Context
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.
My role
As the design systems designer, the project was under my ownership while working closely with 3 other designers who owned different parts of the Primer product - Workflows, Observability & Payments.
Project duration
3 months (excluding development)
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.
Challenge: Unreviewed submission
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 misclicks or allowed a review stage. A review stage is crucial because every submission would lead to a query in the backend and the whole data on the page would get refreshed. 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.
Challenge: Multiple time zones
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!
Challenge: Preset visibility
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.
Results & Conclusions
-
At the time of writing this case study, the designs had reached the state of the hybrid date time picker with range select but the code was only updated to the last version with the time zone indicator.
-
There were 3 major products where the picker was essential - Payments, Dashboards & Workflow runs. All 3 of them had adopted the new component within 3 months of its code release.