In-depth look into designing a custom date picker view

Designing EarlyBird and the goals we set made us question and analyze every part of the interface: from flow, to errors to the way people select future orders. Initially, we designed and tested with multiple prototypes the UIPickerView from Apple. Our intentions for using the picker view were for the reasons of familiarity. Upon testing the picker view, we discovered a few problems: it was too slow to pick a date and time, as seen in a live prototype below. The picker view serves the OS incredibly well but it wasn’t efficient for our purposes. In addition to the issues of usability, it was also incredibly limiting, in relation to the API. There wasn't a lot we could do from a visual point but also from an organization point of view.

The Problem

The problem I witnessed and one that lead me to design this interface was the amount of frustration errors produce for people. In our case, a typical error will not be Amazon Web Services experiencing an outage or Stripe having problems but people’s cards getting declined. What happens typically is an alert view is presented with very vague language leading to confusion and frustration. It also fails in two very important areas: avoiding confusion and people failing to buy the product they were intending in buying. Not only does this fail people because they are often confused but it also fails the business because the interface didn’t adapt to possibly ask users to try another card or communicate in a clear way what happen and suggest what they should do next.

The Constraints and Barriers

Understanding the constraints in designing a new picker view was really important. One of the initial problems we faced, and one that the picker view from Apple solved really well was dates. We wanted to let people order well in advanced, at least a week ahead of their current date. Initially, our picker view just had the name of the day and an indicator indicating that an additional element would drop below it. The best way to indicate further dates was to add the date stamp below the name of day. There was very little room and the way we formatted the date had to be considered. Ultimately, we concluded that month/day was the better option and the only option that really fit in our interface. At last, our biggest constraint was the limited size, and this applies more so in terms of width. Inspecting closely, all of the text inside the picker view is medium in boldness, rather than regular, with the exception of time slots that are not available. Our date names are also shortened because the compromise was to either decrease the text size or shorten the day names. People are more familiar with shorten day names, it’s in our calendars, time stamps for various online services and banking.

The evolution of the picker view

Ultimately, after much iteration and testing we arrived at a simple two step solution for selecting a date and time. We segregate both date and time. Upon tapping a date, we reveal the available times. This enables people to select multiple days much faster and reveal the available times. Creating a custom date picker was the right decision, as proven by internal prototypes. People would consume a lot less time picking dates and times and it was very consistent with the rest of the interaction: the entire flow of purchasing a sandwich consists of tapping interface elements instead of scrolling.

The Solution

After many prototypes, we built a picker view that fit our needs: a picker view that is fast to browse, consistent with our experience, not just visually but also in how people select options and a picker view that let's us communicate vital information to our users.

Conclusion

To conclude, prototyping played a huge part in designing a custom picker view and measuring its effectiveness. Like any challenge, it proved to be an incredible learning experience. At the end, the custom picker view improved the checkout time and the experience for users.