Design & Product Strategy
Discovery, UX/UI and product direction that de-risk the build.
The most expensive mistakes happen before a line of code is written — building the wrong thing, for the wrong audience, on the wrong technical foundations. A little discovery and a clear product direction up front saves a significant amount of money later.
We run structured discovery to understand who your users are and what they actually need, then translate that into interaction design, high-fidelity UI and a prototype your stakeholders can react to before engineering begins. Because the same studio then builds the product, there is no handover gap and no designs that look great in Figma but prove impossible to implement on your timeline.
At the strategic level we help you prioritise a roadmap, choose the right technical approach, and — if you are bringing on an engineering team — give you a plan grounded in what is actually shippable on your budget. The output is never a deck that gathers dust; it is a prioritised direction the whole team can act on.
- Confidence you are building the right thing before the engineering spend begins
- A design hand-off that engineers can build directly, without interpretation gaps
- A roadmap the whole team — engineering, product and business — can rally behind
Capabilities
Product discovery & UX research
User interviews, usability testing, jobs-to-be-done mapping and competitive analysis to validate what to build before you spend on building it.
UX design & information architecture
User flows, wireframes, navigation structures and interaction models that match how your users think — not how the database is organised.
UI design & design systems
High-fidelity visual design, component libraries and a consistent design system that scales as the product grows and speeds up every future sprint.
Prototyping & validation
Clickable prototypes in Figma — real enough to test with users and share with investors — before a single line of production code is written.
Product roadmapping & prioritisation
A sequenced, effort-weighted roadmap that balances user needs, business value and technical constraints — with the trade-offs spelled out, not glossed over.
Technical strategy & advisory
Architecture recommendations, build-vs-buy decisions, technology selection and a pragmatic plan that a real engineering team can deliver on your actual budget.
Positioning & go-to-market direction
Audience definition, value proposition sharpening and a realistic path to your first — or next — meaningful cohort of users.
Deliverables
- A research report and synthesised user insights in plain language
- UX wireframes, high-fidelity UI designs and a clickable prototype
- A design system or component library ready for engineering hand-off
- A written product roadmap with priorities, sequencing and open trade-offs
- A technical strategy document and a follow-up session to pressure-test it
Best suited for
- Founders who want to validate an idea and de-risk a build before committing budget
- Teams facing a significant product redesign or a new platform from scratch
- Businesses that have outgrown their current product and need a clear next direction
- Anyone who wants a second opinion on technical direction from people who will also build it
What we build with
Product strategy & design
Product strategy and design is the discipline of reducing risk before code is written. It answers the question that engineering cannot answer on its own: are we building the right thing, for the right user, in the right sequence?
Discovery surfaces latent user needs and business constraints that are invisible in a requirements document. UX design translates those needs into interaction models that are testable in days, not months. UI design and design systems ensure that what ships is accessible, coherent, and maintainable at scale. Together, they compress the feedback loop between idea and validated learning.
Design is not a handoff phase that precedes engineering. In our studio, designers and engineers work in the same sprint, on the same backlog, referencing the same component library. The handoff gap — where intent is lost between a static mockup and a living product — does not exist because the artefacts are built to be implemented, not admired.
How we move from problem to validated design
The stages below are the default sequence for a new product or a significant feature. On shorter initiatives we compress or skip stages where evidence already exists — we do not run research for its own sake.
- Stakeholder alignment sessions: goals, constraints, non-goals, and existing knowledge audit
- User interviews and contextual inquiry — jobs-to-be-done framing, not feature requests
- Competitive UX review: interaction patterns worth adopting or explicitly avoiding
- Synthesis: affinity mapping, opportunity statements, and a prioritised problem list
- Persona definition grounded in interview data, not demographic templates
- User journey mapping for the two or three flows that drive core value
- Opportunity ranking using impact-confidence-effort scoring
- Success metric definition: task-completion rate, time-to-first-value, SUS score baseline
- Information architecture and navigation structure in wireframe form
- Component-level design in Figma, referencing or extending the design system
- Interactive prototype for usability testing — linked Figma frames or a coded prototype
- Accessibility review against WCAG 2.1 AA from the first wireframe, not as a final audit
- Usability testing with target users and documented findings
- Design token export — spacing, colour, typography, shadow, and radius as named variables consumed by code
- Component annotation in Figma: states, variants, interaction notes, and accessibility annotations
- Storybook story authoring alongside component development for visual regression baseline
- Accessibility audit with axe or Lighthouse before the feature ships to production
- SUS (System Usability Scale) survey cadence on key flows
- Task-completion rate and time-on-task measurement via session analytics
- Heatmap and session recording review for unintended interaction patterns
- Synthesis into prioritised design backlog items for the next iteration
Discovery & research
Establish a shared, evidence-based understanding of the user, the context, and the constraints before any design decisions are made. Outputs replace assumptions with documented findings that the whole team can reference.
Define & prioritise
Translate research findings into a design brief that specifies scope, user personas, key user journeys, and measurable success criteria. This stage prevents scope creep during design and gives engineering a stable brief to estimate against.
Design & prototype
Move from concept to interactive prototype as quickly as possible, using fidelity as a tool rather than a goal. Low-fidelity wireframes validate structure and flow; high-fidelity prototypes validate visual design, micro-interactions, and accessibility at the component level.
Handoff & validate
Prepare design artefacts for implementation in a way that preserves intent and reduces back-and-forth. Design tokens, annotated specs, and Storybook stories replace the traditional static redline document.
Measure & iterate
Validate design decisions against real user behaviour in production. Qualitative feedback and quantitative metrics feed back into the next discovery cycle, closing the loop between design intent and user experience reality.
Design principles we hold firm on
These principles govern how we approach every design decision, from system architecture to the label on a button.
Design tokens, not pixel pushing
A design system built on named tokens — colour.brand.primary, spacing.md, radius.card — means that a single change propagates consistently across every surface without hunting through individual component styles. Pixel-perfect mockups that hardcode values in each frame create maintenance debt that compounds with every new screen. We invest in the token layer early because it is the cheapest time to do so.
Accessibility (WCAG 2.1 AA) from the first wireframe
Accessibility retrofitted at the end of a project is expensive, incomplete, and usually shipping a worse experience for everyone. Colour contrast, touch-target size, focus order, and semantic HTML structure are design decisions, not engineering afterthoughts. We check contrast ratios in Figma before a component reaches code, and we run automated accessibility linting (axe, eslint-plugin-jsx-a11y) in CI so that regressions are caught before they reach production.
Prototype to de-risk before building
A two-day Figma prototype that reveals a fundamental flow problem saves weeks of engineering time. We set an explicit prototype budget for every significant feature — the cheapest possible artefact that can answer the highest-risk assumption — and test it with real users before writing production code. The prototype is disposable; the learning it produces is not.
Design and engineering in one studio — no handoff gap
The traditional handoff model — designers finish, throw a static file over the wall, and move on — loses context at exactly the moment it is most needed. Our designers sit in the same planning sessions as engineers, review pull requests for visual regressions, and update the design system when the implementation diverges from the spec. The source of truth for what ships is the running application, not the Figma file.
Measure with real metrics, not opinions
Design reviews grounded in aesthetic preference rather than user evidence produce beautiful products that nobody uses. We instrument key flows before launch — task-completion rate, time-to-first-value, error rate at critical steps — and review the data in every iteration cycle. A SUS score is a conversation starter, not a vanity metric; it tells us which flows to investigate next, not whether the product looks good.
Tools we use and why
We favour tools that reduce the distance between design intent and shipped product, and that produce artefacts engineers can consume directly rather than interpret.
Research & discovery
- User interview frameworks (JTBD, contextual inquiry)Jobs-to-be-done framing surfaces the underlying motivation behind a request rather than accepting the stated feature at face value. Contextual inquiry — watching users work in their actual environment — reveals workarounds and pain points that interview questions alone miss. Both techniques produce findings that are harder to dismiss in prioritisation conversations than opinion-based user stories.
- Miro / FigJamCollaborative whiteboard tools that let the whole team — designers, engineers, product owners — participate in affinity mapping, journey mapping, and prioritisation exercises in real time. The output is a shared artefact, not a designer-owned document, which improves buy-in and reduces re-explanation in planning sessions.
- Maze / LookbackUnmoderated usability testing at scale (Maze) and moderated remote session recording (Lookback) produce quantitative task-completion data alongside qualitative session observations. Running testing asynchronously compresses the research cycle without sacrificing the depth of behavioural data.
Design & prototyping
- FigmaThe industry standard for collaborative UI design with the deepest component and variant system of any design tool currently available. Auto-layout, component properties, and the Variables API (design tokens) mean that a Figma library can closely mirror a coded component library, reducing translation loss at handoff. The Dev Mode inspection view is the closest thing to a redline document that actually stays up to date.
- Design system (Figma + code)A design system maintained in parallel in Figma and code — with the same token names, the same component API, and the same accessibility bar — is the single most effective investment for product teams that ship more than one surface. It eliminates category errors where the Figma component and the React component behave differently, and it makes accessibility improvements systemic rather than per-screen.
- Radix UI / Headless UI primitivesAccessible, unstyled component primitives that handle keyboard interaction, ARIA attributes, and focus management correctly — problems that are difficult to implement from scratch and easy to get subtly wrong. Building the design system on top of accessible primitives means that WCAG 2.1 AA compliance is the floor, not an aspirational target.
Handoff & quality assurance
- Style DictionaryTransforms a single source-of-truth token file into platform-specific outputs — CSS custom properties, TypeScript constants, iOS Swift, Android XML — so that the same token values are consumed consistently across every platform without manual translation. Changes to the token file propagate everywhere in a single build step.
- StorybookAn isolated component development environment that serves as both living documentation and visual regression baseline. Writing a Storybook story for every design-system component forces explicit definition of all states and variants, surfaces edge cases during development rather than in production, and gives QA a reproducible environment to verify design fidelity.
- axe-core / eslint-plugin-jsx-a11yAutomated accessibility linting that runs in CI and catches a significant proportion of WCAG failures before they ship — colour contrast violations, missing alt text, incorrect ARIA roles, unlabelled form controls. Automated tooling does not replace manual assistive-technology testing, but it eliminates the low-hanging failures that consume QA time and create audit findings.
Anti-patterns we actively prevent
Each of these failure modes is common, recognisable, and avoidable with the right process decisions made early.
Design-then-throw-over-the-wall handoff
Designers produce static deliverables, hand them to engineering, and move on to the next project. Engineers implement their interpretation of the mockup, and by the time anyone checks the result, the designer has no context and the engineer has no feedback loop. The shipped product diverges from the design intent in ways that only accumulate across features.
Designers and engineers share a sprint. Designers review pull requests for visual regressions before merge, update the Figma source when the implementation improves on the spec, and attend sprint demos. Design tokens and Storybook stories are the contract between the disciplines, not a PDF of annotated screenshots.
Inaccessible by default
Accessibility is treated as a compliance checkbox run at the end of a project, after the interaction model, component library, and colour palette are locked. At that point, the cost of fixing contrast failures, missing focus states, or incorrect heading hierarchy is disproportionately high relative to addressing them at design time.
Accessibility is a design constraint, not a post-build audit item. Colour contrast is checked in Figma before a component reaches code. Focus order is specified in the interaction annotation. ARIA roles are part of the component handoff spec. Automated linting runs in CI. Manual screen-reader testing is part of the acceptance criteria for any flow that changes keyboard or focus behaviour.
Vanity metrics as design success criteria
Design outcomes are judged by NPS scores, page views, or time-on-site without connecting those numbers to the behaviours the design was intended to influence. A high NPS for a confusing onboarding flow means users are polite, not that the flow works. Vanity metrics produce optimistic reports and no actionable guidance for the next iteration.
Define behavioural metrics before design starts: task-completion rate for the target flow, time-to-first-value for onboarding, error rate at critical decision points. Measure SUS at a per-flow level, not as a product-wide number. Use session recordings and usability tests to explain the numbers, not to replace them. Every design iteration should be able to state the hypothesis it is testing and the metric that will confirm or refute it.
Go deeper
Design & Product Strategycovers a lot of ground. Here are the specific things we're most often asked to build.
Common questions
Can design roll straight into engineering with the same team?
Yes, and it usually does. Because the same studio plans, designs and builds, there is no handover gap — the roadmap is scoped to what we can actually ship together.
We already have wireframes — do we still need discovery?
It depends. If the user research is solid and the wireframes reflect real user needs, we can jump straight to high-fidelity UI. If the wireframes were built on assumptions, a short discovery sprint before we design in detail will save significant rework downstream.
Other services
Have something in mind?
Tell us what you're building or stuck on. The first consultation is free — no obligation, no hard sell.