Intercom

https://intercom.com

I have been a huge fan of Intercom’s blog for a while, so when the folks reached out about joining, it was a no-brainer.

For a first couple of month after joining I had a brief stint spending time between Developer Experience and Platform teams, creating Intercom's oAuth flow, Facebook Messenger integration, Integrations Page and exploring a new filtering pattern for the app.

An example of my work from that time

In Dec 2015 though I joined the effort to redesign Intercom’s messenger. My focus was on all the interactions related to the first experience of website visitors with the company across web, mobile web, iOS and Android.

It started with designing visitor auto messages to solve the job of introducing a messenger for the first time as well as a job of greeting a person. The metaphor I’ve been using while designing this was an experience of entering a shop and being greeted by employees of the shop.

A friendly message from a team

All of that was accompanied by changing several things on the app side: rationalizing inbox behavior as well as completely redesigning Intercom’s team model - since it had fundamental flows from the system perspective that were uncovered by this work.

Changes I’ve made to the Teams functionality

This is the way hundreds of thousands of people are daily greeted when they visit a website for the first time.

A real-life example from one of Intercom's customers

And then came bots. Bots were a hot topic. There was a promise in bots to change the way humans communicate and so we wanted to dive deeper into the interaction to solve a number of problems we’ve had in the messenger, specifically a problem of missed connections.

When someone starts a conversation and the team is not fast enough to respond straight away, a lot of times that person leaves without providing any contact details, never to come back.

We were philosophically against requiring contact details in order to start a conversation, so the idea was to experiment with bots to do a better job of preventing those missed connections.

I lead the interaction design explorations (from using NLP to sheets to cards), did a constant close collaborations with content strategist, researchers and analysts. And worked on creating a ruleset, manners and interaction pattern for the bot, all of which were later used by other teams for creating various bot skills.

Some of the dozens of bot interaction explorations

Another thing I’ve contributed to the messenger was the creation of messenger card pattern.

Some of proposed cards to be used in the messenger

It actually was more of an inspirational project that was brought up while solving a very critical setting expectations problem. The issue was that Intercom’s messenger was designed around asynchronous model that doesn’t align well with how businesses actually work. So my goal was to find a solution that would be a great experience both for the company and end users.

After rationalizing our existing system for how we are setting expectations and doing several rounds of explorations, I ended up introducing a concept of Office Hours for the company and Active/Away mode for a teammate as well as giving the business ability to control when they are around.

A place to control when you are available

At the same time that meant that an end user would never see a “closed” messenger state - people will always be able to start a conversation, it’s just now they’d clearly see when the team will respond. Different states of the messenger

In Nov 2016 I switched to leading the work to introduce a reporting system across all of Intercom’s products, starting with reporting for Support teams.

I was responsible for the full process, from establishing a high level reusable system design, creating new patterns, working through interactions and all of the visual design.

I stared by determining clear user needs based on an extensive findings that our research team made. With those needs in mind I explored a number of solutions for how those reports would work: from a barebones dashboard to an API-only approach.

A range of potential solutions

After we’ve made a call on the direction that best solves the problem, I started to dig deeper into the nature of each of the elements of the system, specifically individual signals, that we envisioned as the atomic element of the system.

Different forms a signal can have

The idea was for signals to be a flexible element that can be added into any context throughout the product to tell a data-related story.

All the different places a signal can live throughout the system

Multiple signals can be grouped together into a report to tell a more comprehensive story. We decided to go with an editorial approach to how we structure, present and group those signals together.

The most critical question after that was to nail the list of specific signals we wanted to show for the initial solution catered for support teams.

Making sure we include the most importat signals was a result of a tight collaboration between myself, researchers, a PM and an analyst, through chats and user tests.

Finally, ~10 cycles of design iterations later, we had a solution we were ready to go to beta with.

Some of those iterations

As a result of the beta, we’ve uncovered a number of things that didn’t work or were missing, promptly improving things on the fly.

Final designs

While still supporting further design work on reporting, I’m now responsible for all of the designs of Intercom’s product for marketing teams.