(Visual) design influences interaction

I’ve never hidden my opinion of those design workflows that involve interaction designers toiling over intricate, interactive wireframes as a primary deliverable and the inevitable hand-off to the “visual” designer who proceeds to “color by numbers” on the wireframe. To be clear, I find these workflows are ineffective.

I’m not implying that all interaction designers work this way, nor that all design firms work this way. But it is absolutely a common practice, especially in larger, waterfall-style organizations and teams.

The assembly line workflow is a death punch to effective interaction. The reason this is so: you simply can’t separate visual design from interaction design. The visual designer (boy, do I dislike that term) likely has a background in graphic design, a legitimate and non-trivial field of study. Graphic designers are trained to solve problems, and a primary goal of the designer is to communicate something. The goal of the interaction designer is to find the most effective ways that people can interact with the thing we’re designing. Interaction designers and visual designers should either have both of these roles combined, or they should work together. A lot.

Many visual designs are built upon the foundation of complex wireframes. Why not the other way around? Arguably, the interaction designer’s insight might be best utilized as part of the visual design process with the most valuable insights occurring on a completed visual design comp, based on real content and in a browser, when the actual thing can be interacted with, as opposed to a black-and-white, hopeful proxy.

The fact is that when an interaction designer creates a wireframe, they’re inevitably making visual design choices. When these wireframes are used as client deliverables, clients can’t “unsee” these decisions. Similarly, visual designers make decisions that can heavily influence interaction, no matter what the interaction designer theorized. So, we’ve got two disciplines, possibly trained differently, making decisions for one another instead of with one another.

The influence of the visual

I’d like to offer a simple illustration on how visual design can influence interaction. Seth Godin wrote a great little post entitled The First Rule of Web Design, which he says is “tell me where to click”. (Regardless of whether this is or should be the first rule of web design, I do take issue with the word “click”. Godin’s later clarification, “What do you want me to do now?” is much more effective.)

Seth illustrated his point with two images. Please go and read his post to understand the context. Both are examples of how visual design can heavily influence how the user interacts with the sites in question, and how either clarity or confusion is created by design choices.

A form with the least important actions styled as buttons, most important as a simple link.
This component is all about the refund, but the link to get it is visually one of the least important items on the page.

If you examine the first image, a screenshot of part of the process to get a refund, the conscious choice to present the most important thing relating to the purpose of this component as a simple link (text), which has to compete with huge (size) green and gray buttons (color). These buttons are placed where one would normally expect to act on the preceding text (placement/layout). These design choices make for stunted interaction. This is either inappropriate design, or someone did a nice job of making it slightly harder to get a refund.

Form with poorly placed next action button
The “Next” button is more important to this form than “Regenerate Token”.

The problem with the second example is not so much related to color as it is to the choices as to what should be a form element and what should not. The word “Next” offers an action to continue the current process, and should at the very least be structurally and visually closer to the input field. In my opinion, “Regenerate Token” could either be a link, or a less competing color and placed where the “Next” button is currently.

In both examples, wireframes could have, but would not have necessarily anticipated or solved the interaction problems created here. Wireframes or not: once we have these things in the browser, it’s time to go and revisit the interaction after visual design has either helped it or hurt it.

Some thoughts on “designing in the browser”

Ever since Andrew Clarke’s presentation The Walls Come Tumbling Down—which is the first time I heard of the term—the idea of “designing in the browser” has increasingly become a point of discussion and debate.

As one of those crazies who doesn’t use an image editor (like Photoshop) to create design comps, I’m often lumped into the design-in-the-browser category. So let’s clear things up a bit with my take on this approach.

You don’t actually design in the browser

Okay, you can design in the browser, meaning you open up a blank HTML file in both a text editor and a browser and have at it. But why would you? Some people really mean this when they speak of designing in the browser. But in my experience, that’s often not what we’re really talking about.

When I speak of designing in the browser, I mean creating browser-based design mockups/comps (I use the terms interchangeably), as opposed to static comps (like the PSDs we’re all used to). So it’s not the design. It’s the visualization of the design—the one you present to stakeholders. It’s not the only deliverable, but it’s the one that’s most important to show in the browser. Before that, I sketch. On paper. Other people I know who “design in the browser” actually use Photoshop. For sketching. But when we say “designing in the browser”, we mean the comp is in the browser.

We sure do like our comfort zones

