Stop, collaborate and listen: a model for successful pharma and vendor engagement

Digital transformations are having wide-ranging and profound impacts within life sciences, creating both opportunities and challenges. One of those challenges is adopting new software systems to drive the transformations. Pharma invests in powerful software technologies with the promise of increased efficiencies, but ultimately, if the interfaces are unintuitive and more difficult than current processes, end users find work-arounds and do not fully adopt the software (1).Employing a User Experience (UX) Design process is essential to developing intuitive and usable interfaces. While UX tools are commonly utilised within many industries, implementation and recognition of their full potential has not been fully realised within the life sciences (2,3).

A team from Novartis Institutes of BioMedical Research (NIBR) recognised the need to ensure a good user experience for their in vivostudy support groups. The NIBR team, partnered with technology provider, RockStep Solutions (RSS), to tackle the challenge. The industry partners developed a process they called the 4P process (Proof of Concept, Prototype, Pilot, Production) and adopted the UX Toolkit for Life Sciences, developed by the Pistoia Alliance User Experience for Life Sciences(UXLS) group, to help guide the design process (4).In this article, the authors present a case study illustrating a successful collaboration that created software to support complex in vivoworkflows. Furthermore, they describe the repeatable 4P process they developed to help pharmaceutical companies and vendors replicate this success.

What motivates digital transformations

In competitive industries, speed to market is everything. If implemented correctly, digital transformations can enable new research and improve ROI by disrupting inefficient legacy processes and driving quality and efficiency across a R&D organisation (5). As biopharmaceutical companies target increasingly complex diseases, discovery informatics tools play a key role in every functional area from the laboratory bench to the scientists’ desktops.

Legacy software tools have become rate-limiting bottlenecks in production and data intensive processes, as they have not adapted to the changing needs of science. Often times, legacy tools with poor UX design, are used for purposes far outside their original intent because new flexible tools do not exist (6)

The industry must also continue to attract and retain a talented workforce with new ideas that drive innovation. Highly skilled professionals expect to work for companies that lean into technology and where digitalisation is not just a buzz word. Team morale and staff retention are often negatively impacted by processes that are unnecessarily repetitive, outdated, or ill-fitted to career development (7).

Need for a digital transformation

Driving this effort, the Study Support Supervisor, within the Laboratory Animal Services (LAS) group at NIBR, was charged with building a team of in vivo specialists. The goal was to partner with Disease Area (DA) teams within the NIBR framework to provide exceptional science support for in vivoprojects. The operational program was required to be productive, efficient, and lean, while exemplifying scientific excellence. Success would be measured by key operational metrics and the ability to share scientific data across functions and therapeutic areas, both onsite and globally.

The informatics tool kit initially available to achieve these objectives included pen and paper, Excel, Outlook, PowerPoint, SharePoint and stand-alone legacy database tools. However, the utilisation of these tools caused operational inefficiencies, which limited productivity and opened the door for errors. The lack of a centralised collaboration platform hampered communications, team collaborations, workflows, and negatively impacted the availability and harmonisation of data.

Furthermore, while mapping LAS business processes, the team uncovered process inefficiencies in interactions among local and global sites, which resulted in duplication of effort and data.

Gaining insight

The Study Support team collaborated with the NIBR Emerging Technologies group to conduct a gap analysis for a digital strategy. After mapping the current state and the desired future state, it was clear that NIBR LAS would need to undergo a digital transformation, to replace their legacy tools, if they were to achieve their objectives of scientific and operational excellence. However, rather than attempting to address the global LAS needs, which would probably be too large and complex to succeed, the team decided to initiate a project with a more manageable scope and limit phase-one to the NIBR Study Support group. Even within this smaller scope, the project required collaboration across multiple Disease Areas and functions. Overall, the size and manageable complexity of the scope made this an ideal initial test group.

The joint team developed a detailed tier of requirements needed to satisfy their high-level business objectives. The program’s success would require a real-time, customisable, searchable, and centralised digital management tool. The ideal tool would be easy to use and able to operate with legacy data systems. It would also need to support study design and scheduling functionality, data capture, and visualisation.  Additionally, the final product must have the ability to evolve with the LAS digital program, both locally and globally, and be future proof to ensure support for the evolving needs of the LAS and potentially other R&D programs.

Partner selection

Major vendor solutions are built on older technologies with legacy GLP frameworks that could not easily be adapted to provide the flexibility required by early phase in vivoresearch. Solutions built on these old architectures would not be future proofin an environment where complex technologies, like Machine Learning and Artificial Intelligence analysis tools are maturing and demonstrating value. The NIBR group teamed up with the RockStep Solutions to evolve their modern cloud solution, Climb, for this digital transformation initiative (8,9).

