Glidewell Dental's CRM system, otherwise known as GCX, is an enterprise application that manages interactions with our dentists. This project focuses on devising an intuitive navigation for our employees to provide a unified customer service experience to best serve our audiences.

COMPANY: Glidewell Dental

RESPONSIBILITIES: Information Architecture, UI Design, Prototype, User Testing

TOOLS USED: Figma, Figjam, Dovetail 

TIMELINE: 8 weeks



At Glidewell, our customer service team strives to support dentists everyday to help them deliver quick cost-effective products for their patients.

Currently, our GCX (Glidewell Customer Service Experience) system is lacking an intuitive way to view all tasks that a CSR (customer service representative) may have completed with their customer. It takes them a significant amount for time to pull up information about a customer on the system. 


This project would require an entire iteration cycle of our CRM (customer service management system). Given our time constraints with this project, our team decided to focus on the biggest problem that came out of our requirements meeting with product managers, which is designing an intuitive navigation of our CRM to create a more unified experience for not only our CS team, but also cross-functional teams to reduce the need to create specific training user manuals while serving our customers. 

"Our goal is to make the navigation as seamless and self-explanatory as possible to increase process automation."



We developed a 360 panel (left side) to help users find quick information on the user regarding accounts, practice, and provider information so they can effectively adjust information that they need to. Using a side panel for our tasks allows more flexibility for our users to quickly find information about our patient while completing the tasks and provides a focused state so CSRs can focus on helping the patient. Clear statuses are shown on the left navigation bar to indicate which tasks are completed so there is no confusion. 

01 - Research & Discovery


We started off this project by taking a look at our current CRM application to identify any issues. After a quick meeting at looking at some missing pieces, we were able to identify a few high-level problems and synced up with our product owners to make sure it aligns to the business' needs. 



We used open card sorting as a method to identify categories where each tasks should lie to help us with information architecture. There were a lot of repeat tasks that our team had to eliminate, so we reviewed those with our card sorting participants.

We allowed each group to name their own categories and sort the tasks based on the categories given. After card sorting, we added all the results on a spreadsheet and came up with a list of high-level insights:

1. All user groups were not confident with the terms account/practice/provider tasks.
However, they knew what each of those terms meant, by definition. 

2. Users are frustrated that many of the tasks lead to another task, which would create multiple tasks that are unecessary.


 How might we efficently display an intuitive navigation for cross-functional teams to quickly access information about our customers to unify the customer experience? 

02 - Information Architecture 


My team and I started to take each task and identify if there are any crossover tasks and if it makes sense to condense some of them to prevent confusion. Doing so helps the user look for a category then search for sub categories to save real estate on screen.  By brainstorming these flows, we are able to lower the learning curve and ease of use among our user groups to make the system more self-explanatory. 



We minimized the amount of tasks by grouping similar tasks based on our card sorting data. Keeping the navigation at an Account, General and Cases level makes the most sense for all our user groups overall. For our Cases navigation, we only have two tasks listed there due to a misplacement of case-specific tasks, which should be located on the Cases screen under the ellipses. 


03 - Ideate



During our brainstorm sessions, we played around with two different ideas; a side panel task menu vs. a full page task menu to help us visualize a range of design solutions before deciding which one to go with. We knew that the type would depend on the size of the tasks. If a task requires a direct flow to submission, it will have the side panel task. If a task requires more steps to completion, it will have the full page view. 

To increase the process automation, we decided to route all the tasks to its specific work basket so each department can receive their appropriate tasks efficiently.


For each of our individual tasks, we created a side panel and a full page task design  component to help us distinguish which tasks our users are doing. 

For the tasks that have a direct flow, we added them to a side panel. For a more complicated task that require several steps and information, we added them to a full page component to allow the user to focus on the screen. 



