Besides working on the core functionality of the app, another round of UX design was taking place. Whenever I had a new pressing idea, needed a break, or felt drained from working on the core flows, I would shift to working on additional functionalities. I called these UX design cycles because, though not as structured as the initial phases, each new feature and flow went through its own cycle of research, definition, ideation, conception, prototyping, and testing to ensure they fit well into the overall user experience. Besides time logging, reports, and goal tracking, the additional flows that required this separate cycle include conditional reminders, shared challenges, tasks, AI support and suggestions, home, watchlist, onboarding, and authentication.

As the project progressed, I found myself diving into additional research and definition cycles for each new feature or flow. While it wasn’t as formal as large-scale user research, this iterative process helped refine my designs and make them feel more cohesive. I focused on understanding the needs and behaviors of the user, as well as defining the core functionality by identifying the goals and challenges specific to each feature, analyzing similar apps, reviewing design patterns, and mapping out possible user interactions, and then defining the key elements and structure for each flow.

Ideation and conception cycles for extra features were more flexible than the initial stages. I adjusted my process based on the complexity of each flow. Some flows, like reminders and tasks, already had a well-established conceptual model or closely resembled patterns from other solutions, so I felt confident skipping conception and moved directly into designing and prototyping. Other flows, especially activities hierarchy and public challenges, were more complex and needed a solid, clear structure before moving forward.

The conditional reminders flow, for example, was inspired by the smart goals concept but required additional thought and design to adapt it for the app. The idea was to provide users with personalized reminders that would trigger based on specific conditions related to their activities or categories. Another example is the task management flow which largely adopted the basic structure of popular apps like Google Tasks and others, as they provided an effective and familiar way of managing tasks. The main difference was organizing tasks within categories and/or linking them to specific activities.

On the other hand, the activity hierarchy flow needed careful thought about how activities would be grouped, nested, and organized to ensure that users could intuitively understand and manage their activities, and the public challenges flow needed defining how users could turn personal goals into public challenges, share them with others, and track progress together. Both flows required a deep dive into the structure and logic before moving on to visual design or prototyping.

Similar to previous stages, I began these new prototyping and testing cycles in parallel with some other stages. The visual design of the new flows wasn't as challenging as the earlier flows because I already had a solid framework to work with, and its process was similar. The difference was refining color, typography, layout, shape, icons, and other styles ensuring aesthetics, functionality, consistency, and accessibility.

Initially, I divided the color wheel into specific hue ranges corresponding to primary colors, with each range representing a single category. Within each hue range, I used different saturation and brightness values to generate different shades, tones, and tints to differentiate individual activities. I then manually checked for accessibility and removed colors that didn't meet contrast standards.

Using the HSL model to generate activity colors quickly proved ineffective. Since the model doesn't account for the perceptual differences of different colors, hues with different saturation and lightness values didn't always appear visually distinct. Even with different saturation and lightness values, it was difficult to predict which colors would appear distinct from one another. On top of this, generating colors with this model also caused issues with visual harmony. Colors of different hues, even with similar saturation and lightness, often clashed and didn’t complement each other well which led to a visually inconsistent user interface.

This was the perfect opportunity to explore how these systems were originally created and revisit their assumptions. During this exploration, I discovered Material Design’s tonal palette, which adjusts tones and chroma instead of saturation and lightness to account for perceptual color relationships. And Although it still required an algorithm for optimal contrast, it was more intuitive and scalable than the HSL-based system, so I decided to adopt it for the project.

This color system, however, wasn’t perfect due to some inherent limitations. When there were more activities within a category, the available differences in hue, saturation, and brightness within each range started to overlap, making it harder to visually distinguish them. Similarly, as the total number of categories grew, the limited number of hue ranges available became stretched, reducing the visual distinction between different categories. Additionally, ensuring accessibility limited the range of colors I could use, further reducing the options available for distinction (i.e., inside each category) and differentiation (i.e., between categories). Although the system ensured accessibility and maintained a balance between color similarity and distinction, this scaling issue became more noticeable as the number of categories and activities exceeded a certain point.

To work around this limitation, I added a new button that allowed users to temporarily switch the colors of activities when they noticed the visual distinctions becoming unclear due to the growing number of categories or activities . Once they’re done, they could click the button again to return to the original color system without permanently sacrificing the visual consistency of their activities.

Unlike the projects I previously worked on, I used design tokens in this one's design system to achieve better consistency, scalability, and flexibility. Having learned from Google's Material Design 3 (M3) guidelines, It became clear that using tokens to manage colors, typography, spacing, and other elements was much more efficient than styles.

Working on this project from concept to completion was also an opportunity to gain practical, in-depth experience in project management. I originally aimed to finish the project in 1-2 months, but every time I added a new feature or made a tweak, it stretched things out. Before I knew it, 6 months had flown by. It literally  was a crash course in how scope creeps can snowball, delay progress, and turn a small project into a never-ending loop of "just one more thing." I had to learn the hard way, again, that sometimes "good enough" really was good enough if I ever wanted to actually finish.

I also quickly realised that a purely predictive approach (Waterfall) is hard to apply in software design becaue of constant testing and iteration. The process was never truly linear, and instead of sticking to a fixed plan, I needed to adopt a more adaptive (agile) and hybrid approach. This way, I didn't have to compromise flexibility and improvements as new feedback and insights emerged throughout the project.