Case study

Building journey maps for AstraZeneca

Final version of the journey map (blurred to preserve anonymity)


These are some journey maps examples I created to better understand users and the actions they went though to provide monthly updates to a business-critical resourcing tool for AstraZeneca.

Quick note on language, these are also sometimes referred to as customer journey maps or user journey maps, but they are very similar.


Journey maps are great for distilling processes down into a format which is easily understood by everyone on the team.

These also allow easy identification of the stages of the user journey and highlight user pain points.

They also allow us to uncover any issues issues in the journey – addressing these early saves a bunch of time in development.

For example, I often uncover service design/ business process issues which fall outside of the tool itself, but which need considering to  to ensure our solution is coherent and ultimately successful.

By comparing these maps across different user groups I can prioritise opportunities for improvement in a way that works for the user and the client.

You can read more general information in journey mapping (as well as the closely related experience maps and service blueprints on the excellent Nielsen Norman Group website.

Final version

Examples of the final journey maps are above. A more in-depth walk though of how we arrived at this journey map follows…

How we got there

User identification

From previous user research I’d already identified our user groups, and how they fitted into the wider business process around the product.

It had become clear that there were two key groups we needed to focus on, which we called;

  • template creators &
  • template completers.

Draft journey map

We drafted what we thought were the key stages of the journey for each user group.

Against each stage of the journey I considered the specific information we needed to capture. On this project, this was;

  • Specific actions (we knew high level but not detail)
  • Touchpoints (people/processes/platforms)
  • Opportunities for improvement
  • Owners of each stages OR…
  • …additional stakeholder we might need to engage with.
Miro screenshot showing collection of raw data from user research sessions

Discussion guide

I drafted a discussion guide for client approval. This was to ensure agreement on the areas of research, and to provide a guide for the user researcher (me in this case) to make sure all agreed areas were covered in the user interviews.

Finding participants for usr research

We needed to choose our participants carefully. There were many areas of the business we might have sourced them from.

But we wanted to make sure the participants we chose would be representative of the variety and diversity of the user groups they represented.

User Research

Having sourced our candidates, I performed user experience research . We choose remote moderated as the user research method, which effectively means walking the candidate through their journey via MS teams.

Post it note observations were added to our draft journey map in the approximate part of the process they corresponded to.

We also captured multiple screenshots of related service, touch points and tools which supported our users on their journey.

Miro screenshot showing collection of raw data from user research sessions

How to synthesis user research data

After collecting all the data from the user research sessions, I performed some analysis and synthesis of the raw data which this time round involved:

  • Cleaning and sanitising the data
  • Refining our draft user journey from the data we collected in research
  • Identifying for recurring themes or common patterns
  • Extracting opportunities from verbalised or observed behaviour

These findings were summarised into a short report which was delivered to the client

Case study Uncategorised

Heatmaps case study


The client wanted a way to report on resource usage across their drug development portfolio.  

This encompassed tens of thousands of people and hundreds of millions of dollars of revenue.

The approach

It was clear that the scope of this project was somewhat ambiguous so we initially committed to a discovery phase only. 

Depending on the findings from discovery and the direction the project took we would evaluate the best use of time and the most effective deliverables.


Business analysis

The first task was understanding more about the business – what was the specific problem they had and how would we measure success. This involved multiple workshops and interviews with key business stakeholders and users.

Report analysis

There was already an existing offline process in place which made use of multiple excel sheets.  We needed to do a deep dive to understand more.

User identification

Our research uncovered four different user types. 

  • Administrators
  • Resource Council users
  • Function level users
  • Higher management.

We interviewed users in each group to get more complete understanding of their specific problems.

We additionally sat in on monthly resource meetings to observe how existing reports were used “in the wild”.

User Research


A change in direction

From our research it became clear there was more to this project. In order to succeed we needed to broaden the scope of our engagement to consider:

  1. Data collection
  2. Service design
  3. Change management
  4. Enterprise level IT solutions.

High-level prototype

Unconventionally, the decision was taken to develop and test a high-level wireframe prototype as part of the discovery process.

The objectives of this were as follows

  • Demonstrate a possible way of automating the current (labour-intensive) process
  • Sense-check that the work done to date is heading in the correct direction

Prototype user testing

Initial user testing was completed against the high level prototype. 

Affinity mapping was used to organise insights, and a summary deck produced and presented.


Future roadmap

The summary deck was well received, and based on this a strategic roadmap was drawn up to indicate how to progress the project. 

This includes;

  • Workshopping
  • Co-design sessions
  • Customer journey mapping
  • Continues wireframing and user testing
Case study

User testing

Benefits summary

This was a really lightweight and quick way to get feedback which uncovered some fundamental flaws in the approach

  • 3 x critical factors which would have derailed the project
  • Multiple opportunities to tighten up and improve our messaging to communicate more clearly with our target audience

Client feedback

“I thought it was great, and a very critical step.”

“Design of interfaces and ensuring that content is presented in a digestible and accessible way…is such a fundamental need”

“I certainly saw the merit and am already planning on carving out additional budgets to include these types of focused user feedback.”

Client feedback from User Testing session with AZ


We were contracted to develop some ideas for a medical website aimed at pathologists in the US. The purpose of the site drive implementation of HER2 testing, which can have a profound effect on the treatment of breast cancer.

Based on existing research, some wireframes had been created, but we were keen to understand if these would resonate with working pathologists who were the target audience for this site.


Recruitment of pathologists (especially in the US) is extremely tightly regulated, and payment for services can be seen as inducement/bribes, so we had to be very careful from a legal perspective

With that in mind we contacted a specialist(M3) who handled the recruitment and legal/regulatory issues, and screened the candidates for suitability.

Recruiting pathologists is not cheap! – We ended up with 5 who we spoke to for roughly an hour each.

Discussion guide

Prior to the session we created a discussion guide with the client.

This highlighted the key areas we wanted to explore so we had a consistent line of questioning across all candidates while retaining the flexibility to probe deeper based on individual candidate experience

Running the session

In terms of set up we generally kick thinkgs off with a MS teams call before using for the majority of the session. Starting in the teams channel allows us to trouble shoot any connectivity or tech issues the user might have. We keep this available during the call in case of emergencies, but mute it during the main discussion.

Links to the prototype are available through Lookback (we’d set this up previously) so the user can jump straight into it

Client management

With these session, there is often a lot of interest and various people wnat to be involved. Typically we run an account for an assistant to speak to the facilitator during the session. This assistant screens the comments being fed through to the facilitator (it can get pretty overwhelming) while ensuring any relevant feedback from the stakeholders is passed on

Video review and write up

Post the session we reviewed the videos collected on Look this allowed us to retrospectively sense check, and clip videos to give specific examples to clients to illustrate the points.

Over the course of the session we found a number of themes emerging (detailed at the top of the page) which we presented back to the client in a power point format.