Goal
Lead end-to-end design for a new feature
Overview
To meet the company’s goal of increasing customer retention, our product department’s goal in 2023 was to improve our platform’s UX by identifying gaps in existing features and their functionality.
One of the ways my product manager and I identified potential initiatives was by looking at customer support tickets related to our
product space: tracker settings and inventory management.
What we found through an initial review of Zendesk tickets was that users often sent tickets requesting changes to their device settings. We decided to investigate this issue further.
My Role & Responsibilites
Design Lead
Partner with my product manager to define the problem and identify the user(s) we’re solving for
Identify tools to use to understand user paint points
Devise user research plan
Design UI
Create and analyze user tests
Write user research scripts and conduct unmoderated and moderated usability tests
Timeline
~9 weeks
Results
Reduced tracker-related customer support tickets by 32%
The Process
Understanding the Problem
To start this investigation, I interviewed a couple of account managers to understand the current workflow customers go through to update their device settings.
Problems
Lack of transparency: Customers are not confident they are receiving the data they want because they have no visibility into their device settings
Fails to meet timely needs: Customers who need to immediately update a device’s settings cannot do so
Time-consuming and effort-intensive manual process: Support spends 8 minutes per shipment configuring devices for customers with an average 148.4 shipments created per day. Support spends ~19.8 hours per day configuring devices
From these interviews, we learned that customers have no visibility into their tracker settings and rely on support to make necessary changes. The current workflow is inconvenient for our users and time-consuming for our support team.
We came up with the following problem statement: As a Tive user, I want to make sure I am getting the data I want from my device so I know my shipment is arriving on-time and in-full.
SO?
HMW give users visibility and control over their device settings so they feel confident they are receiving the data they want?
Identifying User Requirements
Rather than designing the solution from scratch, I decided to leverage our existing “configurations” feature which is how support currently manages device settings. By leveraging existing engineering efforts, we would ensure a low-cost, fast-delivery and enable our users to tackle their needs as quickly as possible. Furthermore, we could start collecting user feedback sooner which would help us move forward confidently in our decision-making.
Starting off, I created a customer journey map to better understand and visualize the existing workflow internal users go through.
My product manager and I gathered direct feedback from internal users, as well as put our user caps on to think about what potential pain points Tive customers may experience. Our user persona is based off the users who submitted tickets requesting device changes.
A summary of pain points:
Some settings are outdated
It’s not clear what each setting does / what each value means
The only way to update tracker settings is to attach a configuration - this can be time consuming if the user is only trying to update settings for one tracker
There’s no way to update an individual tracker’s setting if a configuration is attached
It takes too long to copy and paste tracker ID’s one-by-one into the search bar
One paint point that my product manager, tech lead, and I, spent time solving was how might we enable customers to easily update an individual tracker’s settings if it already has a configuration attached.
In the product’s current state, if a configuration is attached to a device, the only way a user can change the tracker’s settings is to create and attach a new configuration (too many touch points 👎🏼), or update the existing configuration (this would affect ALL devices with this configuration 👎🏼).
After some brainstorming, we came up with the concept of “removal” - a user can remove a configuration from the device which would allow them to edit that device’ settings. We would have to redesign the backend to achieve this solution which would require more effort and expand the project scope, but we decided to go ahead with this solution because it would provide the best experience for our users and enable us to scale this feature in the future.
Fun fact, this concept of removal is similar to what Figma does with components and instances. To modify an instance, you must detach it from the main component.
Designing the Experience
After coming up with the concept of removal, my product manager decided to split this project into two initiatives given the large project scope. Each initiative would deliver value, with the second initiative building upon the first.
Initiative 1: Enable users to view and edit individual tracker settings
Initiative 2: Enable users to bulk update tracker settings via a configuration
User Flows
Before designing, I took some time to come up with what the potential user flow and touch points could look like for each initiative.
Wireframing
Sketches/Wireframes
Initiative 1: View/Edit Tracker Settings
Design Requirements:
Identify which settings to include and ensure they are easily understandable and scannable
Make it clear what each setting is affected by so the user knows where to go to update it
3 scenarios:
1. The setting is set at the device-level
2. The setting is set in the configuration profile (which is applied to a device) and can only be updated in the configuration
3. The setting is set by “smart settings/auto”, which overrides the other two layers
Initiative 2: Create, Attach and Remove a Configuration
Design Requirements:
Ensure the workflow for creating, attaching and removing a configuration is intuitive
Let the user know that once a configuration is attached, the device will inherit those settings at its next transmission
Design Validation
I designed several iterations of the tracker settings UI, incorporating feedback from my product manager and tech lead after each round. After about 5 iterations, we finally landed on a design to test with users.
I conducted user testing via Maze and included a mix of usability prompts, and open-ended and survey questions. I created two tests: one to evaluate the design of the tracker settings UI and one for the create/attach/remove workflow. We received ~15 completed responses for each test.
Results Summary
View/Edit Tracker Settings
Create/Attach/Remove Configuration
Further Validation
Analyzing the results from these users tests led me to feel confident about the designs I made for creating/attaching/removing a configuration. However, I wasn’t quite so confident about the tracker settings UI. The quantitative data we gained from the Maze test showed me where I needed to dig deeper - why was the “auto” function confusing? How are users interpreting this feature?
My product manager and I scheduled interviews with 5 customers and conducted usability tests with them in real-time to observe their interactions and ask clarifying questions.
Users were clearly confused by the design and did not fully understand what we were trying to convey with the “auto” label. It was clear that they expected to see what the actual device settings are and not what they are manually set to.
Rewriting Requirements
My product manager and I revisited the user requirements and decided for this iteration to only show what the active settings on a device are. We also decided to 1. make the ‘alarms’ section non-editable since those settings are currently being dictated by “auto” and 2. remove the ‘alarms’ settings from the configuration. We believed these changes would simplify and streamline the overall workflow for managing tracker settings.
Final Design
See the entire workflow for creating, attaching, removing a configuration, and editing tracker settings.
Reflections
This project was definitely one of the more challenging designs I’ve worked on. There was a lot to consider on the technical side, and we (my product manager, tech lead, and I) went through many iterations of designs and re-writing requirements as new information presented itself.
One challenge was designing the current experience while keeping in mind what we wanted the future state of the product to be. I wanted to create a scalable design with the least amount of technical debt. However, as we were working through the final iterations, my product manager and I agreed to focus on designing the best experience with the current requirements in mind, and not focus so much on the future state given the level of uncertainty on the technical, user, and hardware side.
Because there were many technical considerations (since I was leveraging existing engineering efforts), my tech lead was a great partner in this project. There were many potential user-facing issues I didn’t think of that he was able to identify given his expertise. One of the most rewarding moments was when my product manager, tech lead, and I all agreed that the current backend didn’t support the ideal user experience, and had a rapid brainstorm session to figure out the best solution. There were definitely moments when we all bumped heads, but with patience and an open-mind, were able to collaborate and figure out a solution we could all get behind.