Full Transcript

Adam Churchill: Hello, everyone. Welcome to another edition of the SpoolCast.

Earlier this year, Nathan Curtis of EightShapes presented a virtual seminar called "Sketching for Understanding." We create these special EightShapes virtual seminars in cooperation with the folks from EightShapes.

This seminar, along with over 100 others that teach the tools and techniques you need to create great design, is now part of the UIE User Experience Training Library.

Now in this seminar, Nathan explains where sketching fits and explores some tools and techniques of the trade. He shows us how to incorporate sketching in the design processes with both large teams and remote teams.

Hey, Nathan. Thanks for joining us again.

Nathan Curtis: It's great to be here. Thanks, Adam.

Adam: For those that weren't with us that day for your seminar, can you give us an overview of what you covered?

Nathan: We talked for about 90 minutes, including some questions and answers. We really covered three big topics. The first thing I tried to do was talk a lot about the basics of sketching, really.

You pick up a Sharpie. You've got some tools and you draw things, whether they're squares and triangles and arrows and text or, as we really got through in most of that seminar, really drawing screens to visualize our ideas in software design.

In the second section, we really dug into not just the process of where sketching fits, which is really anywhere within your process, but also how do you share them and how do you get feedback? Really getting together to understand the problem collectively, which you can use sketching for, but then drawing the solution, presenting your ideas, getting critical feedback so that you can make your ideas better.

Then the latter part of the seminar, we talked a lot about how we share our sketches with others, whether they're remotely using a camera so they can see us sketching in real time or actually bringing together large groups of folks.

What's the process when you bring a team to sketch for a half hour or an hour or half a day or a full day? How do you create scenarios and create good teams and organize the sketches when you're done.

We covered a lot of ground but it was all about how you pick up a Sharpie and draw your ideas and get feedback on them.

Adam: Say a bit more about that. I know a big trick for a lot of design teams is you usually get some people in there that aren't comfortable with this craft. How do they get better at it and how do they get that feedback? How does that happen?

Nathan: Like any kind of skill, you get better with repetition and practice. There's a lot of different formats that sketching can come into play. A lot of different points in the process.

Sometimes, you're sketching alone and then you share those ideas by walking over to your neighbor's cube or you fire up a GoToMeeting and show a picture of the sketch that you drew and you get feedback on the ideas.

And then, there's other formats. When you're working with a large group and everybody's sketching at the same time and you really take turns to get the feedback on your ideas.

But, I recently got asked a question by a colleague of mine that I work with which wasn't how can I get feedback on whether my ideas are good, which is the most important part of sketching, but also how I'm sketching in general.

Oftentimes, the feedback I give them comes down into two different things. The first thing is, "Are you really breaking the boundaries and understanding the breadth and the scope that you're allowed to be creative?"

Because a lot of times we're sketching because we don't have a good idea of what the solution is so we don't want to just draw a basic set of links and maybe a header on top of it and a button on the bottom of it and call it a day. Rethink, perhaps, how the experience works to improve it.

And so, that's really trying to get up and be more creative, get outside their box. And oftentimes sketches don't do that. You can tell that someone's too constrained into how the problem was defined or how the experience used to work to think differently about it.

The other thing I often encourage folks to do is to sketch a little bit more conscientiously. People get so excited about sketching but also might be a little bit nervous about sketching that they try to draw really fast and get their ideas out really quickly.

Instead, it's helpful for them to sketch a little bit more deliberately. And then, as they form that sketch be a little bit more meticulous. Use real words from the experience. Draw some more details around what direction an arrow might be pointing for a drawer that expands and collapses and whether it goes on the left hand side of the header or the right hand side.

Think a little bit more deliberately and perhaps meticulously to produce something that's more refined if you have the time, as opposed to just scribbling a bunch of stuff.

But it depends on your context and what your goals are. Those are the two pieces of feedback I usually get.

Adam: Nathan, do you folks ever use sketching as a method to solve other problems?

Nathan: Oh my goodness, yes. We talked a lot about sketching to solve user interface design problems and how an experience might work as someone interacts with the screen. By and large, that's the lion's share of the sketching we do. But it's no mistake that a big wall of 15 feet by 10 feet in our office space is a big whiteboard wall.

When we start a project, you've got to lead, facilitating the conversation of the group of people, and drawing things like lists of tasks that we want to do, or flowcharts of how the experience works, or concept models of how a team is organized or how an experience is organized, and site maps and other kinds of things.

