Plan UX/UI around real tasks and implementation
An attractive screen does not show whether people can complete their tasks. A useful project links use, structure and interface. Define the workflows to examine, screens to design and deliverables needed for development.
Describe the product, users and tasks
Identify the digital product and its main user groups. Describe actual tasks: booking an appointment, finding an offer or completing an internal process. Existing problems and technical constraints help set priorities.
Distinguish a new concept, redesign and targeted evaluation. Existing brand rules, devices and languages form part of the starting point.
Define workflows, screens and states
Count more than main screens. Input, feedback and exceptions also affect effort. An initial scope can focus on particularly important workflows.
| Component | Scope to define |
|---|---|
| Workflow | Start, steps and successful finish |
| Main screen | Content, hierarchy and interaction |
| States | Errors, loading, empty content and confirmation |
| Device variation | Display and interaction at relevant sizes |
Test assumptions with suitable users
Clarify existing evidence and open questions. Interviews or tasks on a prototype can reveal hesitation and failure. Participants should match actual user groups.
Agree tasks, facilitation and a clear record of observations. A few comments should not be presented as findings for all users. Plan recruitment and appropriate handling of test data.
Agree structure and prototypes before detail
Sketches and simplified screens help test content and workflows before complete visual design. A clickable prototype can demonstrate selected routes; it is not yet a developed product.
Specify the functions and states included in the prototype. Consolidated feedback and clear decisions reduce reworking already approved details.
Combine interface design and accessibility
Typography, contrast, labels and visible feedback affect interaction. Consider relevant devices, keyboard use and user situations. Existing brand rules need to become usable interfaces.
Agree which accessibility aspects to examine. User evaluation and technical checks complement each other. A visually approved prototype does not establish accessibility of later implementation.
Hand over understandable components and decisions
Developers need more than images: names, variants, states and behaviour need clear descriptions. Agree working files, exported assets and access to the chosen prototype.
Identify who answers implementation questions and whether the developed interface will be reviewed. Reusable components and documented decisions support later additions. Software development and publication are separate services.
Compare equivalent deliverables
Compare the same workflows, screens, states and device variants. Research, visual design and development support may be separate items. Define included revisions and additions.
| Item | What to compare |
|---|---|
| Analysis | Tasks, evidence and open questions |
| Concept | Workflows, structure and prototype scope |
| Interface | Screens, states and components |
| Evaluation | Participants, tasks and analysis |
| Handover | Files, documentation and implementation support |
Frequently asked questions
How do UX and UI differ?
UX considers use and tasks across the workflow. UI designs the visible, interactive interface. They often work together in a project.
Does the product need to exist already?
No. Ideas, prototypes and existing products are possible starting points. Describe the stage and open questions.
Is a prototype a finished app?
No. It shows agreed workflows and screens. Implementation, data handling and publication need separate planning.
How can scope be described without an exact screen count?
Identify important workflows and a size band for main screens. States and devices can be clarified in the brief.
Are user tests always included?
Only if agreed. Clarify participants, tasks, facilitation and analysis.
What do developers need at handover?
Working files, understandable components and states, behaviour and a contact for questions. The quote should define the actual scope.
