Adam Churchill: Welcome to another episode of the SpoolCast. This is Adam Churchill. Today I'm talking with Dan Rubin, who did one of our most popular virtual seminars, " Visual Design Essentials for Non-Designers."

Dan is one of the Web's rising stars, responsible for many great website designs. He is a highly accomplished user-interface designer and usability consultant with over 10 years of experience as a leader in the fields of Web standards and usability.

One of the many things we love about him is that he's a great teacher. You'll hear today he has a fun, easy way for anyone to learn the nuts and bolts of visual design. Dan did a great workshop for us in last year's User-Interface 14 Conference in Boston. We knew that a portion of that would make for a great webinar and asked Dan to be a part of our virtual seminar program.

How are you, Dan? I understand you're on the London side of the Atlantic this week.

Dan Rubin: I am indeed. And I'm well, Adam. Thanks. How are you?
Adam: Very good, thank you. Can you give us a quick summary of the virtual seminar that you did for us?
Dan: Sure thing. At it's core, it's about all the aspects of visual design that don't actually require any artistic ability whatsoever. Too often people who could do a great design limit themselves or restrict their involvement because they feel like visual design is the realm of artistic, creative people. And there's a big separation between being artistic and being creative. Creative problem solving is ultimately all that visual design is.

So by understanding some of the basic rules, the visual and typographical and mathematical rules that you can work with and tools that you can work with, you can actually be responsible for creating fantastic visual design without having to have any artistic ability.

We discussed rules about typography including basic, common mistakes in web typography that we can easily avoid using margins and padding to create systems and patterns within the design that result in the balanced-feeling design. Everything from easily creating color palettes to overcoming the challenges of the decision making process by making using tools such as grids to help eliminate arbitrary decisions.

Adam: Well, the presentation was fantastic. And it was clear that once you got our audience thinking about their own experience with visual design, you and I just couldn't keep up with the questions that started to roll in. There were too many. We picked some great questions from the ones that remained and I would like you to tackle some of them today for us.
Dan: Sounds good.
Adam: Sherrie makes a comment that she's looking for your thoughts on: "Isn't good looking design somewhat subjective? One person might think your design is great and therefore easy to use. While another person might hate that design and assume just the opposite."
Dan: Sherrie makes a good point. And I think her question is based on a very common misunderstanding about what exactly design is. Design is not just the visuals and the aesthetic aspect of making something look pretty or attractive, because while there are some established rules and just psychological principles of what makes something attractive, to most people it is a very subjective thing when it comes down to it. You might like a different color palette than I do in a design. Or to one person a lot of visual flourishes might be appealing while to someone else it's distracting.

But those aren't the things we're really talking about. Those are more of the artistic layer of visual design. Picture it in a couple of different layers. Design in its core is about the visual aspects that support the functionality in a given thing. If we're talking about physical products in the real world or virtual products such as web apps and services the design is what communicates the functionality to the user.

When we talk about interaction design, that's a more detailed side of that, beyond just the communication, the actual interaction, the give and take. What people will click on and how that behaves.

When we're working at a lower level, below the behavior, what we actually need to do is provide a foundation for that functionality or for the content. A framework of sorts that allows the user to easily interact with and understand whatever's being communicated. So at its core level, the principles that we were talking about in the virtual seminar are more about how to make something easily communicate its intention.

When we're talking primarily about good typographical rules and creating a balanced visual hierarchy, those things are not subjective. Those just are. You can guarantee that people will react a certain way to these things. And we're not actually looking for an emotional connection where we might be with color and the more artistic layer if you will.

That's the nice thing about design at its core level is that it's not really subjective. It's just a matter of good balanced decision making and not cluttering things, not overcrowding. A lot of the time people mistake good, basic core design principles for just common sense. Because once you see them applied properly they just do make sense. You can't imagine them being done any other way.

Adam: David wants to know if you have any strong opinions on fixed width content areas. The example he uses is when you constrain your content to a certain width regardless of the actual browser window width.

Dan: I do. How much time do we have? [laughs] The fixed versus fluid versus flexible versus liquid. Depending on who you speak to you can have all sorts of terminology for the non-fixed styles. This has been major conversation for years and I think it will continue to be a major issue on the web.

I try to stay out of is one better than the other, because I think it's very contextual, just like deciding which browsers you're going to support or which devices you're going to support. Obviously we all want to support the most we possibly can, but at some point you have to look at your audience and say, "Who is the majority of our user base? And who are going to put the most time into supporting? And what do they need?"

