Nutriguide
A mobile app that lets people with allergies, dietary restrictions, and disabilities scan a product and instantly know whether it's safe for them, without decoding an ingredients label first.
Built during my final year at university as my dissertation project. My earliest end-to-end UX/UI project. I was the sole designer, responsible for research, information architecture, interface design, and accessibility.
Company
Concept Design
Type
Native App Design
Role
Lead Designer (end-to-end)
Team
Me (UX/UI & Development)
Timeline
2022
Onboarding: choosing allergies and how strict to be about “may contain” labels.
Problem
Food shopping can be stressful, and sometimes risky, for people managing allergies, dietary restrictions, or disabilities. Ingredient labels are small, cluttered, and often written in language that isn’t easy to scan quickly, especially under time pressure or with a visual impairment. The tools that existed didn’t offer much personalisation or accessibility; people were left to cross-reference labels against their own restrictions every time manually.
The challenge
How might we tell shoppers in seconds whether a product is safe for them, without making them decode the label?
Process
Research
I used a mix of interviews, a survey, and literature review - partly to get real accounts of the problem, partly to check my design decisions against established accessibility practice rather than just my own assumptions.
Interviews. I spoke to 10 people with a range of needs — severe allergies, coeliac disease, and visual impairments among them. What came through clearly was how much of the stress wasn’t about not knowing what to avoid, but about the time and effort of checking every time. One participant’s comment stuck with me: they said something like being able to check a product instantly would actually change how they shop, because they’d stop standing in the aisle looking things up.
Survey. 150+ respondents told me, in order, what mattered most: fast and reliable scanning (50%), clear plain-language explanations of what’s in a product (30%), and personalised safety alerts (20%). This shaped what got priority in the interface - speed and reliability came before anything else.
Literature review. I read into accessibility and inclusive design guidelines, food labelling regulations, and research on consumer decision-making in retail settings, mainly to sanity-check what I was hearing from participants against wider evidence rather than take individual feedback at face value.
If I could check a product instantly, it would change how I shop. I’d stop standing in the aisle looking things up.
Checking is the stressful part, not knowing what to avoid.
I wasn’t sure if it was flagged for my allergy, or if it was just a general warning.
Knowing it was checked against my own list made me trust the answer.
What participants told me in interviews and usability tests. Paraphrased, not verbatim.
Process
Information Architecture
The goal for the information architecture was to minimise the distance between scanning a product and getting a clear, personal answer, because people are usually shopping under time pressure, not browsing at leisure.
The core flow: Onboarding & Preferences → Product Scan → Instant Risk Assessment → Ingredient Details → Suggested Alternatives.
A few needs shaped how I prioritised within that:
Parents managing a child's allergies needed a direct scan-to-result path with as little interruption as possible.
Low-vision users needed less on-screen clutter, a clearer visual hierarchy, and a logical focus order for screen readers.
Health-conscious users and students needed quick access to edit their preferences without breaking their shopping flow.
Search, saved products, scan history, and settings all sit as secondary paths — there if you need them, but never in the way of the main scan-to-result loop.
Information architecture: a short scan-to-result loop, with secondary paths kept out of the way.
Process
Testing and what changed
I ran usability testing with people from the target group, asking them to think aloud through setting preferences, scanning a product, interpreting the result, and editing preferences afterward.
A few things came out of it that changed the design directly:
Result screens weren't clear enough at a glance. People hesitated on the safe/caution/unsafe result — the distinction wasn't obvious fast enough. I strengthened the visual hierarchy and made the three states more clearly differentiated, both in colour and label weight, so the answer registers before anyone has to read the detail.
Ingredient lists were still hard to parse. Some testers slowed down trying to interpret raw ingredient names. I simplified the language used in the results and highlighted the specific ingredients driving a flag, instead of listing everything with equal weight.
Low-vision testers needed more room. More spacing, larger default text, less on-screen density — small changes, but they came directly from watching people struggle with the denser first version.
People wanted to know the result was actually personal to them. A few testers weren't sure if a flagged product was flagged for their specific allergy or as a general warning. I added a line confirming the result was based on their saved preferences, which testers said made them trust the app's answer more.
Alongside this, I checked colour contrast, tap target sizing, layout consistency, and focus order for assistive technology, not as a final pass, but throughout, since a couple of the usability findings above were accessibility issues first.
Colour
Type
Spacing, radius and elevation
Layout grid
Built for one hand, in a shop aisleComponents and states
The design system behind the screens: colour, type, spacing, layout grids, and components with their variants and states.
Key screens: home, scanning a label, the result and the allergy card. Switch between the three result states.
The full set of screens.
Outcome
This was a concept project for my university dissertation, so there's no real-world usage data to point to. What testing did show: the scan-first structure worked as intended - people could get from opening the app to a clear answer with minimal steps, and the iterations above measurably reduced the hesitation and confusion I saw in earlier rounds.
What I’d do differently
I'd have tested the result-screen hierarchy earlier, before building out the rest of the flow. It was the piece that needed the most iteration, and testing it in isolation first would have saved rework further down the line.
