Full Transcript

Adam Churchill: Welcome everyone to another edition of the SpoolCast. Recently Stephen Hay joined us to present his virtual seminar, "Responsive Web Design Workflow." Stephen's seminar, along with over 120 others that teach the tools and techniques you need to create great design, is now part of the UI User Experience Training Library, something we're calling UIE's All You Can Learn.

In this seminar, Stephen talks about how "Responsive Design" challenges us to rethink our roles, and he shares his practical 10-step approach to improving your responsive Web design workflow. Take aways included going from text content to wire frames, how to decide on break points, creating browser mock-ups, and style guidelines.

So, Stephen was kind enough to join us. Thanks for making some time for us, and welcome back.

Stephen Hay: Thank you.

Adam: For those who weren't with us for your seminar, can you give us an overview of what you talked about?

Stephen: Sure. What I talked about during the seminar was basically an overview of the content of my book, "Responsive Design Workflow." In short, it's a content-based approach to designing which is also focused on presenting the design when it's done in an actual browser or several browsers on different devices.

We're moving away from this idea of static images to present designs, and we're moving toward this fluid presentation of design mock-ups and also letting progressive enhancement have a big role in creating the designs.

We're starting with content, and actually molding that content into the design mock-up, so it's a different way of looking at design.

Adam: There were lots of great questions from our audience, so let's get to some of those. The team at FTI wanted to know how you represent graphic elements like images when you're designing in text?

Stephen: OK, one of the steps in my workflow is something that, Bryan Rieger, a really talented mobile designer calls designing in text.

What that basically is, is thinking about if plain HTML without CSS was the only way to communicate the sting, how would I do that? In a way it's like thinking in terms of, "Oh, we're documented," or something of that nature where you have this linear thing, and the structure of the text helps you determine what are headings, what are paragraphs, what's most important, so just basic HTML.

Writing HTML is a pain for a lot of people, so what I tend to do is use something called markdown or some other plain text markup language which can be converted with software to HTML which makes writing a bit easier for the people who are going to deliver the content that they're using for this design.

Just playing with that linear thing without any style, just structure and content, is what I call designing in text. I tend not use any graphical elements at that point, so literally what I'll do if there are images or even for app interfaces, you can design in text.

You have text in practically every interface, and if you have buttons, then what I would literally do is put straight brackets and make a note there, "a button, this is a button." So straight brackets or curly brackets, button, and then the text that would be in that button, just to know that it will be there.

You can put notes to yourself as a designer in this process, but you'll want to distract yourself with actual images, because you'll be doing what we've always been doing and that's thinking visually first instead of thinking about the content first.

I'm just say write little variables in there, little placeholders, saying that "an image will show up here or where it seems logical within the content flow."

Adam: There were a handful of questions about this sort of markdown phase of your process. Meghan wanted to know how you translate the content into semantic markup especially considering the new HTML5 element's section article mean like those which aren't actually in the vocabulary of markdown?

Stephen: Right. Markdown is actually a front end to HTML, so you can just use plain HTML within the markdown. The main markdown tool that I use is called Pandoc. That's P-A-N-D-O-C.

Pandoc is a converter for a lot of different formats. It goes from a bunch of formats to even more formats. Pandoc has an extension which does support HTML Five, and I use that quite a lot actually, because I tend to use a lot of the newer HTML Five elements.

Pandoc with HTML Five extension will do that for you, and it's a perfect thing when I have. I always ask for a representative concept just to play around and start up the design. That's a change for a lot of clients, because they're used to putting content toward the end of their whole process.

You make a pretty picture, and then the client will fill in the content, or the copywriters will fill in the content. That's not what we want. We want the content first, or something that really, really is close to what the content will be first, since content is the reason this thing is coming to be in the first place.

To ask these content people to deliver things in HTML, you'll get strange looks if you do that. A good thing to do is just say, "Let me take 10 minutes, and we'll talk about this plain-text markup called Markdown," or any other plain-text mark-up language will do. You could literally teach anyone the basics of Markdown in about five minutes.

I've never really had content people who objected to doing that instead of something like Microsoft Word. Actually, I believe Pandoc can even convert from Microsoft Word, so they'd prefer to work in there, they can. But the content people are usually so happy that there's a designer that's placing priority on content, that they're happy to accommodate my wishes, as well. That's how I'd deal with Markdown. It's actually very simple.

Adam: Stephen, Matt wanted to know about the application that you're using in that design and text part of the process.

