Skip to main content

Product design

Design every state the task can enter.

Werkon turns observed user work into content, structure, interaction, and system behavior that a delivery team can build and verify. Default, loading, empty, error, denied, interrupted, success, support, and recovery states belong to the design, not a late implementation guess.

Design contract

Connect user evidence to content, interaction, and system behavior.

A design boundary includes the service before and after the interface. The contract makes research, terminology, records, rules, states, devices, accessibility, engineering constraints, measures, and operating ownership visible in one decision trail.

Inputs

Users and whole service
Observed tasks, triggers, goals, language, context, channels, intermediaries, current behavior, support, offline steps, barriers, failures, workarounds, accessibility needs, excluded groups, analytics, service records, and unresolved research questions.
Content, records, and rules
Terminology, content sources and owners, information hierarchy, forms and evidence, source records, identities, roles, permissions, calculations, validations, state transitions, approvals, audit, retention, correction, and alternative formats.
Surfaces and conditions
Web, mobile, internal tools, messages, documents and support touchpoints, target viewports and devices, keyboard and pointer, assistive technology, text scaling, motion and color preferences, network conditions, interruptions, and physical environment.
System and delivery constraints
Current products, design systems and content patterns, APIs and data limits, security and privacy needs, technical architecture, supported platforms, performance budgets, localization, release sequence, instrumentation, team capability, timeline, cost, and ownership.

Outputs

Task and service model
A traceable view of users, goals, stages, channels, content, roles, records, decisions, rules, handoffs, barriers, support, exceptions, outcomes, evidence, owners, and the exact product boundary under design.
Content and interaction architecture
Terminology, hierarchy, navigation, routes or screens, flows, actions, forms, messages, status, responsive behavior, accessibility intent, pattern choices, and every material state from entry through completion, support, and recovery.
Decision-shaped prototypes
Artifacts at the lowest credible fidelity for the research or delivery question, paired with representative tasks, participants, conditions, observations, accessibility limits, changed decisions, unresolved risks, and a clear statement of what was not proven.
Build and verification contract
Accepted content, assets, tokens, components, behaviors, states, breakpoints, keyboard and focus rules, semantics or platform accessibility, data and permission boundaries, analytics, test criteria, ownership, change history, and design review points in working software.

Design path

Use each artifact to answer a named question.

Fidelity follows uncertainty. A sketch can expose structure, realistic content can expose comprehension, and working software can expose browser, device, data, permission, and performance behavior. Each is evaluated for the decision it can honestly support.

  1. 01

    Frame the design decision

    Record the user task, whole-service boundary, current evidence, desired outcome, constraints, riskiest assumptions, accessibility needs, owners, and what the next artifact must help the team decide.

  2. 02

    Model content and states

    Define terms, information, records, roles, rules, valid states, transitions, errors, denial, interruption, support, recovery, responsive behavior, and the source or owner behind every visible choice.

  3. 03

    Prototype the risk

    Choose representative content and the lowest credible fidelity, reuse established patterns where they fit, expose incomplete and failed paths, and keep the prototype's technical and accessibility limits explicit.

  4. 04

    Evaluate inclusively

    Use suitable research, expert review, manual accessibility checks, automated support, device or browser tests, and technical spikes with representative users, tasks, data, assistive technology, conditions, and delivery constraints.

  5. 05

    Contract, build, and observe

    Agree behavior and acceptance criteria with engineering and content, review working software rather than screenshots alone, record deviations, release a complete slice, observe real use and support, and feed evidence back into the design system and product.

Pattern decision

Create a component only after simpler changes fail.

Every new interaction becomes a responsibility for content, design, code, accessibility, testing, documentation, versioning, and support. The product should earn that continuing cost.

01The interface reflects avoidable complexity

Change content or service

Clarify language, remove a question, combine evidence, change a policy, resolve ownership, reduce a handoff, or offer support before creating an interaction to disguise the underlying problem.

Evidence: Observed barrier, source content or process, accountable owner, proposed change, legal and operational review, representative comprehension or task evidence, downstream effect, and retained exception path.

02A known behavior fits the task

Reuse an established pattern

Adopt an existing platform or design-system pattern when its purpose, semantics, interaction, content assumptions, states, accessibility behavior, device support, and maintenance model match the need.

Evidence: Pattern source and version, fit analysis, supported states, realistic content proof, keyboard and assistive-technology behavior, responsive test, owner, and upgrade path.

03The core behavior fits with a bounded gap

Adapt or extend a pattern

