Email integration MVP

CONTEXT

BACKGROUND

Symphony is a secure team collaboration platform for professional and enterprise users, with a current focus on financial services. The CEO believed our product needs to support core email use cases in order for our users to completely switch over to Symphony for their communication needs.

GOAL

Deliver the MVP of an integrated email experience in Symphony and take the learning to inform the design for the next generation of Symphony.

ROLE

I was the only designer on this project, working with a team of three developers, a tech lead, and my CEO as the PM.

process

Research

As a chat-centric platform, integrating email functionalities into Symphony introduces a lot of challenges because of the differences in paradigms between the two modes of communication. To better understand the problem space, I interviewed existing users to learn about their behavior around these two forms of communication. I made sure to include users in a range of job functions and with varying levels of adoption of Symphony as their communication tool. These interviews reveals some common problems people experienced with email communication in a chat-heavy work setting. In additional to these interviews, I also dug into our backlog of user feedback having to do with email support–most of them are feature requests collected by the sales and business development teams.

I analyzed my research notes and saw the following problems frequently experienced by users managing email communication in trying to adopt Symphony as their primary communication tool:

• Users have to constantly monitor their email client to ensure they are not missing important messages.

• Sharing information in emails into Symphony chats is difficult

• Users find their emails to contain too much noise, making it hard to pull out only the important content

• Users have to search multiple places in order to find relevant information across all of their communication

concept exploration

As email in Symphony is a brand new concept, I was asked to explore a few options to help the team decide on a direction for our MVP.  We first needed an idea of what email looks like on Symphony.  To help answer that, I started by looking at how email may be related to existing Symphony entities.

This exercise helped me to form a point of view on how email fits into the Symphony ecosystem. I mocked up a number of high level concepts to communicate my thinking to the team. For example, I looked at a few options for email’s entry point on Symphony, evaluating the pros and cons of each option.

Building the MVP

With some upfront research and concept exploration done, the team was ready to get started building our MVP. We looked at my research findings, and based on feasibility and business value, we decided to first tackle the problem of context switching between Symphony and email client. Our hypothesis was that having email integrated into Symphony will make it easier for users to manage their communication as they only need to use a single tool. We also decided on adding email’s entry point to our navigation because although there’s a risk of cluttering our navigation, we felt that we could test our hypothesis relatively easily with this approach.

As part of process for figuring out our scope, I led user story mapping exercise to help the team gain alignment on the set of features for MVP.

Throughout this phase, I frequently built prototypes to test my assumptions and to discover usability issues.

diary study

To validate our MVP hypothesis, I partnered with research to plan a diary study to see how people’s email behavior is affected by having emails integrated with Symphony. Specific changed we wanted to see included:

1. A decrease in the frequency with which users access their email client

2. An increase in productivity due to less context switching

We recruited 10 users for this study that was to span 2 week. Our recruiting criteria was informed by my initial research to identify users who are likely to be receptive to accessing emails on Symphony. We knew that certain types of users absolutely need their email client for specific email features not included in our MVP. We wanted to filter out these users so as not to skew our results.

Conclusion

Although we weren’t able to run our diary study because of reasons external to our project, the MVP was made available for internal users to dogwood. We’ve since collected a large number of feedback that surfaces two main themes:

1. Users have a very entrenched view of how emails should work based on past experience with email clients

2. For Symphony to succeed, we must bring other values to email because replicating a full email client adds too much clutter

We will take these learnings as we work on the next version of Symphony, which will include email as a first class citizen.