Sometimes a flexible, non-fixed design is going to be the right way to go, and other times a fixed design might be the right way to go, the best way to go. Or just it might not matter.

So when we then talk about what the actual target widths should be, again, to a certain extent that comes down to your audience. If you're tracking your visitor stats and you see that the majority of your visitors are still on 800x600 pixel screens, well then that might either lead you to a flexible or fluid or liquid design or just lead you to a fixed design that is small enough to fit on that screen resolution.

If you're not dealing with an established user base, meaning you're starting something from scratch, you don't really know, other than the general stats that you can find of the majority of web users, which is kind of very, very generic as far as statistics go.

There's a reason why I suppose everyone for the last few years has been focusing on a measurement of 960 pixels for the good target width. It's been popularized by things like 960.GS and various other grid systems.

I think Cameron Moll was the first person I saw who wrote about it, and it's just easily divisible into columns and gutters. The math is easy with 960. That is actually is something more like, I think, 980ish as a maximum width without causing horizontal scroll bars on a 1024x768 screen.

Now, these are all based on averages and those averages try to take into account the browser Chrome, the interface elements of the window, for instance, on Firefox, Internet Explorer, and Safari, and all these different browser versions because they all provide slightly different widths at the edge of the browser window.

Once we start talking about pushing beyond that average, I think that's still a good average. We see the devices like the iPad coming out that also have 1024x768 screens, it just kind of happens to work, and I think it's still a very good current average if you're doing fixed pixel designs.

But that's not to say there's no reason to push beyond that, or even look at horizontal scrolling instead of vertical scrolling. You design to an average for a reason, it's because for the most part, most of us want to reach the broadest audience possible. There's nothing wrong with that at all, but I'd like to encourage people to try and push the envelope whenever they can.

For instance, there is a design I'm working on for a personal project that, just to see how it works and how people react to it, I'm working on designing to double the 960 target. Instead of focusing on a lot of vertical scrolling, I'm going to try and encourage users to scroll horizontally, and you'll get the space equivalent to two horizontal pages, if you will, if it were designed at a 960 fixed width.

I don't know how it'll work. It's proving to lead to some interesting problems to solve as a designer in trying to do something like this. And it might flop or it might lead me to some other discoveries that I can then use in a client's project down the road. So again, it ultimately comes down to your audience, the project itself, the requirements of that project's content or functionality, and then just making the best decision based on all of that input.

Adam: Very interesting. We talked in the virtual seminar a bit about design critique and Rose wanted to know, in a critique setting, how do you help people base their comments in facts rather than their opinions?
Dan: I think what you want are people's opinions. You want people asking questions in a design critique and questions are going to be based on opinions. Not everyone is going to have every single fact and bit of research that's available to them while they're sitting in design critique.

The goal is to get those questions framed properly. That's kind of tough, because what you need to do is train everyone who's going to participate in design critique to ask the right kinds of questions. It's very similar to asking the right questions as a test facilitator for usability tests.

There's a big difference between the type of question that's too leading and will tell the user what they should click on, or what they should be trying to accomplish, versus a question that requires the user to think and give you their answer.

So, it's the same kind of difference in style of question, and it can be tough to get everyone on a team asking those kind of questions. I think what you need to do is to sit down before a design critique. Get your team discussing the right kinds of questions to ask, and the right way to ask questions. You don't want to ask any questions in a way that will put whoever is running the critique on the defensive.

For instance, if you're doing the critique internally, and you're critiquing someone's design decision, the question to ask is not one that puts them on the defensive and makes them defend their choice. That's not really productive.

So, for instance, asking them "Well, why didn't you do it this way?" is very argumentative and doesn't really promote the kind of explorative conversation that will get you to potentially a better result, or to just a level of understanding about why something was done in this particular way.

Instead of asking them "Well, why didn't you do it this way?" or "Well isn't that stupid?" or anything like that, the question to ask is "What led you to that decision?" or "What was the thinking behind this end result?" It's a subtle change but it's one that encourages conversation rather than discouraging it.

Adam:You offered up some tricks to add visual depth and specifically got talking about Photoshop and some other tools that you recommend. The folks at AIR Worldwide ask, "What about for non-designers?" What tools can they employ to add visual depth?
Dan: Well, the fact is that, if that we're talking about creating bitmapped visuals, which whether that's photos or type that's set in something like Photoshop or Fireworks, anything that's not created in the CSS itself, or even in the tool like Flash, or a visual that's video related, if we're not talking about that and we're talking about bitmaps, Photoshop is typically where everyone starts because it's been around the longest and it's the big boy in the game, as it were.

