Service safari
Go out and use real services yourselves, your own and other people's, and bring back what it actually feels like.
- Time
- 120 min
- People
- 2–6
- Kind of work
- Understand · Generate
In short
A service safari is a field trip in which team members use real services themselves, their own and others', as ordinary customers, recording what happens with photos and notes. To run it, set a focus, choose four to eight services, go out in pairs, complete a real task at each, then share and sort the findings together.
What it is
A service safari takes the people who design and run a service out of the meeting room and puts them on the customer's side of the counter. Each person picks a service, goes through it as an ordinary user with a real task to complete, and records what they see, hear, wait for and feel along the way. The services can be your own, a competitor's, or ones from a completely different sector that handle a similar moment well or badly.
The method is widely used in service design as an early way to build first-hand understanding before formal research, and as a source of ideas worth borrowing. It does not replace talking to users: you learn what the service is like for someone like you, not for someone with less time, less confidence or a different language. In this worksheet each visit gets one record: the service, the task you attempted, the channel and place, what happened step by step, the evidence you captured, the main surprise or pain, and any idea worth borrowing.
When to use it
Use it when
- A team is about to redesign a service that most of its members have never used as a customer.
- Leaders describe the service from reports and dashboards and you want them to feel the gaps themselves.
- You are starting a project and want quick, shared first impressions before planning interviews.
- You are looking for ideas from other sectors that handle a similar moment, such as waiting, paying or proving who you are.
- Two channels of the same service, such as the branch and the app, are said to be consistent and you want to check.
Skip it when
- You treat it as a substitute for research with real users. Staff experience the service with inside knowledge and confidence that customers do not have.
- The service cannot be used without a genuine need, such as an emergency department or a benefits claim, and posing as a customer would waste capacity or mislead staff.
- You cannot get permission to photograph or record in the places you plan to visit, and notes alone will not give the team enough to work with.
You need
- Time
- About 2 hours: 20 minutes to brief, 60 minutes in the field, 40 minutes to share. Longer if visits are spread across a city.
- People
- 2 to 6 people working in pairs, ideally mixing frontline staff with managers and designers.
- Materials
- One worksheet per visit, phones for photos and timings, a short list of services and tasks, and a wall or shared board for the debrief.
How to run it
Step 1: Set the focus
Agree in one sentence what you want to learn, for example "how people find out what to bring and how long they wait before they are served". A clear focus stops the safari turning into a general complaint tour and tells everyone what to watch closely.
Step 2: Choose services and tasks
List four to eight services to visit. Include at least one of your own, one direct equivalent elsewhere, and one or two from an unrelated sector that handle the same moment. Give each a real task to complete, such as booking an appointment, asking a question or paying a bill, so people go through the service rather than just looking at it.
Step 3: Agree the ground rules
Behave as an ordinary customer and do not say you are on a study visit unless asked. Check photography rules before you go, never photograph faces or screens with personal data, and ask permission inside private or government premises. Do not take a slot, a ticket or a staff member's time that a real customer needs more than you.
Step 4: Go out in pairs
Send people in twos: one does the task, the other watches and takes notes and timings. Swap roles at the next service. The observer catches the small things the user is too busy to notice, such as signs nobody reads or the moment a queue stops moving.
Step 5: Record each step as it happens
Fill one worksheet per visit while it is fresh. Write what happened in order, note times, and link each point to a photo. Separate what you observed from what you felt, and capture exact wording from signs, screens and staff.
Step 6: Share the stories
Back together, each pair tells the story of one visit in three minutes, with photos, from arriving to leaving. Others write one surprise or pain per sticky note as they listen. Keep the tone descriptive. The aim is to see the service clearly, not to blame the people working in it.
Step 7: Sort and pick what to take forward
Group the notes into themes, then mark two kinds of finding: problems in your own service that need research with real users, and ideas from other services worth borrowing. Record both, along with what you still do not know, so the next step is clear.
Worked example
A regional electricity utility planned to redesign how new customers request a home connection. The project team of six had all worked on the service for years, but none had applied for a connection themselves, and the brief said only that customers found the process "slow and confusing".
The focus was "how people find out what is needed for a new connection and what happens while they wait for a decision".
Three pairs visited nine services over one afternoon: two of the utility's own customer centres, its website and phone line, a water connection counter, a bank opening a business account, a telecom store setting up home internet, a vehicle inspection centre and a hospital outpatient booking desk.
They came back with 140 photos and 62 notes. At one of their own centres a pair waited 47 minutes to learn that the site plan had to be stamped by a separate office, a requirement that appeared nowhere on the website.
The telecom store gave a printed sheet with each step, the expected date and one named contact. The vehicle inspection centre showed the live queue position on a screen outside the building.
Sorting produced five themes. The team chose two to research with real applicants: missing information before the first visit, and silence after an application is submitted.
They added one idea to borrow, a single sheet with steps, dates and a named contact, to the list for the next idea session, and recorded that none of them had tried the service in a language other than Arabic or English.
IllustrativeTips and mistakes
Tips
- Give every visit a real task. Looking around a branch tells you far less than trying to get something done in it.
- Time things. A wait that felt like 10 minutes is often 25, and a number on the wall is harder to argue with than an impression.
- Include at least one service from a different sector. The most useful ideas often come from places nobody on the team thought to compare.
- Bring frontline staff and managers into the same pairs, so each sees what the other notices.
Common mistakes
- Visiting only your own service, which confirms what the team already believes and misses ideas from elsewhere.
- Taking photos of people's faces or personal details, which damages trust and may break the rules of the premises.
- Writing everything up a day later, when the small details that matter most have already faded.
- Treating the team's own experience as proof of what customers need, and skipping research with real users.
What you walk away with
You leave with one worksheet and a set of photos per visit, a short list of themes, the problems in your own service that need research with real users, and a few ideas from other services worth borrowing. The next step is usually contextual observation or stakeholder interviews to test the problems with the people who live with them, and an analogies session to develop the borrowed ideas.
Questions people ask
How many services should a service safari include?
Four to eight is enough for one afternoon with a small team. Fewer than four rarely gives you a comparison, and more than eight leaves too little time to record each visit properly.
Should we tell staff we are on a service safari?
Usually not, so you see the service as it normally runs. If someone asks, be honest. In your own organisation, tell local managers in advance that visits may happen without naming the day, and make clear it is not an inspection of individuals.
What is the difference between a service safari and contextual observation?
In a service safari the team uses the service itself and records its own experience. In contextual observation you watch real customers or staff as they use or deliver the service. The safari is quicker and builds empathy within the team; observation tells you what is true for other people.
Tool card
The worksheet your team fills in, one box per field.
- Service visited
- Task attempted
- Channel and place
- What happened, step by step
- Evidence captured
- Surprise or pain
- Idea worth borrowing