All those different things are really different ways to graphically represent ideas. The whiteboard wall that we have, drawing with a Sharpie on a piece of paper, all those things are really quick ways to visualize ideas and get feedback on them.

While a lot of our craft comes down to sketching screens, it's certainly not limited to that.

Adam: Do you have a recommendation or tricks maybe to offer up, how to compile and track sketches as a project progresses?

Nathan: Yeah, we've ended up refining how we do that over the last few years as sketching has become such an important part of our process. The artifacts we produce, whether it's wireframes or comps or prototypes or all those different pieces of the design. All those are disposable things on the path to getting the final, perfect production site implemented.

Sketches are no different, and in fact they're looked at as the most disposable thing. They're supposed to be the most transitory -- you sketch something, you share the idea, you throw it away. That's one of the great lightweight things about sketches.

But as sketching becomes a deeper part of our process and oftentimes replaces things like wire framing or comps on the way to a prototype -- sometimes we'll sketch and then we'll go directly to code to render what something looks like -- they become an artifact in and of themselves, both because we need to record the idea so that we can share it with other folks, and sometimes that's taking a picture of it with our phone, using the IPEVO camera to take a picture of it as it sits on a desktop.

More often than that, as we have big teams that come together, we want to take pictures of all those sketches, because you get, say, 20 people together for half a day, that's 10 person-days of work, of ideas that you want to keep. A couple weeks, maybe a couple months later, you want to go back as you're thinking about the scope for a next round or a next sprint, and say, "What were some of those ideas that we sketched before?" You have to have those pictures.

We found that taking the sketches and putting them in a stack on a side table and it just becomes a big pile of trash, that's not really how we do it. Almost always we'll capture those sketches with images, be it our phone camera or IPEVO, like I said. We'll try to label them, put them in folders, and organize them enough so we can retrieve them later. That process literally takes, what, five minutes or so for even a big pile of sketches.

Adam: Have you ever gone sketches straight to design comp, actually skipping the prototyping phase?

Nathan: I almost question the way this question is phrased, because you said go from sketch to comp and skip the prototype, when often, in our process, we're going from sketch to comp and then prototype, because it's a different topic, but part of the impact of sketching and part of the impact of prototyping on our process is making all those different design disciplines more parallel in their work, rather than sequenced.

You have visual designers working on comps at the same time that a UI designer is working on wire frames or even is working on a prototype, and all those things happen together. The nice thing about sketching is that it feeds all of them. Sketching can feed clarifying what a comp needs to depict at a certain responsive size. Sketching can work as a predecessor to a more formal wire frame that you draw in vector format.

Sketching all the time, for us, clarifies what needs to be prototyped, such that we may skip wire frames and skip comps, and if we have an established design language already available to us and perhaps even codified in the baseline CSS we've got, then we'll do a sketch and then we'll prototype it in code. Guess what? That's the only thing you need. What's really in terms of sketching is that input to any of those pieces, depending on the level of fidelity and formality that you need.

Adam: Nathan, what kind of scenarios do you usually start with?

Nathan: It depends. Most often it's designers working together on a project, and so we have a good sense of all the different cases that we need to solve. We don't really use formal use cases in our work. Every once in a while, we'll use stories, but both of those are really inputs to think about how to formulate how the experience works.

Really sketching happens more fluidly in an ad hoc way between two designers collaborating over time, and if we're sitting next to each other you just start talking, you grab the pen, you grab the paper, and you sketch.

The more important time when you need to think about scenarios is when you're facilitating a large group sketching together. We call that a design studio when, say, over a half a day you convene a group of 12 to 20 people. You create teams out of them, and then you've got to sketch across round after round after round where everybody sketches, and then you have these rounds of feedback or presenting your sketches and getting feedback. Everybody gets a turn to present.

You absolutely have to have scenarios for that case. You have to be set up. You have to be prepared. You can't just wing it and say, "Hey, what do you guys think about sketching the home page?"

No, you have to come in and say, "We're going to work on search today. The rest of the home page is pretty much fixed, but we need to work on how the auto complete works, and we're going to work on some best bets and highlighting some specific content," and you really create the different aspects of the design that people need to focus on.

