In commercial software development, the most successful applications are often the ones where the vendor has invested the time and effort to design an engaging user experience. That user experience transcends the widgets you put on the screen, and encompasses critical success factors like:
- Reduced cycle time – reducing the amount of time required to advance a discovery project from target identification through to pre-clinical testing.
- Fit-to-function – how well does the application fit the requirement
- Fit-to-flow – how well does the application fit the workflow that we use. Do we need to spend time entering data into multiple systems?
- Ease-of-use – how easy is it for scientists to start using the application
- Reduced training time – how much time is required to be fully conversant with the application, keeping in mind that the lab may have GLP training requirements for software.
- Reduced rework – reduce the number of times that an internally developed application must be reworked to suit the needs of the scientists.
- User satisfaction – increase user satisfaction and decrease frustration
- Increased bench time – decrease the amount of time spent entering data, and increase the amount of time spent at the bench.
- Aesthetics – studies of computer-human interaction have found that an aesthetically pleasing user interface can reduce work-place stress. Sometimes the user experience can be so compelling that scientists are willing to overlook the fact that the application doesn’t actually cover a significant portion of their workflow.
- User interface consistency – by making the user interfaces for internal applications consistent with one-another, you can reduce training time.
The flip-side of these metrics reflect the ways in which a poorly designed UX can affect productivity and even retention. The applications that scientists use every day are often seen are a reflection of how seriously the company values science and scientists. A poorly designed user experience can result in duplicate work, lots of manual entry work, or manual transformation of data from one form into another in order to get the data into another system.
The 1990s Called And They Want Their UI Back
Millennials have certain expectations about the software they use, based in part on the social media and mobile applications they use every day.
- They expect it to be easy to use.
- They expect it to be as familiar to them as the other mobile applications they use.
- They expect to be able to use it on a range of devices (known as responsive design).
- They expect to be performant. They want interact with it without having to go through multiple page loads.
- They expect it to notify them when a lab process has completed (a robot has finished replating samples, or a sequencer has finished its run).
- And they expect to be able to interact with the system while wearing having personal-protective equipment like goggles and gloves.
UX In Pharmaceutical Companies
In pharmaceutical companies, we have traditionally seen User Experience (UX) practices applied in customer-facing web applications not internally developed research applications. The traditional business rationale for putting additional effort into UX is that a well-designed web or mobile patient-engagement application can result in increased patient compliance with medications, improved customer satisfaction, and increased sales, in addition to simply making patients aware that new treatments for their indication exist. Taken as a whole, these metrics constitute measures of “customer-solution fit”. And while they have a direct bearing on profitability, but also have an important bearing on how the company is perceived by both patients and potential future employees.
Beyond web applications though, we’re now seeing UX and Design Thinking practices applied in everything from clinical trial design to manufacturing and packaging. The ultimate goal of these practices though is to provide a more patient-centric focus.
As we’ll see later on in the article, these UX practices are beginning to filter down to pharmaceutical research organizations in some new and interesting ways. We’re translating the expectations of research communities into applications that fit the way they work.
How seriously do pharmaceutical companies take UX Design?
Seriously enough that companies likes GSK, Novartis, Amgen, Roche, Merck and AstraZeneca all have Centers of Excellence or Communities of Practice for UX Design. In addition, these companies are working together through the Pistoia Alliance to develop a common pre-competitive toolkit for UX design through a program called UX for Life Sciences.
The toolkit contains processes, templates, case studies, and best practices for creating new compelling user experiences, and improving the user experience in existing scientific software. And although we might use this in the context of software development, the same processes have been used by the group to solve problems in logistics, laboratory design, material handling/inventory, and lab operations.
The group borrows from the Design Thinking practices first developed at Google Ventures and taught at Stanford’s d.School (one of the country’s most prestigious design schools).
Design Thinking
The Design Thinking process in use at Google, Adobe, Mayo Clinic, Kaiser Permanente, Pfizer, Novartis, Roche/Genentech and many other companies follow is a 5-step exercise which brings together subject matter experts, UX design, and development experts into a single room to focus on solving a challenging business problems. And although there are a number of implementations of Design Thinking practices, these companies have chosen Stanford’s d.School approach in-part because it’s so well documented, and training videos are available on YouTube.
Design Thinking helps us use what we know about our customers and business processes to design new and compelling solutions that fit their needs. The 5 steps of the process are:
Empathise – Learn about your business process and participants to the point that you understand their priorities, biases and problems.
Define – Define the problem to be solved.
Ideate – Identify as many potential solutions as possible that solve the problem. Sketch what those solutions might look like, and storyboard how a user might interact with them.
Prototype – Create a crude prototype solution using simple tools like Keynote or PowerPoint.
Test – Have the users evaluate the prototypes and provide feedback
Then continue to iterate on the last two steps until you have a prototype that best fits the need. At some point during these iterations, you’ll transition from a Keynote/PowerPoint prototype to code.
The explainer videos below gives you a brief/long overview of the process.
Design Sprints
One of the most common implementations of Design Thinking is a process called the Design Sprint. Similar to development sprints that you see in agile software development organizations, a Design Sprint is a 5-day, time-boxed process for quickly developing and evaluating prototypes that resonate with the end-user. A typical Design Sprint looks like this:
Day 1
- Start At The End – Identify the business goal(s) that you’re trying to achieve.
- Map – map the process. For example, if your goal is to develop a more efficient process to create antibodies (and the software needed to achieve it), then your map would include the people, process steps and technologies currently in use to make that happen. This map provides a common reference point and vocabulary for all of the participants in the process. You can also use this part of the exercise to identify the parts of the process that are slow, user intensive, or just plain broken.
- User Interviews – At this point, subject-matter experts help you flesh out the details behind the steps in the process. Everyone in the meeting will be focused on taking notes, and asking questions.
- Choosing A Design Target – After mapping out the process, the team selects a single target user and event that will become the focus for the rest of the design sprint.
Day 2
- Remix and improve – identify features in existing solutions that you like, and demo them for the rest of the team, and collect the best features on a whiteboard.
- Sketch – Using the some of the previously demonstrated features as “grist for the mill”, the team members begin sketching new solution ideas.
Day 3
- Decide – Review the sketches and select the solution(s) that best solve the problem.
- Rumble – If you have multiple solutions, then the best way to compare them is to prototype both of them during Day 4, and review the results on Day 5.
- Storyboard – Storyboard each of the solutions. Each storyboard walks the user through the business process/scientific process that you want to support.
Day 4
- Prototype – prototype the storyboards using Keynote or PowerPoint.
Day 5
- Evaluation – review the resulting solutions with subject-matter experts.
- To learn more about Design Sprints try Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days. This book walks you through the Design Sprint process using a number of case studies to illustrate each step.
You’ll also find this podcast (entitled “Design Thinking For Clinical Trials“) useful for seeing how Design Thinking has been applied to design more patient-centric clinical trials.
More Reading
- User Experience for Life Science – Pistoia Alliance
- UX Design maximising the value of scientific software in life science R&D
- Pfizer’s Daniel Seewald: Where Design Thinking Breaks Down—and How to Avoid It
- Design Lab Collaborates with Amgen to Explore Adoption of Medical Therapies
Read more of the UX for Life Sciences Series
Need Help Getting Started?
Contact us to learn more about how you can apply Design Thinking in your research organization.