Intercom’s Emmet Connolly on design systems
With success at a startup comes the need for your product, processes and teams to grow – often quickly and on the fly. The challenge then becomes, how do you keep the product consistent and your teams cohesive while still shipping quality?
Emmet Connolly, our Director of Product Design, believes the answer to this lucky-to-have problem is to consider all aspects of your design as a system. More than a pattern library or UI style guide, it’s a shared understanding of how the pieces fit together at all levels of your product – from conception and design to marketing and support.
Emmet joined Intercom in October 2014 following eight years at Google, during which he designed Google Flights and co-founded Android Wear. Today he manages 12 designers who are embedded in our product teams.
I hosted Emmet on our podcast to explain how he’s had to evolve the way his team works as its grown, the importance of our design system in that process, how that system serves the product team as a whole, and much more. If you enjoy the conversation check out more episodes of our podcast. You can subscribe on iTunes or grab the RSS feed in your player of choice.
Below is a lightly edited transcript of the conversation. Short on time? Here are five key takeaways:
- The ways your team works are bound to break as you grow. Treat this like a design challenge, and constantly be on the lookout for opportunities to optimize and iterate.
- With a design team specifically, scale makes consistency – and coherence for users – harder and harder. Emmet sees a design system as the solution.
- When building a design system, don’t stay generic. Account for and encapsulate your product’s specific needs and patterns.
- Thinking of your product as a system, and the simple act of drawing how all the system’s components fit together, is useful for any design team, even those at an early stage.
- Face-to-face communication is a powerful collaboration tool for designers, but it doesn’t always scale. This is another place where the shared understanding that comes from a design system, and design values, proves invaluable.
John: Emmet, welcome to the show. To get us started, could you give us a flavor for what you were doing before Intercom? How did you come to be here?
Emmet: Before Intercom, I was a designer at Google for, in retrospect, a shockingly long amount of time, a little bit more than eight years. I worked in a variety of offices and moved from Dublin to Zurich to Mountain View.
One of my big projects there was designing flight search. I also availed Google’s opportunity to spend 20% of your time on some form of side project, and myself and a couple of friends started designing a smartwatch. That project turned into Android Wear, which is Google’s smartwatch platform that launched four years ago. It’s amazing that smartwatches can start to feel like ancient history but that’s where we are.
Emmet’s development of Android Wear included writing its design guidelines for notifications, voice commands and more.
John: Whether it be from Google Flights or Android Wear, what were some of the bigger lessons that you took from those jobs and applied at Intercom? Or are you one of those people that believes you can never apply a template from a previous experience to the next one?
Emmet: You can certainly take lessons. To take what worked for me as a product designer 10 years ago in a certain role at Google and use that as a template to being a Design Manager at Intercom isn’t really going to work. But certainly, I learned a lot from a lot of people and a lot about building product in those years.
First of all, you learn the craft of what it takes to actually iterate a product over a long period of time. One of the things that Google is still really good at is taking a great technical breakthrough, or some big computer science development, and pairing it really well with a UI innovation. For example, think about Gmail, which launched famously on April Fool’s Day with like one gigabyte of storage. That was a horrifically large amount of storage at the time. But, that meant you never had to delete any email, which you always had to do with Hotmail and the likes beforehand.
And so, they didn’t have to have a delete button; they had an archive button, and search became possible and full threading of conversations became possible. A technological or computer science breakthrough becomes an enabler of UI innovation. Google traditionally has always been really good at that. It’s how they’ve taken their engineering-centric culture and really managed to still turn out great products.
John: That’s an interesting take on it, because the simplistic view is, “It’s an engineering-led culture, so it’s a terrible place for anyone else to work.”
Emmet: It wasn’t an easy place to be a designer 10 years ago. Google has also done a great job of reading the winds of how great companies are evolving, and Apple deserves a lot of credit for changing the culture and the value of design and Silicon Valley companies. But Google went through a quiet but quite incredible cultural pivot, which is maybe a lot harder than a product pivot to undertake. They started to move from a company where engineering was the pinnacle and the be-all and end-all, to where design started to be given a lot more importance. I think we wouldn’t have things like Material Design, or Android feeling as modern as it does today, if it wasn’t for that underlying cultural shift that had to happen in the company.
Adapting process as you grow
John: When you came from Google to here, I’m sure that was quite a cultural shift, but you also went from a massive company with a lot of designers to a very small product design team. How does that contrast with today? Presumably you’ve been through various iterations of how you work and teams and structures?
Emmet: There’s a natural wave that you always go through. I did, somewhat intentionally, go from this very large company to a much smaller one. And before Google, I was at a smaller company and had wanted to try out a big company after that. What’s interesting is that Intercom has now grown quite a bit. Obviously not to Google scale, but it’s a very different thing to dramatically shift from a scale of tens of thousands of people to, at the time I joined Intercom, dozens of people.
You need to constantly be on the lookout for opportunities to optimize and iterate.
When you grow with the company it’s a bit like watching your kids grow up. You don’t notice them getting taller day by day. Then suddenly you turn around a year later and you’re like, “Holy shit, that happened.” Things are very different now.
The danger with that, especially if you’re responsible for evolving the team, is that you don’t see soon enough the need to actually change things like your processes and how you work. That’s something that you need to be aware of and look out for.
John: Is it possible to get ahead of that, or is that just the natural way of things?
Emmet: The breaking is natural, and the first time it happens you’re thinking, “Oh my god, I’ve completely failed because I’ve put these processes in place and I thought they were great and they were working for a while, but they must be rubbish because they haven’t worked.” In fact, you’ve simply outgrown them. It’s not about coming in and setting a culture or setting a set of processes and then just letting it run. You need to constantly be on the lookout for opportunities to optimize and iterate.
As a designer you fairly quickly realize this is just another design challenge. Instead of designing the product, you’re designing the team or the machine that builds the machine, which is a tricky design challenge in itself.
The Full Stack Design System
John: That’s something you’ve actually been talking about quite a bit on our world tour – this idea that you’re now designing the machine that runs the machine, and what systems can bring to that. Particularly the Full Stack Design System. What is that and what makes this approach unique?
Emmet: Despite the fact that we’re scaling, Intercom is still a mid-stage startup. We had four designers when I joined in October 2014. We’ve got 12 now. And yet, we’re building multiple products at the same time. It’s kind of a crazy undertaking on some level, but what it really means is that you have lots of designers but still a great deal of ownership over a large surface area of product. As the team scales to 12 people and beyond, it’s a lot to keep up with everyone else’s work. In fact, if you tried to actually keep up with everyone else’s work, you’d spend no time getting your own work done. You’re just trying to understand what everyone else is doing so that you know enough to produce work that’s consistent with it or rhymes with it in some way.
You need to solve that somehow, and the solution that we’re focusing on for solving this problem is to come up with a design system. A design system is not a new thing. We’ve had visual templates for branding and signage and things like that for a long time, but it’s still a pretty nascent thing in terms of web design.
We had things like Twitter Bootstrap, which is a well known UI framework. But, this design system is a thing for us internally to think about a really modular way of building our own products and for a team like mine to think about how to build a system and then build their product out of that system. A bunch of modules or objects that they can reuse again and again. You get things like consistency but you also get more coherence in the user experience. As the user goes from Part A designed by designer one to Part B, designed by designer two, it doesn’t feel jarring because those designers haven’t built the product out of vastly different materials.
That’s essentially it. A lot of it has to do with ability to scale your output and still remain somewhat coherent, without having a whole ton of overhead in terms of keeping up with what everyone else is doing.
John: How hard is it to retrofit something like that to an existing product or to a product that’s actually evolving? It wasn’t like we said, “Hey, we’re going to stop developing Intercom for a while, so the designers can get themselves together and apply this system to it.” That must really be a nightmare, because you find that people use the same language to mean different things. There are inconsistencies all over the place. How do you start to actually develop that system?
Emmet: It’s pretty tricky. It’s like building the airplane while the airplane is flying. You have to do this while developing new features and so on.
There’s potentially multiple levels at which you could tackle this. A thing we did that was effective fairly early was to be quite specific about our language, about the words that we use to refer to different parts of the product. It’s very easy to be fuzzy and non-specific about the words you use. For example, what you call in Intercom a “conversation” I might call a “chat” or a “message”. When we’re having product conversations, literally sitting at our white board and trying to figure out what new features we should do, if we don’t use the same words it’s very easy for ambiguity to creep in. A pretty simple thing you can do is develop a glossary and just make sure everyone understands and is using the same words.
At the UI level, you can try and rationalize every place that, to take the same example, a message appears. You could then take it a step further and have templates for all the different types of messages that you display, and have that be reflective in code so the same code snippets render them and so on.
The real core of the thing is for the whole team to have the same kind of conceptual model of what the product is. It could take years to build all of the templates, code, objects and snippets that you need, but if you have a shared concept and a shared language, that’s a really good start.
A good system guides more than designers
John: You mentioned code snippets there, the fact that engineers are now able to create things in UI and make sure they’re consistent. Does that start to blur the boundaries between designers and engineers? Is that a good thing? Is that something you want when you’re trying to capitalize on an opportunity and move quickly?
Emmet: Sometimes that’s exactly what you want. A lot of this comes down to organizational design and who you think of as the team that creates your work. At Intercom, our designers are embedded in product teams. A product team typically consists of a PM, designer, an engineering manager and maybe two or three engineers. We don’t have this group of a dozen designers sitting in a room together, pumping out mock ups, sending them to a team on the other side of the office and hoping it gets implemented well.
A huge amount of product success comes from designers and engineers working together.
A huge amount of product success comes from designers and engineers working together and coming up with a shared solution. I’m not going to go as far as saying, “Everyone is a designer”, but everyone can certainly contribute to a design process and to the solution. It’s a real mistake if you don’t invite engineers, PMs, researchers, analysts, content strategists and all these other functions that we have into the design process.
John: I suppose the design system makes sure that everyone’s playing within the rules. The rules, by their nature, are sort of baked into it. Is that the idea that a good system like the Full Stack Design System you’ve got will actually just impose those rules naturally?
Emmet: As much as possible. Just to expand on the full stack aspect of it: I mentioned you have lots of these pattern library type things like Twitter Bootstrap, which include a bunch of reusable text elements, inputs, dropdowns, radio buttons, etc. They’re all styled pretty nicely, and it’s hard to make an offensive UI with them. But they’re generic.
Generic pattern libraries and UI style guides like Bootstrap don’t account for concepts unique to your own product.
If you’re a startup building a specific product, if you’re like Intercom or Airbnb or Spotify, it seems a little silly to me to say, “Let’s take this bucket of generic widgets and try to make our UI out of it.” It ignores the fact that your product is your product.
Your product contains a bunch of concepts that should be encapsulated in that system. This is not to say that Twitter Bootstrap or Material Design are in any way poor. They’re just by necessity generic because they want lots of developers to build lots of different types of products and apps using these patterns.
At Intercom, we have much more specific needs. We want to build Intercom, so we should have Intercom patterns. I would imagine it’s the same for Airbnb and Spotify and so on. It makes sense. A mistake that I’ve witnessed is some companies who are creating their pattern library or design system and for some reason, they generally stay at this generic level rather than baking some product concepts into the system itself.
Educate: full stack design in action
John: Can you walk us through a very specific example here at Intercom where we’ve used systems thinking to crack a problem that would have otherwise proved much more challenging if we didn’t have a system in place?
Emmet: A good example is when we launched Educate last year. Educate, at a very basic level, is the ability to allow you customers to help themselves, rather than having a conversation with your customers to support them, which is what Intercom has done quite well for a long time.
We have Operator, a bot that can suggest articles that will answer your question, if your question is a very simple one. The question “How do I reset my password?” might come in, and the Operator bubble will reply, “Here’s an article that tells you how to reset your password.”
That article object exists throughout the Intercom system. We decided that articles were a key part of this new product that we were building, so where can they be useful? It wasn’t just a matter of saying, “Let’s design this little flow where the bot replies and puts in an article.” Once we’ve created that same article and its properties – what it’s made up of and how it behaves – we can create a website that’s like a help center and lists all those articles and displays them nicely. On what we call the ‘teammate’ side, which is where the business has an inbox where they’re talking to their customers, they can take articles and insert them into the conversation. It doesn’t have to be automatically recommended.
You shortcut a lot of extra thinking once you start with, “What does this object need to be?” How can we manipulate it in all sorts of different contexts in our help center? How can we present it there? In the messenger, how can the bot suggest it? In the teammate inbox, how can they send articles to their customers directly? A nice side benefit is that you have one concept that gets reused in a few different contexts, so there’s less for users to figure out as well.
John: What’s the role of opinion in that kind of design system? It sounds like that’s what differentiates it from a design library.
Emmet: The opinion, if you were to call it that, is at the level of deciding what your objects should be. It’s answering, “Should we create a new article object or should we reuse our message object and send people a message with the answer that they were looking for?” We have had lots of very healthy internal debate around things like that, but they are the foundational things that you get right.
Then there’s the whole visual layer that I haven’t really addressed. That’s obviously extremely important, and we spend a lot of time on that as well, but that is a thing that can change and evolve over time. You start to say, “This is beginning to feel a little bit 2011.” That’s the thing that you do want to keep fresh, almost on a rolling basis. But your core conceptual models, your underlying stuff, you want that to be relatively unchanging. That provides a sense of stability at the core of your product design.
When do you need your own design system?
John: Is there a stage where it’s too early to be thinking about your product as a system, or should every startup develop their own in-house design system?
Emmet: It’s hard to say. A better way of thinking about this is what are the signs that you need a design system? It’s very useful to think about your product as a system because it creates a sense of conceptual clarity, even if you’re in a very early stage team.
It’s like how writing forces you to clarify your thoughts.
It’s like how writing forces you to clarify your thoughts. You might think you’ve got a really good idea or concept, but writing it down forces you to articulate it. You almost certainly come up with a crisper articulation as a result of writing it down. It’s the same with actually trying to draw a little map of your objects and how they connect to each other. That’s useful at almost any scale.
Putting a real effort into creating a formal design system – the system that everyone uses – seems like something that might be a bit more appropriate at slightly larger scales. That’s like, “Wow, we’ve got a lot of confusion creeping in between the designers and the engineers when they talk about concepts and the designer creates a design and the engineer has to rewrite a bunch of codes to create that again and again.” Or “We’ve got quite a few designers here now, and it’s quite difficult for them all to stay in sync. We need to formalize the materials that they’re actually working with a little bit.”
Those things are canaries in the coal mine to a certain extent. You’re gonna be doing very well if you manage to detect those things. Honestly, at an early stage, this comes back to what we were saying before about your processes. Very few people think, “I bet our processes are about to break. Let’s put new ones in place.” In reality it’s a bit more reactive than that.
Stepping away from the Sketch file
John: Today you’re essentially a manager of designer managers. What’s the most challenging part of that transition on a personal level, and where can you have your biggest impact?
Emmet: The most challenging thing is letting go of the things that you’ve learned you’re good at and taking this somewhat unknown leap into the abyss of things that you might be shite at, but you’re going to have to give it a go, because that is the thing that is needed next.
I would never say design is easy, but at least I feel comfortable doing it versus a lot of the challenges that you meet as a designer in more of a leadership role. I don’t have a lot of experience in managing managers. That’s a thing that I need to learn how to do and evolve and figure out if that’s something that I’m good at and can grow into.
One of the traits of being a great designer in our industry is having a growth mindset. Someone who is interested in learning new things. When I started off and was cutting my teeth as a designer, it was time to learn ActionScript and Flash. Even earlier than that it was time to learn Macromedia Director. I wouldn’t have been able to build a sustainable career if I’d thought that was it. It’s the same today. There’s an amazing set of interesting new tools coming out, especially in the last couple of years. Maybe it’s been prompted by Sketch but now we have things like Figma, Abstract and Framer. There’s so much for designers to learn.
In fact, it’s frankly a bit of challenge, because there’s so many great looking new tools out there. You need to be somewhat judicious with how you decide to spend your time and what you decide to invest in. But in general, having that willingness to be somewhat self-led in learning and a curiosity to learn new things is something that will stand you well.
John: You’ve always been a big proponent of face-to-face collaboration and critique. How do you maintain that as the team grows and you’re interacting with multiple other people on the product team and the engineering team?
Emmet: At some point you can’t. I certainly can’t and shouldn’t be involved in every design discussion that happens across the organization.
Face-to-face is the highest bandwidth form of collaboration.
Face-to-face is the highest bandwidth form of collaboration that we have, and for designers, I think some form of face-to-face feedback and collaboration is great. There’s this concept of the rubber duck programmer: If you’re a programmer and you’re stuck in a problem, put a rubber duck on top of your monitor and explain the problem to the rubber duck. By the time you’ve gotten to the end of explaining it, you’ve realized the solution. We’ve all had this. It’s the same as articulating your thoughts by writing them down.
Similarly, just by explaining your design problem and where you’re stuck to another designer, and bouncing ideas back and forth, you can really build on each other’s ideas. Face-to-face is great for more than getting feedback; it’s great for working through your own ideas and being able to iterate on them quickly.
Having said all that, pure face-to-face everything doesn’t scale. As we move into having designers in different offices in different cities, we obviously can’t do that, and so you have to rely on other things.
Back to the design system, that helps people have the same model. We’ve also spent a lot of time on our design principles, which help us make decisions and decide what is important when it comes to the trade off between power and simplicity when we’re designing interfaces. Helping everyone have that shared understanding.
Then there’s a bunch of tools you can use. We use Wake, for example, to share work in progress, and it allows us to comment on each other’s work on an ongoing basis. So there is an element where in some aspects it makes sense to become more asynchronous than just face-to-face. Similar to the process stuff, it would be foolish for us to dogmatically just stick to this face-to-face thing. You’ve got to keep on moving in order to grow.
