UX Writing · Content Design · User Journey
MEET is an enterprise meeting and visitor experience platform. I worked across the end-to-end experience, including user journeys, information hierarchy, terminology and UX writing.
The challenge was to make complex meeting, room and visitor processes understandable within a workflow users were already familiar with.
My contribution
UX Writing · Content Design · User Journey · Information Architecture
Design principle
“Give users the right information at the point of decision.”
Borrowed from Nielsen Norman Group, who advise bringing together “the right information, in the right format, at the right time” to support decision making — nngroup.com.
Interface visuals on this page are recreated from the shipped product rather than captured from it. They are simplified for confidentiality: wording, layout and on-screen details are representative rather than exact, and personal, location and system information has been removed.
Case 1
Set your default meeting location
Choose the location you usually use for new meetings in MEET. You can change this anytime in your account settings.
Building
Users could organise meetings across multiple locations. Setting a preferred meeting location could make future meeting creation more efficient, but this was an optional preference and should not become a barrier to continuing.
What am I doing?
Set my default meeting location.
Why?
Save time when creating new meetings.
What do I do next?
Select a building and save.
Do I have to do it now?
No. Skip for now and change it anytime in account settings.
In this screen: state the benefit, then let users defer.
The content explains the benefit of completing the setup while explicitly giving users permission to defer the decision.
Case 2
Users were already accustomed to creating meetings within their existing calendar workflow. Rather than requiring users to learn an entirely separate process, MEET was incorporated into that existing journey.
1. Starts the meeting in the calendar tool already used every day.
2. Chooses meeting type, then location, then level or area.
3. Compares rooms by capacity and availability, then selects one.
4. Reads the summary and edits anything that looks wrong.
5. Adds external invitees and colleagues visiting from another site.
6. Confirms the booking and shares the details with attendees.
“Do I need to learn a new system for this?”
“How much of this is actually required?”
“Will this room fit everyone, and is it free?”
“Is this the right room, on the right day?”
“What do my guests have to do before they arrive?”
“Is everything in place for the day?”
Mapped in the spirit of the Nielsen Norman Group journey format: persona and scenario up top, phases as columns, the user's thoughts riding an emotional curve, and the frictions and content responses below. Emotional levels are qualitative, based on feedback and support themes rather than measured scores.
In this screen: answer the moment of doubt, not the happy path.
Case 2.1
Type of Meeting
Location/Building
Level/Zone/Area
The experience progressively collects the information needed to determine the appropriate meeting setup — meeting type, then location and building, then level, zone or area. Each choice narrows what comes next, so users are never asked to hold the whole process in their head.
In this screen: reveal one choice at a time.
Case 2.2
Building
Level
Room information is written to support a decision, not to describe the system: the room name, its capacity, its live availability, and a clear selected state. A user scanning the list can answer one question — does this room fit my meeting?
In this screen: write for the decision, not the description.
Case 2.3
Discussion Room 01
4Selected level, selected building
Tue, 1:30 PM – 2:00 PM
Room Admin
House Rules
Before progressing, users are given an opportunity to verify the important details of their selection: the room, its capacity, the location, the date and time, who administers the room, the house rules that apply, and a way back to change any of it.
In this screen: make the decision reviewable before continuing.
Case 2.4
What happens next
External invitees
Visiting staff
Different types of visitors follow different processes. The experience needed to explain those differences without requiring the host to understand anything underneath.
External invitees
Invitation → Registration → Meeting-day access
Visiting staff
Existing credentials → Meeting-day access enabled
The content answers three things only: what happens next, what the user needs to do, and what they should expect.
In this screen: name the journey, not the system.
Case 2.5
Important Notes (do not modify this section)
Warning: any modification to this section may cause system failure.
Recreated for confidentiality. Sender addresses, organisation names and internal details removed.
Part of the generated meeting information needed to remain unchanged because of a technical dependency. Users still had to interact naturally with their meeting invitation while understanding that one system-generated section should not be edited.
Not every UX problem can be solved by removing the underlying constraint. Here, the content had to make an important technical limitation visible and understandable without asking users to understand the technology behind it.
In this screen: design for the constraint, not around it.
Complex enterprise processes
Content-design layer
Structure · terminology · instructions · status · next steps
User experience
Know where you are → know what to do → know what happens next
MEET received Malaysia Customer Experience of the Year — Oil & Gas at the 2023 Asian Experience Awards.
View public project recognitionUX Writing
Clear interface language, instructions, actions and system communication.
Content Design
Determining what users needed to know, when they needed it and how information should be structured.
User Journey
Considering the experience across meeting creation, venue selection, review and visitor registration rather than screens in isolation.
Technology-aware UX
Designing understandable experiences within real enterprise and technical constraints.