Redesigning a shared inbox for sales teams — a UX case study

We know product redesigns can be incredibly tricky. It’s tough to get buy-in, it’s tough to figure out what to change and what to not touch, and getting them built out correctly requires a lot of patience and blind faith. Even if all that happens and even if all your design decisions were well-intentioned and heavily backed up by research, it’s a gamble as to how users will react to it. It can be quite a whirlwind of emotions and stumbles, so let’s walk through it.

You’re probably familiar with Drift’s chatbots, shown here on the websites of some of our clients: Onshape (left), InVision (middle), and Peloton (right). The designs I’m going to walk through are the other side of this story: the view where all these conversations are displayed to the salespeople you’re chatting with.

I joined Drift one year ago, and have had the opportunity to lead a major redesign effort for the core interface in the product, the view where all Drift users respond to leads and manage all the conversations happening on their website. It’s no easy task, because everything is updating in real-time and things are constantly moving around in the view as a result of other humans and bots taking actions on them. It was quite the challenge to come up with ways to improve and simplify the experience. The rest of this post walks through our stumbles, pitfalls, and successes during this process.

The product and the problem

I’m going to walk through how we redesigned Drift’s core conversational marketing platform and overhauled it to be more effective for sales teams. Drift’s primary product line involves a highly customizable chatbot that you can install on your site. Most chatbots out there focus on customer service and support, but Drift offers tools purpose-built for sales teams. When you’ve got hundreds of customers coming to your website and asking questions, there’s a good chance that a few of them are solid leads. Based on how the bot qualifies these leads, these conversations can be sent to specific sales reps or account managers where they can jump into the chatbot conversation and continue talking to the customer, human to human.

This was the state of Drift’s Conversations view when I joined the team. Right off the bat, you can tell that the view is trying to do way too much and that there isn’t much visual consistency or hierarchy to the information architecture and layout of the screen. My first step was to address this right away.

This is where the product I lead design efforts for, Drift’s Conversations view, comes in. When you’ve got a massive sales team managing hundreds of conversations on your site at any given time, it can get a bit chaotic. There’s a mixture of support and sales conversations, there’s dead leads that don’t respond, there’s sales reps jumping into each others’ conversations trying to claim the lead for themselves, and there’s a lot of general confusion as to what the state of things are on your website at any given time.

So when I started at Drift in September 2018, I was tasked with leveling-up this view (note: this is a web app that runs in a browser). I needed to solve the most pressing usability problems in the view, modernize its interface and clean it up a bit, and envision what the future of this view would look like based on where the product is going. All as quickly as I could. No pressure.

What’s so special about this?

Before diving in, I’d like to address what’s different this time around. I’ve written about major product redesigns before and have gone through the process a handful of times. But this one felt different. The product itself isn’t in a category that’s terribly difficult or novel to design for. It’s messaging. It’s a large shared inbox. There’s plenty of role models to choose from and lots of established design patterns to get inspiration from. So why did things feel that much more challenging and so much more difficult this time around? It comes down to a couple of things:

1. I was now designing for one single view that had to contextually scale and handle over sixty or seventy different things, all of which were updating in real-time based on the actions of your teammates, the customers you’re talking to, and bots automating tasks as you’re working in the view. This is very different than say, a mobile app or a video game where you can layer and nest the menus or options across different screens and pages. This entire product was just one view, and I had to use this as a strict constraint when designing.
2. I was designing for people whose livelihood depended on using the product well. This wasn’t just another consumer app free to download on the App Store or a free-to-play game. This was a product people were paying thousands of dollars per month for, and their performance at work was measured by how effectively they could use our product. Throwing major redesigns at people just trying to do their job can backfire dramatically, so this needed to be handled carefully with a lot of empathy for our users who relied on our product for their work.

An example of a very early user workflow map I made in my first couple of months at Drift by shadowing a sales rep for a few hours. I needed to understand how this view that I was designing for fit in context of the user’s daily workflow: what they did before, what they did after, and how they used it in conjunction with other tools. Diagrams like these were instrumental in shaping my design thinking throughout the process to spot breakpoints in the experience.

These were challenges that I never had to deal with before in my design career, so it was a mix of excitement and nervousness. I was ready to tackle it, but I knew so little about industry and the users that I needed quite a bit of ramping up before I got to a point where I felt comfortable knowing what I was doing. It certainly helped that Drift’s culture tends to be one that takes big swings and is all in for you taking big risks and being completely okay with failing at them, because you’d at least have some major learnings from the failures instead of learning absolutely nothing from small incremental updates that fail to garner any sort of reaction from the user base.

Part I: Getting to work

So let’s get into it. This product, internally referred to as the “inbox” or the “convo view”, was not getting a lot of love. Many different product teams had cobbled together features to live in this view based on sporadic customer feedback over the years and as a result, the view had accumulated a good chunk of design debt. There had never been an overall vision or a thoughtful structure to the thing. It was starting to feel clunky, outdated, and very buggy. This is the piece of the product that customers used most frequently, so it was frustrating to everyone that it just didn’t feel good to use. Everyone wanted it to be good, and only around when I joined the team had the company gotten around to properly resourcing a full team to manage and overhaul the conversation management experience.

Here’s the view again in its state when I joined the team. Beyond the visual and IA issues, there were a lot of usability problems in the view. It was difficult to keep track of conversations and it wasn’t clear what needed your attention at what times. I knew there was a lot of work ahead of us.

Naturally, I asked a lot of questions to have some design constraints that could guide my ideation and thinking. I asked sales reps who used the product, customer success representatives who onboarded people into using the view, and the product leaders about what it needed to do. I walked away with a sense that it needed to do a lot of things:

• Let users manage their own conversations while also allowing sales team admins to monitor all conversations on the site
• Scale across different sales teams, connected apps, and multiple orgs
• Allow users to easily search and find old conversations on the site
• Clearly notify and alert users when important accounts are on their site
• Work in conjunction with our email product offerings

That’s a lot of work for one view. And that’s just the primary goals. It gets crazier once you get into the details of qualifying leads in a specific conversation, but more on that later.

A static clickthrough prototype (made in InVision) that I put together to showcase how the interface would handle all that was asked of it while scaling the UI to be collapsible/expandable as necessary. The amount of information in the view is a little overwhelming and forced us to re-consider our approach after looking at this.

