Product design measured in completed tasks, not compliments
Research, interface design, and prototypes for products where people are trying to get something done — and a design system your engineers can actually build from.
Good product design is mostly subtraction. Fewer steps to checkout. Fewer fields in the form. Fewer decisions on the screen where someone is trying to find a part number, place a wager, or read a chart before the market moves. We start by watching how people currently do the task, including the workarounds and the spreadsheet they keep on the side, because that's where the real requirements are hiding.
Because we build software too, our designs come with an implementation reality check. Components map to what the front-end framework can render efficiently. Empty states, loading states, error states, and long-content cases are designed rather than discovered in QA. Dense data screens get treated as their own craft — tables, filters, and dashboards need different thinking than marketing pages. You get files your developers can work from and, if you'd like, the engineers who'll build it.
- User research with your actual customers or staff: interviews, task observation, and a written summary of what's breaking
- Information architecture and flows for the core journeys, agreed before any pixel work begins
- Interactive prototypes you can put in front of real users and test before committing to a build
- Full interface design including responsive behavior, empty and error states, and accessibility to WCAG AA
- A component library and design tokens documented for handoff, so the built product matches the design
- Design QA during development, so the last ten percent doesn't quietly disappear
How we work
Learn the task
We talk to users and watch them work, then write down where they hesitate, backtrack, or give up.
Restructure before decorating
Flows and information architecture get fixed first, because visual polish can't rescue a bad structure.
Prototype and test
Clickable prototypes go in front of five to eight real users, and the findings change the design before code exists.
Hand off and stay close
Components, tokens, and specs go to engineering, and we review builds against the design as they ship.
Work we have shipped
DraftEdge
Machine-learning player projections that keep pace with live injury news right up to lineup lock.
ML pipeline in production Read the case studyStockZ & The Whisper Number
Real-time market data, earnings estimates, and whisper numbers — where a stale figure costs the user money.
Real-time through peak load Read the case studyCommon questions
Often, yes. A lot of the gain comes from restructuring navigation, simplifying forms, and fixing the top three flows. We'll scope a design-only engagement your existing developers can implement, and we'll be honest if the underlying code makes that impractical.
Five to eight per round finds most of the significant usability problems. What matters more is that they're genuinely representative: real customers or real staff doing real tasks, not colleagues clicking through politely.
Yes, though our strongest work is in product interfaces: dashboards, catalogs, admin tools, and data-heavy applications. If you need a brand identity built from scratch, we'll tell you where our work ends and a specialist should start.
Show us the screen your users complain about most. We'll show you what we'd change and why.
One business day. From an engineer. No sales sequence.
or email customers@etlon.net