Visual design that serves the interaction, not the portfolio
User interface design covering layout, visual hierarchy, and component design for web and app interfaces.
What is User Interface Design?
User interface design is the visual layer of a product or site - layout, typography, colour, and the design of individual components like buttons, forms, and navigation - built on top of a structure that user experience design has already worked out. It's the part people notice first, which is exactly why it's easy to overweight relative to what's underneath it.
User interface design is the visual and interactive layer of a product - layout, typography, colour, and component design - applied to an existing structure so that what the user needs to do next is visually obvious.
Why this matters for the business
A visually striking interface that obscures the primary action has failed at its actual job, however good it looks in a portfolio. Visual hierarchy exists to answer one question fast: what does this screen want me to do? If the eye lands on decoration before it lands on the action, the hierarchy is wrong regardless of how polished the individual elements are.
This matters more as a product grows, because inconsistent component design compounds - a button styled three different ways across a product isn't a style problem, it's a signal that the interface wasn't designed as a system, which eventually shows up as user confusion about which version of an element is actually clickable.
What makes this hard to get right
- Balancing visual distinctiveness against the plainer patterns users already recognise and trust
- Keeping hierarchy consistent as a product adds screens over time
- Designing for the real range of devices and screen sizes rather than the one screen in the design file
How we approach User Interface Design
Hierarchy
- Primary action visually dominant
- Secondary actions clearly subordinate
- Decorative elements never competing with function
Typography
- A limited type scale applied consistently
- Legibility prioritised over novelty
- Clear distinction between heading and body roles
Colour
- A defined palette tied to function, not decoration
- Sufficient contrast for readability and accessibility
- Consistent meaning - one colour, one signal
Component Design
- Every component styled once and reused
- States designed - default, hover, active, disabled, error
- Components built to survive real content, not placeholder text
Responsiveness
- Layout logic defined per breakpoint, not just scaled down
- Touch targets sized for the input method
- Content priority reordered for smaller screens where needed
Scope, area by area
| Area | What we deliver |
|---|---|
| Screen designs | Full visual designs for each key screen and state |
| Component specifications | Every reusable element defined with its states |
| Responsive variants | Layout behaviour defined across mobile, tablet, and desktop |
| Developer handoff | Redlines, spacing, and asset export ready for build |
How it actually runs
Inherit the structure
Start from the validated wireframes and flow, not a blank canvas - visual design applies to a structure that is already agreed.
Establish the visual system
Define type scale, colour palette, and spacing rules before designing individual screens, so decisions are consistent from the first screen.
Design components before screens
Build the reusable pieces first, then assemble screens from them, rather than designing each screen from scratch.
Design states, not just the default
Every interactive element gets its hover, active, disabled, and error states designed - not left for development to improvise.
Review across breakpoints
Check every screen at mobile, tablet, and desktop widths before handoff, not after a developer flags a problem.
Hand off with specification
Deliver redlines and component specs precise enough that development doesn't have to guess at intent.
How this compares
| Component-Based UI Design | Screen-by-Screen Design |
|---|---|
| A button is designed once and reused everywhere | A button gets redesigned slightly differently on each screen |
| Changes propagate from one source | Changes require hunting down every instance |
| Scales cleanly as new screens are added | Inconsistency compounds as new screens are added |
Component-based design takes longer to set up initially in exchange for consistency later.
What we measure this against
- Whether the primary action on each screen is visually unambiguous
- Consistency of component styling across the product
- Contrast ratios against accessibility guidelines
Who needs this
A product with validated structure that now needs a visual layer
Interface design applied on top of wireframes that have already been tested holds up better than visual design done first.
A product where components have drifted inconsistent over time
A component audit and redesign resets the visual system to one source of truth.
Where this applies
- A product moving from validated wireframes into full visual design
- A design system audit where components have drifted inconsistent across a growing product
- A rebrand that needs to apply a new visual identity to an existing interface structure
The most common visual design failure isn't bad taste - it's designing screens in isolation instead of components. A screen-by-screen approach can look fine reviewed one page at a time and still produce an interface where the same action is styled three different ways across the product.
Other services in this area
Design decisions backed by what users actually do, not what stakeholders assume
UX research combining user interviews, usability testing, and behavioural data before any design work starts.
The flow, not just the screens
User experience design focused on task flow, information architecture, and reducing friction end to end.
UI/UX DesignStructure agreed on before a single pixel is styled
Low and mid-fidelity wireframing to align on structure and flow before visual design begins.
Test the interaction before building it
Interactive prototyping for validating flows and interactions before development investment.
UI/UX DesignConsistency that doesn't depend on memory
Design system creation - component libraries, tokens, and documentation for consistent product design at scale.
Common questions
After - visual design applied to an unvalidated structure usually means redoing screens once the structure changes. We sequence structure first, visuals second.
No - visual design following a validated structure and consistent hierarchy strongly improves the odds, but individual taste and context vary enough that we won't promise a specific test outcome we don't control.
Figma is our default for interface design and component specification, since it handles both design and developer handoff well. We can work in whatever tool a team already has established, if there is one.
Redlines, spacing and sizing specs, exportable assets, and component documentation - enough for a developer to build from without needing to guess at intent or ask us for every measurement.
By designing components once and reusing them rather than styling each new screen independently - which is also the case for moving to a full design system once a product reaches that scale.
Only if the confusion is visual rather than structural. If the underlying flow or information architecture is the actual problem, restyling it won't fix that - which is why we check the structure first.
Have validated wireframes ready for visual design?
We'll take the structure you've already agreed and build the interface on top of it, component by component.
Talk to us →