A well-developed and carefully implemented digital transformation could address the core challenges noted above. However, a poorly implemented digital transformation would waste time and resources and not accomplish any of the key objectives (5). Pharma-vendor partnerships often fail, or do not progress past the proof of concept phase due to poor communication, misalignment, and unclear expectations (10).Gartner also reports that life science organisations tend to “underdeliver value from digital partnerships due to their risk-averse cultures, hardened legacy policies and positioning, and misaligned outcomes (11).”

To maximise chances of success, the team developed a communication framework with regularly scheduled onsite and online meetings, clear agendas, and shared documents outlining project goals and success metrics. The team also ensured that key stakeholders and end users had institutional support to participate in interviews, process mapping sessions, workshops, and functionality evaluation. Success requires a chain of commitment from leadership to product end-users.

The Pistoia Alliance UXLS toolkit was used to ensure that user centricity was at the heart of an iterative agile development process within the 4P approach. The UXLS Toolkit was built for the life science community by UX professionals, as part of a Pistoia Alliance project to improve access to UX design (4).  The toolkit project was launched due to common complaints from Pistoia Alliance members, who argued that vendors’ software often did not cater to the needs of researchers because of general lack of usability (1).

The 4P Approach

The team developed a 4P approach: Proof of Concept, Prototype, Pilot, Production. This approach builds on recognition that stakeholders know their pain points and have ideas on how to improve them, but they are not fully knowledgeable about the technologies and possibilities. On the other hand, technology experts lack user empathy. The best solution is a joint design built with iterative feedback.

Phase 1: Proof of Concept

The Proof of Concept (PoC) phase demonstrates the feasibility of a solution for the organisation. It determines if the technology performs as anticipated, whether end-users will adopt the technology, and if there is enough anticipated value to move to the next phase.

Technology vendors often shy away from PoCs as they can be expensive and time consuming with no guarantee of conversion to a paid deployment, and pharmaceutical companies are often reluctant to invest time and resources to conduct tests with unknown ROI. However, PoCs have advantages for both parties. The pharmaceutical company can de-risk future investment by determining if a solution can solve their challenges, and they can determine if their users will likely adopt the solution, while the vendor can gather valuable user data to ensure their products address real market needs.

The PoC also gives both parties the opportunity to evaluate the relationship. Software deployments are often long-term investments. It is thus critical to understand the culture of both parties. The pharmaceutical company learns how well the vendor understands the domain, provides service and support,and responds during inevitable conflicts (10).Vendors learn if the company is ready for digital transformation and can avoid failed projects. Well-managed PoC engagements provide access to end users and invaluable feedback, helping ensure the software caters to the actual needs the users. Vendors are also able to gain empathy for the end users, which can be translated to the software development team so that software is built with the end user’s experience at the centre of design.

The first step of the PoC involves mapping and documenting current processes. This step sets the baseline for all success metrics. For this project, the team identified all personas impacted by the technology and found key staff to interview for each persona. Empathy maps (Figure 2) were developed to capture what the users “say, think, do, and feel” (12). For this project, the maps helped align the RSS technical team with the users’ experience.

To limit scope, the team focused on the following areas of operations for the NIBR SS team:

• Study design
• Resource scheduling
• Data collection
• Tissue and fluid collection
• Aggregation and reporting

As part of process mapping, the team documented process inefficiencies, such as time lost during data lock-out, unnecessary application interactions, and multi-user contention issues. Where possible, processes were timed and the resources required were documented, along with how those resources were positioned in physical space. For example, resource scheduling might require a conference room and members of the study team to be in the same physical space. The future system may allow participants to work from their office or remotely, the latter being a significant metric for teams working through a pandemic outbreak.

The next deliverables of the PoC were current and future-state process maps (Figure 3). In this effort, the team considered the potential of the proposed new technologies to eliminatewaste and improve processes. Toward this end, a series of persona-based interviews and jobs to be doneworkshops were conducted to map out key tasks and jobs required of the end user (4).  These interviews facilitated development of ideal future state digital transformation processes, with key performance indicator (KPI) expectations.  For example, the new technology is projected to speed up the study design and scheduling process by as much as 70%. In future phases, we could test measurable outcomes against these projections.

Phase 2: Prototype

The Prototype phase is highly iterative. It is an opportunity to develop and test ideas while rapidly improving the design. Design teams and users conduct hands-on conference room tests and the design team shadows user processes to better understand their feedback.  In the PoC phase, it is determined if the product could work for the needs of the stakeholders. In the Prototype phase we determine how the application would work.

