In September 2015, I learned I’d be leading the design of the biggest project that Intercom ever tackled: the redesign of our messenger. I worked in collaboration with 2 amazing designers on this project: Brendan Fagan who was focusing mobile, and Jakub Antalik who was working on the visual identity.
In many ways, this project was unique for Intercom. We were the biggest team of the company at this time (~18 people), we were working cross platforms (web, mobile web, iOS, Android), we were building a “hosted product” (a product that would live inside our customers’ apps), and we spent a large amount on time on it (~a year, which is extremely unusual for Intercom).
Inspired by the company mission (“Making Internet business more personal”), our goal was to build the most personal business messenger. Something looking more like WhatsApp or Facebook Messenger than the typical customer support form. A tool that would allow businesses to show their authenticity and their personality to their customers.
A quick overview
Let's first have a quick look at the overall redesign cross platforms.
The new version of Intercom's messenger
The Intercom messenger allows users to communicate with a business, whether it's for support, feedback, or marketing purpose. Most of the conversations are asynchronous, meaning that the participants are not necessarily there at the same time. People send a message, and come back later to check the reply.
Back to first principle
At Intercom, peeling back to first principle is almost a tradition… so before diving into the design details, let’s take a step back to try to understand why this project was so important for Intercom.
This is the previous version of Intercom's messenger
The previous version of Intercom’s messenger was working pretty well. The company could have easily spared the investment of building a new version from scratch, and could have spent an entire year iterating on this one instead – fixing bugs, adding features, creating a lot of immediate value for our customers.
But we thought that the existing live chat model was broken and misaligned with Intercom’s mission (remember “making internet business personal”). We believed in a more casual and personal way for businesses to communicate with their customers, taking inspiration from consumer messaging platforms (Facebook Messenger, WhatsApp, Telegram etc). That alone was such a big change, that it required to come back to the first principle of our messenger and to question all the existing decisions. In other words, to start a new product from scratch.
Enabling businesses to be personal
So how did that translate in practice? As I wrote, the main idea was to borrow from consumer apps: to reuse standard patterns and features that people use everyday.
GIFs are cool
The introduction of GIFs is an interesting example. I was a bit skeptical at first. I knew what we were trying to do, but it was a bit hard for me to imagine people sending GIFs to a business. However, GIFs were so aligned with our company mission, and with the project principle (borrowing from consumer apps), that it was obvious that we had to try it. The idea was mostly to get this new tool into of people's hands, and to see what they would do with it. If it failed, we would just kill the feature.
And it didn’t fail at all! People use GIFs, and they use it in their own personal way, making the communication way more casual and authentic.
Another interesting example is the teammate profile. In most of the existing live chat services at the time, the people behind a business remained mostly hidden and anonymous - If you were lucky, you could get a fake name for the customer support person. We wanted to enable teammates to express themselves and to give more details about them because we thought this would help to build a trustful relationship with customers.
So we spent quite a lot of time building teammate profiles. This part of the project has probably been one of the most difficult in terms of design. We’ve built dozens of prototypes in Framer, or directly in React to fine tune an interaction that seemed pretty straightforward at first. We also had to make some very tricky product decisions like when we had to decide if we should allow teammates to hide their location and their timezone, which was against our principle of transparency, but which was for some businesses something extremely sensitive.
This is an actual profile from a real teammate!
And the result was undoubtedly worth the effort. Users can now see that they’re talking to real people, and not to faceless agents. One of the most satisfying experience of the project was listening to user testing participants calling teammates by their name or remembering details about them.
Attention to details
Beyond our “being personal” principle, we also tried to ship a product that was polished in every detail.
Borderless allows users to leave a quick reply
For instance, we realised that when users were having a conversation with a business, they were most of the time having very short interactions. So instead of loading the entire messenger all the time, we’ve built Borderless, a secondary mode that allows users to reply on the fly when they receive a notification of new reply.
Another example is a micro interaction that we’ve added in the middle of the project.
Initially, our messenger had a close button in its top right corner. That’s a pretty standard pattern. During one of our testing sessions, we realised that users were constantly switching between their conversation and the website that we were using for the test. They had to close the messenger with the top right close button and to reopen it with a button located at the bottom right of the website (we call this button the launcher). That didn't seem optimal. So I suggested that we could try to reuse the launcher to close the messenger. A bit like a toggle button. We've quickly added a second state to the launcher, and we've been able to test it with the next user.
Using the launcher as a toggle button
The first user to test this new pattern was initially looking for a close button at the top right corner of the window for few seconds (which was concerning at first). But once they found the new button, it seemed to click almost instantly and made the navigation much easier. This behaviour has been then validated by many other testing sessions.
This example goes against few of our design principles at Intercom (being standard over innovative, intuitive over learnable), but sometimes, it’s good to break principles (as long as it’s done consciously). In that case the benefit of being able to toggle the messenger was so interesting and felt just so right, that we were happy to diverge.
An incredible collaboration
Probably the best aspect of this project was the collaboration that was involved. As the main designer, I was working closely with the product manager to prioritise our work, with engineers to prototype and build (I even pushed few commits in production myself!), with user researchers to write scenarios and to assist them during our user testing sessions, with product analysts to get the right numbers to guide decisions, and more importantly with other designers. Because we were not only building a product, we were building a platform, a tool that would then be used by other teams at Intercom to support their own products. So I had to work closely with all the designers of the company to make sure that we were building something that they could use in the future.
This aspect was so exciting, that it led me to another project: the messenger patterns.
Preparing the future of business messaging
Releasing the messenger was just the first step. The most important part was to make of this new tool something easily usable by the other product teams at Intercom. I tried to create a documentation on “how to design for the messenger”. A bit like the user instructions for designers who will have to invent the future services and interactions of business messaging at Intercom. The goal was to answer questions like “how will my design be rendered across channels?” (on email, or on Facebook for instance), “how do I collect data in the conversation?” (asking visitors to leave their email for instance), or “how do I show my very specific content?” (showing an article from the help center for instance).
An illustration of a flow showing messenger buttons, sheets, and event messages
This “spin off” of the messenger project has been fascinating and extremely challenging. I took inspiration from the famous book “A pattern language” by Christopher Alexander to create a list of common problems that designers were having when working with the messenger, and to provide some examples of answers and guidance. We came across some tough questions, but we ended up building an incredible understanding of the conversation model and of the different tools that we could use, their pros and cons, and when they are relevant.
This project was by far the most exciting experience of my professional life. I loved everything: the domain, the result, and more importantly the team!