And so, in those rounds of sketching people are still trying to solve the same problem even though the range of sketches you'll get is very divergent. As we prepare for those, that's a week, maybe two weeks, of iterating two times maybe with our clients to validate what the scenarios are.

We pick those to be the most important, most consequential, perhaps part of the core happy path to the experience, and then we'll later perhaps later in the day an exceptional case or something that's more interesting and off the beaten path as people have already been warmed up.

Adam: There were a few questions in from our audience about dealing with the schedules of groups, whether you're working with a client and they're not willing to commit a full day or whatever time you're setting aside for this or whatever number of personnel are involved with this project. You can't just pull them together to do this the right way.

Are there tricks or some experiences that you can share that help here?

Nathan: Yeah, once you get beyond one or two hours you have to be cognizant of the fact that many people aren't going to be able to give you their whole day or even a half day. What we found is we think about a session like that as oftentimes we've got those rounds of sketching that are based on scenarios like I was explaining before, but you really have the bookends of the day as well.

At the beginning of the day, you're setting the tone for what the projects about, oftentimes, how sketching works, how the day's going to work, and you really get everybody on the same page for the process of how we conduct those design studios. That's a nice piece for everybody to be at.

Just as much as at the end, the end of the day, or the end of the half-day or what have you, you have a summation period where everybody gets together. You've talked about the last round of sketches, but then you sort of bubble it up, and you say, "What thing really stood out to each of you?"

You can go around the entire group and give everybody a chance to talk, to articulate what was most important to them, what they noticed the most, what the major theme is that they sensed about the day.

It's interesting the things you'll hear, both at the beginning of the day as you're trying to gain a consensus idea of how things work, and at the end of the day when you're trying to gauge the individual reactions of different people, what you get out of that, because actually you can extract from those comments what matters to people, both about the project at the beginning of the day and about the ideas that they saw at the end of the day.

It might not be that you nailed it with any sketch that you did - any sketch might not be perfect but you might realize that everybody's saying the same thing in a slightly different way and when you as a design team take that input, go back to the drawing board after the studio's done, then you can really refine your idea to encapsulate those principles or ideas that they had.

It's important to get the folks, I would say, in the bookends of the day, and that if you already know, also, that there are key participants -- some of the key stakeholders, maybe the lead developer, maybe that teammate developer that you know you're going to work with a lot -- you maybe orient the scenarios based on when you think they're going to be there or not and have them there for the most consequential stuff.

Adam: Nathan, this might be a little bit off topic but anytime we have you or Dan Brown in the studio our folks are anxious to get inside the walls at EightShapes and no more about how you're doing things. There's a question that came in, "How does visual design fit into the design process for your teams?"

Nathan: EightShapes, in particular, we started with Dan and I, and we're both user-experience designers, interested in user interface design, information architecture, interaction design, et cetera, commonly the discipline people distinguish from visual design. But when it comes to how we approach a project and how we've since grown, we really consider visual design as a core part of the experience as well.

It's really a peer of how the UI design works, and often, we'll create the plan of how our activities will be conducted for a design process to make those parallel. At the beginning of the process, we'll try to involve all of the disciplines and activities like the design studio that I'm talking about, and requirements gathering, and brainstorming even as an internal group. We're all involved. We all have a voice.

It might be that the most important consequential thing we do after that is establish the visual design direction based on how sketches are looking. Maybe we throw together quick wireframes. But as the UI design team, as the interaction designers, whatever you want to call them, as those folks are doing things like more detailed wireframes, or maybe starting to build out the prototype and so on, in parallel the visual design team is establishing the visual direction and we're actually working side by side.

We try to communicate as much as we can such that pretty soon thereafter if we can get the design direction established, we'll start blending both of those inputs together into something like a prototype. The prototype really isn't owned by the UI designer. It's owned by the whole team, and we sit together and Chromes and Spector later in a process.

The prototype might be more fluent in the code, but the visual designer's sitting right next to them, shoulder to shoulder, saying, "Can you nudge this thing that way? Can you make the space between those two elements less? Can we darken that opacity for that gradient?" or what have you. We're exploring all those things together.

It can be uncomfortable for folks at times because you don't have the, "I'm going to put on the headphones. I'm going to sit there, and I'm going to do my own work for like a day, and then I'm going to get feedback on it." Sometimes, it provokes more collaboration that can be unsettling for people that don't do it as much, but once you start to develop those relationships you move a lot quicker, and it helps build trust between the two teams as well.

