Available from November
I am Rowan Ellery. I design product interfaces, build the systems that keep them consistent, and stay close enough to the code that the hand-off does not unravel. One project at a time, start to finish.
Engagements
Each one is scoped as a fixed set of deliverables with a named end date. If your problem sits between two of these, say so in the brief and I will propose the shape that fits.
01
Redrawing a core flow that has grown awkward — onboarding, scheduling, reporting, permissions. I work from your existing product rather than a blank canvas, so screens land in the same grammar your users already know.
02
An audit of what you already have, then a trimmed component library with tokens, states and written usage rules. The goal is fewer components than you expect and enough documentation that a new engineer can use them unaided.
03
A single-purpose site for a launch, a funding round or a repositioning. I write the layout in the browser rather than handing over flat files, so what you approve is what deploys — content model included.
04
For teams that need a designer in the room but not a full-time hire. Fixed days each week in your tools and your stand-ups, working the same backlog as your engineers, with a written summary at the end of each week.
Method
No discovery phase that quietly eats a third of the budget. Four stages, each with something reviewable at the end of it, and a clear note on what I need from you while it is happening.
1
A single call to establish what is being decided, who signs off, and which constraints are fixed. I write it back as a one-page scope with deliverables, dates and a fixed price before anything starts.
From youAccess to the current product and one decision-maker.
2
Flows, states and hierarchy in low fidelity first. This is the stage where changes are cheap, so it gets the most review time and the bluntest questions.
From youAnswers on real data and awkward edge cases.
3
High-fidelity work lands in a shared file you can open any day of the week. Weekly review call, written notes after it, no month-long silences followed by a reveal.
From youOne consolidated round of feedback per review.
4
Specs, tokens, named states and a walkthrough recorded with your engineers in the call. Two weeks of questions afterwards are included, so nothing stalls the week I leave.
From youThirty minutes of your build team's time.
Selected work
Short descriptions of what was built and the part I owned. Fuller case notes, including the decisions that did not work, come with the proposal.
Interface design · Field software
A dispatch and scheduling tool for maintenance crews working offline. I redrew the day view and the job-assignment flow so a dispatcher can reassign a route without leaving the schedule.
Design system · Finance product
A reconciliation product whose interface had drifted across four teams. I audited it down to twenty-eight components, set the token layer, and wrote the usage rules the team now reviews against.
Site design & build · Publishing
An independent publisher moving from a template to something of its own. Designed and hand-built as a single long-form page, with a content model their editor maintains without me.
Working terms
These come up in almost every first call, so they are answered here instead. Anything not covered below is fair game in the brief.
Fixed price per phase, quoted after the brief call and written into the scope document before work begins — not an open-ended hourly count. Retainers are billed monthly for a set number of days. If the scope changes, we re-quote the affected phase rather than silently absorbing it.
Usually four to eight weeks, because I run one project at a time. A brief sent early holds a place in the queue without committing you to anything; if your timing is tight, say so and I will tell you honestly whether it is possible rather than squeezing it in.
You do, on final payment — source files, exported assets, tokens and any code I write for you. I keep the right to describe the engagement and show selected screens as work, and I will agree a confidentiality window with you if that is a problem.
For marketing sites, yes — I design and build them directly, which is why they ship quickly. For product work I stop at the interface layer: components, states and specs your engineers implement, plus pairing time during the build. I read your codebase, but I do not commit to it.
Often that is the point. I join your tools rather than importing my own, follow whatever review ritual already exists, and write down decisions so nothing depends on my memory. Where you have a design lead, they set direction and I take a lane inside it.
Small changes are absorbed in the current phase. Anything that moves the end date gets written up as a short addendum — what changed, what it costs, what it pushes back — and nothing proceeds until you approve it. Projects are stopped cleanly at the end of a phase if priorities move.
Start a brief
A few lines is plenty to start. I reply to every brief with either a proposed shape and a date, or a straight answer that this is not a fit.