An applicant arrives with a task: understand a requirement, prepare information, submit it and find out what happens next. A service portal has to support that journey alongside the work of the people reviewing and operating the service.
Start with the decision
Establish what the service is deciding, which information is required and who is accountable for the outcome. Map the steps outside the website as well as the steps inside it. A digital form cannot remove an unresolved responsibility.
Explain the requirements early
Show the relevant documents and information before a person begins. Separate required information from useful supporting context. A first-time visitor should be able to decide whether they are ready to proceed.
Give every field a purpose
Use understandable labels, group related information and explain what to do when an entry is invalid. W3C’s forms guidance describes how labels support people using forms, including people using assistive technology. Clear wording and appropriate markup are part of the service design.
Design the review side too
Identify the work queue, permitted actions, clarification route and record of decisions. Check access on the server for the specific action and record; OWASP’s authorisation guidance explains why permissions need to be validated throughout the application.
Make status useful
Received, awaiting information, in review and decided should correspond to meaningful states in the agreed process. Tell the applicant what the current state means and whether they need to do anything. Avoid presenting a submission receipt as an approval.
Accept the whole journey
Walk through a complete example with nominated reviewers: requirements, submission, validation, review, clarification and response. Include an incomplete application and an attempted action by the wrong role. Agree what evidence is needed before release.
The operating team then needs service instructions, responsibilities, support routes and an understandable handover. Those materials connect the interface to the organisation that will run it.
Take it into the brief
A practical checklist.
- Service decision and responsibilities mapped
- Requirements visible before the form
- Fields labelled and validation explained
- Reviewer actions and access rules defined
- Status messages connected to actual workflow states
- Complete and exception journeys included in acceptance
Further reading.
Primary references checked 1 November 2026. The design approach above is the studio’s own explanatory guidance.
Continue the conversation
Have a related piece of work?
Bring the process, source material and constraints. We can discuss the right starting point.
Start your brief ↗