Map the user journey and pain points

When a library team says “users dislike the service,” it may be hiding different failures. One person cannot find the booking link; another finds it but cannot understand eligibility; a third completes a request and receives no confirmation. One proposed feature will not necessarily solve all three. A user journey map arranges one defined person's actions across a defined service path and records evidence and possible friction at each stage. It is not promotional artwork showing an ideal visit. Its value is locating an interruption before selecting a solution.

Define who the map represents, what that person is trying to do, and where the path begins and ends. We will map a fictional visitor booking a library study room, from discovering the room to entering it. Do not merge the visitor's journey with an employee's approval workflow. The paths intersect, but the actors have different needs and authority. Put the boundary on the map: it starts when the visitor looks for a booking method and ends when entry is confirmed. Starting only at the “book” button excludes people who never find the page. Extending the map to general satisfaction months later makes a small booking decision too diffuse to investigate.

Divide the path into observable actions: find a room, understand availability and conditions, submit a request, receive confirmation, arrive and present the booking. For each stage, record the user's action, the interface or person encountered, available evidence, and an unknown to investigate. Do not write an emotion as if you observed it. “The visitor felt frustrated” requires an appropriate interview or observation; “the visitor revisited the conditions page three times” can be observed in a usability session but does not by itself tell us why. This separation lets the specialist ask a focused question rather than decorate a story.

The worked map's calendar row should say: “Visitor sees time slots and 'provisionally available'; evidence is 90 calendar viewers and 54 later submissions under the unique-person definition; unknown is whether wording prevents submission or some people are simply exploring.” The confirmation row should say: “Visitor submits a request; 42 of 54 receive confirmation; inspect reasons for nonconfirmation before naming a software fault.” Friction points are now prioritized hypotheses, not established causes. A small test of clearer wording and a review of rejection reasons answer different questions; do not present them as equivalent experiments.

If logs count clicks rather than unique visitors, do not calculate person-to-person conversion rates from them. Ask for a stable event definition or observe a consented sample under the organization's policy. If an interview shows that a visitor with a visual impairment cannot read the calendar, do not conceal that finding behind an average conversion figure; request an appropriate accessibility review from the competent team. The specialist's task is a truthful map and a bounded test proposal, with privacy and accessibility issues referred to their owners. The map alone does not authorize changing booking policy.

When a journey map exposes friction, identify the owner of that service step before proposing a test. Unclear availability may arise in interface copy, failed confirmation in mail delivery, and slow approval in staff workload. Labeling all three a “page problem” steers a team toward one solution that cannot address the others. In a joint review, ask each owner what actually happens as a request crosses systems, then compare that account with a bounded event record. If account and log conflict, name a question to investigate. The map connects user experience to operating responsibility without claiming the specialist controls every system.