Dynamic time periods

Re-designing our date picker to remove redundancies, create more focus, and enable users to compare time periods more easily

DTP Version 1

The date picker you see on the left is the version we used in the Sisu product in the beginning. While it solves for the use cases we had, including comparing a more recent time period to a previous time period, having custom presets, and the option to manually type in dates or select them on the calendar, we ran into numerous issues with our customers.

First, the dynamic time range in blue (the more recent time period) needs to be selected by the user first but it appears as the second time range in the calendar. Next, the yellow time period (the “previous time period”) needed to be selected second but that time range could only occur prior to the blue/recent time period. Confusing, right?

To make matters even more confusing, these particular restrictions aren’t mentioned anywhere on the time picker.

Furthermore, customers were getting confused after selecting a blue/recent time period because many of the custom preset options were no longer applicable to the dates they had selected. However, this calendar didn’t offer any language or visual indication that custom options like “Last 14 days” or “This quarter” were not longer applicable to their data ranges. Instead, these options remained active and, if clicked on, would change the recent time period even if the user had previously selected a different time range.

Finally, from a visual standpoint, this date picker didn’t fit into our design system and clicking into the “Custom” section led users to another date selector that was an even further departure from our visual language.

Project constraints

This project required thinking through traditional date picker interaction patterns like those seen when selecting date ranges on Airbnb, booking a flight on Expedia, or booking a flight on Google flights. However, in the Sisu version, the constraints were very narrow as the user needed to:

• Select two date ranges to compare against each other and

• The dates cannot overlap

• Recent time period needed to be selected first and the previous date needed to be selected second. However, visually laying this out proved to be a challenge as the recent period was seen first and the previous time period second

• Users needed to be able to create custom date ranges that were intuitive to use, easy to understand, and functional within a dropdown

• Show users what date ranges are available to them (derived from their dataset)

I never knew how complicated date pickers could be until I got into the weeds of this project :)

Initial clean up

To start cleaning up the date picker, I started by removing the external custom presets which I believed were distracting, not in the correct location, and redundant. I also wanting to bring in more supporting language to help guide the user in understanding what they were doing and how their inputs/selections would impact what they were seeing and their outputs. I also updated the visual design by bringing in more white space to create more balance in an effort to create a more modern and clean UI.

I worked with a teammate to tweak the actual calendar inputs, which you can see in the image above, to allow the user to change the month and year using a dropdowns and inputs, more familiar user patterns. Another requirement was to enable users to select a custom preset like last “X” days, weeks, months, quarters, or years. There was a very limited amount of space to work within but I felt that it was an important decision for the user to make. As a result, I elected to surface these options rather than put them in a dropdown.

Getting into the weeds

I also brought in more fail safes for users, like progressive disclosure, to help guide them through the correct order of operations. For example, certain controls, like the auto advance or including the current day in their time range wasn’t activated until the recent date range was selected. I also brought the selected date ranges out of the calendar and date boxes and presented the information to the user so that they could easily reference it.

I also polished up the date range color relationships by “activating” the color when a date range was selected to enable an easier association between the calendar selection and what appeared in the main modal.

Some final levels of polish included bringing in the success check mark to indicate that the user had chosen available date ranges and a better visual language in the calendar to indicate which dates were accessible and available.