Lunch Money Buddy

Problem

I was tasked with developing a school lunch funds management application from a previously designed set of personas. The development cycle would be no more than seven weeks.
The design required the following needs:

• Add Funds

• Auto Renew Funds

• Lunch Alerts

• Subsidy Status

• Different Payment Options

• Add and Remove Lunch Accounts

Using the double diamond: My part of the project centered around the Define, Develop and Deliver Phases.

Actions

The goal of this application design was to develop a prototype that could be tested digitally rather than crafting a paper prototype.

Define Phase

Story Boards

My first step was to cultivate a low fidelity user journeys and site maps based on each provided persona. Starting out was the creation of story board detailing the steps (as shown in the image below) on how I would take the user through the journey of accessing a child’s lunch account. Then how to go about adding a payment plan and add funds to the account.

User Journey

In tandem of creating storyboards to show the actions of the journey, I also created flowcharts to give a more grounded sense of the design.

I went with creating a storyboard and sitemap structure to give a greater range of understanding of my goal. With the inherent strength of a storyboard to explain the key actions of the overall experience without becoming bogged down in all the minute actions that one typically does without thinking about. The features needed

As was mentioned earlier the flowchart’s more ridged structure helped me convey the design of how a user would choose a child’s upcoming lunches that they wished to be alerted to. I felt that do to the complex nature of this feature, guiding a client through each step could bring more understanding.

In addition, I created two site maps to show the grouping of features for each design. It was within each of these that similarities appeared between the two. I decided that the users needed a main menu so as to quickly move to the information they were seeking with as few steps as possible. As well, as try to keep similar features grouped together for clarity.

Develop Phase

Wire-frame

Using the storyboard and sitemap as a starting point, I created a set wire-frames detailing both a portrait and landscape layout.

I started with two separate wire frame designs for each persona. One focused on speed and the other about clear understanding of the actions that were available. Both designs were arranged to have each feature or displayed information separated into cards. I felt that it would help a user discern information easier and help guide users to their needed task faster.

During feedback, sessions will my colleagues; I came to the conclusion that the application needed the ability to quickly jump between a few of the key features. As such I added a navigation bar to the bottom of each both the funds sub menu and lunch menu. This way a user did not have to go back to the main menu if they wanted to go from the lunch to funds menu.

In a previous design, I focused on visual elements to inform the user of their function, but found that it confused more than helped. In this design, I went the opposite direction and used text to inform the user. What I found is that though I had higher legibility, wording could still create confusion based on the user’s way of thinking.

Deliver Phase

From the wire-frame phase, I moved on to developing a digital prototype using proto.io. The two-wire-frame designs were also merged into one at this phase. Taking the strongest ideas from each wire-frame into a single design that could be beneficial to a diverse set of users.

At the beginning of constructing the prototype, I realized that the amount of design space I was giving myself during the wire-frame phase was far too restrictive. In turn, my design evolved into allowing each card to be seen on screen at the same time. This helped create a more uniform look across the application and give some breathing room for each feature as well.

I wanted to be as direct as possible about what each function accomplished. Originally, this was because possible users of the application would have less experience with mobile applications. While it helped with the flow of the project, I found through feedback that I was being too direct and it was taking away from the experience. This was the first time I started thinking about how much wording could affect the experience.

Results

Following multiple revisions through interactions with my colleagues on where areas that the design needed improvement.

The app is:

• A basic design with very little fluff that could use a little flair to help make the user experience more enjoyable

• Though simplistic, the design can be understood by the user with a minimal amount of effort. With each feature separated to minimize confusion.

• A small amount of steps are needed to complete a task

• The calendar system for the lunch schedule could benefit with some alterations and a fair amount of testing to see if users can operate it easily

• Visually bland, but still give a feeling of security and stability

Lessons Learned