Requirements are feature lists
The team knows what must exist but not how the pieces should work together for users.
08 · Floatger service
UI/UX design
We organise requirements into clear journeys, interfaces, and reusable patterns that help users complete important tasks and give engineering a practical delivery foundation.
The context
When this service becomes valuable.
Make complex products understandable and consistent. The right starting point is a shared understanding of the problem—not a predetermined feature list.
The interface lacks consistency
Different areas use competing patterns, language, and visual rules, increasing cognitive load.
Design and engineering are disconnected
Ideas look polished in isolation but overlook states, constraints, data, and implementation realities.
What the work may include
Connected capabilities, shaped around the engagement.
The exact mix is agreed after understanding your current situation, priorities, and constraints.
01
Product and user context
Understand the audience, tasks, environment, constraints, and business priorities behind the experience.
02
Information and journey design
Structure navigation, content, states, and flows around the decisions users need to make.
03
Interface and interaction design
Create responsive screens and interactions with clear hierarchy, language, and feedback.
04
Design systems and handoff
Define reusable components, usage guidance, responsive behaviour, and implementation context.
Potential outputs
Tangible progress your team can use.
Outputs depend on the scope and stage of the engagement. They are agreed before delivery begins and refined as the work becomes clearer.
- 01Product audits, user journeys, and prioritised flows
- 02Wireframes and interactive prototypes
- 03Responsive interfaces including important empty, loading, error, and permission states
- 04Design tokens, reusable components, rules, and implementation guidance
Planning the engagement
Make the inputs, evidence, and boundaries clear.
Useful delivery starts with the right context and an agreed way to evaluate progress—not an assumption that every possible concern belongs in scope.
What we need to understand
- Product goals, priority users, workflows, and known pain points
- Existing analytics, support themes, research, or stakeholder evidence
- Technical, content, accessibility, brand, and delivery constraints
- Access to representative users and the implementation team where available
How progress can be evaluated
- Priority journeys and states are understandable to the intended users
- Patterns remain consistent across agreed screen sizes and product areas
- Engineering receives implementable states, rules, content, and decision context
Important scope boundary
Research and usability testing depend on access to representative participants. Product design can incorporate agreed accessibility requirements, but a formal accessibility audit or certification requires a separately defined specialist scope.
Delivery path
From context to a practical next stage.
Each stage creates enough clarity for the decisions that follow, while keeping the process proportionate to the work.
Understand
Align user needs, business priorities, product constraints, and evidence.
Structure
Map information, flows, edge cases, and the overall product model.
Design
Develop and review responsive interface patterns and interactions.
Enable
Prepare reusable guidance and stay connected through implementation.
Engagement shape
Start at the point that matches the challenge.
Focused product or UX audit
Identify friction, inconsistency, evidence gaps, and the highest-value design priorities.
Product design phase
Shape journeys, prototypes, responsive interfaces, states, and reusable patterns before or during development.
Design and implementation support
Stay connected with engineering through clarification, review, iteration, and design-system evolution.
Service questions
Useful things to clarify.
Can design happen before the full technical scope is known?+
Yes, but design and technical discovery should inform each other. Early prototypes help clarify requirements while engineering input keeps the proposed experience realistic.
Do you redesign existing products?+
Yes. We can focus on specific high-friction journeys, improve consistency, or develop a broader product and design-system direction.
What is included in design handoff?+
The exact package depends on scope, but it may include flows, responsive screens, interaction notes, component states, content guidance, and ongoing collaboration during implementation.
Can you work with our internal engineering team?+
Yes. We can align on technical constraints, component conventions, review points, and the level of implementation support the team needs.
Do you need direct access to users?+
Not for every starting point, but access to representative users improves the evidence behind important decisions. When access is limited, we make assumptions explicit and define other ways to validate them.
Start a conversation
Let's discuss ui/ux design.
Share the context, current state, and what you need to move forward. We will help identify a sensible starting point.