Using the artifacts gathered in the PoC, process maps, empathy maps, data aggregated from user interviews and shadowing, and jobs to be doneworkshops, the team identified missing functionality as well as opportunities to enhance existing functionality. Additional interviews, shadowing, and workshops were performed as needed for further clarification. Lo fidelity (Lo-Fi) mockups (Figure 4) were created and reviewed with stakeholders for iterative feedback.

In this phase, RSS also collaborated with several other academic and pharma research organisations. The goal was to gather data from a broad group of stakeholders to minimise organisational bias and draw in ideas from a spectrum of creative people with similar but independent experiences. The group of collaborators included a large public biotech, two small biotechs, and a very large academic research group. Each of the selected organisations had similar pain points, desired similar functionality, and were willing to commit resources to assist in this Prototype design phase.

This process of involving multiple organisations added significant time to the Prototype phase and required additional resources. It required harmonising ideas and, in many cases, rejecting input that was too specific to a single group’s process. However, partnering with multiple organisations benefited all parties. RSS captured voice of the market data, essential for product/market fit, while customers had access to software designed with the creative input from a broad group of highly skilled experts.

To finish this Prototype phase, the solution vendor must develop a minimal but realistic version of the functionality.  Final high fidelity (Hi-Fi) mock-ups (Figure 5) were presented to RockStep’s development team, along with acceptance criteria for the functionality. Empathy-based use cases were also presented, ensuring the development team considered the end user experience at all stages of development.

The process of creating a technology solution, that is user inspired, is iterative. For this project, the RSS software team developed functionality to meet minimum requirements and released the software to a user acceptance testing (UAT) environment. User participants tested the functionality and provided feedback on the user experience.  Working in two-week agile development sprint cycles, the development team iterated with regular releases to UAT until the functionality was deemed ready for release.

The RSS design team also loaded sample stakeholder data and study designs into the UAT environment and walked through specific user use cases to compare current processes versus how they would be performed in Climb 2.0.

By the end of this phase, the users had hands on experience with how the system would work. They had tested the system with limited data and scripted use cases, and they had a good feel for how Climb would function in their daily workflow. Because their input was driving the system design, they also ownedthe solution, which helped accelerate adoption.

Phase 3: Pilot

The pilot phase gives end users a chance to interact with the software for an extended but fixed portion of time.  This phase is a rehearsal for production.  Implementation, including integration plans, training documentation and media files, and measured metrics are artifacts of this phase.

To maximise chances of success, RSS and NIBR SS created a project plan, with a Gantt chart to track milestones and progress checkpoints, and a communication framework including online trainings and communication channels for feedback. For the period of one month, NIBR management approved sufficient time for end users to fully test the software.

While in the PoC and prototype phases, users interacted with and tested specific areas of functionality, in the pilot they tested the product end to end in their work environment. Users evaluated the fit of Climb 2.0 (6) for functionality across roles, as well as the overall UX. In preparation for production deployment, the team tested the integration capability with other onsite applications by implementing a minimal viable integration to prove the application would work in the NIBR LAS informatics ecosystem.

During this phase, RSS conducted usability testing of newly-redesigned study outline and design screens.  This was an important part of the pilot phase, as end user experiences are key to user adoption in production. Users were asked to set-up the same study type from design and cohort enrolment to scheduling. RSS interviewers followed the Facilitator Guide from the UXLS toolkit (4),and users were chosen from different roles and with different levels of technology savviness.

Results of the usability testing showed consistency among areas deemed intuitive and easy to use, such as bulk fill down and drag and drop options.  However, 100% of testers struggled with one task in the study design process. The design process from the prototype phase was repeated, with several iterations of mockups and development. While this change was a major undertaking to change the user interface (UI), the resulting workflow was deemed highly intuitive and efficient in subsequent usability testing.

Additionally, users had ideas for increasing efficiency for more complex studies. Since these were simple changes, new functionality was released to UAT before the end of the pilot phase.

After each major iteration of the study design screen, different users, all within in vivoroles, participated in a survey called a system usability scale (SUS) (13).  As shown in Figure 6, minor changes to the functionality slightly improved the usability score in Round 2. However after the major UI and process flow changes were made, the usability scores significantly increased to a grade equivalent of “A”. This process demonstrated how partnering with users, RSS produced a product that was significantly more intuitive.

In addition to SUS scores, data are collected to measure the success metrics developed in the PoC phase. If the new system does not align with the success metrics, a decision must be made to halt, delay and improve, or change the definition of success. In this project, Climb™ exceeded metrics in five of the eight critical areas measure and met expectations in the remaining three, and the team felt that pilot was successfully completed.

