< Back to Design

Case Study: Improving a Product UX with design system UX pattern Guidelines

Background:

With a C-suite executive mandate to elevate one of our ERP products, Syteline, due to decline in sales and market competitiveness. The Syteline product team had reached out to the design system team to get guidance on UX patterns and UI recommendations. We soon learned that the product was built on a 15+ year old legacy platform which came with lots of technical limitations, making the product difficult to adapt new changes. And because of the state of the product and its shortcomings, net new users are forced to invest heavily in product training causing problems for companies to hire employees who are willing to work with the software for the long-term.

While I lead the design portion of the design system, defining and documenting UX patterns is one of my responsibilities. And as a system team, it’s important to help our product teams within the org to use our tools and guidelines, especially those products who don’t have designated designers as resources.

The goal for this project was to guide Syteline in the right UX direction to improve their product experience by helping to identify high-impact changes that they could take and implement.

Research:

We needed to start the process by understanding what the problems were by interviewing the Syteline team. One of the major UX pain points for their product was the complete lack of information hierarchy and its absurd navigation when it comes to task completion for the users. The few problems that needed immediate attentions were:

1) There’s no tight relationships between the interior tabs and the button actions on the right side, causing a lot of confusion for the users.

2) The information and layout presented to the users on any given page tab all look the same or similar, causing users to loose track of where they are in their workflow.

3) The UI of the product is dated (as Syteline did not adhered to the latest UI components due to their dated technology and development constraints)

Wireframe/Design:

Using an existing UX Pattern (called Index-Detail) from the design system as a guide, I had created a “wireframe/design” to help Syteline to visualize a better information hierarchy where the Index (data list) is the “parent”, and Detail (header and body) is the the “child”. The interior tabs and action buttons (related forms) from their current layout could be reorganized as one accordion.

Another major change I proposed in the design was to remove a global toolbar, and place those needed actions to be “in-context” within the workflow of the users. By having actions to be placed within the workflow, users can better understand what actions they are taking to the data in front of them, creating a better relationship and a quicker workflow.

Initial Validation:

The proposed design received great feedback from the Syteline team, and their platform engineers had started to pick up on the major structural changes along with updating their UI.

Design Iteration:

While development was happening, we soon learned about a new challenge. One of the requirements that was never mentioned initially from the Syteline team was that a majority of their “super users” are using the screen size of 1024px by 768px. The previously delivered wireframe/design were best intended to fit on a 1440px wide screen.

Because of the sudden spike and a short turnaround to redesign what I had proposed months ago, I had to come up with some quick design decisions before their team could start implementation.

With the need to consolidate both vertical and horizontal space to satisfy their “super users” (factory shop floor workers) on a small screen, I sketched out some ideas and did some quick screen mockups.

With the previous header taking up more vertical real estate, I tried to minimize that space as much as possible. I had also converted the accordion on the left into a select dropdown and placed it up in the header so users can still access the other pages easily.

While this design iteration would satisfy the needs of their “super users”, I had also recommended that the design should only be viewed as a responsive state and the expected behavior for users with a larger screen should be presented with the previously delivered design.

Outcome:

From a design system perspective, the goal for this project was to help Syteline to use our existing UX pattern documentation and UI recommendations to improve their product experience. While the intended goal was delivered, it would be wise for the Syteline team to perform more research with their users to understand other root issues. The system team had also recommended them to look into consuming our design tokens which would help them to keep up with future UI updates and modernizing their product.

< Back to Design