Stephen: Markdown is the plain-text markup language that I use for the content. I'm converting that to HTML by way of this tool called Pandoc. Pandoc is this really, really handy document converter. It doesn't only handle Markdown, but you can convert to and from many different formats. Because of the HTML5 support in Pandoc, and a lot of other little, nice things that it has, it's just something that I prefer to use.

It's pretty easy. I get content from the client or a content manager, a content strategist, or copywriter, and usually I can get them to deliver this in Markdown, because it's not hard to learn. Then I just use Pandoc to convert it to HTML.

It's pretty easy to use something like Pandoc and just do a one-off conversion to HTML. But what I'm usually doing later on down the line, when we get beyond the designing and text phase, and I'm actually working on the design itself, I have little pieces of Markdown, little Markdown files, for different portions of the website.

I have usually one file, which is a really big Markdown file split up into sections. All these sections are components of the website. You might have a news block, a latest products block, a log-in block. All these little components that you would use throughout the site, I have these in Markdown. Oftentimes, they're a combination of pure markdown and pure HTML, mixed together, which Markdown allows for, so that's fine.

The software I use to generate the actual web pages that I'm using as a presentation for this design, it pulls all these components together in the way that I specify. I actually have files that specify what I want in a particular design mock-up. These are variables that point to little pieces of Markdown that are in my project-file folder structure. It just pulls them together and makes a page for me.

I've come to call these things "declarative mock-ups." My friend Phil Hawksworth, when I did a presentation one time. That's a good name for them. Declarative mock-ups, you have a document where you just declare what you want in it. The software pulls this all together for you, and then you have CSS that makes it look the way it's supposed to look.

Of course, to get to that point, it takes some time. But that's pretty much how I use Markdown. In the beginning, with designing in text, it's just a simple conversion to HTML, just to get an idea of the structure of the content. Later on, I actually split that up into little pieces that get pulled together in various ways to create a whole array of design markups, really.

Adam: Stephen, our friends at Sabre were hoping you could comment on the use of lorem ipsum. Is it being used well in any application at this point?

Stephen: Lorem ipsum gets a bad rap. Karen McGrane wrote a fantastic article a few years ago called, "In Defense of lorem ipsum," I think it was, that's on her blog. That was a great article, because everyone's down on lorem ipsum. You have to have the actual concept. I prefer to have actual concept. But you don't always have it at that moment. The reality of it is that it's just not always possible.

Lorem ipsum has its place, but it's traditionally been used by designers who use it to fill in space, really. They're not totally aware of the type of content that the client would like to present there.

I mean type of content, very, very specifically. Like, will this be a paragraph or will this be a numbered list? Will it be several paragraphs with headlines or just one big paragraph? These are things that you have to know. You have to know what the shape of that content is.

If you're just guessing and using lorem ipsum as a filler, it becomes what we like to call Greek text in the layout, which is basically just lines showing you where text is going to be. But lorem ipsum can mean much more than that if you know what the shape of the content is.

If you do know that this is going to be a paragraph where we'll always have a list of bullet points talking about the product features and we'll always have a form, if you have buttons that the client hasn't decided what actual wording is going to be used in the buttons, then you can use something like lorem ipsum.

Lorem ipsum is a really useful when you know the shape of the content, but you don't know the actual content. I would say, don't be down on lorem ipsum all the time.

Place holder images have the same principle. Once you know what type of image you're going to using, then you can just put something in there, even if it's just a gray box, because you know that that just represents something else. When it actually represents an equivalent in real content, then lorem ipsum is very, very useful and allows you to move quicker and you don't have to wait for the actual content.

Adam: Another question came in regarding the mark down phase and sort of specifically, when you're taking content and giving it some shape. Raimon wants to know, do you plan out how to display the content? Do you need accordions or tabs? Do you ever put it in an illustration?

Stephen: That's a good question. I don't. I don't do that. When I'm working at that point, which is still looking at content, I'm not worried about how I'm going to display it yet. It might run through my mind and you'll get ideas. I think it's a good point to maybe jot down those ideas for later on.

But there's a point later on where I start thinking about what things will look like. I think part of the problem with a lot of web design and app design today, or web app design, is that people are following the pretty popular model of designing from the interface in, so you're designing the interface first and then you're moving toward the content.

But there's so many ways to solve certain content problems. I think that the fact that you have accordions will lead you to perhaps use an accordion, because you have that available to you, when that might not be the best solution.