So my first attempt was a shot at organizing the layout in a way that handled all these things I had just learned about. I added all the features people asked for into the view and tried my best to keep it manageable by making panels collapsible so that irrelevant information can be hidden when it wasn’t necessary. It worked in theory, but it made a lot of people realize that this was starting to get even more confusing with a lot of things on-screen. We could solve some of the confusion through copy and UI clarity, but it got people asking whether we’re asking too much of the view or not. Even I started to feel that this was a little overwhelming because I was cluttering up the view with lots of buttons to hide information from the view. As a designer, that’s when you know there’s a problem.

This, to me, is one of the best things you can contribute as a designer to a product company. Many managers, leaders, and strategists have a high-level overall vision of what they’d like the product to ideally do, but have a hard time visualizing what that would look like in an interface and what the experience of using it would be. If you’re able to put together something quick to give them even the slightest idea of what we’ll end up with, you can quickly pivot on some of the potentially controversial product assumptions.

Some design feedback

Intercom Inbox (left) and Front App (right) utilize a large “filter panel” on the left of their primary view. This panel does a lot of work by being the place for many different actions along with content for navigation, switching modes, settings, accounts, and links to other parts of the product where necessary.

While I was living in concept land trying to make something work in the view, my fellow designers at Drift had some great pieces of feedback. Just before I had started, they had already done a lot of research on this problem of handling multiple types of content and information in the view. Many other web apps that feature large shared inboxes have solved the inbox management issue by utilizing a “filter panel” on the left side. This functioned as a master control for the whole view, allowing users to quickly switch between different preset filters and find what they needed.

I already had something similar in my original concept, so I decided to double down on it even further and clean up the UI a bit, making it match a little more closely to what the other web apps do. Additionally, we decided around this time to not worry about some of the more complex tasks we were asking of the view, like scaling across teams, apps, orgs, and working with the email product. We needed to nail the core experience first, and that just wouldn’t be possible if we were trying to do too many things at once.

My revised prototype (made in Flinto) simulating a flow where you’re having a conversation with a customer as a new conversation comes in to the view and draws your attention — a core workflow that we needed to nail. I needed to prototype with animations because moving UI elements draw a lot of attention from the user.

This time around, I simplified a lot of things. I put a lot more thought into the layout of the interface and wanted to pay closer attention to things like information hierarchy and type styles. It needed to feel fluid, fast, and responsive. Static mocks might be great to convey the idea, but this is a view that’s handling a lot of live data, so little micro-animations and transitions were crucial in conveying the usability of the view here.

This was starting to feel a lot better. The view felt nicer and cleaned up, and the experience started to feel a little more elegant. In user testing, the filter panel seemed to be looking very promising as a solution to the usability issues of the view, as most people seemed to love the idea and were already familiar with the pattern. So we set out to build it in the existing view.

Here’s what the built version of the filter panel in our view looked like. We kept it dead simple to start with in order to validate the usability first before going too deep with visual changes. A light drop shadow and a faded background color helped add some depth to separate this panel from the list of conversations.

As a team, we had grand plans on how to scale up this filter panel from this first version up to a more robust and flexible one based on user feedback and lots of internal beta testing. Our product manager had a full roadmap, milestones, and timelines of when we could release it to all our customers. It helped that everyone at Drift also used the Conversations view to chat with customers on a regular basis, so we expected it to be easy to get feedback and keep building. But…things didn’t exactly go according to plan.

As we put this out to more and more users (just internally), it became clear that the product wasn’t conveying the fact that it had gotten simpler to use. We were introducing yet another panel in the view (on top of the existing three) and proclaiming that it’s easier to use because there’s now more buttons to click on and more panels to manage by expanding or collapsing them. Doesn’t exactly instill a lot of confidence in simplifying the view now, does it? But in terms of usability, we actually were getting positive feedback. Users found it easy to switch between just their conversations and all conversations. They were able to find what they needed and quickly take actions. And yet, the overall view was getting more cumbersome to look at with the addition of a fourth panel, so we scrapped the idea before going too much further with it. The loss in visual clarity was too much compared to the usability benefits of this filter panel, so it died before it had a chance to shine.

In hindsight, I’m still not sure if this was the best move. We had built something that was solving a real problem, and it seemed to be working. There was a lot more we could’ve done to simplify it and educate users on best practices, but we didn’t have the trust of our users to keep pushing something that so obviously seemed like it was headed down the wrong path, so the idea was killed off. Who knows what would’ve happened if we stuck to our guns and pushed through one or two more iterations based on user feedback? We may have solved it, but we can’t say for sure. It’s a bit like putting a low-fidelity movie trailer in front of a focus group to gauge their reaction and deciding to not pursue the film due to it failing to make an impact.

Part II: A pivot to remember

Soon after we killed the filter panel, we got together in a room with our CTO and VP of Product to talk about exactly what we should be doing with this view, because clearly, our team needed some guidance on how to properly approach a project as large as this. They stressed the importance of using a strong role model to build upon: we were working off of role models like Intercom and Front App, but we should have been working off of Slack. Slack uses a sidebar and a detail view as a constant throughout their entire application. This design constraint, intentional or not, forces them to make everything work in a simple layout without too much cognitive load.

Slack’s view manages to communicate a sense of simplicity and ease-of-use by keeping a consistent design paradigm of one dark left panel and one main message window across its entire interface.

I walked out of that room feeling like I had a much better sense of what the view needed to do. It needed to be dead simple, comprehensible at first glance, and always had users in a state where they knew exactly what they needed to do next. And this time, we knew we had a strong role model in Slack. The product goals do not map one-to-one: Slack is inter-team communication whereas our product was geared around communicating with anonymous strangers interacting with a bot on your website. But the takeaway was that we needed the product to feel as simple and easy to use as Slack. It couldn’t have complex interaction models of managing conversations and chatting with customers. It needed to be intuitive and obvious. My goal now was to push this product towards a more streamlined, Slack-like view.

The concept

My Slack “inspired” design for what Drift Conversations could look like. In the interest of keeping familiar patterns and consistency for users, I kept as much as I could as close to Slack’s design as possible. This concept sparked a lot of conversation and debate within the team about whether or not to pursue this approach.

