Work queue manager

Empowering service request fulfillment teams to prioritize and load balance their work

MAKE OF THE TEAM

Lead designer and researcher

TIMELINE

July 2018 - February 2019

Product owner, UX researcher/design, developers

TOOLS

Sketch, InVision, Mural

MY ROLE

The problem

Service request fulfillment teams were managing their work using off-line views that were labor intensive to maintain, inefficient to use, and disconnected from the work itself.

I supported a service request platform that connected the sales force with back office sales transaction services, such as proposals, pricing and contract registration. The back office teams that provided these services managed their work queue within this platform was not adequate to allow the back office teams to efficiently manage their work. These teams were instead using digital or physical murals, or an external application, to manage their work.

In these murals, the teams were tracking various types of information in one place, including:

The service requests they were supporting
Other work tasks
Metrics on their team's performance
Team goals and improvement areas
Information to help prioritize their work, ex. sales deals with top clients
Links to associated tools, such as a vacation planner

Problems included:

Since the murals were separate from the platform, the data had to be manually maintained and kept in sync with the platform.
The back office teams wanted to see metrics on their performance alongside of the work queue itself. This meant additional effort to manually pull in this data.
The murals did not provide interactive capabilities to manipulate the views of the work, to allow it to be viewed from different angles.
The murals did not support navigation to the details of the work itself.
Consistency across teams as to how they viewed the work was not present.

The platform product owners wanted to create a new view of work to provide the back office teams with the capabilities needed to view and manage their work within the platform itself.

To comply with NDA, I have intentionally hidden and replaced content in this case study.

My role

Through user research, I gained an understanding of the important aspects of managing work within this context, identifying needs that the original requirements missed. I applied UI design principles and addressed interaction behavior details, while laying out a roadmap to evolve the tool into a fully effective experience for the target audience.

The business analyst provided me with requirements for the new view of work for the back office teams. The requirements called for a Kanban style board to view the work, similar to such views in other existing work tracking tools such as Github.

I interviewed users and analyzed examples of their current work methods for managing work in order to better understand their needs. I used the results, along with requirements, to create mockups and detailed UI design recommendations. I advised on best practices and leveraged design principles. I also identified

gaps in the requirements with respect to supporting the users' needs that I uncovered in the research.

I later performed reviews of the proposed design with users. This pointed out a number of areas where the original requirements did not adequately meet user needs, particularly with respect to allowing the teams to fully replace their current work method of using disconnected murals. I documented and prioritized these gaps.

I also tested the implementation and logged issues to help ensure that the design was implemented correctly.

Solution

We provided a holistic view of work for the service request fulfillment teams to help them manage priorities, meet deadlines and identify roadblocks.

We designed a Kanban style board that would be integrated into the service request platform. It allowed the back office teams to view their work queues in a flexible manner.

This included:

Viewing key information about each work request, presented within status based pipelines, with option to expose additional details
Filtering work by request type, business area, due date, team and assignee
Ability to save filter settings
Sort the work by submitted date, due date, last updated date, assignee and value of the related potential sale
Manually sort the work using drag-and-drop
Expand/collapse pipelines
Switch between individual and team views of the work
Shortcuts to assign work to yourself or mark as a favorite
Navigate from the work tracker to the work itself

This solution was arrived at within constraints that the team set. So, some needs that I identified in my research were not met. However, this initial solution could serve as a foundation upon which more comprehensive support could be built in the future.

Recognition

The application was a finalist for a 2020 Stevie Award in the category of Collaboration Solution - New Version.

Learnings

While successful, the project provided some good lessons that I take away to continue to improve my design process.

Envision the full future solution

Its helpful to visualize in a prototype how all of the key user needs can eventually be met by a fully built out solution, thereby making concrete the potential of what the application could be.

Teams need to be educated on the importance of starting with user research rather than specific UI requirements