But it's not the only player. I know of tons of designers who love Fireworks and I've used it a lot before, as well, and I love it. There are also a lot of up-and-comers like Pixelmator and Opacity and Acorn, and just more and more and more shareware apps that are really kind of wonderful full-fledged visual editors that have all sorts of tools that, perhaps, Photoshop and the Fireworks don't have while sharing a lot of the same tools and conventions.

The point being, that if you're going to create something to add visual interest in the design and you're not creating it purely out of CSS or some other technology that the browser can render on it's own, you need to use one of those apps.

I think being scared of using them or thinking about tools like Photoshop as only tools for real designers is a big mistake. As a matter of fact, you can talk with a lot of web designers who use Photoshop and will tell you that's it's barely even a good tool for web designers.

Born out of the need for photo editing software, which is where it all started out, and every tool that exists in Photoshop, with the exception of a few that have been added in recent years, are all meant to aid photographers and photographic retouchers. It can do a whole ton more than just that, and that's why a lot of people use it. It's a great way to work with pixels.

So that and all these other apps are there for you to use. Those are the best tools around and what I would encourage you to do is play with them. Download the demos of all of these, especially some of those other ones I've mentioned, and we'll include some links to each of those packages.

Some of the new players in that arena are much more simple and don't have the glut of options available that something like Photoshop does, which can be very, very intimidating to someone who's new to visual design in that way, to pixel design. They're a great way to kind of start playing around with, creating these little extra visual touches.

That said, if the idea of creating pixel graphics of any sort doesn't appeal to you, of course, you can also use tools like Illustrator, especially Illustrator CS5 I think now has even more tools for pixel designers, for web designers, whether it's from exporting a pixel snap or a pixel grid view, you can even work in vector if you want which Fireworks does, too.

But if any of that stuff doesn't appeal to you, I encourage you to look into what you can actually do with CSS, especially CSS3, where we can now start playing with gradients that are generated by the browser and specified in the CSS. Granted, the browser support isn't great yet, but it's coming. Even IE9 is purported to support CSS gradients. We'll see how that goes.

We've got gradients, we've got transitions, we've got RGBA, which allows you to specify an RGB color in your CSS and then add alpha transparencies to it. So you can do all sorts of creative things with borders and backgrounds, just by using a couple of tricks that we have now in CSS3.

The ultimate lesson is just to play. You won't know what you can do or how you can do it unless you try. What I encourage you to do is to find side projects. If they're personal projects, it's great to have a personal site or a blog or something that you can actually use, without anyone hovering over you or telling you what you can or can't do, to play around with some of these tools and experiment about what you can do in CSS, what you can do in Photoshop or Fireworks, and that way you'll learn to be more comfortable with the tools that you have available to you.

Adam: So let's talk color. When your design is dominated by one specific color, how do you suggest incorporating new color relationships?
Dan:[laughs] Well, the first question to ask is, do you need new color relationships? We only spent a little bit of time in the virtual seminar talking about color because it's such a vast subject, and, of course, it is very, very subjective. When it comes to color as a non-artistic designer, again, you want to go to the rules that you can rely on to not lead you astray.

And one of the rules with color, if you don't know how to leverage color, the best thing to do is to not use a lot of it. And there's nothing wrong with not using a lot of it. Limiting your color palette is something that the best designers know to do.

It's really, really difficult to use a lot of colors in any design. Not only will it start looking just like a rainbow; usually, it'll only look like a rainbow if you're lucky enough to design it so the colors line up like that. What will happen more often is that you'll just have too much going on at one time. And that's just as bad as having too much information.

If your information density on a given page is too high, it becomes confusing. If there are too many colors on a given page, it's going to be just too loud and confusing. If your design is dominated by one specific color and you want to break out, for instance, from that one-color or maybe a two-color palette, the best thing to do is to look at other tints and shades of that particular color.

For instance, if you have a design that's primarily a white background and you've got a lot of blue on it, you could use lots of different lighter and darker blues to add more visual interest. And the plus of that is that for the most part darker colors will stand out more, especially on the lighter background, on a light field.

Those dark colors will seem closer to the viewer, and the light colors will recede further away. So just by using tints and shades of that single color that dominates your design, you have a ton of flexibility because of the contrast that's created just by making the color lighter or darker.

I encourage you to do that before trying to introduce different hues from the spectrum, because that just over-complicates. And unless you're introducing a hue for a particular reason, chances are you're just going to make things busier than they need to be.

