Alert Email External Link Letterboxd 0.5/5 stars 1/5 stars 1.5/5 stars 2/5 stars 2.5/5 stars 3/5 stars 3.5/5 stars 4/5 stars 4.5/5 stars 5/5 stars RSS Source Topic Twitter

Interview: Rob Weychert

Interview by Breandán Knowlton

Rob Weychert is a Brooklyn-based freelance graphic designer,striving to create layouts and interfaces that are organized, intuitive and easy on the eye. In recent years, he has shared his design expertise as a creative director at Happy Cog in Philadelphia and as an interaction designer at Harmonix in Boston. Today, still wanted by the government, he survives as a soldier of fortune, slowly piecing together a plot for world domination with his cohorts at Studiomates.

Rob talked to Breandán about his design process, prototyping and testing, including some parallels to his work in print.

BN: Could you start by talking a little about what you’re up to these days?

RW: After I left Happy Cog, I took about a year and a half detour in the games industry1, doing interaction design. That turned out not to be exactly for me, so I decided to move to New York and start working for myself, which I’ve been doing for about a year. Honestly, it’s been kind of slow to start. Not for lack of interest – I’ve received a lot of referrals from friends, which has been really helpful, but I’ve just been slowly acclimatising myself to running a business and figuring out my pace, what I need to do and how I do it all.

BN: Does your business have a name?

RW: It’s Rob Weychert Design, LLC. Real simple. I tried to get cute and clever about it, but then decided to be straightforward.

Over the last year, there have been a handful of projects: a couple of websites that I designed and did the front-end development for. I’ve helped design pages for a start-up. I was working on a project with a publisher about an article prototype, a responsive design prototype. Now I’m finishing up with the latest A Book Apart books, doing print production and composition.

BN: Back to print again!

RW: Yeah. And there are a couple of potential web projects in the pipeline.

Visual design in print and web

BN: Since you’re coming from both print and web – one reason I wanted to chat with you – can you tell me, when you’re building up a visual system, do you take a similar approach for both? What does that look like?

RW: I do take a similar approach – of course, taking into account the factors inherent to the medium. There are certain aspects of the visual approach that are better suited to print than the web.

BN: Do you start with type, color, or something else? What do you do, in what order?

RW: It’s funny – since I got clued into web standards, I’ve changed my whole process, even for print stuff. I’ve gotten back to thinking about design as interpreting meaning, as opposed to dressing things up. So when I work on a print project now, I tend to mark things up as if it was a web project, even though the end product will not be marked up. Since there’s already an established hierarchical language which I can use, and do on a daily basis, that’s become my standard for doing print projects. I tend to sort of use that approach even for A Book Apart. There are different heading levels — you can see them as heading 1 and heading 2 — block quotes, and all that sort of stuff. I see it through a veil of markup now, which is kind of weird but is helpful.

BN: So you’re like in those movies, when the guy is out and the code is flashing?

RW: Yep, I can see the matrix.

Presenting Designs and Prototypes

BN: That’s pretty cool. But people who can’t see the matrix quite as well, like clients, can have a different idea about what design is. What’s your general approach to communicating with them?

RW: I try not to just present stuff and say “Here’s what your site will look like – isn’t it great!” I try to go into a little bit of depth without getting super-nerdy. I explain what’s how the hierarchy works, why it’s set up the way it is and all that sort of thing. So I might not get into “Here’s how markup works,” but I do try to explain the separation of structure and appearance, why that’s important and how it’s dealt with. When there is a system in place, I take pains to describe how that system works.

BN: Do you ever come back with multiple directions and ask people to choose between them?

RW: Yeah, I still do that a lot. That was the way we did things at Happy Cog. It’s one of those things that works great for some projects and not for others. But when I give multiple directions and ask which one they like best, I do try to talk through the benefits of each — beyond saying, “I like green!”

BN: Do your clients ever end up saying, “Well, I like green, so this design is better”?

RW: It depends. When I present multiple options, I try to explain the problems with “frankencomping” or “solutioneering” or whatever other name you may want to call it. I make it clear that each one is a holistic approach so smashing them together is not necessarily going to create success. We can still arrive at something the client’s satisfied with — with one of these things as its foundation. And the end result may be substantially different from any of the foundational approaches. It’s just a matter of seeing the potential in something — seeing a nugget of what you’re looking for in one of those directions.

I don’t just throw them a bunch of stuff and say, “Hey, here are some designs: pick one.”

BN: Can you do it remotely, or does it need to be explained in person?

RW: Actually remote discussion works best for me. Speaking off the cuff doesn’t work as well for me as Basecamp threads or something like that, where I can put my thoughts together really carefully. Conversations in person certainly help the feedback aspect, though. People want to see designs up on a big screen and point at things, but for my initial presentation, it helps me just to write it out.

