Link user problem, design and feedback on a feature.
These sheets describe activities and teaching exercises. They do not constitute job offers, certifying courses or recruitment promises.
All job descriptions
Connect user needs, service objectives and a verifiable solution across the whole journey, beyond individual screen appearance.
Designers document trade-offs; product owners decide scope and priorities. Attractive proposals still require feasibility, maintenance and testing.
Compare two journeys using observed tasks and explain the chosen option.
This is an editorial description of common activities. Job titles and scope vary across teams; it is not a certification framework.
W3C: organising accessibility responsibilities across a team
Improve search for a catalog by examining requests and searches without result.
Work on a copy or demo environment. Define the data used and the expected result before you begin. Keep your decisions and the difficulties encountered in order to be able to explain the process.
A framed problem, reasoned variants, a prototype and a verification plan.
The choices are justified and the limits of the verification are explicit.
For each check, note the context, the action, the expected result and what has been observed. Distinguish a successful verification from a remaining hypothesis. Another person must be able to understand the deliverable without attending all its manufacture.
Use the Functional Validation BookAdding a feature does not guarantee improvement. A decision must remain related to the initial problem and the available observations.
Collaboration to explore: UX research.
Specify the sharing of responsibilities: who provides the information, who decides, who checks and maintains the result. A good handover retains the constraints and decisions, not just the final file.
Employment, trades and trainingAssess a product decision through the problem addressed, chosen scenario and evidence that could invalidate the solution. A prototype helps learning; visual success does not yet establish product usefulness.
| Skill | Evidence to examine | Failure to spot |
|---|---|---|
| Problem | An audience, observable difficulty and decision to make. | The desired feature is used as the definition of the need. |
| Hypothesis | A testable scenario with success and failure conditions. | The test cannot challenge the solution. |
| Trade-off | Compromises, constraints and remaining questions are recorded. | One result is presented as universal validation. |
Download the editable CSV checklist
The file contains this table and blank columns for the observed result, owner and follow-up. It opens in a spreadsheet; downloading it does not send your observations to the site.
Compare two responses to the same need, including a simpler option. Before testing, define what observation would change the choice, then record what was learned rather than only the selected screen.
W3C WAI: involving users in evaluation.
In-depth exercise: Improve a research path where visitors do not know how to differentiate categories. Formulate the problem before choosing an interface. Propose two tracks: clarify categories or modify filtering. For each, describe the people concerned, the dependencies and how to check the effect. Make a prototype limited to the useful course. A decision must be able to be explained by a need and an observation, without transforming a personal preference into a demonstrated result.
These criteria are a working basis to adapt to the context. For each, note the action taken, the expected result, the observed result and the information remaining to be confirmed.
Share selected choices, discarded tracks and open questions with the production team. Link acceptance criteria to uses rather than just screenshots. Specify how a new data can put a decision under discussion. After delivery, compare the observed behavior to the starting hypothesis; The publication of the prototype does not constitute a validation of its usefulness.
Design may address an observed difficulty or explore a new capability. Separate these goals so that an expected correction is not compared with an untested hypothesis.
A feature list does not explain a workflow’s value. Link each proposal to a task, constraint and expected outcome.
Present alternatives and available information. Explain what justifies the trial, what remains unknown and what would prompt reconsideration.
It allows you to show an approach and its limits. It is neither a diploma, nor a certification, nor proof of a production experience.
Specify that this is an exercise, your role, constraints, decisions and checks. Use test data and media whose rights are established.
The choices are justified and the limits of the verification are explicit. Add the difficulties encountered and what remains to be verified rather than presenting absolute validation.
Identify it as a prototype or exploration. Describe hypotheses, people consulted and tasks observed. Separate observed results from expected effects: the document supports a decision without promising unmeasured outcomes.
