Initial Research
I must admit, because of my long struggle with time tracking, it was quite difficult to keep my biases in check as I was trying to empathize with people interested in time tracking. Understanding users' perspective, motivations, preferences, and pain points with time tracking and existing time-tracking solutions required detailed analysis of user's comments and reviews along with extensive interviews with students, freelancers, productivity enthusiasts and professionals. But ensuring that my personal experience didn't cloud my view on their experiences required conscious effort in all stages of research.
In this initial research phase, I quickly realized that focusing on every tiny detail of users' experiences with time tracking proved inefficient because it diverted attention from the app's core functionality. Doing so made it difficult to identify and address the KEY pain points and KEY needs that should drive the design. Research into users' experiences with additional functionality and nuances that improved the overall experience was conducted later on once the core functionality was validated and tested.
The collected data helped in shaping a deeper understanding of users through user personas, empathy maps, user stories, and journeys. However, although I focused on understanding every possible user scenario, I prioritized documenting only KEY personas and journeys that would effectively guide the next steps.
Initial Definition
After collecting and analyzing the data, big and small issues with existing time tracking solutions slowly emerged. The main challenge was to group these small issues and express them in a clear, concise, yet precise problem statement that accurately captured the core issues without losing important details.
Once the problems were clearly defined, formulating hypotheses wasn't that difficult. Making GENERAL assumptions about how certain features or solutions could address the existing problems was straightforward; the real challenge was the ideation, conceptualization, and testing of SPECIFIC solutions that addressed these problems in the following phases.
At this point, It became difficult to keep track of all functionalities, so I divided the app into three primary flows: Activity Logging, Reports & Insights, and Goal Tracking, each requiring its cycle of ideation, conception, prototyping, and testing to ensure it effectively addressed its specific user needs and challenges.
Then, I worked on clearly articulating the unique value propositions (UVP's) that would set the app apart from competitors. The guiding principles in this step were simplicity, insights, and personalization. The app should be easy to use, provide helpful reports, and allow users to set their own SMART goals (i.e., Specific, Measurable, Attainable, Relevant, and Time-bound) that capture every possible goal pertaining to time management, making it a more efficient solution for effective time management.
Initial Ideation
Some of the innovative ideas implemented in this app were in my mind before starting the project, but most of the ideas required a semi-structured cycle of inspiration, competitive analysis, and brainstorming. It should be noted, however, that ideation continued across all stages of design; the main challenge was keeping track of all ideas without losing focus on the three primary flows.
To stay focused, I tried narrowing down my ideation to align with the three flows, but as I was looking for inspiration, studying competitors and brainstorming, new ideas for extra features and functionality kept popping up. At first, I intentionally avoided exploring these "irrelevant" ideas to avoid distractions, but soon realized that doing so meant loosing them. Fortunately, I paid attention to this in the early stages, so I started documenting all ideas, even the crazy ones, in a
"parking lot" and then categorizing, sorting, and prioritizing them according to relevance, required time, potential impact, and alignment with the core vision of the app.
Ideation for this project was accomplished through three methods: inspiration, competitive analysis, and brainstorming. I started by gathering inspiration from various sources, including existing time-tracking apps and broader productivity tools. Meanwhile, I analyzed direct and indirect competitors to identify what worked well and what needed improvement in their solutions (i.e., features, flows, navigation, accessibility, consistency, visual identity, etc.).
In parallel, I kept brainstorming and noting down ideas on potential solutions and features that could enhance the main experience and/or add extra value to core functionalities like simplified time logging, or additional features like advanced analytics, smart reminders, or integrations with other tools
Initial Conception
The most challenging part of this project was figuring out a clear, intuitive, and unified structure that brings together the entire flows of the app in a way that made sense both visually and functionally. Knowing that the report section, for example, should be comprehensive and intuitive is easy, but finding the right conceptual framework that effectively structures the vast amount of data, meaningfully presents them, and intuitively integrates all possible features and actions without confusion or complexity is another story. Simply put, structuring information so it's accessible, understandable, actionable, yet not overwhelming was The Challenge in this project.
Throughout this stage, I kept examining how other solutions solved similar problems. I experimented with different conceptual models to group and structure similar elements and actions, hid less frequently used options behind menus, dropdowns, or buttons, added new tabs for advanced options, adjusted relationships between related elements and changed the visual hierarchy to reflect these relationships.
One breakthrough in time logging was breaking free from the project-oriented models used by most apps, where users create projects and tasks, sometimes with recursive tasks nested within each other. Although this approach worked well for managing projects and tasks, it often became limiting when it was used to track time across various activities and categories, and it lacked the flexibility to enable the grouping of similar projects together for collective tracking. For instance, if a user wanted to track time spent on similar tasks across multiple projects (e.g., client meetings or research), the conventional approach made it difficult to get a holistic view.
The alternative approach, instead, applies the same concept sightly differently by using activities as the core building block instead of projects. Users can then group these activities into broader parent categories, and further nest them as sub-activities recursively. This flexible structure opens up endless possibilities. Users can now take full control of how they want to organize activities and categories based on personal needs or workflows. They can create custom hierarchies, track time across these hierarchies, and generate tailored, meaningful reports that reflect their unique time management patterns.
With persistent trial and error, detailed journeys, complex flows, numerous wireframes, and consistent testing, I finally started to "piece together" the entire flows and sub-flows and "see" a clear direction of how everything should be structured. Once I "saw' that right conceptual framework through which everything fell into place, I started to see it everywhere. It's fascinating how this new framework had always been before my eyes, yet I was too framed to see it! I felt like a fish seeing the ocean for the first time, and I gained a new lens through which I could see how complex systems could be better organized.
Initial Prototyping
Typically, when the conception phase is completed successfully, (i.e., when its "architectural blueprint" is well drafted), the prototyping phase becomes mainly about visually designing elements like colors, shapes, and layouts to establish the product's look and feel and then experimenting with interactions to ensure smooth navigation and consistent experience. As simple as it seems, I had to relearn this the hard way.
One of the big mistakes I did in this project was jumping to the design phase too early before having the right conceptual frameworks in place. As I was designing, I didn't realize that I was both wireframing and designing at the same time. I figured I'd be able to design the interior of a house without fully understanding its architectural framework, but I ended up stuck in an endless loop of iteration. My design decisions kept shifting as the underlying structure was still being figured out, and I didn't realize this until I had already invested a significant amount of time and effort into design.
By that point, I had to backtrack and make major adjustments, which only added to the frustration and delays. Fortunately though, it wasn't late enough to course-correct. I immediately started focusing more on solidifying the core concepts and refining the structure before continuing with visual design. It turned out that unlike what I originally believed, most of the design work, in fact, happens in the conception phase, not the prototyping phase
Once the concepts were refined, I revisited the visual design with a clearer undertstanding of how the elementes interacted and related to each other. At this point, rather than focusing on creating a complete design system, I explored various design decisions and experimented with color, typography, layout, shapes, and effects to find the right balance between familiarity and creativity. I wanted an app that felt familiar enough for easy navigation but also stood out with its own unique visual identity.
This was another major challenge. The more I drew from existing designs, the more I found myself unintentionally adopting their frameworks, which, no matter how creative I tried to be, kept shaping my design decisions. It became difficult to fully break free from those influences, and I could always see how my design was framed by the choices of others, which made it harder to establish a user interface that was truly original.
.png)
Then suddenly, as I was designing a list element based on Google's M3 Design System and Apple's design guidelines, I tried tweaking some properties, and to my surprise, this small adjustment led to a fresh, unexpected look. I could have never imagined that seemingly significant differences between how various products looked were actually the result of small tweaks to a few key properties, but once I realized this, the distinction between apps started to blur. I began to see how small design decisions (like how spacing is handled or how colors are used) could have such a significant impact on the overall feel of an interface.
I feel like after this moment, visual design suddenly became much more intuitive, not just while working on this app, but when analyzing other designs as well. The quote: "Good designers copy; great designers steal" somehow made sense, and I began to recognize the common design principles at play across different apps and platforms. It made me realize that design isn’t about starting from scratch every time, but rather about borrowing inspiration from what already exists and then making it your own with a few KEY tweaks that result in a fresh new look.
The visuals of the app kept being changed and refined when I started working on other features, but once I was satisfied with how the app started to look, I started building an interactive, hi-fi prototype. I first revised the principles of motion design to ensure the prototype felt natural through smooth animations, transitions, visual cues, and feedback. Using user journeys as a guide, the prototype was constantly refined to be as close to the final experience as possible to simulate real user interactions and provides accurate feedback on usability, design, and functionality.
Initial Testing
Before starting the project, I planned to start testing once a hi-fi prototype was completed. However, as the work progressed, it became clear that I had to constantly test every design decision from the early concepts all the way to the final prototypes. Before testing on real users, I tested everything myself first. I tested conceptual models, information hierarchy, and alignment with user goals, and then I evaluated functionality, interaction smoothness, task flows, visual consistency, and accessibility.
The cycle of testing and iteration felt endless at first. The more I designed, the better I became, but the better I got, the worse my earlier designs seemed and the less satisfied I became. This cycle would go on forever. No matter how much I improved, there would always be more room for improvement, and my past work would always feel incomplete. I learned to recognize when to stop and move forward, rather than endlessly chasing perfection. Instead of endless refinements that delayed progress, it was important to know when the design was GOOD ENOUGH to meet user needs and expectations.
Once I was reasonably satisfied with the design, I moved on to testing with real users. I tested with users from different personas to ensure a diverse and representative sample for more accurate feedback.
After testing, I collected feedback, analyzed user pain points, and identified areas for improvement. I refined the design based on this input, making necessary adjustments to enhance usability, streamline interactions, and address any issues.
.svg)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.svg)
.svg)
.svg)
.png)