Using frameworks for prototyping

BN: A lot of standards guys seem to really like hand-coding stuff in TextMate because they can. Since you are working with web standards, you’ve also talked about wanting to have that level of craft. Do you use any of the frameworks out there as a starting point?

RW: Nope. I’m vaguely curious about the 960 grid system.

BN: Seems to be a popular one, and you can tell just by looking at the websites.

RW: Yes, there’s that. I feel like making extensive use of those sorts of frameworks — even though a lot of them are really flexible — can set you on a specific path right from the beginning, whereas I’d rather be restricted by the content than by the layout options that I have. I want the layout to do what’s best for the content. That’s not to say that those sorts of designs and frameworks are always mutually exclusive, but I don’t like working with other people’s code. You know the saying, “Hell is other people’s code”. Well, frameworks are other people’s code. Plus, most of the frameworks that I know of haven’t accommodated the way I’ve always done things, although that’s changing with responsive web design exploding all over the place.

It’s not always possible to start from scratch. When you’re talkinga out jQuery and stuff like that, for somebody like me who is far from being a JavaScript aficionado, pluggin in that stuff is a different story. But when it comes to straight up HTML and CSS, I like to have as much control as possible.

Content, design and interactive wireframing

BN: Does your print experience play into the way you approach design? In print you tend to have the content at hand when you’re starting a print layout, not just a placeholder for a flyer or a poster so the words cand be put in later.

RW: Most content-oriented web design is akin to print editorial design, where systems and flexible templates need to be designed. But there is a lot more contingency and templating in web design, where you need to know as much as possible about the content that needs to be accommodated before you design. And that’s tricky.

In the new version of my site, for example, I’ve got this ridiculous blob of code that basically handles all different kinds of nested lists. I guess some people would have boilerplate stuff that they use for lists – I should probably do something like that, but it’s so tricky because it’s so circumstantial. Some sites will never have to deal with video, tables or things like that, while some will have all different kinds of content. That aspect is definitely different from most print design. In print design there’s a thing: you make it, you made it, and then you’re done. But editorial design definitely has similar challenges, where you need to have a solution at hand for lots of potential problems.

Client education

BN: Do you find that you have to educate your clients to get content delivered early in your projects? Perhaps it depends a little on who you’re working with?

RW: Yeah, it does. Certainly at Happy Cog that was a challenge, even though we had a lot of very smart people who knew what was going on. I think there’s still a prevailing attitude of “We’ll get to the content – eventually.” People can get so excited about the design and the process that they forget they actually need to do something with the site.

Honestly, in the last year or so, I haven’t run into that problem so much. I did a blog design for this guy who was writing all the time, so there was never a shortage of content for me to work with. I’ve been fortunate to not have to chase people for content so far, but I’m sure I’ll be in that situation down the line.

Designing for mobile

BN: To what extent are you considering non-desktop-browser environments for stuff that you’re working with on the web?

RW: I am excited about responsive design, and I hope to be doing a lot more of it. It proposes new workflow challenges. Am I going to design four different versions of a comp to show people how it would work on these different screens? Or am I going to convince them to trust me to make the baseline design look just as good in all these different instances? I ran up against that dilemma while doing something for Adobe recently. I think the way we ultimately went about it was a mistake, so I’ve learned from the experience. Basically, for the first round I gave them a desktop layout, and for the second round I gave them three different sizes based on different screen sizes. I gave them the opportunity to have revisions on multiple screens, and it was a mess. So I’m still figuring that process out, as are a lot of people.

Ethan Marcotte touches on it a little bit in his book, Responsive Web Design, but I think it’s such a new concept that there is a lot of exploration to be done. Never mind the fact that there are a million different devices that handle things in a million different ways. Luke Wroblewski’s book, Mobile First, really gets into a lot of that discussion.

BN: So does Mark Boulton’s Designing for the Web.

RW: Yeah, it’s a tricky issue, but I’m definitely not ignoring it. I spend more and more time online on my phone or my iPad, and there definitely are a lot of desktop-centric user paradigms that don’t work in each environment. I try to shy away from using a lot of hover effects and things like that, for example. I try to shy away from those effects anyway, just because of accessibility for people with disabilities. So, in that way, all this mobile stuff has been really helpful for accessibility.

BN: Is it yet possible as a designer to think about the elements of your page as a hierarchy that can flow or manifest in different ways? Or is it still a question of saying, “I’ve got a screen this wide and another screen this wide – they each need to be rethought”?

