Curious to know more?

This project started due to the need of having a time picker. At the time, I was creating a form and I needed a date and time picker. We already had a date picker in our design system but there wasn’t anything created for a user to define a time.

As I researched the different use cases where a time picker would be needed, I concluded that it would make much more sense to combine the existing date picker with a new section to select the time. The reason behind this conclusion is that, across all the products at Impartner, some require a date selection, and some require a date and time, but none require time without a date (which is logical since time is usually associated with a date).

With this thought in mind, I started to investigate the possibility of utilising the existing component and simply adding a time picker, which would make it easier for the development team to implement, given that they already had the date component created.

Below is an image of the existing date picker:

As I was doing my research on best practices and key elements of a time picker, the biggest challenged I faced was the lack of existing designs in the market for such a component. Most of the work is focused on mobile apps, and a lot of its features would not be appropriate in a desktop interface, so I created a list of crucial elements as my starting point:

• Support of 12/24 hour format

• Support both manual typing and dropdown selector

• Save option

This list brought me to my first draft:

After a meeting with the rest of the UX team, we quickly concluded that the 12/24 hour format support should be part of the user settings, as it will impact much more than just the date and time picker.

Upon removing this element, the date and time picker became a bit confusing, as there was no proper hierarchy nor distinction between the two different sections, and without a clear definition we could face severe usability issues (mainly because the time selector had no indication of being such, as the image below shows).

After this, I reached another conclusion: we needed a clear section header to inform the user about the content of each section.

Below is a set of images of how this idea evolved and all its different drafts:

During the entire design process, I had several meetings with the UX team and there were two topics where the team was divided:

• Some members disagreed with the usage of headers, claiming it wasn’t necessary and added visual noise. I was on the other side, defending the idea that even though the calendar’s meaning is quite obvious, the time picker isn’t, and adding headers eases the cognitive effort, making it easier for users to quickly scan through the picker.

• Some members disagreed with the usage of the confirmation button, stating that usually a click outside the dropdown should be sufficient to set the expectation that the date and time defined were saved. I was also on the other side, defending the idea that a “save” or a “done” button provide additional confidence to the user.

After all these conversations, I returned to the drawing board to make the final design.