Quartzy is an application created by two doctors when they realized how chaotic life-science laboratories are.
Many labs were still using whiteboards and inventory spreadsheets. Quartzy was built to modernize these experiences, later expanding to include a shop.
Increase orders placed with Quartzy.
Our customers are creating orders, but are potentially missing out on the benefits from ordering from us.
Increase purchases made through Quartzy.
Customers should be able to understand what Quartzy offers, and (ideally) buy from us based on that information.
Do no harm. No complaints, no wrong items.
No customer support tickets about incorrect purchase from the changes we introduce
Quartzy operates on quarterly OKRs during which pods had to balance multiple product priorities.
The timeline was four weeks for discovery, design, and development to launch to a select group of customers.
As the Lead Designer and Researcher, I interviewed customers to understand their workflows, observe their behaviors, and to create something they trusted, understood, and that demonstrated our business value.
During the design process, I gathered stakeholders (CEO, VP of Product, and Engineering Leads) in order to keep everyone updated.
Once we reached a decision, I worked with the engineers to get our solution implemented and in our customer’s hands on-time.
The same product is identified in many different ways, and most researchers didn’t realize this. When a researcher puts in a request for an item, they don’t want to risk their experiments failing because one item was slightly different. Many were wary of any unfamiliar items, and this design needed to convince them when these items were actually the same.
In short:
Researchers were missing out on items we had that they wanted, sometimes for a better price, quicker delivery, in small quantities, etc.
Quartzy originally attempted to solve for this by presented information about the same (or very similar) item to users after a request is made. This feature had very low usage and generated some customer complaints for several reasons.
The green banner is Quartzy’s attempt to convert a purchase from a competitor.
In-lab observations and feedback
Researchers:
Multitaskers balancing experiments all over the lab.
Would see that an item was low, rush to their desk to request it, and quickly return to their experiments.
Rarely at their desk longer than the time needed to request an item.
Lab Managers:
Handle administrative tasks, deliveries, and ad-hoc verbal requests for items.
Review and approve requests to keep the lab supplied. They were constantly interrupted, making it difficult to complete tasks.
When a researcher asked for an item, Lab Managers were very reluctant to override the request.
Looking at user behavior in customer labs along with our data of customer behavior in general I identified the optimal place within the app to showcase Quartzy’s item if one is available.
User flow, highlighting the optimal place to inform users about Quartzy’s item,
The existing form where “Request Details” are added.
Considering our timeline, I went to the engineering team to discuss our technical options and constraints to make sure we meet our deadline. They identified some existing data structures we could utilize for the sake of speed. I also worked with them to make sure we showed a label matching the customer input rather than highlighting the manufacturer name.
Idea of adding a notification style presentation to highlight an item.
Idea of adding a banner to the bottom of the form when an item is available.
Idea of adding a banner inline with the pertinent content when an item is available.
Wireframe of the notification idea
Wireframe of the bottom banner idea
Wireframe of the inline banner idea
I proposed a design based on the following:
Catch users at a critical moment: right before submitting a request.
Easily scannable information, where they are already looking, as obviously as possible.
Engineering needed the user’s product information first. With this and performance in mind, we could show our identical item best here.
Paired with a bottom banner, I aimed to catch quick-scrolling users looking to return their experiments ASAP.
Final design with a focus on the inline banner. The bottom banner was added to catch users that were moving through the flow much quicker than anticipated.
We were able to implement our changes, launch to a subset of labs, and monitor the effects.
After 2 weeks of a positive trend we launched to all labs and were able to meet our key result for this project.
The increase in sales held up throughout the remainder of the year, indicating that our changes had a lasting impact.
Increase purchases of items through Quartzy
Isolating the data for this flow we saw a >5% increase in Quartzy selection, meeting our key metric.
Do no harm. No complaints, no wrong items.
We saw no new tickets related to this feature. Of the orders placed, the items surfaced were of the same expected quality, and created repeat orders signaling item satisfaction. Users, at first, took more time on this page to review the new design. After initial exposure, this design did not slow down or confuse users workflows or orders.
Design & Engineering Improvements:
Reformat request table; remove extraneous elements
Faster loading times
Improve Visual Design System
Opportunities I saw:
How could we use this for multiple requests?
Could we pre-select items based on lab behavior?
What if we made a chrome plugin that would allow researchers to generate requests from different vendor pages?
Mockup of a Chrome extension that would identify items to request.
This was an interesting idea — allow researchers to quickly make a request once they find the product they’re searching for elsewhere. This lined up with their behaviors. Ultimately we did not go down this route - customers were usually unable to install extensions on work stations because of security concerns.