After presenting our findings and insights to our stakeholders, we uniamounsly agreed that there needed to be two views to look at different tasks, depending how complicated the task may be. We decided to separate the Account Information, Practice Information and Provider Information out of the task menu and put it on the 360 panel as tabs to simplify the process. 

In our initial interviews, we had a mix of people say "I am not sure how to change a billing address for our customer and that should be a very simple task". By taking this out of the task menu, this will help the user by separating out the different categories.



Our goal was simple, we wanted to reduce the cognitive load a user would go through while looking at a task and viewing case details. We redesigned the case details prior to this project and decided on having a side panel for the different tasks. 


Before -- Tasks would appear at the top of the navigation, making it hard to locate information about cases.


After -- Case-specific tasks would appear as a side panel, allowing the user to still see full visibility about case details, if needed.


From our research, our customer service reps reported frustration while looking for files for a specific case, such as a prescription or photos that are tied to a specific case. We redesigned the case details page and included a Files section to allow easy visibility to all files. 

Now the user can look through the Files section and quickly pull up any files that they are looking for, including being able to view who uploaded the file and what type of file is it. 


Attach File modal did not indicate the case number, which made it difficult to look for specific files for a dentist. 


Recent Attachments is located on the far left, which brings frustration to users who are looking for files quickly while they are on the phone with a customer.


With this improved user interface, users are now able to quickly look under Case Details and find the files that they are looking for, along with full transparency of the file name and uploaded by information to easily track the file, if needed.


Our CRM system was built using Pega Cosmos, a design system for building enterprise applications. Our previous CRM was built using an older version of Pega systems and this updated version differs slightly in the UI to free up distractions for our users and allow them to learn the application quickly through familiar interaction patterns and allows us designers to prototype, design and configure our enterprise applicaton much faster. 



Besides demonstrating an intuitive navigation for our users, we wanted to also focus on what will users look at after they are done with a phone call with a customer? We decided to create a Wrap Up Summary page to show the tasks completed in the phone call, allowing users to get a quick overview of what was completed during the interaction with the customer. 


04 - Iterations & Usability Testing


We kicked off our designs to test with our customer service team along with our technical advisors. Our tests were run on a role-based format to provide our participants with the most realistic scenarios to use the application as if they were on the phone with a real customer. 

1.  Participants loved how simplified and sleek the user interface on GCX 2.0 and are delighted that we are moving towards a seamless platform upgrade. 

2. 3/7 CSRs were not able to distinguish the difference between an account, provider and a practice when asked. There were also clear cases of the same CSRs clicking on account info, instead of provider info in the 360 panel, which may be contributing to the confusion with the “Update Personal Information” Task. 

Our final recommendation would be clearer training around these terms and future research into the 360 panel to clarify any confusion. This first round of user testing helped our team discover a lot of new design possibilities and solutions that may have otherwise gone unnoticed!



A few participants were concerned about what would happen if an account is closed? With the current design, all tasks are available even though an account is closed, which could be confusing for the user.

We reiterated the 360 panel to show when an account is closed, all tasks should be unavailable for the user and the only task that should be available would be to "Reopen" the account. 

CSRs and the accounting team also reported that displaying a close reason for a billing account is even more beneficial for the business and supervisors at a high level to follow up on any outstanding balances, if needed.

Learning and Next Steps


While we were redesigning the tasks, each of them included an input field that required the user to type in who they were speaking to. We plan on revisiting this problem as the CSRs improve their workflow so that the users can see who they are speaking to in the 360 panel, rather than typing it repeatedly after every task is completed.


This is one small part of this entire iteration of our CRM system. By solving one part of this problem helps us narrow down our scope for our future projects. We held many design critiques during this time to get the most effective feedback that ties to our objectives. We were able to come together as a team and spend some time together to think of the best possible solutions. 


We know that we can't solely rely on providing better training for our user groups, so we still have a lot of work to do such as figuring out how to define our scope for the design of the 360 panel. This requires several rounds of iteration and will continue to be a long term goal for our team.