TimeCrumbs for Freelancers — A UX Case Study
Download the app: https://apps.apple.com/us/app/timecrumbs/id1489248477
*Featured* (12/2019–1/2020) on the App Store in the “Apps We Love Right Now” section hand-picked by the Apple editors.
The Situation
Freelancers are jugglers. They often juggle multiple projects, clients, and jump from one task to another. Managing and tracking time is crucial to making their work worth it, but they need a quick and simple process that doesn’t impede their flow.
Brief. We had a broad brief for an iOS app for freelancers: How might we help freelancers track their time? Can we help them figure out how much to charge an hour? Does budgeting need to be a part of this equation?
Scope. We had 6 weeks to design and develop an iOS app for iPhone and iPad.
Roles. Our team consisted of 3 UX designers, 2 iOS Developers, 3 QA Engineers, and our Project Manager.
I led our team of UX designers through research, design, and prioritizing daily tasks. I conducted interviews and user tests as well. I was the main point of contact for the developers and the spokesperson in our sprints and daily stand-ups. I made sure my team was on the same page, everyone’s voice was heard, and our assets and designs were organized.
Ready, Set, Research!
Problem: Define freelancers’ key pain points during time tracking and narrow down the scope of the app.
Solution: Before we started research, our PM assigned tasks and due dates on Jira to keep us on track to ship in 6 weeks to the Apple store. I communicated clearly as I updated our team in our weekly sprints and daily stand-ups.
As we listed our assumptions we saw where we needed competitive analysis, more research, or questions to ask in the survey and interviews. Freelancers face many problems, so it was daunting to begin research — it was a bumpy ride due to all the potential opportunities for the app. We talked through many potential features extensively.
Competing apps had a lot of features, but often felt too complex and intimidating to learn and made the barrier of entry fairly high. It helped to understand the strengths and weaknesses of the resources available to freelancers because it defined the gaps that we needed more input on in the survey and interviews.
The survey ended up being very difficult to phrase the questions well and it took a lot of collaboration and iterations, but we prevailed! and received 32 insightful responses from freelancers. These responses, along with our seven freelancer interviews, gave us the confidence to narrow down the main pain points and areas of opportunity: juggling 1–3 projects at a time, struggling to accurately track time without a process or app, leaving money on the table because of inaccurate time tracking, and wanting the transparency of their time (for client invoices or personal insight).
It’s MVP time!
Problem: Determine a MVP (minimum viable product) that would be feasible with our team, resources, and time.
Solution: In order to create a MVP that would be useful for our users, we needed to define who that would be and frame our product. So we combed the data for the most common issues, frustrations, and goals. Then we incorporated those into the persona, Felipe, to represent our main users.
Based on the goals of our persona, we developed our user story map and MVP. We started recognizing that the narrative and goals were too broad and we needed to cut down to focus on the main feature of the app: time tracking.
Initially, we wanted to help new freelancers validate their rates based on local rates and experience level. We also wanted features to make payments/money conversations easy and professional, especially with payment reminders. However, these features were detracting from the basic function and goals of the app, which were most important to users, and would spread our resources thin.
Here’s looking at you, Devs…
Throughout the user story mapping, I asked the developers for ideas and what was viable — before jumping into designs or settling on an MVP. I made a point to sit at the same table with them to have quick collaboration on our design ideas and understand their process and skills better. And they in turn offered a lot of great foresight into how things could be designed best for the goals we had.
Once we narrowed things down, I wanted to ensure they felt confident about the feasibility of the product in the 5 week build out. They gave their input about what they could do with their skills, resources, and time constraints. This was vital information as a designer because I knew our limits and scope better.
We honed in on our persona’s goals and frustrations — then established that it was most important to focus on the main time tracking feature and making it extremely polished, intuitive, and exceptionally well-designed. We used the data collected to back up these decisions, which supported cutting those extraneous features.
Let the Designs Begin
Problem: Freelancers need an interface that has a low barrier of entry and addresses their main goals.
Solution: We collaborated to figure out the main structure of the app with our site map to meet the goals of our persona. This seemed simple, but made us think through each flow thoroughly. We each did 10x10’s of lo-fi designs and came together with our best designs. Discussing the pros and cons of each design helped us settle on the appropriate designs for the functions needed.
We wanted the app to feel different than other time tracking apps. But we kept coming back to the main list view and 1-tap timer start because you can get to each project quickly — time is money for freelancers. We also kept in mind that our users only had 2–3 projects at a time on average.
We settled on a design where the user flow and feel of the app would be different than competitors’ with overwhelming data and buttons squished together. We felt like expanding the timer when you press ‘start,’ was a good option to give the user more space to navigate their options.
Our app name, TimeCrumbs, came up in our research when we recognized a pattern of little bits of time here and there that were not getting recorded. Freelancers were underestimating their time — hence the name TimeCrumbs, the little crumbs of time that start to add up. We included a feature to display the “crumbs” of time they logged in under 30 minutes. This would motivate freelancers to meet their goals and continue logging those little bits of time because they can see it pays off — literally.
Repeat after me: Test and Pivot
Problem: The app design needs to be refined and backed by user testing data; develop the best product for users that meets their goals.
Solution: We knew testing would be key to polish and refine our designs, so we created an interactive prototype as soon as possible. We built out the most important functions to test, so that users could have more immersive interactions with the app.
We did three rounds of user testing with over 20 people with a set list of tasks using the key functions. We reviewed our notes between each round of testing and tallied the flows that had a pattern of confusion or difficulty. We adjusted and implemented changes to the designs to address those areas and re-tested. With each iteration we discovered major areas of confusion: such as editing the timesheets, discovering the project detail view, and using gestures to archive projects.
After talking with the developers and our PM, we needed to add the settings again so that we could have a place where users could report a bug and meet the team of app creators. We decided to return to keeping the reminders and tutorial in a settings icon.
At one point in the designs, we had a “log time” option in the tab bar for quick access. However, this became repetitive and seemed to be an edge case if people wanted to assign something to an unassigned project. We discussed the discoverability for the “project detail view” and considered making it a part of the tab bar. After more testing we resolved that it was discoverable where it was. We also added a log history tab due to the users’ desires for a view that showed a full activity view.
In our weekly sprint planning meeting, we decided that we would do an iPad view for the app because it would be useful for our users. I discussed the logistics for different views on iPad with the developers. We settled on the main project view to be a collection (tile) view instead of a list view. This was a big pivot, so we doubled down and made lofi designs for iPad. We designed both vertical and horizontal, while keeping in mind the 2/3, 1/2, and 1/3 views for split screen in iPad.
Visualize this…
Problem: Freelancers need to navigate easily through the app and feel motivated to use it.
Solution: We wanted freelancers to have a feeling of energy, motivation, and a clean and simple layout without looking too busy with a lot of features clogging it up. We created a Pinterest board for inspiration with suitable colors and styles.
To explore ideas, we each designed some views then asked people what components and colors they liked best. We combined the elements that were best received and most appropriate for the direction and users of our app.
We deliberated on our style guide with the colors, a logo, icon style, and typography. Then I designed and made our own icon set for the different tabs and buttons.
We also designed iPad views and established the dark mode style guide, which guided us to a simple button style that worked in both modes. We built out all screens in high-fidelity, updated our prototype, and did a few minor tests.
I handed off all assets to our developers and ensured they were in the format they needed and wanted. I checked-in daily and took efforts to make myself available for any clarifying questions they had along the way.
The handoff was a great learning experience for me on how crucial it is to communicate clearly with the developers. During development, there were several flows that we overlooked and had to revisit, such as, how to display the “fixed” rate view in the timesheet because the money wouldn’t be line by line, as it is with “hourly” and how a tag could be deleted or edited. This process gave me insight on the detailed work that developers do and made me appreciate their skills and perspective!
I also had a stretch goal to do an animation for the active timer view. I did a couple variations in After Effects, but we ended up not being able to use them due to time constraints and complexity of the integration with the actual timer.
Hello Pivots My Old Friend
With less than a week left before shipping the app, our developers came across some areas of the design that had to change in order to hit our deadline. With our users and data in the forefront, we quickly made decisions on cutting certain features and re-designing some views.
Pivot #1: The dashboard view would not have a task or project comparison chart or data visualization, and it wouldn’t be able to select dates to compare.
Solution: We decided other features needed to be prioritized, so we re-designed the page to show only a quick overview of total money earned, time spent, and the TimeCrumbs total. This would only be one project at a time, within a specified amount of time: past week, past month, past 6 months, past year.
Pivot #2: Tagging or naming a task would not be possible to have most used tags saved and would have to be inputted manually for each task.
Solution: Manually inputting simple and frequent tasks would really set back our users, so I asked the developers if we could offer some pre-populated options instead. They felt that was a feasible compromise on the feature, so we determined 4 main options for naming tasks: “project work,” “email,” “phone call,” and “consult.” Users would still be able to manually edit these or input their own task name. We re-designed these views and felt confident our users would still be satisfied.
Lessons Learned
Design Growth
User Testing. There were several tricky areas of giving a task to a user without leading them to discover a feature, specifically with gestures. Testing gestures is an area that I would like to research and practice more in the future. I learned to give more scenario-type tasks instead of direct tasks. Also, the order of the tasks given is crucial to not taint discoverability or flow of the app. I also enjoyed the confidence of making many crucial design decisions that were all supported by our user testing data.
Agile/Scrum. As we built this app in an agile environment, I learned a lot about clear communication and collaboration. I gained a great appreciation for each team member’s input and perspective as I better understood the complexity of the product we designed. It was vital to me to get the developers’ insight early on and throughout the design process. This ensured our app was feasible within our time constraints and we were more efficient in our design process. The weekly sprints pushed us to prioritize the design decisions and implement changes quickly and re-test.
iOS Human Interface Guidelines. My understanding of iOS HIG grew as I asked the developers questions, researched, and collaborated with them on design ideas. I’d like to continue to research and learn the HIG more in-depth because it is critical to the success of the designs I create — and it also makes everyone’s jobs easier.
Developer Relationship. I made a concerted effort to build a relationship with our developers by getting to know them and including them in the process of research and design. I also asked about the development process and asked for their advice and expertise concerning our designs. I learned a ton about what they do and strengthened our relationship and trust.
This was vital because they knew we were doing our best to include them. They also knew we wouldn’t handoff a design that would be way out of their skill level or time constraints.
Soft Skills Growth
Leadership. My leadership skills have grown a lot throughout the design and development of this app. I learned how to communicate our designs clearly in our daily stand-ups and explain our decisions.
Every morning my team would ask me what needed to be done. They trusted that I kept our design files organized and up-to-date for our developers and testing. I learned how to prioritize tasks and recognize areas that we could delegate separately, or when we should all hash it out together. My decision-making skills have grown as I filtered through the user feedback, our developers’ expertise, and our team’s input and opinions. I recognized that people trusted me and looked to me to guide our team, so I took that seriously and gave it my all — even if it meant a lot of extra work on my part.
Collaboration. This app required a lot of collaboration between our UX design team, developers, QA Engineers, Project Manager, and colleagues. It was exciting to learn how each group had different perspectives and how to make sure every voice was heard. I practiced active listening and made efforts to make sure I fully understood the views of others. I’ve learned that pure collaboration requires you to check your ego at the door, so that the best ideas can rise to the surface. I’m always amazed at the brilliant ideas that evolve through collaboration!
Feedback (giving & receiving). I have strong opinions about our product in some areas and I’ve learned to personally disconnect and let the feedback sink in. I allow the feedback to do its job of refining the product to the best solution. This can be hard, but I’ve learned that it always pays off to implement the appropriate feedback — even if it’s not what I initially thought would be a good idea. I’ve also grown a lot in how to give feedback in a constructive and collaborative way, so that others always feel validated and valued. I try to look for solutions and not shut-downs.
Encouraging Teammates’ Strengths. I’ve grown a lot in my ability to recognize my own strengths and weaknesses, as well as seeing and encouraging the strengths of my team members. Kyle has a lot of creative ideas/unique perspectives, as well as great feedback in implementing changes after user testing. Elimisha is great at asking questions and covering our bases, making sure we don’t miss anything through each user flow. I relied on their strengths and learned how to encourage their input and ask for their expertise. I made a point to let them know how valuable they are to the team and the success of our app.
Next Steps
If I could spend more time on this app, I would love to do more high-fidelity testing and have more time for the developers to implement the features we had discussed in our MVP. We also discussed doing an Apple Watch view, which would be really fun to design and implement if we continued developing this app. Conducting user tests for Siri, iPad, and Apple Watch would be really challenging and exciting to do!
Download the app https://apps.apple.com/us/app/timecrumbs/id1489248477 and test it out yourself!
Happy time tracking!
Shoutout to my teammates Kyle & Elimisha! And HUGE thanks to our developers Austin & Landon for bringing our designs to life!
