Coverage Tracker

Overview

Brief: The engineering team responsible for Yext's Professional Services dashboard had recently implemented a coverage tracker feature, which allowed client managers to set coverage assignments to client work before going out of office. However, the presentation was unwieldy and the information was hard to process, so they were struggling with user adoption. We provided several high fidelity designs that added guidance, reward, and automation to a previously tedious task, leveraged visual cues for easier parsing of dense information, and aligned the workflow with users' existing conceptual models to improve intuitive understanding. We leaned heavily on user interviews and rounds of design mocks + user feedback, and successfully navigated the constraints of a minimal design system and limited engineer capacity.

This project was part of a broader dashboard redesign, which included updating the branding and design system, optimizing the site map, and improving information hierarchy and presentation. I led the five-person design team on the overall redesign initiative as well as leading the three-person team that worked on this specific project. I was responsible for gathering initial insight, scheduling meetings with stakeholders and users, and aligning with the engineering team on development constraints. I worked closely with the other senior designer, Sneha, through the process of creating mocks and provided opportunities for a junior designer, Alexis, to join the project as her capacity allowed.

Previous Design

Prior to the coverage tracker, out of office communication was done through Google Docs and Sheets. The person going out of office would create a spreadsheet, with each row containing the item or account name, who was covering, how urgent it was, any specific notes, etc. It was a tedious process, since everything was manually entered and day-of coverage always had to be cross-checked against a large spreadsheet.

Creating a coverage tracker within the dashboard, which already housed client information and account assignments, was a huge improvement functionally. Items were now automatically reassigned, so employees could trust that their single queue contained all items they were responsible. Furthermore, people could be sure that the currently assigned manager for each item was always someone who was in office and accessible.

However, the poor design led to minimal adoption -- employees going out of office often just defaulted to using the familiar spreadsheet method since the new interface was confusing -- and it lacked support for iteration after launch. Users had pain points or edge cases that were not being solved for because the engineers developing the workflow didn’t have the processes to pull user feedback and iterate effectively.

A screenshot of the current coverage tracker, a long table with no additional structure. Each row is an item on the coverage tracker.

The previous coverage tracker design -- note that users actually had to scroll horizontally to find assigned coverage.

Diving In: Manager Interviews

Illustrated zoom meeting with four people.

With all of this in mind, I kicked off the design process by meeting with the client managers that initially ideated and pushed for this functionality to hear what their vision was. What frustrations drove the inception of this feature? Who are the different users, and how do they come to it? How does a coverage tracker fit into the overall process of going out of office? What works well about the current process (the spreadsheet) that you’re not getting from the new coverage tracker? These managers had a TON of ideas and were really excited to talk through their process and what they were / weren't getting from the new coverage tracker, which was a really energizing experience for me.

I came away from this meeting with a much better understanding of the important twists and turns that mattered in the full process of preparing to go out of office and/or supporting a colleague that is out of office. Talking to them also revealed some of the underlying wants driving this feature. We used this new insight to establish three goals to guide our initial design process:

More structured guidance

Neither Google Sheets nor the coverage tracker table created any sort of structure to guide users through the creation process. Conceptually, users had to tackle this entire tracker at once, which was overwhelming. It was clear from the managers' suggestions that adding a structured flow would ease user experience and remove barriers to entry.

Auto-fill for efficiency

While the projects and items needing coverage often fell into a hierarchical structure (each was tied to a client account, for instance), this was not leveraged in any of the current design iterations. Creating a logical hierarchy, where account assignments then flowed down to automatically assign project assignments, would save users numerous clicks, re-typing, confusion, and frustration.

Quick access to important info

The plain text formatting and long rows found in the table view made it hard to scan the tracker for important information, such as project status and important links, and the assigned coverage -- the most important information -- required horizontal scrolling to see. It was clear that improving information access would be crucial to user adoption rates.

Design Decisions

I worked closely with my fellow designer, Sneha, to brainstorm, refine, and gather feedback throughout this process. We also worked with a junior designer, Alexis, during the brainstorming phase. Our discussions concentrated along three dimensions: overarching user flows, smaller editing interactions, and designing for quick information access.

User Flow(s)

Something we introduced early on was the idea of creating separate designs for editors and viewers. It was clear that these two user groups required very different things from the coverage tracker, and that their needs could best be served by splitting the project into two flows. This resonated a lot with both the engineers and the client managers, who had struggled to create designs that supported both journeys well.

Viewers