And so I made…a Slack clone. No joke, it looked exactly like Slack. A dark sidebar on the left and a detail view on the right. I talked to a lot of salespeople to figure out the best way to layer all the information we could possibly display on the views here. They wanted to see specific details about the customer, a full history of the account in one conversation, every point of contact they’ve ever had with the person they’re talking to, and much more.

This single design was more eye-opening to the team than any of my earlier concepts. While the previous designs were trying to simply clean up the interface or organize the existing features more effectively, this view completely re-invented what the view was and how it worked. You now didn’t have buttons splattered all over the view to manage conversation status, participants, or tags. The main interaction simply revolved around clicking around different conversations on the left and chatting with customers.

My design concept for how “channels” would translate into our view. Heavily inspired by Slack’s “All Threads” view, an account channel lists out all conversations with customers associated with that account. Users would be able to click into individual conversations to view it in detail, just like any other conversation.

Another revolutionary idea that came out of these conceptual designs were the notion of channels. Again, taken straight from Slack and adapted to our system, channels were proposed as a loose definition of a “collection of conversations”. So many sales teams wanted a historical log of every account within Drift, so it only made sense that we offer a solution for this. The idea was that every account would have its own channel, and you would also be able to create channels for specific sales teams. Individual sales reps could pin and star specific channels that they’re interested in, which would stick their important accounts to their sidebar while they keep having conversations with new leads at the same time.

As you can imagine, creating something like this is no easy task. Nothing in our backend infrastructure was setup in a way to allow for or create this, and even if we did make it, it wouldn’t quite work reliably in the way that users would expect it to. Moreover, the team wasn’t really sold on this idea (myself included). Channels work for Slack because it’s a static group of people you’re familiar with. Channels serve as a hub of communication around a specific topic. It really doesn’t translate well to a system where lots of anonymous users can start blowing up an individual salesperson’s inbox with hundreds of conversations. So due to a lot of open questions and confusion around channels, we set it aside as a thing to figure out and eventually get around to after nailing the core experience of responding to individual conversations.

The build

We already had our existing filter panel built, and we needed to start building this Slack-like view. So we decided to simply build upon the filter panel that we had (left) and Slack-ify its visual design a bit while adding all the new features we needed from the design concepts I had for the first milestone (right).

And then we got building. Everything I had so far were just pretty mockups. We needed to build this out and actually test it with users, so we got to work scaling up our existing filter panel to adapt to a Slack-like sidebar that I had in the concepts. We would essentially be merging our conversation list with the filter panel and just have one sidebar.

We also made a very controversial decision around this time, which is to only test this as an internal private beta and keep it under the radar until it was complete. We wouldn’t be testing with external customers and would not let the world know about this until it was complete. I questioned this choice at the time and was a little nervous about not getting feedback from external users before committing to major design decisions, but went along with it because it would mean that we could flesh it out completely instead of shipping half-baked versions to customers like any other iterative launch. So we recruited some internal sales reps and got to work building out the view.

This was our live build of the Slack-like sidebar. We didn’t touch the rest of the view and only focused on the sidebar for now. Having counts for unread messages in every conversation was more technically complex than we had anticipated, so this version only had orange squares in its place to indicate unread conversations.

So we actually built that Slack-like sidebar. And it was quite a treat to see it actually functioning as a real thing. Conversations were coming in, read/unread states were working, and things were re-ordering as necessary. This was the core workflow we needed to nail, and it was great to see it all come together. We were being very scrappy as a team around this time and just trying to validate our assumptions as quickly as possible, so a lot of the old UI was left untouched in favor of first validating the UX.

Validating design assumptions was a huge challenge to deal with through this whole redesign process. This view was notoriously difficult to test with static mockups and basic clickthrough prototypes. There was a lot of live data and real-time updates happening in the view, which was incredibly time-consuming to prototype effectively. We would never be able to simulate a real-time flow of using the view in a steady state with notifications and live updates working properly. And when we did invest the time to do it, we weren’t getting great results. Users had no investment in the conversations they were seeing and they didn’t reflect the types of questions their own customers would normally ask. So we ended up having to actually build something so that users could test the view with their own conversations on their own account (even if it was just internally) in their own daily workflow.

The “All Conversations” view in our live build. We were being extremely scrappy here in order to move fast. The design simply expands the existing conversation list to span the full length of the view while displaying the same information it did in the list. We stuck to our design constraint of always having the sidebar visible.

We ran into an interesting problem when testing this view. Our own internal salespeople use the view in a slightly different way. Our sales team didn’t rely on conversations being automatically routed to them, but instead they “hunted” for leads in the list of all conversations on the site, a workflow we internally termed “prospecting”. We knew we’d need this in order to get the right feedback, so we needed a view that housed all the conversations on the site that could be accessed without losing track of conversations you were already in. Heavily inspired by Slack’s “All Unreads / Threads” views, we added a button on the top that said “All Conversations”, which when clicked swapped the view to an expanded list of all conversations on the site, along with some light sorting and filtering options thrown in for good measure.

And then we tested it with internal salespeople. And…it didn’t go great. Turns out that this “prospecting” workflow was so heavily relied upon by our internal sales team that they were constantly going to “All Conversations”, clicking into a conversation to get context on the customer’s questions, then going back to “All Conversations”, clicking on another one, and repeating the same process over and over. Occasionally, they’d jump in to a conversation, which would add it to their sidebar, but overall the experience of jumping into and claiming a conversation for themselves was simply not working for them. In the old view, they could simply click into a conversation on the left and start chatting. This became much harder in this Slack-like build because we were now forcing them to click multiple times to take the same action.

The learnings

So clearly, this wasn’t working out as expected. We could’ve kept iterating and keep on making changes, but here’s the catch: the more time we spent working on this internal stealth-mode private beta, the less time we spend on solving UX issues in the actual view that customers were using on a daily basis. We were a tiny team. The usability complaints in the existing view were racking up and we didn’t have enough resources on our team to handle both projects. We had no idea what our timeline would be to get this Slack-like view out to all customers due to all the unknowns, so we unfortunately had to scrap it and pivot back to solving core issues in the existing view.

This isn’t to say that it was a complete waste of time. We ideated a lot on things, made visual concepts for a lot of ideas, and even built out a first version of our vision. This failure resulted in a couple of key learnings:

