Begin with the outcome, not the screen
Consider a representative scenario: a three-person practice serves dozens of clients and coordinates reports and missing documents through email. Staff maintain their own reminders, clients cannot reliably see what remains, and important context is scattered across messages and files.
This is a scenario for analysis, not a customer interview or evidence that every practice works this way.
The GOV.UK Service Standard recommends understanding the user's whole context and testing assumptions about the problem before committing to a solution. Translate “portal” into an outcome:
The client and practice can agree on what is required, what has arrived, what needs correction, who owns the next action, and when the request is closed.
That outcome can be tested against existing software, a process change, or a custom system. It does not assume which one will win.
Map three lanes
Use one row per stage and three primary lanes.
Client lane
Record:
- what the client is trying to accomplish;
- what prompts them to act;
- which channel they use;
- what they believe the current status means;
- what evidence they receive; and
- where they become confused, delayed, or blocked.
Staff lane
Record:
- who creates and assigns the request;
- who validates a submission;
- who decides that a replacement is required;
- how reminders are scheduled or suppressed;
- how a colleague takes over; and
- what lets the practice declare the work complete.
System lane
Record:
- the system of record for each request and document;
- messages and reminders sent;
- status changes;
- timestamps and accountable actors;
- integrations and manual copying; and
- evidence retained for support or audit.
GOV.UK's guidance on mapping a user's whole problem explicitly includes online and offline touchpoints, backend processes, involved people, and evidence users must provide. That broader view prevents the portal screen from becoming a polished front end for an unchanged email process.
Follow one request from trigger to closure
Start with six stages:
| Stage | Essential question |
|---|---|
| Request | Who requests which item from which client, and why? |
| Receive | How does the practice know something arrived and which request it belongs to? |
| Validate | Who determines whether the item is complete, readable, current, and correct? |
| Resolve exception | How does the client learn exactly what must change? |
| Accept | What evidence establishes that the item is usable? |
| Close | Who decides no further action is needed, and which reminders stop? |
The GOV.UK experience-mapping guide recommends combining evidence from several users and iterating the map with people involved in delivering the service. For a small practice, the first map can be a whiteboard or spreadsheet. Its credibility comes from checking it against real requests, not from visual polish.
Define status as an operational contract
Words such as “uploaded,” “received,” and “complete” often mean different things to a client and a staff member.
Create a status dictionary:
| Status | Exact meaning | Owner of next action |
|---|---|---|
| Requested | The practice has asked for a named item | Client |
| Received | A submission is associated with the request | Practice |
| Needs review | A staff member must validate the submission | Practice |
| Needs replacement | The submission cannot satisfy the request, with a reason | Client |
| Accepted | An authorized staff member considers the item usable | Practice |
| Closed | The workflow owner confirms no further request action remains | Nobody |
These labels are examples, not a universal design. The practice may need different states. The important work is defining who can set each state, what evidence is required, which transitions are allowed, and what notification follows.
If a future interface updates status without moving keyboard focus, its status change should also be perceivable to assistive technology. The W3C guidance for status messages provides examples such as announcing submission success, errors, or busy states. Accessibility belongs in the workflow requirement, not only the visual design.
Inventory exceptions before features
Ask staff to bring recent examples of:
- a document uploaded for the wrong client;
- duplicate submissions;
- an unreadable, incomplete, or password-protected file;
- a request that no longer applies;
- a reminder sent after the item arrived;
- a client who cannot sign in;
- a staff member who is away;
- a previously accepted item that must be replaced;
- a portal or storage outage; and
- a phone call that changes the meaning of the recorded status.
For each exception, record:
- how it is detected;
- who owns the next action;
- what the client sees;
- how staff recover safely; and
- what proves the issue is resolved.
This is where a “login page and file list” becomes a service with identity, permissions, support, and recovery obligations.
Compare the map with established software
Established accounting portals already describe capabilities such as secure client collaboration and document requests. For example, ShareFile's accounting material describes a centralized client portal and document-request workflow.
Use the map to evaluate such a product:
- Which stages does it cover?
- Does its definition of a request match the practice's?
- Can the practice represent the important exceptions?
- Which system remains authoritative?
- Which steps still happen through email, phone, or a spreadsheet?
- Is the unresolved gap important enough to justify configuration or custom software?
The existence of one gap is not automatically a reason to replace the entire portal. A small staff-only status board or integration may resolve the material problem while established software handles external identity and document exchange.
Define the smallest coherent improvement
A useful first improvement has a clear boundary. Examples include:
- one shared staff view of outstanding requests;
- a rule that suppresses reminders after receipt;
- a defined replacement reason and owner;
- a daily exception queue;
- or a consistent closure checklist.
Choose one result and measure it with evidence already available:
- fewer manual reconciliations;
- fewer incorrect reminders;
- less time determining who owns the next action;
- fewer status disagreements; or
- faster exception resolution.
Do not claim success because a portal launched. Compare the actual workflow before and after.
Use the map as the buying brief
The accompanying template includes:
- scope and outcome;
- the three-lane journey;
- a status dictionary;
- an exception inventory; and
- questions for the smallest coherent improvement.
Give the same map to established-software vendors, no-code implementers, freelancers, and custom-development shops. Their answers will be more comparable than responses to “How much would a portal cost?”
Frequently asked questions
How detailed should the first map be?
Detailed enough to follow one real request from trigger to closure and explain the most consequential exceptions. Start small, then check the map with clients and every staff role involved.
Should email disappear from the future workflow?
Not necessarily. Email may remain an appropriate notification channel. The important question is whether the authoritative request, status, owner, and evidence remain clear when a conversation moves across channels.
Can we map the workflow without interviewing clients?
You can draft staff assumptions, but label them as assumptions. Validate the client lane with actual or likely users before treating it as a buying or building requirement.