UI challenge: A ‘nice’ date picker design
There are plenty of ready-to-use date pickers out there, but how many of them are actually a nice experience to use, especially on a mobile device? By ‘nice experience’ I mean easy, simple and intuitive to use as well as being aesthetically pleasing. I’ll save you the bother of a google search and just tell you the answer to that question; it’s very very few.
We are currently creating a new website for We The Curious (formerly 'At-Bristol Science Centre'), which includes a ‘What’s on’ event calendar. There is always loads going on at We The Curious so part of the brief was to allow users to filter and search through events in a number of different ways depending on their preferences. We spent time at the beginning of the project working closely with the client to thoroughly profile user stories and understand different user journeys across the website.
So, we know it’s highly likely someone using the event calendar will want to be able to search events for a specific date. For example, they’re visiting Bristol 27 Nov - 4 Dec 2015, and they want to find out what’s on at the Centre during that time. Below I’m going to run through this scenario and discuss the solution I arrived at.
I decided that I was going to take a mobile-first approach with this feature; design the whole experience for someone using it on a small mobile screen, which will tackle the obstacles of touch screen interactions and minimal real estate. It should in theory be easy to scale the design up for larger screens later.
When the user selects the date picker button they are presented with a screen which shows only the date picker - it fills the whole screen. They can’t be distracted by anything else, or accidently press something else on the screen. They are on this screen to do one simple job; choose a date range.
When designing user experiences, we focus on understanding what the user is doing and try to simplify their journey. Not every user is the same though, and it is important that we don’t disrupt the process for anyone with a different goal.
When you arrive at the date picker, instead of presenting you with an empty start date and end date fields, they are preselected with todays date. This wont hinder anyone who wants to choose a different start date as they would have to select a date anyway even if the field was empty. But for anyone who is specifically looking for events on today, which we know is likely to be quite a few people, the job is already half done for them. All they would need to to do next is select the tick and they’re done.
Ok, but this user wants to see events for 27 Nov - 4 Dec 2015. The start date field is highlighted as active with a red marker and the user selects 27 Nov. As soon as this action is done, the date picker automatically switches to activate the end date, making a nice assumption that when you have selected a start date your next job is to select an end date.
Rather than than presenting the user with an empty end date field or with an end date of 16 Nov (today’s date) as it was displaying previously, it has updated to the same date as the start date. It’s making another assumption that you may be wanting to visit specifically on the 27 Nov, in which case, hit the tick and you’re done.
But this user is searching for a whole week of events and swipes across to Dec and selects 4 Dec, selects the tick to confirm and they are presented with a list of events for 27 Nov - 4 Dec 2015.
The key to designing this date-picker feature was to take a bottom-up approach to the solution i.e. think about the journey from the user perspective, rather than what the client wants to show them. Research user stories; who is the user? where are they? what task do they want to complete? what is their motive? what device are they using? Once you have worked that out you can make your design decisions based on these and produce a good looking solution which is a nice experience to use.