MSD
Using NHS trusts to further innovation
Using NHS trusts to further innovation
A website encouraging the participation of competitive innovation through location-based case studies amongst private and NHS trusts in the UK.
Project type
Project type
Webapp
Webapp
Company
Company
MSD
MSD
Location
Location
UK
UK
Industry
Industry
Oncology
Oncology
Role
Role
UX Designer
UX Designer
Tools
Tools
Figma, FigJam, Adobe, UT
Figma, FigJam, Adobe, UT
Empathise
The problem
MSD oncology reps have case studies they spend a long time handing out to their HCP lists. Some of these are emailed over but the bulk of their time is spent trying to find the relevant study to help HCPs work with other trusts and finding solutions to their patients.
The MSD brand team want to propose a digital HUB solution where the case studies can be accessible to HCPs from NHS computers.
Research goals
First we need to understand what the case studies are, what they entail and how we can asses their messaging.
This will be bucketed into:
Case study subjects and their outcomes
How case studies link together
The existing database of studies
Will there be future studies likely to be added
User Interviews
We worked with a small series of KAMs and REPs for MSD who ran us through a series of case studies from conception to delivery and we discussed the flow of case studies from where they're hosted, how the REPs send them and how specialists request information from them.
Below are an example of the type of content in a case study
Journey of a case study
We’ve loosly mapped out the general flow of a case study and how it’s delivered to trusts.
Familiarising myself with a case study
I looked at 5 case studies to understand how they differ, how they’re similar and any key information useful to HCPs that might be pulled out.
Assumption: CS will feature similar information set out in a medical format. Styling will be varied. Is it accessible and what is relevant to HCPs?
Focus: Can they work harder to focus key information. Can we connect people?
Case studies aren’t defined or centralised meaning the job of finding one can be laborious
KAMs are a tool for HCPs to get CS documents but aren’t the factory in swaying the treatment plan. That tends to go to local trusts and HCP workshops in the area, meaning they tend to rely on colleague opinion.
Average user age is high with low technical efficiency rate.
Key insights
Analysing user interviews
Analysing user interviews
Define
Identifying possible product goals
Research on...research?
At this stage we were sensitive to the clients pre-vetted solution but after testing this on a browser it was a bit difficult to understand the flow of information but it did have 1 good value.
+ Information was live and allowed you to change your parameters for different results
- Interface was clunky and not very intuative for a patient who wouldn’t understand many of the terms
We workshopped a solution with the client to find a good webapp-friendly solution.
Planning the treatment
There is no formal plan as patients tend to come either direct through a GP, consultant or hospital
Outreach starts during a meeting with a KAM, usually about something else unrelated, bu have asked the questions.
Competition space for connecting trusts in Oncology
Competition space for connecting trusts in Oncology
Ideate
How can the research define the solution
We have two options to look at when deciding how best to serve case studies. But lets first look back on the overall project goals
“Can we centralise case studies for Trusts and HCPs to access information more easily than our current process”
Trying to ladder up to the initial request as much as possible. We can add value to HCP and trusts with a new product that sits outside of the strict promotional remit whilst connecting oncology teams.
A website thats easily accessible through NHS computers that allows a filtering system for HCPs and Trusts to find relevent case studies
A sharing platform that allows HCPs and Trusts for search terms related to treatment that can a) bring relevent MSD case studies to the front, and b) give contact points for local teams who’s treatment plans match theirs.
Developing a site map
Now we have agreed a webapp is the primary solution we have to define heirarchy of importance so we don’t add too much technical load of NHS machines. These are typically PCs with very low processing power.
Low resolution imagery. Ideally a move from PSD to native information to allow for accessibility
Minimal use of branding to ease connection load time
A simple filtering or search feature that reads tags at a low rate with incremental increases over time to keep it simple.
We workshopped initial ideas with the MSD team to gauge their reaction to idea parameters. They have been loose with any parameters on final product so this was an opportunity to understand their capacity for it.
Prototype
Content buckets
With a general site map in place we can look at bucketing our content. How does it fit together to start to bring our wireframe to life.
We can bucket these into 3 different sections. Promotional (capacity), Pathways (treatment), and general. with a 2-tier approach we can separate non-promotional material without the need for a gateway reducing load times and infrastructure from the dev team.
For case studies we have multiple pathways for case studies; Region, indication and pathway. At first we use these as a full filtering system and not split them out. This gave users less laddering down of types and leaves room for exploration.
Wireframing
After sketching some low-fiddy wireframes the team were confident to move to a mid-fiddy version to help bring it to life. One note for the MSD team struggle to understand concepts without them being at least medium-fidelity wireframes with copy overlaid.
Expand capacity
This is the promotional side of the coin, protected by a gateway we can host specific video content and downloadable material that help MSD push treatment plans. This will not likely be updated over time
Optimise treatment
Looking at case studies that are either bucketed by metatagging search criterea or a pre-built filter system. We user tested the filtering system to see if it allowed HCPs great interaction, or less. Also if its pushed any competitiveness in trusts doing work thats similar
Testing
Revision
MSD team wanted both sections accessible from a single homepage so we looked at various options that allowed us to test some variations of a homepage. Below is an option that yeilded some results but ultimately for our age group the first presented option leant itself best to simplicity.
Revision 2
We felt there was longevity in location-based case studies. We wanted to make sure MSD had all the information they could to make an informated decision so along with user testing multiple variations.
Revision 3
MSD felt splitting their filter systems out would benefit a phase 1 launch.
Look and Feel
MSD have a strong brand which we wanted to plug into and leverage the brand collateral. We looked at a general L&F styling which we would flow into the final design. We tested various options of a stripped back version up to a style that leant heavily on their illustration palette.
Usability
Final user testing on target audience yielded ~20% uptick in collaboration between trusts for a phase 1 launch. Phase 2 is in progress with enhanced collaboration between trusts using this MVP as a portal site to gauge long-term trust with MSD.
Whats next?
MSD phase 1 launch with with REPs for formal testing. Once user insights have been formally gathered we'll move to phase 2 where they can build the collaborative trust features to allow HCPs to work more closely.
Empathise
The problem
MSD oncology reps have case studies they spend a long time handing out to their HCP lists. Some of these are emailed over but the bulk of their time is spent trying to find the relevant study to help HCPs work with other trusts and finding solutions to their patients.
The MSD brand team want to propose a digital HUB solution where the case studies can be accessible to HCPs from NHS computers.
Research goals
First we need to understand what the case studies are, what they entail and how we can asses their messaging.
This will be bucketed into:
Case study subjects and their outcomes
How case studies link together
The existing database of studies
Will there be future studies likely to be added
User Interviews
We worked with a small series of KAMs and REPs for MSD who ran us through a series of case studies from conception to delivery and we discussed the flow of case studies from where they're hosted, how the REPs send them and how specialists request information from them.
Below are an example of the type of content in a case study
Journey of a case study
We’ve loosly mapped out the general flow of a case study and how it’s delivered to trusts.
Familiarising myself with a case study
I looked at 5 case studies to understand how they differ, how they’re similar and any key information useful to HCPs that might be pulled out.
Assumption: CS will feature similar information set out in a medical format. Styling will be varied. Is it accessible and what is relevant to HCPs?
Focus: Can they work harder to focus key information. Can we connect people?
Analysing user interviews
Case studies aren’t defined or centralised meaning the job of finding one can be laborious
KAMs are a tool for HCPs to get CS documents but aren’t the factory in swaying the treatment plan. That tends to go to local trusts and HCP workshops in the area, meaning they tend to rely on colleague opinion.
Average user age is high with low technical efficiency rate.
Key insights
Case studies aren’t defined or centralised meaning the job of finding one can be laborious
KAMs are a tool for HCPs to get CS documents but aren’t the factory in swaying the treatment plan. That tends to go to local trusts and HCP workshops in the area, meaning they tend to rely on colleague opinion.
Average user age is high with low technical efficiency rate.
Define
Identifying possible product goals
Research on...research?
At this stage we were sensitive to the clients pre-vetted solution but after testing this on a browser it was a bit difficult to understand the flow of information but it did have 1 good value.
+ Information was live and allowed you to change your parameters for different results
- Interface was clunky and not very intuative for a patient who wouldn’t understand many of the terms
We workshopped a solution with the client to find a good webapp-friendly solution.
I started looking at the treatment plans trusts and HCPs might use to get an idea of when case studies might be appropriate.
Planning the treatment
There is no formal plan as patients tend to come either direct through a GP, consultant or hospital
Outreach starts during a meeting with a KAM, usually about something else unrelated, bu have asked the questions.
Competition space for connecting trusts in Oncology
Ideate
How can the research define the solution
We have two options to look at when deciding how best to serve case studies. But lets first look back on the overall project goals
“Can we centralise case studies for Trusts and HCPs to access information more easily than our current process”
Trying to ladder up to the initial request as much as possible. We can add value to HCP and trusts with a new product that sits outside of the strict promotional remit whilst connecting oncology teams.
A website thats easily accessible through NHS computers that allows a filtering system for HCPs and Trusts to find relevent case studies
A sharing platform that allows HCPs and Trusts for search terms related to treatment that can a) bring relevent MSD case studies to the front, and b) give contact points for local teams who’s treatment plans match theirs.
Developing a site map
Now we have agreed a webapp is the primary solution we have to define heirarchy of importance so we don’t add too much technical load of NHS machines. These are typically PCs with very low processing power.
Low resolution imagery. Ideally a move from PSD to native information to allow for accessibility
Minimal use of branding to ease connection load time
A simple filtering or search feature that reads tags at a low rate with incremental increases over time to keep it simple.
We workshopped initial ideas with the MSD team to gauge their reaction to idea parameters. They have been loose with any parameters on final product so this was an opportunity to understand their capacity for it.
Prototype
Content buckets
With a general site map in place we can look at bucketing our content. How does it fit together to start to bring our wireframe to life.
We can bucket these into 3 different sections. Promotional (capacity), Pathways (treatment), and general. with a 2-tier approach we can separate non-promotional material without the need for a gateway reducing load times and infrastructure from the dev team.
For case studies we have multiple pathways for case studies; Region, indication and pathway. At first we use these as a full filtering system and not split them out. This gave users less laddering down of types and leaves room for exploration.
Wireframing
After sketching some low-fiddy wireframes the team were confident to move to a mid-fiddy version to help bring it to life. One note for the MSD team struggle to understand concepts without them being at least medium-fidelity wireframes with copy overlaid.
Expand capacity
This is the promotional side of the coin, protected by a gateway we can host specific video content and downloadable material that help MSD push treatment plans. This will not likely be updated over time
Optimise treatment
Looking at case studies that are either bucketed by metatagging search criterea or a pre-built filter system. We user tested the filtering system to see if it allowed HCPs great interaction, or less. Also if its pushed any competitiveness in trusts doing work thats similar
Testing
Revision
MSD team wanted both sections accessible from a single homepage so we looked at various options that allowed us to test some variations of a homepage. Below is an option that yeilded some results but ultimately for our age group the first presented option leant itself best to simplicity.
Revision 2
We felt there was longevity in location-based case studies. We wanted to make sure MSD had all the information they could to make an informated decision so along with user testing multiple variations.
Revision 3
MSD felt splitting their filter systems out would benefit a phase 1 launch.
Look and Feel
MSD have a strong brand which we wanted to plug into and leverage the brand collateral. We looked at a general L&F styling which we would flow into the final design. We tested various options of a stripped back version up to a style that leant heavily on their illustration palette.
Usability
Final user testing on target audience yielded ~20% uptick in collaboration between trusts for a phase 1 launch. Phase 2 is in progress with enhanced collaboration between trusts using this MVP as a portal site to gauge long-term trust with MSD.
Whats next?
MSD phase 1 launch with with REPs for formal testing. Once user insights have been formally gathered we'll move to phase 2 where they can build the collaborative trust features to allow HCPs to work more closely.
Project type
Webapp
Company
MSD
Location
UK
Industry
Oncology
Role
UX Designer
Tools
Figma, FigJam, Adobe, UT
Empathise
The problem
MSD oncology reps have case studies they spend a long time handing out to their HCP lists. Some of these are emailed over but the bulk of their time is spent trying to find the relevant study to help HCPs work with other trusts and finding solutions to their patients.
The MSD brand team want to propose a digital HUB solution where the case studies can be accessible to HCPs from NHS computers.
Research goals
First we need to understand what the case studies are, what they entail and how we can asses their messaging.
This will be bucketed into:
Case study subjects and their outcomes
How case studies link together
The existing database of studies
Will there be future studies likely to be added
User Interviews
We worked with a small series of KAMs and REPs for MSD who ran us through a series of case studies from conception to delivery and we discussed the flow of case studies from where they're hosted, how the REPs send them and how specialists request information from them.
Below are an example of the type of content in a case study
Journey of a case study
We’ve loosly mapped out the general flow of a case study and how it’s delivered to trusts.
Familiarising myself with a case study
I looked at 5 case studies to understand how they differ, how they’re similar and any key information useful to HCPs that might be pulled out.
Assumption: CS will feature similar information set out in a medical format. Styling will be varied. Is it accessible and what is relevant to HCPs?
Focus: Can they work harder to focus key information. Can we connect people?
Case studies aren’t defined or centralised meaning the job of finding one can be laborious
KAMs are a tool for HCPs to get CS documents but aren’t the factory in swaying the treatment plan. That tends to go to local trusts and HCP workshops in the area, meaning they tend to rely on colleague opinion.
Average user age is high with low technical efficiency rate.
Key insights
Analysing user interviews
Define
Identifying possible product goals
Research on...research?
At this stage we were sensitive to the clients pre-vetted solution but after testing this on a browser it was a bit difficult to understand the flow of information but it did have 1 good value.
+ Information was live and allowed you to change your parameters for different results
- Interface was clunky and not very intuative for a patient who wouldn’t understand many of the terms
We workshopped a solution with the client to find a good webapp-friendly solution.
Planning the treatment
There is no formal plan as patients tend to come either direct through a GP, consultant or hospital
Outreach starts during a meeting with a KAM, usually about something else unrelated, bu have asked the questions.
Competition space for connecting trusts in Oncology
Ideate
How can the research define the solution
We have two options to look at when deciding how best to serve case studies. But lets first look back on the overall project goals
“Can we centralise case studies for Trusts and HCPs to access information more easily than our current process”
Trying to ladder up to the initial request as much as possible. We can add value to HCP and trusts with a new product that sits outside of the strict promotional remit whilst connecting oncology teams.
A website thats easily accessible through NHS computers that allows a filtering system for HCPs and Trusts to find relevent case studies
A sharing platform that allows HCPs and Trusts for search terms related to treatment that can a) bring relevent MSD case studies to the front, and b) give contact points for local teams who’s treatment plans match theirs.
Developing a site map
Now we have agreed a webapp is the primary solution we have to define heirarchy of importance so we don’t add too much technical load of NHS machines. These are typically PCs with very low processing power.
Low resolution imagery. Ideally a move from PSD to native information to allow for accessibility
Minimal use of branding to ease connection load time
A simple filtering or search feature that reads tags at a low rate with incremental increases over time to keep it simple.
We workshopped initial ideas with the MSD team to gauge their reaction to idea parameters. They have been loose with any parameters on final product so this was an opportunity to understand their capacity for it.
Prototype
Content buckets
With a general site map in place we can look at bucketing our content. How does it fit together to start to bring our wireframe to life.
We can bucket these into 3 different sections. Promotional (capacity), Pathways (treatment), and general. with a 2-tier approach we can separate non-promotional material without the need for a gateway reducing load times and infrastructure from the dev team.
For case studies we have multiple pathways for case studies; Region, indication and pathway. At first we use these as a full filtering system and not split them out. This gave users less laddering down of types and leaves room for exploration.
Wireframing
After sketching some low-fiddy wireframes the team were confident to move to a mid-fiddy version to help bring it to life. One note for the MSD team struggle to understand concepts without them being at least medium-fidelity wireframes with copy overlaid.
Expand capacity
This is the promotional side of the coin, protected by a gateway we can host specific video content and downloadable material that help MSD push treatment plans. This will not likely be updated over time
Optimise treatment
Looking at case studies that are either bucketed by metatagging search criterea or a pre-built filter system. We user tested the filtering system to see if it allowed HCPs great interaction, or less. Also if its pushed any competitiveness in trusts doing work thats similar
Testing
Revision
MSD team wanted both sections accessible from a single homepage so we looked at various options that allowed us to test some variations of a homepage. Below is an option that yeilded some results but ultimately for our age group the first presented option leant itself best to simplicity.
Revision 2
We felt there was longevity in location-based case studies. We wanted to make sure MSD had all the information they could to make an informated decision so along with user testing multiple variations.
Revision 3
MSD felt splitting their filter systems out would benefit a phase 1 launch.
Look and Feel
MSD have a strong brand which we wanted to plug into and leverage the brand collateral. We looked at a general L&F styling which we would flow into the final design. We tested various options of a stripped back version up to a style that leant heavily on their illustration palette.
Usability
Final user testing on target audience yielded ~20% uptick in collaboration between trusts for a phase 1 launch. Phase 2 is in progress with enhanced collaboration between trusts using this MVP as a portal site to gauge long-term trust with MSD.
Whats next?
MSD phase 1 launch with with REPs for formal testing. Once user insights have been formally gathered we'll move to phase 2 where they can build the collaborative trust features to allow HCPs to work more closely.
Empathise
The problem
MSD oncology reps have case studies they spend a long time handing out to their HCP lists. Some of these are emailed over but the bulk of their time is spent trying to find the relevant study to help HCPs work with other trusts and finding solutions to their patients.
The MSD brand team want to propose a digital HUB solution where the case studies can be accessible to HCPs from NHS computers.
Research goals
First we need to understand what the case studies are, what they entail and how we can asses their messaging.
This will be bucketed into:
Case study subjects and their outcomes
How case studies link together
The existing database of studies
Will there be future studies likely to be added
User Interviews
We worked with a small series of KAMs and REPs for MSD who ran us through a series of case studies from conception to delivery and we discussed the flow of case studies from where they're hosted, how the REPs send them and how specialists request information from them.
Below are an example of the type of content in a case study
Journey of a case study
We’ve loosly mapped out the general flow of a case study and how it’s delivered to trusts.
Familiarising myself with a case study
I looked at 5 case studies to understand how they differ, how they’re similar and any key information useful to HCPs that might be pulled out.
Assumption: CS will feature similar information set out in a medical format. Styling will be varied. Is it accessible and what is relevant to HCPs?
Focus: Can they work harder to focus key information. Can we connect people?
Analysing user interviews
Case studies aren’t defined or centralised meaning the job of finding one can be laborious
KAMs are a tool for HCPs to get CS documents but aren’t the factory in swaying the treatment plan. That tends to go to local trusts and HCP workshops in the area, meaning they tend to rely on colleague opinion.
Average user age is high with low technical efficiency rate.
Key insights
Case studies aren’t defined or centralised meaning the job of finding one can be laborious
KAMs are a tool for HCPs to get CS documents but aren’t the factory in swaying the treatment plan. That tends to go to local trusts and HCP workshops in the area, meaning they tend to rely on colleague opinion.
Average user age is high with low technical efficiency rate.
Define
Identifying possible product goals
Research on...research?
At this stage we were sensitive to the clients pre-vetted solution but after testing this on a browser it was a bit difficult to understand the flow of information but it did have 1 good value.
+ Information was live and allowed you to change your parameters for different results
- Interface was clunky and not very intuative for a patient who wouldn’t understand many of the terms
We workshopped a solution with the client to find a good webapp-friendly solution.
I started looking at the treatment plans trusts and HCPs might use to get an idea of when case studies might be appropriate.
Planning the treatment
There is no formal plan as patients tend to come either direct through a GP, consultant or hospital
Outreach starts during a meeting with a KAM, usually about something else unrelated, bu have asked the questions.
Competition space for connecting trusts in Oncology
Ideate
How can the research define the solution
We have two options to look at when deciding how best to serve case studies. But lets first look back on the overall project goals
“Can we centralise case studies for Trusts and HCPs to access information more easily than our current process”
Trying to ladder up to the initial request as much as possible. We can add value to HCP and trusts with a new product that sits outside of the strict promotional remit whilst connecting oncology teams.
A website thats easily accessible through NHS computers that allows a filtering system for HCPs and Trusts to find relevent case studies
A sharing platform that allows HCPs and Trusts for search terms related to treatment that can a) bring relevent MSD case studies to the front, and b) give contact points for local teams who’s treatment plans match theirs.
Developing a site map
Now we have agreed a webapp is the primary solution we have to define heirarchy of importance so we don’t add too much technical load of NHS machines. These are typically PCs with very low processing power.
Low resolution imagery. Ideally a move from PSD to native information to allow for accessibility
Minimal use of branding to ease connection load time
A simple filtering or search feature that reads tags at a low rate with incremental increases over time to keep it simple.
We workshopped initial ideas with the MSD team to gauge their reaction to idea parameters. They have been loose with any parameters on final product so this was an opportunity to understand their capacity for it.
Prototype
Content buckets
With a general site map in place we can look at bucketing our content. How does it fit together to start to bring our wireframe to life.
We can bucket these into 3 different sections. Promotional (capacity), Pathways (treatment), and general. with a 2-tier approach we can separate non-promotional material without the need for a gateway reducing load times and infrastructure from the dev team.
For case studies we have multiple pathways for case studies; Region, indication and pathway. At first we use these as a full filtering system and not split them out. This gave users less laddering down of types and leaves room for exploration.
Wireframing
After sketching some low-fiddy wireframes the team were confident to move to a mid-fiddy version to help bring it to life. One note for the MSD team struggle to understand concepts without them being at least medium-fidelity wireframes with copy overlaid.
Expand capacity
This is the promotional side of the coin, protected by a gateway we can host specific video content and downloadable material that help MSD push treatment plans. This will not likely be updated over time
Optimise treatment
Looking at case studies that are either bucketed by metatagging search criterea or a pre-built filter system. We user tested the filtering system to see if it allowed HCPs great interaction, or less. Also if its pushed any competitiveness in trusts doing work thats similar
Testing
Revision
MSD team wanted both sections accessible from a single homepage so we looked at various options that allowed us to test some variations of a homepage. Below is an option that yeilded some results but ultimately for our age group the first presented option leant itself best to simplicity.
Revision 2
We felt there was longevity in location-based case studies. We wanted to make sure MSD had all the information they could to make an informated decision so along with user testing multiple variations.
Revision 3
MSD felt splitting their filter systems out would benefit a phase 1 launch.
Look and Feel
MSD have a strong brand which we wanted to plug into and leverage the brand collateral. We looked at a general L&F styling which we would flow into the final design. We tested various options of a stripped back version up to a style that leant heavily on their illustration palette.
Usability
Final user testing on target audience yielded ~20% uptick in collaboration between trusts for a phase 1 launch. Phase 2 is in progress with enhanced collaboration between trusts using this MVP as a portal site to gauge long-term trust with MSD.
Whats next?
MSD phase 1 launch with with REPs for formal testing. Once user insights have been formally gathered we'll move to phase 2 where they can build the collaborative trust features to allow HCPs to work more closely.