Who’s got time to track their work? NOBODY! Who should get paid for their work? EVERYBODY! Our team was tasked to develop a mobile app to help freelancers track their time.
This case study will follow a simple format — the problem, the solution, and a reflection on what we learned.
Our team/my role: Our group consisted of eight boot campers — three UX designers, three quality assurance engineers, and two iOS developers. I was one of the UX designers.
Problem: The current landscape has a broad array of time tracking apps. With so many existing options, what more could we offer? A quick search will show some amazing products — Toggl, Timely, Hours, and many more. These are 5-star rated apps. How could we differentiate our product? What do freelancers even want?
Solution: Research! We built out a short Google survey and targeted local developers and designers. We also sat down face-to-face with seven freelancers to get their insights. It turns out many freelancers do not track their time at all, several of them use homemade spreadsheets. This feedback was promising in that many freelancers are not tied to any of the existing apps, perhaps we could bring something new to the table.
Reflection: By researching such a narrow scope of users, we may have limited our vision. It would have been helpful to get some feedback from freelancers outside of the tech world, maybe photographers, writers, etc.
Problem: She’s right, we were allotted only five weeks before the app needed to be approved in the App Store. Admittedly, we were a team of boot campers in training, not industry veterans. Part of this project would be exploring our limitations.
Solution: Keep it simple! We knew we had to simplify. We were not going to build an enterprise level solution. By focusing on a core function, we could steer clear of dreaming up too many features.
Reflection: Communication with our developers was critical. Understanding our team’s limits helped guide our design ideas. Our open communication with the developers was the key to success.
Problem: So what do we actually start building? Who has the final decision? With three designers on the team and no clear hierarchy, this was ripe for conflict. How do we form a unified vision?
Solution: This did not come quickly, but we eventually found a system. We would each wireframe our individual ideas and then come back and vote as a team. In the case of a stalemate, our developers would have the final vote on a design decision.
Reflection: A systematic decision process should have been in place from the start. It would have saved time and conflict. Had it come earlier, we would have been more efficient.
Problem: Once we started molding our ideas together in wireframe format, we moved towards a low-fidelity model. But we weren’t sure what would work. What would be intuitive for the user? Do the icons make sense? Are the user’s goals met? Are their frustrations eliminated? All these questions needed answers.
Solution: As soon as we built a function prototype (via InVision), we started our series of user testing. We developed a standardized task list we could all test and then easily compare results. This feedback drove the evolution to the high-fidelity model (seen below).
Reflection: Once testing started, we found bugs in our task prompts — the phrasing was misleading at times. This may have muddied the water with the feedback. In hindsight we should have reworked the task prompts after each user test.
Problem: Once we handed off the high-fidelity design, the design process was far from over. Now we had to quickly find replacements to the features, views, transitions (and more) that our developers had to scrap. For example, having a project tile expand downward in a seamless transition would not be possible (several design ideas like this got cut).
Solution: Communication and accessibility. We had to be on call as the developmers hit walls. We would quickly brainstorm and compromise on a solution. For example, with the project tile expansion, we found a way to keep the user flow intuitive and not overwhelm our developers.
Reflection: During the earlier stages of the design, we should have had the developers sitting in on the conversation. Parsing out design ideas would have helped too — rather than dumping a final prototype all at once. We should have divided out smaller pieces as not to go too deep on designs that quickly went to the graveyard.
Problem: We made it all the way to a functioning product, but never really gave it an identity. Early on we brainstormed names and icons, but lost focus of the overarching brand. I suppose it’s like naming a pet, you need time with it to find the right name.
Solution: “TimeCrumbs.” Our app was focused on tracking the small pieces of time that go untracked and unpaid. As the small pieces add up to significant a amount, we noticed this is what our app did well. To retroactively brand this app, we built out a few onboarding pages to hopefully set the tone before users jumped in.
Reflection: Perhaps having an identity or mission statement before building a product would have helped. Although we did have data, a persona and the usual UX steps in place, I think branding early on would have been a helpful guide.
Conclusion: This was my first project working with developers, and it was a formative experience. With multiple cooks in the kitchen there will be head butting, and lead one to shout— “ain’t nobody got time for that!” However, it was a team effort and I would not have been able to do it on my own.