RW: I’ll start with one single design approach, and then adapt that. For now, it’s usually the desktop – I start there. When I get that design the way I want it, then I figure out how that changes to accommodate other sizes. Whether or not it’s useful to plan for specific sizes, some people using media queries have their breakpoints at popular device widths, usually 480px, and so on. For now, I think that starting with one size makes sense, so long as you’re using a flexible approach that isn’t based specifically on pixels, though the visual design itself might be based on pixels.

When it comes to code, however, I do the mobile-first thing. I don’t want the mobile user to have to load all kinds of code that they’re never going to use.

Time to test

BN: How do you test the designs or early prototypes?

RW: That’s something I’m ashamed to say I don’t do. I really need to work with a team to properly test that. When I’m redesigning somebody’s small site, unless they have infrastructure in place to deal with testing, it doesn’t really get tested – beyond my showing it around to a handful of people.

BN: Which can be complete testing – you don’t need to be in a soundproof room with eye-tracking software.

RW: That was one of the most valuable things I learned from Steve Krug2: that you don’t need a million-dollar testing lab to do proper testing. At the same time, I feel that some things don’t get quite the testing that they deserve, so that’s something I need to do better.

Understanding clients, understanding designers

BN: This book is about the expectations gap between the process of making and the process of commissioning. Can you think of a few things that you wish people commissioning web projects would be more aware of? And then maybe things that you, as a maker, wish you thought of earlier in the process?

RW: The best projects are the ones where both sides, the commissioner and the producer, have an 80-percenter mentality. Where whatever team is making this thing has a well-rounded knowledge of the whole process from both sides, and the same is true on the other commissioning side. For example, at Happy Cog, when we worked on the Maryland Institute College of Art website, the guy who hired us on the MICA side, Kevin Hoffman (who then went on to work for Happy Cog3), knew exactly the sort of thing he was going for. So his decision to go with Happy Cog was a very educated one. He used Adaptive Path to do user experience studies and so forth. Whatever success there was in that project had to do with a really good understanding on both sides of what it needed to be.

Getting that kind of understanding can be hard as hell. In Design Observer a few years, Michael Bierut said, “Not everything is design. But design is about everything.” To properly design for something, you have to know all about design, but you also have to know about the thing you’re designing for. And that onus isn’t necessarily on the other side, the side of the person who’s commissioning the project. They need to know intensively about their thing, and so do you. But they’re putting it on you to use your design expertise.

BN: Sounds like we all need to be experts in everything?

RW: In a perfect world. but that never happens.

BN: If you had a client who wasn’t a Kevin Hoffman, and you could hand that person a book, manual or checklist and say, “Read this stuff to get a glimpse into what this process will look like”, what are a couple of things that would be in it?

RW: I’m going to point to Happy Cog again. We worked really hard to explain things right from the pitch. We would go into depth about our process and why it was the way it was, right down to explaining what web standards are and why they are important. We did our best at the outset of the project to say, “Here’s how it’s all going to break down. Here are the milestones. Here is the schedule. This is going to have to be flexible because there’s always a dance, an exploration. But here it all is.” Then at the outset of each specific phase, we would come back with more depth of information. We would say, “We’re going to present these designs. You’re going to have the opportunity to give your feedback. We’re going to revise them.” There was as much information as possible given about what was going on there. Without getting into too much jargon or getting too nerdy, we gave them the vital information they needed.

BN: What kind of information would you like to get from the client?

RW: What’s key to get are things like, “Here’s what we’re trying to accomplish.” and “Here’s why this is important.” We’d do our best to structure our questions to get the best answers that we could in the beginning of every phase. It’s all a question of structuring those communications properly. You can have some boilerplate stuff, but it’s not always about smashing things into a mould – it’s about having a flexible mould. Not treating every project in exactly the same way, but instead trying to get at its idiosyncrasies and specific challenges.

I believe in avoiding templated approaches, but there’s one example that deviates from that, at least with Happy Cog. Instead of giving an ordinary response to an RFP, they would submit a project planner that did a good job of asking the right questions, things like, “What are you trying to do?”; “Why are you trying to do it?”; “Who are you trying to do it for?” That’s the definition of boilerplate, right? But it worked.

So, I guess the key is finding that balance between relying on a standard structure or adapting a structure that makes sense for each specific project. How hard is it to strike that balance? Short answer: it’s fucking hard.


Footnotes

  1. At Harmonix, maker of the popular “Rock Band” video game. ↩︎
  2. Steve Krug is the author of the popular book about web usability, Don’t Make Me Think! ↩︎
  3. Kevin Hoffmann is now working in the Philadelphia area as a freelance information architect, writer, speaker and facilitator. ↩︎