Skip to main content

Hire prototyping experts

A convincing prototype can prove the wrong thing.

Prototyping experts help teams resolve a specific product or technical uncertainty with the fidelity needed to test it. Werkon would assess how a person frames assumptions, uses realistic conditions, collaborates with research and hands off evidence. The decision owner determines what the result supports; stakeholder approval or a working demo does not validate the whole product or authorize production use.

Responsibility contract

Keep research findings, product choices, specialist acceptance, and production release with named owners.

A prototyping expert can make uncertainty tangible and cheap to test. They cannot validate their own preferred idea, turn a participant comment into a finding, approve specialist risk or carry experimental shortcuts silently into production. Agree the evidence and disposal boundary before choosing a tool.

01

Client decision and professional authority

Named client owners decide why the experiment exists, which evidence counts and whether anything proceeds.

  • Product service policy or business owners define the decision, intended outcomes, constraints, options, non-goals, value, priority, acceptable uncertainty and authority to discard, iterate, build, pause or stop.
  • User researchers own research questions, recruitment, consent, method, observation analysis and findings; design content engineering architecture data accessibility security privacy legal quality operations and support owners define and accept evidence and risks in their domains.
  • Named technical, professional, acceptance and release owners decide what may be reused, what must be rebuilt, whether residual uncertainty is acceptable and whether anything can enter a live system. Prototype completion does not transfer those decisions to its maker.
02

Prototyping expert contribution

The expert creates and changes the smallest artifact that can expose the assumption. Expected media and technical depth vary by question.

  • Turn a disputed assumption into an explicit question, scenario, evidence threshold and prototype boundary; choose paper, storyboard, content, service enactment, clickable interface, coded behavior, data simulation or technical spike according to what must be learned.
  • Build enough journey, state, content, interaction, access, timing, data, integration and failure realism to answer the question; label simulation and omission; protect access and information; keep alternatives cheap to change and experimental shortcuts visible.
  • Prepare reliable research and technical test conditions, iterate from observed evidence, preserve versions and limitations, discard failed directions, explain what the prototype cannot prove, and translate accepted learning into a production handoff or an explicit stop record.
03

Shared prototype evidence operating model

Learning is multidisciplinary work, not a demo judged by the loudest observer.

  • Researchers, designers, content specialists, engineers, architects, analysts and domain owners shape questions and test conditions together; participants provide observed behavior and feedback; accountable professionals interpret evidence inside their methods.
  • Product and service owners compare findings, technical evidence, constraints, cost and risk against the pre-agreed threshold; security privacy accessibility quality operations and support owners prevent experimental convenience from becoming hidden production exposure.
  • The team records observations, findings, interpretations, conflicts, limitations, discarded options and decisions separately; hiring owners confirm the exact prototype range, collaboration, access, engagement terms and current availability; accountable people decide whether to proceed.

Capability evidence

Assess one risky assumption across fidelity, behavior, feasibility, and evidence.

A showreel rewards convincing artifacts. A useful assessment rewards the smallest artifact that changes a real decision. Provide incomplete evidence and constraints, then see whether the person narrows the question before making anything.

01

Decision question, assumption, option set, and fidelity

Provide a favored solution, a vague request to validate it, mixed evidence, several possible uncertainties, limited time and a stakeholder asking for a high-fidelity demo. Ask what should be prototyped first and why.

Confirm: The person identifies the decision and owner; distinguishes problem evidence, proposed solution, hypothesis, assumption, constraint and unknown; ranks uncertainty by consequence, evidence gap, cost and reversibility; states what result would support change or reject the direction; keeps materially different options including no build; chooses the lowest fidelity capable of producing credible evidence; explains when a sketch, storyboard, role-play, content artifact, clickable flow, coded interaction, simulation, technical spike or production-shaped slice is required; bounds scenario, audience, states, data and environment; marks omissions and false realism; estimates learning cost rather than presentation value; and refuses polish that cannot change the decision.

02

Whole journey, content, interaction, inclusion, and failure behavior

Provide a cross-channel task with several user groups, support staff, difficult content, permission differences, narrow and zoomed views, interrupted sessions, slow responses, error paths and an inaccessible preferred prototyping tool. Ask for one testable journey.