Both editors and viewers were suffering from a lack of structure to guide their attention and process. For viewers, whose main needs were to access coverage information, links, and notes quickly, we focused on creating hierarchy that matched users’ current mental models. Rather than a single table, we suggested grouping items under their client account and/or creating a division of “In Progress” or “Resolved.”

We also keyed in on relevant properties of each item in the tracker. The current table held some information that users never really needed, such as business ID, and put the “Designated Coverage” column last. On page load, it was not even visible, nor were there any visual indicators on how to find it (scrolling horizontally on the table). Between creating structure on the page and optimizing for most-important properties, we were able to clean up the table rows such that they were much easier to navigate for users searching for coverage information.

"View" version of a coverage tracker, with items in table rows but separated by resolve status.

"View" version of a coverage tracker, with items in table rows but separated by account.

Organizing by status, on the left, and by account, on the right

Editors

For editors, the key focus was to break an overwhelming task into manageable pieces, providing a logical flow and automation where possible to let users feel guided along this tedious task.

One pattern we explored was a fairly simple accordion pattern, where a user could move down a single page that was sectioned by type of item. This pattern provided some structure and guidance to the flow, but prioritized always keeping everything conceptually visible to the user. It was similar to a checkout process for online shopping or a review screen on an application.

The other pattern was borrowed from flows like surveys and wizards and instead prioritized step by step movement through a process. Within this pattern, we did a brief comparative analysis to pull a range of implementations, and ultimately chose to go forward with a sidebar navigation, as we liked the conceptual structure and navigational freedom that it allowed our users.

Initial coverage tracker screen with an accordion pattern, with each drawer a different type of item. Default coverage and general notes are at the top.

Initial coverage tracker screen with a wizard pattern. There's a vertical sidebar nav for type of item and the current screen is asking the user to select default coverage.

Initial screens for the accordion pattern, left, and the wizard pattern, right

At first, we expected the most guided flow would be the winner, since it captured the step-by-step walkthrough that the client managers had in mind. However, our engineering team pointed out something that we had not accounted for -- that users will often have to come back and edit a coverage tracker, as items are constantly shifting within people’s queues. The wizard flow could have technically supported this, but we knew that navigating it to edit would be really cumbersome.

In feedback sessions, users and managers agreed that the wizard pattern's structure felt very rewarding to use, but that the accordion pattern was better for anyone trying to edit an existing coverage tracker. So, we combined the two patterns: the wizard pattern would be used for initial coverage tracker creation and the accordion pattern would be used for the artifact created from that initial flow.

An editable coverage tracker view structured by account.

The design generated from our feedback session with users

Editing Efficiency

A key focus was improving overall efficiency for users filling out a coverage tracker. There were many redundancies within the current process, as well as unideal access item notes, which were very prominent in the old (spreadsheet) coverage tracker. I designed multiple options for what the item editing could look like, irrespective of the overall user flow. Things I explored:

Can we implement any batch editing?
How can we show item notes, allow for editing, and still keep the page relatively trim?
Should editing take place in line, or in a separate container (e.g. a modal or a new screen)? Do users find in-line editing efficient, or messy / busy?
And, of course: How can we optimize for number of clicks?

Quick wins involved removing the unnecessary “Edit/Delete” buttons and allowing for better “Notes” functionality. Users had differing reactions to batch editing, though everyone agreed that the in-table coverage edit bar was more intuitive than one outside of the table. They also really liked the modal for notes and felt they could write expansive notes without overwhelming the page.

Initial audit of the coverage tracker table rows

Editing Flow 1, Screen 1: Item editing with batch selection available for updating coverage

Option 1: notes editing in a modal, optional batch editing. The winner! Includes the most "in-line" editing.

Editing Flow 2, Screen 1: Item selection for editing. No batch selection

Editing Flow 2, Screen 2: Selecting an item leads to a new screen where the user can update coverage and add notes

Option 2: edit on a new screen, no batch editing option. Most similar to the current flow, where items are edited one by one.

Editing Flow 3, Screen 1: Item selection with batch selection available

Editing Flow 3, Screen 2: Pressing "Update" once items are selected leads to this screen, where users can update coverage and write notes for all selected items

Option 3: edit on a new screen, but can batch select items to edit. Could make sense if users usually edit only a small selection of items.

Quick Information Access

Lastly, we made vast improvements to the accessibility of important information. We highlighted an item’s status through red/green color blocks -- looking back, these could be further improved by adding icons for increased accessibility. We also reduced the amount of information presented in the table, as mentioned above, allowing for easier scanning and locating of needed info.

We also created a totally new option, removing the tables altogether and presenting each item in a card. These cards closely mimic the design of Jira cards, which Yext employees were working with on a daily basis. Cards make the information less compact than the table, but users really enjoyed the friendliness felt from them vs the table rows.