Another plus, while we're on the topic of limiting color palettes, of sticking to one or two colors and not getting more complicated than that is that it allows you to use other colors as specific highlights or call-outs, which can be very, very useful depending on the context.

For instance, red is almost universally a negative color. And we see it all the time on good designs, where some sort of call-out is set in red, where the rest of the design, red doesn't appear. Obviously, you can't necessarily do that if red is your dominant color, but being able to use colors like red for something that's bad, for alerts, green for something that's good, especially in Western culture, these are very well-ingrained laws of using color, if you will, and we can use those to our advantage if we keep the overall color scheme simple. The more complicated the colors involved in an interface get, the harder it becomes to use color as a highlight.

Adam: One of the things about your seminar that still amazes me is how much we actually squeezed into the 90-minute session. What I think was really great for our audience is that there were a lot of those "When do I use this?" type of moments. We talked about, for instance, the all-caps situation. But there's one that we didn't talk about that the folks at Penn State University were hoping that you would share your thoughts on: serif versus sans-serif type fonts. When do you decide when to use which?
Dan: Much like color, typography is a very, very broad topic. And to a certain extent, it can be subjective the same way that color can be, although it's not quite as purely emotional as color can be. But there are a lot of instances where a certain typeface is more appropriate than another.

And without getting too far into that broad conversation, just looking at sans versus serif, on the web it's a little bit of a different conversation, ignoring, for the sake of this discussion, new tools like Typekit and Fonts.com and all these web font embedding, because that broadens the conversation, and I think we need to see how things go for a little bit longer and see how the browsers handle these new choices and how designers handle these new choices.

But if we're just dealing with web fonts, a lot of the web fonts that are available to us, that core group that's available across multiple operating systems and platforms, are meant to look good on screen. They're meant to be very legible. They're meant to be easy to read. Which kind of is a different situation than we've had traditionally in print, where, for the most part, if you want something that's more legible in print, you'll use a serif typeface.

When set properly, serif in print is easier to read than sans. The serifs, the little bits at the top and the bottom of most letters if you look carefully at them, without getting technical, when a word is set, it makes the shape of the word flow better than when that same word at the same size in the same environment would be set in a sans serif, which doesn't have those elements that connect the letters to each other. On the web, that isn't so much of an issue. We lose the details in a serif that in print make it superior in many ways to sans serif for reading. It kind of levels the playing field.

So what I'd say is it comes down more to a very, very kind of subconscious level of feeling. Sans serif tends to be more clinical, clean, very mathematical feeling, in most cases. And a serif type tends to be more natural, perhaps feel a little older, depending on your design, and can be, maybe, easier to read in some cases, especially when we're looking at typefaces like Georgia. And even Times New Roman can be very, very legible when set properly.

Back on the sans-serif side, we have fonts like Verdana, which as a typeface, if it gets large, it's kind of considered to be quite ugly by a lot of people. But it's been designed specifically for screen. It wasn't a conversion from an earlier print typeface like some others are, and its legibility is almost legendary at this point.

But that speaks to another aspect. Are you selecting a typeface based on its legibility for, for instance, body type? Or are you selecting it for headlines, where you're more interested in using a larger size, perhaps, and more interested in what a typeface communicates versus how legible it is in a series of paragraphs?

You might be able to tell, as you're listening to this explanation, that there is no particular definitive answer on which is better in any given situation. This is where it comes down a little bit, I think, to the need to understand what you're working with in order to make more informed decisions.

If you don't understand type, and the rules of type, stay away from things like TypeKit and CSS Font Embedding, because you're opening yourself up to a whole wide range of decisions that you're not equipped to handle. If you want to go that route, learn more about typography first, and then you can make informed decisions.

The same with color. If you're not familiar with the rules of using color, don't put yourself in a position to have to figure that out without that knowledge. Stick to the basics.

So the basics in fonts on the web are the core type selections of serif and sans. Most of those that are cross-platform, those accepted Helvetica, Arial, Verdana, Tahoma, Trebuchet -- which you don't see much anymore -- Georgia and Times New Roman. These things are proven typefaces, and you pretty much can't go wrong when picking them. I would say that you would even be OK looking at those core typefaces, and just deciding which particular typeface feels better for your particular design, and you're probably going to be alright with it.

Adam: So a recurring theme here, Dan, is that a lot of this is subjective. The challenge becomes making good informed decisions for your design. What about discussing some of those elements of the design with your clients, for example color?