Confirm: The person identifies which end-to-end steps and channels matter to the question; includes setup, entry, orientation, content, state, actions, feedback, wait, cancellation, error, recovery, completion, support and return where relevant; uses realistic language and content length; represents permissions and consequences rather than only screens; includes disabled people, low digital confidence, language, device, connectivity and assisted paths with research owners; chooses media participants can perceive and operate; distinguishes conceptual inclusion evidence from production accessibility conformance; uses established patterns when their assumptions fit; prototypes alternatives rather than cosmetic variants; exposes dead ends and operational seams; and keeps participant safety, consent and dignity above prototype convenience.

03

Technical feasibility, data, integration, security, privacy, and operations

Provide a convincing interface backed by fake responses, a risky external integration, sensitive information, uncertain identity and authorization, latency and scale questions, an operational handoff and pressure to reuse the prototype code. Ask what technical evidence is missing.

Confirm: The person separates visual behavior, simulated behavior, contract evidence and production behavior; identifies data shape, source authority, freshness, identity, permissions, state transitions, integration protocols, error semantics, timing, concurrency, performance, observability, support and recovery that affect the decision; pairs with engineers and specialists on focused spikes or walking skeletons; uses synthetic or approved minimal data; protects prototype access; excludes production credentials and secrets; labels mocked services and bypassed controls; tests boundaries and failure conditions instead of only a happy response; records environment and versions; distinguishes local feasibility from system viability and operability; subjects any candidate reusable code to normal architecture, secure-development, accessibility, quality and release gates; and assumes throwaway code will be thrown away unless accountable owners accept a deliberate rebuild path.

04

Research readiness, observation, iteration, decision, and handoff

Provide a prototype that works on its maker's laptop, unclear research objectives, unavailable participants, leading tasks, stakeholder observers, conflicting session notes, a successful demo, a rejected concept and a team ready to build. Ask what evidence can be carried forward.

Confirm: The person aligns the artifact to research questions and tasks without leading toward the preferred answer; checks the participant environment, access needs, devices, browsers, connectivity, seed state and reset path; rehearses the session; keeps the prototype stable enough to test and easy enough to change; distinguishes observation, participant statement, researcher finding, technical result, team interpretation and product decision; records versions and exposure conditions; avoids counting preference or task completion without context as validation; shows conflicting and disconfirming evidence; changes or discards the artifact promptly; maps each conclusion to its source and limitation; identifies what remains unknown; preserves only useful learning and assets; specifies what production teams must redesign rebuild test secure operate and accept; and demonstrates that another person can repeat the test or explain why the direction stopped.

Assessment sequence

Take one risky assumption from vague confidence to an owned build-or-discard decision.

Prototyping becomes screenable when the question, artifact, observation, limitation and decision remain linked. Start with the assumption that would make the proposed direction worthless or unsafe if false.

  1. 01

    Name the blocked decision

    Record the problem evidence, proposed options, riskiest assumption, consequence if wrong, decision owner, professional owners, current uncertainty, threshold, constraints, participants and the result that would discard or change the idea.

  2. 02

    Choose the minimum honest fidelity

    Select the prototype form and boundary from the question; identify required journey content interaction access data integration timing and failure realism; mark simulated omitted and unsafe conditions; define access, environment, version and disposal controls.

  3. 03

    Build alternatives with the team

    Create materially different paths cheaply; pair with research design content engineering architecture data security privacy accessibility operations and support owners where their evidence affects the question; keep shortcuts explicit and production systems untouched.

  4. 04

    Run the test and preserve limits

    Rehearse realistic scenarios, meet participant and environment needs, observe behavior and technical boundaries, separate evidence types, record failures and conflicts, compare results with the threshold, and iterate only when the next version can answer a sharper question.

  5. 05

    Discard, iterate, or hand off

    Let the accountable owner stop, change or continue; archive the question, versions, observations, findings, technical evidence, limits and rationale; identify what cannot be reused; then let a receiving team repeat the test or rebuild the accepted behavior through normal production gates.

Evidence loops

Keep every prototype attached to one uncertainty and one decision threshold.

