Creating a date picker
How I led usability tests to design a comprehensive date picker component, boosting user satisfaction and efficiency in reporting
Systems design | Component build
Overview
Context
A single report can have up to 18 date range fields, or 30 date pickers.
Reports is a critical area as customers rely on it to access data regularly for presentations or to monitor their progress. When we encountered numerous usability and technical issues with the existing date picker component, we aimed to replace it with a new design system component.
This was one of my first projects as a product designer. It heavily inspired and influenced my continued involvement in design system work.
Challenge
Clients need more flexibility in selecting date ranges when generating reports to better understand their data to make informed business decisions.
Engineers require a scalable date picker to avoid creating multiple picker variations and adding JavaScript hacks to adapt it in different product areas.
Research
I conducted an audit to identify all the date picker variations we support and evaluate each one against the industry’s best practices and guidelines.
There were no early user interviews conducted on the picker so I created initial designs from observations of competitors. The date picker needed to support:
At least 20 years prior to Today
Calendar interaction
Rolling ranges
Custom ranges
Design
I conducted 3 rounds of usability tests to understand:
What are the top actions when filtering on reports? What are the most filtered date ranges — over the past year? quarter? week?
Are they choosing custom ranges or dynamic ranges? Why?
How does a report date picker operate differently from other variations used for events or scheduled tasks?
How easily do users need to select a specific month? year? A specific date range?
Iterations
V1 - Unexpected requirements
We began with tucking all the range options into a parent dropdown with the following interactions:
If a rolling range is selected, the start and end date inputs are disabled.
Custom range is triggered either by selecting the dropdown option or selecting dates within the calendars.
When custom range is selected, inputs are enabled.
I felt confident in this direction, but a new requirement to add a custom rolling range option so users can be more specific beyond “last week” or “last month” brought us back to the drawing board.
V2 - Confusion between dynamic vs fixed
I organized the range types in tiles and removed the calendars when rolling is selected to establish a clear visual separation between the custom and rolling ranges.
I experimented with new terminology replacing custom and rolling with dynamic and fixed.
Within dynamic, there is a dropdown that includes the custom rolling range option in which numerical amount and duration inputs appear.
Usability test participants:
Struggled with discoverability of custom rolling within the dynamic option
Thought that the new terminology was unclear and suggested tooltips or descriptions to better explain the difference
V3 - Date pickers should show calendars
The tiles may have established a more pronounced separation between custom and rolling but they also placed them on an equal level when customers utilize rolling ranges more often in reporting.
To re-establish the hierarchy of rolling ranges over custom, I pivoted to the first iteration with 2 changes:
The dropdown consists of only rolling date ranges.
Custom range selection is shown as a checkbox below the dropdown.
However, in usability tests participants:
Thought that the “select custom range” checkbox was to select the custom rolling range
Expected to see calendars at all times even if a dynamic range is selected
V4 - Version 1 with a few tweaks
We came back full circle and revisited the top dropdown and made some adjustments.
Custom range was moved back into the dropdown and custom rolling option was added as its own option.
Calendars are displayed for all options, but rolling ranges are shown in gray whereas custom is shown in blue to emphasize the differences.
A hover state is shown for rolling range calendars to provide customers a visual indicator that they will be switching to a custom range.
Results
After handoff, the project was buried in the backlog for almost a year before it was picked up.
Although it was out of scope to revise our basic default picker that can replace all the variations in the platform, we were pleased that creating this date range picker helped to create a more consistent experience in reporting.
The component is also responsive and was built in React, deeming it acceptable to add it to our new design system.
The custom rolling option was not included in the first release. This gif also does not reflect all of the rolling options that were included.
Reflections
Creating this date picker was my first taste of being involved in design system work and I thoroughly enjoyed it. Not only was I able to experience all the intricacies that come with developing a component, I enjoyed being proven wrong each round of usability tests.
During the handoff stage, I was surprised and humbled at how many corner cases I have not considered. Working closely with my developer helped train me into having a more detailed eye and proactively identifying similar questions in future projects. The original documentation only had 1 set of pagination arrows for 2 months but together we saw how this design decision limited users, especially in reporting when they’re filtering on several months at a time.
After finishing a bootcamp where projects consisted of entire app redesigns and large-scale features, it was very satisfying to put all my attention into a smaller item that still required the same level of design thinking and research.