The journey of a date picker
Our daily interfaces are made up of very tiny elements that come together to form the products that we experience everyday. It’s how all of these elements work together and communicate with each other that dictates how that experience would be perceived by us. Among all this, it’s easy to overlook the humble date picker, a seemingly mundane component of countless applications and websites. You’d have used it for scheduling appointments, booking flights, and setting reminders. It’s so ubiquitous that it often fades into the background, taken for granted in our user experience.
Crafting a date picker that seamlessly fits into diverse contexts isn’t as straightforward as it might seem. It’s a journey filled with challenges, where seemingly minor decisions can lead to user frustration and confusion. We had to consider things like how to show the calendar, how it should submit, how to accurately represent the date, what the selection interactions should be and much more. These may seem like minor details, but they had a big impact on user satisfaction. We thought this journey was worth sharing because it shows how even the simplest things in design can be surprisingly challenging. Today, we’ll delve deep into the world of date pickers, exploring the intricacies, pitfalls, and triumphs of designing a seemingly simple tool that stands at the crossroads of form and function.
Why date pickers?
Primer is a payments infrastructure product which allows merchants to accept, automate and optimise their payments. In order to optimise a merchant’s payment performance, we’ve built Observability, a payments analytics suite which presents payments data in a digestible format enabling merchants to make the right decisions. Sometimes, you need to zoom in on a particular slice of data to get a better view of what’s happening. That’s why we’ve got filters for different properties, and one of those filters is a date-time range. This nifty tool lets users focus on a specific period of time, which can be a game-changer when it comes to understanding what happened and exactly when.
First launch
A date picker isn’t something that would be developed from scratch on the first go and I believe it’s a good decision. Almost perfect date pickers have been made multiple of times, readily available in the form of libraries, and making one from scratch takes a lot (I mean, a LOT) of time. Our need for a date picker started from a single date & date range selection, which any of there pre-built libraries could fulfil effectively.
So, we used one and it worked for a long time until we fine-tuned our requirements realising that we needed something more than just a date picker — we wanted a date “time” picker to provide users with super precise control over their data. This decision was also supported by our growing design language, which dictated that we would need a visually different date picker that matches with Primer’s design language — clean, simple & functional.
Early challenges
While we were building our custom date time picker, our developer, Euler, noticed something interesting about the date range picker. It had a default interaction that automatically submitted the final range selection as soon as the user picked the end date. While this sped up the process of getting results, it didn’t account for any potential errors. Additionally, there was no clear indication to users that their chosen range would be submitted immediately upon selecting the end date.
To tackle this issue added an action bar at the bottom of the date picker to allow users to review and modify their selected range before hitting the submit button. This change provided users with more control and ensured a smoother experience.
Whose time is it?
When you’re dealing with a global product like Primer, one tricky factor to consider is time zones. I’m not talking about Einstein’s general relativity here, but the kind of relativity that comes with comparing time zones. For example, if it’s 01:00 PM in London, it would be 05:30 PM in India. Now, picture this: you’ve got a dashboard that’s pulling in payments from all over the world, each in its own time zone. How do you know if the date picker is speaking your time zone language or your customers’?
This was a real head-scratcher because it could affect all of our users. We knew we had to find a way to make it crystal clear which time zone the date picker was using. As we researched more about the time-zone implications, we realized this wasn’t just a date picker problem, it was a dashboard-level issue as well — our dashboard didn’t give any hints about what time zone it was operating in.
To tackle this issue, we made two moves. First, we inserted a time zone indicator on the dashboard topbar. This enabled users to see that every chart and statistics was playing by the rules of a specific time-zone.
Second, we added a time-zone indicator in the date picker itself to guide users while setting those date filters. We brainstormed a bunch of spots to place that indicator, but in the end, we settled on placing it right where the time control sits. Simple and effective!
Selecting range presets
Let’s talk about something we haven’t dug into much yet: range presets. In the earlier versions, these presets were basically buttons that, when clicked, would fill in the date range for you and hit that submit button. Seemed like a time-saver, right? Well, not so fast. We had to make a trade-off in terms of design and resources, which meant we didn’t show the selected date range. So, if you picked “Last 7 days,” it would auto-fill the dates, but you wouldn’t see which range you had actually chosen.
That’s when David, our analytics engineer, came in with some fantastic feedback. He suggested that a hybrid input field — one where you could pick your own dates and another to select those nifty range presets could be helpful for our use case. We loved the idea! It treated both the controls independent of each other which was a clear logic and an overall better experience than before.
This change gave the users the power to choose how they wanted to do things. They could tinker with the input date field and select their dates without any fuss or distractions. And if they were in the mood for those handy presets, they could simply pick one from the preset range, again, without any interference from the date picker.
Time for the journey to end
The aim for this journey was to give a glimpse of how something as simple as a date picker which we use in almost every product isn’t actually that simple. There are many things that can go wrong, and how much thought goes into designing something user friendly for a specific (in this case, complex) context. These elements can have a rich and intentional evolution of their own with the help of feedback. Embracing evolution is a key principle of our design system, Goat and this date time picker is a crucial part of Goat. It’s difficult to make a perfect timeless component on the first go because the product changes and the requirements also change, so why should the component remain the same?
Stay tuned for more behind the scenes of our design team and our design system too. See you in the next one!
