Start with a task, not a screen inventory
Describe one user, their starting context, the decision they need to make and the outcome they expect. A screen list often hides the hardest questions: which data can be trusted, who has permission to act and what happens when the task is interrupted. Map the shortest complete path and identify the moment a user knows it worked. For a new product, prioritize one representative flow before estimating every future feature. For an existing product, bring support tickets and observed friction rather than only stakeholder preferences.
Design the states around the normal path
Record loading, empty, error, offline, validation, permission and completion states for the chosen flow. Specify source and owner of every critical piece of content, including messages in each supported language. A beautiful happy-path prototype is insufficient if a real user cannot recover from a failed submission or understand why a record is unavailable. Prototype the branching moments early and review them with the people who implement, support and operate the product.
Define what a first release proves
Choose a measurable task outcome such as completing an application or finding a correct record, and an observation method appropriate to the product. A click count alone cannot show whether the person succeeded. Agree the sample, data access, privacy and decision owner before claiming a result. The first release should test the central assumption with a usable interface, clear feedback and a practical support route. Document known exclusions so future work is a deliberate backlog rather than a surprise.
Separate product, website and build responsibilities
A marketing website explains the offer and captures interest; a product interface supports repeated tasks, roles and changing data. They may share a visual system but need different acceptance checks. Ask the design team to identify which flows it will research and prototype, which components and states it will specify, whether it will implement them and who owns the backend. Dardo's public Supérame case is a product-interface reference; evaluate its published scope before treating it as evidence for any feature your brief requires.
Sources & editorial notes
How we built this guide
EvidenceThis guide combines Dardo’s direct project evidence with our analysis. Project examples are labeled where they appear.
LimitsVisible design and content decisions are not presented as measured ranking, traffic or conversion gains.
Read our editorial policy