1. We did not properly prioritize workflows for the people we were testing with. We were laser-focused on solving the experience of receiving and managing conversations, but got so tunnel-visioned by it that we ignored a core workflow that our testers had: prospecting across all conversations.
2. Not testing with actual customers was a mistake. This was an internal-only private beta, and we were sort of operating in “stealth mode”. The feedback we were getting was very specific to one type of extreme power-user workflow, which made it very difficult to scale the experience across all of the use cases. Moreover, the people on our team were all pretty fresh to Drift and didn’t feel comfortable making big decisions without knowing our customers and their usage habits well.

Another personal learning for me was realizing that when users and people in product say something along the lines of “make it feel as simple as Slack”, they don’t just mean literally copy the UI. They just want it to work as elegantly as Slack, which often requires hefty backend changes under the hood. You can’t simply change what the front-end interface looks like and expect the entire system to magically simplify itself. Our view is like the final frosting on a cake, where many other complex systems are interacting underneath and creating the foundation for it to work. If those bottom few layers of the cake aren’t providing a stable foundation, it doesn’t matter how great the frosting tastes.

Finally, I learned that designers alone cannot handle sweeping product overhauls like this. There was a lot of pressure on me to come up with a vision of what the view should be and what we should be focusing on. At Drift, designers and product managers are shared across multiple teams, which makes it tough to prioritize big projects like this when you’ve got pressing features and designs to be worked on that are actively blocking the engineers. If you’re ever handling a major product rework, make sure that the team working on it is resourced appropriately and has enough time to fully explore the solution space in order to truly build the right thing.

One more thing…

Before scrapping all of the work for this Slack-like view, I wanted to do one last round of user testing. We had gotten tons of insights from internal sales reps about exactly what they wanted and didn’t want from the view. So I just listed down all the feedback, stuck to the design constraints I was working with, and tried to mockup a very lightweight version of what that would look like if we were to build it out.

My lightweight wireframes for what a prospecting view would look like if we designed it exactly how our users wanted it. I used Slack’s Threads view again as a design reference to showcase the interaction of clicking a conversation and viewing it in a pane on the right before deciding to join it. Users absolutely loved this.

This was a wireframe view that switched up the entire model of how we displayed conversations. Instead of listing the name and last message, we were now displaying the account name and other crucial information like Salesforce Account Owners, location, and company size (all of which the sales reps asked for). This made it really easy to scan down the list, figure out what accounts you were interested in (or look for ones that didn’t have a SF Account Owner), and only then decide whether it’s worth looking at the context of the conversation. If you did decide to click into it, it would open in a Threads-like view on the right, where you could quickly get context on what the conversation was and jump in if you wanted to.

Even though these were extremely simplistic wireframes, we got really good feedback on it. The sales reps loved the idea of prospecting so easily and quickly. On the product side, we were wary of taking feedback from just one sales team and investing lots of resources in building a full-on prospecting workflow (which most of our other customers don’t actually do to the extent that our internal sales team does), so we took some valuable nuggets of feedback from this little experiment and saved it for later.

Part III: A fresh start

Let’s put things in perspective for a second. We failed to ship the filter panel UI improvement due to us using the wrong role model, and we failed to make any meaningful progress on the Slack version of the app due to improper workflow prioritization and a stealth-mode approach. Needless to say, morale in the team wasn’t great around this time. We were questioning why we were failing to function well as a team and what we were doing wrong.

But our path forward at this point was pretty clear. We need to be solving actual problems in the actual view that customers were using every day, not spending weeks and months tinkering with ideas that had uncertain milestones and lots of unknowns. So we decided to just go heads down for a bit on some things that would make a big UX impact in the existing version.

A Compact View

Our existing sidebar (left) compared to our first version of a “Compact View” (middle) and our second iteration of it (right). We re-styled the list based on iOS Messages, a familiar paradigm to our users, and added core features back in after testing with users. We also tested an “Unreads Only” mode that would filter the list down to only unread messages as an effort to reduce the noise in the list, but killed it after getting user feedback that it just ended up being more confusing.

Right off the bat, I noticed that the information density in our existing conversations list was completely inconsistent. Every cell had a variable height depending on how much information we had to display, our tags were styled in visually overwhelming ways, the type styles emphasized the wrong information, and we were displaying tons of irrelevant information in the first place. This absolutely needed to be cleaned up, and I had no idea what information was actually valuable and what wasn’t. So we ran a fun little experiment: kill all the extraneous information in favor of a more compact view, add it as an opt-in toggle to the top of the list, and see what people find themselves opting out of the compact view for. The first version of this removed literally everything from the cells except for read and unread states.

When we asked users their thoughts on it, it turned out that most users didn’t care much for tags or participant information in the list. Boom. This helped simplify the information so much already. They mentioned, however, that they found the avatars useful as a way of anchoring themselves to a specific conversation (it was too type heavy otherwise). Additionally, they found the CQL scores (the lightning bolts) useful as a way of keeping track of high-intent leads. So we added those back in to the second version (along with more useful location/company indication), and then shipped the new version to all users. Validating the assumptions with a small beta pool first really helped us feel comfortable with our decisions before shipping it to everyone.

Our initial list of conversations (left) compared to the final version of our “Compact View” that we shipped (right) after testing with a small beta pool. We removed the toggles and shipped the cleaner UI to all customers after validating all our assumptions and adding back in what users found necessary in their workflows.

A Split Sidebar

Yes, there’s a dropdown up there! Believe it or not, this is how user switched the filters in the list. Users would have to click on the header (left) in order to open a dropdown and switch the applied filter (right).

One of the biggest usability problems in the existing view was that users had to keep opening a clunky dropdown at the top to switch the list of conversations between a bunch of different preset filters. For prospecting in new conversations, users would hunt around either in the Open filter, the No Participants filter, or the All Conversations filter. Then, to manage just their own conversations, they’d keep going back to the My Conversations filter.

The problem was that when they were prospecting in the other filters, they would lose track of new messages and important updates in their own conversations, which in turn left customers on their website hanging. I needed to come up with a solution that allowed users to keep track of their own conversations while also allowing them to keep an eye on other conversations that they could jump into whenever needed.

