In September 2015, after just few weeks at Intercom, I learned I’d be leading the design of the biggest project that the company 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 like a classical live chat widget. A tool that would allow businesses to show their authenticity and their personality to their customers.
Let's first have a quick look at the overall redesign cross platforms.
The Intercom messenger is a very simple tool that allows users to communicate with a business (and vice versa): users will mostly reach a business when they need support, and companies will mostly use the messenger to engage their users. 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.
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.
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.
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.
The introduction of GIFs is an interesting example. To be honest, I was a bit skeptical initially. I knew what we were trying to do, but it was a bit hard for me to imagine people sending GIFs in a business context. However, GIFs were so aligned with our company mission, and with the project principle (borrowing from consumer apps), that it was totally worth trying it. The idea was mostly to get this new mean of expression in the hand of people, and to see what they would do with it. If it failed, we would just kill the feature.
Who says customer support can't be fun? Haha @intercom you guys rock. pic.twitter.com/nw9ldKU2Le— Denny K. Schuldt (@DenkSchuldt) March 16, 2017
But it didn’t fail at all! People use GIFs, and more importantly, they use it in their own personal way, making the communication way more casual and authentic.
Another interesting example of this "personal touch": what we call internally the “teammate profile”.
In most of the existing live chat services at this time (including the previous version of Intercom’s messenger), the people behind a business remained mostly hidden and anonymous. If you were lucky, you could get an avatar of the customer support person, but that was it. We wanted to enable teammates to express themselves and to give more details about them because we know this is the best way to build a trustful relationship with customers.
So we spent quite a lot of time building these 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.
But at the end, that was completely 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 users calling teammates by their name, remembering their job titles or other details about them during our user testing sessions.
Beyond our “being personal” principle, we also tried to ship a product that was polished in every detail.
For instance, we realised that when users were having a conversation with a business, they were most of the time having very short and sporadic interactions. So instead of loading the entire messenger all the time, we’ve built Borderless, a secondary mode that allows users to reply inline and in a very lightweight way to notifications of new replies.
Another example is a micro interaction that we’ve added in the middle of the project.
Initially, our messenger had a close button at its top right corner. That’s a pretty standard pattern. One day when we were attending a user testing, 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.
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 could be concerning). But once she found the new button, it actually totally made sense to her, and she was not upset at all because that felt right and logical. More importantly, she learned the pattern almost instantly and was using the new close button completely easily after that. 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.
Probably the best aspect of this project was the huge 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 products (customer support, users engagement, or lead conversion for instance). So I had to work closely with all the different designers of the company to be 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.
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).
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 very tough questions, but at the end, I think that we’ve built 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 (you can try it by yourself, send me a Bonjour :D), and more importantly the team!
Don't hesitate to have a look at other case studies.