Portal language fits a field of work when users recognise their own subject without having to learn internal jargon. Make core terms such as ‘file’, ‘journey’ and ‘component’ configurable, but maintain one glossary per project. Freedom without agreements creates an inconsistent environment.
A homebuyer looks for a home and choices for it. A parent looks for a child’s file and appointments. An insured person looks for a claim and requested documents. Technically, these processes can use the same components while their visible language differs considerably. That is an important principle for a own customer portal.
Separate the data model from the user-facing term
Software needs stable internal objects. A general unit can, for example, hold information, actions and documents. It does not need to be called a ‘unit’ in the interface. Yindle Portal therefore has project-specific labels for the unit, category and portal itself. The same structure can be presented as a home, case, pupil file or maintenance contract.
Do not use that flexibility to choose a different term on every screen. Define one visible name for each object and document what it includes. If ‘journey’ sometimes means the entire customer relationship and sometimes a single form, both clients and employees become uncertain.
Create a glossary before writing screen copy
A compact glossary prevents discussions during design and content entry. Include at least these columns:
| Internal object | Client-facing term | Verb | Do not use |
|---|---|---|---|
| File | Insurance claim | View | Case, ticket |
| Category | Component | Complete | Module |
| Action item | Outstanding action | Carry out | Task record |
| Response | Submission | Review and send | Submit |
Add plurals, forms of address and status words. Also decide whether to use an informal or formal form of address. Mixed styles are particularly noticeable in error messages and emails, because different teams often write them.
Worked example: a fictional insurer
Fictional insurer HelderSchade wants to use a general customer portal. In the first concept, the main navigation is called ‘projects’, the customer card ‘unit’ and a request for information ‘action item’. The screen works functionally, but test users think they have entered an administration system.
HelderSchade then chooses ‘My claims’, ‘Claim file’ and ‘Still to provide’. The ‘damage assessment’ category gets a short explanation instead of an abbreviation for the internal department. Beside ‘submitted’, it says: ‘We have received your information; a claims handler will check it.’ The meaning of the process has not changed, but the user knows where they stand.
Configurable labels make a general portal structure recognisable for a specific customer journey. The underlying objects remain stable while customers see words from their own process.
Test language with divided attention
Many clients open a portal on their phone between other activities. Do not test only with colleagues who know the context. Give a test user one task and observe which words they actually look for. Then ask what they think each status word means.
Use this language score for each screen, awarding zero to two points:
- The title names the subject the client knows.
- The main button starts with a clear verb.
- A status also explains who acts next or what the next step is.
- Error messages explain how the user can continue.
- Email and the portal use the same name for the same object.
A screen scoring below eight points goes back for editing. This is not a scientific measurement method, but a practical way to treat language as part of design.
Limit exceptions
Some organisations want to customise labels for each department. Only do so when clients actually see different processes. A central glossary reduces management work, makes searching predictable and prevents reports from using different names for the same subject.
Do not forget automated communications. An invitation email saying ‘activate your unit’ can still make a carefully written portal feel unfamiliar. Include invitations, reminders, download names and confirmations in the same editorial review. Ask an employee who is not involved in the project to read the entire journey aloud.
After launch, measure where people drop out or ask for support. Record the words clients themselves use in emails and phone calls. If five people ask where they can upload their ‘evidence’ while the button says ‘add attachment’, that is useful input. Update the glossary in a controlled way and change every occurrence at the same time.
On the Portal page you can find a description of the general file structure. To establish which words your customers actually use, plan a language and process review with Yindle.