The three teams of workforce management initiative, I focused on "Projects" (mainly focused on estimation but also the shell for the other two features pictured here.)
Making Tasks less of a chore
QuickBooks Time
The TL;DR
Helped prevent small-medium businesses from going over-budget by simplifying the estimation and project management portion of our software to allow for easier, granular time-based estimates per tasks.
What'd you do? And with who?
I led product design for the project estimation experience with a team of 8 engineers, a PM and part-time UX researcher. We also worked as a team with 2 other teams of a similar makeup to sequence work and ensure we're all rowing in the same direction.
How long did it take?
The admin experience of task estimation (seen here) took about 3 months. The subsequent follow-up to enable workers to track time to these tasks took about the same time (see project here).
And what happened?
Increase of project estimation rates from 13% to 40% and of those estimates, task-based estimates increased from 10% of all estimates to 50% of all estimates. Decrease of customer complaints/requests regarding task-estimation.
The before and after
Before š§
Previously adding an estimated task required 15 steps, including the enablement of a setting buried in the "betas" section of the product.
After š
The new experience. Add, update and remove tasks in one space! Adds a clear way to choose between the two estimate types (total hours or by tasks)
Let's start with some background
What is TSheets?
TSheets (now called QuickBooks time) is a planning, time tracking and reporting tool across desktop, kiosk and mobile for small-medium businesses.
And where do you come in?
I joined as part of the workforce management initiative within TSheets, an attempt to reduce churn and attract larger customers by offering more complex functionality offered by competitors (project estimation, communication and automated time tracking). This was split between three teams
Projects (me)
Communication
Location aware/automated time tracking
Projects visualized the estimated hours on a project relative to the actual hours used by the person or people on the project. This helped owners and managers address projects before they went over budget.
And why was Projects created?
Spoiler alert- It's all about the Estimate vs. Actual
Projects was created due to the insight that 70% of a projectās cost is labor, which often goes over and is invisible to all but the most vigilant admin. This team focused on helping visualize and understand how estimated labor hours were tracking with actual hours being used by the team.
Estimating a project well ensures
You (and your employees) are paid for your labor appropriately
Your margins remain healthy
You set and meet (or exceed) expectations with your clients.
So...what was the problem?
15
steps
4
areas of the product
1
"beta" feature enablement
to add a task š±
Turns out this old experience had discoverability, content design and usability issues. Which we found out after the three steps listed
Task-based estimates weren't utilized, because they were buried, required extensive product knowledge and an enablement of a feature that was turned off by default
And on mobile, adding an estimate wasn't even possible...
How'd we know?
In user research interviews, we kept hearing people say "I wish I could estimate this project by tasks." [which confused us..because they technically could š§]
Quantitative metrics indicated people weren't adding estimates much š© which confused us because we had people asking for it all the time!
An experience audit of the task add experience (primarily on web š„) I led with my team revealed adding a single task with an estimate took 15 steps, in 4 areas of the product and enablement of a feature turned off by default š±.
The Project detail view did not display tasks...or much of anything else on mobile
And employees couldn't even clock into tasks in the mobile version of Projects
In fact, the detailed view of a project (seen here) on mobile had LESS information than the card view. Unfortunately, the team assumed employees would be able to bridge the gap between two different entities (Projects (the new one) and jobs) and ignore the labeling on the mobile clock-in screen (which only used the term jobs and custom fields. No mention of projects/tasks)
So how'd you fix it?
Who's doing it better?
A quick competitive/comparative review gave me some ideas for how to simplify the task creation and estimation experience. Here's a few of the experiences I examined.
Initial Designs and Alignment
Testing, iteration and validation
Synthesized result findings presented to PM and Eng lead for alignment. Positives, negatives and neutrals features
Small tweaks for big wins
Leveraging my UX research background, I devised and ran a 3 task usability test to validate designs on usertesting.com. (Check out the study plan)
I chose usertesting.com as the task-add experience was relatively simple and straightforward. I also didnāt anticipate needing to do a significant amount of follow-up or complex root-cause analysis with participants.
Given that my PM and I had disagreements on certain copy and interaction patterns, I felt it was best to get objective results to make final design decisions. I summarized the findings and presented them to the team to help us align on final copy and interaction patterns.
Results by task showed areas for the team to hone in on
Results resolve ruptures
I find test results slide like this often help teams align on problem areas in the interaction. In this case, it was copy that my PM and I had disagreements on. By showing customer verbatims, objective test results with good root-cause analysis and sharing test recordings with him, we were able to come to a more objective decision.
š”Most important insight from user testing -
Given the way we were creating tasks in the back-end, we didnāt have the ability to auto-save tasks as they were updated or added.
In the user session, a customer voiced confusion about whether the system would auto-save or not. This allowed us to write and place error-messaging that would prevent accidental deletion or loss of work.
Implemented Designs
The redesigned experience reduced the steps from 15 to 5.
Lessons learned
Content is king
Unfortunately we donāt have a content team, but we do have designers that have more experience in UX writing. Working with them may have alleviated some usability discussions and internal conflict within the product team.
Ask for clear decision-making model earlier
As a new designer, I was eager to get to work and prove myself! I ran into challenges though when the previous designer and I disagreed on interaction patterns. He preferred a more āwait and see if itās an issueā approach while I preferred to use heuristics to pro-actively avoid issues. He was half on one team but still felt he was the lead of Projects, so we came to a few impasses. I was able to clear it up by having an honest conversation with him, my PM and dev lead about how we want to make team decisions. In the future, Iāll probably ask for that upon joining a team to avoid unnecessary conflict.
Better understand ecosystem integrations at the beginning
TSheets was acquired by Intuit a year before I was hired. Theyāve been working on integrating TSheets Projects with QuickBooks projects. While I knew this was happening, I didnāt ensure I fully understood how data flowed between systems when working on tasks. Luckily, the experience we designed works for QuickBooks connected customers but Iād like to be more diligent about understanding system maps and data flows on similar experiences.
Next Steps
My team was under significant internal pressure to deliver on a tight deadline with the initial experience. Weāre now starting to discover what features are missing from tasks and deciding on how to prioritize them. These include:
Re-introducing Custom Fields to provide upgrade path to task-based estimates for existing customers
Adding task Status (Done/Not Done)
Assigning tasks to employees (a technical nightmare apparently š±)