WinPREP is now released and undergoing testing with customers. It is anticipated that further UX improvements will be made to the product based on the UX recommendation I, and other teammates made to the team. It adopts the Revvity design system and it works in conjunction with the Fontus system, which is a life sciences laboratory hardware.

↓ We’re very fortunate to see the product in person working seamlessly with the hardware. ↓

• Initial Analysis:  We set up a 3-in-a-box meeting with the product manager, proxy user and software developers to understand the context of the problem, the requirements and the timeline. This was my first time working with a product team, thus understanding stakeholders’ priorities and listening to other people was my strategy in understanding the context.
• User Research:  By speaking with proxy users and subject matter experts, we understood the general procedure and logic behind the application. The team also interviewed users to uncover pain points with the current application and incorporated the voice of customers into the product. An interesting finding here would be that, while internal stakeholders thought the placeholder element in the home page was redundant, we got to understand that users appreciated the placeholder element as it made them feel at ease while using the application.

The WinPREP software had to be rebranded according to the Revvity new branding. Based on the user research we have done,  I first gathered relevant components in the design system that would align with the users’ mental model while using the application. Building out screens using components is an efficient way to build out designs and manage the designs for future changes and scalability.

One caveat in incorporating the Revvity Branding into the product was the use of the Revvity Yellow brand colour. Yellow is a semantic colour which often signifies warnings. Through an iterative approach and testing, we designed the UI with minimal yellow colour usage while still maintaining the branding consistency across the application.

• Product Develop Cycle: Due to the urgency of rebranding, I had to work with product managers and the development team to work around their code-freeze period. Therefore, we utilized this opportunity to not only revamp the UI of the product but also incorporate as many UX improvements as possible to maximize our impact.
• Adaptation and Learning:  A product can have a huge range of stakeholders. Working with stakeholders,     such as users, developers, and product managers all at once can prove to  be challenging. As a designer, weighing between different opinions and options, prioritizing action items and counter-proposing solutions are useful skillsets to have.
• Design Iteratively: Due to time and resources constraints, some design recommendations have to be    parked for the next development cycle, we iteratively design an interim solution to meet the development timeline for this cycle.

Due to development and time constraints, several iterative improvements and UX recommendations that were made were not actually incorporated in the final shipped product. This was the result of product development realities. These iterations are still valuable and have become functions that are being considered for future development cycles to be implemented.

The first iteration included the UX recommendation for enhancing system status indication.

In research, we found that 90% of the users thought that the current system lacked step indicators, and users felt lost while the application was running. That translated into a design feature to use step wizards to indicate the step system is in.

Also, in research, we found that the majority of the users thought that the current system lacked an indicator of how much time is left in the experiment run, thus they lacked a way to help them plan lab tasks. That translated into a design feature to use a progress bar to indicate how much time is left.

The second iteration is also in the domain of enhancing system feedback indication, particularly error feedback.

In research, we found that all lab technicians are not necessarily stationed in one place in the lab while running experiments. They often let the machines operate and look at the software from afar while they work on another machine. That particular user need was translated into a design feature to include some error messages in more than one place and include error indicators always in the header.