Lunch Money Buddy is a virtual project designed to demonstrate my UX skills, process development, interaction and visual design abilities.
I was challenged to design an app that would have the following characteristics. Parents would be able to:
1- Sign up for an account using an email and password.
2- Fund the account to avoid children from bringing cash to the school.
3- View account, and school menu by child.
4 - Favorite a lunch (and be alerted a night before about it.)
5- Close the account at any time.
In order to address the presented challenge, I decide to take the following steps.
Step 1. With the purpose to inform content organization, navigation and interaction, I created two User Journeys for each of the two personas based on the user model offered by the "client". I illustrated a range of possible situations and tasks. The reason why I chose story boards was because they served me in two important ways, to devise and sell my solution. In addition to that, storyboards bring a vision to life that anybody can grasp and relate to, while they allow us to achieve those "Aha!" moments we expect team members an clients to experience.
Step 2. After I defined how my user might interact with the device I proceeded to diagram the most appropriate content structure for the app. First, I quickly ideated some alternative structures to organize the app through sketching, and then I crafted a clean flow chart and a sitemap.
Step 3. Once I defined an alternative design for the content organization, it was time to create a complete content wireframe for the app. To demonstrate content placement and user flow, I designed a Comprehensive Wireframe and documented it. It is important to note that this would not be the final diagram of the user interface, but a means to exercise and explore content organization, hierarchy, and user flow. This is why it was crucial to me, at this stage, to work using rough sketching techniques because they offered me the advantage of working fast but in a clear way, enough to request peer feedback.
Several patterns and standards influenced my design and guided me through the process of designing the LMB app. I pushed myself to think critically about the UI scheme, giving priority to aspects of the app that I considered more relevant. Looks, and fancy features became secondary characteristics, while usability and learnability played a more central role. To learn more in detail about what models influenced my prototype and why I considered the design choices I made to be the correct ones for my user, client, and the goals of my project, please check my LMB Process Document.
Although up to this point I collected significant amounts of valuable information for the purpose of designing my app, the application is not ready to be coded yet. Before that, I need to identify potential problems. At this stage, I have a few important questions to answer before continuing with the design process.
1- Is my user able to accomplish the specified tasks successfully?
2- Is the time required to accomplish the tasks acceptable to my user?
3 - Is my users satisfied with the experience? Otherwise, what specific changes will I need to make in order to improve the user experience?
To find the answers to these questions I need a medium to high fidelity prototype to test my application.
Testing the App
Iteration and validation. The time invested in iteration and validation is inversely proportional to the chances of ending up with an unsuccessful finished coded product. We should be able to go back to our design over and over again, always with fresh eyes.
First versions should be minimal, and very sketched. This kind of presentations are more inviting and welcome to open feedback. They allow us to work faster and are not as susceptible to changes. All this is essential to keep the design process rolling.
Course-redirection. Designers should be ready and comfortable with course-redirection, and help clients and peers understand the need to be equally familiar with an “organic" design process that welcomes "error."
Labels and buttons should have broadly clear and familiar names. Labels that are obvious to us, as designers or developers, might not be as evident to the user. We should invest time and carefully look for the precise word to each task we want the user to perform, and each section we want her to enter.
Software applications Used
To develop this project I used the following software applications: Photoshop, Lucidchart, Balsamic and Proto.io.