That's why I tend to be down on a lot of these prototyping frameworks. Because they have a lot of UI patterns that are popular and they're easy to implement in your prototype or your design. It's just all too tempting. It's just like the tools that you have in popular design packages. They do tend to give you this framework, this coat hanger to hang your process on.

I understand that, I think that a lot of people do that because it's quick and easy. But I'm critical of it because I think, secretly, no one will admit it, but it's a crutch. It's just a way of making things easier. It becomes a bag of tricks.

It's hard to be creative and come up with a solution. Where an accordion might seem to be the obvious solution, it takes more creativity, it takes a more talented designer to come up with something that really fits the content.

I force myself to not think about the content. At that point, I advise my clients to do the same with their designer. Yeah, I would say think about that later.

Adam: Aimeelyn wants to know about the first thing you typically present to a client.

Stephen: Well, the whole workflow, my workflow, in any case, is based on avoiding what Mark Boulton has called the big reveal, where you go off and you do your design work and you come back three or four weeks later and you do the big reveal, and the client sees this thing for the first time. There are just too many things that the client can notice, and too many factors that might influence any decision about the design.

What I have tried to get away from is just a few deliverables. I've tried to move toward having deliverables constantly. They're not even really deliverables. It's more like the client is seeing the results of every single step of the process.

You don't really present it in the sense of, here you go, client, I'm presenting this to you right now. Because to them it seems like something that they have to judge. You're putting something in front of a jury, as opposed to taking the client by the hand and leading the through your process and having discussions with them about the things that you're doing, so that you're always on the right track.

I think the very first thing that I show to clients is the very first step in the workflow, which is the content inventory. It's not even a deliverable of mine, it's something that we all come up with. It could be that a content strategist has already made a content inventory and we just sit down and talk about that. That's pretty much the first deliverable.

It turned out that I had 10 steps in my workflow and that means at least 10 things that the client is seeing at any given time. Usually, we look at things a couple of times. Whereas normally you would have, maybe 3 or 4 deliverables, we're talking about maybe 20, 20 to 30 moments that we get together and look at something that is going on in the design process.

Adam: There were some examples that you shared in the presentation that Marci commented on. She said that some of the examples you shared seemed to have fairly little interaction. She wanted to know what happens to the workflow that's got a bit more complexity.

Stephen: Right, that's a good question. I've been, I won't say criticized, but people have told me that a lot of my examples, not necessarily in the book, but with anything that I teach, they tend to be simple.

The reason is that while a lot of people get it, there are plenty that don't. I believe in simple examples to explain one simple thing. Thus the little interaction in the examples that I use.

The only thing that changes when you use more complex interaction is, the process doesn't really change much. The amount of time you spend during the phase when you're dealing with that interaction, that's pretty much the thing that changes. If you are using the workflow to design a web app, which is pretty complex, then the whole workflow itself doesn't necessarily change. It's just the moments that you're discussing interaction with a client or that you're testing it with your interaction designer or sketching it out, thinking of break points for it, etc., that all takes longer.

I think the length of time, the duration, is pretty much the big difference with complexity.

Adam: Do you show the linear design in browser? Or is it a simple screenshot?

Stephen: The linear design, I like to show in the browser. It's just HTML with no style. I think that showing that in the browser is pretty cool, because you could show it on a phone. Then the client starts getting them and questions what this type of content does on a phone. Even though it's not designed yet, visually, they start thinking about what that content does on a small screen. I don't make screenshots of that.

Adam: Niels asks this great question, which ultimately sums up, I think, a big point that you were trying to make in the presentation. It's in regards to Photoshop. He makes a comment that coding design is always slower, especially when you need to make changes, and Photoshop's just easier. What are your thoughts there? If you could share a bit about your thoughts on designers having some coding skills.

Stephen: It's no secret that I think that web designers should learn some code. More specifically, CSS, as a design tool in addition to the tools they already use. I'm not saying; never use Photoshop, which a lot of people think that I'm saying. But I'm not. I don't feel that Photoshop is the right tool for the job to create design mockups.

You can do it, like I said during the presentation, the company that did the time.com redesign, they had more than 200 Photoshop documents to do a responsive redesign of time.com. If you're OK with messing around with 200 Photoshop documents, more power to you. I don't think it's very effective. It's much more effective to make one change in one CSS file and have that change propagate to all the design mockups that I've made. The way to do that is to learn some CSS.

CSS at its basic level is not hard. I get comments like this from many people, comments that range from, doing things in code is not creative. What I think we often forget is a lot of the designers who say this to me are designers who grew up with Photoshop.

