Clover Shared Inbox
Making information flow for everyone during COVID
Working under COVID, Clover, a global financial company, struggled to collaborate on deal-making while working remotely. Clover uses email as their main communication, and they are not build for collaboration. Therefore, we built a shared inbox so that every teammate can share emails and information to collaborate.
My Role
I led the reseach with our client and design of the product. I worked together with another designer on the UX and UI design, and supported our engineering team all the way till launch.
Project Team
Me, Lead Designer
Karin, Junior Designer
Jimmy, Product Manager
Ken, Senior Software Engineer
Joseph, Software Engineer
Yuk Lam, Software Engineer
Design Brief
Information should be transparent across the company
Clover facilitates financial dealing between banks and companies. It takes years and many staff from multiple departments to close a deal. Information sharing among teammates becomes crucial to keep everyone on the same page, and make decisions and communicate them as one to Clover’s clients.
Staff from different functionalities, present or past, hold pieces of information. But no one has the whole picture
Most information about a deal is embedded in emails between teammates and Clover’s client contacts. But emails sometimes are not shared with all teammates and are hard to search for. Therefore, Clover tasked us to design a shared inbox system to make information and communications among teams and between clients transparent across the company.
Our design process after receiving the design brief from Clover, our client
Current Challenges
Hard to find and share important emails
I set out to understand why the information was not shared among relevant colleagues who work on the same deal, specifically the following:
How are colleagues communicating with each other?
What information is being shared and how?
Why do they choose to build a custom system instead of buying a SaaS solution
Challenge 1
Staff forget to share their emails to teammates in other functionalities
Sometimes, clients and staff forget to use “Reply All” to loop everyone into the conversation. Other times, staff only include teammates in their functionality, neglecting that teammates from other functionalities also need the information in the email conversation for their next steps.
There are many different people involved in the deal, and they always ask around for information
Challenge 2
Hard to find emails that contain specific information
The challenge in finding information in emails is that we don't search for specific text in the email, but what the email is about, which is not often mentioned in the subject line nor body, rendering the email search useless.
What the email is about usually is not explicitly mentioned in the subject line and the body
Most importantly, search relies on the staff’s memory of which contact or what is written on the email. If we would share emails across the company, many people would not have this memory to search for the right contact or keywords in the first place.
Deeper Insight
Without intuitive organization, staff cannot find any information even if all emails are shared
As I developed the user flow for the shared inbox, I realized the success of this shared inbox hinges on uploading and searching being effortless and intuitive.
Upload and search will make or break this shared inbox
Our engineers and I can ideate many ways to streamline, and even automate the upload process. But the problems of searching persist because the subject line and body text in an email message alone is not enough to pinpoint what information is embedded in the communication
Even if we share all emails, If we can’t search content implicitly, staff cannot find the information they need
Emails in this shared inbox needs be to organized in a way that aligns with what information staff want to get from their emails.
💡
Takeaways from the process
When working with complex workflows, don’t oversimplify
When I first approach this project, I focused on making the userflow as simple as possible. However, the client was not impressed by the streamlined userflow. They wanted the product to mimic their existing business flow.
We lost trust from the client at the beginning because I did not incorporate their business needs into my ideation. I had to go back and talk to many of their staff in order to fully comprehend the complex process of dealmaking. Turned out I missed some crucial steps for the sake of mimizing friction in the user flow.
When working on internal workflow products, it is important to first understand their existing business flow and not to oversimplify the userflow.
Reframing the problem
How might we organize emails by the information staff are searching for?
The end goal of this shared inbox is for all staff to easily find information encapsulated inside email conversations. Understanding what information they look for in emails informs the organizational structure that matches the staff’s mental model when searching for emails.
It turned out that there are generally two types of information staff is searching for in emails, information about the deal itself, and context about the deal or the clients in the deal.
Staff needs both information about the deal and about the client, which are often embedded in the content of the emails
Some of this information are not explicitly written in the subject line or body, but implicitly encapsulated in the context of the email. And the search functions in all email clients cannot extrapolate context.
The design challenge then becomes:
Develop an organizational structure that incorporates the context of emails
and taking that organizational structure to:
Reduce friction when specifying the context of emails during upload
Make searching information in emails intuitive, regardless of how broad or specific the scope is
3 major features for the shared inbox: a contextual organizational structure, easy upload and intuitive search
Feature 1
Organizing email starts with specifying their context
Before we can organize emails based on contexts, we need to specify the context of emails. A major consideration is to make sure the context is not too broad or too specific that it only applies to one email. From the search scenarios I collected from Clover’s staff, I can determine what kinds of contexts they are searching for and prompt the staff to provide these types of context when they upload their emails to the shared inbox.
Clover staff search emails that are situated in various contexts
How to specify the context?
I ideated various ways to specify the context of emails so that emails can be organized by their context. They all revolve around two strategies: descriptive and adding metadata
Ideations of various ways to specify context of emails. Ended up choosing tagging as a method to specify context
After weighing the pros and cons with our engineerin team, I decided to add metadata by tags to specify the context of each email message because:
Tagging adds less friction to the staff who is uploading the email, which increases upload rates
Tag can accommodate very broad or very specific contexts. Uploaders can add more tags to increase the specificity of the context; searchers can filter with more tags to narrow down the search
It is easier to aggregate emails with similar context (e.g. about the same deal) using tags compared to descriptions
💡
Takeaways from the process
Involve engineers early to explore and evaluate designs
When I first ideated on how to specify context of emails, I only considered the user and business needs and decided that users writing structured description would be the most appropriate way to add context to emails.
But when I presented this option to our engineering team, they did not think that it was practical because the engineering effort of grouping emails given such open-ended description would be immense. They wanted to control the user’s input. I have to find a middle ground between our client and our engineering team.
Therefore, it is important to consider the technical implications of the features we are proposing. If available, we can loop in our engineers into early discussions to explore different options and feasibility of our designs.
Open-ended vs Guided tagging
I experimented with two tagging methods to see if staff would over/under tag the context of emails: open-ended and guided. It turned out that staff generally add more tags, but miss some important context (e.g. company) in the open-ended scenario. Because it is important to not miss some context, we decided to go with the guided scenario.
💡
Takeaways from the process
Compromising with the client
I championed the open-ended scenario because it will give more context to each email, hence improving search. But the client insisted that there is some context that cannot be missed.
In these situations, even though we come from the same goal, I needed to step back and accept that some functions are non-negotiable to the client. I counterproposed a number of ways that may automate some tagging of important contexts. But I also think that those solutions will overcomplicate the user experience and implementation.
There are always ways to work around a constraint, whether it is technical or from the client. But I also needed to weigh the benefit over the added complexity to the product. In the end, I and our PM both decided that a few more tags added does not justify the added complexity.
It is not a zero-sum game between us and the client. Realizing these non-negotiable from the clients is also the problems we need to solve makes me feel more comfortable listening and accepting ideas that contradict mine.
I experimented with no guiding questions for tagging. While it encourages staff to add more tags, they also miss tags give important contexts
Uploaders with have these different categories of tags to specify the context of their emails as they upload the emails to the shared inbox. This metadata, coupled with email addresses, subjec line and body text that already exist in each message, matches the staff’s mental model when searching for information in emails.
Feature 2
Applying tags on emails: use intelligence to reduce friction
One of the design goals for this shared inbox is to make upload as effortless as possible. I need to balance the applying tags on emails and the added friction from tagging.
First, I want to make the uploading process a part of the staff’s habit when reading and writing emails. We built the upload feature right on Outlook so that staff can triage, read, reply and upload the email without leaving Outlook.
💡
Takeaways from the process
Working with multiple design systems
Since we are building on top of Outlook for this upload feature, we need to work with Microsoft’s design system on top of our own. Making the product look and feel similar across platforms became one of our priorities.
Making features consistent across platform goes beyond the looks. The interactions should be consistent as well. Some Microsoft components look and function similarly to ours. But for others that are not, I did one of these compromises:
- Adjust the corresponding component in our design system to match its look and function
- Piece together Microsoft’s components to try to match at least the look of our components
- Work with engineers to customize some Microsoft components to match the look and feel of ours
We built a upload email add-on for Outlook so that the staff can triage, read, reply, upload to the shared inbox all in one window
Autofilling tags on upload
To minimize the frictions of applying tags to specify context, our product team came up with these principles
First, automate to replace manual input
Narrow down choices and inputs
Avoid switching screens
Align with user’s mental model
There are tags that can be automatically filled based on the data on the email, such as contacts. We autofill contact tags and their associated company tags that match those email addresses.
If the addresses in the email matches those in our system, we will autofill the contact tags and their corresponding company tags
Suggestions and creating new tags
We then look at the remaining email addresses in the email to suggest new contact tags. The user can create them right on Outlook, instead of going to the shared inbox portal.
If the addresses does not match one in our system, we will suggest staff to add them as a new contact tag
Auto-match for messages in the same thread
If the message belongs to a thread that has been uploaded, the tags will be auto-filled based on that from the uploaded thread
We will auto-fill the tags if there is a new reply in the same thread
💡
Takeaways from the process
Some friction is needed
When I started thinking about adding tags during upload, I want to simplify the process as much as possible. So the first iteration does not allow the user to edit any tags before the email is uploaded.
But when testing with Clover’s staff, this simplistic flow created many confusion that actually hinder them from upload the email. They want to be sure about the tags before uploading.
So I opened up the editor before the staff upload the email, but auto-filled some tags to reduce friction. However, the staff were confused as to why the tags are there. I realized later that the staff wanted control on what they fill because their managers would see the submission.
Therefore, I added a dialog explaining how are tags auto-filled and give the staff a choice to auto-fill them. The added steps from the first iteration introduced more friction, but it enabled the staff to understand and control each step of the upload process, which is more important to incentivize uploading.
Feature 3
Search any email in three steps
Now that we have more contextual information about each email, staff can search emails by many contexts and parameters.
By contextual tags (such as deal, company, contacts...
Receiver and Sender
The subject line, body text, and attachment name
Send/Receive date and time
I want to retain the simplicity of a general search, but at the same time allow user to specify the search parameter. An empty search bar does not signal users the many parameters they can use to narrow their search. Placeholder text can only highlight some parameters available. Listing all search headers can direct users to use specific parameters.
Search with context: use headers to help guide your searches
Staff can also directly type keywords to search. Because there are more types of metadata to search with, other than emails and email addresses, we will show suggestions for different tags, remarks and other metadata.
Auto-suggest of company, contacts, deals and emails related to the search keyword
The search bar is designed for broader searches using 1-2 parameters. To further narrow down their search, staff can apply more filters.
A number of filter options based on different contexts to narrow down the searches
We made sure that any search, however broad or narrow it is, has to be done in three steps. And given the added context provided by tagging, we are confident that the result would be relevant to what the staff intended to search for.
I want to find the agreement signed by Morgan Stanley for the deal between Airbus and Lufthansa
Outcome
Transparency and collaboration helped Clover survive COVID
The shared inbox helped Clover transition to remote work in COVID. Staff read, reply and upload emails to share with their teams, all on their Outlook. Colleagues new to the deal can search previous communications with the client to get up to speed. Teammates from different departments now have the same information to make decisions and communicate with the clients coherently.