Dropbox:
Time Tracking + Invoicing
Discovery
As a designer on the Professional team, a product tier geared toward freelancers, my initial role was to take an existing design that had been validated with users and bring it up to a higher fidelity for an alpha release. Time tracking as a concept performed well in early testing when presented to users as a way of helping them manage their time while working.
Being integrated with Dropbox meant that, conceptually at least, users found it valuable to see how their time was being divided amongst the files/folders they were actively working in. From there, the intention was that they’d use this information to make decisions about how they might allocate their time to the projects they deem most important and spend less time on the admin tasks of managing their business.
Time tracking concept, desktop tray
Methodology
The challenge I had moving into this project was that the initial concept had been designed and tested for desktop, a product surface my team didn’t own. After taking the findings of the concept test to the owning team and learning more about the limitations of desktop, I needed to pivot our solution to web.
I didn’t know enough at this point to disagree with the value prop, rather I was placing trust in the existing signal we had from concept testing. I decided to index more on usability and making sure the experience of tracking time felt intuitive.
During usability testing, I took this also as an opportunity to see if we could get any stronger signal around value, as this would be a net-new feature and mental model within Dropbox.
Findings from usability testing showed what was/wasn’t working well in the design, as well as gave us strong signal on what users expect from a time tracking tool in Dropbox. Users expect that since we are Dropbox and we have access to all of their files and folders, we should know how much time they’re spending in each and they shouldn’t need to manually start a tracker. However, the results lead us to question the whole model around tracking time against files/folders due to some observed ambiguity around what that meant. Moving forward, it was a safer, more universally-understood option to track time against tasks.
Most importantly, we had strong signal that users were interested in tracking time and using the data to get paid.
Usability testing
While usability fixes were being made in preparation for our alpha release, we opened up a conversation with the invoicing team about possible integration with their product, which was already in beta. During the alpha launch of time tracking, we continued to receive signal around user needs for billing clients with tracked time. To get ahead of our next iteration of time tracking, I worked with my PM to define a new problem statement that would give us some direction on a few concepts we might want to test for the integration:
Freelancers view Dropbox as the backbone of their workflow but there’s no single tool that allows them to manage + deliver content in addition to sending invoices and getting paid.
Users are switching between multiple tools and tracking their info manually in spreadsheets or templates they find on Google. This introduces fragmentation to their workflow, causing them to spend more time on admin tasks than they’d like.
Hypotheses
If we can condense tracking time and generating invoices into a single workflow, it’ll reduce the cognitive load of using multiple tools.
If we can intelligently generate invoices based on user-assigned attributes such as rate and client, it’ll save the user time as they won’t need to manually track this info in spreadsheets as they do now.
Time Tracking, user journey
Goal was to document where the existing time tracking solution might need to flex if we were to accommodate the additional use case of billing clients
Service diagram, user stories
Meant to visualize a two-way relationship, or a handoff, between the time tracking and invoicing surfaces. I wrote user stories to help us define acceptance criteria for the next iteration of time tracking.
Solution & Outcomes
I designed and tested two main concepts with users:
Concept A would automatically group tasks tracked under the same client and allow a user to auto-generate an invoice, based on the total amount of time tracked against said client and a rate they’ve set. Concept A2 is similar, the only difference being how the time tracker is displayed.
Concept B would function almost like a shopping cart, allowing a user to choose specific time entries one-by-one and add them to an invoice.
The concept test yielded a few interesting insights. We heard that Concept A felt more suited to freelancers or members of a team (faster with less thinking), while Concept B seemed to be designed for a team admin (an enterprise tool with more control). We learned there can be a lot of variation in how freelancers set rates; sometimes it’s per hour, other times per project. Finally, we heard that being able to enter time manually without needing to start a tracker would be useful, in case the user forgets.
While the initial time tracking alpha ended up being deprecated due to time management alone being invalidated as valuable for users, my team was able to pass our R&D over to the invoicing team for them to iterate further. This was done to reduce redundancy of having two teams tackling a similar user problem. The invoicing team was in a better position within the org to push the work forward and after all, the user would still benefit from our learnings.