This Email Petty — a design journey

Prashant Rao
6 min readMar 4, 2019

--

Inspiration and Ideation

Timekeeping, measuring time either directly, or through a record of our actions gives us our actions context and allows us to place it within the larger realm of possibilities of what is and what could be. It gives us a sense of progress, a window into our mental state at a particular point in time, see a bigger picture of where things are going to. I wanted to explore how people keep time and use it in their daily lives and improve upon existing methods. I started by observing how people keep journals, this could be anything from keeping a dairy, daily sketches, or someone’s personal Soundcloud uploads.

I observed three people and their motivations and reasoning for journaling and their methods of doing so. Motivations ranged form emotional regulation, documenting experiences and states of mind, relieving stress, and sharing thoughts and experiences with others. A common theme that I observed was the difficulty of recalling where recorded notes were, or the lack of a cohesive way to stitch together different sources of data. Even when people used social media as a journaling tool. My ideas then revolved around the point of view of that people should be be “introspecting” more i.e. working on processing their data rather than just spending time searching for it. Making the process of recording and retrieving faster. Two ideas were selected form an initial pool of 15 ideas.

  • An email client that understood the context and history of conversation between users and presented users with relevant information when they needed it automatically.
  • A smart do not disturb mode on phones that understood the context of notifications and messages to only allow the really important stuff to come through.

Storyboards and Prototypes

Next step after selecting viable ideas was to storyboard them. This gave me an idea of the potential use cases and overview of the interactions users will have with the final product. The email application’s storyboard walks people through a busy person juggling multiple projects needing help recalling details of their projects. The do not disturb mode walks people through a person in a meeting receiving an urgent message from someone who doesn’t usually message them.

Storyboards for the smart email app (left) and do not disturb (right). It’s ok for the storyboards to be hastily scrawled on paper, it is just for reference
Quick and dirty paper prototypes for the smart email app (left) and do not disturb (right)

Now that I had an understanding of the overarching interactions users will have with the designs and an idea of their motivations for doing so, I prepared some quick paper prototypes of the above designs. This was to get a quick understanding of the finer interactions users will have with the designs, and provided me with a baseline for refining into the final application.

Basic wireframes for the smart email client (left) and do not disturb settings page (right)

Now that I had a baseline user interface, it was time to find and fix usability issues. This is done by going over a formalized list of design heuristics. I turned to my peers to help me identify any violations of these heuristics in my paper prototypes. This helped me make my prototype more user friendly. There were plenty of consistency issues, and no help was offered to users. With this knowledge I started creating a mockup of the user interface, and decided to proceed with the smart email idea. I created a basic wireframe of the user interface, and started laying out different elements on the screen in Keynote and made the screens interactive using MarvelApp.

Preliminary design mockup (left) and navigation flow of the application (right)

User Testing

Now I had the mockups, but I was still was trying to figure out what level of information to present to users and how to present it. I presented my mockups to users and observed them use the prototype. I presented them with a task, open the app and reply to the email. The scenario I presented to them was as follows:

“You have come back to work after a long vacation. You are a little fuzzy on the details of where they left off on their various projects. You have just received an email asking for some project update. Reply back to this person to the best of your ability.”

User testing the prototype on their computer

Four users took a stab at the task I presented to them. I just observed them perform the tasks, the users were instructed to talk out loud the task they were performing and the what they were thinking while performing the task. After performing the task they were asked to describe their experiences and suggest any improvements they’d like to see. From this knowledge I created two distinct version of my prototype.

Prototype A (left) and Prototype B (right)

A/B Testing

These prototypes, prototype A and prototype B, had only one aspect changed, based on user suggestions. Prototype A had a timeline of a user’s conversation with a given contact presented when the user is replying to an email thread with that contact. The screen also had a list of tasks that the user had to do presented along with the timeline. Prototype B only had a list of tasks presented when the user was replying to email threads. These were the prototypes chosen for A/B testing. The task given to the testers was the same task given to users during user testing. They had to reply to an email the best they could.

I used the platform UserTesting to conduct A/B testing. Four users were given the prototypes to test. I found that while testers were able to easily reply back and navigate the interface, they were faster to reply with prototype A. Testers liked that they had information right when they needed it. The list of do to tasks was the first thing that caught the testers attention and gave them most of the information that they needed. The timeline gave them more context at a glance. This allowed me to finalize prototype A as the final design.

Final Design

While there are email clients exist that can auto fill simple responses to emails, none provide context of a user’s own email to the users. While separating emails smartly into categories like Google Inbox is provides some of that context, it is still a bit lacking especially when it comes to professional/corporate scenarios. Information when it is available when needed most can save tremendous amount of pain, effort and time.

Link to the final interactive UI mockup

Link to video explaining the application

Final Design

--

--