Prototype programs drift when artifacts accumulate, fidelity rises by default, research asks for preference, technical spikes ignore the service or successful demos become commitments. These loops keep learning honest.

  1. 01

    Question, assumption, and fidelity loop

    Can the team explain why this artifact is the cheapest credible way to unblock the decision?

    Working evidence: Problem and current source, decision owner, option set, risky assumption, consequence, evidence gap, threshold, participant or technical witness, prototype form, fidelity rationale, in-scope and excluded condition, estimated learning cost, expiry and discard trigger.

  2. 02

    Scenario, behavior, and inclusion loop

    Does the prototype include the real conditions that could change the answer, not just the presentable path?

    Working evidence: Person and access need, task, channel, starting state, content, permission, action, feedback, wait, error, recovery, support, completion, device, viewport, input method, connectivity, assisted path, simulated element, pattern source, observation condition and excluded population.

  3. 03

    Boundary, feasibility, and risk loop

    Can technical evidence distinguish a plausible interface from an operable system?

    Working evidence: Data source and shape, identity, authorization, state transition, integration contract, mock or live boundary, latency, volume, concurrency, failure, recovery, privacy, security, accessibility, quality, operations and support owner, environment, artifact version, spike result, residual uncertainty and production-rebuild requirement.

  4. 04

    Observation, limitation, and decision loop

    Can every claimed learning be traced to evidence that is strong enough for the decision?

    Working evidence: Research question, task, participant and condition, prototype version, observed behavior, statement, technical result, finding owner, interpretation, conflict, limitation, threshold comparison, rejected option, decision, rationale, next uncertainty, retained asset, disposal record and receiving owner.

Continuity controls

Recover without one maker, hidden mock, or prototype mistaken for a product.

Continuity belongs to the client evidence system, not a tool account or a persuasive demo. Questions, versions, conditions, findings and disposal decisions should survive role and provider change.

Client-held question and authority register
Problem evidence, proposed options, assumptions, consequences, decision thresholds, participants, constraints, product research technical professional security privacy accessibility acceptance and release owners, delegated limits and stop authority remain reviewable by the client.
Versioned prototype and simulation map
Artifact source, environment, setup, scenarios, content, state, access paths, integrations, test data, mocks, shortcuts, omitted conditions, fidelity rationale, versions, dependencies, credentials policy, expiry and disposal status remain explicit rather than hidden in the demo.
Linked observations, findings, and limitations
Research records, consent and access conditions, participant tasks, observations, statements, technical results, professionally owned findings, interpretations, conflicts, exclusions, threshold comparisons, rejected directions and decisions remain linked without collapsing into a validation claim.
Demonstrated repeat, rebuild, and exit path
A receiving team can run the artifact safely, reproduce one test, distinguish mock from real behavior, explain what the evidence does and does not support, discard an expired prototype, rebuild an accepted path through production controls and find why a direction was stopped.

Fit check

Use a prototyping expert when the next expensive commitment rests on an untested assumption.

Good reason to begin

  • A named product or service owner has a consequential decision, the team can state what is uncertain, and evidence from a workflow, interaction, participant, data boundary, integration or technical constraint can still change the direction.
  • Researchers, designers, content specialists, engineers and risk owners can participate; relevant users or technical witnesses can be reached safely; and the client accepts a small disposable artifact rather than demanding production polish.
  • The client wants competing ideas made tangible, risky assumptions tested early, realistic failure and access conditions, explicit evidence limits, a credible handoff and the option to discard the work without treating that as failure.

Resolve before beginning

  • The request is for a sales demo, investor theater, production shortcut, speculative visual redesign, portfolio piece, copied interface, predetermined validation result or a polished artifact that cannot influence a real decision.
  • There is no decision owner, no testable question, no access to users research or technical evidence, no professional owners, no safe data and environment, no alternative under consideration or no permission to change or stop the preferred idea.
  • The prototype must use production credentials or private data, bypass access controls, impersonate a live service, mislead participants, exclude relevant users, make legal accessibility security privacy or feasibility claims by appearance, or enter production without normal review.
  • The answer begins with Figma, code, a prototype kit, artificial intelligence, virtual reality or another medium before the decision, assumption, evidence threshold, participant, system condition and disposal plan are understood.

Source basis

