Ever kept track of the amount of time you spend each week reading, writing, and organizing email? Dealing with email is a major cognitive load—and often a real productivity killer.
Earlier this year at Cubeit, we did a short design sprint—just for fun—to see if we could come up with a better way to handle email. Though our ideas were outlandish, sometimes designing something “wild” is the best way to learn—and to keep from getting bored at work.
Here’s a look at our process and what we learned.
“Sometimes designing something ‘wild’ is the best way to learn—and to keep from getting bored at work.”
What’s wrong with email?
At our kickoff meeting, we talked about how email is currently structured.
Too many choices
People view a list of their messages and have to choose one to open. In fact, studies show (opens PDF) that an average email user sends and receives over 100 emails every day.
That’s a lot of choices to make.
“An average email user sends and receives over 100 emails every day.”
Useless information
Good design makes the user’s life easier
. But if you look at an individual email from a design perspective, it’s a mess—the info someone needs to take an action might be hard to find.
For example, when someone opens a bus ticket confirmation email, they expect to see their boarding details like address, date, and time. They don’t want to see a long block of terms and conditions.
Another example is an email confirming a new user account: people want to know what they should do next, whether it’s completing their profile or finding friends. If that info isn’t clear, they may get frustrated and never go back.
“When someone opens a ticket confirmation email, they expect to see their boarding details—they don’t want to see a long block of terms and conditions.”
Slow
Emails tend to begin with a formal greeting and end on a similar note. People scrutinize every word they type before they send it. It’s anything but quick.
So it’s obvious why there’s a growing trend of using chat-based applications to communicate and collaborate at work: they let people quickly exchange information and easily send and receive files—and it’s all casual.
In chat conversations, mistakes aren’t frowned upon. People may not even use capitalization. You can talk to people like you talk to them in real life. Communication happens in real time—you know the other person is online and waiting to talk to you, whereas in email you’re sending messages to a disembodied server. Shudder.
Designing and testing
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 and receive files from other people and send files and links to themselves for future reference.
Armed with this knowledge and findings from preliminary user research, we came up with a few hypotheses:
- Consuming messages quickly is difficult on a phone
- People can’t easily locate files and links that were shared with them on a phone
- Exploring information related to a single person or concept is difficult on a phone
The drawing board
“Create a user story to describe the problem you’re trying to solve.”
Creating a user story to describe the problem you’re trying to solve is a great way to start understanding the people who will use your product. So here’s what we came up with:
“Gillian gets up before sunrise and takes the early train to work. During her daily ride, she uses her smartphone to catch up on everything that’s happened overnight. She typically has around 20–25 new emails—from friends, family, coworkers, and various ecommerce and social media sites—and that number increases as the day goes on.
Gillian wants to take quick actions on her email. Her work makes her collaborate with multiple people from various locations throughout the day, so she needs a communication platform where she can send and receive files as quickly as possible.”
The design solution
We took design inspiration from 2 places:
- Google Now cards, for their simplicity and replicable nature
- Tinder, for the ease of making quick binary decisions
Email app card design with static and dynamic sections
The card design has 2 broad sections:
Static: The top and the bottom strip consist of navigation and common email actions, respectively. No matter what the message is, these parts don’t change. Deciding the bottom half was easy since all email services have the same standard set of actions.
Getting the top part right was tough. We gathered some information on the frequent usage patterns of users on mobile applications and ranked the behavior according to what people usually searched for on their email. We decided that the top bar should be a substitute for most frequently searched items.
“We gathered info on the frequent usage patterns of users on mobile applications and ranked the behavior according to what people usually searched for on their email.”
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 1 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 person to take action on a message in order to see a new one—they can either swipe left or right. Swiping is a decision: swiping right archives the email, and swiping left sets a reminder to deal with it later. Either way, some tangible action has to be taken in order for someone to see a new message.
“Our design forces people to take action on an email before they can see a new one.”
Interactions: email app
A good question to ask in the design process: are you making users take too many actions? Our team thought a lot about this, since we were making users take 1 action for every email.
But in our view, forcing this wasn’t necessarily a bad move. Reduce steps in the user’s cognitive function wherever possible.
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
And in what we built, the steps are:
- See the email
- Take action
Even though we were planning on forcing the users to take some action in every email, we were taking away 2 steps.
A few more of the wireframes of the different features of the application are below.
People information
Calendar
Attachments: files and 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, making decisions easier
- Limited screen size induces users to communicate in small, quick messages
Shortcomings and other thoughts:
- We thought of the solution completely from a consumption standpoint. We didn’t consider the interactions necessary for people to send email.
- No option for users to scroll through and 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. The problems we discovered:
- It wasn’t useful for general email correspondence, which is typically long-form and highly unstructured. So creating a simplified card for all conversations isn’t possible.
- It added a layer of complexity for the emails not to be addressed immediately. As there’s only 1 card to view at a time, the user doesn’t get quick visual feedback on the number of things that need their attention.
- Email creation has a different flow. Making email consumption easier was the goal, but email creation has a completely different format that calls for unprecedented customization from the sender, thus calling for 2 completely different experiences inside the same application.
“Design for fun with your team every so often and see what happens.”
One of the best parts of working at a startup is having wild ideas—and then building them. Even though at the end of the day none of your designs may go into actual production, the spirit of building something just for fun is a great way to inspire creativity. Design for fun with your team every so often and see what happens.
Have a side project you or your team did that you’d like to show off here? Tweet us: @InVisionApp.
Atharva went from engineering to design. He loves working on borderline crazy ideas. When not designing, he's usually deeply engrossed in a book.
