Workbench Product Redesign
SaaS Product Design
Company: UL Solutions Inc.
My Role: UX Researcher and Designer
Device: Web
Audience: Internal users and SaaS clients
Timeframe: January 2023 - September 2023
Introduction
This project was carried out as part of my role as a UX researcher and designer with Underwriter’s Laboratory. This project was carried out by a team consisting of myself, several developers, and the UX team manager. In this team, I gathered the project’s requirements, brainstormed design solutions, produced and tested new designs, and presented the designs to internal stakeholders.
Workbench is an enterprise software application used to manage thousands of items, namely products and product specifications. It is used by engineers who test both industrial and consumer products to ensure they are compliant with applicable certifications and regulations. Workbench is also used by businesses to track the certification status of their goods, as well as of other goods they use in their supply chain.
The goal of this project was to design an information organization system that was dynamic and responsive on both the user side and on the back-end.
The main challenge with this project was balancing usability and visual design. We had to center the users’ experiences with the system they were familiar with as well as incorporate a suite of new features into a visually updated product.
The solution was to engage user stakeholders early and often by requesting feedback and user testing frequently. Doing this ensured that the humans using the product would be consistently engaging with the product. Their feedback was crucial to designing a system that was functional.
Stage 1: Requirement Gathering
I began the design process by interviewing internal stakeholders to identify an early idea of the needs and features desired by the users.
Requirement gathering was an iterative process that took place over the course of the entire design process. Initially, the engineering team requested an “updated information management system.” Through review of the previous system and ongoing conversations with stakeholders on the engineering team, requirements were added to the scope of the project as their needs became apparent.
These conversations were crucial in fostering a mutual understanding of the required functions of the system. Eventually, it became clear that a responsive table was necessary to host the large amount of data.
The main requirements gathered were:
The system should be responsive.
Data should be easily sorted and filtered so wading through thousands of items is seamless.
The system should follow best practices for both functionality and visual design.
Stage 2: Research
User Research
To properly focus my redesign, I had to understand both who the users are, as well as how they used the previous system. The end user consisted of in-house engineers and testing specialists that used the system to categorize and collate information about testing specifications for various industrial products. Because the users were in house, I had ample opportunity to survey them and test the system.
User Interviews
I conducted user and stakeholder interviews to establish a rough understanding of how the previous system functioned and what pain points were commonly reported by users.
“The data management systems I’ve used before have been pretty awkward to work with, and I often struggle to keep everything organized when I need to enter new information.”
“My team needs to be absolutely sure about which of our products are fully certified and which ones don’t meet regulations.”
Key interview findings:
Users often have trouble narrowing searches effectively and find the search function to not be robust enough
The previous system lacked a filter feature and did not have any means of manipulating data (sorting high to low, recent to old, etc.)
Filter features would allow the user to search for data by name and then narrow further using alternative qualifiers
The current communication features of the system was rudimentary and did not allow for tagging other users or sending data directly without a multi-step export process
User Survey
I designed a survey to collect quantitative data and to screen for users who could provide valuable insights during the interview study. I sought to understand how users interacted with the system they currently used, what features were most valuable, as well as understand the goals of the users.
Use Cases
Search Methodology
Key survey findings
Users mainly used the system to find existing information and log new testing data
When searching for data, users typically searched by item name or the type of certification
Users very rarely used the system for supply chain management and almost never searched for data by country, however they often searched by certification type
Respondents who indicated that they searched by author were exclusively UL testing engineers and not end users of the system as a SaaS product
Personas
I used the results from the survey and from user interviews to create personas representative of common types of users.
Participants indicated how they use their current data management system. Significant use cases are:
19/25 use the system for recording testing data
12/25 use the system to look up existing data
25/25 use the system to communicate testing results or other findings to their peers
2/25 use the system for supply chain management
All users indicated that they used the system to look up existing testing and certification data. The ways in which the users searched for the data are:
25/25 users indicated that they often searched by item name
16/25 indicated that they often searched by certification type
2/25 indicated they often searched by country
8/25 indicated they often searched by author
Heuristic Analysis
I then completed a heuristic analysis to establish strong and weak points of the previous design (design recreated above with information redacted).
Brief Summary:
The visual design of the previous system was cluttered and outdated and needed to be redesigned
The previous system lacked robust controls for the user to adequately sift through large amounts of data
The previous system provided very few guides or documentation to assist users in navigation
Further Research
Further research of data table best practices and a competitive analysis of systems that employ successful tables revealed the following features as being highly helpful to users.
Common Dynamic Table Features:
Fixed headers
Horizontal Scroll
Resizable columns
Variable display density
Pagination
Hover Actions
Inline editing
Searchable columns
Expandable rows
Quick views/Modals
Sortable columns
Filtering
Early in the process, conversations with the end user proved invaluable in fostering mutual understanding. The end user team was strongly considering a table with vertical, rather than horizontal scrolling (think an excel document with reversed axes).
After exploring the prospect and researching alternatives to conventional table design, we were able to agree on using the conventional industry best practice for data table organization. Research and communication were essential to bridging the gap between the system and the user and ultimately allowed for a greater understanding of the end user’s needs. Ultimately, the volume of items that needed to be organized made the decision to use horizontal scrolling apparent.
Finally, I reviewed common table design patterns to gather inspiration for the look and feel of our system.
Stage 3: Design
I used the data gathered through user testing and competitive analyses to establish two separate user flows based on the two primary use cases.
The first user flow reflects behaviors by end users at 3rd party companies who use Workbench to certify their products.
SaaS - Certify Product User Flow
Wireframes and Prototypes
I first wireframed the end user’s view of the system, early wireframes contained new features:
Advanced filtering in a collapsible menu
Certification guide in right rail
Expandable rows
Sortable columns
User feedback indicated the following:
Strengths
Design was clear and status was visible
Increased control over filtering was helpful
Sortable columns were helpful
Pain Points
The users had difficulty remembering what filters they used and had to keep opening and closing the collapsing menu to check them
The users did not find the expandable rows useful
The table was not big enough horizontally to capture all of the information that would be included for each item
I took this feedback into account during following wireframes and, after review by users and stakeholders, created higher fidelity prototypes of the system that incorporated user feedback.
Features included:
Collapsible menu was turned into a static filter menu
Added ability to save and view past search/filter configurations
Added ability to change number of results per page
Moved the “certify new product” user flow into a modal to save space
Incorporated a horizontal scrolling table to accommodate large volume of data
Resizable columns
Visual design was kept minimal so the UI would be uncluttered. Because the main function of the system is to accurately and efficiently store and sort data, signifiers indicating the system’s affordances were made the focus of an otherwise minimal product.
This mockup employs a tabbed container that displays completed steps
This mockup uses a tracker above the information container and shows progression similarly
User feedback indicated the following:
Strengths
Ability to search, save and return to in-progress certifications allowed users flexibility
Tracking progress through the steps was an improvement to the previous system, which did not show progress status
Visual update allowed for greater clarity and recognition of key features
Pain Points
Users expressed that the second progress tracker was clearer to them
Users were unsure of which certifications were new, in progress, or completed
The final prototype screens added icons to the certification request menu indicating whether a certification request was new, in progress, or complete.
Additionally, engineers can select “search existing products” and view the same data system as SaaS users with the key distinction that UL engineers can edit existing products. They can also return to the certification request page from the data table.
The second flow reflects the behaviors of UL’s in house testing and engineer teams. These teams use the system to populate and organize testing data for the end user.
SaaS - Certify Product User Flow
Wireframes and Prototypes - UL Engineers
I also wireframed screens to test and gather feedback on from the engineering users who test, certify, and log different products submitted by SaaS clients.
The initial wireframes evaluated two main approaches to tracking incoming certification requests and showing the user progressing through the steps.
Features include:
Searchable “inbox” of incoming certification requests
The ability to save and come back to in-progress certifications
Two methods of tracking progress