Lab Process Optimizer* takes instrument IOT data and centralizes it to gives labs and their scientists a real-time place to track how experiments are running.
Tracking informatics as they happen and capturing approvals for quality purposes is immeasurably important for pharmaceutical companies. At any moment, auditors from the FDA can drop in and collect paper trails on the everyday business of a lab. Many labs still have a physical paper trail. Getting approvals in large labs can also include many people, making it a time-consuming and difficult-to-track process.
In charge of the staff, lab processes and equipment.
Plans, runs and is responsible for experimental data accuracy.
The Product Development team identified that GLP (Good Lab Practices) compliance would be hugely beneficial for the marketability for this product. Here are three of the biggest challenges the team had to overcome:
- Achieving GLP compliance meant there were significant technical hurdles to overcome for data quality.
- Incorporating compliant e-signatures frequently added complexities to the user experience.
- Depending on specific labs, rules for when and how authorizations were required made customer requirements fuzzy at best.
All product releases would get started with a release planning in which our distributed team (stakeholders, engineering, design, research and product strategy) would convene in a central location for several days.
Key activities included gathering a problem statement and business requirements from the product stakeholders, and a collective brain dump of ideas for how to solve the problem. Together, the team would prioritize how best to solve the problem throughout the upcoming release in addition to giving research enough information to put a plan together.
Because of impending timelines, design and engineering needed to put a minimum viable solution together quickly. We hit the ground running with sketches and user flows.
From stakeholder communication with customer prospects, we learned about a secondary role in the approval process which was the reviewer. A reviewer needed to sign off on items of approval prior to the approver. For the simplicity of the initial technical solution, the team collectively decided to build the process flow to allow for one reviewer and one approver.
Design considerations needed to take into account that approvals could happen at many different moments throughout the lab research process, and those moments might also have to be somewhat customizable per lab. It was important to be able to overlay details about authorizations without potentially interrupting what a user was seeing on their screens. The sidebar design was born.
While design and engineering were moving ahead with version 1, Research was able to put a plan together and get moving on generative research.
While many of the team’s assumptions were deemed supported, a couple were challenged. The biggest takeaway for improvement was the rigidity of one reviewer and one approver that both needed to e-sign was not supported. Reviews in labs were found to typically be more informal, such as a scientific researcher tapping their coworker on the shoulder to take a look at something. It was also discovered that approvals in some instances could require as many as seven different signatures.
“If you’re a technician at a pharmaceutical company, you are directly responsible for everything you do that day. And you have to sign off on it. And your direct supervisor has to sign off on it at the end of every single day. So those electronic signatures are insanely important for folks.”
To move forward with Research’s recommendations, the team did two things. One, review on items prior to approval became an option for users. In this way, feedback could still be tracked in an approval but not have the heavy, required weight of the e-signature. Two, the team enabled the ability to customize the number of approvers required. Through the research cycle, it was also learned that scientific researchers are the ones who are ultimately responsible for doing their work correctly. We left it up to the user to determine how many approvers were required, and who they were.
This product epic didn’t have a perfect process, in that it would have been ideal for Research to complete a study prior to design and engineering creating the first solution. However, because Solution 1 was set up very simply, it was relatively easy to make the necessary changes in Solution 2 to fit what the team learned. This effort also required very close collaboration on the part of design and engineering in order to build an API that could accommodate for complex flows, especially when approvals became denied at any point. The end solution worked out to be a flexible system that could scale and be customized according to different customer needs.
*The name of this project has been altered to protect company IP.