Sources behind the control model.

  • 01

    Government Digital and Data Profession

    Service designer capability framework

    The current role record places prototyping within evidence-based end-to-end service design and collaborative iteration. It helps bound service-prototype depth without making every prototyping expert a service designer or proving local fit.

  • 02

    Government Digital and Data Profession

    Interaction designer capability framework

    The current role record describes prototyping and testing interaction flows and individual elements across levels. Interaction evidence is one prototype domain and does not establish product value, technical feasibility or production quality.

  • 03

    Government Digital and Data Profession

    User researcher capability framework

    The role record distinguishes research planning, inclusive practice, method, analysis and communication of findings. A prototype supports research but its maker does not own findings merely by observing a session.

  • 04

    Government Digital and Data Profession

    Product manager capability framework

    The current record assigns product value, outcomes, priority, strategy and lifecycle decisions to product management. Prototyping experts prepare evidence for those decisions without inheriting product authority.

  • 05

    GOV.UK Service Manual

    Making prototypes

    The guidance recommends multiple disposable prototypes at fidelity suited to the question, protected sharing and user testing. It explicitly warns that prototype code lacks live-service security and performance qualities and should not simply enter production.

  • 06

    GOV.UK Service Manual

    How the alpha phase works

    The guidance focuses alpha on the riskiest assumptions, minimal complexity and a proceed-repeat-stop decision. It distinguishes non-public throwaway prototypes from production and notes limits in technical accessibility testing.

  • 07

    GOV.UK Service Manual

    User research in alpha

    The guidance uses prototypes to test different ideas with a broad range of likely users, including disabled people and support staff, while acknowledging that some assistive-technology evidence requires production code later.

  • 08

    GOV.UK Service Manual

    Plan a round of user research

    The guidance asks teams to define actionable objectives, participant and access needs, tasks, consent, environment, recording, analysis and a rehearsed end-to-end artifact. It does not make one round or participant count universally sufficient.

  • 09

    GOV.UK Service Manual

    Choosing technology

    The guidance uses prototypes to explore technology, data, compliance, interfaces and component boundaries early while keeping choices open to revision. A technical spike still needs system, security and operating evidence before adoption.

  • 10

    GOV.UK Service Manual

    Understand users and their needs

    The Service Standard connects real user research, quick throwaway prototypes and operating data to understanding the problem. Its public-service requirements do not replace local evidence or product authority.

  • 11

    GOV.UK Service Manual

    Make sure everyone can use the service

    The standard makes inclusive research, assisted paths and accessibility part of service work. Prototype participation and conceptual checks can reveal risks, but production conformance needs production evidence.

  • 12

    GOV.UK Service Manual

    Create a secure service which protects users' privacy

    The standard brings security and privacy into multidisciplinary service design from the start. Prototype shortcuts, access and test data need explicit controls and do not establish local compliance.

  • 13

    GOV.UK Service Manual

    How to apply the Service Standard

    The guidance supports small learning slices while distinguishing iteratively fixable issues from accessibility, security and data risks that must not be deferred into harm. Prototype learning does not authorize release.

  • 14

    GOV.UK Design System

    Patterns

    The catalog provides task-focused patterns based on government-service research and expects teams to adapt and test them in context. Reuse can accelerate a prototype but cannot prove local fit or erase unsupported states.

  • 15

    W3C

    Web Content Accessibility Guidelines 2.2

    The current Recommendation supplies testable criteria for web content and acknowledges that conformance does not cover every user need. Prototype fidelity determines which criteria and assistive paths can be evaluated credibly.

  • 16

    NIST

    Privacy Framework 1.0

    NIST supplies a voluntary framework for identifying, governing, controlling, communicating and protecting privacy risk. It does not have force of law, and a prototype must minimize data without claiming compliance.

  • 17

    NIST

    Secure Software Development Framework 1.1

    The final SSDF organizes secure development practices across preparation, protection, production and vulnerability response. Candidate code moving beyond an experiment must enter the real development lifecycle rather than inherit prototype exemptions.

  • 18

    OWASP

    Application Security Verification Standard

    The current ASVS project provides application-security verification requirements and announced version 5.0.0. A convincing prototype or limited spike does not demonstrate application-level verification or production security.

  • 19

    DORA

    Customer feedback capability

    DORA connects early customer feedback to product and feature decisions and warns against validating only completed specifications. Its research does not prove that one prototype or method will produce a product outcome.

  • 20

    DORA

    Working in small batches

    Current DORA guidance connects small independent valuable testable batches with faster feedback and lower-cost correction. A small artifact still needs honest scope, risk, acceptance and evidence boundaries.

[ 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

Hire product designers

Connect user evidence to product design and prototypes that test a specific assumption.

Open path02

Browse the hire map

Compare prototyping with product management, research, service and interaction design, engineering, architecture, accessibility, security and quality roles before fixing the title.

Open path03

Review how Werkon works

Use the delivery model to inspect how evidence, authority, small slices, implementation, verification, handoff and client ownership fit together.

Open path04

Review product design

Use the product-design service path when problem framing, journeys, prototypes, product behavior and implementation need a defined multidisciplinary engagement.

Open path05

Review custom application development

Move to an application-development engagement when the accepted learning must become production architecture, secure code, tested behavior, operation and owned release evidence.

Open path