Some examples of my early ideation for how to alert users about their own conversations while allowing them to view other conversations. I tried a tabbed-layout approach above the conversation list (top-left), tabs for every conversation you’re in above the details window (top-right), the same tabs but at the bottom similar to FB Messenger (bottom-right), and a split out navigation above the conversation list that just exposed all the options in the dropdown (bottom-left).

I explored quite a few options here, because the solution this time around wasn’t as simple as “kill everything and see what happens”. This was a major workflow change and would be a big effort from the front-end engineering side. So I spent some time ideating various options based on how other inboxes and messaging apps have tackled the problem. I tried exposing the dropdown options, switchable tabs on top laid out horizontally across, and even versions where different conversations would be available in tabs across the top or pinned as chat windows to the bottom.

All of them seemed promising and people gave some great feedback in user testing, but we would be introducing so much more complexity into the system here with this change. It would be much easier to actually end up losing track of your conversations with any of these options, and notifying or badging specific conversations with unread messages gets even trickier. So I kept doing some more competitive research until I stumbled upon a solution that harkens back to the design constraints of the Slack-like version.

Discord (left) and LiveChat (right) split their sidebars into multiple sections to categorize and separate different types of content. They also allow these sections to be collapsible and expandable.

There were apps out there like Discord and LiveChat that had successfully used Slack as a role model and split up their one single sidebar into a long scrolling list that had different collapsible sections. This was exactly what we were looking for. Slack doesn’t let you collapse the list because your list is mostly static, but for apps like these with dynamic lists of ever-growing content, collapsible sections go a long way in ensuring that important stuff doesn’t keep falling off below the fold. Confident that this was the right solution for our use case, I mocked up what our view would look like with this type of split sidebar where users could keep track of their own conversations on top while prospecting from the list below.

The final “split sidebar” that we ended up shipping as part of our public opt-in beta. Users’ open conversations would be in the top section (left) and all other filters would be accessible from a dropdown in the section below (right). We had many workflow concerns around a change like this, so we kept it as an opt-in for now.

After some visual iteration on what the styling should look like, I had a solid concept that we could build and test. If the user had no active conversations, the top list (“My Open Conversations”) would be empty, and they could click on a conversation from the bottom list to jump into, at which point it would move into the top section. This did cause some concerns amongst the team about conversations jumping between sections all the time, which could throw off users. There was also a chance that conversations would suddenly disappear based on what preset filter you had selected at the bottom.

Because of all these concerns and our learnings from the past two massive changes that we pushed to the view, we kept this split sidebar gated to an opt-in public beta. Users could try out a new version of the Conversations view, which would put them into this beta with the split sidebar. We also added a way for them to give feedback about the view directly through app, which helped a lot in addressing the main concerns of our users. More on this later!

A Northstar vision

So we were feeling pretty confident that we had solved the most pressing problems in the view, and that we can keep building upon this idea of the split sidebar. In fact, this sidebar was behaving so elegantly and intuitively that I kept pushing it further to incorporate even more types of information in it in the form of a long, scrollable list with collapsible sections, internally named “slices” of conversations.

I created a fully interactive prototype (made in Principle) that showcased how these sections would expand and collapse, as well as scale to accommodate different types of “slices”. This was all done in grayscale because I didn’t have the final visual design figured out yet; I just wanted to focus on the interaction design. Pagination, scrolling, and loading items in the list can get really wacky if not handled elegantly, so I had to make sure it all worked as intended by prototyping it out.

We were asking one sidebar to do a lot, but I had some ideas on how to make this work seamlessly. Users would start off with the same two preset slices that we had in the split sidebar, and they could keep adding custom slices below it based on specific conditions. For instance, displaying customers that are online on the website but aren’t actively engaged in conversations is a big one. Targeted accounts that the sales rep has indicated as important can be its own slice entirely. This was meant to scale and handle lots of different types of data over time, so we were building the foundation for it here.

This was all well and fine, but the product team wanted a better picture of where we were heading long term. Even though we had solved pressing issues in the view, it wasn’t totally clear where we’re going with this product and what the future vision was. The engineers needed to build the infrastructure correctly and we needed to plan our product roadmap ahead of time, as we had been burned in the past by not planning adequately for sudden pivots and a lack of clarity around product and design objectives of any given approach. So in order to paint a better picture of where we were going, I got to work on some “Northstar” vision concepts for the view.

This was my “Northstar Vision” for the Drift Conversations product. A sidebar on the left that handled many different types of conversations and accounts, and a main view that would swap to the relevant screen while always keeping the sidebar visible. This home dashboard had quite a few ideas kicking around in it, including a way to inform users about actions that they should take right now, new leads that need their attention, and other bot-qualified leads on the site.

I took a different approach this time around. Instead of asking “how do we fit all the existing features we have into a nicely organized layout?”, I asked “what would I design this view to look like if we weren’t attached to the existing interface and had no technical constraints?”. This obviously led to drastically different results in the ideation phase. Based on all my learnings so far, I organized all of the crucial parts of the sales rep’s workflow into a home dashboard. This would be what they see when they opened Drift every day. It would summarize all of the key events happening on the site and would prompt them to take action on the most immediate things.

Again, there was a fair bit of asking around actual salespeople to figure this stuff out, because there’s no way I could’ve known all these things myself. Things like meetings booked, lead syncing, information about account owners, and the lead qualification process is all handled very differently from one sales team to another, so it had to be high-level and flexible enough to adapt and accommodate to a specific sales team’s workflow appropriately.

Some alternative concepts and ideas that I had as part of explorations for the Northstar vision. Metrics on individual and team performance (top-left), a better indication of going online or offline (top-right), a right-click menu to bring up additional actions (bottom-right), and a pop-out prospector view that would trigger by hovering on any user in a specific list that displayed important details about the prospect (bottom-left) were all concepts that I toyed around with in this phase.

I also took this opportunity to mock up some wilder ideas based on user feedback that could potentially work well with our view. A lot of sales reps wanted to know how they ranked up against their team, so I added a few status and funnel tracking graphs to help salespeople understand how they were doing relative to their peers. The concept of going online or offline had always been a confusing one in our product, so I modeled an idea for a giant “Go online” button following in the steps of popular ride-sharing apps like Uber or Lyft. For the custom slices, I also had the idea of a “pop-out prospector” view, where the user could hover over some of the online visitors and get quick information about them at-a-glance without needing to swap the entire view just to see a few additional details.

