Redesigning the most used UI component using the most sophisticated design tool – data.
Our senior account manager pinged me for the second time, “Can we fix the date-picker?”. I have been postponing it for a few months as the existing date-picker was working fine but there was definitely a room for improvement. (Is there anything, expect things not designed by humans, where this is not the case?) Here’s what she wrote:
“Amrinder having a huge problem with the date picker and the “custom” time period. Having to click through the months when I want to do a whole year or more is too many clicks. Also when using the picker, having the start date same and changing the end date is near impossible. Any chance we can go back to the old way where we could manually input year if we needed?”
I promised to look into it the following week, and keep her posted.
What’s wrong with the existing datepicker
The existing date-picker doesn’t allow you to input dates. One can only click her way to select a date range. We have 1-click selections for last 7 days, last week, last month, and last 30 days but to select any particular month or other time periods such as last two quarters, and one or more years users have to click on the calendar’s previous/next navigation buttons multiple times. It was simple and error free way of selecting a date range.
This was not a feature request, it didn’t come from R&D team or our CEO or sales or marketing. This came from one of our account managers. To verify this, I reached out to a few other Account Managers and asked if they received any comments/feedback on the date-picker.
Let’s study the usage data
After they confirmed, I decided to look at the usage data. One of our front-end developer who mostly worked with me agreed to participate in the research. She reached out to one of our developers and collected date-picker usage data for the last 8 months.
We posted our research on Slack to encourage others. This was a prime example showcasing how data can help learn more about the problem and assist in designing a better solution.
Using these insights we decided to break the date-picker in three sections:
- A drop-down with list of most frequently used options
- An extended drop-down, where first tab is editable date inputs
- Second tab with ability to quickly select months, quarters, and years
I shared these sketches with our dev lead to get his input on efforts and time it would take to build. He suggested we break it down into two releases as the second tab was a unique UI, something the JS library they were exploring didn’t support.
What I Learned
- Encourage AMs to actively share user problems, feedback and requests
- Use quantitative data more often
- Dig deeper to pull insights
- People are ready to step up if given opportunity