Lunch Money Buddy is an app designed to allow parents or guardians to interact with their child's school lunch program.
The Design Problem
The design challenge for the this app, which we are calling "Lunch Money Buddy" was to create a simple, easy to use application with the following functionality:
- Download and sign up
- Add one or more payment methods.
- Add funds.
- Select a primary payment method.
- Change a payment method.
- Delete a payment method.
- Select whether they’d like balance auto-replenishment or not.
- Turn auto-replenishment on/off.
- View account balance
- View subsidy status
- Favorite a lunch
- Close account
The application needed to work for the personas that we were supplied.
The first step was to take the supplied personas and features list and begin to analyze how the users would interact with the application via a user journey. The user journey helped me to understand the how users might actually use the application and move through the different pages. This was a very helpful step as it forces us to think from the perspective of each of the different personas that make up our target demographic.
Following the creation of journey maps, I created a site map. This step is important to help understand how the application would function. Given the need for the application to interact with potentially several different third parties, I structured the site accordingly with the user accounts forming the central hub. This means that when a child account is selected, the information regarding that account is accessed from the school or district while the other accounts remain un-accessed until their account is selected.
After creating a site map, my attention turned to wireframes. These drawings progressed from pencil sketches to more illustrated drawings of the layout of the application. In considering how the app would be used and structured, I determined that the average user would be likely to use the app to check balances and menus more often than anything else. As a result, during the wireframing and prototyping phases I made sure that these tasks could be completed from the main screen. This minimizes the need for browsing into different areas of the app for the most common tasks.
During this first and the following initial prototype phases, I had opted to make the children available on the landing page so that they would be easy to get to when you logged into the account. While this seemed to be a good solution at the time, the end result was that it became much more difficult to access them in cases where you were adding funds to more than one account since you'd have to browse back to the landing page in order to switch accounts.
This complicated things and I determined that I needed a more functional solution. Instead of adding those same buttons on all the pages of the application, I added a second menu at the top right where the user could add, remove, or change accounts. This made the use of the system much more practical.
The final step for this project is to project a higher fidelity look. In normal circumstances a usability test would determine the viability of the design decisions but that is outside the scope of this particular project.