Lunch Money Buddy - Mobile App

The Objective

In our Interaction Design class, part of the M.S. in Information Architecture program at Kent State, we were asked to create a mobile app called “Lunch Money Buddy” which would allow parents their children’s school cafeteria lunch accounts.  Parents and guardians had to be able to accomplish the following using the app:

  • Download and sign up
  • Fund the account
  • View the account balance
  • View school lunch menus by child
  • View their lunch subsidy program status
  • Favorite a lunch
  • Close the account

In addition to meeting the above criteria, we also had to cater to three personas: Samantha and Jorge, busy and disorganized working parents who conduct most of their financial business online, and Henry, a retired grandpa who buys lunch for his grandson every day but is slow to adopt new technologies.  To cater to these very different personas, we had to design an app that was simple and intuitive so it could be easily used by people unfamiliar with new technology; it also had to be convenient and full of reminders to ensure that busy parents on the go would not forget to fund their children’s accounts.


User Journey Maps

Based on the personas I was given, I first created user journey maps, which helped me put myself in the shoes of Jorge, Samantha and Henry, and understand what tasks they would want to accomplish and how, as well as their feelings throughout the workflows.

User Journey - Henry

User Journey - Samantha


Sitemap

Now that I had a feel for the personas’ top tasks, concerns and motivations, I could start outlining the architecture of the application with a sitemap.  The sitemap established the navigation and main screens in the app, and it provided some basic context around the functions of each screen.


Wireframes

With an outline of the site structure in place, I could begin to play with the layout of the site and dig into the more granular pieces of functionality using wireframes.  Collaboration with other classmates was an important part of this process, as we were able to use other designers’ suggestions for optimizing the layout and covering any requirements we had missed in our first few iterations.


Prototyping

I then used Proto.io to create interactive mobile prototypes, increasing the fidelity of the wireframes and linking them together and began using standard UI patterns and interactions.  I opted to use Google Material Design patterns, which have become the standard for Android devices.  Again, collaboration with our classmates during this step helped us cover our blind spots and gather ideas for improvement.

The result of this process was an interactive wireframe that could be used to conduct user testing.  Finding and fixing errors in the user testing phase is much less expensive than fixing them after a system has been fully implemented, so it's important to test prototypes with users and fix any usability issues before they make it into development.


Lesson Learned

I had already been quite familiar with the process of wireframing and prototyping, but (and I think this is common for many designers currently employed in software) I realized how I had been under-utilizing tools like personas and user journey maps.  We do have personas where I currently work, but rarely do we apply them to user journey maps to help us really get into the shoes of our users and understand their motivations.  We think we know our users until we spend hours trying to walk through the workflows from their perspective–then we discover small needs that we had overlooked.  Going forward, I think I will spend more time in this phase of the UX process, as it is an important part of the user-centered foundation on which the rest of our applications are built.