When I started doing print design many years ago, we didn't use Photoshop. That was something we had to learn. We were saying the same types of things that people are now saying. "Well, we're designers, as soon as we touch code, then we're not creative anymore." I can understand that, because that's the same thing that we did, crying about creativity when Photoshop came around and we started using that instead of colored markers to draw out our designs.

We were afraid of something new. We were afraid of Photoshop. The designers who have grown up with Photoshop are afraid that they might have to learn some code.

I would say, don't be afraid of learning a little bit of code. It's mostly CSS that we're talking about and the basics of CSS are not very hard. It can get very, very involved, and developers are not always happy with CSS. They'll sometimes mention how hard it is. But I would advise designers not to be scared, and just start trying it out. It's very simple to start adding things like color to plain HTML and start playing around with things.

Photoshop's a fine tool for sketching and brainstorming, trying things out. It's just not the right tool for presenting mockups to clients. It's not the right tool to create web design mockups. It just has absolutely no reflection of the reality of the web at all. Web design is one of the few design disciplines where you have this opportunity to get your design in the actual medium without someone in between.

I could not actually go to a printer and have a print design printed just to show it to the client and ask them if they thought it was something that they wanted me to go ahead and make. An architect doesn't have the luxury of having the building built before it's built. That's why architects do scale models. The scale models, they have to be pretty much exactly like the end result will be, just at scale. Fashion designers work with their materials and they play around with it.

You don't have to go into a code editor and open your browser and start designing that way. But it's pretty useful to know some CSS. I mean, if you're an interaction designer, it can help you immensely to know exactly what types of things, transitions, animations or what have you, are possible in CSS.

You could learn it second hand by always sitting down with a developer. But it's useful to add that as a tool to the toolbox. I think that designers should learn some CSS.

The younger designers that are coming out now, a lot of them are the hybrid designer/developer types. I think if you only work in Photoshop and you consider yourself a web designer, in like 5 to 10 years, I don't even think those types of designers will really be doing a whole lot of work. I know I'm out on a limb here, but I think that most web designers will be able to at least do some code, and with good reason.

I'm not saying give up Photoshop. I don't believe that a creative designer should hang their creativity on a single tool. I think you have many tools at your disposal and Photoshop is simply one of them. Saying that you're not using Photoshop for a certain aspect of your design process, I think it's pretty extreme to say that there's no creativity left on the process simply because you don't have your crutch.

Maybe it's challenging. Maybe that's why people are afraid of it. But there's absolutely nothing to be afraid of. Just try it out slowly, just slowly pick up little tiny bits of CSS and see what you can play around with. Talk to developers and learn a bit more. I mean, learning Photoshop took years, in most cases. It's a complex program and so is CSS, in a sense. If you learn Photoshop, you can learn CSS.

Adam: Stephen, some in our audience are going to want to know more about this responsive design workflow. You wrote this fantastic book by the same name, "Responsive Design Workflow." Tell us a bit about that.

Stephen: Well, about the book itself? It was born out of some presentations that I did, actually, several years ago. The publisher happened to be at one of the presentations and thought it would be interesting to expand upon it in book form.

The reason I even started presenting about it was, it's all born out of frustration. I had some projects that I was working on that weren't responsive, actually, the first time I started thinking about a new workflow. But I was struggling with the whole Photoshop comp thing and dealing with client changes to designs within that process. They were so time-consuming. There were many instances, I mean, many, many instances where changing one line of CSS would have done the trick and instead, I'm spending two days messing around with these Photoshop documents.

That was the beginning. Then once I started doing responsive design, the problems just compounded. Not only related to Photoshop, but just related to the entire process. It gave me an excuse to put in my pet philosophy of content as the basis for design and to crystallize that into a form that I could use for my own work, but also to help other designers or clients who have in house design teams. Which is really the work that I'm doing a lot of today as opposed to just sitting around, myself, designing, which I do less and less of lately.

But this process, I started using, I started trying it out on actual projects that I was doing. Some big projects, very small projects, as well. Just testing it out, and refining and refining on it. I'm still refining today. I could probably write a revision of the book today where several things are slightly different.

But the book was basically documentation of my process at that time in the hopes that people who had similar frustrations would at least be able to pick up a few ideas that they think might be useful when encountering the same type of stuff that I was encountering in these projects.

Adam: Very good, Stephen. Thanks for joining us again.

Stephen: Thank you.

Adam: To our audience, thanks for listening in and for your support of the UIE Virtual Seminar program.