Under the guise of productivity, we've seen various changes attempts by e-mail startups over the years to "make email better". Better has been intensely focused on inbox management and slick UI, but as one of the most fundamental apps in use by billions of users, could it do more?
That's what we set out to learn and establish a vision for.
In three months time, we went from a decent concept to having a usable prototype that touched on all the features in this case study. The founders took our alpha build and working vision to investors to consider for investment.
Unfortunately, we were not able to secure funding to continue working on this project.
One of the pain points identified was that people were often frustrated with the method of replying to an email using the block quote. Where one would comment and format responses inline, within the block quote, retaining all prior conversation.
This method led to a lot of clutter in responses, often leaving it difficult for recipients to parse what was important or even relevant given multiple responses.
Focusing on keeping conversations easy to read, I defined and proposed the feature of inline commenting to evaluate as a way to improve communication.
The key pain point we were looking to solve here was "finding that file I need" in a conversation. Passing files back and forth in threads is fairly common and since we had a different method of to threads and conversations, looking for the Attachment icon wasn't going to work.
The poll object enables the email composer to create a simple, trackable method to gather responses by only sending a single email.
The poll in this case, exists in the email, but also becomes visible in the Companion within the app, where actions or desired objects are populated.
This enables the participants to provide and answer and keep tabs on the results, without having to refer back to a thread of responses in a conversation.
One core differentiator we were positioning was to introduce interactive content to Echo. In addition to productivity improvements, could a customer "save" special widget-like, micro apps to the Companion to monitor packages delivery or in this case track a baseball game via ESPN.
Under the guise of productivity, we've seen various changes by e-mail startups over the years. The majority focus on better design and inbox management, while true productivity and feature sets remain hamstrung by the legacy protocol.
What if e-mail could be enabled with modern SaaS capabilities, where the protocol was managed behind the scenes and content and productivity reduced cognitive overload?
In three months time, we went from a decent concept to having a usable prototype that touched on all the features in this case study. The founders took our alpha build and working vision to investors to consider for investment.
Unfortunately, we were not able to secure funding to continue working on this project.
Through a mix of qualitative and quantitative work, I identified specific user behaviors, pain points in their daily work to generate the prospective features and requirements.
I was responsible for all visual design throughout this engagement. The strategy wasn't to invest too much time in the details, but to be appealable enough to represent a baseline experience.
Leveraging what I learned, I defined tangible productivity enhancements that no e-mail app offered. I realized all of the feature work through a mix of low and high fidelity prototypes outlining product functionality, some of which went to development for investor review.
I utilized Keynote to develop all interaction prototypes to visualize all feature concepts.
If you ask any person, they can probably come up with a least one or two problems they encounter while using e-mail. The co-founders of Cloud City Labs were no different. The platform in more recent years has become the app you love to hate (but you can't live without).
The ubiquity of and the protocol which e-mail uses is most responsible for the the slow progress we've seen to the platform. When you have to rely on the same old tracks to move your freight, you have little in the way of ability to innovate. At CCL, we knew to enable some of the changes we wanted to make we'd have to jump the tracks. Though we first needed to know which direction to point ourselves.
Upon joining the team, there had been no formal research done. Given a condensed timeline, I choose to focus on talking with e-mail power users. I recruited individuals for interviews, who spent more than 3 hours a day using e-mail, managed other individuals and who believed e-mail inhibited aspects of their formal job.
I used contextual interviews to understand how each user managed their email which led to identifying pain points and methods they used to manage their work through email. I then surveyed a broader group to evaluate whether pain points were common amongst other e-mail users.
After receiving and analyzing results, I wrote How Might We questions to help us focus on topics we could generate ideas around to address. These included:
THIS NEEDS TO BE REWRITTEN TO SUMMARIZE THE WORK FOLLOWING
Text goes here
One of the pain points identified was that people were often frustrated with the method of replying to an email using the block quote. Where one would comment and format responses inline, within the block quote, retaining all prior conversation.
This method led to a lot of clutter in responses, often leaving it difficult for recipients to parse what was important or even relevant given multiple responses.
Focusing on keeping conversations easy to read, I defined and proposed the feature of inline commenting to evaluate as a way to improve communication.
In addition to cleaning up conversations, I asked how might we start to encapsulate the history and content of a conversation and make it easier to find a response or a file without opening up multiple messages in search of them?
In my research, people were often frustrated by searching for a nugget of information or a file a colleague had delivered via e-mail. While many would suggest search as the best option, many end users would initially use search, fail to identify the desired message, then have to dig through a conversation thread to find the file.
I saw in this as an opportunity to summarize the events of a conversation to make them more easily accessible to the end user.
The key pain point we were looking to solve here was "finding that file I need". Passing files back and forth in threads is fairly common and since we had a different method of to threads and conversations, looking for the Attachment icon wasn't going to work.
Here the user can access an activity view,
In certain cases, e-mail might be the easiest method to gauge the sentiment from a large amount of co-workers. Though in most cases that means receiving multiple distracting replies, which you then have to collect results manually.
What if you could just send a simple poll, that would unobtrusively collect those results as you focus on other work?
The poll object enables the email composer to create a simple, trackable method to gather responses by only sending a single email.
The poll in this case, exists in the email, but also becomes visible in the Object sidebar within the app, where actions or desired objects are populated.
This enables the participants to provide and answer and keep tabs on the results, without having to refer back to a thread of responses in a conversation.
In the realm of customer service, response speed is a highly valued metric. One of our interview participants was working at a startup answering general and support questions. They would receive multiple requests for support each day that shared similar answers. In answering, they often used a Word document to copy and paste content into a message, taking them out of context and back in.
What if you could create and insert content that you could use repeatedly to speed up your responses?
Where text expanders worked well for only text, we wanted to create a method that enabled users to extend that functionality to other elements such as images, files, web views and text.
E-mail hasn't been always friendly to meeting scheduling. Commonly, users would have to check their calendars, remember the times and then type them out as suggestions, waiting on an entirely new email to confirm.
Locating the spare time you have doesn't need to be complicated and reviewing a calendar is often slower than necessary to find a block of time.
After finishing your note to the recipient, the user would use a forward slash action to query their calendar for free time to connect. The options returned could easily be edited to the sender's preference and sent along.
The recipient, if using Echo, could respond in the sidebar or message, but if not using it would have an embedded CTA that pivot to confirm in the browser.
Depending on a users workplace model, they may be the recipient of many notification e-mails. While the intent is to keep you on top of happenings, each carries the same weight in your inbox, but they aren't all equal and none are truly actionable.
So I asked, how might we make categories of messages actionable and provide the easiest path to completion?
As a culture, we're bombarded by notifications. By default or need, the most common place we receive these is in our inbox.
Other services classify and sort them differently, but what if we were able to parse the email into a useful action and never ask you to manage the original message?
Why would we just not outbound the user to a web browser they use? People are easily distracted when they switch contexts clicking on links sent through email. We wanted to bring the content to them to resolve an action, so that they can maintain their focus as they manage their email.