A conversation on hiring designers with Intercom’s Product Design lead

At Opbeat, we’ve been looking for the next full-time designer to come work with us (hey Casper!), and as part of the process, I reached out to Emmet Connolly, who leads the Product Design team at Intercom.

Luckily for us, Emmet was gracious enough to share some of the learnings he has made at Intercom on how to hire for Design roles.

Below is an extract of our conversation.


We’re hiring another designer at Opbeat, and we’ve had some talks about how to define their role. In the office, we’ve talked about the distinction you make in job positions at Intercom between “Product Designer” and “Visual Designer” — how do their titles translate into the tasks they work on in the everyday grind?

My title is Product Designer, and a lot of what I do is essentially taking tasks away from our Product Manager and executing on them. That means mocking up concepts for new features, detailing how they work etc. Currently, as the only dedicated designer on the product, I’m also heavily involved with the polish of our webapp. While it’s nice to get better at finding where the dropshadow-button is located in Sketch, it’s not my main skill. I think about systems and flows, not elements.

The person we’re looking for should find the latter part more interesting, however. They should focus on making our UI elements and general expression as beautiful, useful, and part of a coherent whole as possible, while not necessarily always being involved in the strategic decisions behind new features.

Would you define these two roles as “Product Designer” and “Visual Designer” as well, or is that being too blunt in the distinction? I mean, I definitely have opinions on what our visual expression is like, but the minutiae of it isn’t necessarily top of my mind — and I’m sure someone focusing more on visuals has opinions about the features we do.


To start with, if you haven’t read our job listings for each role, take a look:

Your distinction is pretty much exactly the one we draw. Product designers are “full-stack”, and if someone really had a hard time designing something that looks half-decent, then I’d be really hesitant to hire them.

How do you define “full-stack”? As in they can think both strategically and visually?

They think strategically (what problems should we solve? how should we solve them? what solution should we invent?) right through to implementation (layout and interaction design of a usable UI, basic visual styling, copy editing). The first part is largely done in collaboration with a Product Manager.

Does “full-stack” also mean they use multiple tools to design the solutions (Sketch, Photoshop, Framer.js etc.)?

It varies from person to person, but a typical designer here does UI work in Sketch and Framer (some use Photoshop, some dabble in After Effects, etc).

In practice, we’ve discovered that we need specialised people in a couple of areas like visual design and mobile design, which is why we’ve recently hired a dedicated Visual Designer. So far his role has been to define new visual styles, do animations, and overall improve our aesthetics. He’s definitely aware of what the Product Designers are working on. It’s not unusual for a Product Designer to take something he’s created and tweak it to “make it work in the real world”.

As you said, this also frees the Product Designers up to think at a higher level: strategic design (i.e. overall product direction, roadmap) and interaction design, without having to sweat the details of visuals too much. This also helps with consistency: they follow his lead without having to invent tons of new styles themselves.

FWIW, our current ratio is 7 Product Designers to 1 Visual Designer.

Oh, that’s interesting! Having only two designers currently (with me working on product mostly), it boggles my mind what eight designers would be capable of producing.

Eight designers sounds like a lot, but we’re building out an insane amount of software… In truth we’re actually building a platform, and four products on top of it, and that’s just the beginning. Which is why we’re still hiring aggressively! I can definitely see us doubling again in the next year.

Do each designer then own a part of the web app and/or platform (web/iOS/Android)? Or do they work on projects/features as a part of an ad-hoc team?

We’ve bet big on the ‘Jobs to Be Done’ framework, to the extent that we’ve organised our product and teams around it. So if you look at the Intercom website, you’ll see multiple products, each one based on a ‘Job’ (basically a use case), and that’s how our teams are organised. So each designer owns a Job, which could involve spanning many features across the entire web app.

Our Visual Designer is actually the first member of an entire team we’re building, who will build out a system model of Intercom (we’re pretty big on conceptual modeling before getting to UI), build a modular component library, and focus on polish/details/consistency across the UI.

As well as a hardcore system designer, I can see us adding a prototyper and maybe even a motion designer to this team eventually.

How do you see motion design play into your future designs? It’s in every way the last thing I think about — there’s just no time for that because it’d take time from me that I could spend working on the next feature, or improve the workings of a current one.

We’re at very early stages with motion design. Our Visual Designer is doing most of that work today, but if/when we get big enough, I can see us adding a dedicated person, but it will be a while yet.

Lastly, could you say a bit more about how you define “conceptual modelling”? Do you want to understand more about how a particular feature plays into the every day work for your users? Or is it about getting an understanding of the system behind a feature, i.e. the flow of screens etc.?

With Intercom being so vast and potentially complex, we try incredibly hard to base everything we build on a few core ‘objects’… Things like a user, a conversation, a message, etc. We mix and match these objects in different ways to create different uses, but we try to keep the basic model, or “map of the Intercom system”, really simple. It’s not about screens at all, in fact, it’s attempting to get designers to think systematically about what they are building rather than chucking a few locally optimised screens together (which would quickly lead to bloat).

Thanks a lot to Emmet for taking the time to answer these questions. It’s immensely helpful to know more about how a bigger team is organizing themselves around their product, and I hope it’ll help others reading about it too.

Read more about Intercom’s approach to design on their blog, and if you’re a developer looking to set up proper application monitoring, definitely check out Opbeat.