Enterprise websites often grow around the organisation’s structure. Each department adds its own section, navigation mirrors the organisation chart and important tasks are buried several clicks deep. Users, however, arrive with specific goals: finding a service, comparing options, checking eligibility, contacting the right team or completing a transaction. Designing around user journeys means starting from those goals and shaping content, navigation and functionality to support them. This article sets out a practical approach for enterprise teams.
Identify who uses the site and why
Begin by defining the main audiences and their most important tasks. For a large organisation this may include prospective customers, existing customers, partners, investors, job seekers, media and regulators. For each, identify the handful of tasks that matter most. Draw on analytics, search logs, contact centre enquiries and conversations with front-line staff, as well as direct research with users. Internal assumptions about what people want are often incomplete.
Be specific about context. A procurement manager in Riyadh researching suppliers on a desktop has different needs from a customer in Dubai checking a service on a phone between meetings. Language preference matters too: many users in the region switch between Arabic and English, and some tasks are more naturally completed in one language than the other. Capture these differences in simple task descriptions grounded in evidence.
Map journeys end to end
A journey map describes the steps a user takes to achieve a goal, the questions they have at each stage, the channels they use and the points where they encounter friction. For enterprise websites, journeys rarely start and end on the site. A user may see a social post, search, visit the site, call the contact centre and then return to complete an application. Mapping the full sequence reveals where the website helps, where it hands off and where the handoffs break.
Focus on a small number of priority journeys rather than attempting to map everything. For each, document the current experience honestly, including dead ends, duplicated content and forms that ask for information already provided. Then design the target journey, noting what content, features and integrations are needed. This becomes a practical brief for design and development, and a reference point for decisions later in the project.
Structure content and navigation around tasks
Once journeys are clear, organise the information architecture around them. Group content by what users are trying to do, use labels they recognise rather than internal terminology and make the most common tasks reachable from the home page and search. Card sorting and tree testing with real users are inexpensive ways to check that a proposed structure makes sense before visual design begins.
Arabic and English versions deserve equal attention. Mirrored layouts, typography that works well in both scripts and content written natively rather than translated literally all affect whether a journey feels coherent. Where content differs between languages or countries, make that explicit in the content model so it is managed deliberately. Search should handle both scripts and common spelling variations, since many users navigate primarily by searching.
Connect the website to the systems behind it
Many journeys cannot be completed with content alone. Checking an order, booking an appointment, requesting a quote or updating account details depends on integration with CRM, ERP, booking or case management systems. Identify these dependencies early, because they often determine timelines and budget more than front-end design does. Where a full integration is not yet possible, design an interim path that is honest with users about what happens next.
Pay particular attention to forms and handoffs. Pre-fill information when a user is signed in, validate inputs clearly, confirm submission with a reference number and send a follow-up message through the channel the user prefers. Make sure enquiries reach the right team and that someone is accountable for responding. A well-designed front end loses much of its value if the process behind it is slow or opaque.
Measure and improve over time
Define success measures for each priority journey, such as task completion, time to complete, drop-off points and the number of related contact centre calls. Review them regularly and test changes with real users. Treat the website as a product with an owner and a backlog rather than a project that ends at launch, and revisit journeys as services, regulations and user expectations change.
A partner such as MomentumX can help with user research, journey mapping and bilingual content design, and with connecting the website to the platforms that journeys depend on. The most durable results come when internal teams own the journeys and the measures, with outside support focused on building lasting internal capability rather than replacing it, and on handing over the tools and methods needed to keep improving.
