You are preparing to build or rebuild a product and the foundations are not crisp. The team has a vision but no validated strategy. Stakeholders disagree on what the product is or who it serves. The existing product needs structural rework, not surface refinement. The dev team is waiting for direction the brief cannot give.

A defensible foundation for build. Validated user and market understanding. An explicit strategic framework with recorded rationale. Decision principles that govern downstream choices. An information architecture that maps the product's structure. The build can be commissioned and briefed without ambiguity.

• Brief intake and gap surfacing
• Research scoping, expert and user interviews, competitive and analog analysis
• Synthesis and discovery documentation: affinity mapping, proto-personas, insight surfacing
• Identification of the requirements that drive product structure
• Strategic decision-making: alternatives compared, decision recorded, stakeholder review and lock
• Content inventory and information architecture audit
• Taxonomy, classification, navigation, and labelling design

• Discovery synthesis: research findings, proto-personas, insight summary, opportunity definition
• Strategic framework: structural requirements, decision rationale, governing principles, recorded decisions
• Information architecture: content inventory, taxonomy, site map, navigation, labelling reference
• Brief-ready foundation for downstream design and build

You need a brand that holds across surfaces and aligns with what the product and business have to do. Building or rebuilding from scratch. The brand is inconsistent across marketing, product, sales, and document surfaces. The brand has not kept pace with what the business has become. Multiple products or sub-brands and the portfolio structure is unclear. Marketing brand and product UI feel like different brands. About to launch and brand assets need to be ready for go-to-market.

A brand structured as a system. Positioning that addresses the relevant audiences. Verbal and visual identity defined and documented. Coherent expression across product, marketing, and document surfaces. Internal teams and external partners can apply the brand without ambiguity.

• Brand audit where an existing brand is in place
• Positioning: category, audience, differentiation, value proposition, messaging architecture
• Brand portfolio structure where multiple offerings exist
• Verbal identity: voice, tone, language rules, naming, narrative framing, microcopy guidelines
• Visual identity system: logo, colour, typography, imagery, iconography, motion and sound where applicable
• Brand-product alignment: continuity rules between marketing brand and product UI
• Brand guidelines and governance: documented system, ownership rules, evolution rules
• Application across launch surfaces: website, pitch deck, sales materials, product UI key states, document templates

• Brand audit findings where existing brand is in place
• Positioning statement and messaging architecture
• Brand portfolio structure document
• Verbal identity guidelines
• Visual identity system: logo, colour, typography, imagery, iconography, motion and sound where applicable
• Brand-product alignment map
• Brand guidelines document
• Applied brand across priority launch surfaces

Foundations are in place and the product needs to be designed, systematised, and prepared for engineering. You have strategy, information architecture, and brand and need the product designed against them. The existing product needs design-led rework: redesigned screens, systematised components, cleaner handoff. Engineering is waiting on specifications and handoff documentation. Multiple products or surfaces need a coherent design system that scales across teams. Existing design files are inconsistent and need systematisation before scale.

Product design ready to build. Priority flows designed at the right fidelity, validated where required, and supported by a documented design system. Engineering has the specifications, prototypes, and handoff support to implement without ambiguity. Design quality and consistency hold across the product.

• User and task flow design and interaction logic for priority scenarios
• Screen design with full state coverage and information design where the product carries structured data
• In-product microcopy: button labels, tooltips, error messages, empty state copy, onboarding
• Pattern application and new pattern proposals where standard patterns do not fit
• Interactive prototypes and usability testing for priority flows, with design changes verified against findings
• Design system: tokens, components with full state and variant coverage, documentation, versioning, Figma library publication
• Engineering handoff: design specifications, interaction and behaviour documentation, annotated files, accessibility specifications (keyboard navigation, contrast, screen-reader support, alternative text)
• Handoff sessions and ongoing collaboration through implementation

• User and task flow diagrams for priority scenarios
• High-fidelity screen designs across priority surfaces
• State matrix per priority screen
• Information design specification including charts and dashboards where applicable
• In-product microcopy
• Interactive prototypes for priority flows
• Usability testing reports and revised designs
• Design system: tokens, components with full state and variant coverage, documentation, governance, distributed Figma library
• Wireframes for priority screens and flows
• Design specifications including accessibility specifications
• Interaction and behaviour documentation
• Annotated, handoff-ready design files
• Handoff session record and design QA notes during implementation

You are building or extending a product with AI features and they need to be designed for trust, usability, and structural soundness. Introducing AI features into an existing product. Building a new AI-native product. AI features have been prototyped but lack design rigour, user controls, or governance. Regulatory exposure (EU AI Act, NIST AI Risk Management Framework, sector-specific frameworks) requires governance design and product UX that supports compliance. Trust signals are missing or failure modes read as broken product. Multiple AI features need consistent design language across the product.

AI features designed for trust and usability, with a governance framework and product UX patterns aligned with the regulatory context. AI behaviour is legible to users. User agency over AI is preserved. Failure modes are designed for, not assumed away. The product can launch and scale AI features without accumulating trust debt.

• AI capability scoping: where AI fits in the product, what user problems it addresses, what it is deliberately not used for
• AI design patterns for trust and transparency: explainability, source attribution, confidence indication, decision rationale
• AI design patterns for user control and consent: override, undo and redo, opt-in and opt-out, agency levels from suggestion to auto-action
• AI design patterns for failure and uncertainty: hallucination handling in the UX, error recovery, fallback to human review
• AI governance framework: review processes, accountability structures, and the product UX patterns through which governance surfaces (auditability, consent flows, ethics review touch points), aligned with EU AI Act, NIST AI Risk Management Framework, or sector-specific frameworks where relevant
• Systematisation of AI patterns into the design system once stable

• AI capability scope document with rationale and explicit negative scope
• AI design pattern set covering trust and transparency, user control and consent, and failure and uncertainty
• AI governance framework documentation: review processes, accountability structures, and product UX patterns that surface governance

The product is launching or has launched and design decisions need to be grounded in evidence. Beta or post-launch and the team needs to know whether design decisions are working. Existing product needs evidence-based improvement, not opinion-driven iteration. Stakeholders disagree on what to fix and need a shared evidence base. Continuous discovery practice is needed in place of one-off research events. Analytics are instrumented but no one is reading them for design implications.

Design decisions grounded in evidence. Validation findings translate into design changes. Analytics readings translate into design implications, not descriptive reports. Continuous discovery established as ongoing practice. Stakeholders share a single evidence base for product decisions.

• Validation strategy: what to validate, by whom, at what cadence, with design metrics that map to business outcomes
• Continuous discovery cadence: regular customer touchpoints and ongoing assumption testing
• Qualitative validation: usability testing on prototypes and live product, customer interviews, field research where context requires it
• Quantitative analytics interpretation: reading behavioural data for design implications
• Behavioural and attitudinal triangulation: combining what users do with what users say
• Findings synthesis: translating validation findings into design changes, capability decisions, or backlog priorities
• Benchmarking with standardised scales (System Usability Scale, SUPR-Q) for measurable baselines across releases

• Validation strategy with metric definitions and cadence
• Qualitative validation reports: usability testing, customer interviews, field research
• Quantitative analytics interpretation with design implications drawn from behavioural data
• Validation findings reports with prioritised design implications
• Benchmarking reports with baseline and trend metrics