A field guide to the invisible part of the experience
The customer
between
the tools.
Your customer does not care which system owns the record. They care whether the business remembers what happened, keeps the promise, and makes the next step clear.
Enter the blueprintThe experience is larger than the interface
Every gap is
felt by someone.
A customer can forgive a system boundary. They should not have to discover it by repeating themselves.
One tool captures an inquiry. Another holds the account. A third sends a document. Somewhere in the middle, a person copies a name, checks a status, asks for a detail the customer already supplied, and tries to make the whole thing feel intentional.
That middle is the service. GOV.UK’s service-design guidance describes a good service from beginning to end, front to back, and across every channel. It includes the internal processes, software, data, and policies that support the visible experience. [1] That is the lens this report applies to customer portals, project workspaces, onboarding flows, support systems, and any business where the customer waits on a handoff.
A portal is valuable when it gives the customer useful agency and continuity. It is harmful when it merely exposes internal fragmentation through a new login.
Context should survive the handoff. Responsibility should survive the tool change.
The customer should not become the integration layer.
A status should answer what happened and what happens next.
A useful action should carry the right record and permission.
A person should have a clear route when the path breaks.
A useful map shows the hidden work
See the service
from both sides.
18F’s service-blueprint method uses four rows: user steps, frontstage actions, backstage actions, and support processes. It is a compact way to make relationships between people, systems, and evidence visible. [2] NN/g makes a related distinction: a journey map centers the customer’s experience; a blueprint centers how the organization creates it. [3]
Every visible status, field, email, and portal action is evidence of the business behind it.
Every promise needs an owner, a source of truth, a permission check, and a recovery path.
Self-service only helps when it carries context
A portal is
a promise.
A useful portal lets someone see the right status, provide the right detail, and take the next action without asking the company to reconstruct the story. It should reduce uncertainty, not move it behind a password.
SELF-SERVICE THAT WORKS+
It answers the customer’s actual question: what do you have, what is happening, what do you need from me, and who owns the next step?
- Shows a status with a timestamp and next action.
- Preserves documents, messages, and decisions in one context.
- Lets the customer correct or add information without restarting.
- Offers a clear route to a human when the case is unusual.
FRAGMENTATION IN A NEW SKIN+
It adds a login to an internal filing cabinet while the customer still needs email, a phone call, or a staff translation to understand the outcome.
- Shows a status label without an owner or next step.
- Duplicates information across tools without a source of truth.
- Exposes internal teams or codes the customer should never need to know.
- Has no recovery route when data is missing or access fails.
NIST’s current identity guidance treats authentication, identity proofing, privacy, security, and customer experience as one decision. [5] For a portal, that means asking what this person should be able to see and do, how much assurance the risk requires, and how they recover without creating a new support trap.
The smallest useful operating model
Make the seams
observable.
The handoff is where a customer experience becomes an operating system. Start with one journey. Name the records, roles, events, and exceptions that must travel together.
- 01
Name the source of truth.
For each important fact, decide which system owns it. If two tools can change the same status, the business needs a reconciliation rule before it needs more UI.
- 02
Carry the smallest useful context.
Pass the customer’s goal, current state, owner, due next step, and relevant evidence. Do not copy the whole back office into the customer journey.
- 03
Authorize the object and the action.
OWASP’s API guidance warns that an attacker can change an object identifier to reach another user’s record. Every endpoint that reads or changes a record needs an object-level authorization check. [6]
- 04
Measure the finish.
GOV.UK’s performance guidance recommends defining metrics from the start and using completion and drop-off data to decide what to research next. [7] For a business, that can mean completed requests, time to a useful answer, corrections, and escalations—not just portal logins.
Ian helps owners map the customer’s path, separate a portal from a filing cabinet, and connect the systems that need to act like one service.
Sources & methodology
Make the invisible
legible.
This report was researched September 8, 2026. It combines official service-design, data, identity, and API-security guidance with original UX research on service blueprints. It does not describe an audited client journey or claim that a portal will reduce support cost or increase retention.
The blueprint and portal comparison are proposed patterns. The cited frameworks describe useful methods and risks; the recommendations are Ian Dikhtiar’s synthesis for business owners who need one accountable technical owner across websites, portals, automation, and customer experiences.
- [1]Designing good government services: an introduction ↗
Government Digital Service · GOV.UK · Updated December 7, 2023
Frames a service from beginning to end, front to back, and across channels. It is service guidance, not a claim that one portal solves every customer problem.
- [2]Service blueprint ↗
18F Guides · Current guide checked September 2026
Defines a blueprint as a start-to-finish view of using and supporting a service, with user steps, frontstage actions, backstage actions, and support processes.
- [3]Service Blueprinting FAQ ↗
Nielsen Norman Group · Updated November 2019
Original UX research and practice guidance distinguishing a customer journey map from an organization-facing service blueprint, including frontstage and backstage actors.
- [4]Designing with data: an introduction ↗
Government Digital Service · GOV.UK · Updated November 25, 2024
Guidance on data sources, consistent formats, privacy, reuse, APIs, and planning measurement from the start of service design.
- [5]Digital Identity Guidelines, Revision 4 ↗
National Institute of Standards and Technology · Updated September 30, 2025
Current identity guidance covering proofing, authentication, federation, security, privacy, and customer experience. Assurance and recovery should follow the service’s risk.
- [6]API Security Top 10: Broken Object Level Authorization ↗
OWASP API Security Project · 2023 edition
Explains why APIs must authorize every object and action, not merely accept an object ID supplied by a client. It is security guidance, not a forecast of a specific breach.
- [7]Using performance data to improve your service ↗
Government Digital Service · GOV.UK · Updated April 6, 2022
Encourages teams to define performance metrics from the start, including completion and cost per transaction, then use drop-off data to guide research and improvement.