School Meal Ordering App

UX • UI 

Sector: Hospitality

Tools: Sketch, Adobe Photoshop CC, MarvelApp, SAAS, Adobe Color, Jira,

The School Meal Ordering App is a SAAS based application designed for both the parents and the students to pre-order their school meals. There are two distinct versions of the app:

  • Primary school oriented. In this version of the app, a parent places meal orders for their children a day, a week, or even months ahead.
  • Secondary school oriented. In this version, the child registers and places orders for themselves.

 

Applications of this kind are used by various schools all across the UK. So how did I approach the task of designing such an important app?

Research

• Core message
• Target market
• ntention

Problem

• Persona
• Problem
• Plan

Idea

• Attention
• Engagement
• Goal

Prototype

• Ideas
• Creation

Testing

• Functionality
• Success
• Team effort

Research

This is the very first question I always ask myself, before I start looking at the task at hand. And the answer, in this case, is pretty vague; this application is a software as a service tool, designed for various possible customers on-demand – meaning that this app is aimed overall at the education field within the UK.
The task in front of me is the UX and UI of two functional apps that are supposed to coexist within our target market:
  • The first application is targeted at parents whose children attend school;
  • The second application is targeted at those children who are actively attending the school in question.
In the end, this leaves me with quite a broad target user base, that I am supposed to divide based on age and goal.
The application I set out to design is supposed to make ordering school lunches much easier for both the parents and the students. To improve the efficency of the catering service and reduce the queue time at the canteen. How can I achieve that?

Since we are looking at an app that would facilitate food ordering, I wanted to perform some:

  • Comparative analysis with other applications that deal with food in the UK (Deliveroo, JustEat, UberEats, Monzo) and with applications that are popular among my target market’s age groups
  • Target market analysis would insinuate analysing several layers of population: 
    • The education field: what schools would be interested in using my application? How do I adapt the functionality of the app to the needs of the schools in question? Overall, what is my application’s niche?
    • The parents of young children: are they technologically engaged? How do I make the app easy to use and navigate? What would my target user base need the most (and the least)?
    • The high school students: what do teenagers find appealing in applications? What do teenagers hate?

Problem

To start working out my plan of action, I need to ask myself how do I cater to such a broad userbase?
For that, I am going to address customer personas.

Eileen Hayward

Primary persona – a parent.

Donna Grey

Secondary persona – high school student.

Idea

As I always do, I start my ideation process by channeling my imagination through a simple flowchart that is supposed to include all functions necessary without creating any unnecessarily complicated function intersections.

 

Both applications are to have incredibly similar functionality, which is why their flowcharts are almost identical.

 

To keep to the simple flow of this diagram (Figure 1.1 & 1.2), as well as resolve the problems presented by the personas, I would have to:

  1. Present an application with no complex roundabouts or hidden functionalities,
  2. The initial prototype of the design is BlueRunner Solutions branded. Which means:
    • A design that is easy to customise according to the preferences of each client (images, colour variations, fonts, etc)
    • Simpler app design overall to cater to a wider audience – so that it is applicable for any possible client.

(Figure 1.1)

(Figure 1.2)

(Figure 2.1)

(Figure 2.2)

(Figure 2.3)

Prototype

  • Step one: a low-fidelity prototype, where an overall outline of the main pages of the application
    • For the parent-oriented SMO: “Wallet(s)”(easy to swite left or right between them or open all of them by tapping at one Figure 2.1), “Menu”, “Previous orders”, “Transaction history”) is created.
    • For the child-oriented SMO: “Wallet(s)”, “Menu”, “Transaction history”
    • Clear navigation and labelling of the pages. Added the page names at the top.
  • Step two: main functionality descriptives and changes to the skeleton of the app:
    • Home: (= child profile,) immediate access to the other pages (Wallets, Menus, Orders, History, etc)
    • Menu: calendar for navigation, food information (Figure 2.2),
    • Previous orders: orders listed by date with cancellation and editing options,
    • Added top-up function (Figure 2.3) right to the main page,
    • Transaction history: all payments, sorted by date
  • Step three: additional customisations per app:
    • Parent-oriented SMO: option to add photos of children for easier navigation, option to enable Offers depending on the client
    • Child-oriented SMO: added QR code scanner page (code with white background for easy functionality with no hitches)
  • Final step of this stage: creation of a medium-fidelity prototype for testing and overview.

Design system

I developed brand guidelines and design systems for BlueRunner Solutions. When I start working on the UI design for an app, the initial design is our own. Therefore, the overall design system is based on the BlueRunner Solutions directives, which are:

  • Simple design with minimal backgrounds and overall details (for easy adaptability and customisation),
  • Bold and easily legible headings, body texts,
  • Colours are light, nothing too bold or saturated,
  • Easily visible separation of all the buttons (noticeable borders/background colours)
  • Personalised (replaceable) icons

 

This design system is not set in stone, meaning that later we change the colours, logos, type faces and images for the apps to make them fit our clients’ brands.

Icons & Colours

User Journey flows

Onboarding & Registration

Home page with wallets

Order meals

Examples of the client's apps

Feeding Hungry Minds

Greenshaw Trust

Sodexo - School Food United

Harlaxton College

Test

The testing process was done in two different sessions.

 

Session 1: QA bug testing. (Both SMO apps)

  • 4 participants:
    • BlueRunner Solutions employees
  • Untimed testing session dedicated to: 
    • Looking for bugs typical for the apps of such profile,
    • Testing if everything operates smoothly,
    • Testing if orders are coming in.
  • Any design adjustments for additional functionality / removed functionality / low visibility.

 

Session 2: timed testing session for parents. (Parent-oriented SMO)

  • 10 participants:
    • People of varying genders and ethnicities,
    • Over the age of 30,
    • With at least one child.
  • A timed testing session, where the participants were tasked with:
    • Registering into the system,
    • Adding children,
    • Accessing their child(ren)’s wallet(s) and topping them up.
    • Accessing the menu and selecting 3 meals that are up to their preferences,
    • Finding the nutritional value of the 3 meals in question,
    • Placing orders for the selected meals within three different timeframes:
      • One – two days in the future,
      • One – two weeks in the future,
      • One – two months in the future,
    • Cancelling one of the orders,
    • Editing an existing order.

 

Once all the sessions were completed, I looked at the time it took to complete each of the tasks and tried to make the tasks that took the most time more simple and straightforward.

 

Additionally, any feedback obtained from already existing clients from our vast UK-based schools database is counted as test data all along, and has been/will be used to improve the application and, possibly, eventually add additional functionality if necessary.

Thank you!

Let’s make something awesome together