flows, not screens
The arrows are the design work
A screen is easy to draw and cheap to argue about. What decides whether an app is any good is the route between screens, and what happens on the branch nobody wanted to think about.
Skip to how an app is scoped
Disciplines 02 · Mobile apps
Mobile apps, one decision per screen
Mobile design makes every decision visible. Limited space forces hierarchy, navigation and interaction to earn their place. I explore iOS and Android as one job — interface concepts and working prototypes that treat design and build as a single discipline.
- Platforms
- iOS and Android. Design and build are the same job, done by the same person.
- Approach
- Scoped before it starts, iterated as it goes, finished rather than abandoned.
- Status
- Interface concepts and prototypes — no published store app yet.
- Accessibility
- Built to WCAG 2.1 AA practice — dynamic type, contrast checked, a label on every control.
- Source
- Prototypes and source kept in one place as I build.
01 · What this is
The screens, and everything that decides them
An app people open on a phone: the interface, the flows between screens, the states nobody remembers to draw, and the small mechanical decisions that make it feel like it belongs on the device rather than on a website that has been squeezed. Design and build are one job here, not two — which mostly matters at the seams, because the seams are where a handover loses things.
Most of the cost of an app is not in drawing it. It is in the decisions taken before anything is drawn, and in the states that only appear when something goes wrong.
one thumb
The important control is where a hand reaches
A phone is held, usually in one hand, often badly. The primary action goes inside the arc a thumb can cover; the destructive one deliberately does not.
dynamic type
The reader already chose their text size
Somebody set that in their system settings for a reason. Layouts are built to grow with it rather than clip it, which is the single most common accessibility failure on a phone.
local first
The device holds the truth until the server can be asked
Work done on a train is still work. What was saved locally is shown as saved, what has not reached the server is shown as pending, and neither pretends to be the other.
two platforms
One design, two sets of conventions
Back is a gesture on one and a bar on the other; the primary action sits in a different place. Matching the platform is not a compromise on the design, it is part of it.
the release
The last step is somebody else's queue
Build, submit, wait. Preparing the listing and walking a submission through is its own small discipline, and a review process will not allow everything — that gets flagged early rather than argued with.
02 · The states
One screen has five states. Four of them get skipped.
Almost every app is designed in the state where everything worked: content arrived, the network was there, the account existed. The other four are where people actually decide whether to keep it. All five are drawn before anything is built.
- 01
Empty — before there is anything in it
The first screen almost everyone sees, and the one almost nobody designs. It has to say what this is for and give exactly one thing to do next.
- 02
Loading — while it is still thinking
Shaped like the thing that is coming, so the layout does not jump when it lands. A spinner in the middle of a blank screen tells the reader nothing except to wait.
- 03
Content — the state everybody draws
The one in the pitch deck. It is the easiest of the five and it is the reason the other four get skipped.
- 04
Error — when something has actually gone wrong
What failed, in words, and what to do about it. Never a code, never a shrug, and always a way back that is not force-quitting.
- 05
Offline — when the network is gone
One true sentence for every screen. What is cached is still readable and marked as cached; what needs a connection says so. A spinner that never resolves is why apps get deleted.
03 · The method
Five decisions, before a screen is drawn
Every app worth taking on starts as this sequence, written out and argued with while arguing is still free. It takes an afternoon, and it is the cheapest afternoon in the project.
- What is the one thing this app does? Everything else is a setting. The argument about which one thing it is happens now, on paper, where changing your mind costs nothing.
- What can someone do before signing in? Signing in is a price being asked of people before they know what they are buying. Ask too early and the download is where they stop.
- What does each screen say with no connection? Every screen needs one true sentence for when the network is gone.
- What is the smallest complete version? The one you could put in front of ten real people this month — not the one with every screen drawn.
- Whose accounts are these? Developer accounts, store listings and signing keys belong in one place from the start, so nothing has to be untangled later.
04 · What I test for
What's part of the build, and what I leave for another project
Same size, same weight, both columns. Knowing where a build's edges are is as much a design decision as anything inside them.
Part of the build
- The five decisions above, written down and settled before anything is drawn.
- The interface and the flows, explored and built as one job.
- Every state drawn, including empty, error and offline.
- Accessibility as a build practice — dynamic type honoured, contrast checked, a label on every control, motion that follows the system setting.
- A store listing worked through as a design exercise, end to end.
- Prototypes and source kept in order from the first week.
- Full source, readable end to end.
- Real iteration, not a first draft called final.
Outside this exploration
- A backend that does not already exist — its own exploration, never assumed inside this one.
- Ongoing feature work beyond the initial prototype.
- Store fees and any third-party service — each its own exploration.
- Content, photography, video, and copy beyond a first draft and one revision.
- Anything a platform's review process will not allow. It can be flagged early; it cannot be overruled.
- A live submission through an app store review queue.
- Any claim about downloads, ratings or store performance. These are concept prototypes, not shipped products.
05 · The questions
Answered rather than dodged
Why does an app take so much longer to reason about than a website?
Because two apps described in the same sentence can be an order of magnitude apart in actual complexity, and a screen count alone hides most of it.
The things that drive it are not mysterious. How many screens there really are once the empty and error states are counted. Whether anything is stored, and where. Whether it has to talk to a system that already exists. Whether there is a login, and therefore an account to recover. Whether it goes to one store or both. And how long a review queue takes when it gets there, which is nobody's to control. Those six questions are where the thinking actually starts.
There's no app in the portfolio yet. What do the ten websites actually prove?
Some of what an app needs, and not all of it — worth being exact about which is which rather than blurring the two.
What they do prove: interface work, flow design, keyboard and screen-reader discipline, drawing every state rather than the happy one, and the habit of writing down why a decision was taken. What they do not prove: store submission, device fragmentation, and a release that ends in somebody else's review queue. The honest test is to open any one of the ten builds and read its interaction code — why focus goes where it goes, what happens on a slow connection, what the reduced-motion path does and why. That is the same work, in a browser instead of a store, and it is running right now.
06 · The work
What you can check today
None of these is an app. They are the interaction work an app is made of, they are self-initiated, and each one is live with a write-up saying what fought back.
Signalform
Keyboard-complete interface · 2026. A command palette that behaves like one: focus held while it is open, arrow keys, scroll locked, focus handed back on close.
Noctis Studio
Touch and pointer · 2024. Pointer capture done properly — a drag that does not break when the finger leaves the element, which is the bug every hand-rolled slider ships with.
Brightloop
Drawn interface, no assets · 2022. Progress rings and counters drawn in SVG rather than shipped as images, on one shared observer instead of one per element.
See the ten builds — all self-initiated, all live, all with the source open.
mobile apps
See it in the ten builds
There is no app here yet, but every principle on this page — states, flows, keyboard and screen-reader discipline — is already running in the ten. The projects show the same discipline applied.
Always exploring the next idea.