Fog Creek

Designers Doing Development – Interview with Cap Watkins

In this interview with Cap Watkins, the new VP of Design at Buzzfeed, formerly Sr. Design Manager at Etsy, we discuss his approach to product design and design management. We cover how to get and use feedback, why designers should code and engineers should design as well as working practices to encourage this. We finish with hearing about resources for non-designers interested in product design.

You can learn more about design and design management on his blog.

Content and Timings

  • Introduction (0:00)
  • About Cap (0:24)
  • Competitor Analysis (1:34)
  • Getting and Using Feedback (3:10)
  • Why Designers Should Code (6:30)
  • Why Engineers Should Design (10:20)
  • Recommended Product Design Resources for Non-designers (12:38)

Transcript

Introduction

Derrick:
Today we have Cap Watkins, VP of Design at Buzzfeed, previously Senior Product Design Manager at Etsy, previously in design roles also at Amazon, Formspring and the first designer at Zoosk. He speaks and writes about design and design management topics at conferences on his blog at blog.capwatkins.com.

About Cap

Cap:
So I like to start with a confession before I talk about design stuff. I’m not a designer. Sorry, I’m dropping this on you right now, but I’m not a design by education or anything. I was actually a Creative Writing major in College and got out of College and didn’t really, like every good English major, I didn’t know what to do with my life. And went and did what every good English major does and worked in a coffee shop for about a year. Wrote a bunch, played on the Internet. I had learned pretty early, when I was sixteen how to write HTML and use Photoshop 4.0 at an internship I had. So I was doing that for some friends for like cash on the side. A couple of friends got their startup funded in Oakland and needed a cheap designer, which was me because I figured it was better than my coffee shop job. And so I moved out to Oakland and, yeah just went from there, that was my first startup. And then went on to work at Zoosk, like you said, Formspring, Amazon, Etsy.

Competitor Analysis

Derrick:
You’ve written a few posts about your design process and one thing I noticed right away was that Competitor Analysis was right there with the problem definition at the beginning, why is that such an important stage?

Cap:
It’s hard to, I think some people feel weird about that, some people feel like concerned that they will see something that someone else did and they’re not going to be able to think outside of it. I know that some designers try and silo themselves away from competitor analysis, at least at like, the beginning. I’ve found it super useful, I think like whenever I do design work, I’m always writing down the pros and cons of each approach that I’m coming up with, because nothing’s perfect obviously. It’s good to be honest with ourselves about what is good and bad about what we have done. But what’s really helpful to me is looking at what other people have done, and the pros and cons of those designs, so that I can avoid the cons of the designs and take some of the things that I really like.

When we’re working on Etsy, we’ll look at Ebay, we’ll look at Square, Shopify, which are all great products but obviously different from Etsy and have different problems they are trying to solve. So the pros and cons of those, what’s good and not so good about those designs, helps us identify opportunities that we’re missing, or problems that we want to avoid. I’d rather know that upfront, not get like 6 weeks down the road and see this other thing and be like ‘oh, that’s pretty good’ or ‘yeah, that’s bad and I’m doing that too.’

Getting and Using Feedback

Derrick:
So, you’re looking at other products in similar spaces and getting feedback. There’s other ways about getting and using feedback that’s heavily build in to your process too. What are some of the techniques and tools that you use to get feedback on your work?

Cap:
Sure, so at Etsy what we use is Basecamp. It’s like a religion for the design team. We use it kind of differently than I think that other people do. Basecamp is actually Project Management software, but we don’t use it that way. It’s just for design work at the moment. So what happens is, there’s 27 product designers at Etsy now, and it’s really hard to keep up with everything going on obviously for all of them. And we are all better off if we’re seeing each others work all of the time and able to give feedback. And also just see what is happening. So when I’m like designing something and someone else is, we can like merge those efforts if we see the opportunity. And so what Basecamp does is it allows us all to, we put all of the designers on every project, so every designers adds all of the designers to their project and then starts posting work. Constantly, right the way throughout the process. Every project starts off with a written list of problems we’re trying to solve, goals and that sort of thing. And then it just goes from there. So it’s like a constant, regular feedback loop. And then the other thing we do, we have a couple of in-person meetings each week. So like, a small design team will get together each week and the larger design team will get together once a week to share, get feedback and critique. Obviously with 27 designers, the bigger group thing is little bit more high-level. It’s hard to get like deep down in the weeds with it, but like, it works pretty well.

Derrick:
You’re obviously working on things that are visual, it seems like everyone is going to have an opinion, with a lot of feedback like that going around. How do you know what to listen to?

Cap:
It’s a good question, it’s something that we’ve been working on at Etsy. Because also, in addition to the designers, your entire team of engineers and product managers are on those threads as well. So like a designer will put their product manager and engineers on the thread with all of the designers. And we kind of figured out, it was OK for a while, we only had 9 designers for a while, and it was OK because we were only small and we had pretty tight feedback, so it was OK. Now there’s a lot feedback at times and it feels somewhat overwhelming. So what we’ve been trying to do is, we kind of made a blanket statement, so if it’s your team responding, so if it’s your engineers, your PM, your design manager, the other designers on your team, then that stuff is important to listen to. So like make sure that you respond to, make sure you’re having that conversation that’s open. But if it’s coming from outside of that team, like another design manager outside of your team, then it’s just an opinion, you do not have to, there’s no actionable thing to do there. Unless you think that you should. Like that’s a good idea, I should do that. We’ve also set that expectation with everyone else. So if you’re outside the team, give feedback, no problem, say whatever you want to say, do not expect, like there should be no expectation of action. And if you feel super strongly about it, like come talk to the whole team, and have that conversation, but don’t like you know, fire off like a one-off opinion in to Basecamp or in to email or something like that. It’s a randomising thing.

