Lilist — Case Study — Jihan Raihana

A pregnant graphic designer opens Figma for the first time

The first version of Lilist existed in 2021. I was pregnant, about to leave freelance work, and curious about Figma — a tool I'd never touched as a graphic designer.

I designed four frames: onboarding, login, home, and a planning screen. No user flows. No principles. I didn't know what UX even meant. I just wanted an app to help me plan groceries, because I was about to be responsible for a household.

Then my son was born, and Lilist sat in a forgotten Figma file for three years.

In 2024, back from a career break, I reopened that file. The work was unrecognizably bad — but the problem was still real, and I now had three years of life as a household manager to understand it. Lilist became how I taught myself what I'd skipped: how digital products actually get built.

V0 — THE FIRST FOUR FRAMES, 2021

Made during pregnancy — the first time I ever opened Figma. No flows, no principles; I didn't yet know what UX even meant. Built on an old Samsung, so the proportions are rough. The screenshot is left exactly as it was.

Why Lilist, and not my more ambitious project

Before Lilist, my husband and I tried a more ambitious product — JAKA, a multi-device POS system. It was my first attempt at a full UX design with flows and a design system, and it taught me, painfully, that ambition without scope discipline doesn't ship.

We paused JAKA. Around then Sirkala was born — the small studio we created to focus on lightweight daily apps we could realistically ship with two people and no funding.

Lilist answered a smaller question: what's the simplest product we can actually finish? So Lilist became the one that reached a Play Store listing.

V1 — what I shipped

V1 launched on the Play Store in May 2025, built around one opinionated flow:

Plan a list→Shop→Log expenses→See report

It was usable — if you used it exactly the way I expected. This was my first end-to-end product cycle, and I learned what “end-to-end” really means: research, wireframes, a design system, hand-off, sprint planning in Jira, Play Store submission, and the strange anticlimax of watching your app go live.

I was proud of V1. I was about to find out it didn't work.

The day I learned I'd designed for the wrong person

I gave V1 to three friends. No introduction beyond “try this shopping list app, tell me what you think.” All three got stuck — not on a button, on the premise.

WHAT THEY EXPECTED

An app to track what I spent on groceries. I open it, log what I bought, done.

WHAT LILIST DEMANDED

First plan a list. Then shop. Then match what you actually bought against what you planned.

“I thought this was a tracker, not a planner.”
— ALL THREE OF THEM, IN DIFFERENT WORDS

I had assumed everyone shops like me — with a list. Most people don't. They walk in, buy what they need, and want to know later if they overspent. My friends weren't wrong. I was.

The redesign, and the clever idea I had to kill

My first instinct was to serve both kinds of shopper. I sketched two personas — Planners and Budgeters — and built one app with two modes, switched by a single “Planning” toggle.

THE PLANNERS· Make a list first· Want planned vs. actual· Need structure

THE BUDGETERS· Shop spontaneously· Just want to track spending· Want speed

On paper it looked clever. Building it out, I got uncomfortable. To switch modes well, the user first had to know which kind of shopper they were — and declare it. I had removed the forced flow and replaced it with a forced identity. Same original sin, new costume.

✕ THE CLEVER FIX I SCRAPPED — A MODE TOGGLE

WHAT KIND OF SHOPPER ARE YOU?

PlannerBudgeter

✕ SCRAPPED

My first redesign made people declare an identity before they could do anything — the same forced choice, wearing a costume. So I killed the toggle.

My friends never said “I'm a Budgeter.” They said “I just want to log what I bought.”

THE REAL FIX

The problem was never two personas. It was the entry point forcing a behavior before the user did anything — so I killed the choice.

DOOR 01Plan ahead

Make a shopping plan or a bill reminder.

DOOR 02Record after

Snap the receipt or quick-log what you bought; Lilist reads it and quietly matches it to a plan if one exists.

↓ ↓

THE SAME HOME

Beranda — today's plans + recent spending, one glance. No mode, no toggle, no interview.

So V2 makes the list the quiet unit underneath everything, and offers two equally easy ways in. Whichever door you walk through, you land in the same home — the app does the reconciling in the background instead of making the person do it.

WHAT V2 BECAME — 4 TABS, ONE COHERENT PRODUCT

BERANDAHome — today's plans + recent spending, one glance

RENCANAPlan — a forward calendar of shopping plans & bills

BUDGETEnvelope budgeting tied to payday (not a dead date), with savings that accumulate and a no-double-counting withdrawal flow

LAPORANReport — where your money went, framed as awareness, never judgment

PLATE 02 — PHOTO-LED ONBOARDING

V2 opens warm and photo-led — honest about the two ways in: plan ahead, or just record after. No mode, no toggle, no interview, just a friendly welcome into the same home.

LIVE SIMULATORlive · auto-plays 3 slides

PLATE 03 — RECORD AFTER · SCAN

“Record after” only works if it's effortless. On-device OCR + an LLM pass turn a messy receipt into clean items, matched to a plan if one exists — pennies per scan, viable for a two-person studio.

LIVE SIMULATORsnap → read → matched

The design system is a teal-led token set in Nunito, with glass effects used as an accent only — a deliberate choice for readability and performance on the low-end Android phones our users actually carry.

PLATE 04 — DESIGN SYSTEM · TEAL TOKENS, NUNITO

SCROLLABLE — FULL DESIGN SYSTEM IN BUILD

A token-based system in Nunito — palette, type, components, units and states, consistent across every screen (glass used only as accent, for the low-end Android phones our users carry). Excerpt shown; the full board scrolls in the build.

This was the most systemic design work I'd done. It taught me to treat a screen as a system of states — and to treat my own clever solution as a hypothesis, not a trophy.

Honest status

V1 — STILL LIVE

Original flow that didn't survive contact with users, built before we adopted AI-augmented workflows. I'm leaving it live and unmodified — hiding it would dishonestly polish a learning project.

V2 — COMPLETE DESIGN

Every screen and state, from photo-led onboarding through all four tabs, budgeting, settings, receipt scanning, and edge cases — ready for development.

We paused Lilist in late 2025 to focus on Synetic. With Synetic's MVP 1 handed off and now in early testing, I finished the Lilist V2 design in a focused push — and it's in early development with my husband now, heading to a Play Store update. No fixed timeline: Synetic, a live clinic, comes first. Small team, one real thing at a time.

What this project gave me

The full cycle from blank file to Play Store listing — completed once, with all its mistakes.

The discipline to redesign instead of defending V1 — and then to redesign my redesign when the clever fix was secretly the old mistake.

A token-based design-system practice, and the habit of designing for real constraints: low-end Android, pennies per scan, two people, no funding.

A fast AI-augmented workflow that let one person take a whole product from re-think to a complete, consistent system.

The lesson under all of it: real users will always show you what you cannot see alone — including when your “solution” is just your blind spot in disguise.

Lilist isn't my biggest project. It's the one that turned me from a graphic designer into a product designer.