For these changes especially we made sure to align with the engineering team to determine what it was possible for them to do. For instance, styling the statuses in pills in-line would not have been straightforward, and we knew that creating the cards would take a good amount of work. I worked closely with the main developer to ensure we reached the best compromise.

A coverage tracker design with item cards nested under accounts in an accordion structure.

Displaying information on cards instead of in table rows

Eliciting Feedback

We had struggled early in the process to get useful feedback. The engineers that we were working closely with tended to defer to “best design thinking” when discussing sketches and wireframes, but offered lots of opinions (and implementation constraints) once presented with high-fidelity designs or specific asks. To ensure we could get feedback before making design decisions, we ended up creating multiple high-fidelity options for consideration. We leveraged a small design system that I had created along with our rapid hi-fi skills to efficiently create the kinds of mocks that we needed. We still relied on lower fidelity practices for initial brainstorming and designing within our small team.

Our struggles to get good feedback from our engineering partners pushed me to be really intentional about how we solicited feedback from client managers and users. I created a Figma prototype with our different flow options and annotated the flows with explanations of the designs and their major features. I focused feedback even further by providing guiding questions. I used these questions to facilitate in-person sessions but also encouraged people to drop comments on the presentation asynchronously.

Setting up a presentation like this went really well. It kept our meetings on track and ensured that I didn’t forget to elicit feedback on something important. Client managers and users responded well to the intentionality and were very engaged. Moreover, it was great that I could do it all within the Figma file. Adding designs to the presentation was easy and any notes automatically appeared on the designs, making it really easy to keep track of comments when we went to make changes. I was excited about the success of this technique, especially after our earlier struggles, and will definitely look to use it again in the future.

Initial screen, annotated with comments and questions.

Editing screen, annotated with comments and questions.

Annotated designs with guiding questions for feedback

Future Steps

I was let go as part of Yext’s mass layoffs in Jan 2023, unfortunately before finishing this project. The project itself was also put on the back burner as capacities for remaining employees shifted. However, the success of our completed iterations and the recent feedback sessions had given us a clear path forward. I had made plans to sync with the main developer to pin down feasibility, Sneha and I were focusing the design options to lock in the chosen user flow patterns, and I was setting up feedback sessions to gather more reactions to the editing functionality.

We were close to designs for an MVP, so I was also thinking about how to set up user testing and validation metrics to establish success of the new coverage tracker. Regularly gathering qualitative feedback -- How did it feel to use? What was confusing or tricky? When are users having to use other tools or other screens? --felt important, especially for initial launch. Metrics such as percent of total adoptions (where users are not supplementing with old spreadsheets), number of clicks taken to find info or edit an item, total time spent on the page, and amount of user backtracking were all potential ways to passively measure how useful and usable this new system was for users. Ultimately, I was excited to get this in the hands of users and be able to see how they were using it.

Final Eval & Takeaways

This project taught me a lot about taking charge of gathering feedback. In retrospect, it's clear that design decisions were difficult partly because no one in our weekly meetings was responsible for representing the user voice. While we spent several weeks hoping for more feedback from our engineers, deferring to them since they had the final say on what got built, we ultimately only made progress once I decided to trust myself to move forward with designs in the face of limited feedback and to actively seek out more regular feedback from users and managers. Keeping users in the loop would have allowed us more rapid iteration, improved grounding throughout our process, and a quicker arrival at an MVP. Alternatively, a good product manager who deeply understood the user needs would have been an invaluable asset.

It was also interesting working within the confines of a pretty limited design system. It made building out hi-fis very quick, since the components were readily accessible, but it limited our creativity and there were consistent concerns that something would be out of scope for dev. However, I really enjoyed building a relationship with the main engineer on the project and working with her to figure out places for compromise, understand which pieces would be low or high lifts, and just dive into more technical problem solving.

Overall, working on this project was a constant reminder of why I like product design: strategizing with stakeholders and users, working within a very iterative design process, and getting to dig deep into interaction design and user flows. I was not expecting how energized I would feel after the ideation and feedback sessions with the client managers, and it was exciting to flex skills that my client work didn’t always require. I’m sad I didn’t get to see this project finished and deployed, but I'm excited to take the lessons learned into my future projects.

jackie.

nelligan

Yext Coverage Tracker

More structured guidance

Auto-fill for efficiency

Quick access to important info

Want to know more about this project?

Other Work

Candidate Application

Android App: Planter

Web App: Iribe Welcome Kiosk