The requirements need to take into account user needs from the start and they must be general enough to leave room for creative UI design to take place. When there are too many compromises for the sake of matching pre-determined business requirements, this often results in a less intuitive UI.

Balancing support for user needs with feasibility requires team collaboration

Accounting for implementation constraints while at the same time supporting both user needs and UI design principles is a balancing act the requires close collaboration and creative solutioning. Usability testing, including A/B testing, can objectively provide evidence of which solutions work best.

Key UI interactions should be visualized in detail

User flow diagrams help to make the design of interaction behaviors more thorough and clear.

Initial design sprint

Approach

Through user research and evaluation, I exposed user needs not addressed by the original requirements, while assisting the project team to create a strong initial release based on UI design principles and user needs.

I joined the project team for initial discovery sessions that were based on requirements already gathered. I did user research to validate the requirements and understand the user goals and tasks. This research revealed the need to elaborate upon the original envisioned solution. I created a user story map to show how the tool could evolve to support user needs and allow them to migrate from their existing off-line, manually intensive solution. I also assisted the team with refining the design for initial release, providing mockups with UI specification details. I tested the application as it was developed and also evaluated it with end users. That evaluation again showed the need to evolve the tool further in future releases.

Discovery & User Research

Through user research, I identified additional user needs that were not addressed by the original requirements, while gaining understanding of how users managed work within their teams.

The team held discovery sessions to determine the requirements, mainly based on previous requirements gathering work that took place before I was involved. Such requirements would have typically been based on what was gathered by kaizen, a role that work with users to determine what they needed. However, the methodology they used was not shared and most likely not based on user research best practices. That being the case, I performed interviews with users where they could take me through how they manage their work and describe the relevant scenarios that occur, in order to better understand their goals and steps. This identified a set of user needs that went beyond what the project's initial requirements were calling for. I found that the initial requirements would not be sufficient to allow the user audience to fully give up their reliance on their current murals.

The project team did not want to alter their requirements to take into account the research findings. I raised concerns about this, while advocating for early involvement of UX in planning research. More generally, I suggested that design methodology, such as Design Thinking, should be incorporated into the discovery process. While this did not yield immediate benefits on this project, it may have helped pave the way for future projects that eventually did utilize these methods.

Key needs of users who complete works requests, which I identified from interviews:

Users prioritize work requests based on the value of the associated sales deal, the type of request and input from the requester.
Requests that look difficult may remain unassigned in the work queue. Such requests should be highlighted.
Events related to work requests, such as addition of a new comment or other information by the seller (requester) need to be noticed easily.
Teams want to balance the work among their members.
Having to manage the data in an offline mural necessitates extra work to manually copy data multiple times per day. This also opens up possibility for error in keeping this data in synch with the on-line service request platform.

Based on the research, I created an empathy map and a as-is scenario diagram. I documented user goals that I then compared with the requirements that the team were providing me. I also plotted requirements on a prioritization grid to help determine which of them should have focus.

Design

I used wireframes to visualize early ideas. I did a competitive review of other Kanban style boards. Later, I created a story map to show how the application could evolve to progressively support user needs.

Early wireframe

How I solved the major challenges:

Filtering

I used tokens to keep the user visually informed about the currently applied filter criteria. As the team wanted to have the data view update only when the user explicitly chose to do that, this meant that the user's chosen and applied filter selections could differ at any given moment. I provided a few different possible solutions for this, including one where the 'Filter' button would not be enabled until the user made a filter selection, thereby to indicate to the user when unapplied filter selections existed.
The team also wanted to apply color to the tokens. While I did not feel that this was optimal, I helped them with this as an interim solution, providing suggested color choices mapped to the filters. I also suggested ordering tokens left to right in the same order as the filter controls. This was to provide a consistent structure for the user to help them quickly understand their applied filter scheme.
I added a counter in the filter label of how many selections have been made so as to help users understand in which filters selections have been made.
'Clear all filters' and 'Save filters' actions were placed as transparent buttons at the end of the token string for affordance and to distinguish these important actions from other elements. 'Save filters' would save the current filter scheme as the default across user sessions, an important feature for users who may want to often focus on the same dataset, such as a team for which a certain type of request is a high priority.