Change an existing pattern only where the task requires a clear addition and the team can preserve familiar behavior, semantics, accessibility, documentation, tests, and compatibility.

Evidence: Exact gap, user and system evidence, change boundary, content and state matrix, accessibility review, component API, tests, migration impact, design-system owner, and upstream contribution decision.

04No existing behavior supports the task

Create a new pattern

Design a new interaction when the need is recurring and important, alternatives have been tested, and an accountable team can own its complete states, accessibility, implementation, evidence, documentation, and lifecycle.

Evidence: Repeated task evidence, alternatives and failures, interaction model, content and state contract, inclusive research, working-code proof, platform and device tests, ownership, versioning, adoption, and retirement plan.

Design controls

Keep the design file from becoming a false source of truth.

The real product is the content and behavior people receive. Design artifacts support that product only when their evidence, limits, implemented state, and ownership remain visible.

Every decision traces to evidence
Link needs, content, flows, patterns, states, and priorities to observed behavior, service records, policy, technical facts, accessibility needs, or explicit assumptions. Record contradictions, confidence, exclusions, owner, and review date.
Every material state is designed
Include initial, loading, empty, partial, invalid, error, denied, expired, interrupted, offline, conflict, destructive, success, undo, correction, support, appeal, and recovery states where the task can enter them.
Accessibility uses several forms of evidence
Combine standards-based criteria, semantic or platform inspection, keyboard and focus review, zoom and reflow, contrast and motion checks, assistive-technology use, realistic content, and research with disabled people appropriate to the product and claim.
Working behavior closes the loop
Review implementation across target states and conditions, keep accepted deviations and fixes visible, connect design-system releases to product code, instrument agreed questions, observe support and field evidence, and retire stale artifacts.

Engagement fit

Use product design when a real task must become a complete, testable behavior contract.

Good reason to begin

  • A product or service needs clearer content, structure, flows, states, responsive behavior, accessibility, pattern decisions, or design-to-engineering agreement around a known user task.
  • Users and service providers, current evidence, content owners, policy and rule owners, representative data, designers, engineers, accessibility context, support, and product decision makers can participate.
  • The team can prototype the riskiest decision, test realistic content and failed states, and review implementation in working software before treating the design as accepted.
  • The client can own research, content, design source, design system, product decisions, implemented components, accessibility evidence, analytics, support learning, change, and retirement.

Resolve before beginning

  • The request is only visual styling, a predetermined feature list, a copy of another product, or a fixed prototype with no authority to change content, flow, rules, states, or technical behavior.
  • There is no user or service evidence, no lawful research route, no product owner, and no access to content, policy, record, rule, support, or engineering owners who can resolve design decisions.
  • The proposed experience depends on deceptive choices, hidden consequences, inaccessible custom controls, fabricated urgency, silent state changes, or transferring failure and support work outside the measured journey.
  • No team can maintain content, patterns, components, documentation, accessibility, research, product metrics, support feedback, platform changes, and design-to-code parity after delivery.

Source basis

Sources behind the control model.

  • 01

    Government Digital Service

    Make the service simple to use

    The GOV.UK Service Standard asks teams to help users complete the thing they need with minimal help, test frequently with actual and potential users, include online and offline touchpoints, and cover devices that reflect user behavior.

  • 02

    World Wide Web Consortium

    Web Content Accessibility Guidelines 2.2

    The current W3C Recommendation defines technology-neutral, testable criteria across perceivable, operable, understandable, and robust web content and notes that conformance does not address every user need.

[ WORKFLOW / SYSTEMS AUDIT ]
THE FIRST ENGAGEMENT

Start with one real workflow

A Systems Audit is the usual starting point. If the opportunity is already clear, we can move directly into a focused build.

Show Us the WorkflowStart with the free automation readiness checklist

OBSERVEQUANTIFYDECIDEBUILD

Continue with the work

Choose the next useful path.

Stay with the operating question. The technology can wait until the work is clear.

01

Explore software development

Place product design inside the wider product, application, web, mobile, modernization, integration, quality, and support responsibility map.

Open path02

Develop a digital product

Connect design decisions to the wider user need, operating outcome, assumptions, release evidence, investment decision, and product ownership.

Open path03

Build a dependable web product

Carry the behavior contract into semantic content, responsive interaction, server authority, performance, browser verification, and web operation.

Open path04

Develop a mobile application

Carry the behavior contract into platform conventions, permissions, lifecycle state, accessibility, synchronization, signed distribution, and device support.

Open path