All of these details were great, but they seemed to distract from the overall vision of the Northstar, which was supposed to be simple and focused on one goal. So we scoped out the idea of having a separate home dashboard and all these other tabs and views within it, as well as decided to not get too distracted by the other “nice-to-have” features (like the ones above) before nailing the core of the experience first. Working with my product manager, we condensed the goals of this Northstar down to four simple tenets:

• Smart in-app notifications for high-intent leads
• Prioritized alerts for when Target Accounts are on-site now
• Configurable sidebar with sliced views of active leads and prospects
• Direct editing of lead information right in Drift

I put together this final set of images to showcase exactly what the Northstar vision was all about in order to communicate the goals of this update to the rest of the product teams. The interface here got heavily streamlined to focus on core workflows and everything was prioritized according to these four tenets.

And there we had it. In terms of the actual interface, the view of a single conversation didn’t really change all that much. I just drew a little more attention to the messages, cleaned up the message composer below, and simplified the contact details on the right side. This final design abided by the simple two-pane layout constraint that we were going for with the Slack-like version of the app, and incorporated many of our learnings and insights from the lightweight prospecting view of the Slack app that we had gotten some feedback on. This final version felt simple, straightforward, and intuitive.

This really helped rally the team around what we should be building towards. Before the rest of the team saw this, no-one had a clear vision on where the product is heading or what we were actually working up to. Only after showcasing and explaining these conceptual mockups to the team did it become clear how to proceed forward with the rest of our goals and roadmap.

Public opt-in beta

Now that we knew where we were going, it was time to swing for the fences. We already had a public opt-in beta that users were manually opting into for our split sidebar experiment. We decided to just convert this to a full beta where we would make big changes to the interface and see how people reacted. Our concerns about breaking user workflows were ameliorated by the fact that users could always switch back to the old view if something went wrong or if they weren’t happy with it. We weren’t killing any features and users always had a safety hatch to go back to their old workflows if they didn’t like what they saw in the new view.

The very first thing we did was to darken the list of conversations in accordance with our Northstar vision. I got rid of all the lines separating the content and gave the headers more definition (left), which we then also simplified once users got used to it (right). We also added “Priority Leads on site” as another slice here to test the waters for whether or not this sidebar would elegantly handle so many different types of content and still behave smoothly.

The most immediate place to start here was the list of conversations on the left. Thanks to our Northstar vision, we knew we were going to have a sidebar that had to handle many different types of information and would need to have multiple sections that were expandable and collapsible. And we knew it was going to be dark, so I used our existing color palette from our design system on here and essentially dark mode’d the list of conversations. This was the first thing we built, and we kept making UI tweaks to it in order to efficiently fit more information into it, experimenting with even more compact layouts and information density based on what worked and felt right.

Our old Contact Sidebar (left) compared to the cleaned up and redesigned version (right). We removed irrelevant CTAs on the very top that were crowding the view and brought focus to the content within the sidebar, highlighting each card prominently and even allowing it to collapse into a minimized state.

Another big piece of the view we hadn’t touched yet was the sidebar on the right. This was the “Contact Sidebar”, which provided users with more context on the customer that they were chatting with on the site. An entirely different product team owned this section of the view, so we hadn’t touched this at all. But in the spirit of extreme ownership, we decided to take a big simplification pass at this sidebar and clean it up a bit. We streamlined a lot of the information into cards and added a more sensible hierarchy at the top.

My concept for a collapsed Contact Sidebar (made in InVision) that would allow users to access the respective cards on hover from the collapsed state (the LinkedIn Sales Navigator is shown here accessed from hover).

I proposed an idea where we would have a minimized version of the sidebar that only displayed the icons. Hovering over each icon would temporarily reveal the respective card, and users would be able to hover into each card and take actions as they normally would in the expanded sidebar. This concept was received very well in user testing. It cleaned up the view quite a bit and worked even better to reveal all the available features of the sidebar better than before. In the old version, things hidden below the fold were quite undiscoverable, but in the collapsed state, an icon at least provided an affordance for what else existed down there.

My prototype for the full expand and collapse interaction of the Contact Sidebar (made in Principle). Users could still open the sidebar and scroll like they used to previously, but hitting the close button on top collapses it into its minimized state, where the same cards can be accessed by hovering over the icons.

This minimized state made a huge impact on the legibility of the view. Instead of an entire sidebar, users now only saw a small strip of icons that they could access as needed. We had small badges with counts on some of the icons (like tags and participants) to call attention to them when needed. We also made the choice to keep the sidebar in its minimized state at all times because it’s the better “default” way of using the view. Users could still manually expand it and scroll through the entire list of cards like they could before, if they wished to do so. This collapsed state helped immensely with saving real estate and bringing focus to the actual conversation while still allowing for accessing all the functionality that it had before.

Our old message composer (top) compared to the one where we made some basic visual updates for consistency (middle). In the beta, we simplified it to the extreme to focus on sending and receiving messages (bottom) and moved the other actions like changing status and tagging to the new Contact Sidebar.

The final piece of the puzzle to simplify the view was the message composer. Our old message composer was strange, clunky, and felt incredibly outdated. We decided to take a stab at first cleaning up the UI to see if we could modernize it a bit, which we built and shipped. But still, it wasn’t simple enough. There were tons of buttons scattered all over it, irrelevant icons that got in the way, and weird CTAs that didn’t quite belong in a message composer. All of this got in the way of the primary purpose of the feature — to clearly be able to type out and send messages.

All the icons that were splattered across the top of the message composer were now moved into a dropdown inside the “+” icon (which allowed room to give them a label and make them clearer). Users could still perform these actions when necessary, but the focus was moved to typing and sending messages as the primary action.

So we heavily simplified the message composer down to focus on its core essence, which is to type out and send messages. All of the extraneous actions like attaching files, inserting links, and adding internal notes were moved into an overflow menu (modeled after Slack). The other entirely irrelevant features like managing tags and conversation status were taken out of here entirely and moved to the Contact Sidebar. Overall, this felt like a much cleaner and more intuitive method of typing and sending messages. User feedback echoed the same sentiments.

Change management

We added a CTA at the top of the view where all users could opt-in to try out the new experience which included the darkened split sidebar, our collapsing Contact Sidebar, and the simplified message composer.

