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.)
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.
Previously adding an estimated task required 15 steps, including the enablement of a setting buried in the "betas" section of the product.
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)
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
Location aware/automated time tracking
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.
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 😱.
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)
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.
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 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.
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.
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: