Zendesk is a customer service platform that lives by 3 principles: be genuine, listen to customers, and keep things beautifully simple. Having this design-focused organization in the InVision community is something we’re really proud of.
We sat down with Brent Palmer, Product Design Lead at Zendesk, to hear his thoughts on running effective design critiques, the worst feedback he’s ever gotten, and how to spot jerks during the hiring process.
How is your team set up at Zendesk?
I’ll talk about the product design side. We have 8 products, and they’re all distributed by city. So in every city—Montpellier, Singapore, Melbourne, Dublin, Copenhagen, San Francisco, and Portland—there’s a design lead and a design manager for each project, and each manager has 2-3 product designers below them.
We all report to the Director of Design, Charles Stabb, and Charles reports to Ryan Donahue, the VP of Design. Ryan reports to Toke Nygaard, the Chief Creative Officer. Product design and brand starts to diverge at Charles’s level, so we product designers interface with him quite a bit.
How does your team make design decisions?
We try to be as objective as possible, and we try to validate our designs early and often. This is assuming that we have a business model, or maybe a roadmap’s been planned out and we prioritize what we’re building and why.
I think every designer would like more influence on design decisions. But as far as the day-to-day, and how designs just get made—on a tactical level, we have a UI library that takes a lot of decision-making out of it. It’s called Garden and it’s being worked on and being produced in conjunction with the rebrand.
“Validate your designs early and often.”
Right now we’re redesigning all of our products around the world, so we have an updated refresh component library that we’re trying to pull in, which is great because all the rigor and the validation is vetted. We apply all that upfront so the component is rock solid and we can share that. It helps us ship faster and more easily make design decisions. Still, all these are just components, and they have to be put together in a larger ensemble.
We have several methods of validating our designs, but we usually start with a discovery. We work closely with data analysts throughout the whole process, too. We figure out the problem we should be solving, where the breakdowns are in the UX, what the clicks are, what the heat maps are like, etc. And then we can pair that with the why, the intent.
So, if we have a design or a proposed design solution, we can target those customers pretty easily. We can reach out to them via email or by phone to conduct an interview. If we feel like we’ve gotten a design solution worked out, we’ll show them a prototype and get their feedback.
We also do quick validation with UsabilityHub—eyeball tests, click tests, things like that—and use InVision to help answer questions like whether something should be a drop-down menu or a tab.
What do you think makes your team, and maybe just design teams in general, work really well together? And how have you gotten to that point?
A good team is built on trust.
Once you get to a place where you can share information and you can share work without being jilted, that’s a healthy sign.
I’ve always thought that Zendesk does a good job in regards to the social, physical, and emotional components of a great workplace. The social component would be something like, are you friends? Do you feel like there’s unique perspectives that are collected here? Can others rely on you to do good work every day?
With the physical side, are the spaces flexible? Do you have whiteboards and materials that you need?
The emotional component is important, too. There needs to be stability and growth, and people need to be constantly learning and know that it’s okay to fail publicly. Egos are checked at the door, and we do a great job here not hiring egotistical maniacs. At the same time, we do a good job of not hiring delicate geniuses who may be super sensitive.
A lot of design organizations will throw a big salary at a rockstar designer. But it’s all about the chemistry of the team. Sometimes that rockstar will come in, and because they’re a delicate genius, they can’t collaborate. To me, that’s just half a designer.
“You can get answers so quickly with an InVision prototype.”
Do you have any tried-and-true methods for spotting those types of people during the hiring process?
References. References are gold.
So, if you’re calling up references, there are particular questions you can ask that, when phrased correctly, open the door for feedback on the candidate. You can’t just ask a reference if a candidate is a jerk, but you can ask something like, “What advice would you give me on how to manage this person?” Or, “If this candidate wanted to grow in their career, what advice would you give me?”
How did you get into design?
As a kid, I drew all the time, and I was a huge fan of Garfield and The Far Side. I thought I was going to be the next Gary Larson or Jim Davis. I’d set up a comic strip on the left and a blank sheet of paper on the right, and I’d redraw comic strips all day.
I wound up studying advertising at the University of Texas at Austin, and my program was heavy on copywriting and art directing. For me, combining professional art with making money just made the most sense, career-wise.
Can you tell us about the design culture at Zendesk?
What I like most about it is that everyone’s freed up to do the work they need to do—we’re all empowered.
Our Chief Creative Officer, Toke, has built things up around this quote: “Don’t hire people for the job—they’ll just do it for money. But if you hire people for what you believe or how you believe it, they’ll run through walls for you.”
Everyone there wants to do good work. Critiques are run well, and they’re never personal—they’re objective. Everyone feels heard. There’s a nice balance between collaboration and being inclusive on a process, but also sharing ideas.
At Zendesk, we’re in a unique position in that we have our product designers on the engineering side and our marketing designers on the brand side all report to our Chief Creative Officer. We’re going through a rebrand right now, and having brand and product design under the same roof is immensely helpful.
How do you run design critiques?
We do critiques both formally and informally. For example, we’ll get a Slack thread going about a piece of work, and people will chime in on it. Or, here in Europe, we have a weekly design meeting where the agenda’s stated beforehand in order to be completely clear about the problem we’re solving and why, and who we’re solving it for. Sometimes things seem obvious, but you should always be as clear as possible.
I’ve been in critiques where you just kind of put work up and ask if people like it. We avoid that. What drives decision making and what ends discussions is some kind of validation. So if we take out the echo chamber of designers and we say, “Okay. Look, it was validated this way with customers.” then everyone gets on board with that and moves on.
Are there any statements you try to avoid when you’re giving feedback?
Giving and receiving feedback is a skill in itself. When I give feedback, I try to reframe it as a question.
Reframing feedback as a question allows you to put that inquisitive seed in there, and then the designer can reconsider and own that process themselves.
It’s also really easy for written feedback to be taken the wrong way, so I try to speak with people face-to-face as often as possible so we can have a dialog around that feedback. When in doubt, don’t send a Slack message or an email—go talk in person, or get on a video call.
“Designers should think of themselves as being part journalists.”
What’s the worst design feedback you’ve ever gotten?
A few years ago, I did some designs for a client at a consultancy. I thought they were really friendly and useful, and they tested well. When I presented them to the client, they said they wanted something “more enterprisey.”
Where do you see design headed and how can designers prepare for that?
Designers should fall in love with data. There are just too many tools out there to take your design and your idea and your solution out of the realm of subjectivity and objectivity.
Related: Getting started with data-driven design
Prototyping in InVision is one of those tools, right? You can get answers so quickly with an InVision prototype.
There’s this myth that data is a crystal ball, like it’s an actuary that predicts which design is going to be the best. But there’s no perfect design—there are many options that could work.
Gone are the days of a designer sitting with headphones on and pushing around pixels and mockups. Designers have to be part journalistic in their approach—how they investigate usage in their products, how they interview and talk to customers. Designers have to be reporters with a journalistic spin.
As design gets a bigger role at organizations, designers will have to validate or communicate their ideas at each layer with a certain amount of validation. And you can easily do that with the myriad of tools out there—Optimizely, Google Analytics, InVision.
How does your team use InVision?
We use InVision to keep the conversation moving along internally. So, I’ll put together proof of concepts and we can share those internally with product managers and engineering leads. Looking at InVision projects helps them easily and quickly understand the entire UX and flow.
“InVision makes language barriers a non-issue.”
For example, billing within Zendesk across 8 products is pretty gnarly—and it’s across all the products, and all the different teams around the world. InVision breaks that language barrier. All the time we’d spend on conference calls discussing the flow, we can instead just demonstrate with an InVision prototype so everyone can actually see it, play around with it, and get it.
InVision bridges that gap between whiteboarding and conversations, and then high fidelity.
And personally, I absolutely love Craft—I use Craft Sync and the Data plugin every day. Our engineers also love how InVision’s now connected to JIRA.
Do you have any advice on how designers can work better with developers?
It seems obvious, but just collaborate with them—and include them early and often.
Find the developers who are product-centric or have a UX focus and just latch onto them. They want to build great products, too, so treat them as a partner.
“Developers want to build great products, too.”
With the best products I’ve worked on, we all had equal footing. The engineer, product designer, and the product manager—we were all like the 3 legs to the stool.
That healthy tension makes the best products.
Photos courtesy of Zendesk.
