UI/UX Consistency Project

Organization: enterprise call center software company | Role: Designer & Quality Assurance Engineer | Team: Contract Developers | Timeline: 5 months

The challenge
After merging three separate products into one cloud platform, a number of inconsistency issues were revealed. Many of the same UI elements (pop up dialogs and tooltips, for example) were styled and behaved differently in various parts of the platform. 
At the time, the research and development (R&D) team did not have a complete visual pattern library or standard design process to reference when fixing the inconsistency issues. Therefore...

how might we reduce inconsistencies in the UI so that users can seamlessly experience the new platform?

This story begins after three standalone products were merged together into one call center management platform.

the solution
The problem called for a pattern library that defined styling and behaviors for common UI elements on the new platform. The designs were created and proposed by a special team of contract developers and me, and they were approved by a cross-functional group.
The Process
Defining the needs
With broad instructions from management to just fix the inconsistent UI/UX issues in the platform, we started with a discovery phase with the following actions to identify the issues and define the needs of this project:
   1. Met with customer facing teams: customer support and technical training
   2. Received backlog UI/UX features based on customer feedback and escalation bugs
   3. Conducted a UI inventory of the cloud platform

Based on all of the insights, there were several needs that this project aimed to address:
Putting it all together, we came up with a list of 10 UI components to tackle:
             1. Saving/Canceling on Forms
             2. Time/Date Formats
             3. Tooltips
             4. Editable List widget
             5. Available/Assigned widget
             6. Tables
             7. Toggle Button Group widget
             8. Filters/Search
             9. Toasters/Dialogs
             ​​​​​​​10. Color Pickers

The following section details the general process in coming up with standards for each component, using the first one - standardizing the saving and canceling on forms - as an example.
The process - Saving/Canceling on Forms
One main area of concern mentioned by everyone was the saving and canceling functionality on administrator form pages. There were over 100 long form pages in the platform for configuring various entities used throughout the platform - for example, users, teams, schedules, servers, etc.

This is the typical structure of a long form page, with certain modes and fields.

the issues
The main issue was that the Save and Cancel buttons functioned inconsistently across long form pages. Areas of inconsistency include:
   - The save button's state - sometimes it never enables unless a specific field in the form is filled out; other times it is always enabled.
   - Clicking on the cancel button - sometimes a warning dialog pops up when leaving the page with unsaved changes, even if no changes were made on the page; other times the page immediately leaves the page without confirmation.

Overall, we found that the issues regarding the save and cancel buttons were actually part of a larger problem of how these long form pages should function and how they should be navigated to and away from.
The users' information needs
After identifying the issues with the Save and Cancel buttons, we defined what the user needs to know when they are on one of these pages to configure something in the system. I had the team ask ourselves two questions:
   • What information does the user need to know in order to interact with one of these long form pages?
   • How do we provide this information to the user?

We organized the kind of information that the user needs when using a long form page in terms of what the user needs to know and how can they know this.

User Flows
Next, I mapped out the form workflows when creating a new entity mode and editing an existing entity. 

To make the decisions on how to notify the user about the form's state after clicking the Save or Cancel buttons, I drew on the cognitive psychology principles of attention. If there was an error, the user should know that there is an error and recognize what was the error. Therefore, I provided a dialog to add friction to the user’s workflow, so that they will pause to attend to the warnings of when the page did not save correctly or when they leave the page with unsaved changes.
At each point in the workflow, I considered what the state of the Save button is. Based on the workflows, I decided when should the Save button be disabled or enabled in order to provide the user with the current state of the form. I then considered what should happen after the Save button is clicked on, as well as after the Cancel button is clicked on.
Of the two buttons, the Save button workflow was more complicated to design due to its significant role in telling the user about the long form's state. The Cancel button, on the other hand, remained constantly enabled throughout the form workflow. However, our team had difficulties with agreeing on what to do with the Cancel button, mostly because the Cancel link effectively acted as a navigation button, yet the word “Cancel” doesn't give off the sense of moving to a different page. 

We ended up coming up with three different possible solutions because we could not agree within our team on one solution, which leads to the purpose of the proposal meetings.
Proposal Meetings
We wanted management and the R&D team to be on the same page on how to fix these issues, and the best way to accomplish this was to put everyone in the same room. We identified the main stakeholders and engineers who would provide the best input and have the power to approve our proposals:
   • Product Managers
   • Engineering Managers and Directors
   • Senior UI Developers
   • Technical Writers
   • Automation QA Engineers
We wanted to make sure that every person understood the issues, the current state of the product, and what ways they could fix the issues through standardizing the visual elements. 

At each proposal meeting, we reiterated our goals of the meeting. We wanted everyone in the room to understand the issues and work together to refine our proposed solutions.

Implementation and Impact
The meetings were productive, and it felt relieving to exit a meeting with approved solutions to the many UI/UX issues in the product. I was in charge of sending out meeting notes and documenting them on Confluence. At times, we had to revisit our proposals and create new mockups based on feedback after the meeting, and then sent out the second iterations out for another round of review and approval.

Although much of the implementation of the standards is still ongoing, the designs have at least been approved by through our cross-functional meetings. Developers and QA have already started using the meeting notes documentation as a reference when building new features and fixing bugs. Product Management have also referenced the documentation when designing their new features.
Main Takeaways
• This was my first professional UX project, and it covered a wide variety of UX issues. Because it was focused on analyzing and fixing existing issues, I learned what improvements in UX can be made without rebuilding entire products from scratch. 

• It was enlightening to learn that a lot of the many UI/UX issues can be fixed by establishing a design pattern library. 

• Through examining numerous UX/UI issues, I also gained a great sense of what designs to avoid in the future. I would love the opportunity to build out a pattern library at the beginning of a project, so that designers, developers, and QA alike can reference it as they work.


Back to Top