Phase 4: Production

After a successful pilot, the product is nearly ready for production release. In this phase nonfunctional requirements are addressed, such as deployment architectures, SLAs, and cost structures.

A transition plan is developed that includes integrations with internal and external systems, data migrations, and user training.

Conclusion

Life sciences laboratory workflows are inherently complex, constantly changing, and difficult to model in software. Successful solutions deliver a positive user experience while improving work quality and efficiency. Most software solutions fail to deliver and thus suffer from poor user adoption (14).

In this article the authors presented a successful case study by which the software vendor and the user community engaged in a partnership aimed at creating a solution for complex in vivo laboratory processes (8).The team developed a 4P process which engaged the vendor and users in a partnership with user empathy central at all phases from design to deployment.  The team developed KPIs to measure success and used the Pistoia Alliance UXLS tool kit as a guide at key phases in the process.  The final product, Climb 2.0 exceeded expectations at five of the eight KPIs and met expectations on the remaining three.

The methodical approach taken for this successful project required diligent adherence to process and commitment over a 12-month time span. The authors advocate that this process is repeatable and increases the likelihood of success for crucial pharma life sciences projects.

Dean Morton¹, Charles Donnelly², Austin Lanham¹, Julie Morrison², Szczepan W. Baran VMD, MS³

¹ Study Support, Laboratory Animal Services, Scientific Operations, Novartis Institutes for BioMedical Research (NIBR), Inc., Cambridge, MA, USA, ² RockStep Solutions, Inc., Portland, ME, USA,

³ Emerging Technologies, Laboratory Animal Services, Scientific Operations, Novartis Institutes for BioMedical Research (NIBR), Inc.,

About the authors

Dean Moreton is Manager of the Study Support Team within Novartis Institutes for Biomedical Research Cambridge. Operated within the industry for over 30 years joining Novartis in 2010, implementing digital solutions to transform operational process to deliver first in class science to our partnered customer base and supporting functions.

Chuck Donnelly is CEO and Co-founder of RockStep Solutions, a life sciences informatics company. Prior to RockStep, Chuck was Director of Computational Sciences at the Jackson Laboratory. In his work with RockStep, Chuck received several innovation awards from the NIH to help drive digital transformations into in vivo drug discovery.

Austin Lanham has been an Associate in the Study Support Department at Novartis Institutes for Biomedical Research since 2015. Before that, he was in a similar role at Charles River Laboratories. Driving methods for better communication and administration within the discovery space.

Julie Morrison is President and Co-founder of RockStep Solutions, where she developed and implemented user centred design practices central to the company’s product development. Driven by a passion for UX, she continues to lead efforts to improve vendor-biopharma relationships.

Szczepan Baran is a comparative medicine veterinarian & scientists turned technology geek who currently heads Global Emerging Technologies (GET) within LAS/SO at Novartis Institutes for Biomedical Research. He leads development and implementation of strategic vision for emerging technologies to optimise non-clinical models of efficacy, mechanism, and safety to improve endpoint prediction, reproducibility and clinical translation. In this role, he also leads technology evaluation & qualification efforts for drug development & medical use.

References

1. Paula de Matos.Pharma iQ:https://www.pharma-iq.com/informatics/articles/want-better-science-then-we-need-better-user-experiences
2. Jacek Ziemski, Simon Fortenbacher, James Hoeksma, Jan Taubert, Roger Attrill, Paula de Matos, Andre Richter, Julie Morrison. Drug Discovery World. https://www.ddw-online.com/informatics/p323450-evolution-of-user-experience-for-life-sciences.html
3. Pistoia Alliance UXLS project: https://www.pistoiaalliance.org/projects/current-projects/user-experience-for-life-sciences/
4. Climb™ 2.0 Tour: https://www.rockstepsolutions.com/tour/
5. RockStep Solutions: https://www.rockstepsolutions.com/
6. Hank Barnes, Michael Maziarka. Gartner (G00320956):Tech Go-to-Market: Enterprise Technology Customers Want the ‘After-Sales’ Experience Before They Buy
7. Michael Shanler. Gartner (G00382422): Life Science CIOs Need to Improve Their Organization’s Digital Partnerability
8. Sarah Gibbons, Nielsen Norman Group:  https://www.nngroup.com/articles/empathy-mapping/
9. SUS Scores: https://www.usability.gov/how-to-and-tools/methods/system-usability-scale.html
10. Josh Fruhlinger, Thomas Wailgum, Peter Sayer.CIO: https://www.cio.com/article/2429865/enterprise-resource-planning-10-famous-erp-disasters-dustups-and-disappointments.html

Image: Campaign Creators