01
Choose the Primary Journey
Describe the most important thing a visitor should be able to do. It might be finding a teacher, joining a community, requesting a service, or buying a product. Map the steps from arrival through completion, including the information the person needs at each point.
Different audiences may need different entry points. A practitioner and a teacher, for example, have related but distinct goals. The navigation should acknowledge that difference without asking every visitor to learn the organisation’s internal structure.
02
Design the Administration at the Same Time
Every customer action creates work somewhere. A listing needs approval, a booking needs confirmation, a cancellation changes availability, and a support request needs an owner. If administration is deferred until the end, staff may be left maintaining essential information outside the platform.
Define what each operational role can see and do. Consider drafts, pending reviews, corrections, archived records, and bulk actions. A practical administrative tool often needs clearer status information and better filters more than it needs another dashboard chart.
03
Understand Transaction States
Payment and booking workflows contain intermediate states. A customer may return from a payment provider before the final confirmation reaches the application. A booking may be cancelled after a notification is sent. A repeated click should not create a duplicate commitment.
Document the source of truth for each state, what the customer sees, and what staff do when a transaction needs attention. The exact implementation depends on the selected providers, but the business behaviour should be agreed before development begins.
04
Treat Content as Part of the Product
Profiles, product descriptions, service explanations, policies, and support information affect whether visitors can complete a task. Give each type of content an owner and a structure. Decide what must exist before launch and how it will be maintained afterwards.
For public pages, use descriptive headings, meaningful page titles, accessible links, and a clear internal hierarchy. Keep private account information behind appropriate access controls. A public marketing page and a private workspace have different discovery and privacy requirements.
05
Include Mobile and Less Convenient Situations
Test the important journeys on a narrow screen, with long names, empty lists, incorrect input, and a slow or unavailable connection. People need understandable feedback when an action fails and a way to continue without losing work unnecessarily.
Keyboard access, labelled controls, readable text, and useful error messages improve the experience for a wider range of users. Accessibility should be considered as the interface is designed, with the intended standard and verification scope agreed for the project.
06
Plan a Launch That the Team Can Support
A launch plan includes content readiness, account ownership, provider configuration, data checks, user acceptance, and support arrangements. Identify who can make a go-live decision and who handles the first operational questions. Important changes need a recovery plan appropriate to the application.
After launch, collect evidence about the journeys that matter: where people get stuck, which requests recur, and which administrative tasks create friction. That evidence is a better basis for the next release than an ever-growing list of unrelated features.
