Libretto

👀 At a glance

Six problems, six design changes

🧩 The problem

Parents need their children's health documents at unexpected moments: a school form due today, a new specialist, a vaccine appointment. In my interviews, those documents lived in binders, paper notebooks, phone photos, WhatsApp chats and cloud folders, often all at once.

Health systems don't always help. Some clinics don't share records, so every new doctor means starting again. One father told me his five-month-old daughter had already been seen in at least five different places.

The core job: store a document quickly, find it reliably, and show it when someone asks.

How the brief narrowed

My starting brief was broad: let parents review their children's records, print them for school or camp, and see when visits are due. Interviews showed that everything else depends on one thing working first: getting a document in and back out again. I kept printing and appointments for Pablo, the secondary persona, and later work.

🔍 Research

What I did

I interviewed five parents and parents-to-be in Argentina and Ireland, then grouped the notes into themes in Mural. Before the first interview I tested my questions on a fictional parent and found one was leading: asking about "organising" assumed the need, when it could just as well be storing, finding or sharing. I reworded it.

What I heard

See the raw notes and the competitive audit

Competitive audit. I compared 7 direct competitors and 3 indirect ones (Google Calendar, Google Drive, Notion), and looked closely at Guava Health and Google Drive. All the direct competitors offered some kind of family profiles. Neither of the two I studied closely offered end-to-end encryption, and Google Drive's screen reader didn't read out file names. That pointed to three opportunities: family profiles done simply, privacy explained plainly, and a calm identity that doesn't look like a hospital.

👥 Personas

Persona photos are illustrative. I designed for Anne first; Pablo's needs (reminders, printing) shaped the Calendar later.

🎯 Defining the problem

Problem statement

Storyboards

The storyboard follows that moment: Amapola needs a document for school today, Anne can't find it, and later, with the app, she finds it in seconds.

A second, close-up storyboard follows the moment the app has to get right: Anne opens it, is welcomed, taps Add, chooses to scan or upload, fills in the info, confirms, and sees "File uploaded".

From storyboard to paper wireframes

I sketched five screens (Home, Add a file or scan, Document details, Confirmation, Search), drawing on apps people already use to manage files, such as Google Drive, OneDrive, Proton Drive and Dropbox. For Home I drew five variations side by side, then redrew one before moving to Figma, where I rebuilt the screens as a clickable lo-fi prototype.

See the paper wireframes for details and search

🧪 Study 1: testing the lo-fi prototype

Goal: find out whether the app lets people retrieve a record faster than a paper folder. Who: 5 people aged 23 to 50, including a physician and someone who prefers hard copies. Tasks: add a medical record, fill in its details, then find it from Home. The results below describe where people got confused. They don't include task times, so this study can't say whether the app is faster than a paper folder.

See how I sorted the observations

Problem 1: The details screen didn't tell people what to do

Principles: recognition over recall, and progressive disclosure: ask for the minimum now, more later.

Before

After

Problem 2: People weren't sure the file had been saved

Principle: visibility of system status: show the result where people will look for it.

Before

After

Problem 3: Home mixed files and appointments

Principle: group related things together and keep navigation visible.

Before

After

🎨 Going hi-fi

Colour and type

I wanted the app to feel trustworthy, warm and familiar, not like a hospital. Most health apps are blue and white, and parents are often already stressed when they open one. I took paper, ink, wood and green as the reference: a calm palette with no saturated colours.

• Dark wood#4B2C1E
• Olive#4B5936
• Paper#F8F6EF
• Paper light#F3EFE6
• Gold#CA9F5D
• Ink#2C2C26

LibrettoRoboto Serif gives the archive-like feel of a record book. Roboto Slab is used only for the app name.

The colour and type choices come from my moodboard and my own judgement, not from a user study. Preference

How the look changed, version by version

• Two moodboards. The first, in August, was a cool blue duotone, a direction I moved away from. The second, in October, used real materials instead of other apps: wood grain, warm paper, a deep green and a wooden bookshelf. I took the palette from it with Adobe Color and turned it into Figma variables.
• Hi-fi v1. A cream background, very dark brown main buttons, bright yellow for pressed and active states, and a big "Hi, Anne." greeting. The direction felt right, but the yellow broke my own rule of no saturated colours, and the greeting took space from what Anne came to do: see and add records.
• Black became brown. I tried full black for the strongest elements. The main buttons now use dark wood brown, which keeps strong contrast (9.39 : 1) but stays in the wood-and-paper family.
• Yellow became gold. The muted gold works as a pressed state because ink on gold is 5.77 : 1. Gold on paper is only 1.83 : 1, so I never use it for text.
• Hi-fi v3 gave the app its name. Libretto feels closer to a small personal booklet of records than "Health Records App". Home lost the greeting and gained a chip showing whose records you are looking at.

I used ChatGPT only to explore colour combinations. Claude, connected to my Figma and Notion files, listed what the first hi-fi prototype was missing, and each gap in that list is tied to a finding from my research.

Layout

Material Design 3 for Android on an 8 px grid, one main action per screen, always at the bottom, and the same record card everywhere a record appears, so people recognise it.

Accessibility checks

I measured contrast on the design tokens with the WCAG 2 formula. The thresholds are 4.5 : 1 for normal text and 3 : 1 for large text and interface parts such as borders and icons. Established guidance

Icon buttons sit in 48 × 48 px containers. The 32 px filter chips are below Material's 48 px minimum, which I haven't explored yet. Filled and outlined icons mark the active tab, so position doesn't rely on colour alone. Screen reader support and large text sizes are not checked yet.

🧪 Study 2: testing the hi-fi prototype

How: 4 moderated sessions in September 2026, on a desktop screen-share, thinking aloud. Tasks: add a child's blood test result, find it when the school asks, then edit it. Afterwards I asked what was confusing, where they thought the file went, and whether they'd trust the app.

Problem 4: Nobody could open a record after saving it

Why it mattered: Anne's job ends with showing the document to the school or the doctor. The flow stopped one step short.

Before

After

Problem 5: "Destination" made no sense, and nobody knew where the file went

Principle: match the real world: file things the way parents think about them, by child and by type, in plain words.

Before

After

Problem 6: The app chose the child without asking

Principle: user control: make defaults visible instead of silent.

Smaller fixes and the backlog

✨ The final design

Beyond the core flow

I also built what Study 2 couldn't exercise: Records as folders (child, then type, then year) that mirror the saved path, Search across records and appointments, and a Calendar with reminders for Pablo.

Try the prototype

Design system

43 components built in three levels (main component, nested component, icon slot), with colour, type and spacing stored as Figma variables and styles.

See the components and layout tokens

🚧 Limits and what I haven't explored yet

Not explored yet

These are questions I haven't answered, not a to-do list.

🌱 What I learned