Adam: Can you say more about the design studio idea? There were some questions about how it could be adapted for smaller groups of designers or stakeholders. Isn't the design studio geared towards bringing those people together?

Nathan: The concept of a design studio is a formal way to set up a two or more hour session to involve many participants. That's why you focus a lot on teams. That's why you focus a lot on getting the scenarios right before people show up. That's why you have rounds where people sketch as a team, and then they aggregate their ideas and share them with other teams.

And so, that whole structure, that whole framework for doing sketching, yes, it's intended for larger audiences. When we learned about sketching studios and sketching in general, a couple people that we learned a lot from were Will Evans, and, in particular, Todd Zaki Warfel. He was kind enough to sit with us and talk us through how it all worked so we could incorporate it into our practice.

What we didn't expect was whenever you have two people sketching together -- two or more people -- the core principles of how the interactions work apply, because whether you've got a team of five people sketching in a design studio setting as a team, or you have two people sketching together, or four people sketching together just for a half an hour, we still formulate the problem. It takes maybe 5 or 10 minutes.

Then as a design team of four people, let's say we're on a GoToMeeting and we've all got our IPEVO cameras ready to show what we're sketching.

We formulate the problem for five minutes. We'll sketch for about 12 minutes, and then we each have four minutes. For a couple minutes we present our ideas and then everybody else reacts to those ideas and gives us feedback.

While it's not a full day session with lots of preparation beforehand and lots of people getting their calendar invites all set up, nothing that formal. It's just the way that we share ideas now. It could be a half hour or it could be even 10 minutes. "Hey, can I grab you for 10 minutes?" and do that same define the problem, sketch the ideas, present the ideas, and then get the critical feedback from other people.

That is just now a part of the way we interact with each other.

Adam: How about in an agile environment? When would you typically conduct a design studio?

Nathan: The agile environments that we've worked in need to define a set of scoped items to work on for each of their sprints. And so, it naturally seems to indicate that a good time to sketch together, to work through what those ideas are are at the beginning of sprints, but maybe even more consequentially in that "sprint zero," really the design period that precedes the sprints, if that's how your agile process is set up.

When you talk about design studio, that's when to do it. It's really when you want to explore a lot of different ideas and be able to, if that's the intent, then reconcile all those ideas into something agreed upon that you're going to work forward with.

And, depending on the maturity of the design language, the maturity of the team, and lots of other factors, maybe that's what you need to go into sprints. Maybe that's the input. But I would also say sketching as a technique can happen at any point. And so, if you've got a sprint, the last designated period of time, let's say a week or two weeks or what have you. It doesn't mean on day 8 of 10 if the developer has a question and they walk over to the designer or they contact him and they say, "Hey, what's going on here?"

You throw together a sketch. It takes three minutes and suddenly they have all the clarity they need. That's saves them a half day's worth of work that might have been a mistake otherwise.

Sketching, as a technique, really fits in anywhere.

Adam: What are your thoughts on using an iPad as a sketching tool?

Nathan: That's an interesting question because, at least at EightShapes, we spend a lot of money on software and certainly the Adobe Creative Suite, everybody has it. It's almost as if the big purchase I have to do otherwise is go to the websites where we buy all our sketching markers and pens and so on. Sharpies and Copic markers for wide grey and all sorts of stuff. I'm buying those materials all the time.

And so, to me, that at least indicates that people continue to use pen and paper to create the sketches most of the time. We each even have another member of our team, Veronica Erb, who does a lot of sketch noting, too. I know that she and many of the other members of the team -- I haven't personally -- have experimented with a lot of the different styluses that you can get for an iPad and even lots of the different apps that you can sketch.

But I haven't sensed it become a part of their workflow as a practicing UI designer. As something that they have replaced paper with using the iPad.

Some of those apps have great ways for you to create a sketch and then share it with other team members or even, I think, create a common place where you save them and then they're just all available to everybody. But we haven't used them a lot in our process. We have generally relied on the IPEVO camera to take pictures of them live and share them as the sketches are happening and then just use pen and paper.

Adam: Very cool. Thanks for taking some time out of your busy schedule to come back to this topic of sketching in your design process. It was great to hear from you again.

Nathan: I love talking about it. Thanks for having me.

Adam: For those listening in, thanks for your time and listening and for your support of the virtual seminar program. Goodbye for now.