Jeremy Keith on the Style Guide Podcast

The Style Guide Podcast, hosted by Anna Debenham and Brad Frost, is quickly becoming one of my favorites. They interview designers from organizations and teams that utilize, predictably, a style guide in their work.

The most recent episode features Jeremy Keith of Clearleft. It’s great episode because Jeremy is able to profoundly put into words the struggle of designing for web in the present day. While I highly suggest listening to the entire episode (41 minutes), here’s part of the conversation that I found particularly provoking (starting at 11:55):

Anna: Do you tend to work straight in code, or do you kind of come up with mockups first and then get them built?

Jeremy: There’s nearly always mockups first. I guess the question is how long you spend refining those mockups…

There’s three reasons a mockup could exist. One is that it’s for buy-in. It’s basically for sign-off. You’re mocking something up to present it to a decision maker who then says thumbs up or thumbs down…

Use number two is its a deliverable for a front-end developer, so in other words it’s something a visual designer gives to a front-end developer to get turned into code. That’s a separate use case. Now here’s problem number one is that mockups made for the first use case end up getting used for the second. So if you’re designing for sign-off everything’s perfect. Everything lines at the top and the bottom…everything looks beautiful…Well, everyone’s just going to get disappointed, right? The developer’s going to get frustrated because it’s not accurate, the designer’s frustrated because, “hey, that doesn’t look like my mockup,” and the client is frustrated because that doesn’t look like what they were presented with…

And then there’s a third use of a mockup which is for a visual designer to think…they have a tool that they’re comfortable with, like PhotoShop, Sketch, Illustrator, whatever, and its the fastest way for them to get ideas down is to create a mockup.

I think that’s extremely insightful. Everyone agrees that a mockup isn’t the website, but this artifact has different purposes in the process. Jeremy continues:

They’re three very different use cases…[A]nd yet what happens is a single mockup will end up kind of doing all three…

So this is the problem…we found in general is that there’s this mismatch, I guess, of expectations. And this is why I love Dan’s [Mall] idea of deciding in the browser…Yeah, you do stuff in PhotoShop or Sketch or whatever you’re comfortable with. It’s more about that third use case, use whatever tool is comfortable with you. But you don’t go to the client and say approval or not approval until you’ve got it in web browsers until you’ve got it in code. Because that’s just so much more accurate to reality.

Wow. Jeremy puts into words the things that we struggle with so well. While even he admits that they’re still refining their process, I think it’s a step in the right direction. The approach sounds more true to the medium.