As we were launching these big features in the public opt-in beta, we knew we had to deal with educating users about what’s changing and why. We knew there would be a lot of friction to change up an existing workflow to a new one, so we handled this with a lot of caution. In the old Conversations view, had a manual opt-in where people could take these beta features for a spin, with the ability to switch back to the old view at any time. We explained what the new view was before they were switched over and what it did differently from the old one as best as we could.

Users could give feedback from within the product by either typing it out when switching back to the old view, or click the “Give feedback” link to do the same while continuing to use the new view.

We knew we needed to learn from users who were taking the new view for a test drive to see what they liked and didn’t like about it. Was it solving problems they previously had? What features did we remove that they find themselves going back to the old view for? What’s their overall reaction to this? So we added two different ways of allowing users to leave feedback. Every time they tried to switch back to the old view, we asked why they were doing so (submitting this feedback was optional). Additionally, we also had a “Give feedback” button right next to the CTA to switch back, allowing users who had decided to stay in the view a way to send us their thoughts on what they thought was better or worse than the old version.

The feedback that was sent from these modals was piped through a Segment integration into a specific Slack channel where we monitored what users were saying about the new view and its features as we kept shipping changes. The team was quite surprised by the volume of feedback being sent. It was far higher than we expected for a completely optional action. This in-product prompt for feedback ended up being an incredibly valuable tool to inform us about what was and wasn’t working well in the new beta view.

The ability to bulk close conversations was a feature that existed in the old view which we killed in the new one in favor of simplifying the conversation management experience, but we learned that the feature was a core part of the admin workflow. We got a lot of requests to add it back in, and so we did.

By far the most popular request to come from the feedback modals was to add the ability to bulk close conversations back in. This was a feature we had in the old view but decided to kill in the new one in favor of experimenting with a simpler approach that didn’t focus too heavily on managing conversations. The usage for it was very low based on our metrics and wanted to see if anyone would care if we simply killed it off. Turns out that they cared a lot, so we added it back in to the beta.

The few users that used the bulk close conversations feature absolutely needed it for their core daily workflow. These were admins who were monitoring their team’s conversations and would frequently need to close a bunch of conversations at once because the individual salespeople forgot to close them once they were done with qualifying the leads. Upon reaching out to these customers, we also discovered that this was a common workflow on a Monday morning, where admins would bulk close all the conversations that came in over the weekend.

In addition to bulk close, we also added the next most requested features back in to the public beta over time: the ability to change the sort order of conversations, the ability to change the display density of the view, and allowing users to choose whether or not they wanted a “Send” button to be shown in the message composer.

Similar to bulk close, we get many requests to add better conversation sorting options, more flexible information information density, and the option to hit a Send button instead of hitting Enter to send their message in the composer. Again, we had originally removed all of these in the new view because we weren’t really sure how valuable they really were for users, despite having some rudimentary click tracking on them. We had fallen into a trap of adding tons of features in the old view but never quite providing users with guidance or best practices for what setting to choose or use for different situations.

So this time around, we added these most requested features (that we killed in the beta) back to the view in a less obtrusive but still accessible fashion, relying heavily on the Obvious-Easy-Possible framework to decide on how much to expose the features to users. I segmented all our features into these three buckets to ensure that the entire team is aligned on what actions should be obvious, what should be easy, and what should be possible. It cleared up a lot of ambiguity amongst the team when giving design feedback about features that weren’t intuitive at first in the mockups. That was okay, because those features didn’t need to be intuitive, they just needed to be possible.

Responses from the customers who had left in-product feedback after I reached out to them inquiring further about the features they left feedback on. Many of them gave detailed descriptions of how they use Drift and exactly how they wanted certain features to behave for them, which was very eye-opening for the team.

The best part about getting feedback through these in-product modals was that we had the emails of these customers, which meant I could reach out directly to the customers and follow-up with questions probing further on why they were using a specific feature in a certain way. Over the course of two months, I reached out to over two hundred customers who had provided feedback to get a better sense of their workflows. Many of them happily agreed to jump on calls as well to give detailed feedback about the view. All of this was tremendously valuable in ensuring that we were making the right types of changes in the beta and were addressing feedback as we got it.

Some interesting feedback to get on your design work from users. What was most surprising to me is how many users freely admitted to being change-averse and cited that as the cause of them not wanting to try out the new view. It’s a big change and users weren’t opening Drift to learn a new interface, so t made sense.

An extremely interesting learning from all of this feedback was that users didn’t really hate the new view. They simply didn’t like change. Designers who have gone through rebrands are intimately familiar with this notion, but it was incredible to see so many users flat-out state in their own words that they’re so averse to change. They’d much rather cling to the familiar than experiment with something brand new. They had built workflows and hacks around the clunky, unintuitive ways of working in this view over the past few years and were suddenly being asked to re-learn everything.

Ultimately, it all makes sense. Users aren’t opening Drift to learn a new interface. They’re not coming here to figure out where the buttons went and how to perform the common actions. They’re just here to qualify leads and hit their quota. This was a humbling learning for the team, because we spend all our days obsessing about how our product should work and behave, but at the end of the day, Drift is simply one of many tools that our users use in their daily workflow. Asking users to re-educate themselves about an interface that they’ve already been trained on and learned beforehand is simply too demanding without much of an incentive.

Some users really didn’t like the dark list of conversations. It can be strange to get this type of feedback about something you’re pretty confident about as a designer, but it also puts things in perspective about how your opinions about the view simply don’t map onto users living in it and using it all day.

And then, we got a lot of users who simply weren’t fans of the dark sidebar. This had me a little rattled at first, because I was pretty sure that this was a good idea right from the start in the Northstar vision designs. Most modern messaging applications do this to differentiate the types of paned content and it seemed like a great fit our view. But it was causing a lot of contrast issues suddenly going from dark to white while going back and forth between scanning the list of conversations and reading the messages in the main window. It’s still not entirely clear whether the users are simply reacting to change here or if this is truly causing big usability issues.

Intercom Inbox’s dark sidebar (left) to the lighter sidebar that they switched to (right) also garnered a similar storm of negativity from users who found the change too jarring when they launched their redesigned Inbox.

