Information hierarchy pass
An explicit decision, per screen, about what the user needs first, next, and last, backed by layout, weight, and grouping.
Design
UI design built for the interface people actually use
Not a set of pristine mockups with placeholder text. Interfaces designed for every interaction state and tested against the messy data they will actually display.
Most interface design fails quietly, after handoff, when the mockup meets real content. The empty state nobody designed. The error message that was never written. The table row with a name forty characters longer than the one in the mock. UI design that only accounts for the ideal case is not finished design, it is a proposal for design that still has to happen during development, usually under time pressure and without the original designer in the room.
We design interfaces as systems of states, not single frames. Every meaningful screen gets designed for its default state, its loading state, its empty state, its error state, and its state under real data volume, because a production interface spends most of its life in one of those states and not in the polished default screenshot. This is slower up front than shipping a handful of hero mockups. It is faster overall because it removes the guesswork that otherwise gets resolved ad hoc by whoever is writing the code.
Information hierarchy is the other place this work earns its keep. A screen with twelve pieces of information displayed with equal visual weight is not organized, it is just laid out. Real hierarchy means deciding, explicitly, what the user needs to see first, what they need next, and what should be available but not competing for attention. That decision has to be made consciously for every screen, not inherited by default from whatever order the data happens to arrive in from the backend.
This work covers product interfaces, internal tools, dashboards, and any application surface where people work inside the software repeatedly rather than viewing it once and leaving. That repeated use is exactly why interaction states and accessibility cannot be treated as polish. A pattern a user encounters daily has to hold up under real use, not just first impressions.
What it is
Hierarchy, states, and accessibility as a design constraint
Interface design is judged here by how it performs under real conditions, not by how it looks in a single static frame.
Information hierarchy starts with a plain question for every screen: what is the one thing this user needs to know or do here. Everything else on the screen gets weighted relative to that answer, through size, position, contrast, and grouping. Dashboards are the clearest example of where this goes wrong by default, since stakeholders tend to request that every metric be equally prominent, which produces a screen where nothing is prioritized and the user has to do the hierarchy work themselves every time they look at it.
Interaction states are designed explicitly rather than assumed. Every interactive element needs a default, hover, focus, active, and disabled state defined, along with loading and error states for anything that depends on a network call. Skipping this is how interfaces end up with buttons that give no feedback when clicked, forms that fail silently, and focus states that either do not exist or were left as a raw browser default that clashes with the rest of the design.
Accessibility gets built into the design decisions themselves, not checked afterward with an automated scanner. Color contrast ratios, keyboard navigation order, focus visibility, and screen reader labeling are decided at the same time as layout and typography, because retrofitting accessibility into a finished visual design usually means undoing decisions that were made without it in mind. Treating accessibility as a late QA pass is how teams end up with compliant color contrast and completely unusable keyboard navigation, because the checklist covered one and not the other.
The last test every design has to pass is contact with real data. A user list mock with five clean names does not tell you what happens with five thousand rows, a name with no last name field, or a status field that is empty because the record has not been processed yet. We design against representative real or realistic data before development starts, specifically to surface the truncation, sorting, empty-state, and overflow problems that ideal mock data hides. This is slower than designing against a clean sample set. It is the difference between a design that survives launch and one that starts collecting patch tickets in week one.
Fit
Who this is for, and who it is not for
We would rather say no early than sell a program that cannot work.
Right fit
- You are designing a product interface, internal tool, or dashboard people will use repeatedly, not a one-time landing page.
- You need interaction states, empty states, and error states designed upfront rather than improvised during development.
- You want accessibility decided at the design stage, not audited after the interface ships.
Not the right fit
- You need a marketing site's visual design. That is a different discipline from interface systems built for repeated use.
- You want polished hero mockups only, with states and edge cases left for development to figure out.
- You are not willing to review the design against real or realistic data before build starts.
Deliverables
What this work includes
Every screen ships as a system of states, not a single frame.
Full interaction states
Default, hover, focus, active, disabled, loading, and error states designed for every interactive element, not assumed at build time.
Accessibility built into layout
Color contrast, keyboard order, and focus visibility decided alongside typography and layout, not audited after the fact.
Real-data screen tests
Key screens designed against representative or real data to surface truncation, overflow, and empty-state problems before development starts.
Component-level design
Interface elements designed at the component level so they hold up consistently across every screen that reuses them.
Annotated handoff
Specs and state documentation handed to engineering directly, so the states designed on paper are the ones that actually get built.
How we run it
How the work runs
Hierarchy and states get decided before visual polish, not after.
Step 1: Content and data audit
We pull real or representative data for key screens before designing them, so layout decisions are made against reality rather than a clean sample.
Step 2: Hierarchy decisions
For each screen, we decide explicitly what the user needs first, next, and last, and get that decision reviewed before layout work continues.
Step 3: State design
Every interactive element and data-dependent view gets its default, interaction, loading, empty, and error states designed as a set.
Step 4: Accessibility review
Contrast, keyboard order, and focus behavior get checked against the design before handoff, not left for a later audit.
Step 5: Handoff and build support
Annotated specs go to engineering with the states documented, and we stay available through implementation to answer edge cases that come up.
What makes UI design different from just making an interface look good?
UI design decides information hierarchy, designs every interaction state, treats accessibility as a layout constraint, and gets tested against real data. Visual polish alone does not account for loading, empty, or error states an interface actually spends time in.
Why should accessibility be part of design instead of a later audit?
Retrofitting accessibility into a finished design usually means undoing layout and color decisions already made without it in mind. Deciding contrast, focus order, and labeling during design avoids rework and produces genuinely usable, not just compliant, interfaces.
- Contrast and focus visibility are layout decisions, not a post-launch checklist item.
- Keyboard navigation order has to be planned alongside the visual layout, not inferred from it afterward.
- A checklist can confirm compliant color contrast while completely missing broken keyboard usability.
Where this connects
Where interface design connects to the rest of the work
UI design decisions are built to be reused, and they hand off directly into engineering.
Components and interaction patterns designed here get documented into a shared design system so the next screen reuses decisions instead of reinventing them.
Visual language and typography follow the rules set in brand identity so the product interface still reads as the same brand as everything else.
Interface transitions and feedback states are scoped together with motion graphics so animation supports the interaction states rather than sitting on top of them as decoration.
When the interface is a data-dense screen built to surface metrics at a glance, the hierarchy work described here is exactly what shapes dashboards since a dashboard with no designed hierarchy just becomes a wall of equally weighted numbers nobody can scan quickly.
Layouts built and tested here for print and digital brand touchpoints share the same component discipline as marketing collateral even though the two serve different audiences.
Questions
UI design questions we get asked
Get an interface designed for how it will actually be used
States, hierarchy, and accessibility decided before development, not after.