How to beat the ​“paradox of choice” in UI design

“Less is more” is one of the most important minimalistic design principles every designer learns: you read about it a lot, you know it’s really important, but still you might get it all wrong. The important thing is to come around, learn from it, and evolve. And so we did.

With the release of Todoist Next in January of this year, we introduced a new design alongside new features. From the beginning, our focus was to modernize the app and improve the user experience across the board. Postponing tasks was one of the things we especially wanted to improve. But it wasn’t as easy as we expected…

Out with the old

The previous version of our app had only two options when it came to rescheduling tasks. Either you chose ​“Do it today” or ​“Postpone” (that could be either tomorrow or next occurrence for recurring tasks). Whenever you needed a bit more control you needed to use the full calendar, or type in a new date. On the Web and desktop clients, it’s really easy to type in a new date and time, since you have the physical keyboard and mouse. But on mobile, the experience was a bit broken. You could type in a new date but wasn’t very convenient, especially when you’re in the ​“one eyeball and one thumb” mode.

In with the new

Since the old system was so limited, we really wanted to give our users more options and make it much more visual so that it would be more flexible and easier to use on mobile devices, but also great on other platforms. At that precise moment, the choice was more.

Since we wanted to make a great mobile experience, we used the ​“mobile first” approach in the development: if it works on mobile, it’s easier to make it work on desktop where you have more screen space and more precise input methods.

With all this in mind, we started to explore how it could work and which direction would most help our users. We researched other solutions that were trying to address similar issues to our own, but we felt that most of them were limited and that we could improve upon them, although some of them are really good solutions.

A ​“smart” scheduler was our big idea. A smart system that would look into your tasks and would suggest the best dates magically. For example, when you reschedule a task for next week, the system would look into your current tasks and select a day in the next week with no due tasks. And it would be awesome! For the user it would be a no brainer, with a really nice interface powered by a strong algorithm to fetch the best dates. For the team, it would be a great accomplishment that blended an awesome interface with solid coding into a solid product.

Early stages of development: from circular menus to really complex sets of options with date suggestions marked on the calendar and additional feedback on tap.

Everything was falling into place with the initial developments, and the first mockups were looking promising. We even started to come up with new ideas about how to make it even more powerful. We added an initial group of choices (today, tomorrow, next week, someday), a classic calendar view option, and ​“date suggestions” that would bring all the magic to the screen. We tried different layouts, even a circular menu, and iterated quickly on the options range (between 6 to 9 options on the screen at a time).

Soon we started to think about how to cut interaction steps, how to increase choice options and reduce taps. One of the options would display the classic calendar but that seemed like an unnecessary extra tap, because we could fit everything into the same screen. And so we tested. And tested.

The uh-oh moment

One of the first problems we detected with the ​“magic” was the lack of feedback on the dates. If the user chose next week, the system added the date but the user had no say in it. Even if it was a free day, you might have wanted the task scheduled for another day. We needed a extra step to show the date that the user could then confirm.

Another problem became obvious: we didn’t have enough information about the users to truly make the best possible suggestions. To do so would probably have required a lot of input from the user or, really, spying on everything they do. On top of it all, the coding of such a system was getting really complicated.

Also, the interface was getting really cluttered with a lot of choices, and too many taps were required for some simple selections. At this point we had reached a ​“paradox of choice” — a term coined by Barry Schwartz—we had so many options that actually selecting one was a daunting task in itself.

The first solution we started with was an algorithmic solution that would do calculations for you. The idea is smart on paper, but a nightmare to implement since we don’t have enough information to make it really smart. — Todoist founder, Amir Salihefendic.

With the precious help of Khoi Vinh (amazing designer and UX guru), we started to realize that we weren’t achieving our goal of simplification, we were making the app more complicated.

Finally overcoming the Paradox of Choice

When developing an app, most of the time your imagination is the limit. This means that it’s easy to go completely overboard. We overselves fell into this trap. From there, we needed to take a step back and rethink the entire system.

We strongly advocate simplicity in user interfaces, so our new visual scheduler couldn’t be complicated. Here, we started by using one of of Sheena Iyengar’s principles from ​“The art of choosing”: cut. The option set was restrained and date suggestions were removed altogether.

Although Android and iOS versions work the same way, the UI was adjusted to better fit each platform. Although it’s the final layout, the options set would still be adjusted before the release.

The layout was also simplified. The final solution is a 3×2 grid of options, with access to a full calendar as one of the options, so it’s easy to know what to expect at any point. Some of the other solutions might have been good choices, but after testing, we figured they were harder to use and required a steeper learning curve. Sometimes it’s just better to keep it simple.

There was a lot of effort put into developing the system and, in the end, we decided on an easily understandable group of choices. All of this in order to offer a great user experience that actually helps the user make decisions about due dates, and ultimately get things done.