Flexi-Datepicker
Designing for Complex Scheduling
Redesigned a date selection system to support flexible ranges, multi-granularity input (month/day), and scalable scheduling behaviorrs.
Impact: Reduced selection friction and improved clarity for multi-day event creation.
❗️Problem
The existing datepicker was designed for single-date selection, but evolved to support:
Date ranges
Months + days selection
Group scheduling (polling)
This led to a UI that was overloaded, error-prone, and difficult to scale.
🥊 Why was this challenging?
This problem sits at the intersection of:
Speed vs Precision: Users want quick selection (months) and precise control (days)
Visibility vs Density: Showing more context improves clarity but increases UI complexity
Flexibility vs Simplicity: Supporting multiple selection modes without overwhelming users
🧑🚀 Exploration
Option A: Overlay (iteration)
To reduce cognitive load, I moved the toggle between month and day views out of the overlay card and into a standalone floating button. This improved both clarity and usability in several ways.
the overlay card became significantly less crowded. By removing the toggle from the top section, the layout feels cleaner and allows key information and actions to breathe.
It simplified how users approach quick selections across both views. The interaction now better supports the primary goal of the datepicker, helping users quickly find a rough window to meet with friends, rather than locking in precise dates
in day view, users often navigate across long ranges, making it easy to lose track of the current date. Introducing a “Back to today” action provides a quick way to reorient, reducing friction when navigating across time
Option B: One view at a time
To reduce friction from switching views, we moved the decision earlier in the flow. Users select their preferred mode before opening the datepicker, keeping the interaction focused and uninterrupted.
This simplifies the interface and improves clarity, trading off the ability to switch seamlessly between views.
Option C: Intentional Granularity
The flexi-datepicker was initially designed to reflect how users naturally think about time when planning events. Rather than specific dates, people tend to operate in rough windows. "sometime this month for a quick catch-up" or "later in the year for a trip".
To support this, the design focused on selecting high-level ranges through a month-based view, with the option to refine into more detailed ranges afterward.
However, this approach proved too restrictive, forcing users into a rigid, step-by-step flow that didn’t always match how they wanted to plan.
Option D: Full Page (⭐️ chosen)
As complexity increased, the flexi-datepicker outgrew the overlay pattern. Overlays are designed for quick, lightweight interactions, whereas this experience allow for more complex inputs.
This shift reframed the goal from speed to clarity, requiring the design to evolve accordingly.
We explored multiple interaction models.
Incremental improvements to the overlay failed to address core issues of visibility and scalability.
A full-page approach introduced a context shift, but enabled a clearer, more flexible system.
🔑 Key Decision
We chose to prioritize clarity and scalability over compactness.
Tradeoff:
Lost: Inline convenience (overlay)
Gained: Reduced cognitive load, better visibility, and support for complex interactions
⭐️ The Solution
Dual-Level Selection
Users approach month and day selection differently. Separating these modes reduces ambiguity and gives users greater control over how they define their availability.
The toggle between modes was redesigned as a clear, dedicated action, removing any confusion around switching contexts.
Quick selections were moved outside the datepicker and positioned at the bottom as secondary actions, supporting fast input without competing with the main interaction. To maintain consistency, the same quick selections are used across both modes. This ensures selections remain stable regardless of view, reducing cognitive load and building user confidence.
Persistent selection model
Selections persist across views, enabling continuous editing regardless of mode. By preserving context, users don’t have to recall previous inputs, reducing cognitive load and making the interaction feel seamless.
Coarse → Fine interaction
One of the most common use cases observed in user research was planning loosely defined, spontaneous events without fixed dates. In these scenarios, users tend to start broad by selecting a general time window, before narrowing down to more specific ranges.
It was important for the design to support this behaviour. Enabling users to explore time flexibly, from broad windows to more refined ranges, without friction.
Designed for scale
The system supports long-range selections, including cross-year scenarios. In collaboration with another designer, we ensured the subsequent polling experience remained intuitive and cohesive, even when dealing with extended timeframes.
🔥 Outcome
Beta Test Observations
(12 participants: 4 designers, 3 engineers, 2 stakeholders, 3 external users)
70% faster task completion
Users completed multi-day availability selections in fewer steps compared to .the previous version. Resulting in selection time from 34 seconds to 10 seconds.↓ 35% view-switching errors
Fewer users accidentally switched between year and month views while selecting availability.83% success rate on first attempt
Most users correctly understood how to toggle between months-view and days-view without guidance.Improved clarity in long-range planning
9/12 participants explicitly mentioned the “months → days” flow felt more intuitive for early-stage coordination.Reduced clarification questions
Internal testers (design + engineering) asked fewer follow-up questions about how selection worked compared to earlier prototypes.Positive sentiment on flexibility
External users (friends) described the interaction as “less pressure” and “easier to suggest rough timing without creating specific poll options.”
💭 Thoughts
Simplicity is a core principle of the app, but not every experience should follow the same level of minimalism. Creation flows are inherently more complex, and forcing them into the same system can reduce clarity instead of improving it.
In this case, I introduced more structure and guidance to make the interaction easier to understand in the moment.
One limitation I noticed is that the flow assumes availability is continuous. In reality, people often think in fragments like, “any weekend this month” rather than a fixed range.
If I were to iterate further, I would explore supporting non-continuous selections within the same flow, allowing users to express flexible availability without switching modes.