TL;DR
Relay is an enterprise progressive web app designed to enable internal teams to track work (projects and tasks) status and to easily communicate with vendors and clients.
Today, we're just looking at one aspect.
The Problem
Our Project Managers face challenges in tracking project and task statuses due to poor system transparency, leading to incomplete status knowledge, missed deadlines, and delays. For instance, vendors may request extensions, but PMs might miss these updates, leading to delays or missed delivery. Sorting tasks based on approaching deadlines is also difficult, risking late deliveries and lower customer satisfaction.
Proposed solution
We’re going to build dashboard that tracks project and task statuses, due dates, exceptions, and new work requests in one unified workspace, saving 1-2hrs of PM time daily, and eliminate the need for offline trackers, customizations, and updated project notes. Enable the sorting of tasks based on approaching deadlines, prevent missed deadlines and delays, and allow for the correct action to be taken without digging for information.
So begins the user research
At this early point, only some basic pain points are known. In order to better understand the scope of the problem, it’s necessary to identify a group of affected users who are actively interested in participating in the design process.
This initial survey gathered a total of 36 responses from people. Below are the questions and the responses.
Note: An offline tracker is just a spreadsheet to track statuses. Even though these spreadsheets are "forbidden", very PM uses them and updates them manually. Our PMs do this because they aren't confident in the system's ability to track statuses in real time.
Additional insights
As one of the highest requested software enhancements, this is at the top of everyone’s list. Our PMs are engaged and eager to help in any way possible. Additional 1:1 interviews were needed to in order to provide context and help clarify some of the above answers. For example: The question asking how many exceptions do you encounter on a daily basis varies widely depending on squad. Squad 3, responsible for managing Google account projects, skews the results due to a higher throughput of smaller projects.
One takeaway is that PMs think in terms of a giant, sortable, filterable spreadsheet. They think they want to see something like the below image.
The mental model
Based on survey answers and followup interviews, the current mental model can be represented as something like this.
Diving a little deeper.
TL;DR - A few more UX artifacts to ensure we really understand these users, their motivations, thoughts, and feelings.
User personas
Let’s put it all together. Based on research and data provided by our users, including their goals, behaviors, motivations, and pain points it’s time to create user personas. This’ll help our teams better understand and empathize with our PMs users, and create a feature set that meets their needs and expectations.
Rapid prototyping
Every UX designer has a favorite part. Rapid prototyping is mine. I love seeing all the abstractions come to life in a clickable design. No concepts left to the imagination.
"Final" MVP design and components
After a few more conversations with engineering to right-size the MVP scope, I landed on the following MVP design.
In retrospect…
1. This was initially begun as a UX exploration. I had an idea based on some frustrations our PMs had expressed and I wished to explore it further. No stakeholders had signed on, so getting the study off the ground was the result of sustained “side project” effort. Eventually, after socializing my work, a Product Manager was assigned and the greenlight was given. This has now become an integral tool.
2. Welocalize has teams spread across the globe. This is one way in which high throughput can be maintained. While the teams have learned ways to operate with one another, the interaction is terse and focused on communicating only the most salient of details. While this may be fine for the management of a project, it represents a significant challenge to the research and design process. I discovered quickly that our APAC teams would say very little when interviewed in “large” groups of 4-6. This is actually an understatement. Often times there was no response whatsoever to my questions. Only by adjusting the interviews down to a 1:1 was I able to get them to speak openly with me about their frustrations.
3. Breaking this apart into multiple phases took a lot of work. After completing the moon shot version in which all features were available, I had to make multiple (understatement) watered down clickable prototypes until our teams could finally agree on what was a reasonable approach to the development process.