Mobile Interaction Design

A funds management app called Lunch Money Buddy


A middle school was having issues with their children managing their lunch money. They wanted a mobile app (Lunch Money Buddy) which would allow the children's parents and guardians to manage lunch funds remotely. Other features such as low funds alerts, lunch calendars and favorite lunches were being considered as well.

My approach.

I first reviewed the app specifications brief to decide what features the app should have. I made notes as I went of ideas or potential problem areas. This gave me a vision of where the design should be headed.

Then I considered the app's users. User personas helped me see how intuitive the app needed to be to appeal to such a varied audience as the guardians of school children. For example (see user journeys below), the theoretical "Samantha and Jorge" were tech-savvy, but "Henry" was not. He would need something simple, something that behaved according to his mental model. Only usability testing could refine that, but I aimed for simplicity in the meantime. 


M.S., Academic Project

Competitive analysis.

Once I had a good understanding of what kind of app I needed to design, I looked at similar apps I had used myself. The Chase bank and Ally bank apps came to mind. Money-management apps. In particular, I liked the Ally app because:

• The most important information was prominent. (The balance.)
• The main screen was as simple as my bank portfolio. (Only 2 accounts? Only 2 on the screen.)


I did foundational work by designing a site map and user journeys. The site map let me see if all the parts played well together, and the user journeys tested the logic of the map.
  • Site Map
  • User Journey

Wireframe sketches.

With the foundational work completed, I started sketching the interface. I kept the personas in mind, focusing on making the design useful rather than aesthetically pleasing. That's what drafts are for! I also made sure I was incorporating all the functionality required in the design brief.


In these high-fidelity wireframes, the account balance features prominently. I kept primary functions as visible as possible, such as the “Add Funds” button on the main screen. I divided the primary menu into 3: calendar, home (the landing page), and funds management. The secondary functions are kept in the hamburger menu.

The text is large and contrast is high, keeping with accessibility standards. A fingerprint login is an option for the time-conscious. Interactions have visual feedback to reduce user frustration, and common symbols are used wherever possible for ease of adoption.

What I learned.

If I could do this again, I would build out individual account pages for the children, not just individual calendars. What if a parent has two children attending different schools? The balance would be different for both of them. Also I would add the account balance under the dollar symbol menu, because I can anticipate confusion there. I was resisting redundancy, but there are times when redundancy is appropriate. Of course, A/B testing could help with such a decision.