Automata

B2B / Enterprise Platform redesign

Role: Lead Designer

Evolving the software that controls automation of science labs.

Automata revolutionise science labs by leveraging robotics to streamline experiments, enhance reproducibility, and increase testing throughput.

My role was to lead the evolution of the software which controls the robotics focusing on starting an experiement. 

Evolving the software that controls automation of science labs.

Automata revolutionise science labs by leveraging robotics to streamline experiments, enhance reproducibility, and increase testing throughput.

My role was to lead the evolution of the software which controls the robotics focusing on starting an experiement. 

Key achievements.

Key achievements

1

1

Simplified a complex B2B system in to a customer facing application for Scientists and Lab Managers. 

Simplified a complex B2B system in to a customer facing application for Scientists and Lab Managers. 

2

Implemented a 3 amigos (Product, Engineering, Design) way of working, transforming how we built products.

Implemented a 3 amigos (Product, Engineering, Design) way of working, transforming how we built products.

the science lab

the hardware controlled by the software

The software enables Scientists to create experiements called a 'workflow', which includes selecting instruments (incubators, centrifuges etc) and inputting timings and other parameters. 

Based on these parameters the software controls the robotic arms and moves plates containing samples for testing, between the different instruments in the workflow until they are ready to be read.

This has since been deployed at the Royal Marsden hospital for cancer screening. 

my role

evolving the software that controls automation of science labs.

Automata revolutionise science labs by leveraging robotics to streamline experiments, enhance reproducibility, and increase testing throughput.

My role was to lead the evolution of the software which controls the robotics focusing on starting an experiement.

Context

software originally built by developers for developers, wasn't scalable or fit for purpose.

As our customer base expanded, it was not realistic that internal developers could continue to support the set up and deployment of all experiments on to the hardware. 

With this in mind, the software needed to change to be customer facing and these tasks be completed by a new end user. 

Context

software originally built by developers for developers, wasn't scalable or fit for purpose.

As our customer base expanded, it was not realistic that internal developers could continue to support the set up and deployment of all experiments on to the hardware. 

With this in mind, the software needed to change to be customer facing and these tasks be completed by a new end user. 

problem

Software was unusable even by internal staff, impacting sales.

After speaking with interal growth and sales teams we discovered they were not able to demo the platform to potential customers. They were confused by how it worked and actively avoided discussing it. 


There were 3 key issues: 

  • No linear journey: No clear next best action guiding you through the experience. 
  • Siloed areas: Related functionality was split between different areas. Required manual navigation to different sections to pull in information created in other areas. Highly unintuitive. 
  • Too much flexibility: Platform was built for lab set ups (scenairos) that our customers did not need.

Overall the mental model of the users was vastly different from how the software was structured which was more of a reflection of how developers viewed the platform and was not user centric. 

problem

Software was unusable even by internal staff, impacting sales.

After speaking with interal growth and sales teams we discovered they were not able to demo the platform to potential customers. They were confused by how it worked and actively avoided discussing it. 


There were 3 key issues: 

  • No linear journey: No clear next best action guiding you through the experience. 
  • Siloed areas: Related functionality was split between different areas. Required manual navigation to different sections to pull in information created in other areas. 
  • Too much flexibility: Platform was built for lab set ups (scenairos) that our customers did not need.

Overall the mental model of the users was vastly different from how the software was structured which was more of a reflection of how developers viewed the platform and was not user centric. 

design principle

Speak the language of our users.

The software was orignally created by developers for developers, so we wanted to start changing the historical way teams thought building the software by adhering to 1 core design principle. 

There were 3 key ways we thought we could speak to this principle, and we leveraged these to influence Product and Engineering to a more user-centred approach to the software. 


Taking a step back

taking a step back to consider the correct hierarchy of the siloed areas and how they link together more logically. 

To better understand the siloed areas, and try to create a focus around the core Workflow (experiment flow), I took a step back to consider each part. 


Taking a step back

taking a step back to consider the correct hierarchy of the siloed areas and how they link together more logically. 

To better understand the siloed areas, and try to create a focus around the core Workflow (experiment flow), I took a step back to consider each part. 


Automata image_placeholder

holistic exploration

Creating a simple, holistic view of the new mental model. 

I created an abstracted, holistic design to bring this new mental model to life. This helped for initial conversations within the cross-functional squad. 

Working more abstractively enabled greated exploration around solving the problem and reimagining the experience, without getting tied in to detailed wireframes. 


extended this thinking across devices for error handling scenarios.

Considering the aim was for Scientists and Lab Managers to spend less time in the lab itself, it was paramount that they had trust and confidence the experiment was running without error. 

I explored how we could use other devices to proactively alert these users to potential issues.

This outlined what content would be shown by default vs progressive disclose across smaller devices, i.e. what was more critical for these users to view. 


extended this thinking across devices for error handling scenarios.

Considering the aim was for Scientists and Lab Managers to spend less time in the lab itself, it was paramount that they had trust and confidence the experiment was running without error. 

I explored how we could use other devices to proactively alert these users to potential issues.

This outlined what content would be shown by default vs progressive disclose across smaller devices, i.e. what was more critical for these users to view. 