Why Designers Should Code

Derrick:
Any key part [of your design process] is coding up your designs. Why do you think designers should code?

Cap:
For the same reason I think engineers should design. I think, I’ve never not coded. Just like, I’ve been in startups for so long where being a designer also meant I wrote the front-end for everything I did. And it made working with my engineering partners like, really, really easy. Because we were talking about the same thing, which was the codebase. And I could like, I don’t know how to write back-end architecture or anything like that, but because I am talking to them about the front-end architecture they are explaining to me the harder, the more complex parts of it, of what they do. So because I’ve worked with them so closely, I have this mental model of how things work so we can have an intelligent conversation about back-end architecture sometimes, without exactly knowing what I am talking about. And I just feel like that cross-pollination of responsibilities and ideas, like makes the product that you are working on better. Because everybody is responsible for everything. Designers at Etsy are also like semi-product managers. They think about the product we are working on, where we’re going, why we’re going there, like how to get there, what’s next. And like the engineers think about that stuff too, we have a lot of great product-minded engineers that really care about those same questions.

I’ve been at places where it has been siloed and it hasn’t been that great. And the product is not as good as it could have been as if people had shared the responsibility. And like, front-end, HTML and CSS, isn’t that hard to learn. Like, it just isn’t, it’s very presentational. Like, some of the more complex stuff gets harder, but just dipping your toes in is pretty simple.

And we have a lot of mechanisms at Etsy to teach those how to do that. We’ve hired designers who are strong at UX and Visual Design but aren’t quite there with front-end stuff. And like, we have a strong engineering team who will totally help teach the designers how to write code. We have a design bug rotation once a week, where two designers sit down and crush through a bunch of design bugs on the site and deploy them. And we’ll pair people together, so someone super senior in that area and then maybe someone who is just coming along. They’ll pair with them and be able to help them. So there’s a lot of mechanisms for providing that. And I think it’s because the whole organisation buys in to it that we’re able to do that. If the engineers were like ‘we don’t want people in our code, period’ then it would be a lot harder, right. But luckily they’re all like ‘this is amazing, I can’t believe this happens, this is good.

Cons are definitely you’re limiting yourselves to who you can hire. I talk to a lot of designers who are great designers, don’t write the front-end and have zero interest in doing that. So we hire people sometimes who haven’t written HTML and CSS hardly ever. But it’s all circumstantial though right. There in a place that doesn’t let them do that, or like they’ve just never had the opportunity but they really want to, and we’re totally down for that. No problem, come on let’s go. Yeah, so I definitely talk to a lot of designers who don’t want to do that, ‘it’s not my job’. Which is totally a legitimate and reasonable thing to say, it’s just not something that fits in with our culture at Etsy. And it makes it hard, there’s just not that many people who are good at everything like that. At like the whole stack of design, so that’s tough. I talk to a lot of designers, to find like, the ones that can do this stuff.

Why Engineers Should Design

Derrick:
You said developers should learn design too, is that something you strongly believe in?

Cap:
Yeah, like I just want everybody to feel as close to the product that we’re building as possible. I want everybody to feel like so much responsibility, from the very, very first meeting all the way through to like deploying the code at the end. So we involve engineers in all the design discussion that we have. So we’ll have a design kick-off at the beginning where we’ll just like run through problems, like ideas, like we’ll be sketching together. I constantly see people going to whiteboards together and working through design problems with an engineer and with a PM obviously. And it’s like, engineers don’t have to create the artefact. If you think about design as just a thing you make, like it’s the photoshop file, or it’s the sketch file, it’s like, yeah probably not. Engineers are probably not going to do that, they shouldn’t have to do that. But if you look at it like more of the process of product development as one continuous timeline it all starts to make more sense. So yeah, if you just like siloed off, if you have a timeline that’s like this long. Oh we design this much, and we engineer this much, and then we deploy and measure this much. Like, siloing those things off feels like, bad. When it is one timeline, if you look and everyone’s involved from here to here, then it means that you like won’t drop as much stuff. People will feel like at the end that they can really defend what we did, and are really invested.

Derrick:
Are there any other practices that you use to encourage coding skills in designers, and vice versa, design skills in engineers?

Cap:
We just got finished sending a lot of engineers to essentially bootcamp for iOS and Android development. And it was funny, as soon as the design team found out we were doing that I got like ten emails that were like ‘I want to go to that.’ So we sent a bunch of designers, I think all of them actually signed up to go to these bootcamps to learn Objective C and Java. Which is completely outside of what we expect from them, but like they just can’t help themselves. They just really want to get in there.

Recommended Product Design Resources for Non-designers

Derrick:
Do you have any recommendations for non-designers interested in developing their knowledge and understanding of product design?

Cap:
Designer News is like a pretty cool resource, just to like see what’s going on. Like, a lot of designers do this – just ripping off people until you get it. Until they understand why something is happening. And a lot of the advice I give to folks is like, just to go design stuff. Build stuff. As for critique from a designer you know.

There’s an engineer at Etsy who is like always building a side project. Always. Like never doesn’t have a side project. And it’s always super cool and he’s always sending me his projects and is like ‘so what do you think to this design?’ And like he bought himself Sketch. Sketch is like 50 bucks or something like that on the App Store and pretty easy to get. Pretty cheap to get. And started fooling around with tons of tutorials online. And you can just like find a designer, a designer you like who will spend time with you. I find engineers I like to spend time with me and stuff.

Derrick:
Great, fantastic. You’ve given us a lot to think about today, I really appreciate your time today Cap. Thanks for joining us.

Cap:
Thanks for having me.

Derrick:
No problem.