Sorting

Based on user research finding, I proposed an option to sort by updated date to help managers notice when requests were not being attended to.
I labeled the sort options for easy scanning.
The project team wanted to include the ability to manually sort the cards to help teams to prioritize important requests, such as to prioritize a large sales deal at end of the quarter. I felt that this would add unnecessary complexity, at least for first release, and suggested that supporting tagging of requests would be preferable. However, I provided design suggestions for the manual sort feature, including that we should add shortcut actions to move a a card to top or bottom of a pipeline, in addition to facilitating this through drag and drop.

Switching views

Two tabs were provided to allow the user to switch between viewing the work for their entire team or work for an individual. Separate filter schemes could be saved for each tab. This supported various scenarios such as service team

discussions, a team member helping out a teammate where they need visibility to their work, or a team member managing their own work.

Content

The cards within the pipelines had default and expanded states. I sought to include the most important information for tracking purposes in the default view.

I included:

The client for easy identification
The request type to indicate the type of work involved
Dates to help the request be completed in a timely manner
A small icon used to indicate a special type of request, called an 'Accelerate' request
The potential value of the associated sales deal to help prioritize requests.

For the initial release, metrics were kept to a minimum, just showing the number of requests within each pipeline (including those not loaded in the view). It was evident from user research, that additional metrics would be helpful in the future to help teams understand their performance.

One of the user goals was understanding the balance of work across the team. Fully supporting this goal was a prospect for a future release. But, for the initial release, mapping colors to assigned team members, as represented by circles containing initials, was explored.

Interaction

Clicking on the card would expand/collapse the card itself. In this way, it would be very easy for users to quickly obtain additional information as they evaluate the workload.
Within the card, there were links for specific actions, such as opening the requests' detailed view, assigning the request to yourself, marking the request as a favorite, or opening a contextual menu of other actions.
As the user scrolled to the bottom of a pipeline, a button was displayed so that they could force the load of additional cards, at a natural position to do so.
At the top of each pipeline, two icons represented actions to expand or collapse the pipelines themselves, providing more expansive views when users want to focus on requests of a given state, such as those waiting for actions by others.
I suggested that dropdown lists for filters be given sufficient height to minimize scrolling, as users did not need to see the underlying page content while selecting their filters.

Visual design

In the cards, I applied styles to the various elements to provide visual hierarchy to the content, based on the importance to the task.
I also aligned and balanced the position of elements in the card. All of this helps with making the information easy to scan.
I advocated for keeping most of the UI color neutral so that color could be used purposefully to highlight important information, both now and in future releases, such as alerts to important events such as overdue request.

Evaluation

I performed a user evaluation of the pilot implementation, including with respect to common user tasks such as identifying the highest priority request to work on next.

Usability evaluation of release one

The evaluation I did with users found that while the release one implementation has useful functionality, it was still limited in comparison to what users needed. Findings included:

Users need to know when tasks handed off to others for a given request are completed.
The work tracker needs to convey the progress of a request and work remaining, such as through associated notes or other more structured mechanism.
It could be useful to group requests according to specific roles within a support team to align with how teams divide up work.
Similarly, users miss the ability to easily understand in one view, the distribution of work load across their team. This includes the need for a better way to visually map requests to their owner to understand individual work loads at a glance.
Teams could benefit from building in additional logic to take into account information that would effectively indicate the relative importance of each request, including due date, value and work remaining to be completed.
It would be helpful to have metrics within the work tracker such as the time requests remain unassigned, the age of a request and the time it takes to complete tasks handed off to others. This could provide benefit to team managers as well as members, and could help identify which team members need help.

Next project