Chris Farnum – Wireframing Strategies

The notion that “wireframes are dead” has been coming up every so often over the past few years. In truth, wireframes are still a valuable way for teams to communicate. Building up scenarios through state changes helps to both show and define a user’s journey through your design.

Chris Farnum employs wireframing strategies in his work at ProQuest. In his virtual seminar, Choosing the Right Wireframe Strategy for Your Project, Chris explains what wireframes actually are and what they’re used for. The audience had a ton of great questions for Chris during the live seminar. He couldn’t get to all of them then, so he’s back to answer some of those questions in this podcast.

• Should a design team all use one tool or is it better that each person uses their preferred tool?
• How do you determine the appropriate level of detail for your wireframe?
• What if a client demands high fidelity but you know there are issues that need to be resolved in a low fidelity version first?
• What is the best online low-fi wireframing tool?
• How do you wireframe for responsive interfaces?
• How can you avoid doing wireframes for every breakpoint in a responsive design?
• What is the recommendation for sketching interactions?

Recorded: February, 2014
[ Subscribe to our podcast via  ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

---

Adam Churchill: Hello everyone. Welcome to another edition of The SpoolCast. Recently, Chris Farnum joined us to present his virtual seminar, “Choosing the Right Wireframe Strategy for Your Project.” Chris’s seminar, along with over 120 others, is now part of UIE’s all you can learn library of all things UX.

Wireframes come in all sorts of shapes, sizes, fidelities. Knowing how much effort to invest in making them can be challenging. In this seminar Chris explains that wireframes are an artifact that drives progress, regardless of fidelity, for everyone working on the project. Chris showed techniques and strategies to uncover the right amount of communication for any design team.

Hey Chris. Welcome back.

Chris Farnum: Thanks Adam.

Adam: For those that weren’t with us for your awesome seminar, can you tell us a little bit about it?

Chris: Sure. I will preface this by saying I have had a long love/hate relationship with wireframes, but there’s a lot of love, too. I’ve heard people talk about the death of wireframes, but I’ve been hearing that for many years now. I think that the reality is that many user experience professionals find wireframes a valuable way to communicate.

In my seminar, what I did was I talked a lot about the process of creating them, and I started out by explaining what they are and what they aren’t and talking about the different types and varieties of wireframes and about all the different tools that we have for creating them. I’ve used four of them in the last 12 to 14 months, so I focused my examples on those, and those include Visio, Adobe Illustrator, Balsamiq, and Axure.

One of the main things about this presentation that I did was that I think it’s best to have a good strategy for creating wireframes. I cover three main areas that you want to address no matter what tool you’re using. I’m trying to be tool agnostic, in a way, even though I’m presenting a lot of examples from these tools.

I talked about the concept of page types as something you’ll need when you’re starting out planning your project. Then I went on to a complex topic about showing state changes and complex user scenarios, and I talk about how you can leverage the features in your drawing tool of choice to tackle this challenge, and to work in the concept of layers, which are a feature of tools, and also page components.

In the next section of my talk, one of the pitfalls of user experience design that I’ve noticed is that it’s easy to get into the rut of loving our tools and our deliverables a little bit too much. The point in this section is learning what it means to draw just enough.

Toward the tail end of the seminar, I get into the discussion and return to this point about people proclaiming the death of wireframes. We take on that question a little bit, about their alleged demise, and also some other questions.

I think that, overall, whether you’re a junior user experience designer or a veteran, there’s something here that’ll be of interest to you. If you’re just getting to know the tools and are trying to select one, then maybe this seminar contains some things that you’ll want to know or maybe you’ll learn some techniques. If you’re a veteran, you should probably pay attention to some of the grander themes I’m trying to point out along the way as I show all these examples and stitch them together into these three key strategies.

Adam: Very good. You mentioned tools. Obviously, there were a ton of questions from our audience about tools, and in particular, this one from PayPal. They’re hoping you can talk a bit about, in a large team, you’ve got a lot of people and play with varying levels of experience. Would you recommend that each designer use their preferred tool, something that they’re best with or most comfortable with, or do you really think that the team as a whole should coordinate with some sort of a singular resource?

Chris: OK. I will say that life is good and life is easy if you’re all on the same tool and you can all agree that it’s the tool of choice for the organization. There’s a lot of ways that you gain efficiency that way. I’ll also say that it’s just not always possible. Sometimes it’s a problem of platforms. You might have one office in your organization that’s very Mac-centric and another one that’s very PC-centric. You might have people with differing levels of skill, some people who prefer a high fidelity visual design tool like Adobe Illustrator, and others who don’t have that background and need something that makes it quick and simple and usable in order to communicate ideas.

What I would say is that if you have a team of multiple user experience designers, at least two, working on the same project, it’s really best if you can get them to use the same tool, so that they can share things like stencils and widgets, so that they can edit each other’s documents and pick up for each other. Say, if someone has a sick day and that person has to deliver something, it’s really great to be able to step in and share files and edit them quickly.

Yes, there are a lot of efficiencies to be gained. I would say that if you’ve got multiple people working on the same thing at the same time, you’d better be sharing the same tool.

There are maybe some reasons why it’s also good to experiment with multiple tools. Again, you might have people of varying skill levels who are comfortable with communicating in one medium or another, and you want to play to their strengths. Another is that it’s always good to be investigating new tools and not be stuck on the one that you currently have. I find it really interesting to learn and explore new tools, and I would hate to prevent other people from doing that, too.

As to the question of what tools work best for large teams, I find that there are a lot of ways to slice that. Now, tools like Axure and iRise have some built-in collaboration features. Axure actually even has a way of checking in and checking out files so that you’re not overwriting each other.

With other tools that you have — say you already have Ruzenin as part of your corporate infrastructure already — then maybe you don’t need features like that, and you can work with tools, like OmniGraffle and Visio, where you’re creating your own repositories. Since those things are not part of the tool, you need to choose some strategies where you have a common place where you’re saving files, a common place where you’re sharing stencils, and make it easy to collaborate with each other using a host of other solutions that you have. Maybe it’s Dropbox or Google Docs. Maybe it’s your company Intranet.

There are also some other interesting ways that you can collaborate and get input from other people with even tools like Balsamiq, which include plug-ins for Atlassian tools like Confluence and JIRA. Balsamiq is a tool that’s nice and lightweight, of course, but it invites people to collaborate. Because it’s easy to get started with, it also allows these sorts of plug-ins so that lots of people can get their hands on the tool and it’s not just limited to a few people.

Adam: John wanted to know if you could speak a bit about how you determine the appropriate level of detail for your team.

Chris: This is something that, in the virtual seminar, I touched on all the way throughout, especially in the first half. My advice there is it depends. To quote a friend, Keith Instone, it depends a lot on your audience. Sometimes you have a client, for example, who requires a lot of detail to visualize things. Sometimes you’re working with a stakeholder or a client or teammates who can live with a lot of ambiguity and who can live with things that are low-fi, in which case it might not be worth the effort it would take to polish things up to a high degree of fidelity for everything you do.

Another thing that impacts how much detail is needed is, do you need to write a spec or a quick user story? Are you working with engineers, for example, who need to consume documentation, and those engineers are part of a very close-knit agile team? They might not need as much description. However, if you’re working with a large, distributed group, possibly with people you haven’t even met, who may be working in all kinds of different geographic locations, you may find that you need to go to a little bit of extra length in order to describe something the right way.

In some cases, you might be handing over a fairly quick sketch, everybody understands what the design guidelines are if it’s a mature project, and so you don’t need to do too much.

Another case that you might want to consider is that if you’re doing new product development and you’re designing a site or an application for the first time, you might need to go to some extra lengths of detail in order to build something from the ground up, because it doesn’t fit into an existing framework yet and there might be a lot of decisions yet to be made. It might pay to be more specific in cases like that.

In other projects, you might be refining something that is already part of the system. Maybe you’re modifying an existing page, and so your level of documentation might consist of a screen shot and overlaying some drawings on top of that that are sort of sketchy.

There’s a whole spectrum of fidelity, and the reason I say it depends is that there are a lot of factors that you want to think about. That is what should determine the level of fidelity and complexity and detail that you put into a wireframe is all those factors of what’s going to make your project successful. You’re going to know that by examining your own context and making some smart decisions about that.

I would say, when you can, err on the side of a little less fidelity, and do more iterations.

Adam: Chris, Denise wanted to know, what if the client demands high fidelity when you know that there are issues that need to be resolved first with some sort of a low fidelity format?

Chris: I’ve been in that exact situation, working with an agency with marketing clients, and there were some projects where it just did not make sense to show wireframes to the client/stakeholder. What I would do in cases like that is work with an interdisciplinary team of smart people who would give me lots of great feedback and collaborate on wireframes, and do several internal iterations, and then maybe the visual designer in the group would need to execute a couple of design directions or a quick comp in order to do a more formal presentation.

However, getting client feedback is really invaluable, as we know. Getting stakeholder feedback is really invaluable. I would say that another strategy that you could try, in order to get that collaboration with a client, might be to ask a stakeholder to delegate to someone in their organization who maybe has more of the time and the patience to give you that wireframe feedback.

Often, if you’re dealing with a very busy marketing manager for a client, they might not have time to sit and understand all of the things that you put in a wireframe, because it’s not necessarily obvious what’s going on to someone who’s not used to looking at that kind of deliverable. Perhaps they could delegate to a subject matter expert, who could give you that feedback in the iteration before you then present back to the stakeholder.

Adam: Rob wanted to know what your favorite low-fi online wireframing tool is.

Chris: [laughs] I’m not sure if it’s exactly online because it is an install, but Balsamiq is one of my favorite tools for low fidelity wireframing and prototyping. It’s one of the ones I’ve had the most experience with. There are a whole host of new tools coming out that allow you to do wireframes within your Web browser window rather than doing an installed application. One of these that I have my eye on is UXPin, and I believe that also allows you to do some of that Balsamiq-style magic of making things look sketchy.

I think my favorite so far is Balsamiq, but that’s an area where I’m willing to explore some other tools and try out some things.

Adam: A couple of questions came in from folks that are working on responsive designs. Ally wants to know if you can recommend approaches to wireframing for responsive interfaces.

Chris: I’ve had some experience, although I feel like I’m getting started with responsive wireframing. What I did was, in the past few months, I’ve been using Axure 7 beta, and that is a very interesting tool. What it forces you to do is set up your breakpoints first, and it makes you decide, right away, whether you are going to start with your mobile drawing as being the parent drawing, the main drawing, or the desktop view.

You could also probably start with tablet, too, but the point is that you have to make one of your breakpoints the king. I think that’s probably a great thing to do, no matter what tool you’re using. Even if you’re just sketching on paper, you need to know which one of the drawings, which one of the breakpoints, you should do first.

In my work so far, I’ve chosen to start with mobile as the main breakpoint, and then I draw some objects, I look at them in the next breakpoint up and then in the next breakpoint up, and I adjust them. What’s neat about this tool, Axure 7 beta, is that there is inheritance across the breakpoints. Some properties, like say the text of an object, stay the same, but you can change the dimensions or change the color. What happens is that when you start with the main breakpoint, say you draw a box, you go to the next breakpoint, wider, and the color is maintained. You can choose to change it, you can choose to change the size, and then those properties will be maintained in the next breakpoint down the line.

You have to be fairly disciplined when you’re doing this and very intentional about how you create objects on the page. Sometimes you discover things in the desktop view that mean that you need to go back and refine the original breakpoint. That’s totally possible, and it’s totally what you should do. Things do get a little complex, though, as you go. It takes some the discipline of wireframe components to a whole new level when you do it in responsive.

Adam: Michael’s looking for you to say a bit more about that. Concerned a little bit about time and cost, he said, regardless of the tool you use, how do you avoid doing wireframes for every single breakpoint of a responsive project?

Chris: Since I’m not a visual designer myself, and because of exactly this problem that he points out of needing enough time to get through the project and not have to control every single size and view, I think it’s useful to choose key breakpoints for your project. I recently was working on a project where what I did was, for my parent breakpoint, I chose phone portrait view. Then, for the next breakpoint up, the most key one that was going to influence my design, I chose tablet portrait. Then, for the next breakpoint, I chose desktop, which tends to be in more of a landscape mode.

You still have to think about phone landscape and tablet landscape along the way, but those were things that I intentionally chose to work out when we got to comps and HTML, because there was only so much prediction I would be able to do and only so much time I could spend doing the wireframes. Once you start maintaining these different views, you do put a lot of work into making sure that they’re right and making sure that they work, especially if you’re doing a prototype.

With those three views, I was able to describe at least the 80 percent that I needed to describe in order to let the visual designer and the front end coders do what they needed to do, and also to allow them to give me some input on how things should adjust for those other midterm breakpoints.

Adam: Esri wants to know what your recommendation is for sketching interactions.

Chris: Interactivity, as I cover in the seminar, how you sketch that interactivity and communicate it depends a lot on your tool. If you’re using something like Visio or OmniGraffle, it’s a little bit harder than it is with something like Axure to do state changes that turn into a prototype. What you can do instead is employ an open-canvas approach to your drawings. You might draw part of the screen, then use an arrow and call-outs and maybe a little mini flowchart, if you will, to show what happens to a section of the page as it changes states. It’s almost like you’re drawing a cartoon or a storyboard of the process.

Folks like Kevin Cheng have been talking for years about how you can employ that kind of cartoon approach and sketching approach to expressing a complex interaction, and I definitely invite you to check out those methods as well. What you won’t get out of that is something that you can turn into a prototype. What you might get out of it that would be really good would be a good sketch that you can show other teammates, who may then be able to execute a prototype or a design based on it.

Adam: Well, that’s great, Chris. Thanks for making some more time for us.

Chris: Great. I really appreciate getting to talk to you more about this, Adam. I think about wireframes a lot, and it’s good to get it off my own chest.

Adam: To our audience, thanks for listening and for your support of the UIE virtual seminar program. Goodbye for now.

via:http://www.uie.com/brainsparks/2014/03/04/chris-farnum-wireframing-strategies/