Product and flow design
Work out what the screen is for and what the user is trying to finish, before deciding what it looks like.
- Task and flow mapping
- Information architecture
- Wireframes and prototypes
- Usability review
UI/UX Design
Design that survives contact with the codebase.
Product design delivered alongside engineering: flows, states, and a component library that maps to the code, so the built interface matches the design without a translation layer.
Inside the delivery
Design the complete task, including the difficult states
Map critical journeys, decision points and accessibility needs with available research. The flow below shows the main delivery stages and the evidence produced at each step.
- 01
User and task discovery
Map critical journeys, decision points and accessibility needs with available research.
Output
Journey maps and experience priorities
- 02
Interaction structure
Prototype navigation, information hierarchy and task flows before refining visual detail.
Output
Wireframes and interactive prototype
- 03
System and states
Define reusable components with loading, empty, error and permission states.
Output
UI system and annotated screen designs
- 04
Validation and handoff
Review representative tasks with users where available and resolve implementation questions with engineers.
Output
Usability findings and design handoff specifications
Controls across the workflow
- Accessible interactions
- Responsive behavior
- Component consistency
- State coverage
Decisions that shape the scope
- Is the deliverable only a set of polished screens?
- No. The useful handover includes interaction rules, responsive behavior, states and reusable components. User testing depth depends on participant access and the questions the design needs to resolve.
- Do you do brand and visual identity work?
- No. This is product and interface design for software being built: flows, screens, states, and design systems. Where brand direction already exists we work within it, and where it does not we would recommend a brand specialist rather than improvising one.
Before you commit
Is this the right engagement?
- What we need from you
- User goals, product flows, brand assets, existing research, technical constraints and access to representative users.
- How you accept the work
- Review representative tasks with users where available and resolve implementation questions with engineers. Acceptance records the tested scope, unresolved issues and the owner's decision.
- Scope & alternatives
- No. The useful handover includes interaction rules, responsive behavior, states and reusable components. User testing depth depends on participant access and the questions the design needs to resolve.
Overview
The states nobody designs are the ones users hit
Most interface problems in business software are not aesthetic. They are the empty state, the error, the partially loaded table, the permission the user does not have, and the screen at 200 rows instead of five. We design the flow and those states together with the engineering team, as components that map to what will actually be built.
- 01Flows, screens, and the states between them
- 02Component libraries that map to code
- 03Accessibility built into the design
- 04Design review inside delivery, not before it
Capabilities
Engineering scope and deliverables
Select the work that addresses your constraint. Responsibilities and acceptance criteria are agreed before delivery.
Interface and states
Specify the whole surface, including the conditions that only appear in production.
- Screen and component design
- Empty, loading, and error states
- Permission and role variations
- Responsive behavior
Design systems
Give the team a shared vocabulary of tokens and components so the interface stays coherent as more people build on it.
- Tokens and foundations
- Component library and variants
- Usage documentation
- Contribution and review process
Accessibility and quality
Treat accessibility as a design requirement with a testable definition rather than as a compliance exercise at the end.
- Contrast and typography checks
- Keyboard and focus paths
- Screen reader labeling
- Design QA against the build
Integrations
Selected for your environment
Tools are chosen around your existing systems, access requirements and operating constraints.
Web and mobile applications
Internal APIs
Business applications
Analytics platforms
CI/CD pipelines
Identity providers
Frequently asked questions
Questions to resolve before starting
01Is the deliverable only a set of polished screens?
Is the deliverable only a set of polished screens?
No. The useful handover includes interaction rules, responsive behavior, states and reusable components. User testing depth depends on participant access and the questions the design needs to resolve.
02Do you do brand and visual identity work?
Do you do brand and visual identity work?
No. This is product and interface design for software being built: flows, screens, states, and design systems. Where brand direction already exists we work within it, and where it does not we would recommend a brand specialist rather than improvising one.
03Can design happen alongside development?
Can design happen alongside development?
That is how we prefer to run it. Design working one increment ahead of the build, reviewing implemented screens as they land, avoids the large up-front specification that stops matching reality after the second sprint.
04We already have a design system. Can you work in it?
We already have a design system. Can you work in it?
Yes, and it is usually cheaper than starting again. The first task is checking whether the system as documented matches the components actually in the codebase, since the two commonly diverge.
05What do you deliver at the end?
What do you deliver at the end?
Flows, screens including their states, a component library with defined variants and tokens, accessibility criteria, and usage documentation. The intent is that your engineers can build new screens without needing us for each one.
06How is accessibility handled?
How is accessibility handled?
As a design requirement with testable criteria: contrast, focus order, keyboard operation, and labeling are decided during design and checked against the build, rather than being audited after release when changes are expensive.
07What should we prepare for the first technical discussion?
What should we prepare for the first technical discussion?
User goals, product flows, brand assets, existing research, technical constraints and access to representative users.
08What evidence is available at handover?
What evidence is available at handover?
The agreed delivery includes usability findings and design handoff specifications. Review representative tasks with users where available and resolve implementation questions with engineers.
09How is the engagement estimated?
How is the engagement estimated?
We review the available inputs before estimating: User goals, product flows, brand assets, existing research, technical constraints and access to representative users. The proposal identifies dependencies, review milestones and excluded work; the scope determines the schedule.
Start a conversation
Discuss your next technical step
Share your current situation and the constraint you need to resolve. We will use the discovery inputs above to define a practical scope for UI/UX Design.