Errors anywhere, anytime 10
Errors anywhere, anytime 12
Errors anywhere, anytime 9
Errors anywhere, anytime 11

sizing the restructure

restructuring the software required significant changes.

Based on the desired structure, initial flows were worked out to understand how much the existing platform needed to change in order to match the new model. 

 

Workflow

scoping

User story definition and wireframes

To ensure we were covering the core journeys I converted required user scenarios in to user stories. 

Frame 1818

Wireframing

Wireframes based on user stories created focus on key journeys

All user stories and journeys were played back to stakeholders to serve 3 purposes: 

  1. Validate these were the right user stories. 

  2. Identify more user stories. 

  3. Gather feedback on journey specifics and identify potential improvements. 

  4. Team alignment and convergence on direction and future of the experience.

Wireframing

Wireframes based on user stories created focus on key journeys

All user stories and journeys were played back to stakeholders to serve 3 purposes: 

  1. Validate these were the right user stories. 

  2. Identify more user stories. 

  3. Gather feedback on journey specifics and identify potential improvements. 

  4. Team alignment and convergence on direction and future of the experience.

validation

user testing with internal team. 

As these were wholesale changes to the software I conducted high level validation sessions with various internal colleagues including:

  1. Field Application Scientists (ex Lab Scientists). 

  2. Application Engineers (who work with end customers to create experiements). 

  3. Growth/Sales (who pitch to potential customers). 

Through these sessions we were able to establish at a high level that the new structure was more inline with the mental model users had previously talked through. 

Whilst we didn't conduct detailed user testing due to such large changes, we were able to gain enough confidence that these changes carried low levels of risk in order for us to start building. 

validation

user testing with internal team. 

As these were wholesale changes to the software I conducted high level validation sessions with various internal colleagues including:

  1. Field Application Scientists (ex Lab Scientists). 

  2. Application Engineers (who work with end customers to create experiements). 

  3. Growth/Sales (who pitch to potential customers). 

Through these sessions we were able to establish at a high level that the new structure was more inline with the mental model users had previously talked through. 

Whilst we didn't conduct detailed user testing due to such large changes, we were able to gain enough confidence that these changes carried low levels of risk in order for us to start building. 

planning

Creating a roadmap for the Product owner to influence the order of work.

Helped the product owner by outlining an initial approach to the order of build. This took in to account dependancies between sections and how releasing each part of the experience would still fit in with the existing experience. 

planning

Creating a roadmap for the Product owner to influence the order of work.

Helped the product owner by outlining an initial approach to the order of build. This took in to account dependancies between sections and how releasing each part of the experience would still fit in with the existing experience. 

Redesign, order of work.-1
Redesign, order of work.

integration

Achieving seamless integration with existing platforms.

As this was a large change to the software, it wasn't going to be built and deployed in one go. Therefore I looked at how releasing each part would work with the existing platform without causing more confusion. 

This enabled me to identify and communciate the reality of:

  • How fit in with legacy parts of the platform. 
  • Identify any short term ban-aids needed to ensure continued use. 

 

integration

Achieving seamless integration with existing platforms

As this was a large change to the software, it wasn't going to be built and deployed in one go. Therefore I looked at how releasing each part would work with the existing platform without causing more confusion. 

This enabled me to identify and communciate the reality of:

  • How fit in with legacy parts of the platform. 
  • Identify any short term ban-aids needed to ensure continued use. 

 

influencing

business pivot threatened the execution of finishing the build.

After a lot of the restrcuture had been built by the development team, business priorities caused a need for Product and Engineering teams to re-focus elsewhere, this threatened to halt work on the restructure. 

I had 2x sessions with Product and Engineering teams to push to finish the work. This required getting all teams to think pragmatically about the relationship between the following:

  • The value add to customers and therefore the importance of finishing the work. 

  • Understanding the reality of remaining effort required. 

Result: I convinced the Director of Product the importance of completing the build resulting in the work being finished. 

This led to the Sale team reporting an increase in sales due to an intuitive customer experience that our competitors were not able to offer. 

influencing

business pivot threatened the execution of finishing the build

After a lot of the restrcuture had been built by the development team, business priorities caused a need for Product and Engineering teams to re-focus elsewhere, this threatened to halt work on the restructure. 

I had 2x sessions with Product and Engineering teams to push to finish the work. This required getting all teams to think pragmatically about the relationship between the following:

  • The value add to customers and therefore the importance of finishing the work. 

  • Understanding the reality of remaining effort required. 

Result: I convinced the Director of Product the importance of completing the build resulting in the work being finished. 

This led to the Sale team reporting an increase in sales due to an intuitive customer experience that our competitors were not able to offer. 

final design

final visual designs for MVP build.

Final designs focusing on the Workflow as the heart of the experience enabled Sales to start leading conversations with potential clients with the intuitive user interface, rather than actively avoiding this. 

This resulted in the Sales team verbally reporting an increase in sales.

final design

final visual designs for mvp build. 

Final designs focusing on the Workflow as the heart of the experience enabled Sales to start leading conversations with potential clients with the intuitive user interface, rather than actively avoiding this. 

This resulted in the Sales team verbally reporting an increase in sales.