Creating comps like this puts many designers out of their comfort zones. Many feel they have to learn to code, or “think in HTML and CSS”. Those who know that isn’t true can still feel awkward pairing up with a developer to visualize designs. That said, I think that learning CSS can be a useful addition to a designer’s toolbox. Note that in all my talks and in my book, I’ve only ever stated my opinion that browser-based comps are preferable to Photoshop-based comps. I have never stated that code should replace Photoshop.

That said, I’m increasingly frustrated by the articles, talks and discussions defending Photoshop comps, almost all of them citing Dan Mall’s idea of “deciding in the browser” rather than “designing in the browser”. I do agree with Dan; in fact, designers should already have been “deciding in the browser”, for years, especially when doing static image comps. If you design for the browser, you decide in the browser.

So much effort is being put into stating the case for static image comps, almost as if to justify the current (which is also the past) way of working. “Let me tell you why I want to stay in my comfort zone.” “Let me tell you what you other disciplines need to do for me so that I can continue to stay in my comfort zone and do things the way I’ve always done.”

It would all be fine, if it weren’t complete bullshit. And that is partly due to the flimsy premises of the arguments given.

Flimsy arguments

I don’t mean to pick on any specific article, but I’m compelled to provide an example and this particular article really got to me. Probably because I’m sure the author is skilled and talented, and thus many folks who read the article might swallow the premises whole. But looking at the points made, I’m inclined to disclose a couple of fallacies.

  1. The author states that the desire to increase the speed of design and development is the driving force behind designing in the browser. While speed may be a factor, it’s arguably not the main factor, and certainly not the only one. More important, for example, is bridging the traditional gap between what the client sees in a comp versus the end result.
  2. The implication of the sentence that follows is that web-based comps help speed but reduce the quality of the design work being produced. Tell that to The Guardian.
  3. The author then proceeds to make the case for Photoshop instead of code (albeit with an 80/20 split). Nothing wrong with that, but the author’s personal experience with code yielding “dull” designs does not mean that code yields dull designs. It most likely means that the author tried getting into code too soon, or skipped sketching altogether, or is simply not as comfortable in code. I would agree that might not work out well. But in that case it’s the design process at fault, not the fact that code is used at all.

Code can support the creative process

Fabulous, creative things are being done with code. Just because some of us are more comfortable with graphical tools doesn’t negate that fact. It simply means that we’re less comfortable with code because we don’t know it as well as the tools we’ve been using for years and years. Which is logical, if you haven’t learned to code yet use Photoshop daily. And if you’re in my age range, you’ll remember that we didn’t always use Photoshop to create design comps. We had to get out of our comfort zone and learn it. And learn it we did, eventually.

For every person who tries opening a text editor and typing code from scratch before claiming “FAIL”, there are scores of us who actually sketch before even touching code. And I know designers who don’t code, but team up with developers to create design comps in the browser.

If you prefer using graphical tools, that’s fine. Nothing wrong with it. No one’s attacking you. But don’t say web-based comps are about speed when they’re not, that the process is less creative when your own approach to it is the problem. Photoshop is neutral. Code is neutral. It’s what you choose do with them and how.

I think code is a valuable tool, and I think web-based comps offer a plethora of benefits to the design process, clients, and teams. But again, I said web-based comps offer benefits as compared to Photoshop comps. Not “code is better than Photoshop”. That’s a huge difference. Designers know Photoshop; not all of them know the benefits of code as a design tool. I feel it’s important to talk about that.

Nobody is going to take your copy of Photoshop away from you. So since no one’s attacking, perhaps there’s no real need to defend. With false statements at that. In fact, for every defensive article or talk or tweet against code, I think about how time could have been spent learning some.

Creativity is tool-independent.

Disarming loaded feedback

While I was off sipping Mojitos in a pool bar in Portugal, Laura Kalbag wrote a column for A List Apart about eliciting more effective feedback from clients. She shared her perspective and experience on the subject. Please read that before you read this. Her approach works for her, but that didn’t keep a couple of commenters from declaring that she was wrong.

She’s not wrong. There is no wrong in dealing with clients, unless you say or do something that jeopardizes the relationship or the end result.

Here’s a fact: every client is different. Every contractor is different. And every client/contractor relationship is different. Every unique combination of personality, chemistry, experience and expertise calls for an appropriate approach. And mine might not be Laura’s, and hers might not be yours.