Carolyn makes this comment, that she's heard that you never discuss those elements of the design with your client. You focus on the business goals, you focus on the pains or challenges that you're trying to solve or resolve with the design. What are your thoughts there? How do you approach those discussions with your clients, either before the design process has started, or once it's under way?

Dan: I very much feel that when designing for a client -- rather than designing for yourself, or creating something for yourself, or something that you're offering to customers -- when there's actually that client relationship or someone above you, a manager, someone who has sign off that isn't you, your job as a designer is to read between the lines. We're constantly reading between the lines as designers, acting as interpreters of what the client is actually asking for.

There's a barrier in design language and understanding, once we get outside of the realm of designers who train designers even. There are a lot of people who are capable of producing really, really good designs who can't communicate verbally what they're actually doing, and what the motivation is and what the justification is. We can't really expect clients to ask us exactly what they want us to do. It's our job to listen to what a client is asking us to do and to determine what they're likes and dislikes are.

If they say these five imaginary things over here are their business goals, and what they want their app or their site to do, based on those business goals, it's our job to look at those actual business goals. Which we have to assume the client knows their business better than we do, so we can look at their stated business goals, and say, "OK. These we can treat as facts in this context." Then we look at what they've asked us to do, based on those goals. It's our job to interpret the connections between them.

Often I'll have initial discussions with clients, and a lot of the initial written questions and requests, or even conversations that we have, and chats that we have about the pending project and the scope, a lot of them will start out being about what colors they like, here is some other sites we like, and what things they like about those sites.

They all end up being very visual things, and very specific things. "We love the navigation on this site, and we would love to have a mega menu, and have all these drop downs on our site navigation." That's actually a design decision. Maybe their site won't need drop downs. Maybe the fact that they think they need drop downs, is a sign that they perceive themselves to have a lot of content, that needs to be represented.

They can't imagine how that would be represented without something like drop downs. It then becomes my job to change the conversation around to what makes them like that. Much like I was saying earlier, about asking the right questions in a design critique.

When you're talking with clients, you want to get out of them information that's useful to you, once you actually go to solve their problems. So if they tell you something that they really like, and they frame it in a form of a solution, it's your job to then continue the conversation, until you can find out what the problem actually is that led them to thinking that the solution they told you would be the right one. Whether that's a color or typeface or a layout.

If a client asks for a three-column layout, they're not qualified to tell you whether a three-column layout is better than a four-column, or a two-column, or any columns. It's your job to decide that as a designer. It's also your job to find out why they think the need one, and sometimes it might just be personal preference on their part, and in that case you just have to know that if a client really wants a three-column site, and if you decide that a two-column would be better.

Then that's one of the conversations that you're going to have to have with them, down the road when you present this two-column site to them, knowing that in their mind they want a three-column one. So you'll have to justify and convince them otherwise.

When it comes to things like color for instance, which color and type but especially color, isn't ruled by us, as we said. Color is very subjective and ties into emotions. So when you're dealing with clients about something that's very emotional, you can actually ask them what colors they like.

But it's much more useful to show them things that represent what you've figured out during the course of the initial conversations with them about what their goals are, what they want, and what they're trying to do with this site or this app, whatever this project is.

I love using pictures, and that's one of the reasons why, in the virtual seminar, we showed -- without any artistic knowledge -- how to get color palettes out of a photograph. This is really, really useful, because photos are a great way to gauge emotional response. You can show a client a series of pictures that you've gathered together, something very similar to the mood walls that people put together when they're brainstorming on a project or a design.

You can show a client images that you think, based on your conversations, represent the things they're trying to accomplish with this project. Based on which ones they prefer, versus the ones they dislike, that gives you a whole lot of emotional information that you can then use in the design. In a lot of cases, it'll tell you the color preferences, light or dark, even if it's just generic.

If the client picks photos that have a whole lot more bright, punchy colors, then you kind of know that's the direction you need to go, and you can use those images to source your color palette. On the other hand, if they choose photos that have more muted colors or a lot of shadows, or going even further a ton of contrast versus a low contrast image, this tells you a lot about what you can do visually with the design to appeal to that client, without ever having to get into the discussion about the particulars.

That's what you want to avoid. You don't want to try and get your client's opinion on a design decision. You want to get out of the client everything that informs your design decision.

Adam: Well, Dan, once again I've given you a time slot, and you've somehow jammed it full with all sorts of great insight. Nice work. Thank you for joining us today.
Dan: Thank you, sir. It was a pleasure.