01/
Evidence versus assumption
What is known from research, analytics, or support themes, separated from what the team is assuming.
UI/UX Product Design
Product flows and interfaces shaped around real user decisions.
Start with the design question
Decide whether the design question needs new
evidence at all
Not every product decision needs design exploration. We start by establishing what's already known and what genuinely needs deciding.
TIER01
Assumption is enough
TIER02
Visual refresh only
TIER03
Bounded flow redesign
TIER04
Evidence-led product design
Evidence and users
Separate evidence, assumptions,
and visual preference
Design decisions should trace back to a defined source, not to what looks appealing.
02/
Users, roles, and tasks
Who does what, in what context, and what "done" looks like for them.
03/
Information and content
What data and content the interface actually needs to show, including the difficult and edge cases.
04/
Constraints and existing systems
Platform, accessibility, and technical constraints that shape what is actually buildable.
Design boundary
Design complete workflows, decisions,
states, and recovery
Loading, empty, error, permission, and recovery states are part of the design, not left to engineering to improvise.
(001)
Design the complete workflow, including the states nobody wants to draw
Loading, empty, error, permission, and recovery states are part of the design, not left to engineering to improvise.
(002)
The right artefact for the question
Wireframes, prototypes, or a design system are chosen for what they need to prove, not applied as a default package.
(003)
Accessibility is a direction, not an afterthought
Requirements and testing are named explicitly rather than implied by "clean design."
(004)
Design stays connected to implementation
Feasibility, data, and platform behavior inform design decisions before they are presented as final.
Technology decisions
Design systems &
prototyping tools
The stack follows the requirement, not the other way round. These are the categories this engagement typically has to decide.
01
Figma Design System
02
Design Tokens
03
Storybook
04
WCAG 2.1 AA Standards
05
Interactive Prototyping
06
Tailwind / CSS Modules Handoff
Possible scope
Use wireframes to decide structure
before visual polish
The exact artefacts depend on the product question. None of the following should be assumed automatically.
Existing evidence and assumption auditUser, role, and task definitionInformation architecture and content reviewConstraint and platform review
Wireframes for structural decisionsInteractive prototypes for workflow or interaction questionsVisual direction tied to actual use, not trendDesign-system work where reuse and governance justify it
Usability evaluation against real tasksAccessibility review against a defined standardStakeholder and engineering feasibility reviewIteration based on findings
Source files and assets as agreedSpecification of states, content, and interactionEngineering feasibility and open-questions recordDesign-QA responsibility during implementation
Design decisions
Give the interface a visual hierarchy tied
to actual use
Every design decision trades something specific for something else. The useful choice is the one whose reason is understood.
01
How real does it need to look to answer the question?
Fidelity should match what is being tested, not the team's comfort with polish.
02
Design something new or reuse what exists?
A new pattern is justified when the existing system genuinely cannot serve the need, not by preference.
03
Does design need to finish before build starts?
Some workflows benefit from design and engineering working the same problem in parallel, with tighter feedback.
04
Full system or just what this project needs?
A full design system is a governance commitment; a scoped component set may serve one project better.
Inspectable outputs
Leave outputs, access, ownership,
and limitations explicit
Deliverables should make the design reasoning and its handoff visible and usable.
01/
Evidence and assumption record
What is known, what is assumed, and the decision this design work needs to inform.
02/
Workflow and state design
Information architecture, flows, and interface states including failure and recovery paths.
03/
Evaluation results
Usability and accessibility findings against real tasks, not just internal review.
04/
Engineering handoff
Specifications, assets, and open questions in a form implementation can actually use.
Delivery and engagement
Bound the first design scope around
the next decision
The starting engagement should establish what's known before design work is scoped.
01
BOUNDED DISCOVERY
Evidence and research review
A bounded stage to establish what is known before design work is scoped.
02
FIXED-SCOPE MILESTONE
Defined design engagement
A project-shaped stage to design one workflow, product area, or system.
03
STAGED RELEASES
Design alongside build
Design and engineering run together for tighter feedback on feasibility.
04
CONTINUOUS CADENCE
Ongoing design responsibility
Continued design ownership once the product has an active roadmap.
Fit and routing
Choose UI/UX when product behavior and design decisions
define the work
UI/UX Product Design is the right starting point for evidence-led design decisions. A different service may own the wider need.
01/ ALTERNATIVE
Custom Software Development
Choose this when implementation, not design decisions, is the primary need.
02/ ALTERNATIVE
MVP Development
Choose this when the next useful step is testing a first release, not design exploration.
03/ ALTERNATIVE
Product Modernisation & Improvement
Choose this when design is one part of a broader existing-product transition.
04/ ALTERNATIVE
Ongoing Product Engineering
Choose this when design responsibility needs to continue alongside an active roadmap.
Frequently Asked Questions
UI/UX Product Design questions,
answered clearly.
Technical delivery and architecture details. Key decisions regarding code quality, integrations, and handoff rituals.
No. Product design can include users, tasks, information architecture, workflows, states, interaction, visual hierarchy, prototypes, evaluation, accessibility direction, design systems, and engineering handoff according to scope.