Re-imagining email: What if your inbox was like Tinder?

Originally written for cubeit.io

In the late 2000s, almost 15 years after Hotmail changed the way we communicate, people started to finally understand that the tons of email they received was hampering their productivity. Enter the concept of Inbox Zero, and a clique of people started trying to re-imagine email. With hundred of emails piling up in our inboxes the clutter of information had risen, and where there is a problem, there is a startup trying to solve it. (The latest was Acompli, a mobile app, which Microsoft acquired for a lot of $ a few months ago.)

At Cubeit, we were aware of the problem (we don’t use email for internal communication — Slack is the tool of choice for us), and decided to do a short design sprint to see if we could come up with a solution to the clogged inbox.

The Current Email Paradigm

We began with a few thoughts on the current way email is structured.

• The Paradox of Choice: All current applications retained the traditional list view. This means that the user still has a list of emails to choose from and decide which one he/she will be interacting with. In his book, “The Paradox of choice — why more is less”, Barry Schwartz argues that eliminating consumer choices can greatly reduce anxiety for shoppers, i.e. giving people less to choose from means they will be able to decide easier and do more. With studies showing that an average email user sends/receives over a hundred emails everyday, there are a lot of choices to make. This gave us our first major design input — What if we bypassed the question “Which email from this list is most important and hence which should I act on?”, and forced users to act on emails when they opened the app?
• Useless information: A single email in general is very unstructured in nature. The tangible information needed for a user to consume the message and take an appropriate action is scattered across the length of the email. Also, many a times there is a lot of information inside the email which is unnecessary for the user. For eg, If someone receives a bus booking confirmation email they expect to see their boarding details like location, date and time. They are indifferent to the long list of terms and conditions.
• Instant gratification: The other emerging trend we worked off was the rise of short form of communication. With the advent of social media and chat based applications instant messaging has become the norm to exchange information and just like email, chat based services let the users send different type of file formats with ease. In chats the hierarchical structure of communication is deconstructed and replaced with a continuous torrent of messages. On the other hand, each email message begins with a formal greeting and ends with a similar note. Every single word typed in an email is scrutinized before sending the message. Somehow (maybe it is the big imposing email window with labels, buttons, colours and what not) email pushes the user to be formal, and restricts free flowing and fast communication. Unlike email, in chats the conversation is far less formal, and mistakes are not frowned upon. You can talk to people like you talk to them in real life. Communication happens in real time, because you know the other person is online and waiting to talk to you, whereas in email you are sending messages to a disembodied server (shudder).

Creating the Hypotheses

The next step was to design and test the insights we had gained so far. Apart from broad communication, we knew that people use email to share information and get automated updates from various sources (rss feeds, receipts etc). They send/receive files from other people and send files/links to themselves for future reference. These were good starting points for us to dive in with, and armed with preliminary user research we came up with a few hypotheses.

• Consuming messages quickly is difficult on the phone.
• People have a hard time finding files and links which were shared with them on the phone.
• Exploring information related to a single person/concept is difficult on the phone.

The Drawing Board

We started by creating a user story to describe the problem we were trying to solve;

“Gillian begins the day early. She gets ready for work and takes the daily train to work. Gillian takes out her phone to check up on all the things she missed since last night. Every morning she has to deal with around 20–25 emails, and the number of emails just increases through the course of the day. Some are promotional emails which tell her about the latest discounts on a e-commerce site. Some are from her social network site indicating a comment someone left on her new profile picture or a new follower on her blog. She also has e-mails from her parents, cousins, distant friends and work which need to be answered. She has calendar invites to meetings and dinners, and pictures of nephews and nieces to look at and documents to review and send.

Gillian has a lot of information to deal with. She wants to take quick actions on various emails quickly. Her work makes her collaborate with multiple people from multiple locations throughout the day. So she needs a quick communication platform where she can send and receive files as quickly as possible.”

The Design Solution

To come up with a solution we took design inspirations from two places.

• Google cards: for their simplicity and replicable nature.
• Tinder swipe interaction: for the ease of making quick binary decisions.

Email App Card Design with Static and Dynamic sections

The card design has two broad sections:

Static: The top and the bottom strip consist of navigation and common email actions respectively. These parts do not change no matter what the message is. Deciding the bottom half was easy since all email services have the same standard set of actions. Getting the top part right was the difficult part. We gathered some information on the frequent usage patterns of users on mobile applications and ranked the behaviour according to what people usually searched for on their email and arrived at the conclusion that the top bar should be a substitute for most frequently searched items.

Dynamic: The central part shows the different messages. The large central section shows the message in a concise consumable manner and the lower part extracts the actionable links and attachments. The user sees one email message at a time in the central card and the related information in the lower part.

Example Flight Email

Interactions

Here’s where we deviate significantly from current solutions. The design forces the user to take action on a message. The user cannot see another before taking some action on the current existing email. He can either swipe left or right to see a different message. By swiping in either direction he takes a decision — swiping right to archive it or swiping left to set a reminder and deal with it later. Either way,some tangible action has to be taken in order for the user to move towards a new message.

Interactions — Email app

An argument within the team was whether we will be making users take too many actions (one for every email). Anytime the user wanted to see something new he would have to swipe. In our view forcing this action was not necessarily a bad move. We saw it as reducing steps in the user’s’ cognitive function.

For example, in other applications, the steps to action on an email are:

• Scroll vertically through to the email
• Tap to open the email
• See the message
• Take action

In what we built

• See the email
• Take action

So even though we were planning on forcing the users to take some action in every email, we were reducing two steps from the user's cognitive function.

A few more of the wireframes of the different features of the application are below.

(from left to right) People information, Calendar, Attachments — files & links.

Pros:

• Reduces number of steps to see the content of the email.
• The card shows the conversation title and the concise summary of the message so decision taking is easier.
• Limited screen size induces users to communicate in small and quick messages.

Shortcomings and further thoughts:

• We thought of the solution completely from a consumption standpoint. We did not consider the interactions necessary for people to send emails.
• There was no option for users to scroll through (explore) previous messages.
• We were unclear on the representation and consumption of email threads.

Why we didn't follow through:

After we built these wireframes we tested them with a few users .We saw a few problems with our solution:

• Not useful for general email correspondence: General email correspondence is slightly long form and highly unstructured. So creating a simplified card for all conversations is not possible.
• Adds a layer of complexity for the emails not to be addressed immediately: As there is only one card to view at a time, the user does not get a quick visual feedback on the number of things that need his/her attention.
• E-mail creation has a different flow: Making email consumption easier was the goal, but email creation has a completely different format which calls for unprecedented customization from the sender, thus calling for two completely different experiences inside the same application.

This design was something that came out of one the many design sprints we had over the past year. Looking back the idea seems like the musings of a daft man who a little too much to drink (Tinder for email, seriously?). But one of the perks of working in a startup is that no idea is crazy enough to junk (apart from manufacturing light sabers — yes that came up). Even though at the end of the week none of your designs may go into actual production but the spirit of building something that seems outlandish is the best way to learn.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

This blog is part of my work experience as a UX designer at cubeit.io. We do cool design stuff here at cubeit, for more cool stuff from the rest of the team follow us on Facebook, Twitter. You can check out more of our design work on behance. Where we are building a mobile app which will change the way you manage your content. We are currently looking for UI/UX designers to join us in similar sprints.