01
Dashboards and overviews
Deciding what gets the first screen, and defending that choice against competing demands.
Design · 02.2
The screens nobody shows in the pitch.
A product is judged in daily use: the form with errors, the table with thousands of rows, the empty dashboard on day one. We design those moments first.
Form states
Default
ErrorCheck the email
EmptyNo data yet
Success✓ Saved
01 / What it is
What we design.
Pick the one closest to yours.
02
Multi-step flows
Sign-ups, applications, checkouts and approvals, including users who leave partway through and come back.
03
Forms and data entry
Field order, validation timing, error wording and keyboard behavior.
04
Tables and data views
Filtering, sorting, bulk actions and density. Twelve rows and twelve thousand rows need different designs.
02 / Included
What interface design includes.
The difference between interfaces that get presented and interfaces that get used.
Every state
Loading, empty, partial, error, too much data and no permission, each designed as its own screen.
Empty states that welcome
The first-day experience, and what users should do next.
Errors in plain language
What happened and the next step, without codes or blame.
Keyboard paths
Tab order, shortcuts and focus management.
Density for heavy use
More information per screen without hurting readability.
Responsive behavior
Deliberate decisions on how tables, dashboards and flows work on phones.
03 / What to watch
What we design against.
Each risk, and how we avoid it.
×Designing with clean sample data, then shipping to messy real data.
We design with long names, empty fields and real volumes.
×Polishing the happy path while improvising the errors.
We design the error version of every key screen.
×Giving every option equal weight.
An explicit hierarchy, with one primary action per view.
×Adding each new feature as another tab.
We review the whole navigation as the product grows.
×Designing onboarding last, for an imagined user.
We design it first, by observing real users.
04 / How it works
How it works.
How we usually work. The quote sets the dates before work starts.
Frame
Who uses the product, how often, and what they're trying to get done. Deliverables: flow map; priority list.
Structure
Low-fidelity wireframes, navigation and hierarchy, tested against the hardest cases. Deliverables: wireframes; structural decisions.
Interface
Visual design applied through the system, covering every state of each key screen. Deliverables: screen designs; state coverage.
Prototype and handoff
A clickable prototype of the critical flows, then documentation and a handoff session with your developers. Deliverables: prototype; handoff specification.
05 / Questions
Questions we get asked
No. We design the high-risk screens and the system that keeps the rest predictable, and we review the screens your team builds.
Yes. Most of our work is redesign: audit what exists, find what's costing money and fix it in priority order.
Decisions are settled in sequence (direction, structure, then surface) and aren't reopened without a reason.
Lightweight testing on the riskiest flows, plus a review of your existing research. Full research programs are separate.
To a point. We'll challenge what belongs on a screen, but product strategy remains your call.
Show us what you're designing.
Describe the project in a few lines. We'll reply with a plan, a timeline and a fixed quote.