Facilitating synthetic biology execution
Mission Control
Mission Control is enterprise software designed for Ginkgo Bioworks to enable the execution of client driven synthetic biology R&D projects.
Planning spreadsheet
Order management system
PL’s then must track the progress of their individual orders within the same ordering system using a table which displays all of the orders across all the active projects across the whole company.
Each internal lab has different formats of data to return and are stored in various software around the Ginkgo environment.
Each project can include an average of 4 deliverables, each deliverable can contain many modules. Modules have many tasks and each task can be associated with many experimental orders.
Goal
Decrease the time spent for PL’s during the execution stage of a project spent on ordering and tracking the progress of orders.
Decrease the time spent searching for data files from internal labs.
Decrease back-and-forth communication.
Increase the time PL’s can spend on actual analysis of scientific results and running more projects.
Currently a single PL can oversee 1-3 projects at time, Mission Control will allow Ginkgo Bioworks to scale with the goal of PL’s overseeing +10 projects at a time.
Challenge
End user
Project Leads (PL’s), who are responsible for leading the scientific effort and the success of reaching client goals and deliverables.
The problem
PL’s must plan their hypothesis into organized distinct scientific tasks to reach client deliverables in a spreadsheet to enable the business to capacity plan and forecast.
PL’s then must use a separate order management system to place orders to various internal labs to run experiments; experiments can be stand-alone and non-dependent or strung together into modules where downstream experiments are dependent on upstream results. Also depending on the exact parameters of an experiment and time considerations, experiments are often run in parallel.
Solution
A single view where Project Leads can see their project plans along side the orders of experiments that are running in the lab or queued up. Before Mission Control, this would be a manual process for PL’s to keep track of the progress of all the lab experiments to compare with the planned timelines, and then would have to make adjustments in two different places if there was a delay.
The value added is a contextual view of all of the experimental orders, this enables the user to see upstream and downstream of a project and to see dependencies. Mission Control is able to read from the planning spreadsheet, so the back-end would be able to find and assign experiment orders to tasks to allow users to bulk create orders instead of manually searching and finding orders and placing them individually in the current system.
One surprise benefit we learned after the MVP was deployed, the interface gave a single view to the whole project team, as other members of the team would request orders and the MC interface automatically found and associated them to the correct task!
“This will solve and remove a lot of the cognitive workload for a PL.”
“This will save me hours every week”
“Instead of going into Servicely and creating orders individually, this is a blessing”
Results
Metrics
1 Week after MVP release
50 out of 151 active projects have opted into using the Mission Control interface
1 Month after MVP release
71 projects out of 151 active projects have opted into using the Mission Control interface, with projects spanning across different domains: microbial, agricultural, and mammalian
49 unique PL’s have onboarded their projects
48 unique customer projects are now being tracked on Mission Control
Web stats
Unique users: 110
Session trends: 18.9% increase (rolling average)
Users trends: 14.3% increase (rolling average)
Funnel tracking of order creation: 78% conversion rate with average time of 24 seconds.
Learnings
Staying aligned to project timelines and mitigating any deviation from the estimated timeline is a huge pain point for PL’s when managing client driven projects. There are many steps along the process where delays can occur, we’ve only address a handful in our MVP and have seen added value for our users. The team will uncover more points of delay once they start to integrate with other pieces of internal software to give the PL’s this single view of executing a project.
Planning and execution of scientific projects go hand-in-hand. Downstream parts of a project rely on upstream parts to produce positive results or the remaining plan must change. So it’s hard to isolate execution from planning and there is still a need to go back and forth between the two pieces of software that enable each step. The team must reach parity in the Mission Control tool with the current planning processes if it wants to build an all inclusive tool for the PL’s.
Next steps
Design an Alerts and Notifications user experience to focus the PL’s attention to the area of most need.
Integrate Mission Control with other pieces of internal software a PL must interactive with for project execution and learn what are the essential pieces of information a PL needs to make decisions for each integration.
Remove the burden for the PL of having to navigate many pieces of software to find resources associated with a project: non-standard forms of communication, resources and documents, and data returns.
Keep iterating on the design to be able to surface all valuable information in the UI while balancing information hierarchy and clutter.
Process
Team
2 Project managers, 1 Engineering manager, 5 Engineers, 1 Designer
User research: Workshop
Initial discovery research goal was to define a consensus workflow that mapped out the process and steps of a synthetic biology DBTL (Design, Build, Test, Learn) cycle, this would simulate a single module of work. I ran multiple workshops that include 3-4 PL’s each. The format of the workshop was for each PL to spend a few minutes mapping their own steps of tasks, communication needs and software needs for each step through a the cycle. Then the group would come together to create an agreed upon workflow, this step was for the purpose of capturing all the use cases and identifying where in the process PL’s needed to complete similar tasks.
Workshop template
Project lead DBTL cycle processes
Capturing PL’s user flow
Grouped DBTL cycle
What we learned is that PL’s spent a lot of their time communicating with individual lab members running their “Ordered” experiments to define the work, to check on progress and status, to find relevant information or data and to discuss the quality of the work.
Obtained further evidence to support:
There were many forms of communication
The project information was lost in the noise
The project information was hard to find
New findings:
There was more communication needed with the labs than previously known
There was more prep work for PL’s to work with each lab and to handoff data between labs
Identified specific pain points for scheduling work and handing off work
I then created a very simplified workflow of the DBTL process and outline what parts of the Mission Control tool could apply and add value to the process.
Focused interviews
For the next round of research I wanted to focus in on a single order to answer questions of the specific types of the information that a PL’s needs during the execution phase and when they need it. PL’s, themselves have informational needs when running a project but they are a central hub at Ginkgo, so they’re responsible for reporting out project status to many parts of the company. So, I focused the questions around information needs for themselves, the immediate team and for teams across the organization and what are the specific need for each team.
I also wanted to learn about more of the temporal context of these needs, what information is needed before, during and after the execution of an order. This will inform what the UI should surface and display and when, to only display the most essential information so we’re not cluttering the interface with too much noise.
Demographics
8 Projects Leads (PL’s)
Some PL’s who worked on project independently, some PL’s led a team, some PL’s were parts of other teams, and a combination of all 3.
The range of currently managed projects were between 2-4.
The range of experience was between 17-126 months at Ginkgo.
Analysis
The analysis consisted of tagging all the hour long interviews with the existing team defined research tags but I also added some custom tags to keep track of specific needs from our Project managers.
Example of a tagged interview
Analysis of Pain points
Analysis of User needs`
Synthesis
How Project Lead’s defined their role
Managing the information flow between people
My role is to enable the other people to do what they're supposed to do
Current consensus workflow
After importing all the tagged statements onto a board, I started to aligning the tagged statements from each user to start to map out their user flows. I then created a current consensus workflow.
I then asked all the users that I interviewed to review the workflow to see if I captured everything correctly and asked if they would make edits or add comments. I also asked the users to define where in the workflow delays might occur and the types of delays that regularly happen. I then created a current consensus workflow to share with the team.
Next, I synthesized the user needs and pain points and mapped the themes along the workflow, here are a few examples I highlighted for the team.
Then I mapped ontop of the workflow the most common delay and the steps need to remedy the issue.
I then mapped out all the steps in the workflow where a delay can occur to show the points of risk.
User needs
Gauging process against the estimated timeline
Mitigating risk against timelines
Visibility into lab-to-lab hand-offs
A single repo to collect project information for future reference
Pain points
Unpredictable turn around times
No notification of delays
Hard to keep planning spreadsheet and order management system in sync
Hard to see discrepancies between spreadsheets and order management system
Design
The benefit of having internal users is that I’m able to quickly get user feedback, from early concepts and wireframes to high fidelity designs. I can review with users and then draft recommendations and concepts to meet with the engineering team to see what solutions are viable, balancing value and development cost.
Starting to visually refine an “Order” and the informational needs.
Testing what simple scientific workflows would visually look like with considering of screen dimensions and experience.
Refining navigation.
Further refinement of informational needs for each order with dependencies on temporal context.
Example of building out a clickable prototype for A+B testing.
Early visualization glyph concepts for scan-ability of progress.
Concepts of what information would be useful for an order.
Defining the user interactions and functional requirements.
Early concepts of thinking through validations of hand-offs between labs as i/o needs.
Decided on a vertical view to avoid horizontal scrolling and applying it to the workspace.
Exploring interactions within the workspace and interactions for an “order”
Testing
Here are two examples of the types of user testing we ran pre and post release of the MVP. We ran UAT sessions beforehand to test the use cases that we had designed and to get feedback to see if we missed any edge cases that would be essential for success of the MVP.
Pre-release UAT
Use cases
As a Program Lead, when I open my project page, I can see all deliverables and modules defined in my PPSS in that workspace, reflecting the ordering of these rows in my PPSS. I can see both the row name and module selection (for module rows) for these deliverables and modules.
As a Program Lead, I can view all Servicely orders associated with a module via the Project Plan Linkages section of Servicely orders. Any orders directly associated to an offering row are visible under that row in Mission Control. I can find and click on the Servicely link to any module/offering-row associated order in Mission Control.
As a Program Lead, I can save time by creating orders through Mission Control and relying on it to automatically filled in both the module and offering fields of the Project Plan Linkage section of Servicely orders.
As a Program Lead, I can quickly identify if there are Servicely orders associated with the module that do not have an offering row association and take action in MC to add that association.
Session
We watched users run through the use cases
Noted if users Passed or Failed, then asked for feedback and comments
Then asked for an overall Go/No Go - Pass/Failed assessment
We got the Ok to release the MVP if we added some minor interactions, such as fixing terminology, giving the users the ability to hide paused orders, and visually adding an hierarchy group to the view.
Post-release Usability
The usability sessions are a team effort, everyone is invited to participate to increase empathy for the user throughout the team and also during the synthesis session we can come to agreement for post release development quicker.
We ran the user through similar use case as the UAT test, and everyone jot down notes in the spreadsheet.
Blockers
Other errors, struggles, & pain points
Opportunities
Observations & other relevant things you saw the participant do or talk about
Positive comments, task successes, and other things that went well
We then took all the individual nots and synthesized into high levels
We took the pain points themes and mapped them on a grid of Impact vs Effort
The last step was to come up with solutions for each of the pain points.
Metrics
I then configured a Fullstory dashboard to capture key metrics, we also added inline tags on buttons and links to track specific interactions.