The interesting thing is that even if we went the other way here, we would’ve received similar feedback. Intercom famously went from a dark panel to a lighter one in their Inbox product and their users reacted viciously to the update. Again, they were simply reacting to a big difference in the contrast from what they were used to. Even here, it’s difficult to tell whether this was for the better or not, because reactions to purely visual changes like this are entirely emotional and can be very tough to gauge. We know users will eventually get used to it over time, but there’s no proper to way to ease them into a big visual change like this, so you just have to stick to your guns about the fact that it’s fine and things will calm down soon.

A final note about this is that when dealing with user feedback through in-app feedback prompts, keep in mind that you’re attracting a lot of negative feedback to start with. Users who are relatively happy with the product typically won’t be looking to voice their happiness through the feedback modals. It’s only the ones who are unhappy with the experience and have something pressing to say that will take a few minutes out of their hectic day to passionately write out a few words about how much they hate the new version. As long as you’re aware of this and are ensuring that you’re not taking too drastic of swings based on what a vocal minority of users say, you should be able to balance and prioritize the right features correctly.

Learnings and next steps

Once we were confident that all the crucial user feedback had been addressed through the beta period of opt-in testing, we finally decided to kill the old view and permanently switch everyone over to the new view. We now had high confidence in the fact that it was a better experience, and just needed to bring all our customers with us for the ride. We killed the ability to switch back to the previous view and switched all customers to have the new view.

Once we switched all users over to the new view, a “What’s New” CTA at the top of the view triggered a modal that walked the users through all the changes and updates in the new views to make the transition smoother.

To now deal with the discoverability and re-learning issue, we introduced an in-app education wizard modal that would walk users through all the changes and updates in the view. The CTA for this was intentionally placed right next to the “Give feedback” button so that users had a chance to teach themselves about where something that they were looking for now lived before deciding to drop in a question about missing features. This would also automatically pop up when users would try the view for the first time, just once.

Here’s some good change management advice for product design in general: try to separate the issue of designing the right experience from the issue of user education. Often in product organizations, we tend to conflate the two and inextricably link them together. Just because something can’t be discovered by users doesn’t mean it’s bad design. It simply means we need to deal with discoverability as a separate issue. Nail the experience first and then worry about ensuring that users are able to find it when they need it.

A series of educational GIFs that I put together for sending over to users via a series of targeted email campaigns informing them about all the changes in the view.

We had even split our users into various segments: ones that had tried the beta at one point but then decided to switch back to the old view, ones that had never switched to the new view, and ones that switched and stayed in the new view. We had different email campaign strategies on how to educate these users about the upcoming changes to Drift, so I created a series of short, digestible, educational GIFs that we could embed in emails and send over to these customer segments. This would ensure that everyone is familiar with all the changes coming to the view.

Our user retention goal for the public beta was that more than 70% of the users who decide to try the new view decide to stay opted in to the new view. By the time we had decided to switch everyone over to the new view, we had a retention rate of a whopping 96.5%. Despite all the negative feedback through the in-app modals, we were retaining a very high degree of users who seemed to be using the view just fine, so this also gave us a lot of confidence to kill the old view and simply switch everyone to the new view.

Bringing it all together

The final redesigned and updated Conversations view (shown with the Contact Sidebar expanded and collapsed). If you’re a Drift user on a Premium or Enterprise plan, this should look familiar to you. This is what the new Conversations view looks like at the time of writing this post (October 2019).

So there we have it. Two massive failed attempts at bringing about big change later, we took our time and iterated heavily in the existing view that users were using all the time. We took big leaps and made big workflow changes in a public opt-in beta where we addressed as much user feedback as we possibly could before shipping the changes to all users. We forced a big change to happen in a view that’s notoriously difficult to change or update by being very deliberate and intentional with our choices.

Everything I mentioned in this post happened in the span of eight months. It’s a little hard to believe sometimes, but that’s how fast we were able to push our ideas forward and get user feedback on our work. The key learnings here are:

• Stick with it and be patient. Making changes in a product that users rely on to make a living as part of their daily work is very different than a consumer app. You’ll fail a lot, and you’ll learn a lot. You’ll get a lot of reactions and opinions, so you need to be prepared to ride out the negative storms until you eventually get comfortable enough to hit the smooth seas.
• Keep users in your process. One of the biggest failings of the earlier designs and concepts was that we didn’t get as much user feedback as we could have gotten. Who knows what would’ve happened if we added in-product feedback modals and shipped an opt-in beta to a wider audience with the Slack-like inbox version? Hard to say.
• Split apart the experience from education. It’s too easy to design a great thing and then feel dejected when users can’t seem to find or use your feature, especially in a view which has sixty different things scattered all across it. Don’t worry. Just show them where it is, see if they like it once they can use it, and only then worry about in-app education. Separating these components are essential to drive any product design forward.

Before and after: The change we pushed in the view over the course of eight months. It’s a night and day difference.

Finally, I couldn’t have done any of this without the talented group of individuals I’ve had the good fortune of working with at Drift. A huge thanks to my product managers Alexa Nguyen and Daphne Funston, who were crucial in gathering user feedback, defining the jobs to be done, and driving the team forward towards my designs throughout the whole process. And a big hats off to the Drift engineers Mate Rakic, Brandon Read, Dan Whitcomb, Raymond Cox, Trent Duffy, Christian Connelly, Peter Templin, Miro Jelicic, Nadine Shalaan, Bahar Sheikhi, and Luciana Corteggiano for their unrelenting efforts in ensuring that all my designs were built to pixel-perfection and ensuring that the design quality of this view keeps its incredibly high bar through all the crazy iterations and changes it has gone through over the course of all these versions.

A sneak peek…

Coming soon!

So what’s next? Well, the team has been hard at work for the past few months on something incredibly exciting. We’ve learned a lot through this process and feel like we have a very good sense of where to head next given what we know about our users’ goals and our own capabilities as a product team. So we’re currently in the early stages of trying something ambitious and exciting where we’re building an entirely new product that has some truly next level stuff in it. Hint: It looks very similar to what some of my Northstar vision designs had, and I’m excited to lead the design and UX of this new product as we test early beta versions of it with customers. More on this soon, so keep an eye out! :)

Feb 2020 UPDATE: If you’re a Drift customer, you can download the Mac or Windows build of the desktop app from here. Currently, it only supports the features available on the Free plan, but all paid plan features are being actively worked on and will be coming soon!