I think that in addition to articles about shaving two bytes off of your JavaScript and demos of cartoon characters made with pure CSS, we should start sharing more of how we deal with clients (if you are fortunate enough—yes, I mean that—to be in that position). That would be a good thing.

Before starting my consultancy, I ran a design and development firm. I’m a schooled graphic designer, but selling was completely new to me and I eventually found myself in the position of having to do it, and with big and sometimes scary clients. While my previous experience pitching designs as a print art director was useful, selling websites (which design presentations are a part of) is not quite the same.

Stop getting defensive

I have a pretty thick skin about critics of my design, as long as they’re not me. I torture myself. But stuff others say, I (usually) handle pretty well. But, boy, do I have questions when they do.

What helps keep me from getting defensive—on good days—is a sort of detachment from the work. I mentally try and cut myself loose from it. Almost as if it’s someone else’s. And then I await the comments and don’t absorb them. I try and imagine that the comment or question is a physical thing. Something I can put on the table and examine. Because I’m going to do a sort of autopsy on this thing. And if I do end up having to implement the client’s will (it does happen), I can do so knowing I’ve done my best to handle the situation well.

There are three main ways I tend to deal with client comments on design work, or any work, for that matter (in no particular order):

  • Defer
  • Drill down
  • Disarm

(Yes, I did spend a minute or two trying to find synonyms for these words that start with a “D”. Have fun, Twitter.)

Defer

If I do happen to be feeling overly emotional or defensive on a particular day, or if I don’t know how to deal with it right at the moment, I’ll just hear the comment or listen to the question and make a note of it.

“Okay. we’ll look into that”, or “Thank you. I’ll discuss that with the team and we’ll get back to you”, are examples of how I might react. This tactic is particularly useful for larger clients in big meetings with lots of stakeholders. Trust me, there’s enough discussion, politics, and psychology going on in those meetings. I’ll regroup with my contact later by phone or in a separate meeting.

Drill down

In many cases (seriously), someone knowledgable on the client side gives useful and informed feedback, and all that needs to be done is to drill down to specifics:

Client: “Given the recent discussions about hamburger icons and our lack of data, I’m concerned about the use of solely the icon.”

Designer: “Are you thinking in terms of an alternative icon, or more in terms of text?”

Client: “I’m not sure. I like the clarity of text but I don’t want it to be boring.”

Designer: “There are ways we can design text so that it stands out visually, and so that customers know that they can click or tap on it. Would it be worth exploring that?”

Client: “Yes, that sounds great! Here’s lots of money.”

Okay, maybe not that last bit.

Disarm

This last one is what I do when I get feedback I can’t do anything useful with. I basically encourage the client to rephrase or reconsider their feedback. I want them to figure out what their problem is and then tell me. Or at least get close to it so that I can do a proper drill-down.

One thing I will not do is waste my time on discussions of taste. I’m only interested in someone else’s proposed solution if they are able to properly articulate the problem.

This is tough, because how you do it depends on your personality and your relationship with your client. If you want to be sarcastic or use some humor, you’d better know how that will pan out for you.

Some clients, if they were to say “make the logo bigger”, I could squint at the page, straining to see the obvious logo like a guy without his reading glasses. “Where—what? You can see that thing? You have great eyes. All I can see is your product.”

They get the point and have a laugh. Then we discuss the real problem.

With other clients, you can still disarm loaded feedback without humor:

Client: “The text is too large.”

Designer: “Okay. Too large compared to what, exactly?”

Or this dangerous one:

Client: “We want a carousel. Users like carousels.”

Designer (delivered sincerely and without any sarcasm): “Oh, I’m sorry. I didn’t realize you had user data.” (implied question)

Client: “We don’t.”

Designer: “Oh. You said, ‘Users like carousels.’ I’m curious which users you were referring to?” (question)

Et cetera. This is a slightly obnoxious example, but you get the point. You also have to be very, very careful. The point is not to jab or insult, but to encourage deeper thinking about the problem and more useful feedback. Disarming is generally asking questions about their feedback. And then questions about their answers. Do not state your knowledge or opinion on any matter at this point. You must latch onto everything the say without giving them anything to argue with.

The key to disarming is to focus on what the person said, and return it to them, as a question, in such a way that they must reconsider and return more refined feedback or information to you. So that you can do your job.

That’s how I tend to deal with feedback, in a very small nutshell. I enjoyed reading Laura’s, and I’d certainly enjoy reading how more people approach client feedback.

Hint, hint.