Mobile is greatly influencing the user experience community. It’s challenging traditional approaches to design, but also bringing with it a host of new opportunities. Being a user experience practitioner in this changing environment is a bit scary. Yet coupling existing skill sets with the constraints of designing in the mobile space makes for an exciting world full of possibility.

The transition from designing for the desktop to designing for mobile can be a daunting one. Rachel Hinman of Nokia had her own experience with this challenge back in 2005 when the mobile world truly was a scary place to live in. Back then, the mobile web was little more than an afterthought. The experience of using the web on a mobile device was painful. With advancing technology and the advent of the iPhone and Android devices, mobile is becoming easier for users. Rachel considers that personal feeling and concreteness to be one of the exciting things about working in the mobile space.

The very nature of mobile offers opportunities that the desktop doesn’t, but also brings with it problems you don’t encounter on the desktop. Rachel thinks that it takes some “unlearning” to position yourself in the mobile context. Embracing the constraints of mobile and taking full advantage of capabilities such as voice and built in cameras are key. This allows you to leave the desktop mindset and design for the context.

Rachel will be presenting a full-day workshop at UX Immersion 2012 in Portland, OR April 23-25. Find out more details about the UX Immersion conference.

As always we want to know what you’re thinking. Share your thoughts in our comments section.

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

Full Transcript.

Jared Spool: Welcome everyone to another episode of the SpoolCast. I’m Jared Spool and I am your host for today.

We have with us Rachel Hinman, who is going to be speaking at our upcoming UX Immersion Conference, which is going to be April 23-25 in Portland, Oregon.

And Rachel is going to be doing a fabulous workshop that will help everyone, who is just getting into mobile design understand exactly what they need to do and how they need to approach the problem of designing great experiences for mobile devices. Rachel comes to us from Nokia and we have her here today.

Hi, Rachel!

Rachel Hinman: Hello!

Jared: Hello! You’ve been working in mobile now for a really long time, right? You were one of the first to really start designing in this space that I knew about.

Rachel: Yeah, I started my career in mobile in 2005. I had just gotten a job at Yahoo and, at the time, Yahoo was really interested in figuring out how to get Internet content on mobile devices. This was way before the iPhone was around or Android phones or Windows Mobile phones, so getting Internet content on a mobile device was a pretty difficult experience, difficult user experience. I was hired to help them figure that out and help them make that a better experience for their users.

Jared: And so back then, it must have been hugely challenging to do this. The browsers weren’t on every phone and the phones that had them, the browsers were really crippled in what they could and couldn’t do, right?

Rachel: There were a lot of sort of pain points for users at that time. There was definitely issues around the browsers and there was also this really big chasm between smartphone users and sort of basic phone users. And there was also sort of, people knew the Internet access was potentially a feature for their phone, but they weren’t even sure if their phone was capable of doing that because that language really wasn’t in people’s sort of mindset at that point.

I think another big problem that we saw, was that data plans was something that was a huge issue for people back then, as well. So even people who did understand and “get it” that they could get Internet content on their phone and were interested in it, then they would get these horrible bills because there really wasn’t a lot of clarity around how much it would cost and what the pricing was, what was driving the pricing. There were a lot of really significant user experience hurdles for folks in those days. My, how times have changed!

Jared: Yeah! Yeah, I remember back then having this little LG flip phone. We had a Verizon business account and they gave us six months free of a data plan, just so we’d get hooked on it.

I remember trying to use it and it felt so impossible because it wasn’t a smartphone. I had to do everything through typing in the letters with the number pad, so if I wanted a “C” I hit the “1″ key three times. Just typing in a website was like this major, major effort.

Rachel: Yeah, I have this great video clip that I remember from one of the research studies that we did where we asked the participant to… She had mentioned how one of the things she had done is that she would look up movies at blockbuster.com to see if a new title was available at the rental store and I asked her, “Could you demonstrate to me how you did it?” It was seriously like a four minute video clip of her typing in on T9, www.blockbuster.com and then, waiting for the page to fully render in the browser. It was a great clip because it really communicated just how something so simple that we take for granted on a PC, is so very challenging in the mobile world.

Jared: So it must’ve been, you know, here you are, hired into Yahoo and you’re tasked with making a great experience in those conditions. That must have been really scary because nobody knew how to do that back then, right?

Rachel: Yeah, I was really terrified, I would say, for the first three to five months of my time there. Because my experience before Yahoo had really been in the web — when I say web, at that time it was more the PC web — and I felt really comfortable in that space. I felt comfortable designing websites that were really for the PC context.

I had gone to graduate school at the Institute of Design and learned about user research and all that stuff, but I really didn’t have a lot of specific knowledge around mobile. In fact, a lot of people at that point didn’t. I think that I had done a project or two in my graduate program that involved mobile devices and I think that is why I got the job. But the first three to give months of that job, I was just really terrified by the fact that I didn’t really know a whole lot about mobile. I really didn’t know how to — I guess I would say — engage with it, if that makes sense.

Jared: Yeah, I mean at that point, it was really a different thing. So it took you a good long time, at that time, to sort of get comfortable. What were some of the things that stand out that were like “Aha!” moments for you back then?

Rachel: Well I think even knowing how to design for a small screen like, what are the design constraints? What are the typical design constraints? What’s the screen size? You know, I think with a website, you have a sense of how browsers work, and how page loads work, and sort of how to create a web page that, you know, it was of the medium of HTML and it would work. You know, it wouldn’t really choke the browser or be really difficult for a user to download or be really difficult to construct and build.

I think I didn’t really know a lot about that stuff and I got really caught up in sort of the technical parts of it. I think that that was probably for me, one of the things that really terrified me the most. Yeah, I would say that was the thing that probably terrified me the most. [laughs]

Jared: As you started to work in it, how did you start to get so you weren’t as scared of it and terrified any more? What sort of happened to get you there?

Rachel: I think, for me, one of the things that really kind of kicked me into it and really got me excited about it was doing user research because I was seeing firsthand how people were experiencing the stuff that was currently being built for mobile. I saw how poor it was. I just realized — here I am — I’m almost paralyzed in terms of my design skills, or being able to sketch out ideas and start to be able to put them together and build them.

And I’m seeing what other people have done and how really horrible it is for other people and I’m like, “I can’t do any worse.”

That was what caused me to just realize that I have these skills. I can empathize with users. I can draw and sketch. The technical skills that I don’t have, there are plenty of people within my group that I can look to, to help me with that. I realized after going out into the world and talking to people and seeing some of the broken experiences that they were having, that it was [inaudible] of me not to just jump in.

I found that to be just really something that made me just get beyond my fear.

Jared: It’s interesting that you said that the things that got you beyond your fear are basically, proven time-tested usability and user research techniques — just you know, sitting and actually watching people, seeing how bad the status quo experience was, realizing that you could sketch out your ideas and put them in front of folks and see if you could incrementally improve that experience over what was out there. I mean, that’s not new. That’s not new to mobile. There’s nothing mobile-specific about those things, right?

Rachel: Right, exactly. I felt like it was also interesting because going out into the world and talking to people, observing them and observing how they were using their mobile devices was something that was surprising that more people in the organization hadn’t already done that. There were some really significant issues that they were trying to solve and they were struggling with, and were trying to find good solutions to, but going out and actually watching people, and sort of understanding how they understood their mobile devices, was not something a lot of people felt comfortable doing.

I think from a user experience perspective, that ability to empathize with the user and observe that and sort of be able to come up with design solutions based on those observations and those insights, is something that like you said, it’s a tried and true, proven skill that sort of applies to a lot of things.

Jared: Let’s fast forward to today. Now, you’re working at Nokia. You’re sort of neck-deep in mobile experiences all the time, right?

Rachel: Yes.

Jared: We have the iPhone has come along and the iPhone 2, and the iPhone 3GS, and now the iPhone 4. We’ve got Android phones, and last I heard, Nokia has some awesome new phones running Windows Mobile 7. And so there’s all sorts of new experiences today. Does all this stuff make it harder or easier, than what you were dealing with way back in 2005, you think, for people who are just getting started?

Rachel: Well, I think it’s a kind of a combination of both. I think it’s easier because I think, you know, mobile’s not this sort of side thing, side interesting thing, it’s really something that’s I think become front and center, both in the user experience world, as well as the business world, technology world and it’s something that people are a lot more aware of.

That’s definitely a big change. I think that awareness and excitement around it — you’re not the mobile team of maybe three or four people kind of cobbling something together that not very many people use — there’s a lot more people now doing pretty sophisticated things with their mobile devices.

There’s a visibility now, and I think, a user group now, just in the general public that’s a lot greater than it was seven years ago.

But I think in some ways there’s kind of a… I don’t want to say that there’s a dark side to that. But I think one of the things that makes that challenging is, there’s a lot of noise. I mean I think that an image that comes to mind is — I use it in my book — was this image of the Oklahoma Land Rush. You know it’s like all of those horses running! There’s a sort of fervor around it. I think that energy can be not always the most productive for people.

I mean, some people work really well in that kind of a space, around that kind of energy, but not everyone does. I think in that some ways that can kind of get folks into trouble.

Jared: Say a little bit more about this “land rush” thing that’s happening.

Rachel: Well, I think people just feel like mobile is really hot right now and it’s just kind of like the Land Rush. They want to figure out their place in it. They want to get their piece of that opportunity. I think people are just sort of rushing in and trying to figure that out.

And I think, you know like I said, the positive side of that is that sort of optimism and sense that anything is possible is there. I guess I try to embrace that positive part of it. Like, “Anything’s possible! Infinity and beyond! Hooray!” It’s a nice thing to be around.

Jared: It is! What’s really fun for me is, I see clients who get really excited about the possibilities of mobile and start to say, “Oh, and we can give them status updates on where things are. We can let them check the progress of their deliveries. We can skip things in the user experience. They don’t have to check in with us anymore. They can now just do it on their phone and go straight to the gate or just take off.” Those things become simpler to imagine because they have so many experiences to compare to.

Whereas back in 2005, I think it was hard to imagine all the things you could do with your phone. It was much more “sci-fi-ish” back then.

Rachel: Yeah, I think that’s one of the things that has been really exciting about the last I would say two to three years of being involved in mobile. Is, I think, like you were saying, with the release of things like the iPhone and the Android phones and touchscreen devices, as well as tablets, I mean I feel like there were a lot of conferences and academics and people in research labs, who were talking about ubiquitous computing, but it’s almost like these devices and tablets have really become an almost gateway drug to what’s possible. Right?

It’s not something that’s this sort of wonky, abstract thing that people can’t relate to any more. The ability to access information from anywhere, from almost any context, it’s really sort of allowing people to experience that firsthand and make that type of experience concrete and more tangible.

And so it’s exciting because it’s no longer this kind of weird, abstract thing that most people can’t relate to, it’s something that is a lot more near and dear to them. They can experience it. They can get glimpses of that future.

Jared: Yeah, I mean if you’d asked me in 2005, what would be some of the neater apps, I wouldn’t have said,”Well, I’ll just point my camera at my W-2 form and Intuit’s tax product will read the form and fill out my income tax 1040 based on what’s right there.” But that’s done now. Then once you realize, “Oh, if we can do it that,” then Walgreen’s realizes that, “OK, well, I could just point the camera at a prescription bottle and make it a refill request.” All of a sudden, all this stuff just happens. It’s like, “Oh, that’s easy.”

So it’s almost like the palette of colors we have to paint with has just gotten hugely bigger.

Rachel: Yeah. That’s a great way to put it. It really is this sort of green field. I think that it’s almost like this golden age now, where these sort of wonky things that we thought would be so impossible, it’s like, “Wow, it’s really not.” It’s not impossible anymore.

Jared: So, given that, and all these cool things are there, there are still some challenges that people today deal with on a regular basis. What are some of the challenges that you’re seeing when you talk to folks who are trying to design for mobile today?

Rachel: Well it’s interesting, because I think a lot of times when I talk to people, a lot of the fears that people have are the same fears that I had when I first started, which was, I got really caught up in the fact that I didn’t have any experience in mobile. I got really caught up in the sort of technical aspects of it that I didn’t completely understand.

I know that those are valid fears. I’ve experienced them myself, but I also have experienced firsthand I can move up and out of that. Because most people, if they’re involved in user experience and have some sort of user-experience projects under their belt, they have developed some skills that will serve them very well in designing mobile stuff, mobile applications, mobile websites and whatnot.

It’s really around sort of recognizing that and having confidence in the skills that you have, and the contribution that that can make to whatever mobile projects you’re working on and for your team. I think that confidence issue is definitely one challenge that I see a lot of people having.

And the technical stuff, I think that that’s becomes a weird thing too, because when people ask, “Oh, should I make a native application, or a web-based application? Should I make a mobile website? Should I make an Android application? Should I make an iPhone application?”

To me, those are important questions to ask, but I think it’s really more of a timing question. I see people asking that question right away, like at the very beginning of their design process. I just feel like that’s not really the right time to be asking that question.

The right time to be asking that question is further along, after you’ve allowed yourself to explore and see what might be possible, and just let yourself explore what could be possible, explore what mobile experiences might make sense for your users, and then make your decisions, your sort of execution decisions, based on those ideas.

Jared: All this technical stuff, it sounds to me like, while it’s really important, what I hear you saying is that a lot of the issues that come up when you’re designing, there’s a way to do it most of the time, and if not, you’ll find it out pretty quick. So don’t worry about it too much. Chances are you have a group of people around you who are going to be able to guide you through the, “Oh, that’s easy” or “Wow, that’s going to be really hard.”

But the things that make a really good experience typically are not things that are technically difficult to do. Is that true?

Rachel: One of the things that I think is really important to remember with mobile is that even a beautifully executed bad idea is still a bad idea. Right? Execution is important, but it’s really around what your idea is.

I think one of the things that’s super exciting about mobile is the fact there’s still so much about it that we don’t know, and we don’t understand. And that’s why I really encourage people to allow themselves to explore that preliminary blue sky idea space, and give themselves a generous amount of time to do that, because there’s really a lot of room in mobile user experience to innovate.

I think it’s important for everyone to allow themselves to just take that time to come up with a bunch of crazy ideas, and really save the execution decision making part of the project for a little bit later in the process. Because who knows who’s going to come up with the next new interesting idea, right?

Jared: Yeah. Some of the coolest stuff in mobile has been really out of folks that you wouldn’t think of as a particularly innovative organization or group. I mean, take the prescription bottle thing from Walgreen’s. I think before that, if you had asked me, “Who are the top technology innovators in the world?” Walgreen’s wouldn’t have come to mind.

Same with the folks over at Bank of America. I think it was Bank of America. Who was it who made it so you can take a picture of your check and deposit it without having to be at an ATM?

Rachel: I think it was B of A, but I think actually, I want to say it may have been something government oriented, because I thought that the first people who were doing that, it was designed for folks in the military.

Jared: Oh, yeah. I think I might have heard that, too. But even so, neither of those organizations you would put at the top end of technology innovation. It’s not like they had some special incubator, or some think tank that was coming up with this stuff. It was just a bunch of guys that, “Hey! What if we took a picture of it? What could we do with that picture?”

So it’s sort of that playfulness that I think really makes mobile stuff really, really interesting.

I’m curious. You spend a lot of time helping people, and you’re writing this book for Rosenfeld Media called “The Mobile Frontier.” What are some of the traps that you see folks running into when they start, that it’s like, “Oh! Dude! You should be reading my book! You should come to my workshop, because you would so not have done that.”

Rachel: I almost think of it more as unlearning. But I think one of the things I see a lot happening with people is that it’s very difficult to recognize and be conscious of the fact that a lot of how we think about computing experiences and technology today is really based on the PC experience and the context of the PC.

So a lot of ideas, and even solutions that people come up with are very much sort of entrenched and tied to that legacy.

And I think it takes some unlearning to recognize that mobile is just a very different context to design for. There’s limitations to that that can be somewhat frustrating for designers, but there’s also a lot to it that’s kind of, like you were saying, taking a photograph of something and using that as a way to trigger an interaction. That’s something that you really don’t see a lot of with the PC.

Voice is another one, another input that has been explored somewhat on the PC, but mobile’s really taking that baton and running with it. I think also just playing around with information, information access in a different context. What does that mean? How do you depict information? How do you convey it in a way that is glanceable, is not annoying, is valuable to a user in a variety of different contexts?

Those are things that become interesting design questions for mobile, that I just don’t think the PC has ever really explored. I think that it’s that unlearning of the PC, and really allowing yourself to kind of cast off that anchor and explore a different way of doing things that really becomes a challenge for people.

Jared: This getting away from the PC. Are there tricks that you’ve been teaching people, to sort of divorce themselves of that thinking?

Rachel: One of the exercises that I tried kind of early on in my career and I was just so surprised at how excited people got as a result of that exercise, was… You know, a lot of times at the beginning of any project, you’ll have a brainstorming exercise. I think there’s a typical scenario for that brainstorming exercise, and that is, your team sits together in a conference room, maybe have a bunch of hash sheets, and you come up and you start brainstorming ideas. That’s the sort of scenario.

I was working on a project, and we were thinking, “Hey, instead of sitting around this conference room, let’s actually get out into the world and start coming up with ideas that way.” And it was actually sort of, we could have termed in “brainstorming in the wild,” but people going out into a variety of different mobile contexts, and using that as sort of fodder and inspiration for their ideas.

And I think what the result of that is is that your ideas can actually have a kind of empathy and sensitivity to some of the contextual issues that you encounter when you’re designing for mobile.

Even some of those challenges just become this sort of inspirational fodder for a kind of clever and interesting way to solve a problem that someone might have, or just think about access to information in a completely different way.

So I think that it’s that idea of getting out of the static context, is one really great way to kind of shake yourself out of, “Wow, I’m not designing for this sort of, I’m sitting at a computer with a keyboard.” Put yourself in a typical user’s environment and try to come up with some ideas.

Jared: Are there other traps that people run into too?

Rachel: I’d say that I’ve really found that prototyping is… I think for any user experience activity has been evangelized as really important to prototype, but I think in mobile, it’s like, three or four times more important to really give yourself the time and the space to prototype your ideas. I think for the PC, it’s really considered a luxury, but I think for mobile, it’s just, it’s essential to really just bust out and really get your ideas on paper, and find a way to really test out your ideas early and often.

Jared: What is it about mobile that sort of forces your hand on the prototyping thing?

Rachel: I always think of the design process you think about it in sort of four phases, like discover. You’re sort of in that big idea space and come up with lots of ideas. Then there’s that define, which is the second phase. It’s where you say, “OK, this is what we’re going to make, this idea.” Then you develop that idea, and you fine tune the design. Then you deliver. That’s sort of the fourth phase. So it’s discover, define, develop, and deliver are the four phases of design process.

I find that the place where things really fall off the rails for a lot of folk when they’re new to mobile is it’s really in that develop phase, where you’ve actually taken a couple of design ideas, or one design idea, and you start to develop it. It’s really because people lack the skills to make really good, educated decisions, because they’re new to the design space.

Something that maybe sounded really good in their head, or maybe like there was an interesting drawing, or a few rough prototypes of it, once you really start to develop it, you start to see some of the flaws. Then it just becomes like a pain parade till the end of the process, because you just really didn’t have a great idea that you could develop and deliver on.

If you start to prototype those ideas at the very first stages of that design process, in the discover and define phase of a design process, I just really prototype the heck out of all of your ideas. I find that it helps you make those decisions better. You’re not just relying on an idea in your head, or a really rough idea that you maybe lightly sketched out, or made a really rough prototype of. It’s like, if you vigorously kind of pursue that idea, and embodying that idea in a prototype, it helps you make better design decisions.

Jared: Well this has been really interesting. I’m really excited to see your workshop at the UX Immersion Conference, and the book, “The Mobile Frontier,” is coming out, and I know you’re going to be doing one of our Next Step Virtual Seminars with us, that we do in conjunction with Rosenfeld Media, that sort of celebrates the book and talk. We’re going to be talking to you a lot.

Rachel: Will be exciting, yeah. It’s going to be a fun spring, that’s for sure. 2012 is going to be a good year.

Jared: It is, it is. And it’s just in time, because I think this mobile thing is finally about to take off.

[laughter]

Rachel: I’d say.

[laughter]

Jared: Yeah. I predict all sorts of people will be using their phones. [laughs]

Rachel: Yeah. I mean, I don’t know, I’ve talked to a lot of people lately, and I’m super excited for the future and what’s happening, because I think there’s just so much possibility, and so much space for innovation and invention. It’s like I said, I’ve been in this industry for seven years, and I’m still excited by the possibilities of it.

I just see a lot of designers who are intrigued by mobile, but I can also sense that sort of hesitation and fear that they have. I hope that people just are able to move beyond that sort of hesitation and fear, and just jump in, because it’s a fun place to be. It’s where the action is.

Jared: Well, at the UX Immersion Conference in Portland in April, you’re going to be helping people get over their fear, with your full day workshop. I think people are going to really love it.

Rachel: Yeah, I do, too. I promise there will be no trust falls.

Jared: No trust falls. OK. Excellent. Well, Rachel, thanks for spending the time with us.

Rachel: My pleasure. Thank you.

Jared: And if you want to see Rachel, you’ll want to come to Portland, to the UX Immersion Conference. Again, that will be April 23-25. You’ll also want to be checking out her book that’s going to be coming out from Rosenfeld Media later this year, called, “The Mobile Frontier.”

That would be an awesome way to get a great introduction into how to design for mobile. I want to thank everybody for listening, and as always, thank you for encouraging our behavior. We’ll see you next time.

Touchscreen devices give you the ability to directly manipulate content. This allows designers to create interfaces where the content itself is the control. This lessens the need for buttons and can reduce the level of complexity within your design. The problem is making the user aware of the availability of gestures in your design. Gestures, especially multi-touch gestures, are powerful control mechanisms but useless if the users aren’t aware of them.

Josh Clark, author of Tapworthy, says that touch interaction should revolutionize your approach to interface design. In his virtual seminar, Buttons Are a Hack: The New Rules of Designing for Touch, Josh offers techniques to make gestures more discoverable without overloading users, and experiences, with endless instruction. We ran out of time for all of the audience’s questions during the seminar, so Josh joins Adam Churchill to tackle those remaining questions.

Here’s an excerpt from the podcast.

“…buttons are an abstraction and I don’t mean that just in the virtual world, I also mean that in the real world. If you look at the history of the button, which is really only about 100 years old with the introduction of electricity, even then buttons were a hack, a workaround.

If you think about a light switch, putting a switch over here to turn on a light over there is not particularly intuitive, right? It’s a workaround because it’s really inconvenient to walk into a dark room with a ladder and climb up to the light bulb to turn the thing on. We’ve used buttons, at times, when we didn’t have the luxury of direct interaction. We had to insert this middle man…”

Tune in to the podcast to hear Josh answer these questions:

• How do you transport hover interactions to touch interfaces?
• Should swiping “back” be used for a back button type of command?
• Is there an advantage to Apple’s one hardware button versus Android’s multiple ones?
• Is there a replacement for radio buttons?
• Should multiple audiences be considered when giving instructions for gestures?
• How should users be able to access hints if they’re needed in the future?
• Is there any way to avoid collisions between operating system gestures and application gestures?
• What is the value of affordances?

As always we want to know what you’re thinking. Share your thoughts in our comments section.

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

Full Transcript.

Adam Churchill: Welcome everyone the SpoolCast. Josh Clark recently joined us for a virtual seminar titled “Button Are a Hack: The New Rules of Designing for Touch”. This seminar on mobile design spoke to the massive evolution in technology that is becoming increasingly tactile. Josh is joining me today to get to some of the questions that we didn’t get to address in the seminar.

Now, if you didn’t get to listen to the particular seminar, like all of our virtual seminars you can get access to the recordings in our UIE user experience training library. It’s presently over 85 recorded seminars from wonderful topic experts just like Josh Clark that will give you the tips and techniques that you need to create great design.

Hey, Josh, welcome back.

Josh Clark: So happy to be here.

Adam: Josh, for the people that weren’t with us for your seminar last week can you just give us an overview?

Josh: Sure, yeah. I was basically talking about touch screen design and the way that touch interfaces require really new thinking about the way that we as designers think about creating our interfaces. For that matter, we as users, the impact that it has on us sometimes in very subtle ways about accessing information in this really direct interaction rather than with this illusion of unmediated interaction with content instead of what we’re used to, which is the desktop GUI that we’ve been using for 30 years with buttons and tabs and menus and so forth.

I guess a broad point that I was trying to make at the outset of the seminar was that direct interaction with content of tapping and stretching and pulling and dragging content and really using content as the interface instead of buttons and controls is really going to revolutionize or should revolutionize the way that we design our interfaces.

And so the title of the talk, “Buttons Are a Hack” is really talking about how buttons are an abstraction and I don’t mean that just in the virtual world, I also mean that in the real world. If you look at the history of the button, which is really only about 100 years old with the introduction of electricity, even then buttons were a hack, a workaround.

If you think about a light switch, putting a switch over here to turn on a light over there is not particularly intuitive, right? I mean it’s something that is a workaround because it’s really inconvenient to walk into a dark room with a ladder and climb up to the light bulb to turn the thing on. We’ve used buttons, at times, when we didn’t have the luxury of direct interaction that we had to insert this middle man. So it’s a workaround, a hack.

An inspired hack and a necessary one in many cases. We’ve used that same approach in our interface design and I think with touch where we can create, again, this illusion of manipulating content directly or using content as the control and information as the interface rather than this middle man of buttons and switches that it actually helps us cut through complexity for our users.

The trick is as we explore all the possibilities of gestures, particularly these abstract gestures, multifinger gestures, three finger swipes, things that don’t have, maybe, a corollary in the real world, we have this real challenge, both as designers and users, of how to teach those gestures. And that’s really what the meat of the seminar was about. What are the techniques that you can use to make these gestures easy to discover without burdening people with lots of instruction?

Adam: Well great. Let’s get back to some of the many questions that our audience fed us that day. Tim had a question about web applications on touch devices. How do you transport hover interactions from desktop to touch?

Josh: Yeah, you know, it’s something that is a question that I get a lot because obviously there is no hover on a touch screen. If you’re going to interact with something you literally do have to touch it. I guess I would back up first and say is hover a great idea anyway? I think there are other folks that have a talked about this at length, I know Luke Wroblewski has a very pointed perspective on this, which is that hover is kind of a crummy idea to use in interface anyway because it confuses proximity with intent.

That is, just because your mouse strays over an area sometimes it triggers an interaction that you don’t always want. But I’ll sort of leave that conversation and discussion to the side and recognize that we do have a history of tool tips and the thing of being able to try explore something and say, “What is that?” that we lose, in a sense, with touch screens.

For all the advantages that we have with touch, the things that we gain in these interfaces, we certainly lose other things too. I think that in terms of the interaction that I recommend for things like this is that sometimes you’ll see two patterns. One is that a single tap triggers a hover for introductory information. You see this in most touch screen map apps, for example.

You touch a pin or a location, you see a little, essentially a hover element show up to show some cursory information about that, and then you can tap through again to get additional information. Before talking about the second pattern that I see there, one thing is that that obviously introduces additional taps. I think that’s actually OK. I mean, we have a squeamishness about extra taps and clicks that come from the web, essentially, because of the history of network latency where, especially in the early days of the web, it was a real commitment, you know?

Clicking a link on the web, that could be a 30 or 45 seconds before you find out what’s on the other side. But I think in issues where you already have the content cached and available, where there is no latency, that additional taps can be fine. The important thing here is not necessarily tap quantity but tap quality.

That is, as long as every tap shows you some useful piece of information or completes a task or even gives you some sort of delight additional taps and clicks are OK. They’re necessary, in fact, if you want to embrace complexity in your application. The way that you handle complexity in the world and conversation and books and, in fact, in software isn’t dump everything on someone all at once but to think about things in terms of progressive disclosure.

This sort of idea of getting a quick tap on something to find out what it is or what it does or get that quick information or preview I think is OK. And then as long as there’s a quick tap to follow that that’s sort of one pattern to follow to replace hover.

The second one is a slightly longer touch. So let’s say that you have an element where tapping it will activate it in some way or take you to some other place for navigation and you don’t want to insert sort of an intermediary step there. The other alternative is to do a slightly longer touch and that triggers a hover mode to explore. That’s something that you can think about, too, for a series of… Say a toolbar that has a set of icons on it.

You might want to find out what does this icon do when I touch it and a long touch will reveal the tool tip. I’m not talking about a really long touch. Maybe a quarter of a second, just long enough to distinguish between that and an actual tap. It’s also for that same toolbar or palette you can also just drag across and trigger an OS10-like dock experience where it doesn’t necessarily have to be a long tap on one element but triggering a swipe across these things could trigger that OS10 hover effect.

It’s obviously a different way to think about these things than hover but these are ways to get at previews or tool tip information.

Adam: Eric asks a question about swiping back on a smartphone screen. Should that be used as a back button type of command or strictly used for carousels?

Josh: I think that the swipe is really understood as moving through navigation and that means moving forward and back whether that’s in a carousel context. And you see this. A great example of this on the web is on the New York Times home page right in the middle of the page they’ve got a carousel that on the desktop is triggered by forward and back buttons but if you go to it on the iPad or other touch devices you actually can swipe through it and those buttons aren’t present as all.

Forward and back is just a natural understanding of what swipe does so you can use that for navigation, you can use that for moving back and forth with your history as you see with the iPad version of Twitter, for example, where you swipe through these panels, no back button required. I think swipe is flexible in that context is that it’s something that is one of the fundamental, building block gestures that you can use, that across all platforms, swipe means forward and back.

Adam: The team at Excellis Interactive wants to know what you think about Android devices having multiple buttons versus Apple’s one big home button?

Josh: It’s funny, right, because the talk is called “Buttons Are a Hack” so obviously I’m a fan of thinking about do you even need buttons? This is not to say that buttons are bad or evil, but just as I was saying earlier, that they’re workarounds and it’s worth asking do we need all those buttons in the first place?

You know, I think it’s useful in Apple’s case to have at least sort of a single hardware button. It’s something that if the screen locks up and you’re not able to use your software buttons that having that hardware button is a good fallback. It’s still a necessary fallback or workaround I would think.

Android is interesting because up until now Android phones have always had hardware buttons as part of the device and starting with the new version of Android, Android 4, Ice Cream Sandwich is its codeword, which is just starting to roll out but it’s still on very few phones. Those phones are moving into the screen as virtual buttons, software buttons, rather than as physical hardware buttons.

I think in both cases, actually, those buttons complicate touch interfaces a bit. The ergonomics of these devices is something you have to think about when you’re designing the interface for them because we are accustomed to thinking of interface design as sort of a visual pursuit. Certainly there’s information architecture but it’s about how does this thing look, what is the visual architecture of the page, and so forth.

When you are dealing with devices that are worked by finger and thumb you’re really getting out of the realm of graphic and visual design and into the realm of industrial design and thinking about how do these things get used? One of the basic rules of industrial design is that you want to have your controls below the content, right? You think of that in terms of, I don’t know, the iPod. It’s got the scroll wheel below the display.

A scale for your weight. You put your feet below the display. Keep your fingers and thumbs out of the way. That’s why you see navigation and buttons like the home button or like the Android buttons at the bottom of the screen. That’s the appropriate place to do it. The trouble with controls at the bottom of the screen is that you don’t want to stack controls at the bottom of the screen.

If you’ve got navigation and these Android buttons that are always fixed there that means that you get these sort of tap collisions. It’s a really busy area of the screen and it invites mis-taps to have controls at the bottom which is why you often see navigation in Android apps at the top of the screen to separate them from that sort of flurry of system buttons at the bottom and it actually creates some problems because there is no great solution.

You have to have your navigation at the top of the screen which means that your hand is covering the screen every time that you use those controls and that’s not ideal but it’s better than stacking controls on top of these system buttons. So I would say Android system buttons create a few problems, not least of which are these ergonomic issues that I talk about, but also that they haven’t really been consistently used.

There’s this option menu on the Android buttons, think of it as contextual menus, sort of a right-click button that will show you options that you can take on the current screens. And, you know, a lot of app developers weren’t using it consistently and it’s actually getting dropped in the new Android 4. There’s a lot of complications there that the Android system buttons create, not the least of which, by the way, is the back button which is very inconsistent and hard to figure out exactly where you’re going to go back.

Because sometimes it takes you back in a temporal sense, where was I last, and other times it takes you back in sort of an application architecture sense which is take me up a level. Now Android is actually introducing a second button, an up button, that will try to separate those concerns so that one is about navigating the application and the other one is about navigating where you’ve been.

I’m concerned that that’s going to be an additional level of complexity. It’s just going to make people more confused because sometimes those buttons will do the same things and other times they will do something differently. I have a lot to say about the Android system buttons. I’m afraid it’s sort of more bad than good.

Adam: The folks at Crate & Barrel would like to know what you suggest as a replacement for radio buttons.

Josh: Oh, I’m so glad. I thought they were going to ask me to suggest some new flatware for their 2012 season. I can sort of say more about that. Not everything necessarily needs to be replaced by gestures. My point is not to be particularly dogmatic here and say, “Get rid of all of your buttons, go fully gestural.” We’re always going to need buttons for some things, particularly for abstract actions, and, of course, they’re great labels. They tell you where you are.

And certain kinds of buttons, here I’m thinking maybe more tabs than radio buttons specifically, which tabs and radio buttons function the same way. You have one active element. I think that when you’re choosing options, when you’re choosing text options and things like that touching the element that you want is fine. I don’t know that we necessarily need to replace radio buttons.

The option there is here is a multiple choice section, choose the one that you want. I think that touching that content directly, touching that option, is fine, that that is still, itself, using content as the control. You maybe don’t actually need the radio button, the little round button itself, that just touching the content and highlighting that in some way is just as effective.

Adam: The team at Uncorked Studios asks a pretty interesting question, I think, and it has to do with how do you get your instructions to your users. Their question is how much gravity do you think needs to be given to multiple audience types? The example they give is super savvy touch users versus say novices.

Josh: I think that it’s important to remember that there are very few experts in this right now and, in general, that really all of us are novices. And here I mean there’s things of teaching people how to zoom in by pinching or spreading your fingers to zoom in and out or what a tap means or what a swipe means but those things are very easily taught, usually in the very first few seconds of using a device, and so people get those.

The question is how do you teach people more abstract gestures, the things that maybe aren’t totally obvious? This is really the realm of shortcut gestures. Theses are gestures that you use to do something quickly, you know, to use say a two finger swipe to skip ahead to the next section of the newspaper versus the next article, for example.

The reason I say we’re all novices in this, this is true for both designers and users, is that there aren’t conventions yet. Doing a two finger swipe in one magazine does something completely different in that magazine. So we’re in this very exciting but also confusing and unsettled and I suppose unsettling era of interaction design which is that we don’t yet have these conventions and we’re all making it up through trial and error.

And hopefully when I say trial and error… Just, experimentation is what I’m getting at. That’s true for users, too. I think a lot of people will touch around the screen to see if there’s anything hidden there and that’s not good enough. And so I guess I would say that we need to treat all of our users as new users because we really are. In the seminar one thing that I said is I think it’s useful to think of yourself as a parent when you are designing and trying to explain these interfaces.

By that I don’t mean to say that we should treat our audiences like children or to be patronizing or condescending about it, only that we should use the same kind of empathy and care with our audiences, the people that use our software, that we would when explaining something new to a child because, in the same way, we haven’t see this stuff before.

Very much what I was talking about in the seminar was looking at how we teach through toys and games. I mean games are terrific at teaching new interactions. Many games, you know, you don’t even know what your goal is when you start, you’re dropped into this environment where you don’t even know what your goal is let alone what your abilities or powers are or what obstacles that you’re going to overcome.

And if that sounds familiar, it should because that’s exactly the situation that we find with a lot of touch interfaces where they’re beginning to be, and I suspect there will be more and more, these sort of invisible interactions that we have to be taught because we’re not going to discover them on our own. And so when we talk about discoverability a lot of times some of these gestures are poo-pooed a little bit that it’s like, oh nobody’s going to ever be able to find them.

You know, and that’s true about a lot of things in nature, too, and we learn things by being shown them. We have to do a little bit of demonstration and practice, which is exactly how video games teach you, sort of through levels and contextual help. I think that that’s really the important thing to think about here for instruction is that it’s not about providing a manual or a screencast or a whole long list of gesture instructions as your first view of the application because we won’t read them and won’t watch those screencasts.

Instead, we need to teach people gradually instead of teaching all at once. Sure, have that reference manual for advanced users. I think that’s the way to think of it, as a reference manual not a learning guide. For software designers we need to do a lot more like what game designers do and keep an eye on the progress that people are making through our applications and give tips and help people move from novice to expert to master through this kind of contextual help.

Once they’ve learned the building blocks then you can show them the gesture shortcuts, which are essentially, you know, gestures are the keyboard shortcuts of touch. They are useful for anyone but especially useful in the hands of an expert, that is an expert not in touch screens in general but in your application, someone who knows enough about the application to say, “great, I’ve got it, I want to now apply those gestures to move through the application more quickly.”

Those are things you don’t need to teach right away. Those are things you should teach step by step. One thing, one approach that I mentioned there is allowing people to do things the slow way. If something takes three taps to get to let them do it that three tap way because that reinforces that mental model of where things live in the application and sort of the geography, if you will, of the application’s information.

But once they’ve done that a few times they’re like oh gosh, here comes this other three tap thing. The fifth, tenth time that they’ve done that three tap sequence in a row then you have a little overlay and a gesture animation to show you, oh, here’s a gesture you can do instead of those three taps. Then you wait for them to actually do that gesture so it’s “here’s a demonstration”, now, you know, encouraging practice.

Then their very first interaction with that gesture is a success and they’ve done it themselves. You don’t have to show that tutorial anymore because the lesson’s been learned and move on.

Adam: So I think this next question takes that thinking about instructions to your users, it takes it a little bit further. What thoughts do you have on how to access hints when they’re needed in the future?

Josh: Right. So the thing I just mentioned there about doing this demonstration after somebody has already done it and you sort of show them that demonstration. I think that this is something that works really well for devices and applications that are used by a single user, which is generally true of our phones. For our phones we’re usually the only ones who use them, except for if you have kids and man they’re always trying to pull it away from you.

For more social devices like an iPad, for example, where it’s often used by many people this idea of watching somebody’s behavior and then giving them that tutorial and then not giving it again is obviously problematic because it may be missed by one of the other users in the session.

So, two things. For bringing those tips back I think that you want to sort of reset the counter to zero. If you trigger that tutorial, that hint, the tenth time somebody does it the long way, the slow way, and then you do that interaction to show them the fast way with the gesture then just reset the counter. Here it comes. Wow, you’ve done it again 10 times in a row. Here’s a better way to do it that I think you’re going to like, will hit that more social environment.

As I said also, I think it’s important to have a reference so that if you’re looking for wow I know there was something. How did I do that? You do have a reference guide as a back-up. Again, don’t think of it as a learning method. People won’t read the instructions unless they’re looking for something. They won’t read the full set of instructions just to learn how to use the app.

I think this combination of having contextual hints that recur when it seems the lesson hasn’t sunk in to show people that shortcut, that power up, coupled with having a complete reference that people can go to if they’re like, “Wow, wasn’t there something that I could do?” that they can go back to refer to that.

Adam: Our next question has to do with a really cool demo that you sort of wrapped up the seminar with and that was the Uzu demo you showed us or the little video. The question are there thoughts that you have or can you say a bit more between the division between the IOS interactions like the application selection and the menus when you’re using something like that Uzu.

Josh: Right. Uzu, for people who don’t know about it, is this thing that’s called a kinetic particle visualizer but it’s really more like a lava lamp, like a little tool to hypnotize stoners. It’s super fun and trippy and you know, it has all these multitouch gestures that essentially draw visual effects. The varying number of fingers on the screen changes what the app does or the patterns that it makes.

So three fingers on the screen does something different than seven fingers on the screen. And so by lifting and raising your fingers and drawing with these you can really play this almost like a visual instrument. The question though sort of goes to, “well, what about when there are collisions with these multitouch gestures that you’re doing with an app like Uzu or anything that’s using these multitouch gestures, what happens when they collide with operating system gestures?”

For example, in IOS there are now gestures for three and four finger pinches to close an app and you can swipe using, you know, a four finger swipe and move back and forth through apps.

The problem is sometimes you’ll be using Uzu or some other app and suddenly it will trigger that IOS gesture and will send you right out of the app which is really disconcerting and obviously bad. I’m not sure there’s much that app developers can do about it and I’ve written about this a little bit. I was really disappointed, by the way, that Apple implemented these gestures. Because, wow, a full finger pinch, that’s a gesture that we could really put together as app developers.

A three or four finger swipe that’s really useful to be able to take your whole hand and slap at the screen to do something, right? Unfortunately, Apple has taken these really useful gestures not only and sort of, kind of locked them up in ways that now we can’t use them as app designers, but I think more important, it confuses things because you have operating system gestures happening in the app canvas, in the area that’s supposed to be dedicated in the app now doing things where it seems like you’re touching the application content but also doing things at a more abstract operating system level and that’s confusing.

I think that Apple, frankly, did this the wrong way. You look at other operating system like Palm’s Web OS which look like it’s probably defunct now, we’ll see, or Windows 8, the forthcoming Windows 8, and others. I should say MeeGo also, the Nokia Intel operating system. All these things had operating system gestures that worked from the edge, so-called edge gestures.

That is, if you wanted to flip through the current applications you would swipe across the screen but starting off-screen, on the bezel, on the frame, and push into the app. I think that that’s much more useful because that preserves the app canvas so that you can do whatever you want within that frame, but if you do gestures from the frame then that’s something that’s more reserved for operating system things.

What’s great about that, too, is it fits the metaphor. The operating system is the frame for applications so somehow if you start gestures outside of the application at the frame level it rhymes with the way we kind of understand how an operating system and applications work. Unfortunately, I think Apple blew it with these operating system level gestures and they do cause collisions, just like the question hinted at, where that’s bad.

Creating uncertainty for your users where it’s like, wow, if I use this gesture what am I affecting? That’s a really kind of critical problem that we have. Our job as designers, and I would say Apple’s job as an operating system designer is to reduce that uncertainty and give our users confidence.

Adam: Josh, there was also a question about the value of affordances or lack of them.

Josh: Affordances, or signifiers as Don Norman likes to call them, are visual hints that suggest how an interface works, whether that’s a door handle or a button on the app. And so we need affordances. That’s how we figure out how stuff works. Things can’t be a mystery. We do need visual hints and references in order to be able to figure out how to do gestures.

Especially these abstract gestures which don’t necessarily have a corresponding action in the real world. Again, the two, three finger swipe for example. That’s not visible and it’s something that we need to create a visible hint at how to do it. Understand that people can learn these invisible gestures but only if we tell them about them, only if we show them.

I think it really does mean that we need to use animation, we need to use overlays, we need to use all kinds of different hints to suggest to people. Color, little pulsing brightness, things that draw attention to elements that can be touched or manipulated. We have to provide affordances and I think that the way to do it, though, is to do it in context and we have to be better at it.

And I don’t want to paper over the challenge of this. I think this is a real development challenge as well as a design challenge of observing and being thoughtful about where people are in the app, what they’ve done before, what they’ve yet to learn, and providing instruction in that moment, which is exactly what games do so well.

I think that all designers should be playing a lot more video games to see how software can teach you. We’ve had a lot of bad experiences with this, right? I mean I think everyone remembers Clippy, the little talking paperclip. The concept wasn’t bad, having an assistant to pop in and tell you, hey, this is how you do this. It’s just the content was terrible.

Every time, every time, you started to write a letter Clippy would say, “Hey, do you need help writing a letter? It looks like you’re writing a letter.” That’s not helpful. It was distracting and also redundant. Maybe the first time you could say no thanks, I know how to write a letter, but he kept coming back every time you wrote the word ‘dear’. Dear Adam, then here it comes.

That’s not the way to do it. You can’t have overbearing help and it has to be contextual and it has to be meaningful and it has to be based on what you’ve already observed that the user knows. Affordances and help and hints, absolutely critical. You think about the way that we learn to do things in the world and it is through, as I said earlier, demonstration and then practice so we have to demonstrate how this stuff works.

I’ve alluded to this before, the way we typically do it is through some sort of mountain of instruction, usually before we even start using the app or through some sort of screencast that’s going to take me five minutes to watch. We just don’t do that as human beings. We don’t like to read instructions because it feels like a diversion. Even if it’s something that will help us get our job done more quickly, it feels like it’s not because we want to get to it.

Yeah, we need to have that kind of instruction but we have to do it carefully.

Adam: Josh, awesome stuff.

Josh: Thank you, sir.

Adam: Thanks for circling back with us and to our audience thanks for listening in and for your support of the virtual seminar program. Goodbye for now.

The goal of any site is for the right audience to find the right information. But beyond your actual content there are many things that can cause findability issues. These tend to be unanswered questions about your primary audience and whether or not you’re satisfying the need of that audience. Good information architecture can help guide your design decisions so that your users can effectively engage with your content.

Lou Rosenfeld offers up suggestions in his virtual seminar, 8 Better Practices for Great Information Architecture: Closing the Findability Gap. Lou believes information architecture offers long-term strategic value, and is more inclusive than some people may think. There wasn’t enough time to address all of the question during the seminar so Lou joins Adam Churchill to answer the remaining ones for this podcast.

Here’s an excerpt from the podcast.

“…I spent a lot of time talking about the Zipf Distribution, which is basically a rule of many sites that a little goes a long way. Things like, a few of the search queries that people do on your site account for a huge proportion of all search activity. So a handful of queries needs to work well in order for search overall to work pretty well. Or, a handful of your documents are the ones that most people are going to be accessing, or are going to be accessing far more than any of the other documents.

So really not worrying so much about the long tail of the Zipf curve, but the short head. And once you have a sense of what that short head is, you can start working on smaller problems that, when you solve them, go a long way…”

Tune in to the podcast to hear Lou address these questions:

• Are there any special considerations regarding intranets?
• How many audiences can a website reasonably handle?
• Is there a distinction between engagement and involvement?
• Web analytics and UX tell us different things. How should you balance knowing when something is wrong versus why something is wrong?

How do you use information architecture to solve findability issues? Share your thoughts in our comments section.

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

Full Transcript.

Adam Churchill: Welcome, everyone, to another episode of the SpoolCast. Lou Rosenfeld recently joined us for a virtual seminar entitled, 8 Better Practices for Great Information Architecture: Closing the Findability Gap. Now, the seminar yielded lots of good questions and comments, and we decided to have a follow-up conversation that we could make available as a podcast for you.

Now, Lou’s seminar spoke to new opportunities for information architects that add significant value to projects. We’re fortunate that Lou gives us a lot of time, and he’s graciously offered to come back and tackle some of the questions that he thought we could re-address from the seminar.

If you didn’t listen to this particular seminar, you can get access to the recording in UIE’s growing User Experience Training Library. There’s presently 80 recorded seminars there, all great topics from speakers like Lou from the world of Experience Design.

I wonder if that’s any coincidence that the two seminars Lou presented for us happened to be numbers 50 and 75 in our arsenal. Nice milestones for us, and with one of our favorite speakers. Hey Lou, welcome back.

Lou Rosenfeld: Thanks, Adam. I guess you’ll get me scheduled for number 100 pretty soon, right?

Adam: That would be awesome.

Lou: Excellent.

Adam: So, Lou, for those that weren’t with us in November for your presentation, can you share an overview with folks?

Lou: Sure thing. This sort of came out of a bit of frustration that I’ve felt the last couple of years that a lot of people see IA in a very limited sense, and don’t see it offering much long-term strategic value. I don’t think anything could be further from the truth.

So what I tried to do was at least map out eight directions that I called “better practices,” because I don’t think there are any such things as best practices in a field where nothing can ever be perfect. You can only make things better. But I laid out eight, and I’ll go through them really quickly right now.

One is just getting better at doing diagnostics, and I spent a lot of time talking about the Zipf Distribution, which is basically a rule of many sites that a little goes a long way. Things like, a few of the search queries that people do on your site account for a huge proportion of all search activity. So a handful of queries needs to work well in order for search overall to work pretty well. Or, a handful of your documents are the ones that most people are going to be accessing, or are going to be accessing far more than any of the other documents.

So really not worrying so much about the long tail of the Zipf curve, but the short head. And once you have a sense of what that short head is, you can start working on smaller problems that, when you solve them, go a long way. And I proposed something of a very simple rinse-and-repeat process for constantly diagnosing small things that have big impacts, and correcting for those and doing those on a regular basis.

That was the first one, maybe the most critical one. The second one, simply having better evidence, more balanced evidence. I trotted out one of my favorite diagrams, Christian Rohrer’s diagram of the landscape of user research, which breaks the methods we all know and love into four quadrants along two axes. One axis around attitudinal behavioral data, and the other around quantitative versus qualitative data.

What I’m simply suggesting is to be very careful not to do all of your research in one of those quadrants, to have balance across those four quadrants so that you have enough different blind men looking at the elephant and trying to get at true insight.

I talked a little bit about advocating on behalf of the long-term and the need to create anchors, things like missions and vision statements and elevator pitches, to counteract what many of us are dealing with in the trenches, which is constantly changing plans and directions, often due to ripple effects from management turnover and just things that are constantly reactive mode. We need anchors to stabilize our work so that our designs don’t go off the tracks and our teams don’t go off the tracks.

The fourth one was some thinking around measuring engagement and really looking at how we might do a better job of developing new metrics and ultimately better and new KPI around things that don’t have to do with clear cut conversions. How might we start thinking about developing metrics around engagement, around authority, around orientation?

Really around the stuff that I call “the metrics of in-between-ness,” the things that are beyond, again, those just sort of basic conversion measurements that we’ve been doing for years. Because there are more to our sites than the conversions. There are all kinds of other things that need to have to happen in order for people to have a good experience.

The next two, the fifth and sixth, are really areas of information architecture especially that people don’t think about and aren’t investing nearly enough, and in which there are fantastic opportunities. Those two areas are better contextual navigation within our deep content, and better search, especially across silos.

A lot of people think of IA as top down navigation. They talk about IA and search, which is wrong. IA includes any kind of finding. So I proposed a bunch of ideas around investing in contextual navigation, specifically things like content or domain modeling, as well as some ideas around improving search, especially taking advantage of opportunities both in how we allow people to enter searches through the search UIs that are involved both initially and through refinement, as well as the design of search results.

And then the last two, seven and eight. Seven was combining design approaches effectively, basically looking at opportunities to have better hybrids of what robots will do for us, things like search engines, that can do certain things really well, and what humans can do for us manually, things like best bet selection, and how you might put these types of things together in more effective ways than we typically do right now.

Finally, the last one, number eight, was around just remembering that things change, and that your design, your information architecture specifically, must respond to those changes. Looking at things like seasonality as a driver for how we present and organize information, how that type of thing can be formed by data. Looking, again, at how things are constantly changing in terms of users’ needs, and being able to respond effectively to those changing needs.

So that’s my nutshell version of those eight better practices for findability.

Adam: I love that concept, the metrics of in-between-ness. That was a great part of the seminar for me. Louise wants to know if you have any special considerations or approaches in regards to this closing the findability gap, in regards to her effort looking at their company-wide Intranet?

Lou: That was a really good question, and I hope I do a better job with it this time. We’ll see. Intranets are kind of an interesting animal in that so much of what they’re there for is to help connect people with expertise and to be part of a broader ecosystem. In other words, most intranets fail because there are easier ways to move information around, primarily things like email and sending documents as attachments, and overriding the hope for benefits of putting a canonical version of any particular document in one place that everyone can find.

Core information architecture is one of the reasons people bypass intranets and move information through other means that are less effective when it comes to things like version control. So they’re a slightly different thing. They’re part of these bigger systems, and there’s also other parts of these environments that go beyond HTML, things like CRM systems and so forth.

So, intranets, still, you’re going to find a lot of the same diagnostics are useful. You’re still going to see a Zipf Distribution for things like what content is being used most frequently. But you’re also going to have to look in other places, like are there certain types of our staff directory or our CRM system that are being used most frequently? Are certain tasks that span those different technologies, and how can we make those bubble up to the surface?

So the same things really apply, except that information architects who work on intranets are even more challenged in terms of integration. It’s not just integrating content, it’s integrating systems that house different types of content. It’s also integrating people and making sure that the systems don’t get in the way of the actual human connection. Because, again, a lot of times people want to find other people in their organization who have some sort of expertise, and that’s the killer app of the intranet.

So, again, I think a lot of the same things apply, but there’s often more silos to deal with, more fragmentation, and that creates just a bunch of new challenges for information architects. Also, a lot of great opportunity. So, if you are confounded and pulling your hair out of your head, I would flip it around and say, “Hey, you’ve got a great opportunity facing you.”

Adam: Kristin wanted to know, how many audiences a website can reasonably handle?

Lou: Well, I wish Kristin was on the phone, because I’d make her define reasonable. Reasonably, I’ll hazard a guess of three to five, and even that might be generous. My thinking goes back to Zipf, again, this idea that maybe there’s one or two audiences that are hugely critical. And then there are secondary audiences, maybe even tertiary that don’t get that same level of treatment, but get some form of treatment. So if you’re an academic website, those audiences might be students, people considering applying and considering being students, and staff and faculty.

So that’s three or maybe four audiences, and you have to really consider what their common needs are for each audience. What does each audience want? What are the tasks they need to accomplish? What are the things they need in terms of information needs that need to be satisfied? That’s sort of the high-level treatment where you might invest a lot of manual effort for each of these audiences.

But then, I think secondary audiences for an academic website might be the media, it might be alumni. It might be academics from other institutions. You may not have the resources to scale up so much manual effort for those folks, but you can still give them maybe a lighter treatment. Maybe less customized information for each audience, but maybe a single page that basically gives the lay of the land of the web environment for each of those audiences.

And then maybe tertiary audiences, I can’t just really think of off the top of my head, but those folks, you don’t do anything for them other than give them the straight robot-handled forms of access. Hey folks, we don’t know who you are. We don’t know if you’re that important, but you can use our search engine and you could use our very basic site hierarchy to navigate the site. Good luck, and let us know if we can help you. So that kind of tiered approach is what I think makes sense.

Now, the math, you know, is it one audience, two audiences that gets that Rolls-Royce treatment, is going to be very much dependent on how many resources you have at your disposal. So it all becomes an issue of scalability. But at least if you tease it into different tiers, now you don’t have to treat every audience the same way and feel the pressure to give every audience the Rolls-Royce treatment.

Adam: Luke wants to know if you draw a distinction between engagement and involvement. In other words, the example he offers up is that, he may interact with a power company’s site very intensely because he’s upset, he’s got no power, but he’s not necessarily engaged. Can you just say a bit about that?

Lou: Well, yeah, I think that’s a great example. I think what I had said in the presentation was, our goal ultimately is to design not experiences, but design for engagement. In other words, to give people an opportunity to engage with us in conversation and dialogue, and to feel ownership of that dialogue. In other words, not have our web environments just be sort of this way to project a one-way monologue to people, but to give them a way to talk with us. So we listen as well as we talk, and as much as we can to give them a sense of ownership about conversation, about the service itself, and what we may be providing.

Luke’s example is great, because it’s like well, my power company makes me angry. So I’m very involved with their website, but not in a positive way. Well, again, I would look at that as an opportunity to create something positive. I know as a retailer at Rosenfeld Media every time we have a negative customers experience, and there’s not that many, but when we do we can usually win people over and give them a sense to at least make them happy, to take lemons and make it into lemonade.

But ultimately, what can we do when we have their attention? Can we help them? Can we give them something? Can we give them something that might give them a reason to come back in a way that makes them feel like they’ve dealt with a human, and they’ve been listened to and that they have certainly a better impression that might pave the way for a future engagement?

The power company, you know, if you look at that example, yes, who would ever want to engage with a power company? Well, most of us probably would. If we have a better sense of being listened to and engaging in a dialogue with the power company, we might be willing to let the power company know that there’s a problem that might be affecting the community, and might be willing to be on the lookout for issues that would be helpful to them.

We might be willing if they give us the opportunity to report on their level of customer service, how helpful, how gruff are the people they send out into the field? What would we like them to do in terms of alternative energy? They may be doing lots of surveys, but what about direct feedback? Hey, I would be willing to put solar cells in my roof, and I would be willing to spend this amount of money to do so. Those are the kinds of conversations that those companies aren’t very good at having, but probably really would benefit from.

So even the power company should be — not can be — but should be designed for engagement. And often a negative interaction might be the doorway to a longer-term and more positive form of engagement.

Adam: Lou, one of the things that came up during the seminar I thought was fairly valuable, I wanted you to say a bit more about it, and it was this. That with web analytics alone, we know something’s not working, but we may not know why. With UX alone, we may know why but not necessarily know whether it’s working or not.

Lou: That’s right. This goes back to the second point I made about doing balanced user research, and having essentially a balanced set of evidence to use to drive your decision making. I mean, ultimately that’s what we do is we’re making decisions and we need evidence to make those decisions well. That’s what design is ultimately about, and when we have a balanced set of inputs, a balanced set of types of research, what that does is, if it’s balanced we not only get a better picture, but the sum is greater than the parts. We get just better insight overall at whatever problem we’re trying to solve, whatever we’re trying to accomplish.

So, I think there’s a lot of interesting dichotomies in the work that’s done inside most organizations that haven’t necessarily put together things like web analytics and user research. In fact, I believe I presented a slide about all those different dichotomies in the presentation people are welcome to look at. But one of them is, what versus why? So here you have all these people in one part of the organization. Maybe in one silo, maybe they’re associated with Omniture, whatever it might be. They’re the web analytics team, whatever you call them. But I have all this really rich stuff that describes what is going on based on behavioral data.

Now, if you’re on the user research team and doing task analysis, which is a totally different thing, might you want to know something about the common information needs that come out of web analytics to influence the type of task analysis work you’re going to pursue? Because that’s expensive work, and it would be really good if you had some foundation that was based on behavioral data to help you shape that agenda for task analysis.

So there’s a nice kind of complementary nature of, hey, you know, we user researchers, we’re really good at figuring out things are they way they are. We can do this sort of attitudinal research. We can talk to people, we can observe them, we can have them think out loud. But what are the good questions that we should be checking out with users in doing those studies? Well, can we go back to the data to help shape that agenda? It’s just, again, one example of how these things can come together so that the sum is greater than the parts.

And there’s a whole host of not only examples, but more importantly, opportunities. I think the organizations that figure out how to combine what are currently siloed and all these organically-evolved pockets of research and put those together in ways that are optimized from making insights are going to ultimately make good decisions. And that’s really what I’m trying to get at there.

Adam: Well, this was awesome, Lou. Thanks for circling back with us.

Lou: My pleasure.

Adam: For those listening in, thanks for your support of the UIE Virtual Seminar Program.

A common trap in designing data visualizations is focusing on all the different ways to represent the data, rather than the questions that the data should answer. The presentation of a data set is pointless if it’s not useful, usable, or if people can’t understand it. With so much data to choose from how do you keep the goal of the visualization in mind? How are you sure you’re telling the right story?

We turn to Noah Iliinsky when it comes to data visualization. He is the co-author of Designing Data Visualizations and co-editor of Beautiful Visualization. Drawing from cognitive psychology, Noah explains that there is both an art and science to designing data visualizations. Aspects of shape, color, and placement all play into our brain’s ability to process the data being presented.

With the idea of placement in mind, it helps to think of the constraints and boundaries of your visualization. Careful consideration of its landscape prevents you from ending up with a “hairball” of data. Putting meaning behind placement helps the layout of the data but also conveys greater knowledge about it.

Noah and Jared Spool discuss creating data visualizations in this podcast. And you won’t want to miss Noah’s virtual seminar, Telling the Right Story with Data Visualizations, on Thursday, February 2.

As always we love to hear your thoughts. Please share with us in our comments section.

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

Full Transcript.

Jared Spool: Welcome, everyone. On today’s SpoolCast, we have with us the fabulous Noah Iliinsky, who is doing a virtual seminar for us here at UIE on February 2, called “Telling the Right Story with Data Visualization.” He is also the recent author of “Designing Data Visualizations,” his second book with his co-author Julie Steele. And today he’s going to talk to us about how you get into projects where you’ve got massive visualizations.

Noah, welcome.

Noah Iliinsky: Hi, Jared. Thanks for having me.

Jared: I am so happy to be talking to you again. It’s so much fun. So, you and I were talking before we got on the air here about this project you have, connecting all the dots between the musicians of Seattle. Tell me a little bit about this project.

Noah: This is a website—people can go check it out right now—called SeattleBandMap.com. This is the “before” state. We’ll be releasing the “after” in a couple of weeks. And, as like so many projects, it started without a real clear plan or design. It was some people in Seattle starting to draw on the kitchen table—well, probably on a napkin—starting to draw the links between the various bands in Seattle, bands that had musicians that had played in one band and then went onto the other band and bands that had recorded albums together and that sort of thing. Seattle’s got a pretty hopping music scene, and the map got pretty big. At one point, they did a poster-size version of it, and they had a large, banner-size version printed.

But the map continues to grow; new bands, obviously, are created all the time. And so they’ve been growing this map. And of course, now there’s an online version, at SeattleBandMap.com. And what it is right now is just a collection of about, I think we’ve got 3,700 or 3,800 bands on this map, and a little hairline link between each band that has shared a member or played on an album together, that sort of thing.

Jared: Yeah, I’m looking at it right now. It looks like a case of bad acne or a Lichtenstein picture, something that’d be hanging up in MoMA.

Noah: Yeah. This is an example of what we in the industry refer to as a “hairball.”

Jared: Yeah, it looks like it. What makes it a hairball?

Noah: Well so, and this happens, by the way, a lot of the time. This is not unique to this project. This is sort of a classic result of people start a visualization with some data, and their goal is “Let’s visualize the data.” Which isn’t, it turns out, actually a goal. It’s a process. So they have created a visualization, naively, and this is not a bad thing, but they didn’t have very specific goals in mind for what information they wanted to reveal. What I’m doing with this project is I’ve come in to help them redesign, specifically, the look and behavior of this network visualization to make it more constructive, more useful, easier to get information from.

One of the difficulties that they’re having right now is that they don’t really have a lot of information represented, and so this is a little bit paradoxical. But if we represent a little more information, it’ll add some more constraints to this visualization.

So right now, all they have is bands and connections between bands. And I guess there’s sort of a third encoding, where the dots are a little bit bigger if the bands have more connections. But there’s very little else represented here in terms of any number of the other things that you can think of that might pertain to the meta information about a band. There’s nothing here about total number of members. There’s nothing here about how many albums the band recorded or how many shows they played, the overall lifespan of the band, genre, is this a band that started in Seattle or it started somewhere else and moved to Seattle.

Because there’s not a scope on this particular data set, it has crept to bands that were never Seattle bands. So the Beatles are on here and Johnny Cash is on here, because at some point somebody from Pearl Jam or something played on a group album with somebody else. And so the network has sort of crept over this initial concept. And none of these are tragic. None of these are fatal flaws. It’s just a reflection of what happens when you don’t have a more well defined goal in mind.

Jared: Right, right. And I’m guessing there’s a bunch of misinformation here, too. Like, these lines have different lengths, but does line length actually mean anything.

Noah: It really doesn’t, as far as I can tell, in this generation. I don’t actually know what the placement algorithm is for this. I think it’s relatively arbitrary. There may be a little force-direct thing going on here, where the clumps get clumped a little tighter. But the point is it’s not even relevant if there is an algorithm there if the humans who are meant to be learning from it can’t understand what those meanings are, so it may as well not exist.

Jared: Right, right. And I’m also seeing, there are places where there are multiple lines. There seem to be lines that go through objects and through points, bands, I guess, and then lines that actually terminate at a band, and it’s not clear whether, in fact, there’s always a connection to the band it goes through or if it’s just an accident that the line just happened to intersect with the dot.

Noah: Yeah, yeah. There’s a lot of ambiguity here.

Jared: Yeah, because it doesn’t go through the center. I’m looking at the band Memes, and there’s lines that go through on the edges and lines that go through on the center, and it’s crazy. Someone’s going to get hurt. [laughs]

Noah: Yeah. This is a dangerous network here.

Jared: It is. It is. OK. You’re not just critiquing this. You’re actually involved in the next generation, right?

Noah: Yeah. I’m designing what this next-generation diagram is going to look like, this network diagram. And I’m also, then, going to create it. I’m going to build it in code. So I have the accountability there of not just being able to wave my hands and say, “Here’s how it should be,” but then it’s up to me to make that actually happen.

Jared: I’m really intrigued now, right? Because I wouldn’t even begin to know how you get started on a project like this. Well, first, give me a little history. How’d they suck you into it? You didn’t just bump in on the street and say, “Oh my gosh, you have a visualization problem. Let me help you.”

Noah: No, not like that. No. It was sort of the other way around. It was a woman who’s a UX designer, who is friends with the people who run the band map, works for a professional acquaintance of mine. And I don’t know how it came up with them, but I got an email saying, “Friends of mine need some help with a visualization, a network visualization in Seattle. Is this something you might be interested in helping out with?” And so the introduction was made. And of course, it’s a fascinating project and it’s a fun project, so I absolutely was excited to work on it. And so I said, “Sure, I can do that. Piece of cake.” And here we are.

Jared: This is obviously very rich, and there are all these connections and all these bands. How does the data look on the back end? Have you looked at that yet?

Noah: I haven’t looked at the raw data. We have another friend of mine who’s working on the database angle of things, and so she’s exported samples of the data and exported versions of the data set for me and that I need to do the design with.

I haven’t seen the complete, unadulterated, raw data set. It’s mostly been user-submitted and user-validated. So I think they believe that the quality is very good, but the completeness of it may not be as complete as they would like. And they fully intend to allow this to be a site that people can add data to, whether they’re musicians or fans or whoever, and certainly allow bands to come in and, for example, put in links to their Wikipedia page, put in links to their MySpace page or the band’s home site. So you find a band on here that’s maybe connected to other bands you like, and you can click through and see when they’re playing or download some tracks or something.

Jared: That’s interesting that you sort of jumped right into the use cases. That’s really critical in terms of understanding how to visualize the data. I’m guessing you really have to start with “How will someone want to use this?” Right?

Noah: Yeah, absolutely. And that’s a little bit of a flaw. Well, this is evidenced by they just started with “Let’s show some data.” And they didn’t say, “Let’s show a particular kind of data,” or “Let’s show data to a particular audience who has a particular interest.” It’s just “Let’s show some data.” And the problem with that approach is that it leaves you a little unfocused. You are less well guided towards particular solutions, and it’s hard to tell when you get there.

So, something that we’ve been discussing in these conversations around this website is what are the sorts of information that people who come to this website are going to be interested in? So, for example, I listed off earlier things like which instrument does each musician play and how many albums did each band release. And a lot of this information is not, probably, going to be represented on this website, because there’s other ways to get it. You can go to the band’s website and look at all their albums, or you can go to their Wikipedia page, or you can go to AllMusic, or there’s any number of ways to get that information from the world, and so that doesn’t need to be a strength that we need to duplicate.

Instead, the goal here is to focus on things that are not well-represented by these other resources, which is to say, show me the network of which musicians have played together in which bands and how those bands are then linked. And that’s a very different perspective that you can’t easily get from any of the other resources that are out there now, so that’s the real strength that this offering has and that we’re trying to focus on.

So that changes, of course, things like the data that we’re going to choose and how we’re going to choose to visually represent the data that we include, because we’re telling a different story than “Here’s all the Seattle bass players for the last 50 years and who they’ve played with” or “Here’s just a timeline of the punk scene in Seattle.” Those are different, more-focused questions. And instead, we’re looking at this greater sort of network, specifically, and less about some of the details that we could.

Jared: That’s interesting to me. It feels like a trap. And this makes perfect sense to me. Tell me if I got this right. There’s a trap that teams fall into, which is they are so neck-deep in all the data they have that if they say, “Oh, we’re going to come up with an interesting way to visualize all this data,” they just start thinking about, “What are all the ways I could represent the data?” But they’re not asking the question, “What are all the questions that our audience wants answered?” to prioritize that data in a way that gets them there, and so they end up, like anything else, building out a lot of functionality that is neat but not useful.

Noah: Yeah, it is exactly that trap, and it’s the trap that UX professionals typically are familiar with, because they’ve seen it happen and are then hired to solve or hired to keep from happening in the first place. And it’s something that I bring to data visualization that I think is a relatively uncommon perspective. Not to say that nobody does it, and clearly there’s a lot of capable and smart data vis practitioners who think deeply about what the goal of their visualization is. But when you look at the whole world of stuff that’s been visualized, a lot of it is, “We had some data, so we graphed it.”

Jared: Yeah. [laughs]

Noah: Or, “We had a lot of data, and check it out: we got it all on the page, all at once.” And that’s really exciting, and it’s kind of fun, but at the end of the day, it doesn’t necessarily solve anybody’s problem or answer anybody’s questions. I find design constraints kind of useful and interesting, because they cause you to think about the problems in ways that you wouldn’t have caused when you have total freedom of expression. And for me, that sort of requirement that constrains what’s possible actually makes me think in more creative ways about what we can do with it.

So, for example, looking at this hairball, I’m a big proponent of axes, because thinking about the landscape of your visualization, the boundaries of your map, axes kind of define the whole world. And if you don’t have them, you kind of get a hairball. There’s nothing that says, “This band should be over here and that band should be over there.” And so it’s difficult to extract meaning from the placement; in fact, there is no meaning in the placement here. And so, if you can make placement meaningful, you’ve now conveyed a lot more knowledge about these bands, and you don’t have to label each band.

So one thing I was thinking of, in terms of what would be some interesting data that would also, for example, help with this layout problem a little bit, and I thought of the time line. So, each band here is a dot, but what if you had a horizontal time line of the last 30 or 40 or 50 years of bands in Seattle, and each band, instead of being a dot, was more of a lozenge, right?

Jared: Oh, OK.

Noah: A band that was around from 1997 to 2002 would have a little length of about five years, and that’s a useful thing and certainly tells you some information about the band. But it also, in the grand scheme of things, gives an enormous coherence to the layout, where now you can look at the bands that were around in the ’60s and the ’70s and the ’80s and the ’90s and see how that evolved. You can say, “I just want to see the bands that were active between 1989 and 1992,” if you’re looking for the birth of the grunge scene.

And it gives you a lot of information. It makes the information you have on the screen more accessible. It organizes it more. So it’s a paradoxical example of how adding more data to the screen can make it easier to find the data that you’re looking for. Now, maybe I’ve created some use cases that didn’t necessarily exist, but that’s OK, in the sense that we are creating an interface that facilitates more use cases that are possible with this particular interface.

And so, rather than saying, well, if we added a little date stamp next to each band names in this map, it would become harder to see everything but wouldn’t actually add a lot of value. It wouldn’t be any easier to extract the information. But when you use that extra, the addition of more data—in this case, time frame—as a constraint, you actually are now molding the data into a shape that’s easier to understand.

Jared: That makes perfect sense to me. What I like about it is that, for me, it’d be really helpful if there were a couple bands that I really liked and I had a sense of their time. I’d be able to see when they happened and who might have influenced whom and what connections they had in terms of the players between them.

And it also helps because, last New Year’s, not this past one but the previous one, I went to a film festival, and one of the films they showed was of the Boston bar scene. And there were all these bands from the ’70s that I’d forgotten about that were in this documentary that was put together. And I could see how long each of those bands lasted and how much they have influenced bands that I like today from the local scene, and even possibly from the national scene. And that information would be really interesting to me, because I hadn’t thought about those bands in years, and I could see, if I had that explorer, I would have these moments and go, “Oh! I remember loving those dudes. What happened to them?”

Noah: Mm-hmm. Mm-hmm. Yeah. And also, being able to trace the lineage of, “Oh, there’s a particular musician,” and “Oh, I didn’t realize that they were in these other bands, and that’s why they kind of sound the same, or that’s why I like…” It gives a whole context, in a way that these isolated little dots on the screen don’t reveal in the same way.

Jared: So it feels to me like there’s this iterative process where, like everything else, you sort of give yourself this constraint—in this case, it’s the timeline thing. And then you say, “OK, what use cases could we design for?” And then you start to ask, “Are those important use cases? Are they not important use cases?” And then you turn back and say, “Well, OK, if they’re important use cases, what might that design look like? What might other constraints that lend themselves to those use cases be?”

Noah: Yes, exactly. And this sort of iteration, it almost doesn’t matter where in that loop you begin, in terms of, “Are we starting with a use case? Are we starting with a design constraint?” It almost doesn’t matter which of those you start with, as long as you do iterate through and you end up with a coherent set that includes some use cases that are hopefully based in reality that are actually going to be useful to your customers. And also includes the right data being revealed to satisfy those use cases, and then eventually involves a design that can be constructed with that data and, again, continues to satisfy those use cases.

Certainly, there are situations where you don’t really know enough about your customer but you’ve got a good sense of the data and you can kind of think, “What are the interesting relationships in the data?” even if I don’t exactly know what my customer is looking for. And there are some times when you have the luxury of saying, “We know exactly what information we’re looking for. I’m going to go to my infinite data reserve and pull that data down.”

So there are situations where, if you want to graph all the census data, for example, versus employment or income, the data is out there in the world, and if you want to cross-reference those, you can probably go find it. So you can sort of assume that the data’s available in some situations and really focus on what are your use cases, or you can say, “We have some of the constraints. Let’s go from there.” But yeah, at the end of the day, you get a set of data, design, use case that kind of go together and hopefully produce something of value at the end.

Jared: Given this, it feels to me like this is actually very similar to designing anything else. There’s nothing special here. You know, here at UIE, we’ve divided up how people make design decisions into different categories, and one of the categories is self-design. So, if I needed this data myself, I could design this for me and I could look at the use cases that I would need, and as long as the rest of my audience has the same sort of needs that I have, that would turn out to be a pretty useful design.

But there’s another type of design, which we call activity-focused design, which would be how you would go out and actually research what those use cases would be. But the methods that we use to research those use cases probably aren’t any different when we’re designing for data visualizations than when we’re designing any other application, right?

Noah: Yeah, I totally agree. In fact, I consider the work that I do, the data-visualization work that I do to be a subset of user-experience work. I’m still designing experiences. I’m still designing interfaces. They just happen to be particularly focused around visualization and the visual conveyance of knowledge rather than forms and drop-downs and scrollbars and panes. And of course, I wrap those things around the data visualizations sometimes. But this does feel like, absolutely, a similar related sub-discipline that just happens to have a product that’s a little more focused.

That’s all for the first portion. And the second portion of designing a data visualization is actually taking the different dimensions of data that you have and choosing, “What do we represent with that axis? What do we represent with color? What do we represent with shape? What do we represent with size?” And that whole second half of the process we haven’t even touched on yet in this conversation, and that’s a whole specialty, another art and science into itself. And there’s definitely both art and science aspects to that phase of the design.

Jared: Yeah. But again, that feels very familiar to me with other parts of UX, right? Because if I’m laying out a form or I’m coming up with a workflow for my users in an application, I still have that sort of mix of art and science. Some of it is just based on my experience and things that I know that have worked well in the past I can draw from that. Based on inspirations I get from other people’s designs, I can draw from that. Based on experimentations that I do and prototypes I build and say, “Oh, that didn’t work so well. Let’s try that again,” I can get inspired or get data from that.

So it’s the same, right? It’s the same sort of thing, except you’re just working with a different toolbox, as it were.

Noah: Yeah, yeah. I think so. I will say, in one aspect, we have pretty good science behind a lot of data visualization in that there’s been a lot of research, in the field of cognitive psychology, there’s been a lot of research in how do people perceive different colors, how do people perceive the meaning of shapes, how do people perceive the meaning of placement? And so there are some well-established, measured, scientifically valid reasons to say, “Use color for this; don’t use color for that,” “Shape is good for these things; shape is not good for those things.”

And so it is treated a lot like an art, but you can burrow underneath that art and you can go back and read the research that explains why so many people use color for categories, for example. It’s great for categories, and we perceive it really excellently in a categorical fashion. And color’s actually not very good for showing quantities. You can use brightness or intensity for quantities, but cycling through the rainbow is actually a poor choice for showing quantities. We can show the studies that measure that as well and talk about why the brain just is never going to be very good at that. It’s not because we’re stupid or we’re from a different culture; it’s because that’s just not what we’re wired for.

And so there really is solid scientific foundations behind all this, which really can make or break a visualization, because there are ways to take certain kinds of data and encode it with encodings that are not very compatible with the shape of that data.

So, if I’m trying to show really fine-grain differences in numbers, trying to represent those with colors is very difficult. When you’re trying to differentiate between a couple of shades of light blue and decide which one is how much darker than the others, that’s a very challenging task that our brains are just not very good at. Whereas if you want to do that with position, you can tell the difference between 34 and 37 on a 100-point scale. If you’ve got a bar graph, you can see, “Well, this one’s 34 and that one’s 37, and look, a 37 one’s clearly longer.” Our brains are very well suited to seeing that difference and quantifying it and understanding it.

And so there is a science underneath all of it, where you can make well-informed choices that will lead you to a design that is easier for people, easier for your customers to understand and get good knowledge from.

Jared: You and Julie do a fabulous job of walking through that stuff in the “Designing Data Visualizations” book. That’s what you’re going to be talking about at the virtual seminar, too, right?

Noah: Yeah. The virtual seminar is actually going to be not quite a literal page-by-page walk through that book. But we’re going to follow the process in that book, starting with a data set, and we’re going to talk through and demonstrate each of those phases; the deciding what to visualize; picking out data that supports that particular story that we’ve decided is relevant. And then, once we’ve selected the data to tell that story with, going through the process of applying visual properties—placement, shape, color, size, all these things—applying these to the different data dimensions, so that what we get is a visualization that actually tells a story and reveals the knowledge that we want to reveal.

Jared: The process that you went through with the Seattle Bands Map stuff, that’s a very typical process that a lot of folks will go through, right? In terms of, “We have all this data, we have to think about the use cases, and then we’re going to apply what we know about good data visualization to pick colors and shapes and all that stuff.” Like any other UX thing, once you realize what the tools you have to work with are, it’s not an overwhelming, “Oh my gosh, this is crazy” thing. It’s, “No, I can get my head around this,” type activity.

Noah: Yeah, absolutely. Absolutely. And that’s exactly the goal of the book, and ideally the goal of the seminar, is to give people a handle on the process, give them enough of a framework and sort of a step-by-step process that they can approach these problems and understand that success is possible. And in fact, it’s a fairly deterministic thing. If you go through these steps, you’re not guaranteed of a beautiful visualization, but your likelihood of creating something that is incredible and successful goes way up, above and beyond most of what you see on the Internet, a lot of which is just sort of, you know, shots in the dark.

Jared: Yeah. I’m really excited to see what you’re going to do with this Seattle Band Maps thing, because it has a lot of potential and it would be really cool, but I completely see how it’s, at this point, in that stage of, “We have a lot of data. Let’s plot it in two dimensions with different-colored dots and then connect lines to them.”

Noah: Yeah. And to be fair to them, and anybody else who’s working with data, this whole process that we’ve been talking about, in some ways, has to come after you already have explored the data a little bit. And you’ve already spent some time doing messy things with the data and you’ve spent some time understanding, “This data set would look very different if most bands had 10 connections versus a data set where most bands have two connections.” And so, understanding the density of the data, and what are the time frames we’re dealing with, and how many bands are we talking about, how many musicians are we talking about, how many connections are we talking about.

You do kind of have to muck around with it. Maybe in a private way, maybe not out in public, but you do kind of have to muck around with it, to get a sense of what it is that you’re dealing with. Because what happens—and I’ve certainly had this experience myself—is somebody says, “Well, we have some data.” And your first thought is, “Oh, well, here’s a great way to visualize it.” And then it turns out that the data is incomplete. Or it’s too big to do effectively with that visualization. Or the patterns you hoped were going to be revealed aren’t really there, or it turns out that 90 percent or 95 percent of your data all looks the same and there’s only a few on the edge that are kind of interesting.

You can only do so much design in the abstract before you start to look at the reality of the data, and you’ve got to just kind of muck around and prototype a little bit. As you do with other kinds of interface design, you’ve got to prototype a little bit and see if your understanding or your conception of what you think you have is actually supported by the reality of what you really have and what you have to deal with.

Jared: You have to really build into your process a chance to do some really fast iterations with the data, so you can just get a feel for what it could be.

Noah: Yeah, get a feel for what it could be. And I’ve certainly found that, even when I had a pretty good sense of what I wanted to build, as soon as I got the data into a tool that allowed me to manipulate it a little bit, I started having some more ideas about what was possible, or I started running into some constraints that I didn’t know existed.

And so, yeah, you’re definitely going to want to leave room in your schedule and your budget, certainly, but also leave room in your headspace for “This initial design that I have in mind isn’t the be-all and end-all or the end answer. It’s a starting place. And then we’re going to let the data and the technology and other constraints that we haven’t even thought of yet drive our understanding and drive our process. So that, at the end of the day, we will end up with something that is closer to the reality than we started out with when we had ideas but weren’t as intimately connected to the reality of what we’re working with.”

Jared: I’m going to bet, once you get it in front of users who aren’t you, other things come up, like they say, “Oh! I wonder if I could do X.” And then suddenly you’re thinking, “Well, we could, but we just didn’t build that.”

Noah: Yeah. Right. “Come back for the next version.”

Jared: [laughs]

Noah: For sure, for sure. Actually, one thing I really like about collaborating with different people and different teams on data visualizations is they are the domain experts. And so I’ll come in and say, “How about a visualization like this?” And they say, “Well, that’s not going to show this other thing that we’re interested in looking at,” and they start to describe something else. And so, then if I sketch that or bring that to them, they say, “Oh, we didn’t even think of that aspect.”

And so you get this sort of back-and-forth that’s really well supported by having different points of view and different experiences with the data. You get this back-and-forth where people with different levels of exposure are going to have different ideas, and as they bring those ideas, the commonality of those ideas are going to surprise and inspire other people on the team. It’s a really nice thing to do collaboratively because you get more insight and more ideas than any individual’s ever going to get by themselves.

Jared: So I’m comforted by this thought, that designing great data visualizations is not too far different than designing other types of great user experiences. The big difference is that you’ve got this different set of tools because you’ve got this space and this graphic elements of it, and so you have to understand how size and color and distance and connectivity and all those axes, all those different elements play together. But once you’ve mastered those things and you really get a handle on them, this is pretty much familiar territory.

Noah: Yeah, that’s right. I think the goal for a lot of design processes is to boil down the fundamental process so that you’re not tripping over yourself just getting the process right. And it allows you to, instead, spend that brainpower and that effort creating the interesting aspects for this experience, for this data set, that make it really unique and really compelling, rather than struggling just to get the fundamentals in place.

Jared: That sounds excellent. Well, I’m really looking forward to the virtual seminar, where I’m going to get a chance to learn what those things are and to get a chance to give the book a thorough reading. Thanks so much, Noah, for joining us today and talking about all this.

Noah: Thanks very much for having me, Jared. I’m looking forward to doing the seminar.

Jared: For those of you who want to attend the seminar, you can find out about it at uie.com. It’s “Telling the Right Story with Data Visualization.” Just come and click on the link that says “Virtual Seminars.” It’ll take you right to it. That’ll be on February 2, with Noah Iliinsky. And the book, “Designing Data Visualizations,” published by O’Reilly, you can get it at all your favorite book-buying spots. It’s a nice, wonderful book with Noah and Julie Steele.

Noah, thank you again for spending the time with us.

Noah: Thanks, Jared.

Jared: And I want to thank our audience for listening in today. As always, thank you for encouraging our behavior. We’ll talk to you next time. Take care.

The goal of Lean UX is to take the focus of user-centered design off of documentation and put it squarely on the experience. The way to do this is to view any design idea as a hypothesis. With a focus on the experience, you can validate or invalidate this hypothesis much quicker. The sooner you reach this validation, the sooner you can focus on designing and building the correct solution.

Jeff Gothelf is a firm believer in the Lean UX process. One of the key aspects of Lean UX is how collaborative it is. Jeff says that the separation between design and development really needs to be broken down. That the people who are collaboratively building this experience or product need to be collaborating with each other much more frequently. Jeff discussed the idea of Lean UX in his virtual seminar, Lean UX: Getting Out of the Deliverables Business, and the audience posed a number of great questions.

In this podcast, Jeff and Adam Churchill address the questions that there wasn’t time for during the live seminar.

Here’s an excerpt from the podcast.

“…The core of Lean UX is bringing dev and design into the same time frame. That’s what we’re focusing on now.

To do it successfully, there’s an amount of upfront thinking, at the very least, that’s done by the product and design teams before we plan the next iteration.

There’s a little bit of heads up that says here are the things that we’re likely going to be working on in the next iteration. Let’s do at least a little bit of thinking around that. If there needs to be a little bit of illustration or visualization of that thinking, then it’s very, very lightweight.

It could be a sketch on a piece of paper, it could be a very rough wireframe. We’ve gone into iteration planning meetings where we’ve drawn on the whiteboard and said here’s how we’re thinking about solving this problem.

That engages the entire team in a low-fidelity way of articulating how they think the problem should be solved. Because it’s a sketch or it’s a whiteboard drawing it’s erasable. People can write over it. You can redraw it. You can redo it. That encourages collaborative problem solving…”

Tune in to the podcast to hear Jeff answer these questions:

• How do you validate with the engineering team what they’re going to need before the project starts?
• Does Lean UX require new tools or skills?
• Does the UX team build the wireframes or is it the developers?
• Does Lean UX work for larger, legacy organizations?
• What can you do if you don’t have access to your end users for testing?
• Where does user research fit into this process?
• How do you overcome expectations for wireframes that are already set?
• Does the Lean UX process reduce the number of hours spent on a design?

Do you have experience with Lean UX? Share your thoughts in our comments section.

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

Full Transcript.

Adam Churchill: Welcome to the SpoolCast everyone. Jeff Gothelf recently stepped away from his busy role as the Director of User Experience at TheLadders.com and joined us for a virtual seminar, Lean UX: Getting Out of the Deliverables Business.

We know Lean UX is an important topic and, quite frankly, one that some folks are still trying to get their head around.

We had lots of good questions and comments during the seminar. We decided to have a follow-up conversation that we knew we could make available as a podcast for you.

Jeff has graciously offered to come back and tackle some of the questions that we didn’t get to address and some of the ones we thought were worth talking about again.

If you didn’t get to listen to this particular seminar you can get access to the recording in UIE’s growing User Experience Training Library.

Right now we’ve presently got over 80 recorded seminars from wonderful topic experts just like Jeff giving you the tips and techniques you need to create great design. Hello, Jeff, welcome back.

Jeff Gothelf: Hi. It’s great to be here.

Adam: Jeff, for the people who weren’t with us for your seminar earlier in the month can you give us an overview of what they missed?

Jeff: Sure. We talked about this idea of Lean UX. Really it’s a way to rethink about the way user-centered design is being done by taking focus off of the documentation.

Instead of the end goal of the design phase of any project being an actual document that describes an experience and focusing more on getting to that experience as quickly as possible to validate your designs.

The idea was any design idea, any user experience focus of a project is initially a hypothesis, regardless of how experienced you are or how much subject matter expertise you have.

You have a hypothesis about how to solve a particular business problem. And so the sooner that you can validate or invalidate that hypothesis, the sooner you can be designing and building the right experience, the right product for your customers and your business.

The focus is taking user experience design practices, taking a look at the entire toolkit, and figuring out which tools to use at the right time and at the right depth.

Now in addition to that, it’s about taking those tools, using them at the right time and at the right depth, and collaborating much more openly and much more frequently with the team that you’re actually building the product with: with developers, with product managers, with QA, stakeholders, and subject matter experts and really building this culture of shared understanding of where the project is going, where the product is heading, so that as much parallel work can take place.

In other words, instead of waiting for the IA to finish their work and the interaction designer to finish their work and hand it off to the visual designer who then hands it off to the developers to build, how much of that process can happen collaboratively and how much can happen in a parallel track?

That’s a lot of what we talked about is different techniques and ways to work more collaboratively as a team with UX design driving a lot of that focus.

Adam: Great. Let’s get to some of those questions. John wanted to know how do you validate with the engineering team what they’re going to need before the project starts and during the project do you need to circle back with them? Is it enough?

Jeff: That’s exactly what I meant by collaborative. This separation of dev and design really needs to break down as much as possible.

The project teams that are working together to build a particular product or a particular experience need to be collaborating much more regularly and much more frequently.

That’s really what this whole Lean UX idea is about. It’s about designers reaching out and saying, here’s what I’m working on, here’s the direction that I’m heading in, here’s some lightweight ideas.

I want to get your feedback and I want you to know what I’m thinking well before the pixels are dry on the page, if you will.

By maintaining this active conversation, by engaging the other members of the team, especially engineering, in the design phase, in the user research, in the stakeholder meetings they’re always aware of where the project is, what changes are being made, why those changes are being made.

Their dependency on UX as a maker of documents so that they can do their work diminishes greatly just by having that open air of conversation and collaboration.

Adam: If you’re going to be good at Lean UX are there new tools or skills that you need?

Jeff: I think the main skill that you need is the ability to collaborate and to have frequent conversations with your team.

And that potentially is a new skill in that there’s a certain comfort for a designer to be handed a particular problem and for them to go off and sit behind their monitor for a period of time, whether that’s a day or a week or a month, and then come out and say, “OK. I’ve solved it. Here it is.”

The different skill is to be proactive about the direction of the solution of the design that the UX person is creating and to do that much earlier in the process.

You have to get up, you have to get out, you have to circulate your ideas in what perhaps historically would have been seen as an unfinished form of the design and is now indicative of the type of direction that you’d actually like to head in.

By sharing those early and often you’re building that culture, that transparency, into the design process and with that transparency comes trust.

The one new skill, I would guess, beyond obviously all the other UX skills we already have, is proactive communication. If you’re not doing that today I would say that’s key to the success of Lean UX.

Adam: There were certainly some folks that were curious as to how things get done at TheLadders.com. One of the questions was who tends to build the prototypes there? Is it the UX team or is it the developers?

Jeff: It is almost exclusively the UX team. We use whatever tools we are either comfortable with, and that varies from person to person, or whatever is available to us in the time that we have to create those prototypes.

Occasionally we will test live code that’s in production with users and of course then it’s not necessarily a prototype, that’s actual production ready code.

But for the most part it’s the user experience team working either in markup, in HTML or CSS, in Fireworks in the past, we’ve even done some Flash prototypes, and we’re experimenting with some new and different tools these days.

Adam: There was a question that was in the seminar but I think we agreed it made sense to circle back on. The team at Piehead made the comment that it seems like a Lean iterative process works really well for small or new clients but maybe not so for larger clients like big, corporate systems. They were looking for your thoughts on that.

Jeff: So, I tend to disagree with that. I think the Lean UX approach can work on any size project in any environment.

One thing, though, there’s definitely a lot more upfront work that needs to get done in these larger legacy environments.

I actually wrote a blog post about this on my blog, which I’ve got at jeffgothelf.com, called “Lean UX Let Me Down”.

Which was, we took on a legacy project, perhaps overzealously, and didn’t dig into the existing systems and the architectures that were affecting the piece of the experience that we were there to fix.

As we peeled back the layers of that onion, the scope of the project grew and grew and the pitfalls and the different directions we had to go to fix things really came back to bite us.

So yes, I think it can definitely work in larger, more legacy projects but the goal would be to get a very clear sense of what’s affected by the piece of the project that you’re currently working on.

You really need to get a sense of the entire system, perhaps at a high level, and ensure that when you’re digging in with these rapid iterations there aren’t other pieces of the application that you’re breaking.

Adam: Jeff, one of the things I know you and your team do pretty religiously is that every week you’re talking to and watching your users with your product. Shaw wants to know what to do when you can’t get at your end users.

Jeff: That’s a great question. If you have no access to the end customer the best thing you can do is launch software quickly and iteratively.

Now obviously you need to be in an environment where that’s possible. If you can get software out into the marketplace quickly, or at least into a beta test, at least you have people using your ideas and you’re getting quantitative feedback on what you’ve put out there and how well it’s working.

At least you get a sense of what people are doing with it and if they’re actually succeeding at whatever it is that that particular experience was supposed to solve.

You need to do that regardless of whether you have access to your end customers or not but that provides the quantitative feedback and some insight.

Ultimately, if you don’t have specific access to a person if you can put surveys on the site itself or in the experience that allow the customers to actually reach back out to you via those mechanisms, anything you can put in that gives customers some sort of an opportunity to give you that some of that feedback.

But ultimately their usage would be really helpful.

Adam: I guess a related question, let’s get you to say more about that. Jerome wanted to know where you place user research in this process.

Jeff: We place it as often as possible. We found a system that works well for us where we test every week. For us it’s on Thursdays, it’s Thursday mornings, and we bring three users in every Thursday.

We run multiple teams so what happens is that testing that happens on Thursday is not unique to any particular team. There’s not one team that owns the testing that week.

That is usability testing for the week and if you have something to test regardless of what team you’re on you can bring your material to that test on Thursday.

Obviously, we do plan that a bit in advance and make sure the test plan is written out at least a day in advance and that there is a decent flow to the script that we have with the participants on Thursday, but that is a shared resource that happens every week and that anyone can hop on as necessary to validate their thinking.

Adam: How do you overcome already set expectations for wireframes?

Jeff: There’s two ways. It’s qualitative feedback, so every Thursday you’ve got people looking at the experience and they’re giving you feedback on something.

With a short video snippet or a usability report you can show that this is working or this is not working. We thought this was a good idea and this was not a good idea.

Qualitative feedback, in other words, usability testing, is one way, especially if you’re doing it often.

If you’ve got a regular track of communicating qualitative feedback to the organization. Even if you designed a wireframe on Monday if it bombs in the user test on Thursday you’ve got that feedback to get right back to it.

The other is quantitative insight and to say we’ve set these expectations, we’ve actually built this, and we’ve got people using the product and there’s data coming in saying that people are succeeding with this or people are not succeeding with this.

What we initially thought was a good idea is actually failing in the marketplace. We want to iterate on that. So it’s really customer validation is the key to continually improving and encouraging an evolving point of view on what the right experience should be.

Adam: Sarah’s looking for a little bit of insight on what Lean UX does to man hours. Does it actually decrease the number of hours you spend on a design when you’re using Lean UX or do you use the same number of hours just in a more collaborative or productive way?

Jeff: So it definitely does not decrease the amount of work or the amount of hours you’re spending. It just simply distributes the time more evenly over the course of a project’s life cycle, whether that’s in iteration or a design phase or however your process works within your organization.

It just distributes those hours in a different way. Whereas traditionally in a waterfall, gated process design was heavily, heavily concentrated upfront.

What you’re doing is you’re taking the heavy concentration and you’re distributing those hours across the entire project life cycle.

Adam: Ty asks a question and so I don’t butcher it I’m going to ask it exactly the way he wrote it. At scale, multiple teams of developers, product people, designers, et cetera, is there a greater risk of inconsistency in interaction patterns or brand application?

Is there a mechanism built in to protect this or is it a lesser consideration because this is really small? Again, that assumption that it’s for small teams or in start-ups.

Jeff: Yes. Great question. The short answer to the first half is yes, there’s absolutely a risk of inconsistencies and different patterns being applied and different approaches to solving the same problems manifesting themselves in the experience.

That is absolutely a risk, especially if you’re running multiple teams across a product suite like we do.

I’ve found two very effective ways to mitigate this particular problem. The first is having a centralized user experience team. What I mean by that is there is a UX team. Now, that team my be distributed out to individual Scrum teams if you’re an Agile environment or individual project teams if you’re in a Waterfall environment but there’s a home base for the UX team to come back together.

They have weekly meetings, they share knowledge, they share project work, and they show each other, they’re constantly talking to each other and sharing what they’re working on and how they’re solving the particular challenges that they’re facing.

That can happen on an ad hoc basis, it can happen on a very formal basis in a weekly UX team meeting where there’s work sharing and that kind of thing. That works really well as a knowledge sharing, kind of an informal solution to this.

A more formal solution is to codify a lot of these patterns in a style guide or pattern library or a component library where that is readily available to the entire organization so that if one team has solved how to do sign-up forms that is saved in a particular online environment.

It provides people with the ability to go and see how one team solved it and to take that UI and to take that code and to plug it into the pieces that make sense in their particular project.

That should evolve and grow as people change those solutions but that should always be the first place someone goes when they have to go build an experience or a product that uses existing components.

We’ve developed that at The Ladders and that’s worked very, very well for us as a centralized hub and a starting point from which to maintain a consistent user experience across our entire product suite.

Adam: Jeff, tell us more about the participants that you have in those weekly tests. How do you do the recruiting, where do you get them, where do you get these folks? Do they come from a pool of users or customers? Are you rotating through the same folks? Tell us about that.

Jeff: We work through a two-sided ecosystem. We have job seekers and we have recruiters. The first decision we need to make is who we’re bringing in this week and we typically make that decision on Mondays and we’ll decide if we’re bringing in job seekers or recruiters.

The next thing is we’ll ask what are we testing this week. If there are improvements to existing work flows we will likely dig into our existing user base.

So whether that is a set of recruiters or a set of job seekers, and we’ll make certain determinations based on the type of individual that we need to get in there to use the product that we’re currently designing.

For example, we could say we’d like to bring in folks from the Midwest who earn $50,000 to $75,000 and work in the tech sector, for example. That could be something we decide to do.

At that point we could say we need existing customers or new customers. Now, we won’t actually fly those folks into New York into our offices. We may do remote testing or we may just do phone calls with them.

Even in New York we’re grateful for the large population there and create those segments very, very quickly.

Then we decide whether or not we want to bring in external users or people who are already familiar with the product to see if we’ve made improvements.

That really depends on what we’re testing that particular week. We source those individuals, again, either from our member logs, we can create those queries and pull those usernames from our databases, or if we’re looking for external folks we’ll go to an external recruiter.

Our external recruiter, we can hand her a list of our names or we can ask her to provide non-Ladders members who fit this particular demographic profile or psychographic profile.

We use an external recruiter. She does all of the recruiting, the scheduling, the make-up, the finding folks when somebody bails on a particular session.

For us, given that our action designers do the usability testing at The Ladders, that takes a significant amount of work load off of their plate and we’re happy to have that external vendor provide us with that particular service.

Adam: Carolyn poses a problem that I suspect a lot of folks run into. She says they’re having a hard time integrating UX practices into their Agile approach and planning even with Lean UX in mind.

So she asks the question is there a way you found to be possible without having disconnected design sprints before a development sprint?

Jeff: Yes. Absolutely. That’s really the core of Lean UX is how to bring as close together dev and design into the same timeframe. That’s what we’re focusing on now.

The way that we’ve done it successfully is there’s an amount of upfront thinking, at the very least, that’s done by the product and design teams before we plan the next iteration.

There’s a little bit of heads up that says here are the things that we’re likely going to be working on in the next iteration. Let’s do at least a little bit of thinking around that. If there needs to be a little bit of illustration or visualization of that thinking, then it’s very, very lightweight.

It could be a sketch on a piece of paper, it could be a very rough wireframe. We’ve gone into iteration planning meetings where we’ve drawn on the whiteboard and said here’s how we’re thinking about solving this problem.

What that does is it engages the entire team in a low-fidelity way of articulating how they think the problem should be solved. Because it’s a sketch or it’s a whiteboard drawing it’s erasable. People can write over it. You can redraw it. You can redo it. That encourages that collaborative problem solving.

What happens at the end of that iteration planning when you’ve got everybody kind of tearing up wireframes or looking at sketches together is that everyone, when they leave that iteration planning meeting they understand what we’re building, why we’re building it, and what direction we’re heading in.

There’s an amount of shared understanding that you’ve built during that process that allows developers to then go and build that perhaps infrastructure layer so that you can continue to refine the design as a designer.

The other thing that’s critical as you plan your iterations in Agile is to have the UX person heavily involved in the prioritization of the back log. The back log is just the list of the stories or requirements that you’re going to build in a priority order.

The user experience designer has to be involved in the prioritization of that back log because they’re the person who knows how they’re going to design out or refine the designs they currently have as the iteration moves forward.

And so a developer may say, “I need this page, this tertiary page, in the experience design first.” And the UX designer can push back and say, “Well actually I can’t give you the tertiary page until I design the secondary and the primary page. Let’s figure out a way. Maybe there’s a task that doesn’t require any UI that you can work on first while I design the primary and secondary pages and then I can get to the tertiary pages.”

It’s critical for the user experience designer to be present and active in the prioritization of every iteration in an Agile environment.

Adam: That’s great, Jeff. Thank you for giving us more of your valuable time. I appreciate it.

Jeff: My pleasure. I hope that was helpful.

Adam: It was. To our audience, thank you so much for joining it and your support of the UIE virtual seminars. Goodbye for now.

The Agile development process is often accused of being too focused on delivery over the user experience. But that’s not to say that Agile is the bane of UX. Anders Ramsay believes it’s important to distinguish between Agile methods and Agile values. Many, such as fast prototyping and shared understanding are also valuable in the user experience world.

In general, the difference is a fundamental one. Agile development is very solution-focused and user experience practitioners are more interested in the problem. But it’s the commonality that is important and the realization that they are out to accomplish the same thing. Weaving UX into an Agile process and emphasizing the shared values leads to greater collaboration. Ultimately the goal is to arrive at better designs and better products, faster.

Of course, this isn’t an easy adjustment to make. Coming out of the heavy document and detailed wireframe world, Anders says that it’s more a matter of recognizing what aspects of the documents are waste and are things you could easily just have a conversation about. He admits that it can be a shocking transition to make:

“…this is people who have ridden a horse and buggy their entire life, and now I’m going to put you in a car. That’s just not going to happen overnight. It’s a new way of getting from point A to point B.”

In this podcast, Anders and Jared Spool discuss designing with Agile. Anders will also be sharing more of his insights in the first of our virtual seminar Next Step Series in collaboration with Rosenfeld Media. Don’t miss Designing with Agile on Tuesday, January 24.

As always we love to hear your thoughts. Share them with us in our comments section.

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

Full Transcript.

Jared Spool: Hello, everyone, and welcome to another episode of the SpoolCast. I am very happy and excited today, because I have a chance to talk with Anders Ramsay, who is delivering a virtual seminar, in conjunction with Rosenfeld Media. We’re doing a bunch of what we call the Next Step Series, and he’s doing our first one. It’s called “Designing with Agile: Fast, Effective UX Methods that Work.” And that’ll be on January 24th. You probably don’t know this, but Anders is also working on a book for Rosenfeld Media, called “Designing with Agile: Lean User Experience for Successful Products.”

Anders joins me from New York, I believe, yes?

Anders Ramsay: Yep, I’m in New York.

Jared: Excellent. Anders, how are you doing?

Anders: Good, good. How are you?

Jared: I’m doing very, very well. So, I’ve got some questions about your work with Agile. You’ve been in the business for quite a long time, right?

Anders: At least 15 years. I built my first commercial website in ’96.

Jared: OK, yeah, so just after the web had started to really take off. So, given that you’ve been around, Agile hasn’t been around, at least the values were all written up in about 2001, if I remember correctly.

Anders: Yes.

Jared: And so, when did you start working in Agile?

Anders: Well, I think I was practicing techniques probably already as early as 2004, 2005, but I wouldn’t have called them Agile because I hadn’t really become familiar with Agile at that time, and so I would say more explicitly adopting Agile methods more closer to 2008 or 2009, and since then having, obviously, been practicing that. But that’s one of the interesting things is that it’s a way of working that it’s not necessarily tied to that you have to follow, for example, these very explicit values. That’s one of the important things to understand about Agile, I think.

Jared: Yeah. I mean, what’s interesting about Agile is that there are all sorts of different layers to it. It feels to me sort of like an onion, in that you’re always seeming to peel things back, and at the core of it are these Agile values that really, I think, speak a lot to what people are trying to do and why this really is something more than just a fad or just a re-branding of something we already were doing.

Anders: Yeah. So what’s interesting and maybe confusing for people who aren’t aware of the history is that even though the “Agile Manifesto” you know, was formulated in 2001, that was something that was many, many years in the making. And it’s really sort of turned upside-down, because the methodologies that people are familiar with, they actually existed before that term “Agile” was coined. And, in turn, those methods originated from what was generally referred to as lightweight software-development methods.

So I see myself as being more of an adoptee of these earlier, original elements that became the basis for Agile. And Agile is more just like a brand, a term. It’s something that we can all refer to. We can just talk about Agile. We’re referring to this kind of way of thinking about design in general and software specifically.

Jared: Right, right. So what would you consider to be the project that would be the, accomplishment, you know, the UX/Agile accomplishment that you’d be most proud of?

Anders: There are probably several, but one that certainly comes to mind is a project I worked on, I guess a couple years ago, in which we had done a lot of maybe what we might think of as more traditional UI design work for this project. And it was a very complex enterprise project, very domain-specific. And there was really sort of a morality struggle in the project, in which the product owner and the team in general felt that, one, they felt overwhelmed by the user interface. Also, despite all our efforts to present these various wire-frames and other more traditional UX documents, they were just very concerned about, “How are we going to be able to get all these various features? I don’t really understand it. It’s not making sense to me.”

There was really a struggle, low morale with the team. And at that point, we were finally able to bring on software developers, front-end developers, onto the team, which we had been wanting to do all along, and so be able to shift then to more of an Agile approach, in which there was an intensive back-and-forth between myself and the developers, so that rather than, for example, me having a meeting with users and then coming back with some wire-frames and trying to communicate the design concepts and get their approval on that, we instead would incorporate a construction of the actual tool.

And so, what that resulted in was that we took this one concept that effectively involved the system sort of responding to the various window sizes of the tool. And this was a really critical part for these particular users because some of them needed to work on small screens, some of them needed to work on large screens. And we were able to have them actually interact with this feature. And suddenly all this hand-wringing that they had been experiencing about, “Oh, all this complexity! I don’t understand it. I don’t get it,” suddenly just melted away, and they just kind of grokked it, to use a nerdy term. It just made sense.

That was a truly powerful example of the idea of cross-functional pairing. So we’re taking pair programming and adopting or adapting that to, or extending it to, include UX. In some ways, unofficially at least, it saved the project. The morale just was boosted, and suddenly people really believed in the product and believed that this was going to be a success.

Jared: Say a little more about this pairing-up thing. How does that work in a UX frame? Because I understand how it works in programming, right? Basically, you have two programmers sitting next to each other, and they’re actually coding together, and having the two brains sort of focused on the same activity, they spot errors and defects and they come up with ideas faster. Right? That’s the idea behind it when it’s programming, but what is it when you’re talking about it from a UX perspective?

Anders: So the difference there is that we’re doing the same thing but we’re doing it across disciplines. So, in this particular case, the way that it worked is we would both start at a white board and white-board a little bit together. And then the critical part there was that the developer was very actively engaged, and he would say, “OK, I feel now that we can add more value and evolve the design more effectively by moving to starting to build.” That was a critical part.

So we made a critical shift there, when we moved to the white board and moved from sketching to sitting next to and sitting in front of the computer. And then he would start doing some construction, and then I would just kind of continue to sketch, sitting next to him, because he may need a little time to build up certain pieces, but have some quick questions, like, “Did you mean this? Did you mean that?”

And so, the debugging that’s happening there is not so much in terms of code quality but in terms of experience quality. And one of the reasons that this works, this particular instantiation of cross-functional pairing that we were doing is something called “designing in the browser,” if people want to Google that. The reason that you can do it is because, in a modern kind of software front-end development world, where we have so many patterns and things like jQuery, a lot of highly abstracted tools–jQuery, obviously Python, Ruby and so forth, and Rails–they’re able to work at a very high speed. So we’re able to actually sit next to each other and actually build, almost like building blocks.

So it’s very powerful. And it certainly does not replace pair programming; pair programming has its own place. But it’s something that is great to do for highly detailed design work, particularly when the team already has established somewhat of an interface language, so that I, for example, can say, “Yeah, let’s use that list table, and let’s use that compact dashboard and so forth.” And you’re able to work very intensively back-and-forth and really do atomic-level design work, right directly in the browser, or in your mobile device, as the case may be.

Jared: So you’re taking advantage, if I’m understanding right. You’re taking advantage of the code components that already exist and the elements that are already there. Plus you’re using these languages, like jQuery and, potentially, Ruby or things like that, that let you get things done very fast. And as a result, that means that, sitting next to the developer, you can see the interactions and those little, subtle nuances that can’t easily be explained, like, “No, wait. When you click on that, it has to fade in a little slower. Otherwise someone may miss that it’s appeared.” Right? That type of thing. You’re able to sort of work through that and say, “No, that’s too fast,” “No, that’s too slow,” “OK, that’s just right.”

You can have that conversation. And because you’re having it with the developer at that moment, it sounds to me like that gives it an advantage. Tell me if I’m wrong here, but that gives an advantage. Later on, when you’re not sitting next to the developer, that developer understands your intent and can make decisions, saying, “Oh, I bet you what Anders was talking about was this,” and can make a decision, is more likely to make a decision that matches what your intent is when you’re apart because you had that time together.

Anders: Exactly. And so, things you want to do, then, is do what in some circles is called “pair stairs,” where you want to make sure that, as a UX designer, you kind of tour the entire team or tour all the developers and actively make sure that you are actually going to be pairing, not just with this one developer, but you want to make sure you’re pairing with everybody. What happens then, which is the same with pair programming, is you’re distributing knowledge. You get knowledge distribution across the team, and eventually I don’t even necessarily need to be as much a part of the picture. Like you said, they pick up the language on their own.

But I wanted to pick up on something else you said, which was the whole reason that we’re able to do this is because of a higher velocity, of being able to kind of build faster tools. What’s interesting is that’s really the origin of Agile in general.

One of the reasons why Agile has become so powerful is because we are able to deliver working software at a higher velocity. There was a time when you could make a case for big specifications because coding was slow, time-consuming, and expensive, and that no longer is justifiable. So it is, the whole reason we can even talk about doing two week sprints or one week sprints or hour-long sprints, if you’re doing a hackathon or something, you can be turning things around in very short cycles of time, is because developers are basically able to speak in a more succinct and eloquent way with machines, use more words that have more richer meaning. Back in the early days of the [indecipherable 11:11] , it was like you’re in third grade or first grade and you have only a few words that you know. Now, we speak this very rich language. So that has then cascaded into we’re now wanting to adopt the UX practice to that new world.

Jared: This must have been really different from the ways you were working when you were doing Agile. I mean you said you started in ’95, ’96 and you had that block of time in there where stuff wasn’t Agile. This pair programming and using these components, were those the big differences or were there other big differences that sort of stand out in your mind?

Anders: The fundamental difference is really just looking at and thinking about what is valuable and effective. So in those days, to me, well let’s be clear. In the very early days, everything was just chaos and ad hoc. There was no process. So, around ’98, ’99, we started to develop and formalize specification documents and so forth. At that point, the holy grail of UX design or information architecture or whatever term was used at that time was the perfect specification document, the perfect wireframe, the document that would just absolutely crisply communicate what needed to be built, and then you know, you could hand it to somebody and they would build it.

The problem was always with the document and if it wasn’t working, then we need to make the document better, and they need to be clearer and need to add more detail and so forth. So there’s been a fundamental shift there where, rather than a document-centered model, now it’s a conversation- and human-centered model. It’s a fundamental paradigm shift.

Jared: And so by having this human-centered model that you’re focusing on, I mean this is where a lot of folks get freaked out, right? If we don’t document the overall design, how will we make sure that it all fits together?

Anders: Right. Yeah, this gets to the core of what somebody who’s coming from a very document-centered world – somebody who’s really been indoctrinated into the design document as the culmination of one’s work, of one’s practice – it can be scary to think of a world in which you’re really centering your communication around conversation, direct interaction. For me and as for most people who adopt this, it’s something that is gradual. It’s not as if one day you’re doing heavy, big specifications and, the next day, flip the switch, and now we’re just going to talk and use barely sufficient artifacts. It’s something that is progressive.

So, early on, somebody who’s adopting an Agile approach, they’re probably going to continue to create fairly detailed wireframes. Over time, they’ll discover, they’ll think of it more and more as waste. They’ll think of it as, “Why am I adding all this detail? Because we could just have this conversation.” So it’s more that you have an increasing understanding of what elements in the documents that you create are waste. That is something that is, as your practice matures, your ability to perceive what is waste in the documents or whatever artifacts you’re producing increases. It becomes more acute.

Additionally, it’s not the simplest thing. It’s not a cut and dry thing as far as either it’s waste or it’s not waste. It’s highly contextual. It’s specific to each team, each project, and who you’re working with. So, for one project, it may make sense for me to maybe crank out a very detailed wireframe which has all kinds of annotations or whatever in a certain point for a certain project. Then, on the next project, it doesn’t make any sense at all. There’s much more value in me just scribbling a few lines on a whiteboard and then talking to those scribbles with a developer. It’s highly contextual. But it’s also certainly not something that happens overnight. We’re talking about basically this is people who have ridden a horse and buggy their entire life, and now I’m going to put you in a car. That’s just not going to happen overnight. It’s a new way of getting from point A to point B.

Jared: I think that a lot of people feel, though, they’re sort of thrust into this world where they have to not only go from the horse and buggy into the car, but they go from the horse and buggy to driving in NASCAR. [laughs] That that’s what’s expected of them. That’s a hard transition I would think.

Anders: It is. So part of what I’m trying to achieve with the webinar, with the book, and all the workshops and everything is to provide UX designers with a combination of thinking tools, basically a mental model to understand Agile, how to think of it, to see it, to give them a clear mental model of it. Then, a readymade set of tools that they can use as a starting point to be able to function in this very different world. Then hopefully as they understand Agile thinking under Agile values, they can customize and create their own tools and shape them to their particular situation. Certainly it is challenging, but that’s one of the reasons why I feel it’s important to be doing what I’m doing.

Jared: It seems to me that getting your head around those Agile values really helps a lot, because when I first saw them, I looked at them and I said, “You know, that’s sort of what we were doing all along.” This idea of individuals and interactions over processes and tools. That to me feels like focusing on the users, focusing on the way that we talk about our users, everything from having good personas so that we can talk about users and what they do in a realistic format to working along with the developers directly and having them see usability tests, all that stuff. That’s one of the core values is this individuals and interactions over processes and tools, right?

Anders: Yes. So one of the things there that’s important to understand is that those values are the equivalent of you reading a description of Rome in a guidebook versus going to Rome. [laughs] So it is an attempt to convey the most key attributes but, at the end of the day, it’s just something you have to do it to really understand it. Once you’ve done it, suddenly these statements take on a whole new meaning.

At the same time, I feel as if they are very, very high-level and it’s almost an understatement to call them the tip of the iceberg. I mean it’s just the very, very ultra-distilled representation of what we mean by Agile and there is such a universe of this entire culture, you know? So here I go, I read this one paragraph blurb about Italy and visiting Rome and Italian culture. And what have I understood if I’ve never been to Italy? Well, not a whole lot. But if I go Italy and I spend time there and then I come back and I reread that same blurb, it’s going to have a whole other much richer meaning, as with anything else. This isn’t anything particular to Agile. With anything else, it’s helpful but you have to do it.

That is why I try to take a very active, kind of workshop-oriented approach when I can when I talk about this stuff, to actually get people engaged and in some fashion experience what Agile means, or provide instructions, to say, “Now that we did this, here, go out and try and do this activity, activity X, activity Y.” So it is in some ways its own culture, its own set of values and norms, and that has both a good side and a bad side. There’s a dogma that is called a sort of negative side of Agile. It’s a curiosity in my opinion because the idea of dogma in itself is antithetical to Agile values, but it’s there. You have to just be accepting of that reality and then work through it.

Jared: I was talking to somebody just yesterday about that dogma. What occurred to us was that it seems that when you’re new to something… Of course, a lot of UX people who are new to Agile are actually working with entire teams that are new to Agile, so everybody is new. When you’re new to something, you almost require that dogma to be there in order to be successful because you’re sort of taking it on faith that the way you’ve been doing things needs improvement. That dogma is really important to having that faith-based approach to things until you’ve had enough time to know that you can break the rules and which rules are really effective and which ones aren’t. You need to have solid rules and be really dogmatic about those rules in that period. That’s sort of getting used to something.

Anders: So one of the problems is that the rules that have been devised by methods such as Scrum and XP are intended to achieve a different set of goals and a different set of objectives in contrast to what a UX designer does. A case in point is a user story is one that is solution-focused. Basically, it’s one where it’s been designed to find the most effective route to get the customer or the client or whoever it is to tell the developer what to build. Tell me what to build.

Jared: You know, as a doctor, I need to find my patient’s X-ray.

Anders: Yeah, so that’s design. You’re asking them to do the design. Now in UX, a core aspect of UX is that, in many cases, what we do as UX designers is we effectively give the customer what they do not know how to ask for, right? So in that regard, what we want to understand is not what the solution is. We want to understand what the problem is. The developers are not really interested in that. Just tell them what to build.

Jared: The problem for that particular story might be more complicated. Like, as a doctor, I want to discover that there have been tests that just came back that I didn’t realize were ordered because they were ordered by another doctor in the ward. And therefore, I want to take that information into account when I’m doing my rounds and diagnoses.

Anders: Yep. What’s interesting is for any one problem there’s, of course, any number of possible solutions. That is where the UX expertise comes in. It’s in helping shape and determine which the best solution for the particular context is and so forth.

And that is not something that Agile methods… And I want to be really clear about distinguishing between Agile methods and Agile values. Agile methods, such as XP, extreme programming, Scrum, other methods, are focused on delivery from the perspective of a developer. I’m being very simplistic. I’m being very generalizing. But from a very generalizing, simplistic perspective, those methods are delivery-focused. This is about shipping, shipping early and often. Once it’s out the door, I’m onto my next feature. I’m building my next feature.

But, from my UX perspective, at that point, sometimes that’s where the real game begins. Now we’ve got to validate this thing. We’ve got to make sure was it really as good as we thought it was going to be and so forth. Then, of course, there is the question of what are we going to ship, what are we going to build, what is the product going to be, and that requires sometimes a much more holistic perspective than this more incremental model that many Agile methods tend to lean toward.

Again, I am generalizing in some regards, but that has been my experience, that the well-established Agile methods are focused more on being told what to build and then finding the most effective way to deliver that. That’s a very good and important thing, but it does not in itself make a whole practice.

Jared: That’s a really important fact that I think gets glossed over a lot. One of the realizations that I had very recently – I hadn’t considered this – was that a lot of the stuff that we see for Agile, the practices that have evolved, they all have a heritage that comes out of internal system development where the customer is somebody who often works down the hall and eats in the same cafeteria. So the teams when they say, “OK, we’re going to have a customer on the team,” they don’t really have a customer on the team. They have someone who is pretending to think about the needs of the customer but who may not have any more information than anyone else on the team has.

Anders: Yeah, I mean, some interesting things that may be sort of shocking to a user experience designer is actually that Agile in its original methods are actually not user-centered. They’re client-centered.

They’re all originating from an enterprise world, and they’re originating in the early enterprise universe in which it wasn’t so much about, “Oh, is that button right or does it feel right?” It’s like, “Does it work?” Allow me to click on the button and build it so that the thing that I need to get done when I click on the button happens happens, and that’s it. So that is why, in the early days of software development…and I mean early. In the day when… I guess this would be in the 90s, mid-90s, 80s. Obviously software development goes further back than that, but as far as when we were just getting into GUIs, graphical user interfaces, at that time, particularly in an enterprise context… I don’t want to talk about Apple and all these things that were happening at the same time where we were getting much more into formalizing human factors and so forth.

In the context of an enterprise, the user interface design, that was just another task that the developer would undertake. So they would select a drop-down or a radio button, whatever the case may be, and what most pragmatically and effectively would achieve the feature that the customer had asked for. And so that has then continued on within Agile methods and, in a pure XP model, the user interface is just another task that is part of delivering the story. Now, of course, there’s an awareness, obviously, with the evolution of more advanced user interfaces and so forth that that is not sufficient, but that has been part of the growing pains of Agile and part of the changes that have been necessitated by that and part of what the Agile UX movement is all about.

Because we’ve gone from a world in which, if Agile were a restaurant, it’s gone from being this institutional cafeteria where basically whatever you get is what you get to a food court where if I want to get a to-do app on my iPhone, I have at least 50, more than 50. So which one do you think people are going to pick? Well, they’re going to pick the one with the highest, best experience quality, because they all pretty much have the same features. So it’s this new world where experience quality is a fundamental factor determining success, and that was just not really part of the equation when Agile, you know, originated.

Jared: To me, it seems like UX folks who are new in this environment, they can benefit a lot by sort of understanding this history of it and being able to talk the language of Agile and say, “Look, what I want to do is exactly what you want to do. I want to get us closer to those users so that the things you’re building are the right things and really are valuable to the people who we’re trying to design for, and I want to do it as quickly as you can.” And so having techniques and methods that aren’t so documentation-focused but are really, like you said, pair programming, sitting down with people, talking about them, getting everybody on a common ground, and having tools like fast prototyping, things like that, all of that becomes really essential to making this work.

Anders: Yeah and for me, one of the core attributes of an Agile UX practice is the idea of active collaboration. So we’re replacing this intensive rapid kind of “passing game”. I like to use rugby as a mental model for an Agile approach, and we’re rapidly passing the ball back and forth between team members. We do that, for example, through various workshop-oriented activities or pairing or other types of activities. And by doing this intensive collaboration, we reduce the need for writing things down, and that’s actually a very good thing because what’s interesting is, as software development philosophy has increased, traditional documents simply are unable to cope with that type of velocity. They were not designed for that pace of change.

I mean for a while, wikis, trying to use wiki pages and so forth, and that certainly had its place, that allows for somewhat of an increased velocity of change, but even that is in some case falling to the wayside. Ultimately, one of the few communication methods that can keep up, can cope with the everyday chaos of a software project, is direct conversation and human interaction. That’s something that’s implicit in the value statement. When it says, “We value direct interaction,” it’s really saying it’s more than we value it. We must have it in order to survive and be successful. So there’s an element of urgency that is not explicit in the Agile manifesto but, for anybody who has kind of lived and breathed an Agile project, it’s there.

Jared: Cool. Well, you’re going to be talking about how to do this in our January 24th virtual seminar called “Designing with Agile”. I’m looking forward to that. That’s going to be a lot of fun.

Anders: Yeah, I’m looking forward to it as well.

Jared: And I’m also looking forward to seeing the book, “Designing with Agile: Lean User Experience for Successful Products”, which is going to come out from the wonderful publishers over at Rosenfeld Media. And so I’m sure that’s making its way through the gristmill.

Anders: Yep.

Jared: Fabulous. Well, Anders, thank you for spending time with us today.

Anders: It’s been my pleasure. It’s been great.

Jared: I want to encourage everyone who’s listening to check out the books and to join us for the virtual seminar on the 24th. You can find all that out at uie.com, and thank you very much for taking the time to listen to us today, and, as always, thank you for encouraging our behavior. We’ll see you on the SpoolCast later. Take care.

While the traditional “mouse and cursor” interfaces are still in use, many of us are becoming familiar with touch-based interactions. The power and capabilities of mobile and tablet devices are growing. Often, these devices are the more convenient alternative for users to access your content. But beyond accessing your information, how are they interacting with your design?

Josh Clark, the author of Tapworthy, offers the notion that buttons are a hack. Touchscreen devices allow users to manipulate content with more than just their index finger. Multi-touch gestures can be used in many apps, in some case as the equivalent of keyboard shortcuts on the desktop. It’s a great way to create a fluid and deeply engaging interface.

The problem? Gestures are invisible. This leads to discoverability problems because it’s not clear what a certain gesture accomplishes, and they’re not the same in every app. Because there is no pattern library for gestures, it takes something like word of mouth for a gesture to catch on, such as the “pull down to refresh” gesture.

Josh shares his thoughts on designing for touch with Jared Spool in this podcast. And if you need more from Josh, you won’t want to miss his January 12, 2012 virtual seminar, Buttons are a Hack: The New Rules of Designing for Touch.

As always we love to hear your thoughts. Please share with us in our comments section.

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

Full Transcript.

Jared Spool: Hello, everyone. Welcome to another episode of the Spoolcast. I am very excited to have Josh Clark with us here today.

Josh has been speaking at our Web App Masters tour for the last couple years, and he’s doing a virtual seminar for us on January 12th of 2012, called “Buttons are a Hack: The New Rules for Designing for Touch.”

And I wanted to sort of get into the background of that with Josh today, and he’s joining us all the way from beautiful Amsterdam, across the wonders of the Skype.

Josh, how you doing there?

Josh Clark: I’m doing great. I’m tempted to decide to call Skype a Dutch word, but I don’t actually know if that’s true.

Also, you know, hey, I wanted to say, by the way, so, we’ve got this virtual seminar coming up on January 12th, and I wanted to be sure that, for the folks who come, the folks who listen in and watch the webinar, definitely wear your party hats, because it’s my birthday.

Jared: Oh, I didn’t realize that.

Josh: Yeah. That’s right. I will be, I guess, what, 23 years old, as far as you know.

Jared: Well, yes, in Internet years.

Josh: Yes. That actually makes me 150, I think, but that’s…

Jared: It could be, it could be. That’s really awesome, happy birthday. I think if we wanted to make Skype a Dutch word, we’d have to use a J.

Josh: Right. I’m staying here on the Skypeingrocht. Skypeinstrasse.

Jared: Yes, indeed.

So, you’re talking about the world of touch. And this world sort of just sprung out at us, as far as I can tell, really fast. It reached out to us really fast, maybe, is the right way to put it.

And you went on and wrote a fabulous book called “Tapworthy,” and have some other stuff in the works right now. But you’ve sort of immersed yourself in this world where we interact by gesturing on plates of glass.

Josh: It’s true. I mean, you’re right, that it has kind of come out of nowhere. The world of touch was, for a long time, limited to technological curiosities, Microsoft Surface, coffee table, for lack of a better word.

Jared: Well, airport kiosks, right? I mean, it was this really, sort of, clunky museum, big button, you just press really hard, and hopefully, it’s calibrated enough so that it actually presses the thing you want.

Even ATM machines were only touch sometimes, right? Often times, they used hardware buttons, because they couldn’t count on touch actually working.

Josh: Right. And it’s amazing, it’s gotten so much better. You still run into that, I would say, bank machines. I use Bank of America, I hate to say. And their ATM machines all touch screen based, and they’re all calibrated wrong.

They’re always, like, at your waist level, so your angle is weird, so it looks like you’re touching at one point that you’re not. I miss all the time. I mean, here I am, right, I’m supposed to be some touch screen expert, yada yada. I can’t even make my ATM machine work.

So, we’re still, clearly, learning how to use touch and design for field of view, design for ergonomics, design for different stances. You know, the stuff that I work with is primarily handheld, phones and tablets. But the fact is that we’re starting to see touch show up and get refined in kiosks where they’ve been a long time, as you’ve seen.

But also, on desktop screens, you know, with the early word from Microsoft is that Windows eight is going to be a touch based UI, where you flip through screens very similar to you do on the Windows phone, and on the Zune player before that, which Windows phone was heavily influenced by.

So, here’s this touch interface that, and we’ll see how this works out, because it’s kind of jammed together in sort of an unholy alliance with old Windows. You’ll be swiping through and tapping through stuff, and all of a sudden, whoa, here’s a Microsoft Excel spreadsheet from 10 years ago, and now you’ve got to figure out how to go back to keyboard and mouse.

It’s a little bit of a Frankenstein thing going on there, potentially.

Jared: I’m imagining some sort of mash-up between Minority Report and Dance Dance Revolution.

Josh: You know what? If it turns out to be that, I think that we will all be incredibly happy Windows users. You know, I think that probably a lot of the folks that listen in to this, sort of, the folks who do design work and UX work are probably Mac folks. But you know what? You just described the recipe for getting everyone back to Windows, the whole world.

Jared: That could be it, that could be it. And I’d probably lose 10 pounds. Or at least, temporarily misplace it, which is what I usually do with weight.

Josh: Oh, here it is.

Jared: Exactly, exactly. I know it’s around here somewhere, I probably just left it in the bedroom.

Josh: It always rears its head this time of year.

Jared: Yeah, yeah, it seems to find its way back.

So, lots of people are taking things they’ve been building for that sort of single click, index finger mouse world. And now, trying to bring it to the glass plated gesture touch world.

I’m curious if you’ve run into any sort of examples of things where that transition hasn’t gone as smoothly as it probably could have.

Josh: Yeah. I think, in general, we have a broad problem with what’s called discoverability. You know, gestures are not labeled. They are invisible. You have to find them.

And so, I see things go in two directions. One is, there’s no cue at all, you know, there’s no effort from the part of designers to help people find these gestures, which are powerful shortcuts, in many cases.

So, the new Twitter app, for example, which, for their mobile apps, people kind of got upset about it. And particularly I’ve seen a lot of conversation around the iPhone app, where, sort of, once core features, like direct messages and account switching, for people who use multiple accounts, got pushed a layer deeper into the app, sort of, hidden underneath one of the tabs, the me tab or your profile information is kept.

And they give you shortcuts, though, to get quick access to that, they swipe up from the lower right corner, from the me tab, that will trigger your direct messages and get them to you instantly rather than having to poke around.

And so, this is the kind of thing that’s like, wow, this is great, except that they aren’t discoverable. It’s something that’s unlikely for someone to try on their own. So, they have to be bold about it.

Jared: Yeah, I was told by a Twitter employee. My guess is that all Twitter employees are now responsible for spreading this. I call these word of mouth functionality, right? Where the only way you can learn about it is through word of mouth.

Josh: And, you know, fair enough, that’s the way a lot of expertise is conveyed. But I think that it’s something that the application can actually teach you in context and lead you through that, as well.

I don’t want to put in too many spoilers, because this is actually the meat of the seminar, is how do you design these gestures and put them to use and make them discoverable? That’s really something that I’ll be talking about a lot is really practical strategies and techniques that you can do to use some of these next generation interface interactions.

But in ways where people will find them effortless and easy to learn and won’t, two years later, after using your apps, are you kidding me? That’s been there all along? Which, I think, is often the way it is with those kinds of shortcuts, you know. You’re glad to learn them, but you’re a little bit angry that it wasn’t easier to find.

Jared: Yeah, I was going to say, these things have sort of been around for a while, because, you know, if you think about desktops, drag and drop isn’t that discoverable, either, right? I mean, if you’re familiar with it, you might experiment with it.

But, for example, you can click on an image in many browsers and drag it someplace, like on a desktop and it will do something with it. And what it does, you can’t tell until you’ve done it once. The fact that you can pick it up and drag it is not an obvious thing unless you do it by accident, you know, you’re holding the mouse button down when you didn’t mean to and move your hand, and suddenly, oh, wait, I just dragged that.

And so, this sort of behavior of things that you can’t discover and have these sort of hidden semantics to them, has really been around for a long time. It’s not new with gestures, but I’m wondering if somehow, because the screens are smaller and therefore, we’re more constrained as to what we can put on the surface if we’re more likely to run into this in the touch world.

Josh: Well, you know, I think if there is, and I think it’s not just small screens, I think it works for tablets, as well. I think it’s twofold. And one is that, even though the screens are nearly the same size as tablets, you still want big chunky elements and generous white space, because that’s what makes them ergonomically friendly. Which means that it does take up more room to have controls.

And in general, the whole trade off of interface design, since the get go, has traditionally been, the more features, the more functionality, the more capability that any particular screen has, typically, the trade off is more and more chrome. You know, I think, Jared, you use in your talks a lot, you showed Microsoft Word with all of its toolbars and ribbons shown. It literally fills up the whole screen.

But that makes visible all of the functionality, all the huge functionality of Word. And one of the things that’s sort of interesting about gestures is that now we’re able to use non-visual language and controls to replace some of that really dense and frankly, confusing chrome.

But now, you’re right, we have to also take into account techniques that reveal those, the presence of those gestures. And there a whole bunch of techniques that I’ll be looking at from coaching to animation to all kinds of little things.

Sometimes, they’re so subtle that they won’t even get your users’ attention consciously, but will be enough to get them to almost subconsciously try to do things. It’s the Manchurian candidate approach of interface design.

I just made that up now, by the way.

Jared: I like that, I like that.

Josh: You can have it for free.

Jared: OK. Manchurian candidate approach. That’s really cool. Everything just suddenly changed.

Josh: Oh, but, I’m sorry, one other thing, you asked me about, sort of, examples where we go awry. A big popular thing is to use screens that are themselves, sort of, 3D clones of a physical device. You know, sort of skeuomorphic design.

And the advantage of this is, wow, if it looks like a physical object and it behaves like that physical object, I will understand how to navigate it. If it looks like a book, I will understand that I can swipe to turn to the next page, to get more content.

But I think a problem that you see, a lot of times, is that people don’t follow through on those metaphors. So, you have things that look like a book, but turns out, if you still punch in buttons, flipping pages doesn’t actually work. You see that in Apple’s context app for iPad, for example. And until iOS five came out, in their calendar app, as well.

And so, the thing is that, we’ve used these tricks and stunts forever in print and, more recently, in desktop software, as eye candy, pretty up the design, you know, you see this in OS 10 all over the place now, there’s sort of all this gratuitous stuff that looks like 3D objects. And it’s just eye candy, has no function.

But when you put that into a handheld device, suddenly there’s a real expectation, and this just goes to the different way that touch interfaces tickle our brains, there’s a real expectation that, because I’m holding this physical object, if it looks like a physical object, I would expect it to act like one.

And so, there’s a real thing now that you have to follow through on your interface metaphor.

Jared: I think that, this is interesting to me, because this, to me, feels a little bit like history repeating itself. Because I remember the days of, in the ’90s, when Microsoft Bob came out with these sort of pseudo skeuomorphic designs where you had a physical desk as your desktop. And you manipulated books on a bookshelf to get to data, and you had a file cabinet to get to your files and you had a phone to operate your modem.

And then again, when the web first came out, there was Southwest Airlines, their first website, they thought, OK, we’re going to be really clever. So, you had to walk up to the ticket desk, and you interacted with an agent at the ticket desk. And there were e-commerce sites where you had to physically place things in shopping bags, and the shopping bags got more and more bloated as you shopped more.

And there was always this sort of, in some ways, awkward skeuomorphism. Some of it had to do with the fact that the resolution and the number of colors you had and stuff couldn’t do photo realism. But even in interfaces that could do photo realism, it always felt, I don’t know, kind of Uncanny Valley-ish.

Josh: Yeah, well, right. So, a couple of things. And one is, we’re always dealing with illusion, some sort of metaphor, some sort of interface metaphor that borrows, in some way, from something we already know.

So, you described a whole range of experiments in there of trying to create new metaphors, when the web came out. And in the traditional desktop also had things like that, well, you mentioned Microsoft Dot.

But, when you look at what we did arrive at, which is, here’s some pictures of folders and here are some pictures of documents and we’ve got a little trash can over here that bulges when you put stuff into it. I mean, we still did wind up with some sort of metaphor of using the real world to express notions of containers and files.

And, of course, there’s no such thing as a file on your hard drive, it’s all a bunch of little magnetic impulses, zeros and ones, essentially. This is this mess of stuff that your operating system is somehow making sense of.

So, I think that it’s important to realize that whatever we come up with for metaphor, it’s illusion. I mean, that is what we do. That is what we do as interface designers, we create illusions and abstractions that stand in for the manipulation of content and information. And touch is giving us, now, a new way to do that.

And so, it is natural, I think, to explore as we get a new way to interact, to explore fresh metaphors that go away from our traditional GUI desktop. But, yeah, I think it’s important to remember that things can veer pretty quickly into kitsch. And we do see that a lot.

You know, I think that the Yahoo entertainment’s iPad app, when it first came out, was sort of this really, sort of impressive looking living room set that you sort of see from above, and you can manipulate the stuff in the living room to do the kinds of things, very much like the Southwest waiting room ticket office that you described.

But I think when we see things like books, like, all right, that’s a pretty straightforward metaphor that we should at least be able to follow up on. But you still see a lot of things, book interfaces, that don’t let you turn the page, which is on Apple’s own apps. Again, the contacts app is like that, it’s an address book that works with desktop style buttons.

Jared: Yeah. Yeah, I think there is, really, something about thinking about taking that all the way through and making sure that you’ve got all the gestures the way it works. And I guess some of that comes from making sure you’re spending the time.

You know, the lens of the world I always use comes from a user research perspective, right? So, if you go out and you do your user research, and you actually watch people interact with these things, at some point, you should see someone gesture in a way that makes a lot of sense, that they start to manipulate the real world.

You know, there’s that You Tube meme that’s floating around, of the video of the three-year-old, or two-year-old, who’s trying to use a print magazine like an iPad, because she has these gestures that she’s learned worked on the iPad, and now, she’s trying to get pages to turn by swiping them instead of picking the page up and moving it.

Josh: Right. I think it’s titled, “Magazine is a broken iPad,” I think. Well, and there’s a similar thing, you know, there’s a video making the rounds right now with a lizard playing a game, oh, what’s it called? Ant Crossroad, I think, is the name of the game, or ants crawl across the screen and it’s trying to zap them with it’s tongue.

I guess my point with this stuff is, if you do go the physical route, of aping a physical object, you should make sure that it behaves like that object, so that you’re giving people useful cues of how to use it. Because it’s not just eye candy when it’s in a handheld device, it really is a cue for how you’re supposed to use it.

But, on the other hand, you don’t necessarily have to do that, either. You know, you look at something like Windows Phone, which is not a realistic interface, you know, it’s very two dimensional, these tiles that move around the screen.

And so, it’s not trying to be anything that we know from the physical world, but it operates as if it were physical. Which is to say, that there are these tiles with physics that you slide around. And so, while it’s not necessarily something that you recognize, it, as an object from the real world, it is something that responds very physically.

Jared: It was actually interesting, this idea that you sort of have to create physics properties for your virtual space. And say, you know, if I point and I move my finger to the right, that’s going to create a momentum for this set of pixels to actually react to that and have physical properties, so that if I do it fast, they should move fast, and if they do it slow, they should move slow.

And if they don’t quite complete the gesture, maybe they should snap back into place. Is that what you’re saying? That having those?

Josh: Yeah. I mean, just in general, this notion that there’s a physical response, creating the illusion of a physical response to your touch. That yeah, and all those things that you talked about, the snap back, and sort of the inertial reaction of things slowing down or bouncing around the screen, those things are hard to get right.

And this is one of the very subtle, I think, polish and finish differences that you see between Android and iPhone, for example. Where iPhone, they really paid a lot of attention to it. And for Android, depending on the hardware you’re on, it can feel really stuttery, it brings you out of that illusion.

But I think one thing that you mentioned earlier is how we’re manipulating things under glass. And that’s the fundamental illusion that we’re able to create, right? It’s manipulating flat objects under glass, two dimensional things. There are opportunities where we can create illusions of depth or of texture. And those can also be inviting and give cues for where and how to touch the screen.

But ultimately, at the basic level, the Windows Phone approach of having tiled content that you slide around and move through and tap and touch is sort of the most honest approach, right?

I’m not saying that one is better than the other, I think that a lot of people are fed up with, sort of, the skeuomorphism as a visual design trend. And fair enough, I think we’ve seen a lot of it.

But I think it’s also really useful to help people turn the corner into getting used to using these objects. And Apple’s definitely been a big proponent of doing it, and its touch interfaces. And increasingly, in its desktop interfaces, too.

And I think that, it’s hard to say that it hasn’t been a success when you see newcomers to computing, either, typically, on either side of age spectrum, either toddlers or seniors, how quickly they’re able to pick up and understand this through the direct interaction and often through these real world cues. You know, that is a powerful teaching mechanism.

Jared: Yeah. I think it is. And yet, there’s still things that are difficult to manipulate. You know, so, for example, I have trouble, I don’t know, maybe you do, too, with the video slider in video player on the iPhone. So, being able to, you know.

I want to go back, you know, somebody just said something interesting and I was only half paying attention, and I want to go back and hear them repeat it. And I find it to be a really clumsy act to just somehow get back a few seconds so I can hear what they just said without going back and having to listen to the last 10 minutes.

Josh: Yeah. So, you know, what’s interesting about this, is that there actually is an adjustment for this. But this, again, is something that’s poorly explained and it’s not easily discoverable, is that if you touch and hold that slider and then pull your finger way down the screen and slide from there, that you’re going to get, sort of, a more fine control on the scrubber control.

Jared: Oh, interesting.

Josh: Which is not obvious, but, sort of, when you think about it a little bit, it’s almost like, you were getting, like, leverage, if you think of it as a whole, as like, it sort of has a physical corollary. But, in any case, it’s not something that is easily discovered.

So, one of the things that I’ll talk about in the seminar is how to improve stuff like that. That means, great, that there is consideration for things like the shortcuts that I mentioned earlier, or different ways to use it to get finer control over the scrubber control, like you mentioned.

But we need to do a better job. We have to go beyond just coding that stuff in and doing more to help lead people by the hand, literally. How to touch these interface controls and how to use them. And how to learn them gradually.

You know, one of the things that I’ll talk about in the seminar is all the ways that we try to teach people to do it that really are failing, that are failing our users, and, in a way, then, they’re failing all of our efforts to make great software.

Jared: Yeah. I think it’s interesting. And I think that people who are sort of really been immersed in a desktop way of thinking have to have some sort of way of stepping back and attacking the problem a little differently.

You know, I’m thinking about, for instance, one of the banking apps that I use is from Chase, Chase online banking. And their controls, the way I manipulate my bank account, and this is on my desktop, through a browser. The way I manipulate my bank account is through this list of functionality that is all the line height of text, separated from each other.

And if they tried to move that to my iPad, you know, if I try and use the website for my iPad, it’s virtually impossible, because I can’t get, with my fingertip, that granularity of pointing control. And I’m often selecting the wrong function, because my fingers are just too wide, and they cover up what I’m touching. And all sorts of things that are not an issue when I’m using a mouse.

Josh: You want to know one of the really, and we talk about, sort of, irony, I guess. I think this qualifies as irony. Is that, actually, the harder that you try and concentrate to hit a specific point, on iOS, specifically, the more likely you are to miss. And the reason is, because of the shape of your finger, the part that it looks like you’re touching, to you, is actually above where the actual meat of your finger touches the glass, because of the curve of your finger.

So, they have adjusted the code downward. So, in other words, you touch a point on the glass, it will actually sort of give you the credit for touching a few pixels above. So, if you’re really trying to just zero in and touch with just the very tip of your fingertip, you will miss.

Jared: Yeah, so, I end up playing all these games with pinch zoom and trying to zoom into the text so that it’s big enough that it’s the right size for my finger. But then, the screen messed up and it doesn’t always work. It, sometimes, for whatever reason, the browser resets its page back to the original size before I can do that. And oh, it frustrates me.

Josh: I mean, this is why all of us in this industry got to get better at building websites that look great on every device, you know. And all the great work that folks like Ethan Mark Cohod and Erik Gustafson have been doing the last year to explain responsive and adaptive web design. So important right now, so that we can have those big chunky touch targets for mobile, but that sort of shrink down to more reasonable visual size on desktop.

That’s the big challenge for us, is to be a bit more flexible and clever about adapting our designs, or really, more specifically adapting our content to different sizes of screens. I don’t mean, what kind of content we show. I strongly believe that the same content should be shown on all platforms. But you know, how we display it.

Jared: Right. Right. I think that there’s lots of challenges, because I think it’s really easy to go overboard in creating all these gestures, so that, you know, if you sweep to the left and then move to the right and then do a little dance, that’s going to be open file.

Josh: Right. Or at least, hokey pokey.

Jared: Yes. either way, it’s what it’s all about.

Josh: Yeah, that’s right. Well, and I think that it’s important to realize that it’s for complex gestures, like what you’re talking about. Those have got to be power shortcuts, those have got to be for power users, right? Those are the keyboard shortcuts of touch.

So, just building a shortcut like that doesn’t mean you can eliminate the long way around. There still has to be some evident visual cue for any basic function. And so, that does mean that we need to have buttons in appropriate places.

But I think it’s important to remember that buttons are a hack, and I mean that in both the real world as well as the virtual world. And I’ll explain what I mean by that in the virtual seminar.

Jared: Yeah, no, I think you’re absolutely right. We’ve created this, sort of, monstrosity because of our fingers, and because of the way we’re built.

You know, Bill Buxton used to only half joke that if alien archaeologists land on our planet, you know, 20,000 years from now and dig up our remains of today’s society and find the computers of today, they would think that we only had one finger.

Josh: Right.

Jared: Because, up until recently, the devices we had, at least, the technology devices we had, sort of assumed that you only did one finger at a time, that you didn’t have feet, that you could move independently, and you didn’t have multiple fingers.

And I think that the gesture world pushes us beyond that, so that, you know, you don’t play a piano with one finger if you’re a successful pianist. You move independently across your hands and even your feet.

And it feels to me like these new technologies are helping us see into that world a little bit more and take advantage of what we can do. But at the same time, we have to create a whole new language for this.

Josh: Yeah, that’s right. And we’re just starting to get into that multi touch world. I mean, we’ve had multi touch on phones for nearly five years now. But only, sort of, in theory.

Most of us haven’t used multi touch, except for the occasional pinch, right? In general, most of us use just one digit, our thumb, to use the phone. You’re holding it in one hand, unless you’re holding it in some kind of crazy claw. You’re using your thumb to tap away.

And so, it’s really, with tablets, especially, now that we have a larger screen with enough room to put all of our fingers on the screen, and a form factor that you pretty much have to use it with two hands, means that you’ve always got a hand free to do more complex gestures on it.

So, you’re right, though, now that we’ve opened up this possibility and started to get some willingness to do it, we don’t have a very understood gesture vocabulary, at all. Because the iPad is, very literally, the very first truly mainstream far and wide, multi touch device where people will actually use multi touch on it.

And so, we’re in this horrible situation, not horrible, it’s an awkward situation for both users and designers, where we have to figure out what does a three finger swipe mean? And it means one thing on another app, and another thing on another.

So, we have a lack of confidence, as users, and as designers. And there’s nobody who’s really showing much leadership in it right now. I mean, my big concern, actually, is that it’s going to be the toolmakers who decide this stuff.

You know, as more and more people use, for example, Adobe’s toolkit, magazine makers and publishers, I’m thinking of, particularly, here, to export their print magazines into more fancy iPad designs. By using Adobe’s tools, they do Adobe’s interactions.

And you know, I give a lot of props to Adobe for a lot of stuff that they do, but I’m not necessarily sure that their interaction design is the best.

And so, I want to make sure, and it’s part of the reason that I like to talk about this stuff a lot and do the virtual seminar like we’re going to be doing, is to talk in a more thoughtful way about, what should these standards be? And how can we arrive at them as a community, instead of just inheriting them de facto from the big boys?

Jared: Well, that’s interesting. Because, you know, take something simple like pull to refresh. That just showed up in, I think it was a Twitter app, initially.

Josh: That’s right. It was Tweetie, what became the official Twitter app, that’s right.

Jared: Yeah. And then, all of a sudden, it’s everywhere. And it becomes this general thing. And there was no standards body that said, you know, that the UN did meet and say, “We hereby declare that pull to refresh will be the official way to refresh data for the rest of humanity.”

Though that would be cool if they did. Particularly with whatever accent I just made up there.

Josh: I really like that, I think it was kind of quasi-European, but also, vaguely gnomish. I don’t know.

Jared: Yes, it was very gnomish.

So, it’s interesting to me that that standard just sort of became the standard. And you’re right, I think some popular tool vendor is going to pick something, and everyone’s going to say, oh, that’s what we’ll use, and they’ll start borrowing and stealing it. And the next thing you know, it’ll spread like wildfire through the design community. And I wonder how we make sure that we don’t have regrets about what we settle on too quickly.

Josh: Yeah. I think that that’s a real challenge, right now, and a real worry that I have.

I mean, on the one hand, we need to standardize as soon as we reasonably can, because that’s what’s holding us back right now, is sort of a sense of confusion of, well, what does a three finger swipe mean? You know, what does that mean? Do I have license to do that, or am I just going to confuse people? So, it’s sort of a holding area that we’re in now, holding pattern, in that regard.

But on the other hand, you know, right, we don’t want to do it too fast. I mean, I think the pull to refresh thing is a great example of both the good and the bad of this. On the one hand, when Loren Brichter, the developer who made Tweetie, he sort of invented that gesture and put it into the Tweetie app, that then became the official Twitter app.

You know, he put a lot of thought into how it is that that should work, why that works. And, in fact, in the version before, sort of a quick, sort of, interaction design history of this app. In the version before he introduced pull down to refresh, he just had a refresh button at the very top.

And the thinking was, wow, all right, when you’re going to see what your latest tweets are, you scroll up to the top of the screen. What better to do than have a refresh button waiting there for you when you got there?

And as an exercise, I was like, well, wait a second, I don’t even need to do that at all, right? So, it has the instruction, pull it down, you snap it back, and the thing reloads.

And so, that is a great interaction. It’s this thing that is just sitting there waiting for you right when you need it. It’s piggybacking on top of the known behavior and gesture that you do to scroll to the top.

But what you see, interestingly, is that, other apps, where that behavior isn’t part of it, Foursquare, for example, for iPhone, uses that pull down to refresh gesture for locations, even though there’s no chronological aspect to it. And so, it’s something that you wouldn’t discover on your own unless you were a fan of other apps that use that, and you just naturally associate that with the refresh button.

This is also an iOS only behavior, you know, you don’t see this much in Android apps, this has sort of been an iOS community thing. So, we have this issue, not only of, right, do people understand the intent and context of the gesture to use it in the way that it was originally intended?

So, I think it’s great that the pull down to refresh gesture spread far and wide. But sometimes it’s spread too far into context where I’m not sure that it works as well.

And then, we also have cases of, well, all right, so what’s the Android community thing going to be? You know, as we develop platforms and software ecosystems, apart from each other, you know, is it going to be like developing ecosystems in the real world, where we have all this crazy stuff done in Australia?

Sorry, Australians, you’ve got some crazy animals there. Do you know the platypus actually has, like, electric shocks? Anyway.

Jared: Huh.

Josh: That we’re going to have, sort of, that.

Jared: Seriously? Like an electric eel?

Josh: Yeah, they’ve got, like, fangs and they’re poisonous and they have an electric field. Anyway, I learned this recently, I’m fascinated by it. But it’s like.

Jared: Are they like a renewable energy source? Could we, like, hook platypuses up to our toasters?

Josh: Yeah. I mean, I think that would be adorable. You’d just have to watch out for the poison.

Jared: A platypus powered toaster.

Josh: I’m also going to be doing another virtual seminar on the zoology of Australia coming up after this.

But no, but that’s my concern, it’s like, oh great, in a way, the pull down to refresh gesture is the platypus of iOS that doesn’t exist on other platforms.

And so, I guess I worry about this slightly, right, how do we manage these expectations of what is standard in terms of just good practice touch screen and what do we understand as working well on an Android tablet, or an iPhone tablet?

We’ve always had this kind of problem with operating systems, and we had it with Windows and Mac, they broach differently, similarly enough, but enough to confuse you when you tried to switch. And that was generally OK, because usually you were an all Mac or an all Windows person.

But now we have all these different touch screens in our lives that run different systems. And so, there’s, I think, a real need just to share and talk and it’s really, I think, a time to be generous with our ideas about what’s working. And I mean that even with companies that are competitors.

I mentioned publishing earlier. I think it’s crazy that you have to learn completely different gestures to read a magazine in different magazine apps. You know, I feel like, wow, all right, Conde Nast, Time Inc., get together and figure out how you want it to work. That’s not a competitive thing, that’s just basic infrastructure.

And I think that we as designers and developers and IAs need to reach out to our peers and say, hey, why did you make that decision? I’m thinking of doing this. Do you think that would work for your app, too? Would you be willing to sort of give this a try so we can sort of try to develop some standards?

But in a way, that’s a community way that comes from the right source, sort of, the creative source and from close up views of our users and how they’re using our apps, rather than top down from the toolmakers.

Jared: It would seem to me that the first step of that would be to start putting together some way of seeing what all these gestures that are evolving are and who’s using them where.

So, back in the ’80s, I worked for a company, Digital Equipment Corporation, and we made computers within our own product line. We had something like 24 different operating systems for different architectures of hardware that we worked.

And it wasn’t like the thousand versions of Android that are out there. I mean, these were radically different interaction models depending on the technology we were using.

And, of course, you know, a common thing across each of these things was being able to edit a document, usually a program file, right? So, you had to write programs, and you had to edit them, so you needed some sort of editing tool.

And so, there were 14 different editors from Emax to various proprietary editor tools to word processors to all sorts of different things. And I created this table, and I was the first person to ever do this in the company, because I was writing a brand new family of word processors. I wrote one of the first PC based word processors for this company.

And I created this table of all the different ways you could do something like cut and paste. And there were myriads of gestures and myriads of keystrokes and myriads of commands. And some had physical keys that were literally on the keyboard, labeled cut and paste. And others had control keys or control shift keys.

Or there was one program that had a meta key. So, it was meta shift control. And the left shift key and the right shift key would do something different, so it was like, meta left shift control right forearm would generate.

Josh: You’re making me dizzy.

Jared: Yeah. But we had to create this table of all the different ways to do common functionality, and there was no consistency across it. And I’m wondering if anyone’s doing a sort of similar thing today across the popular apps and just trying to catalog this.

Josh: So, I haven’t seen anything, but this is something that I have been wanting to do for awhile, and if anybody out there is interested in collaborating with me, I’d love to, is to start putting together a gesture pattern library.

This is still pretty new, just in general, just getting mobile pattern libraries together, and there are a few really good ones out there. But there hasn’t been a lot in terms of how are gestures being used, and how can we start to use a collection like that, as you said, have a conversation about what is it that’s working well and is working best? Because we’re still finding our way, you know, with that stuff.

And you’ll see apps take right turns, too, like the new Twitter app that I mentioned before, used to have this thing where you could swipe left to right across the title bar, the navigation bar in iOS, and doing that, if you were drilled down into the app, would just spring you back up to the top of your timeline. They did away with that in their new version, and now you get at it by tapping the home tab again.

So, you know, there’s still a lot of trial and error and experimentation within apps, let alone across them. And I think that that’s healthy to a certain degree, but it’s also frustrating. It’s, like you say, it’s a balance between getting to standards as quickly as we can, but with enough time and thought that we’re arriving at the right ones.

Jared:Wow. Well, you’re going to talk a lot about this further in your virtual seminar, which is going to be January 12th.

Josh: My birthday.

Jared: And your birthday, Josh’s birthday. “Buttons Are a Hack: The New Rules of Designing for Touch.” Josh Clark, thank you very much for joining us today.

Josh: Thanks for having me.

Jared: And thanks to everyone for listening. And once again, thank you for encouraging our behavior. We’ll talk to you later.

A designer can never have too many tools and methods for creating their designs. Many times conveying interactions in a static wireframe is difficult. So designers have turned to HTML and CSS to create wireframes and prototypes to provide a richer interaction. JQuery can also be thrown into the mix to further this process along.

Richard Rutter and the Clearleft team discovered that JQuery is a great tool for wireframing. Richard says it gives them the flexibility to work out ideas very quickly. One of the reasons he feels JQuery is such a good tool is the documentation it provides. The amount of tutorials and documentation mixed with its ability to work quickly allows “so you don’t have to spend your time and your ‘thinking energy’ coding. You can spend that vital ‘thinking energy’ designing instead.”

Richard’s virtual seminar, JQuery for UX Designers, generated a bunch of great questions from the audience. In this podcast, Richard joins Adam Churchill to address the questions that weren’t addressed in the live seminar.

Here’s an excerpt from the podcast.

“…what JQuery does, by its very nature because your coding with it, it gives you ultimate flexibility about what you want to do with your designs. Things you want to try out. Effects that you might want to do. Bespoke interactions that you want to map out. Even the most simplest sounding things, like say, adding a tag. That’s actually got a bunch of states in there, which you may or may not want to specify in some detail…”

Tune in to the podcast to hear Richard answer these questions:

• Why should you use JQuery instead of interactive wireframe tools like iRise, Axure, or Balsamiq?
• Is there a reason to use the hover jQuery function rather than the hover CSS pseudo-class?
• How do you avoid having a developer look at a sophisticated-looking interaction and re-using it in production code?
• In your experience, do UX designers find using PolyPage easier to understand?
• Do changes set using jQuery persist upon a page reload?

Do you use JQuery in your wireframing? Share your thoughts with us in our comments section.

Recorded: December, 2011
[ 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 episode of the SpoolCast. Earlier this fall Richard Rutter joined us for a virtual seminar titled, “JQuery for UX Designers.” There were lots of good questions and comments. And we decided to have a followup conversation that we could make available as a podcast for you. Richard’s seminar spoke to how JQuery facilitates the vital steps of designing and testing interactive wireframes. Specifically, the complex interactions of today’s modern websites and web applications.

In the seminar Richard got folks started with JQuery. He offered lots of examples, hints and tricks. And he’s graciously offered to come back and tackle some of the questions that we didn’t get to address in the seminar. Now, if you didn’t get the chance to listen to this particular seminar, you can get access to the recording in UIE’s growing User Experience Training Library. There’s presently 80 seminars there that have wonderful topic experts just like Richard giving you the tips and techniques that you need to create great design. Hello Richard, welcome back.

Richard Rutter: Thank you. Thanks for inviting me back. Hello.

Adam: Happy to have you. For the folks that couldn’t join us for that seminar, could you give us an overview of what you talked about?

Richard: Sure. What I wanted to do in this seminar was really give a very practical introduction to UX designers about what JQuery is and how to get started using it. Right from the very beginning assuming kind of no knowledge. Because, really that was a seminar that I could have done with when I first started using JQuery as a UX designer to help me design. That was the real focus I wanted to get over, that JQuery can be a design tool. If you’re using HTML and CSS as your method of defining wireframes. And helping design more rich kind of interactions that most websites have now a days. Most things go a bit beyond just being texts and links and images. There’s Ajax and all sorts of stuff that starts to get in the way. Which is pretty difficult to design with static wireframes in things like Viseo.

We find at Clearleft that JQuery is a really good tool for helping us do that. We like to hand code our wireframes. JQuery fits into that nicely. It gives us, as designers, the flexibility to really work out some ideas very, very quickly. Which is the whole sort of idea of JQuery. So in the seminar, yeah, it went from sort of first principles, how to get JQuery working, and then showing some more detailed examples about faking Ajax interactions. Simple show and hide. How to get plugins working so you can straight away get things like popup calendars and light boxes. And all these other tools that you might want to include in your designs. It makes it easier to get that stuff together quickly so you don’t have to spend your time and your thinking energy coding. You can spend that vital thinking energy designing instead. Which is really important.

Crucially, actually, I finished off with a bunch of the best documentation and tutorials and places online where you can go and get more information. One of the great things about JQuery is that it’s hugely well documented. There’s lots and lots of people all over the place have written tutorials and so on. So that in itself makes it a good tool. If getting your hands dirty with code is not too scary for you. For me, I quite like doing that as part of my designing. It helps, I think, to get your hands dirty in the medium for which you’re designing. I think that’s quite important. That’s why I put this together.

Adam: Cool. Well, let’s get back to some of those questions. So the folks at Lokion Interactive wonder, why use JQuery and the tools that you offered up versus interactive wireframe tools like iRise, Axure or Balsamiq.

Richard: Mm-hmm. What JQuery does, by its very nature because your coding with it, it gives you, sort of, ultimate flexibility about what you want to do with your designs. Things you want to try out. Effects that you might want to do. Bespoke interactions that you want to map out. Because even the most simplest sounding things, like say, adding a tag. That’s actually got a bunch of states in there, which you may or may not want to specify in some detail.

That said, I think the other aspect to those other pieces of software is that like any piece of software, there’s a certain amount of time ramping up learning how to use it. Learning how to use it well. And, if you already know how to code a little bit… Now remember, we’re not producing production quality code, just enough stuff to get your ideas over, then adding JQuery on top of that tool set you already know, perhaps, is no more onerous, for example, then learning how to use Balsamiq or any of the others.

But obviously, if you already know those pieces of software well, then sticking with that might be to your advantage. Although you are hamstrung to a degree by what the software can do. And there is occasionally a danger that the software can drive the interactions that you specify rather than the other way around.

Plus, to Clearleft, we do have the advantage of being a relatively small company. Which means that the UX designers that we have are surrounded by visual designers and, crucially, the front end developers as well. Who are more than happy to chip in and give us a hand every now and then if we want to, you know, have to do something a little bit tricky. We can just go to them and say, “hey, Andy. Can you help me with this bit.” And they’ll be more than happy to do so.

So, it works well in our environment now which is very open and collaborative. Like I said, that suits us well. And so JQuery just fits into our work flow nicely.

Adam: Phil asks if there is a particular reason to use the Hover JQuery function rather than the Hover CSS pseudo-class.

Richard: There isn’t really. It might depend slightly on what you’re doing with that hover state. If that hover state is merely changing the style of something then it’s fine to just do CSS instead. Assuming that you haven’t got any kind of cross browser issues. I mean, when we put wireframes together, they’re designed to show to the clients, obviously. And because they’re just wireFrames, we can say to the client, “you’ll need the latest version of to just do CSS instead, assuming that you haven’t got any kind of cross-browser issues.

When we’ve got wireframes together, they’re designed to show to the clients, obviously, and because they’re just wireframes we can say to the client, “You’ll need the latest version of Firefox or Chrome or Safari or something other than Internet Explorer 6,” essentially. Then you’re OK with things like hover state in CSS for something other than just links.

But if you’re trying to do something more complicated then you want a JavaScript event to do something with, then that’s where you’ll be finding jQuery, in this instance, as the thing to go with anyway.

Adam: So Richard, we need to address this. Phil also took a poke at you in Twitter. There was an example in your presentation that talked about Phantom Menace as a favorite film. And there was something about a loss of respect for the presenter. I know you wanted to address that.

Richard: Yes, Phil was under the misapprehension that the fictional user we were showing in our wireframe, a user called Amidactio, was me. Our user Amidactio was down as having Phantom Menace as his favorite film, but also such musicians as Bon Jovi as a favorite musician.

Now, I’m not saying there’s anything necessarily wrong with Bon Jovi, although Phantom Menace, that’s a different question. So it wasn’t me who has Phantom Menace as a favorite film. It was our fictional user. So I need to make that clear. Thanks for giving me the opportunity.

Adam: Absolutely. Understood. We talked a bit about production code and folks were wondering about that transition from these kind of interactive wireframes that you were showing them how to make and how they may or may not end up as production code.

The folks at Expeditors International wanted to follow up on that and they want to know, “How do you avoid having a developer look at a rather sophisticated looking interaction and then just saying, “Well, this works. Why wouldn’t we just reuse the code?”"

Richard: The flippant answer is, “Hire good developers.” That’s kind of the only answer in a way. I mean, the code that you as a UX designer put together using JQuery might be suitable for production or it might not. It shouldn’t be our job to make that decision. It’s just our job to get the design working or tested with users.

If that ends up in production code, as far as I’m concerned that’s kind of none of our business in a way, apart from our job as a user experience designer to have some say in the user experience. There is some degree of, I think, responsibility a UX designer might have as wanting the performance to be good, certainly wanting it to be good in terms of actually making the performance good. That goes to people who are experts at that.

So really the answer is that a good front-end developer should be able to make that decision as to whether the code is suitable or not. It is, of course, easier, in some cases, just to nick a function and use that in the production code. But the chances of it really being bulletproof, I would say, unless you’re a particularly good coder in the first place, are fairly slim, certainly in my case.

Adam: So there was a question about PolyPage, wondering if, in your experience, UX designers typically find that easier to use than jQuery templates or just vanilla, if else, in JavaScript.

Richard: In our experience yes, people who use PolyPage – and that includes us at Clearleft – find it easier because you can just put a piece of logic in there by simply adding a class. It strikes me as being a lot easier to just add a class to a DIV and have the logic just work for you.

So the typical example that we’re talking about there is – the way PolyPage works is if you add a class of “pp_notes” then you get a toggle magically appear at the top of the page called Notes and you can use that to show and hide anything which has that class. Basically, in this case, you’re probably showing and hiding notes. Or just simply by adding one class to each DIV or paragraph or whatever you want to call your notes.

So it makes it very easy for us, rather than writing functions, to do that. It’s already been done for you.

Adam: OK. Cristobelle asks a question. She wants to know if changes set by a jQuery, if they persist upon page reload.

Richard: The simple answer is no. If jQuery has added or changed the state of something it’s shown when previous it was hidden or it has paragraphs or lists or changed the mark up in any way and then you hit reload, it goes back to whatever the state was before. Unless that piece of jQuery is also doing things like setting a cookie for that state at the time, in which case you’re introducing state by jQuery. But it doesn’t happen automatically, you have to get it to do that.

It leads me onto a point that I wanted to make. In the seminar I was keeping things nice and simple when I was talking about event handlers, adding a click event handlers to, say, a link so that when that link is clicked you can get it to do something other than go to a new page. You can get it to hijack that link and get it to fake a piece of Ajax.

If, for some reason, you’re getting jQuery to add in more links automatically, then those new links that you’re adding, they won’t actually get that click event handler click on its own. The click method just applies to everything that’s there already on page load.

However, there’s, with jQuery 1.7 – didn’t really intend to go in lots of code in this podcast, but it’s quite an important thing. So jQuery 1.7 introduces the on method, which is basically the new way of doing all event handlers. So it would be along the lines of instead of click open set brackets, you got on open brackets with click inside saying that’s the event I want to use.

It’s all there in the documentation on jquery.com and jqapi.com which is an alternative source of the documentation. But it’s the on method that you want to look for then. And you can just replace where you had click before. It’s just something they introduced fairly recently to deal with that situation where event handlers can be added on the fly rather than just on page load, which was the situation that used to be.

Adam: Well, OK Richard, thanks for circling back with us, certainly appreciate it.

Richard: You’re welcome.

Adam: And to our listeners, thanks for joining us. Goodbye for now.

The term Lean UX is bandied about quite a bit these days. Along with it, there seems to be some confusion as to whether this is just a buzzword, a new way of working, or simply a new description for what people in the user experience realm already do. Jeff Gothelf of The Ladders is a champion of Lean UX, so Jared Spool sat down with him to find out what Lean UX was all about.

Taking inspiration from Lean Product and Agile development, Jeff describes Lean UX as a way of cutting down on the heavy documentation and getting deliverables out of the process. This process gets the entire team into a collaborative environment and helps to knock down silos, all while keeping the users top of mind.

One of the core ideas behind Lean UX is viewing each design iteration as a hypothesis. Jeff says you need to validate the hypothesis from both a customer and business perspective. The more wrong paths you can uncover quickly, the less time you are pursuing the wrong hypothesis. This makes Lean UX a way to integrate user experience into an Agile process.

Tune in to the podcast and hear Jared and Jeff go in depth about the Lean UX method. And if you want even more on Lean UX, don’t miss Jeff’s virtual seminar, Lean UX: Getting Out of the Deliverables Business on Wednesday, December 7.

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

This is a sample of Lou Rosenfeld’s, Beyond User Research, from the 2011 IA Summit.

UX professionals have made a lot of progress in large organizations. Companies realize the importance of connecting with their users more and more. User research is becoming firmly rooted as companies strive to produce better products and services for their users. But user research itself can be narrow in focus and full of biases. Lou Rosenfeld of Rosenfeld Media, suggests that by breaking down the silos that exist between other research practices, we can create a complementary research experience. This will produce even better analysis and therefore, better products as a whole.

In an attempt to map out organizational structure, Lou offers a set of dichotomies. In terms of research, web analytics folks and UX professionals both bring important insights to the table. But they focus on different things. It’s this separation of insights that lead to the silo effect. Even though these insights would be completely complementary, the cross-pollination that would require this enhancement to the research often is not occurring.

It boils down to the differences in how people think. User experience people tend to shy away from quantitative data and take a more qualitative approach. Neither is a bad approach to take, but the differences between empathetical and analytical thinking, for instance, provide vastly different results.

By combining the efforts of these different practices we can arrive at tremendously useful insights. For example, Lou explains that by adding data to typical personas you can enrich them and enhance the design process. The personas may then align closer to the analytics data simply by adding what they would search for, resulting in a deeper understanding of your users.

Lou is presenting a UIE Virtual Seminar, 8 Better Practices for Great Information Architecture: Closing the Findability Gap on November 3. There are new opportunities for Information Architects to add significant value to projects. There exist new metrics for measuring engagement with your site visitors. These measures will guide you towards design decisions that let your users find what they’re after. Learn more about Lou’s seminar.

This podcast was recorded at the 2011 IA Summit. For details about next year’s summit, visit IAsummit.org.

[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Lou Rosenfeld: We have this fragmentation problem which I’ve already said things live in silos not just content but now insights that ought to help us figure out what to do with content and other design issues.

We’ve got differentiation. We don’t really understand what that CRM stuff is about. I’ve never seen one of those things before. Yet, I sense it might be good to look at if I’m doing any kind of design work.

And then most importantly this combinatorial issue, the synthesis of all those insights into something that approaches an organizational brain, an organizational or institutional way to make smart design decisions.

So that’s kind of what we’re facing. In my limited experience with this, I’ve tried to map it and I think a lot of us are pretty good at doing this sort of mapping of an organization and how it works. It’s almost like the same sort of urge that we use, that got us into doing things like site maps and wire frames.

I came up with a bunch of dichotomies. I couldn’t map it so let me run through some of these dichotomies. What I’m finding is, there’s a lot of people who are really good at figuring out what is going on and there’s a lot of other people often not the same that are really good at figuring out why those things are going on.

So for example, people draw on information that comes from analytics research, the quantitative data. They may learn something really interesting. But it’s all behavioral stuff. They don’t really know what was going on in a user’s head.

They can draw up and infer interesting hypothesis but they can’t test those hypothesis. That’s something that people who are really good at doing user studies for example like a lot of us, are really good at.

We, on the other hand, aren’t always so good at knowing the right questions to ask. And I’m kind of going to start focusing a bit on two areas of practice, web analytics and user research but these are the ones I know best.

This is really even more complex when you introduce all the other perspectives but let me just focus on these two. A lot of web analytics people can tell you what is going on. They can’t tell you why. A lot of us can tell you why things are the way they are but we don’t know what to test necessarily.

We don’t have the right questions to explore without the data to help us figure that out. There’s a whole kind of a breakdown between qualitative and quantitative people. I love this diagram with the two brains in there. I wish I had come up with it.

I’m not sure how well you can read it but numbers versus emotion, analysis versus empathy, the brain versus binky? Is that what it is? So you know, we have different ways of looking at problems, different ways we try to solve problems and we often are comfortable with different types of data or evidence to help us solve those problems or at least to help us understand what the problems might be.

So that’s a big breakdown. A lot of what I’m saying right now, I’m trying to make a point and by making that point, I’m going to over generalize quite a bit but I think a lot of us kind of would fall into one of these categories.

I don’t know that anyone is equally comfortable with qualitative and quantitative data. I’ve met very few people that seemed to be able to do that. In many cases, I think some of us make for qualitative studies because we’re really uncomfortable with quantitative data or vice versa. It’s just the nature of how our minds work and what we’re comfortable with.

A lot of us are in the business of making sure our organizations reached their goals. Web analytics people as an example, they express goals as KPI, things that are measurable, key performance indicators.

A lot of us in this room have been trained to think more on behalf of the user and what their goals are and how to identify them and make sure they’re using them. Sometimes those things are very easy to mesh together especially in commerce sites for example. Often, they’re not.

We have to resolve these things but we’re not always so good at it because usually, whoever is making the decision has a bias in one direction or the other. In effect they’re thinking with half a brain.

I think a lot of us are really good at measuring the world that we know. Certainly, again, on the analytics side, you start with your KPI based on metrics and you say, “I’m going to look at all that data and figure out whether we’re performing against the goals that we’ve set out for ourselves as an organization.

Are we doing well? Are we not doing well? Contrast that with looking at data for patterns, looking at data for things to emerge that were unexpected. That kind of emergent data analysis is really looking to learn about the world we don’t know and therefore we don’t know how to measure.

And then yet another, I’m sure there are more dichotomies. There’s a breakdown between the comfort level and understanding of statistical data versus descriptive data and you could have people who make very strong arguments, garbage in, garbage out in both cases and they’d both be right probably in both cases.

But that’s not how they see it. Usually, we have a bias toward one direction or another. We like one, we like the other, usually not both but they tell us very interesting, but different things that often fit together nicely, as we’ll see.

I’ve tried to, like I say here, reduce this to a very over generalized, over simplified set of dichotomies that I’ve just gone through. This is just a summary of what those are. And this is just for two areas. This is just for web analytics and user experience.

But if you look at these, I hope what you’re starting to see is not just the differences but the fact that they come together quite nicely, that they’re very complimentary. That’s where that’s where combinatorial effect that’s coming in where the insights that one has fit quite nicely with the insights of the other.

Now, I can’t map this. It’s just not in my wheelhouse but I bet some of you could. What I’m really hopeful for is that someone like Alex Osterwalder who wrote the Business Model Generation book. Is anyone familiar with it? Fantastic.

He actually created and published it with a bunch of people, created a whole new business model around publishing just to do one book. Amazing. But he did a whole bunch of mapping of essentially business models. It’s over simplified but damn it, it’s useful.

We need something like that to take all these types of insights and put them together in a way that would be really useful for us especially making design decisions. So without a map, why bother even trying?

You know, if we can’t map, this is really a hard problem, what’s the value of jumping in? Well, for one, we can really, really learn quite a bit from each other’s data, right? So let me give you an example.

This is one of my favorite things in the world. It’s a little bit of site search analytics code little snippet of stuff. All you really need to know is that if you look at it, the orange stuff like “vincense plate” is what was searched.

There are a few other things that you can maybe figure out, an IP address so you know who it is, the time-date stamps, you know when it happened. The zero next to the last bit of information is how many search results there were.

Now, look at another line. Same time, roughly two seconds later, same IP address. Now they’re searching license plate and I got, I think it’s 146 results. Interesting, what’s going on here? Maybe they spelled it right but well what happens next?

Oh, it’s a different user and they’re searching on a real mouthful. This is a state government site and this user was searching that site for Regional Transportation Governance Commission. People search things that long? They know what those things are even called? Do you know what government agencies are called?

As you’re looking through this, I bet you each one of you are already putting on your analysis hats and saying, “You know, obviously typos are an issue. How would I fix that problem? Maybe I would turn on the spell check on the search engine.”

Now did they get what they wanted when they were searching on the license plate or not? You don’t know. Is that a common thing that people search and what about this mouthful in the last line?

Basically, each one of us should probably have a whole bunch of different ways of looking at this data and we would start ferrying very different hypothesis, just a couple of examples.

I think a lot of people from, to over generalized analytics community, would be wondering things like are we converting on license plate renewals. A lot of other people like me would be saying, “What are people searching for the most? Is it license plate coming up a lot?”

If so, are we giving that information very easily, are we presenting it on the main page so they can renew their license plate easily and so forth. So we look at the same data, tiny little snippet of data and we probably are all starting to come up with different conclusions or at least different hypothesis and thinking about what we do next differently.

What the next action would be could be very different if you’re looking at this as an interaction designer versus an analytics person versus a content strategist. Another way we can really benefit each other is by helping improve each other’s design tools.

So I grabbed an Adaptive Path persona and you know again, I love site search analytics but there are lots of other types of analytics out there that you can do this with but I threw some site search analytics data in there.

So you got your typical persona stuff, right? And then, why don’t we add some data? Wouldn’t that enrich in a new way “what does Steven search?” Now I can actually go to my analytics people and say I could use some of that data.

In fact, maybe my personas might match up well with your audience segments. Maybe you can start putting these things together in some new and far more powerful ways. We can really help tell each other’s stories.

I love this example. Adaptive Path again, Jeff Veen and a team were working on a product to make analytics data more easy to understand. I think it’s called Measure Map. Is that right anyone? Measure Map.

Google liked it. In fact, Google basically bought Measure Map but they really bought the team. And they’d already purchased the analytics application that they were going to make into Google Analytics but they wanted that team to work on it, to help tell the story of the data in a way that maybe someone from the web analytics world wouldn’t have thought.

Dave Gray, founder of XPLANE, and co-author of the book Gamestorming: A Playbook for Innovators, Rulebreakers and Changemakers, is known for his sketching and brainstorming techniques. At last year’s User Interface 15 Conference, Dave gave a 90-minute talk called Gamestorming: A Grammar for Creativity and Innovation. In light of the fact that Dave will be joining us for an October 20 virtual seminar, we’re presenting a sample of his UI15 talk for this podcast.

The cubicle is a staple in many modern workplaces. It came into existence to give workers their own individual spaces to do their work as efficiently as possible. The drawback to this is it all but kills collaboration and stifles creativity. Dave challenges the accepted idea of workplaces as factories. He suggests that moving toward modeling work as a “collaboratory” will help open the black box of design to others within the organization.

Gamestorming can allow collaboration to happen. It quickly gets a lot of people working together, sharing ideas, and getting creative. Words may be tricky because you’re not certain if someone has interpreted what you’ve said the way you meant it. The beauty of Gamestorming is it gets people to think visually and physically express their thoughts and ideas on paper.

Another technique that Dave talks about is Bodystorming. Instead of sketching ideas out on paper, with Bodystorming you physically act out an experience. One example that Dave points out is a group that was attempting to address the problem of disposable coffee cups. By actually creating a mock experience of waiting in line and then ordering your morning coffee, they were able to generate a number of ideas for improvements to the cup itself. These improvements in turn made the entire experience better.

You won’t want to miss Dave’s virtual seminar Brainstorming Games for Team Creativity–Gamestorming. Dave will showcase techniques that get the entire team involved in the design process. You’ll see how to keep the energy level among your team high and arrive at consensus and get results faster. You can add lifetime access to the recording of this seminar by using the promotion code GAMES.

[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Dave Gray: ..from a business perspective. Business people have a tendency to think of design as something that’s kind of a black box. “We have a department for that. We have a team that does that.”

And we typically want to kind of separate them from the rest of the organization, right? Because it’s kind of crazy and we don’t look inside the box that often, it’s a little crazy in there.

I mean, who feels like they’re in that box and the senior people don’t necessarily want to look in or know what’s going on, they just want good things coming out of the box? Anyone identify with that?

Because we’re in the box, right, we’re the design people. But what we’re finding more and more is that we can’t just do our design inside of our black box, we have to engage with a lot more people than we used to.

We have to engage with the organization, with customers, with other people in organization. I mean, raise your hand if you need other people who are outside of your team to get your job done. Yeah. I mean, almost everybody.

So this black box has to be something that we need to open up and that’s what Gamestorming’s about. It’s about taking those things that we do as designers and making them more accessible to groups instead of individuals.

So this is a woman named Elizabeth Gould. She discovered something called neurogenesis. Raise your hand if you learned in school that brain cells don’t regenerate. I learned that in school. You don’t take drugs, right, because if you take drugs, you’ll kill your brain cells and they won’t grow back.

Well, if you have taken drugs, I have good news for you.

[laughing]

Brain cells do grow back, and this woman, Elizabeth Gould, a researcher at Princeton University, discovered this in 1999. And it was an unexpected discovery, because there had been a lot of research done that proved that brain cells don’t regenerate.

Here’s the thing – almost all that research had been done on lab animals, who were kept in cages and they weren’t in their natural environment and they weren’t creatively stimulated at all. Basically it was like taking a prison population and thinking that it represents humanity, right?

So here’s a question I have for you – does this look like anything you’ve ever seen at work?

[laughing]

Right? OK, there’s my reveal. All right, so here’s the thing. If we wanted to design our workplaces to inhibit and stifle creativity, to kill brain cells literally, we couldn’t have done better than the modern office cubicle.

So this is one of the reasons I’m going to have you actually standing up and using your body today, because that’s part of what’s killing creativity is being in the gray box and trying to get your work done.

All these things were designed to make work as efficient as possible, not to make work as creative as possible. So we have to find ways to break down these barriers if we want to get more creative at work.

The model for work or the metaphor for work that we’ve been working under for a long time, and a habit that we have to break, is thinking of work as a factory. And, you know, think of it – in a lot of ways, we’re always mapping, processes we’re doing work flows. A lot of those kind of ideas, and I’m not saying that work flows and processes aren’t important, but they aren’t everything, right?

So we need to move from thinking of our workplaces as factories, even to the point where, “We’re going to make a creativity factory, and you’re going to be in charge of the initial thing, and then you’re going to be in charge of the next thing and the next thing,” and start thinking of them as collaboratories, where we have to get comfortable with a little bit more chaos and mash-up in the process, because that’s the kind of thing that helps creativity happen.

These are some snapshots that I took of people Gamestorming. This is just very simply a survey, except it’s done with sticky notes with a physical group in a room. So a very quick way to get a lot of people helping and participating and answering questions.

A couple of pictures of just people doing creative work, getting into the Gamestorming process. I mean, does this look like something you’d like to see more of at work? Raise your hand.

No? Come on, raise your hand, you liars.

[laughing]

OK, it looks a little crazy, it looks a little chaotic, and I’ll explain to you a little bit what these people are doing, but when we were writing the book, that’s actually a paper prototype of a toilet seat. Yes.

[laughs]

Alright, when we were writing the book, my co-authors and I convened about 50 people in a conference center to actually work on all the ideas and prototype all the stuff in the book. And I want to tell you a story of something that happened there.

50 people come together in a conference center, they’re staying there. They’re going to have basically two or three days with them. In the early stages we did a game called Poster Session, which we are going to do today together.

And the idea behind Poster Session is everybody makes kind of an infographic style poster that explains something that they’re interested in, something they’re excited about or something that they want to propose as a project, et cetera.

This guy, who’s not a designer, had the issue that he cared about, which was disposable coffee cups. Millions of us go to coffee shops every day, we buy our coffee in disposable cups, we drink our coffee and we throw the cups away.

Now, that adds up to a lot of waste and a lot of problems, because they’re hard to recycle and so forth. And here he was coming in, he said, “You guys have design skills, this Gamestorming stuff is about innovation and creativity. I don’t have the answer. I have the problem. The problem is we need better disposable cups.”

That’s what he thought the problem was. “I don’t want to blame the people who are throwing away the cups, there’s got to be something we can do to make a better cup that’s just easier for people carry around and use and re-use, instead of them using all these paper cups.”

So he said, “I challenge you to help me with this, help me do this.”

So the survey that I mentioned earlier was part of that activity. So he got some people with him to work on this project that he cares about, and they started by doing kind of a survey of like, “What’s your coffee experience like?”

They designed some questions, they had people answer the questions, and one of the things I heard from them was, “Doing a survey in this way was actually very helpful, because I got to see more of the thinking process, as people answered the questions with the sticky notes, than I would have if it was just an online survey. So we actually went and changed some of the questions and were able to adjust as we were getting feedback.”

Now, it’s not necessarily what you would do for a research survey, but for a quick and dirty getting a feel for things, and of course most of us do know what it feels like to go get a coffee in the morning, and most of us use disposable cups, that they were able to do that.

The next exercise that we did with them is something called Bodystorming, and this is a picture of people Bodystorming. Raise your hand if you’ve done this or heard about it.

Bodystorming is simply a kind of improvisational role play where instead of designing your product on paper, you actually design it by working it out with other people in real time, in real space.

So this person is the iPhone, OK? You can see the iPhone there. And we have the user. And these are people who are aspects of the application. This guy’s looking up whatever he’s going to be doing next.

So it’s a very quick way to prototype a system and really get a feel for how does it feel to interact? How does it feel? Get a flavor for it. And it’s a kind of a play that’s helping us figure out what’s on the other side of that? What’s the better iPhone look like? What’s the next generation look like?

We could play with those things and tweak them until we start to get a feeling for something that then we can go a little bit deeper on. So it’s a way of sketching. This is a way of sketching.

So the Betacup team, that was their name, this guy, Tony Daniels, he had actually named his problem the Betacup design project. So what they decided to do in their Bodystorming was they were going to set up a Starbucks, and they’re going to feel out the system. So they have barista, this is the Starbucks here, this is the asshole, see?

So they actually, what they did was they set up the Starbucks and they started role playing what it feels like to be in the line, to go through, to experience this, to try and figure out, “How can we fix the cup? What is it that we can do with the cup?”

And they came up with some pretty cool ideas, just by tweaking the system a little bit. And one of the things they discovered was, “Wow, it sucks to be in line behind the asshole, because he’s taking forever, he doesn’t know what he wants. You’re waiting in line, you’re waiting in line.”

So they came up with this idea where your cup would also be your loyalty card and your credit card and everything else, so you’d have your order built into your cup, so when you came to order, you could skip the whole line, you just put your cup at the end. They picked it up, they had your order in there, they had your loyalty program in there. All they had to do was swipe the cup and they could put it into the system and it would come out the other end with your stuff.

So there’s all these benefits to that, like you could pick up three or four cups from your co-workers, you know, and you wouldn’t have to remember their orders, because it would be built into their cup, right?

So they had actually kind of thought about a lot of cool benefits.

So after the event, a lot of these people that we had in were bloggers and social media people and so forth, so they actually posted about it on the Internet. “This is our Betacup Bodystorm, these are the ideas that we have.”

And it was, you know, people were reading it, people were like, “Oh, this is kind of interesting.” And who would be reading this but Starbucks, the VP of Sustainability at Starbucks saw the video. This is like a really rough, shaky, hand-held two-minute video of the, excuse my language, I’m saying it because it’s the language they use – “The asshole in the Starbucks line,” and the way they acted the thing out.

This was the guy they had on their radar. They wanted to get a meeting with him. They had wanted to get a meeting with him forever, and he called them.

Now, What’s interesting about this? Well, when you’re doing innovation work, you don’t know what you don’t know when you begin the project, so you’re learning as you go.

So first they thought, “We’re going to make a better cup, it’s all about the cup.” But then they started looking at the system, and they said, “Actually, what we need to work on is not just the cup but the whole system around the cup, and make the system work better.”

And then from there it became the social system. The thing that the Starbucks guy was excited about was not the particular solution that they had come up with. He was interested in the whole social engagement factor about how they got all these people connected to trying to solve this problem together, collaboratively. He was interested in the wisdom of crowds stuff.

So there’s actually now a Starbucks competition. It’s a $20,000 Betacup prize. They’ve already awarded it once. There’s winners and everything. This came out of just people getting into a room and not knowing what they were going to do together…

Story mapping is a way to build a model of user experiences. More than that, in the Agile context, it allows you to tactically plan for what should go into each release. It is a way to get everyone on the team thinking and talking about user experience. Getting people into a discussion mode starts to create a very collaborative environment.

Jeff Patton is a consultant and expert in Agile development. In his sold out virtual seminar, Story Mapping for UX Practitioners: Tying Agile and UX Together, Jeff outlined how to create a story map and how it fits into the Agile process. Jeff ran short of time to answer all the questions during the seminar, so Adam Churchill caught up with him to answer those remaining for this podcast.

Here’s an excerpt from the podcast.

“…A lot of the answers to selling [story mapping] is, to not, just get started. If people can see and physically engage with something big and something they can touch, [the answer is] to get it up there and get them to engage in it.

I’ve seen a lot of folks spend a lot of time trying to introduce the concept to people, trying to convince people it’s a good idea for them to do it. If you’re a user experience person, build one of these maps on the wall, physically in your area, and if you’ve got someone to collaborate, lead them over to it and say, “This is what I’m seeing happen. The person using our product is doing this, this, and this. And here’s where the real pains are.”

And when I’m working with people on these things, I really watch closely for their body language. I watch for people to start to point and start to use words like “here” and “there” and “down here” and start to engage with it. I’ve found that these things end up selling themselves. Trying to sell it doesn’t work.

There are a lot of products that are hard to sell. And I think I’ve heard from people talking about TiVo this way. TiVo has a hard time telling people what their product does and why you like it, but you use it and you know why you like it. And it does better being sold via word of mouth, or maybe you just have to experience it…”

Tune in to the podcast to hear Jeff address these points:

• Who do you have build the story map?
• How do you get the right people in the room?
• How do you story map when you’re designing with multiple personas in mind?
• How many users should you interview prior to building the story map?
• How do you ensure non-functional requirements don’t fall through the cracks?
• How do you scale this process to different-sized projects?

Do you incorporate UX into and Agile environment? Share your thoughts with us in our comments section.

Recorded: September, 2011
[ 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 episode of the SpoolCast. Jeff Patton recently joined us for a Virtual Seminar titled “Story Mapping for UX Practitioners: Tying Agile and UX Together.” Now, the seminar sold out, and the activity we were watching in both the Adobe Connect room as well as the Twitter stream was a lot of fun to watch. Lots of good comments, lots of good questions.

Jeff’s seminar spoke directly to folks working in an Agile environment who struggle with knitting user-experience design practices together with the iterative process they work in.

Jeff’s graciously offered to come back and tackle some of the questions we didn’t get to address in the seminar. If you didn’t listen to this particular seminar, you can get access to the recording in UIE’s growing User Experience Training Library, which presently has over 70 recorded seminars from wonderful topic experts just like Jeff Patton.

Hello, Jeff. Welcome back.

Jeff Patton: Hello. How are you doing today?

Adam: I’m doing very well. We had a lot of fun yesterday, didn’t we?

Jeff: We did have a lot of fun. We packed a lot into a short amount of time.

Adam: Well, let’s get right to it. For those who weren’t able to join us yesterday, can you give them an overview of what we did talk about?

Jeff: Yeah. My goal was to introduce people to a practice, something that I’ve been doing for a lot of years and something that’s growing in popularity. A lot of people are doing this. We focused on story mapping. And for a UX person, I’ll tell them story mapping is a way to build a map of user experience, something like task analysis.

I’ve seen lots of flavors of task analysis that yield sort of a map that looks like a story map. But if you’re working in an Agile context, you’ve got to build a backlog and come up with a bit of a tactical plan for what we’re going to put into a release and how we break it down into bits and pieces to build.

So we talked about that idea of a story map and how it sort of plugs that hole. And the big benefits, for me, are we’re able to tactically plan and execute like we need to do in an Agile context, and we’re able to get everybody thinking about user experience. So, for me, this is why it’s a bit of a bridge-gapping practice.

So during that talk, we talked, basically, about what an experience map was and how to quickly create those. And then we went into a lot of depth about what user stories are and what they aren’t. And one of the biggest misconceptions, or one of the questions I hear constantly, is “How do I write good stories?” One of the points to make about stories is they’re called stories because they were meant to be heard. They were meant to be discussed and talked about, and how they’re written isn’t as big an issue as what people talk about and what pictures they form in their heads.

Definitely, we have to write things down, but the form that we write them is really contextual. Then, when we combine these ideas, of the idea of a story or the things that we talk about and the idea of something like an experience map that lets us see the big picture, that’s where we get the story map.

After introducing that idea, we talked about the basics of how you build a map. Start by getting the big picture, what I would call the backbone of the map, down, and some of the details, then how we pile in lots of details. And then, where we ended up with was talking about how we use that simple square structure of a story map to carve out or slice up a product into incremental product releases.

This is where I think the shape of the map shines. It arranges information left-to-right based upon users’ experience and decomposes it top-to-bottom into parts. And when I slice it left-to-right, I start planning or thinking about releases in holistic product slices. And I get better releases. I get both thinner releases, releases that have less in them, and more comprehensive releases, releases that really satisfy users’ needs.

That’s where we ended up. There was a last tail-end section that I came into the seminar hoping that I could fold time or do a lot more than we did. And the section we didn’t get talked about tactically working with story maps, and tactically working with stories for that matter, during Agile-style iterative and incremental development.

Adam: Well, let’s get to some of those questions that we didn’t get to answer yesterday. There was a question about, how do you sell to the group, and how do you get started with that group?

Jeff: A lot of the answers to selling it is to not, to just get started. If people can see and physically engage with something big and something they can touch, it’s to get it up there and get them to engage in it.

I’ve seen a lot of folks spend a lot of time trying to introduce the concept to people, trying to convince people it’s a good idea for them to do it. If you’re a user-experience person, build one of these maps on the wall, physically in your area, and if you’ve got someone you’ve got to collaborate, lead them over to it and say, “This is what I’m seeing happen. The person using our product is doing this, this and this, and here’s where the real pains are.”

And when I’m working with people on these things, I really watch closely for their body language. I watch for people to start to point and start to use words like “here” and “there” and “down here” and start to engage with it. I’ve found that these things end up selling themselves, and trying to sell it doesn’t work.

There are a lot of products that are hard to sell. And I think I’ve heard from people talking about TiVo this way. TiVo has a hard time telling people what their product does and why you like it, but you use it and you know why you like it. And it does better being sold via word of mouth, or maybe you just have to experience it. Does that make sense?

Adam: It does. It does. And yeah, there’s a list of products like that. Twitter would be, I guess, another good example. You don’t really understand what it is until you use it.

Jeff: Yeah. Yes. Something like that.

One of the key points out of yesterday’s discussion was, and several people pinged me afterwards, and I’d asked them, “What were your takeaways from this?” And I strongly made the points that it’s not what’s written on paper that matters; it’s what’s in people’s heads that matters. We’re working really hard to collaborate together and form shared understanding in people’s heads, and that’s a value that people don’t focus on much, and it’s a real benefit we get out of these big, simple models on the wall.

Adam: So, Jeff, who do you have to have in the room to build the story map? Do you involve clients, the development team, the user-experience designers? Who’s in the room?

Jeff: What’s interesting about a story map is–well, I’ll go back. I’m lazy. I don’t want to build multiple things. A story map, initially, for me, is about thinking through and understanding user experience. Subsequently, it’s about explaining user experience to other people. And then when we start breaking things down and planning, it starts to be, well, about that, about planning and about tactically figuring out how we’re going to get this product built. And there’s different audiences for each one of those activities, as you can imagine.

When initially using the story map to kind of understand what I’m doing, maybe this is a habit I picked up from working in an Agile context. I like to pair, and I’ve seen a lot of designers that focus on pairing. And there’s an old Yogi Berra quote: “Pair up in threes.” So I like these small groups of two, three, sometimes four, to think through and build things. It’s a single-pizza-sized group. These are the people you want to pull together, that have some understanding, to initially build the map.

Once you’ve got a map initially built or initially structured, then I want to start to pull in other people with different kinds of experience, different sorts of subject-matter experts, and I want to vet my understanding with them, and I want to add to it and change it and richen it up. If, by building the map, I see I’ve got holes, and I’ve got to go out and do more research or learn more, then I might do that and come back and fatten up the map that way.

Then, once I’ve got a little bit of a map that starts to explain a product, oftentimes we’ve got to share that with other stakeholders or share the vision of what we’re getting with this product with other people. So we’ll bring people in. And the purpose is not to add to the map or validate it so much as use the map to explain, “This is how we see people using this new product, and this is the flow of that use, and this is how it breaks down into pieces.

Then, downstream, when we have to start taking this apart and planning it, that’s when we want to pull more engineers and more QA people, other people that know, tactically, what it’s going to take to get this thing built, into the room.

So it’s not if all those other people should be involved. It’s more of a when they should be involved.

Adam: Any tricks to helping you understand if you’ve got the right people in the room?

Jeff: Adam, looking back, there was a question. And I’m going to repeat somebody’s question. What if a key stakeholder, a product manager, checks out of the process and starts thinking, “That’s not my job. It’s engineering’s job”? And the reason I’m bringing them up is, how to tell you’ve got the right people in the room, sometimes they sort of vote with their focus, and if they’re losing focus, they may very well be the wrong people.

Now, getting the right people in the room. One of the things I’ll focus on is a team, I leverage a mantra and often draw a Venn diagram that looks at these three concerns: valuable, usable, and feasible. Valuable to the organization building the product, usable to the people that end up using it, and feasible to build.

Now, strictly speaking, if it were just building a map of user experience, I could just focus on people who understand users and how they work with things, and the right people to initially build the map could be just user-experience people. Some organizations just have business analysts that take care of that capability.

But I want people in the room that are also thinking with their business hats on and really gaining some empathy and understanding for users. And while they may not be contributing to the map, I want them in the room.

Then there’s a dysfunction I commonly see and everybody commonly sees. A business comes up with a great idea. User experience works out the details of how users need to work with it. And then we produce all those details for engineering and engineering says, “That’s going to take a long time to build.” And then we go back to the drawing board because it far exceeds the budget that we’ve got.

Having engineering in the room earlier on gives us early warning for that, and oftentimes gives us perfectly reasonable ways we could do things that would be cheaper, more cost-effective to build and still satisfies users and still reaches the business needs.

The right people in the room for me is a balanced team that includes someone who understands some engineering concerns, someone who understands business concerns, and initially, when we’re building out the experience, people that deeply understand users’ experience today and then the experience we’re striving for with the new product.

Adam: Edwin wanted to know how you do the story mapping when you’re designing with multiple personas in mind.

Jeff: That’s a great question, and I’m glad you asked it. I’ll answer another question first, or point out another concern first, and then answer it a little bit more squarely.

There’s a standard user story template that’s used by a lot of people in Agile development. It’s the, as a kind of user, I want to have something do something so that I get some benefit. And that template, in the “as a,” it seems to call for one answer there. And for me, I’m always looking at the product from the perspective of multiple personas or different kinds of people that would use the same functionality and have different concerns when they’re doing so.

Edwin’s question was, how do you story-map when you’re designing with multiple persona’s in mind? The story map is about the product and it’s about the experience. Gosh, it’s a little bit about both. You need one map because you’re going to build one product.

Initially, to get the shape of the map in place, I’ll think through it from the perspective of one persona and get the backbone and the basic shape of the map going, and the basic shape of the map starts to reveal the shape of the product. And then I’ll grab other personas with different concerns and walk through it from their perspective and see if it breaks it, changes it, does other things.

And to remind people that this product is for multiple personas, at the top of a story map, we’ve got big activities that break down into users’ tasks, and those break down into the tactical details of what we might build. Right above those activities or above sections of the map, I’ll post those multiple personas or hang them there, so that people can see, clearly, these big activities in this map serve these different personas, and they have different concerns.

Let me give one more detail here. Some folks that are building an application where multiple personas use the same functionality will go through and tag all the stories. They’ll tag their personas each with different-color dots, let’s say, and then go through and tag all the functionality that’s particularly relevant to one persona with that color dot.

This does a little bit of an analysis so that we can see that for these personas, they’re really concerned about this functionality; these personas are concerned with this other functionality. And we can see a bit of overlap that way, too.

Adam: So when you’re doing that research, how many users do you need to interview to know that you’ve got what you need to build the story map?

Jeff: Research is a troublesome thing for me. I’ll be honest with you. I came to doing what might be more rigorous user-experience work in about 2001. Before that, I was just spending a lot of time with users and building stuff, and I didn’t know that I was doing research. I would spend a lot of times with users using the software. Maybe I didn’t know that was contextual inquiry. So it wasn’t so rigorous. It was after 2001, when I dug in deep, that I started realizing, to be rigorous, I probably should be doing a few other things.

Now, if I fast-forward, I often find that organizations don’t do any research, because to do it rigorously takes a lot of time. So they go back to doing what they were always going to do, and they follow what I heard Jared call the MSU process, or “making stuff up,” only Jared didn’t use the word “stuff.”

Adam: [laughs]

Jeff: So, how many users. In working with some folks, for every distinct audience segment or role, I’ve heard general guidelines of three to 10 people. And it depends on how much variation there are in those roles, so if I were covering half a dozen roles, I might be interviewing lots of people.

However, one of the strategies I leverage when initially building personas and initially building story maps is to leverage tacit knowledge that’s in the room. Pruitt and Adlin talk about building assumption-based personas, and I build assumption-based story maps and assumption-based personas. By initially building a story map, we make clear what we do and don’t know, and then we can look back at this and say, “Gosh, where is our information hazy?”

Then let’s design a research plan that helps us not just learn about people. Since we’re modeling work or activity with a story map, my research plan can be very focused on the specific activities where I don’t know anything. And more importantly, if we’ve got businesspeople in the room, we’re looking for this intersection between stuff I don’t know and stuff that matters a lot, and that’s where we’re going to focus. [laughs]

Adam: Jeff, just a couple questions on nonfunctional requirements. And Ariadna asks, “If story mapping mostly concerns itself with functional requirements, how do you ensure that some nonfunctional requirements don’t fall between the cracks?”

Jeff: That’s a great question, and that’s a great question that’s applicable in any software-development process or any scheme to try and get your head around what requirements are for what to build.

So I don’t know if I have any fabulous answers. And one of the shortcomings sometimes with user stories in general is, I mentioned the initial idea of user stories, where you write down something and have a discussion, and out of that discussion comes the details of specifically what to build, and over time, the goal is to get smaller and smaller stories so that we could build smaller and smaller things.

When you look at nonfunctional requirements, the things that automatically pop to mind for me are things like scalability and performance and usability and all those things that people call “ilities.” Security, which doesn’t end in “ility,” that’s one of those also. These are big, cross-cutting concerns. I don’t just implement the scalability story and call it done. They’re quality characteristics of the product, just as usability is.

You don’t measure usability on a single check-box. It’s not necessarily sensible to if we’re concerned about usability of someone accomplishing a whole task.

So, let’s track back. Those sorts of nonfunctional requirements, yeah, we don’t want to lose them, but they’re cross-cutting. They’re big. I find that the story map helps me a lot because they’re often activity-centric, and the story map reveals what those are. So I might have particular scalability and usability and performance concerns in one particular activity and a lot lower scalability-usability-performance concerns in another. One of the things I’ve done personally is go up to that activity level and document or record stuff at that level.

As Ariana asks, how do you keep them from falling through the cracks, or falling through the story so to speak, oddly, it’s not easy to make them stories. They become concerns that we constantly pay attention to during development. We constantly do things to measure usability, maybe by testing, measure scalability by testing, except different kinds of testing.

Then, as we encounter problems, that’s when we get these more emergent, tactical stories that we inject to fix things or make things better. I document the concerns up at the activity level, and I would pay close attention to them during development and inject stories to correct problems as I find them.

Adam: One of our attendees acknowledges that he understands how you break stories into smaller chunks and chunks that you can develop in shorter time frames, but how do you do the same with those usability tasks that encompass full systems, like ease of use?

Jeff: [laughs] I’m looking at Eduardo’s question, and he also has a cool term after that. He says “confusability,” which is a term I’m going to use from here on out. [laughs]

Usability is a nonfunctional requirement. It’s a nonfunctional requirement sometimes. Some people are more focused on the technical nonfunctional requirements, but things like usability is a strong one. And just like other nonfunctional requirements, they’re big. Like Eduardo points out, they’re not localized to a little story.

We have to look at them as a cross-cutting concern. And it’s during this iterative and incremental development, we have to keep asking, “Is this activity usable?” And we add more stuff to it: “Is it still usable?” And we add more stuff to the software: “Is it still usable?” We keep checking that stuff over and over again.

And exactly how and where that goes in Agile software development, and exactly what story card it gets written on, well, there’s no set answer for that, and there’s no one story card it goes on, and it’s not so simple. I find that you’ve just got to keep your head engaged [laughs] while you’re doing this stuff. And again, back to the previous question we talked about, I like documenting those concerns at the activity level, and I like testing for those concerns at the activity level.

Adam: One last question, Jeff, and I know that you and I talked about this one as we were kind of mapping out this podcast. And it’s a bit broad, possibly vague and tough to answer out of context, but I’m going to ask you to give it a shot because I think it’s important for our audience. This technique of story mapping, how do you scale it to different-sized projects?

Jeff: [laughs] When we were talking ahead of time, I winced a little bit, because I get asked this question all the time. I find that different people who ask “How do you scale?” mean very different things.

So when we look at scale with respect to different-sized projects, I hear some people mean we have a lot of people working on this project. In some contexts a lot of people means 20, and in some contexts a lot of people means 200. I know some organizations where they put 20 people on the project, but those 20 people are spread across five different countries.

Scale, for them, isn’t big in terms of number of bodies; it’s big in terms of number of time zones. I hear people talk about scale in terms of how big the product is: “This is something that’s going to take a year-plus to build, and it’s going to take dozens or over 100 developers to build it.” Scale means a lot of different things to different people, and it has to do with size of teams, size of product, geographic distribution, lots of other things.

So, given all that, given the question, my first question is usually to ask people back, what do they mean by scale? What I tend to find, though, is, for big products, for instance, it becomes difficult to build a story map for the entire product. That’s tough.

I’ll find I’ll end up building a lot of local story maps. We’ll break a big product down into separate problems and then map that problem and look at a single experience or a single activity. And I might create a big map for the entire product, but create it at a higher abstraction level. And it becomes more informational. It becomes not tactical. I don’t use it to find the detailed stories to push down to individual teams. Rather, I use it as some way to connect individual pieces that are going on with different teams or different groups of people.

And then one of the questions we answered in the online seminar and I always get asked, what about geographically distributed teams? That’s always an element of scaling also.

At the beginning of this, we talked about these different activities that revolve around a story map, and one of them is initially constructing it and filling it in and doing some planning. I find that nothing beats getting a core, small group of people to initially build that map, and getting them together face-to-face to do that. And even in big, geographically distributed teams, it doesn’t work to get a big group of people together anyway to do it. Get a smaller group of people together, and then the problem becomes, “How do I socialize that with a lot of people?”

And you get excellent story-map visualization practices, like Todd Warfel’s Task Analysis Grid. I don’t want to claim Todd Warfel’s practice as a story-mapping practice, but gosh, that Task Analysis Grid is a perfect representation of a story map that also conjoins a lot of the missing context that’s not always in a story map, like users and where they’re using it and pain points. There’s a lot of great things in that.

If we’ve got a large team, oftentimes it’s a small team that builds the map, and oftentimes we then need to build something that’s more of a design-communication version of a story map, to share that with other people.

Adam, I’ve hit a number of different elements of scaling, and we could probably go deep into that for a while, but it’s a sticky subject.

Adam: Well, Jeff, thanks very much. It was a lot of fun, and I appreciate you circling back with us. To everyone listening in, thanks for joining us and for your support of the UIE Virtual Seminar program.

Mobile is the “hot topic” these days. It’s increasingly at the front of designers’ minds. In a world where the power and capabilities of the device in your pocket are so great, the possibilities become somewhat astounding. The mobile landscape is changing so rapidly that it makes developing a formal strategy to “figure mobile out” all but impossible.

Luke Wroblewski is at the forefront of the mobile design movement. He suggests that it’s better to put something, anything, out there and see how it fares. Excessive planning in the mobile space leads to missing opportunity after opportunity. Taking advantage of the market as it is today and the capabilities of these devices can lead to the refinement and evolution of your product.

Luke will be conducting a full-day workshop full of his thoughts on mobile, including why you should design for mobile first, at the User Interface 16 Conference, November 7-9 in Boston. Learn more about Luke’s and the other 7 full-day workshops at UIConf.com.

Here’s an excerpt from the podcast.

“…today, [mobile] devices have a lot of constraints based on the ergonomics. They’ve got a small screen. In many situations, you’re using them in environments where there’s other stuff going on. You’re not hunkered down at a desk for an extended period of time.

You may be at home on the couch watching TV, or you may be in a line somewhere, or passing some time in, hopefully, not the car. So there’s these constraints. Low bandwidth is another constraint. And when you use the devices, you familiarize yourself with what those constraints are.

But there’s also a lot of opportunities in terms of capabilities. And if you use lots of apps, you can see, how are they using the accelerometer? What have they done with front and rear-facing cameras? How are they using location in order to deliver information? How are they using the video port, the camera, the audio input? All those things can open up new ideas about how to take advantage of those capabilities in your service.

This is a device that you can use pretty much anywhere and everywhere. You have it with you all the time. Coverage of networks is way better than it’s been. And so, through the fact that you have it with you everywhere and anywhere and you can pull it out and access a network and access assets, all these new use cases emerge that you didn’t have before…”

Tune in to the podcast to hear Luke answer these questions:

• What is the alternative to sitting and planning your mobile strategy?
• Where should teams start to familiarize themselves with mobile?
• Is there an advantage to playing with as many apps as you can to learn about the interaction design?
• What are some things that make good mobile design stand out?
• What is the benefit of desktop operating systems emulating features on touch-based devices?
• How is multi-platform emergence affecting approaches to design?

Do you design for mobile? Share your thoughts with us in our comments section.

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

Full Transcript.

Jared Spool: Welcome, everyone, to an episode of the “SpoolCast”. Today I have the amazingly awesome Luke Wroblewski, who is going to be speaking at UI16, our User Interface Conference.

It’s coming up this November. He’s going to be giving a full-day workshop on designing for mobile, a really hot topic. And he is the guy I know that knows the most about mobile, and I’m very happy he’s here today.

Hello, Luke.

Luke Wroblewski: Hello, Jared. Thank you for having me.

Jared: Thanks for being here. So let’s just get into this. I’ve got all these clients now, who are pushing hard on their mobile, and they’re really trying to get there, but it’s really hard to figure out what to do right.

There are some crazy things that people have been trying to do. What are some crazy things that you have seen organizations do with their mobile implementations, particularly organizations that should have known better?

Luke: If they’re doing small, crazy things, at least doing something, I think that’s OK. The biggest issue I’ve seen is people running around and making PowerPoint deck after PowerPoint deck, trying to figure out their mobile strategy.

Jared: I saw that! I saw a guy on the plane. I’m sitting in the aisle, and then there’s someone in the middle, and this guy’s in the window, and he is editing up a PowerPoint deck of a mobile app.

And then, every 20 minutes, taking his laptop and passing it to the woman in the window behind him. [laughs] And then they would have some conversation, and then he would come back and he’d make more changes to it.

Luke: Wow. So there you go. And real-time, on the plane, even.

Jared: On the plane. [laughs]

Luke: It’s gotten to the point that I make this joke when I go and talk, especially at corporations. I say, “The worst thing you could be doing is just sitting around making PowerPoint.”

And pretty much inevitably, I always get this nervous laughter and someone coming up to me after the meeting: “You just nailed what’s going on over here! How did you know?”

[laughter]

Luke: I know because it’s pretty much what everybody’s doing.

Jared: Wow. And so what’s so nutty about that? On the surface, it sounds like a great prototyping tool.

Luke: [laughs] Well for building an app within it, sure. But when you spend all your time trying to imagine the future of mobile and planning accordingly and not taking a move until you’ve got everything nailed, then you’re just missing opportunity after opportunity right now.

And frankly, if you look at the space, I think it’s changing so dramatically day after day that any strategy, long-term, you put together is likely to get pretty disrupted.

Just looking at the past few weeks, right, we had HP getting out of WebOS, killing their tablets. We had Google buying Motorola. We had Steve Jobs resigning.

It was just bombshell after bombshell after bombshell in terms of what’s going on in mobile.

And so I think, when you get in this mode of all you’re doing is planning and things keep changing on you, you just keep planning, planning, planning; you never actually do anything.

So what you’re describing, where the guy’s actually designing an app, in whatever prototyping tool he needs, I think that’s great.

My concern is more along the lines of, “Hey, we’re planning out this large architecture. Hey, we need this long-term road map.” While I’m not completely ragging on planning, I think it’s very, very possible for organizations, especially bigger organizations, to just get stuck in that phase and never get out of it.

Jared: Yeah. So the alternative is what, then?

Luke: The alternative is just to put something out there and see what happens. If you actually look at the big companies that are currently doing well in mobile, that’s what they did.

So I keep hearing stories of a small, rogue, or interested team just went out and made an app or a mobile website, and all of a sudden it started taking off, and now that has gained a lot of momentum in the company and they’re taking off from it.

So one of the, perhaps, biggest examples is eBay. eBay was one of the first ones to pull together an iPhone app. And that was essentially a product manager, designer, and they worked with outside contractors just because they were really interested in it and wanted to make something there.

And you look now; eBay has 50 percent of mobile commerce in the US, and 70 percent of that is coming from their iPhone app.

At least as far as I hear the stories, I wasn’t there, obviously, this wasn’t some huge effort in terms of strategy and planning. It was rolling up your sleeves, making something and getting it out there.

I heard a similar story, for example, from Expedia. For a long time, I used Expedia, the travel site’s mobile app as an example of “Look at how focused their mobile experience is compared to their desktop Web experience.”

And I heard from someone after one of these talks that that app was created in their R and D Department by, again, two or three guys who were just really interested in, passionate about the space, and now they’re taking a lot of what they learned from there and applying it to the desktop and other places.

So this “just roll up your sleeves and do something,” I think the type of market it is and the type of environment it is lends itself a lot more to that kind of effort.

Jared: The folks over at Disney, there was an article recently published that had this visualization of all the Disney mobile apps, and there’s like 35 or 40 different Disney mobile apps.

Is there a point where just getting out there and doing it and having all these different parts of your organization just trying something gets in the way, and that maybe you should be sitting back and saying, “Well, do we have a strategy here?”

Luke: Yeah. Well, once you hit the point where you’ve actually done something. I guess I should clarify. I’m talking about people who are trying to, “figure mobile out.”

Jared: Right.

Luke: There’s organizations that have been in there from the beginning and have done a ton and they’ve learned a lot.

And once you’ve learned a lot and you understand, if they’ve got 35 apps, they probably know which ones are being used. They probably know where they’re getting new customers, where they’re making money, which platforms are working for them.

They have a crap-pile of information upon which they can start to build a strategy.

Jared: Right.

Luke: Whereas if you’ve never done anything, and all you’re doing is thinking about the re-architecture, which is going to take you two to three months, you’re not as well-positioned to actually develop a strategy because you don’t have any data, you don’t have any examples; you don’t know what people are actually doing with it, and so on.

And I do see, actually, a lot of companies are in the state that you’re talking about, in that they tried a bunch of things, released stuff, and now they’re looking at, “Well, how can we streamline this a bit? What are ways we can integrate this a bit more? What are the services that are actually sticking? What are the things that are not sticking?”

Jared: But the fact is, they did it, they got out there, they made it work for themselves.

And they didn’t really concern themselves too much whether they were leaving this sort of legacy trail of apps that they could be retiring at some point or disbanding.

Luke: I suspect a lot of those apps, to be frank, come from marketing organizations. And if you look at the trail of micro-sites emblazoned on the Web, right, you see a similar trend.

It’s the same kind of thing. People treated apps a lot like that, in that they would basically say, “Hey, the iPhone app is a new micro-site. Let’s just put them out there for a promotion or a service or a movie, whatever.”

But I’m also pretty confident that Disney has some core applications, representative of the brand and that are targeted at specific age groups and things like that.

Jared: Yeah, they do. They have some guides for moving around the theme parks and a restaurant finder and stuff like that.

Luke: I think they also have a core Disney app as well, because I believe my son watches videos on it. [laughs]

Jared: Oh, yeah. Yeah, I would think they do.

Luke: I think some of that detritus of all these different apps does come from this “treat the app as a micro-site” kind of approach.

But I see that decreasing now, because, as you said, people are looking at it and saying, “OK, well, these things are really low-value.” Once they drop off like an App Store list, they don’t really gain that much traction anymore.

This is why doing kind of gets you to learn. There is, for example, a whole suite of Disney individual, standalone books as apps.

Jared: Right. OK, yeah.

Luke: That’s all about selling a brand, right? So you’ve got the “Winnie the Pooh” book. You’ve got the Pixar “Cars” book. You’ve got interactive puzzle games associated with those brands.

Again, I don’t know exactly what’s going on in Disney, but my suspicion is they put out one of those, probably working with a third-party vendor. And if that format sticks, then they’ll throw other brands against that format.

So, put like a “Winnie the Pooh” jigsaw puzzle book. If that one works, then use that same stack to put another brand, like “Cars 2″ or “Toy Story,” on it.

Jared: Yeah, OK. So they are getting something out there. They’re seeing how well it works, they’re seeing what works well and what doesn’t, and then coming back and saying, “OK, let’s do another one and see what works there.”

It’s the standard iteration, “go as fast as you can” type process.

Luke: Yeah. And again, it’s that kind of environment. This is not a mature market right now. In a mature market, you don’t see the types of things that happened over the past three weeks.

You don’t see huge shifts in something like WebSearch, for example. The brands are pretty much established. We already had all that shakeout with Microsoft and AOL and Yahoo and who knows who.

Jared: Altavista and Ask and …

Luke: You’re familiar with this sort of trend of technology, right?

Jared: Yeah.

Luke: Where you have this period where there’s lots of very big moves, people are figuring out, and then over time things stabilize a bit more and there’s a little less change.

We’re not in that phase yet. [laughs] Things have definitely not stabilized yet. So iteration and constantly putting things out there and seeing what’s working is, I believe, the mode to be in.

Jared: When you’re doing that, when you’re coming to mobile first, you don’t want to treat it as if you’ve never seen it before. So if you’re in a team, let’s say you’re working at a hospital that has decided that they need to get something mobile out there.

So if you’re talking to the IT team at the hospital, what do you recommend they do for first steps, in terms of getting themselves familiar? Do they just go out and study what’s happening on the Web, or do they just start building something, or is there some cross between it? Where do they start?

Luke: I guess there’s a couple of ways to answer that. From a development perspective, I think it matters what they’re most comfortable with, development-wise.

The majority of companies that I interact with and see all have websites and Web presences. So starting to build something on the mobile Web is a very, very fast way for many organizations to prototype and put stuff out there, because they already know how to do HTML, CSS, JavaScript.

They can run it on a bunch of different devices, and they can simulate the form factor, simulate the interactions, and get a lot of things going. You can’t do everything, obviously, on the mobile Web that you can do in an app. So usually that’s a good place to start, technology-wise.

Then, in terms of overall adoption and use, if you don’t have a specific audience and a specific platform, which few people do but some do, you basically go by overall usage numbers.

And so, highest engagement still remains the iOS platform, and then you fall back to Android, and things drop off after there.

And with the transition with BlackBerry, maybe there’s something viable there, maybe Windows will stumble into something. But those don’t really look like very big plays right now.

So you can sort of prioritize what you do technology-wise, and then actually determining what to do with the product and the service you’re offering is exactly the process you’re talking about.

I don’t think it’s necessarily anything new. Know your audience. Observe real behaviors. All the design stuff that we’ve been talking about since I don’t know when applies here as well.

Jared: Do you think that there’s a real advantage to playing with as many different mobile applications as you can get your hands on and learning the lingua franca of the interaction designs?

Luke: What’s different about mobile, I guess, is an interesting question to talk about. And I think there’s three things that really make mobile very different.

The devices, and when we’re talking mobile here, I’m not blurring the line between these laptop, tablet, all kinds of things. I’m literally talking about things that are in your pocket pretty much all day. Very, very mobile.

So, today, those devices have a lot of constraints based on the ergonomics. They’ve got a small screen. In many situations, you’re using them in environments where there’s other stuff going on. You’re not hunkered down at a desk for an extended period of time.

You may be at home on the couch watching TV, or you may be in a line somewhere, or passing some time in, hopefully, not the car.

So there’s these constraints. Low bandwidth is another constraint. And when you use the devices, you familiarize yourself with what those constraints are.

But there’s also a lot of opportunities in terms of capabilities.

And if you use lots of apps, as you describe, then you can see, how are they using the accelerometer? What have they done with front and rear-facing cameras? How are they using location in order to deliver information? How are they using the video port, the camera, the audio input?

All those things can open up new ideas about how to take advantage of those capabilities in your service. So it’s these constraints. It’s these capabilities.

And then the third thing, which is sort of simple but I think it’s also the most powerful of this, is this is a device that you can use pretty much anywhere and everywhere. You have it with you all the time. Coverage of networks is way better than it’s been. It’s not perfect by any means.

And so, through the fact that you have it with you everywhere and anywhere and you can pull it out and access a network and access assets, all these new use cases emerge that you didn’t have before.

And that involves things like when inspiration strikes you can do something. You can do something in all sorts of different situations and contexts and environments and places, and increasingly between devices. This is a very interesting area.

I was talking to someone on the traditional-appliance manufacturing side of the coin. And we were talking about, “Well, why doesn’t the appliance interact with my smartphone?”

If you have either an RFID tag or a QR code, so if it’s got a maintenance issue, I can just point my smartphone camera at the QR code it generates on its screen and it tells me exactly the service that it needs.

Or better yet, fills out the whole form for me and I just hit a button and the technician comes and fixes it. But I can’t do that necessarily, without being able to have these devices with me anywhere and everywhere I am, and that’s a huge determining factor of new uses for them.

Jared: That’s really interesting, because what this really talks to is we can get very creative very quickly once we have a chance to just start to play with this.

It reminds me of the time when I heard the stories of Jeff Hawkins, who founded Palm, which, in essence, was one of the first mobile devices.

He just took a block of wood, and he carried it around in his pocket. And he would literally take the block of wood out and pretend to take notes on it or look something up and just figure out, did it make sense at that moment.

So it sounds to me like, if you got something simple up and running that you could carry in your pocket and then you could actually use it the way your users would use it and go through those scenarios, you would quickly learn where it works and where it doesn’t.

Luke: Yeah. And this takes us right back to where we started. That’s the kind of rapid iteration, “just do things” I’m talking about. That’s going to get you much closer to the mark of what your product should be doing and how than iterating in PowerPoint for hours, or days or weeks or months.

Again, I’m not dismissing the planning phase, but because these devices root you in real-world use, just to go back to the eBay example, some of the testing they did on that eBay iPhone app was they actually went to a Fry’s or a Circuit City or Best Buy with the device, went back to the back of the store and tried to use it for things like price comparison.

They were looking at these things. And they realized really, really fast that, hey, even though there’s great networks outside and within buildings, once you’re in these kinds of environments, they’ve really got to double down on performance because it wasn’t good enough to hit these core use cases where people were going to use them.

Jared: That’s really interesting. So the issue was that because the signal was so diminished inside the building, you had to minimize the amount of data that was being transferred radically to make it still a useful, functional item in that low-signal space.

Luke: There’s actually a lot of great stories from this eBay iPhone app. Karlyn Neel, who I worked with at eBay, gave a talk.

And actually, I wrote all this up, so everything I’m referencing here you can actually go and look up in this “One-Billion-Dollar iPhone App.” [laughs]

Jared: We’ll put a link to that in the show notes.

Luke: Great. That’s the really interesting thing. I mean, this one iPhone app did about two billion in sales last year.

Jared: Wow! OK.

Luke: So all that testing and that rapid iteration and just getting it out there, I think, really worked well for them.

Jared: That’s a lot better than all the fart apps that are out there.

Luke: [laughs] Yeah, I think so.

Jared: Two billion in sales. That’s crazy!

Luke: That is crazy. Single iPhone app.

Jared: Yeah. Yeah, wow. OK, so that makes sense. So now, what are some other things that you’ve been collecting that make good mobile design stand out that designers really want to look into?

Luke: Actually, this is a nice segue to what we’re talking about with the conference, because I’ve been really taking a hard look at what are the things that make mobile different.

How do these constraints, capabilities, and the ability to interact with these devices anywhere and everywhere, what do those do to what we know traditionally about input, about navigation, about organization, about even things like menu design, layout?

All this stuff, I think, gets impacted, and we need to take a step back and say, “OK, let’s rethink how we think about gathering input because of these constraints, capabilities, and modes of use.”

Let’s step back and think about, “Well, how do we think about navigation menus and IA in our organization because of these constraints, capabilities, and modes of use?”

I personally am very, very self-nervous that I want to apply too much of what I know already on the desktop Web to this new environment.

So I constantly keep slapping myself and pulling myself back and saying, “Hey, just because it works over here, is this really what you’re going to do on mobile?”

The thing that keeps resonating in the back of my head it feels like we’re in a similar transition to when we went from print to Web, and the first reaction of everybody was to take what works in print and put it on the Web.

Jared: Yeah. Yeah.

Luke: It’s a very, very similar situation now. Take what works on the desktop Web and put it on mobile; put it inside mobile apps and things like that. And again, there’s different capabilities and new things that you can do, so that doesn’t always make sense.

Jared: So what’s an example that you’ve seen recently of someone who just sort of blindly moved over and they probably shouldn’t have?

Luke: I don’t know if I can name a specific name, but I can tell you how to identify something like that.

Jared: OK, yeah.

Luke: If you go and hit a mobile-optimized experience, and at the top of the screen there’s about five navigation-bar headers, with menu options that take up, I don’t know, 50 percent of this tiny little screen and you can’t actually see any content, that’s generally an example of someone just porting over what they had on the desktop onto mobile.

Jared: Yeah, OK. The funny thing is that those five layers of navigation at the top of the screen probably didn’t work on the desktop either.

Luke: Yeah. [laughs] Exactly. And then you get breadcrumbs and all this other stuff, just really porting over everything that they had from the desktop over to mobile.

Another telltale sign is I have this one example that I reference a lot around a university’s mobile Web experience.

What they had on there was a letter from the president, a photo gallery of life on campus, alumni in the news. All the sort of irrelevant promotional stuff that litters desktop Web experiences and nothing that actually considered modes of use on the phone.

The most stereotypical, generic example you can think of is a campus map. You think if you’re going to take the time to build out a new UI or experience for your university for mobile devices, you’d give people a way to get around the university.

Jared: Yeah, you would think.

Luke: You’d think, but they didn’t have that.

Jared: Wow.

Luke: And things like that. Things which are task-based and allow you to get stuff done as you’re out and about in the real world. All that stuff is absent in situations where they just take what they have on the desktop and port it over.

You don’t see anything taking advantage of these capabilities and modes of behavior. It’s just the same content, smaller layout.

Jared: So, keeping this idea of just sort of saying, “OK, what is the key piece here? Let’s not focus on the chrome.”

This is one of the things, right? Because what happens to folks who work, particularly in larger organizations, is that because every group is responsible for their own content, they say, “Well, we’re not responsible for that.

“We’re just responsible for the stuff the content gets poured into. So we’re just going to focus on this shell, this chrome that we put around things, and that’s what we design. And we don’t really know.”

And so you get a lot of sort of lorem ipsum style designs where the thing that the user actually comes for, the thing that the user actually cares about, is actually not part of the design process.

And that gets them into trouble. That’s still true in mobile, and it probably gets really magnified in mobile, I would think.

Luke: Absolutely. I think you nailed it.

I have this rant about wireframes because when I look at the vast majority of wireframes, images which are content are represented as a box with an X through it.

Text and the actual copy or information, or even detailed data, is usually a line. It’s not even text. Or it’s filled with lorem ipsum.

So it’s all fake and the things that actually are, “real” are navigation menus.

And so what you get is you end up with these designs that have a whole bunch of navigation menus all over the place, because that’s what people are iterating on during the design phase.

To your point, they’re playing with the shell instead of playing with the actual content.

And I think mobile, and in particular, actually, at a broader level, touch-based interactions and these natural user-interface principles really magnify this issue because on those types of devices, you can directly interact with the content.

People start to expect that. Once all the stuff starts taking away from the content and you start putting buttons and navigation menus and everything all over the place, it starts to feel more and more foreign.

And especially when you have smaller screens, you get more and more frustrated that you can’t actually get to the content.

Jared: Yeah. I see myself doing this. So I’ve got this Canon camera, and it has the capability for me to see, on the little digital screen that comes on the back of the camera, nine pictures at once. So I can press a button and now I can see the last nine pictures I worked with.

And the way you’re supposed to interact with it is you use the little arrow keys on the back of the camera. If I want to get to the upper left-hand corner, I have to scroll back and then scroll up and then push the OK button and I get it. So it’s like eight keystrokes to get to a picture.

But I find myself unconsciously just trying to push the picture on the screen, move my finger over and push the picture, and I want to interact with that data directly. And of course, my camera predates the touch-screen movement of the iPhone.

But I think people are growing to have this expectation that they can just interact with this data that way, when it’s in that form factor.

Luke: Yeah. A more interesting piece of that, at least to me, is you and I have grown up and used all kinds of different input formats and devices.

Look at people who just started on touch. So my two and a half year old, he goes up to any screen and he expects it to be a touch-based screen.

Jared: I’ve heard that. That if you grow up in a household with a touch screen you think any glass surface is a touch screen.

Luke: Right. So those are your expectations. I love doing this quote, but anytime he sees sort of like a GUI menu, he comes and grabs me. He’s like, “What the hell is this? Fix this thing.” Because it feels really foreign in that environment.

Jared: That’s really interesting. Yeah, I think you really do have to be immersed in that language of the natural user interface as it’s sort of becoming called, this new thing. What’s your take on Apple reversing the scrollbars on Lion to match what’s happening on the touch devices?

Luke: I saw a great phrase recently which is, “Apple is going to take us kicking and screaming into this next generation of UI whether we like it or not.” Because they actually make pretty bold moves in these areas, and that’s a great example.

Jared: Well but Windows 8 looks is looking like it’s getting that way too. Right?

Luke: Yeah. I saw some really confusing stuff about Windows 8 recently.

Jared: Yeah. They backed away from that. So the original Windows 8 thing that they showed, what, about six months ago, was really this very touch-centric interface.

And then just like last week or something they said, “Well, actually you’ll be able to switch between that and the old way of doing things.” And it’s like, “Ooh.”

Luke: Which I don’t get. So I would like to see that. Because of you look at those two screenshots, it’s like Microsoft Office 2012, the one with the ribbon-type interactions for Explorer and then what looks like Windows Phone seven for the touch-based viewing and toggling between those two seems quite, I don’t know. I would love to see how that works.

Jared: It reminds me of the old saying, “Standards are great, there are so many to choose from.”

And it sounds like Microsoft is taking this middle road where they say, “Well, OK, you get to choose what which standards you have.” But that’s just going to create all sorts of wacky interaction and confusion.

Luke: To go back to the point around how Apple is taking the stuff from the iPhone and adopting it to Lion, I think people are starting to expect the way things work on their mobile devices to work that way on a desktop.

Chris Messina recently posted a thing where he said, “I think I just double tapped my space bar the laptop expecting it to insert a period and a space.”

Jared: I have done that.

Luke: Yeah, because you do that on the phone all the time. You go space, space and it inserts a period and spaces over. And now you go to the laptop and you do it and you’re like, “Wait. Why didn’t this do that?”

Jared: Right.

Luke: So it’s amazing the way we start to reprogram ourselves through continued use of these other devices. If you just plot out the trend line, more people are going to be interacting with their mobile phones more often than they do their laptops outside of very core professionals.

So yeah, the behaviors you get on the mobile device are probably going to become the dominant ones. And those are the ones that are going to influence what you expect in other places, hence the transition of scrollbars online.

Jared: I think so. So from an application developer perspective this really means that we can’t just limit ourselves to a single platform anymore.

We have to become versant in all the platforms that are out there and have a census to how people are switching between them.

And understand that there’s a good chance that our app is being used in more than one platform by the same person often simultaneously in some ways.

Luke: Yep. And so there’s two things that I like to talk about with that idea. One is, it’s becoming very, very clear that a cross-channel user, AKA someone that uses your desktop app, your mobile website, and your, I don’t know, your Chumby app or something like that.

[laughter]

Luke: Not only are they a better user because they use you in three different channels so they add up to more time, but in each of those channels they are higher use than somebody who’s only using a single channel.

So the stat I always pull up because it’s the biggest one, Facebook has 250 million mobile users. The people who that use Facebook on mobile are twice as active on Facebook on the desktop as those who do not use Facebook on the mobile.

Jared: That’s really interesting. Yeah, Netflix was reporting something very similar. And they worked really hard so that if you’re watching it on your TV and you pause it, and then you go and you bring up the same movie on your iPad, it picks up right where it left off on the TV.

Luke: Netflix is actually pretty fascinating. I remember at the Web App Summit you guys put on, Bill Scott made a couple comments around how there’s all this debate in Netflix about whether they should have the same experience across all their devices in terms of UI.

Or if they should be optimized for the capabilities and constraints. And they have this notion of user posture across all devices.

And what he quoted was that in all the testing they’ve done it always comes out that the device optimized UI performs better than something that’s generic across everything.

Jared: Right.

Luke: And I think that applies to how you represent the interface. But at the same time, there’s seamlessness between your data and your interactions and your state across all those different interfaces.

So it’s sort of like the same but different, is really the right answer. Because you want the interactions, the core value, your data, all that stuff to be the same. But the way you interact with it should be influenced by what the device can or can’t do.

Jared: That makes perfect sense. That makes perfect sense. So, people coming to your full-day workshop.

You’re going to walk through a lot of what you’ve been learning. Particularly with your recent explorations doing the whole Bagcheck experience, which was a gorgeous experience.

Which, it’s interesting how you were co-developing this desktop-based experience alongside doing a mobile experience. And you started with using mobile Web for it.

I remember early on you told me that eventually you would expect it to be a mobile app. But you were using the mobile Web so that you could get to the functionality and understand what the users needed faster and you could react to it faster instead of having to go through the App Store cycle, right?

Luke: Right. Exactly. It’s actually even more complex than that I guess. We started out by building a command line version first. AKA, we built the API.

So what we would do is really think about, “What are the different objects? How are people going to interact with those objects?” And we would build a core functionality which we could interact with through command line.

So the first things we actually did when we were testing … this is kind of silly. But the first interactivity and “usability” testing we did was in the command line. [laughs]

And from there we took that command line and we gave it a bit of a front-end in a mobile Web experience. And then subsequently we built a desktop experience after that.

But the mobile Web experience, one of the reasons why we did that first was because we had again, these tight constraints, but also because we could interact with it anywhere and everywhere.

So we would literally be out in the evenings. I used it when I went on vacation. Just trying to figure out what are the modes of behavior, very similar to the eBay example we talked about earlier.

What are the modes of behavior that makes sense with this service? And once we thought we had that tuned then we went over to the desktop and said, “OK, well, let’s take what we learned and develop a larger screen more in-depth kind of immersive experience for it.”

Jared: So by going that sort of command line which got you to the essential functionality and it said, “These are the transactions what we will have with the server.”

And then, in essence, it sound like you put a nice pretty skin on it and built it out from there for your mobile experience.

And then you went to the desktop and said, “OK, what does the desktop need to have that borrows from that mobile experience and what does it have to have that’s unique to the desktop?” Is that sort of the evolution?

Luke: Yeah, definitely. And with the desktop too. I mean, you just have different kinds of capabilities.

So you’ve got a lot of screen space. So we were able to do things which are more like asynchronous editing, which is very hard to do on mobile because you just have this small screen.

You can’t have multiple pieces of say, like a creation tool open simultaneously and allow you to switch between them. You tend to be locked into a mode or a state because that’s all the room you have.

So when we took it to the desktop all of sudden we were able to do things that were a lot more asynchronous, that were more multi-modal if you will.

And we were also able to do a bit more automation on stuff because we had nicer connections in the bandwidth pipes overall.

So for example, one of the things we did on desktop, which we didn’t do on mobile, was on a desktop we would go and build out a listing of all your stuff using metadata you have on other services.

We said, “OK. Well tell us who you are on Flickr,” and we’d go and find all the camera gear you use on Flickr and essentially build out this list for you in this full-screen interactive mode.

Whereas on the mobile, we built something that we didn’t have on desktop, which was you can go and scan the barcode of an item to input it, which is pretty awkward and clunky in most people’s laptop and desktop experiences.

So those two things were separate to the platform. Long term, maybe we could have morphed the two. Certain things just made more sense.

Like the barcode. You could pick up the phone; point it at an object really easily. So that makes a lot of sense on mobile. So that app had that functionality.

Jared: Well, I mean, it all sounds great. And I’m really looking forward to your workshop at the conference. And I’m very excited because you’re really going to get into the core details as to how people make this happen.

You’re going to talk specific about gestures and how Hover works, and doing input, and displaying data, and all that stuff.

So it’s going to give people a really solid background and starting place for the language of what works and what doesn’t.

Luke: Yeah. I wouldn’t come unless you want to get really into the details of how to do these things.

Jared: OK. So we’ll tell people to stay away unless they really need to do that.

It’s key that they don’t come unless they really want to know that stuff.

So that’s excellent. And people love your workshops, so that’s great.

Luke, I want to thank you for taking the time to talk to us today. This has been really fascinating and hearing these stories of how you guys did this and what’s going on in the mobile space has been really a lot of fun. Thank you.

Luke: Thank you. My pleasure.

Jared: So everybody, you can hear Luke at the User Interface 16 Conference, which is going to be November 7th through 9th in Boston, Massachusetts. He’s going to be doing a full-day workshop on designing for mobile.

And you now know why we chose him to be the guy to do this because he’s done this stuff. He knows what he’s talking about. So you definitely want to see that.

You can find out all about that at Uiconf.com. We’ll love to see you there.

Again, Luke, thank you very much for spending this time with us.

And I want to thank the audience for listening. And as always, thank you for encouraging our behavior here at User Interface Engineering. We’ll talk to you next time.

It’s easy for applications to get overcomplicated and bogged down with data – especially in an enterprise setting. It’s hard to keep track of so many different things. When dashboards and widgets are employed, the goal is to make your life easier, but often that’s not the result. The solution—simplify these applications for specific use cases and give the right people the right information they need for their given task.

Hagan Rivers, of Two Rivers Consulting, spends her time meeting with teams to show them exactly how to streamline these complex applications. Whether it’s an app for managing purchase orders or hospital patients, there is a lot to consider. Hagan expresses the value of taking a step back and sifting through the complexity. This allows you to untangle the necessary bits to arrive at a better focus.

We have 8 full-day workshops at the User Interface 16 Conference in Boston, November 7-9. Hagan is bringing her expertise to one of those workshops, showcasing the methods she uses to create consistent, beautiful applications. For more details about the conference visit UIconf.com.

Here’s an excerpt from the podcast.

“…there are certain expectations we have about where buttons should be. The “OK” button is the one that’s bigger and brighter and more clickable, and the “Cancel” button is less so and they’re in a certain position. And toolbars go above tables. And the first thing is usually new or something like that. Like, if you didn’t have the language cues, how much of just the layout and the organization and the arrangement of things would lend the pattern to you.

And sometimes I show people screenshots of Japanese GUIs. And I ask them to really look at it, because they get so used to just reading the labels, especially the developers. They’re very good about actually reading everything on the screen. Users are not.

But the developers read the text on the screen. They say, “Well, it’s obvious, it says in the help text right there.” Yeah, but, OK, don’t read the text, just look at it and see what you can learn…”

Tune in to the podcast to hear Hagan address these questions:

• How do you identify and prevent unnecessary complexity?
• What is the value of “hand-holding” when a customer is experiencing a product for the first time?
• If a design isn’t in a standard pattern, can consistency alleviate any potential confusion?
• Are there exercises that teams can do to develop patterns?
• What is the best way to implement dashboards?
• Are there patterns on mobile that are making their way back to the desktop and other places?

Do you have experience with complex applications? Share your thoughts with us in our comments section.

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

Full Transcript.

Jared Spool: Welcome, everyone to another episode of the SpoolCast. I am very happy, because today I have one of my favoritest people in the entire wide world of the UX space, Ms. Hagan Rivers, who is going to be speaking at the User Interface 16 Conference, which is going to be in Boston November 7th through 9th, and she’s doing a full day workshop on the 9th called “Simplifying Complex Applications.” And I’m very excited that we get a chance to talk to her today about just this topic. Welcome, Hagan.

Hagan Rivers: Thank you, Jared. It’s good to be here.

Jared: So, I have a question for you which are why we’re doing this, because I have a bunch of questions for you. Lately I’ve been working with these teams that have these designs that have been going on six, seven, eight years, right? So they’ve been around for a while, and they’ve got dozens of designers and developers who are working on this.

And just a few weeks ago, we’re watching actually a training video, so it’s a video of a customer being trained. And it’s a beautiful way to watch people use a design, because you see what the trainer is doing. They’re walking the user through the various aspects of the design, and you get to see the screens. You get to see how the new user is responding to all these things.

And one of the things I’m noticing is that as every part of the interface pops up as the trainer is walking through it. Each one has sort of a different signature look. They’re all maintenance screens, right? So, you know, one’s a customer screen – these are places where you have classes, so one’s a class setup screen, one’s an instructor screen, and each one has a capability to make changes and save, but the way you make changes and save in one screen is a “save” button, let’s say, and it’s at the top of the screen.

On the next screen, it was an “update” link that was at the bottom of the screen, and each one was different, and as we went through these, I began to realize that I could actually start to pick out which developer had probably developed which set of screens. I didn’t know the developer by name, but I knew that screens one, seven and nine were all probably developed by the same guy, because they had the same basic look to them, but screens two, five and six were done by somebody else.

And, of course, all this made the trainer’s job that much more crazy, because every time they had to sort of explain a different way of doing it. And so I’m realizing that entropy takes over and these designs become this giant hairball of complexity, and I was wondering, do you have any suggestions? What could you tell teams to do that would sort of prevent this hairball from growing as nattily as it does?

Hagan: To make it never happen in the first place?

Jared: Well, maybe, but at least to start to identify that it’s happening and maybe prevent it. I don’t know.

Hagan: Yeah. I mean, I see these apps all the time. When I meet with new clients, they demo their apps, and I see the same thing. I can tell which screens which parts of the development team did. I can tell you how many different developers there are working on the GUIs, you know?

Jared: Exactly, exactly, yeah.

Hagan: And each one has their little pet peeve about they don’t like to call it the “OK” button. They think “save” is clearer, so they always say “save,” or whatever. They all have their thing going.

And as new features get added, especially as you talked about in the preferences and stuff like that, that’s where the developers tend to do a lot of design work. They just sort of throw whatever they think works onto those screens.

So, actually, it’s interesting you talk about the training, because I did some work with a client last year, and I went and took their training. I acted as a customer and I just said, “I want to attend your training classes.” And I got so much great material there, because as we went through screens, there were all these places where the trainer had to stop and tell us what was weird about that screen, and I would take notes. I’d go, “OK. We need to fix that.”

And we’d go to the next, and they’d say, “Well, on this screen, you have to be sure to click this button first.” And I’d go, “OK. Well, we got to fix that,” you know?

Jared: Yeah, so one of the things we’ve been doing with clients is when we take these video tapes and we actually start dividing up the tape into pieces, and any place where the trainer is in essence helping the customer get value – so, in other words, that particular thing, like the customer setting up their first account or their first class or putting in their first instructor, right? They’re getting value from that, and so we call that “goal time.”

But the places where the trainer is sort of explaining – like there was one option that took about – we counted it – it was about six minutes to explain that you should always keep this number set to one. Whatever you do, don’t change it, but then went on to explain why it was there and why it might not be one for people who weren’t you, but you should always have it as one.

Hagan: Yeah, don’t touch it.

Jared: Exactly. And so we call that “tool time,” right? So that’s the time that you have to just sort of deal with the tool. And you can actually measure how good your UI is doing by the ratio of tool time to goal time, right?

And if you keep reducing tool time and increasing goal time during the training session, you’re getting real value, because there is value to hand-holding a customer through their first experience for some of these high end products. But that hand-holding is different than mine field avoidance lessons.

Hagan: That’s right. That’s right. Yeah, I mean, a lot of the apps I work on are really complicated. They’re not apps that you can typically just hunt through the web and find them. They’re the kinds of apps that are installed in enterprises, so apps for managing purchase orders or patients at a hospital or ticket systems for managing help desks – stuff like that. I mean, big, big apps, and they’re complicated, and they do often have training.

And you’re right – there’s this tool time is like just spent trying to dig through what is quirky about this app. And there are always a lot of internal inconsistencies, and I always tell folks, like, “Just pick one.” I mean, in a way, it doesn’t even matter which pattern you pick for your forms – just pick one and use that one again and again. Like, yes, they obviously can make improvements later, but the inconsistencies just throw everybody for a loop.

It hits you in training, but it hits them in QA. It hits them in documentation. It hits them all the time when they are being inconsistent.

Jared: Yeah. I think there is something to that, right, because you can have something that is illogical but consistent and it works, right? The old start button on Windows XP, right? It didn’t make sense that to shut down your machine, you press the start button except that once you learned it, it just work. It just always worked.

Hagan: That’s right. And so, if your app has, the OK button as a link on the upper right hand corner, you know that’s not how most folks do it. That’s not the standard pattern. But if you do it in every one of your screen, people will learn it and will just do it. It will be fine. But if you change it every single form, you are creating much more work. And the other thing is you are creating more engineering work. I mean if you have to recreate how you deform submission for every single form, that’s a ton of effort that’s wasted.

Jared: Well, one thing that gets me is on the American Airline site. I can go on for hours about the American Airlines. I mean but on the American Airlines site; they have this convention where the OK button is a red button. How do you like that?

Hagan: I love that.

Jared: In the lower right hand corner, it’s the farthest most right button, except occasionally, the start over button is that button.

Hagan: I’m sure the ramifications of clicking that are a lot of fun.

Jared: Yeah. If you are like me and you are trying to make a reservation quickly and you do it 20 times a year, it drives you nuts when you hit start over and you didn’t mean to. It’s like, “UGH!”

Hagan: Yeah. To answer your first question like the hair ball of complexity. I think if you do what I do. When I first meet with a client, I go around and I talk to the folks in their sales team. I talk to the folks in the support engineering. I talk to the folks that helped us. I talk to trainers and as I talked to them, they’ll tell you about these inconsistencies and they know them because they are working directly with the customer trying to deal with them.

They spend a lot of their time dealing with them every day. And you know, I see those and that’s why I know why the products got the hair ball of complexity in addition to looking at it myself. One of the first things we tackle is these patterns. They are trying to create very standardize ways to do things that you use throughout your application. The one way to do a form, one way to do a chooser, one general way to present a toolbar over a table, so that you don’t have to reinvent that all the time.

You don’t have to retrain people all the time. These complicated Apps, it’s hard enough just to understand how to work the App and do the real tasks. Much less have to wade through a complicated, difficult to use UI.

Jared: Yeah, I think they are creating a library of patterns. It’s really a good idea. People ask me this. There are now a handful of sort of general purpose patterns that people put together. Jennifer Tedwill put one together. There’s a guy in Germany who’s got a really extensive site. I don’t remember how to pronounce it. It’s German so everything I know about German I learned from Hogan’s Heroes. Which is probably not the best way to model an entire culture.

Hagan: I think that was all deliberately mispronounced.

[Editor's note: The "german guy" is actually dutch and his name is Martijn van Welie. The site is welie.com. Apologies for not getting that right in the recording.

Jared: You're probably right. There are all these third party pattern libraries that are emerging. But I still feel like there's a lot of value in sort of crafting your own library as a team, because you have a lot of really useful discussion about what is a pattern and what do we call that, and it creates a language, which I think is really important.

Hagan: Yeah. I find the same thing. If you just kind of hand an organization a pattern and say, "Here's your pattern library," they don't use it. They just shelve it. It's not their pattern. It is a pattern library, but it doesn't always apply to their apps and it doesn't make sense and they haven't even agreed to use it. So you know, we try to do a conversation with the development team, and I'll go through and I'll find the six different ways they do a chooser screen.

And we'll put them all up on a screen and we'll look at them together and we'll say, "Well, which of these do we think is the best and why?" And I'll tell them why I think which one's the best, and we'll pick one and then we'll get it recorded down in a pattern and we'll start migrating to using that for everybody.

Jared: Do you do an exercise when you do that, because I've done this with teams? Do you do an exercise where you actually say, "OK. Let's just make a list of what's different - let's not assign good or bad here. Let's just make a list of what's different between these different variations so that we can make a catalog of why each one of these things sort of existed?"

Hagan: That's right. You'll learn things, like some chooser that someone did is really good for that particular situation, because he's choosing between maybe hundreds of thousands of items, whereas another one might only for choosing amongst 50 items or a 100 items, and they do different things. And so you say, "Well, OK. When you identify these, it's not that they're good or bad. It's that they're solving different problems."

You start to build your pattern library, say, "Well, whenever we need a chooser for more than 5,000 items, we'll use the giant one, and whenever it's less than that, we'll use this one. And so if you do an exercise, you get them to think about what's making that work? Why did they choose to design it that way? And what's the purpose? What problem is it solving? How does it help the user? Then they understand why they would reuse the pattern. I think that's much stronger way to start building a pattern library than to just grab a book off the shelf.

Jared: I'm thinking this doesn't have to be a difficult thing, right? You could take, like, 15 minutes of a weekly staff meeting and just put up a chooser one week and a form next week, the way you do login authentication the week after that, and just do one a week for 15 weeks and all of a sudden you've got the start of a library.

Hagan: Yeah, it doesn't have to be super hard. I think what happens is a lot of folks get very married to the patterns that they've created and they really feel they've got the best solutions. So sometimes you do need to go out and talk with users and talk with the support folks and see what's really working for people. But most of the time when you ask people to sit down and really look at the design, and compare it to other designs solving similar problems - they're pretty quick to pick up on what needs to be done.

Jared: I have this friend who was a real film buff, and he went and studied all these film classes and would watch every DVD extra where they talked about how they made the thing. And he always wanted to go off and be a filmmaker himself. And I would go to the movies with him, and we'd be sitting in the movie theater, and this exciting thing would be happening on the screen and he'd hit me on the shoulder and he goes, "Did you see that tracking shot? That was like an awesome tracking shot!"

Or we'd be watching a video at home and he would make us go back and rewind something because the zoom was particularly good. And, it's like, "Dude, I just want to watch the guy get the girl." You know?

Hagan: What guy? What girl?

Jared: Yeah, exactly. He had stopped paying attention to any of that. He was looking at what the cameramen was doing the whole time. And so, "I figured out how they did that." And like, we'd have to watch the same scene 15 times.

Hagan: He was interested in the craft, not the product.

Jared: Exactly. Exactly. And I'm wondering if, in fact, that's what we're trying to do here with developers. They can't log into, you know, PayPal without noticing exactly how PayPal does their authentication screen, now, because they're going to pay attention to that level of detail, because we've dissected it.

Hagan: That's right. Yeah, I mean, I think, you need to be able to, kind of, step back. Like, I always think it would be fun to take a piece of software and replace all the English in it with gobbledygook. And see how much of it you could drive.

You know, there are certain expectations we have about, like, where buttons should be. You know, the "OK" button is the one that's bigger and brighter and more clickable, and the "Cancel" button is less so and they're in a certain position. And toolbars go above tables. And the first thing is usually, like, new or something like that. Like, if you didn't have the language cues, how much of just the layout and the organization and the arrangement of things would lend the pattern to you.

And sometimes I show people screenshots of Japanese GUIs and stuff. And I ask them to really look at it, because they get so used to just reading the labels, especially the developers. They're very good about actually reading everything on the screen. Users are not.

But the developers read the text on the screen. And so, they're just like, "Well, it's obvious, it says in the help text right there." Yeah, but, OK, don't read the text, just look at it and see what you can learn.

Jared: That's interesting. I actually found myself in a Dutch police station once in Amsterdam and watched the cop fill out a theft report, a friend of mine had had her purse stolen. And so, we're watching him fill out the theft report, and of course, the screen was entirely in Dutch. And yet I had no trouble following along with what he was doing, because it did follow those sorts of conventions that we're used to.

Hagan: That's right. And I have a theory that if a pattern is working well, the labels are irrelevant. They add supporting information, but you should be able to figure out how to use it without being able to read them.

Jared: Yeah, I think that makes an awful lot of sense. It is really interesting that this idea of being able to use the design independent of the language that's there. And can you drive it that way, basically, through just convention. Makes a lot of sense.

But at the same time, a trap that I see teams falling into, I don't know if you've seen this, is when they try and come up with generic designs and they use "Lorem ipsum" style text. And then, when they plug the real design in.

Hagan: It's just too generic.

Jared: It's too generic. And it doesn't handle the special cases, which is why you need the patterns for the 50,000 item selection, or is this the 3,000 item selection?

Hagan: Right. We'd worked on an app last spring. It had a bunch of wizard based forms for editing. There were a whole bunch of different objects in the system. So, they had, like, 20 different tabbed wizards for editing these 20 different objects.

And so, they all looked the same. I mean, once you opened one up, it was really hard to distinguish them. You know, I told the engineers, we need to put labels at the top, we need to repeat these labels. Like, instead of just saying, "Name," we would say, "User's name." So, it was very clear what name we meant. Or "System's name" or whatever name we were asking for. And they said, "Well, they should know by the context they're in."

And I said, "Well, the language is what gives them the context." We saw regularly, people would open up a screen in our usability study and they would forget what screen they were on. The language is the thing that gives you those cues, oh, I'm working on this. Oh, it needs to know this. And being repetitive, like, there's this real tendency to be really lean in language on some of these apps. And sometimes it's confusing.

Jared: Every pixel costs, right? So, you want to save on those characters.

Hagan: You've got to save, I know, because it might, burns out your monitor. I don't know. But yeah, it's like, there's this appreciation for brevity that doesn't really help users at all. I mean, obviously, you can swing the other way and have full sentences all the time, and that's too much. But there's this desire to be really, really concise in the language, and I think it's disorienting, sometimes.

So, yeah, I don't mean to say, if you use the pattern without seeing words that it would be perfect. But the sort of placement and arrangement of things can be very suggestive. And then, the language kind of adds to the whole context and the behavior layer on top of that. To, sort of, tell you what is this thing? How does it work? What's its relationship to other things in the system? What can you do with it? And that's what the language layer kind of gives you. Of course, the language is really critical.

Jared: Yeah, I think that the more we understand about interfaces, the more we realize that we're basically creating a language that is both visual and verbal with our users. And that the combination of the two is really important.

We saw this early on with icons, where there was this big push to have visual symbols for everything and no words. And we were working on this tool for software developers. The team had come up with this hatchet dripping blood. Which was the "Execute" program icon?

Hagan: Yeah. That'll translate well.

Jared: Yeah, exactly, yeah. A visual pun that just does not work. The funny thing was that we'd have these usability tests and all the male developers that we had come through went, "Oh, that's really cool." And all the female developers go, "Ew. Why?"

Hagan: Ew. [laughs]

Jared: So, that one really split down gender lines. But what we found early on was that when you just had pictures, often people didn’t know what the picture meant. And when you had just words, it wasn’t as good. But the picture and the word together, actually seemed to really work best.

Hagan: Yeah, the pictures give you a differentiator, so when you’re using your kind of positional memory of the toolbar in your head, you remember it’s kind of the fourth or fifth one in, the picture kind of gives you a reference point for your eye to grab onto. At least that’s my theory.

Jared: Well, you know, what was really interesting was we experimented with that. We started moving the icons around, and we found that the position wasn’t as prominent as we thought. In the early Microsoft Office apps, for example, the first icon was open and the second one was save, and the third one was print, or something like that.

But we found that if we moved them around a bit… I mean, if you completely reversed it, if you put open and close on the far right instead of the far left, people would have trouble with it. But if two icons appeared before open and close, nobody was freaked by that. It didn’t have to be the very first icon.

Hagan: Yes, I don’t think positional memory’s that absolute. I think it’s just sort of like, “it comes first-ish neighborhood” memory. But it helps. It’s an important piece of finding stuff again and again, especially in an app you use all day long.

Jared: So what’s your take on dashboards? We have a lot of clients that are doing this sort of dashboard thing, and it sort of starts with some executive declaration of, “I just want one screen that tells me exactly what my business is doing.” And the next thing you know…

Hagan: Wouldn’t that be nice?

Jared: Yes. You’ve got odometers, and speedometers, and temperature gauges. Every physical skeuomorphic gauge that man has ever come up with is now a visual element on this opening screen that nobody understands.

Hagan: Yeah, they’re trying to really create the pilot’s dashboard, which works great for pilots, but not so much for most other folks.

Jared: Except that pilots are intensely trained on those dashboards.

Hagan: That’s correct. That’s why it works for them. They need to know where things are and what to click and what to look at, whereas we present someone with something just as complicated as a pilot’s dashboard and say, here, this helps you know what your whole business is doing! And they scream and run out of the room.

So, dashboards. I can usually tell if a client knows who their users are and what they do just by looking at the dashboard. To me, I think of the dashboard as like an extra layer of navigation, actually. Like, a whole screen devoted to navigating to key parts of the application and bubbling up information from key parts of the application.

Jared: That’s interesting.

Hagan: Yes, so if you know your users, your dashboard, it reflects it. I’ll give you an example, because this is this new idea that I’ve been working on for the last year or two.

So, we worked on an app a couple months ago for managing mailing lists, email lists, and stuff like that. And they had a dashboard, and when you logged in you got this screen, and it showed you your user profile. So it showed you your first name and your last name, and a place to change your password, and those things. And then it showed you a list of the mailing lists you were subscribed to.

This dashboard was the dashboard for the administrator of the mailing lists, mind you. Not an end-user, but the administrator, the person who actually sets them up. So, there was nothing on this dashboard that was of any use to this person. And they had little meters and metrics and stuff, but it was useless. They all clicked right through it and went off to doing stuff.

So we went and talked to some of these users, and we talked to them about what do you do the most often? If you talk with them, after a while they said, well, the biggest problem they have to deal with is updating other people’s email addresses. That’s their number one problem. Like, they send out a message and a bunch of them bounce back as having failed. And they need to know who those people are so they can get it up to date, and they have to look up and manage those users and deal with the failed deliveries.

And then the other thing they do a lot is they send out these mailings. So when we were done, the dashboard now had a quick way to get to a list of users who have disabled email addresses due to delivery failures. So you could just say, 150 people right now, their emails are no good, click here to go straight to them. A quick way to look at users who don’t have email or are out of sync however with the system. We even had a little box right there where you could type in an old email address and a new email address and just push a button, and it would just look it up and do the swap.

So that was, again, we were looking, what’s the common task? And then we had a place for starting new messages and sending them out. So we went out and said, what’s done really commonly, what’s really hard to do, what things do you have trouble finding? And those were all the things we bubbled up and put on the dashboard. And we had some reporting stuff too, but it was mostly like, how many mailing lists do you have, how many total users on each mailing list? Just some very simple metrics, and they were not giant dials, they were just some very straightforward numbers.

So the idea is that the dashboard is like storytelling. It tells you the story of what the app does, and the most frequent things you’re going to do with it. And it navigates you very quickly to those key places to support those tasks. Most dashboards don’t do that.

Jared: Yes, that to me makes a lot of sense. So, you could have it, for instance, if you had items that needed attending, you could have it put the number of items that need your attention in red for those things, much like the way unread messages show up on an iPhone, or something of that sort.

Hagan: Right. For instance, in a lot of apps, you’ll have a list of stuff and you can filter that list. So it’s possible to go in and set up whatever filters you need to find something out. But on the dashboard, you could put five links to the most important filters that the user’s going to need a lot, and it just immediately takes you to that page and applies those filters and gets you up and running. And you don’t have to do anything more complicated than that, it just gets them going and gets them started on their work.

Jared: Yeah, because I think a lot of these sort of visual elements, though, they might demo well just from an “Ooh, that’s very impressive,” the dials and gauges and stuff. I think the amount of information that they communicate for the number of pixels that they use, that sort of data-to-ink ratio is probably pretty low.

Hagan: Yeah, it’s very low. We’ve done a lot of work cleaning those up to try to increase the information density, and it’s really low. The other thing is I think, at least I’m finding with our clients’ customers, you know, a year or two ago, they would just be really wowed by seeing a dashboard covered in these controls. But now, when I go and sit in on sales meetings, I hear them saying, “Well, what is this for? What is it telling me?”

So, the customers are starting to become more critical of these flashy screens and really asking what they’re good for. And I think that’s going to be what drives improvement in the design, is that the customer is getting a little jaded about all those bells and whistles.

Jared: So, we have this definition of the word “clutter.” Every so often, you’ll be sitting in a usability test and a user will tell you, “That screen feels really cluttered to me.” And what we’ve realized is that clutter doesn’t mean high information density. Clutter means there’s a lot of stuff on the screen that I either don’t understand or I don’t care about. And there’s very little stuff that I care about.

And I’ve actually seen screens where we did a before and after of a design. And the before, the user told us, was much more cluttered than the after. But the after had more information on it than the before did. And what made it less cluttered was that all the information we had designed to be relevant to something that user needed.

And so, I think what I’m hearing you say is that these dashboards that don’t do well, that the users are now saying that maybe that’s that clutter effect, right? They’re looking at this dashboard that has a lot of stuff on it, but it’s not stuff that they are interested in in running their business or doing their job or whatever their operation is. And if you replaced it with stuff that was actually, really important.

So, one of the things is, we have this client who has this application. It’s a subscription thing, it’s a monthly subscription thing. So, every night it goes and runs a batch of credit cards for the people who are renewing on that day of the month.

And the first thing every one of these business owners of these customers did is that they would go to the report that told them how that job did, which credit cards got declined, how many got declined. Because that pretty much set their to-do list for the day of who they had to contact and say, “Hey, your card is expired,” or “Your bank’s not accepting this charge anymore and we need a new card or we’re going to have to shut off your service.” And that wasn’t on the dashboard. Right? Yet it was the most important thing that pretty much every customer we went to visit did.

Or just checking to make sure the job ran at all, because there are random nights where, for whatever reason, things don’t go well and nothing was charged, right? And the batch is left hanging, because of some technical error.

And so, having this thing that says, yeah, last night, we ran 23 credit cards and every single one of them cleared, would save, like, A, six clicks, and give something incredibly useful that that person wants to know when they first login in the morning.

Hagan: That’s right. And that’s what I mean about it being kind of a mechanism for bubbling up key information and giving the user a quick way to get into, maybe, deep places in the application to do tasks that they have.

So, I have this funny exercise I do with clients now where we do a demo of their product very early in the process. And they bring up their dashboard screen. And I say, “OK, let’s take a look at this. I’m going to go through this screen, and I’m going to tell you what I think, based on this screen, are the most important things in your app.”

And we go through the screen and it’s mostly garbage. I mean, it’s just sort of like random stuff we’re able to tell you, but has no bearing on things you do, or things you care about. And they quickly realize that they really haven’t given it much thought. They just sort of threw everything on there that they had, rather than spending any time thinking about how people use the app.

Jared: Your content management system has 47,000 letter E’s in it today.

Hagan: Yes, exactly. And those are the kind of stats they’ll give you. And it’s like, thanks.

Jared: Sixty four percent of words are spelled correctly.

Hagan: Yeah. One million three hundred and twenty two pages. Great. OK. Why isn’t it 323? I don’t know. Like, it’s just data and they’re just sort of flooding you with this firehouse of data. And it’s not useful.

Jared: So, you really have to get into the head of the user to figure out how to do a dashboard right.

Hagan: You really do. I mean, you can build your app and never put a dashboard on it. The dashboard is a completely separate layer. It doesn’t do anything that the app doesn’t already do. It doesn’t tell you anything that the app already doesn’t have in it.

So, the question is, why are you putting it on there? If it’s just to be a sales gimmick, yeah, I guess. But I think the clock’s running out on how much people are going to love that in sales calls.

You really want to say, we know our app is complicated, we know there’s a lot there, and we’ve really spent some time studying what our users need to know, and what they need to do, and we’ve incorporated those things here.

Jared: So, one of the things that we’ve been doing when we go out on customer visits is we say, OK, so what’s the first thing you do every day? And we have the person we’re visiting actually walk us through those sorts of first steps. So, if we start to see patterns from one visit to the next, of a first thing that everybody does each day, that, to some extent, is telling us what a good dashboard entry might be.

Hagan: That’s right. And that’s why I say, I can usually tell if my customers know their customers just by looking at their dashboard. If they know what they’re users are doing with their app, and they know what information their users need to have, then their dashboard will show it.

Jared: I wonder if this is one of those places where self design, you know, designing an app that you also use yourself on a regular basis, actually really helps, because you know what you want to see. And if your behavior matches your users’ behaviors, you know, which doesn’t happen that often, but programmers creating tools for other programmers. People who are business owners creating something for other business owners. It does happen.

You can get away with that. But if you’re not in that space where you’re not a user of this thing, the odds of you coming up with what those dashboard things, without doing serious research is probably very slim.

Hagan: So we worked on a help desk application a couple years ago. This was an app where we had some really different types of users, different personas that we were working with. A help desk tickets come in. End users have problems, they submit tickets, and then there are the people running the help desk.

There are the folks that answer the help tickets, the front line worker. What they do with the app is they go through their list and they work through their tickets, right? I mean, that’s their job. Then there’s their manager and their manager might manage 20 or 30 of these people and they want to know things like who’s doing the fastest job of going through these tickets?

Who’s got the longest back log? What do I do when this person’s out on Tuesday and I need to redistribute his tickets? And they were using the same dashboard for both of these user types and they had totally different needs, you know? And so we separated it out. We had two different dashboards.

Sometimes the managers did answer tickets so they would use the ticket answerer’s dashboard sometimes which was a list of your tickets that you were assigned to and helped you deal with that. What’s the highest priority, things like that.

Then there was this separate place that managers could go that would show who are your top performers. Who has the greatest back log of high priority tickets, things like that and they could look it up and find that information really quickly. All that information was already in the app. You could have gone and gotten it any way you wanted but the dashboard collected it all together in one place.

Jared: I would think, also, that the dashboard would be an opportunity to plug other things in that may not be part of the app like server up time statistics and things like that, that would be specific to, “what is the current state of a given server right now” so that if all of a sudden a slew of calls comes in, “hey the system’s not working”, you have this up to date information that says, “oh yeah, we know.”

Hagan: Exactly. The router’s down, we’re dealing with it. Exactly. You can bring in that information. A lot of folks, especially in IT, they like for the dashboard to include information about the app itself. Is the app running properly? Was it able to contact everything it needed to? Sometimes the problem is the app itself is breaking down and so they love to see that information.

Jared: Right. It seems to me that things like dashboards and stuff are going to be moving to mobile platforms, that there’s an opportunity to have a way to bring this up. Are you seeing… now that people are using things like iPad and Android and stuff like that are there patterns there that are coming back into the desktop?

You know, Apple just recently with their newest release changed the direction of scrollbars. Are we going to see some of those visual tropes that have been happening with the IOS operating system are we going to see those starting to come back on the desktop and other places?

Hagan: I definitely think so. They didn’t just change the way scrollbars work, they now hide the scrollbars when you’re not in the scrolling area which is a direct lift off of the IOS platform because they don’t have many pixels. They don’t want to clutter it up by showing you a scrollbar.

Jared: Yeah, I wonder how long that’s going to last because you need some sort of visual clue that there’s more.

Hagan: Yeah, I mean I think the number of patterns we have is always increasing. We always have new problems to solve and the patterns are really just an expression of what we commonly do to solve these problems. And as the interactions evolve and we use different preferences, we use touch, we use different things, the patterns adjust and what we consider normal, changes.

One example on the IOS devices is for instance in a list of phone numbers, so I’ll have a list of people’s names and they’ll have a row for the name and then they’ll have a little circle on the end on the right. If you click anywhere in the row you make the phone call. If you click on the little circle you go edit the address book card for that person, right?

That’s a completely new pattern that was developed on mobile and it would not surprise me if in a year or two we see that coming back to desktop. Stuff like that. So yeah, the pattern space is always increasing. Interestingly, I’ve been putting this class together and a lot of the patterns from desktop from 30 years ago and from web still apply in the mobile space.

So, there’s an enormous amount of overlap between them. I think they’re all converging into one big pattern space that just keeps growing.

Jared: Any of those 30 year old patterns that really shocked you like oh my God we still use that?

Hagan: We still use this basic desktop form for tables. A table with a toolbar above it. That has not changed. Mobile has a little trouble with tables because they’re wide. And so mobile is using more of what I call a list where you don’t really have columns you kind of wrap stuff into thick rows but they still have a toolbar at the top or the bottom. It’s the same idea.

Jared: Yeah, OK. Yeah, it’s true. That goes back to almost pre-Windows days where, yeah, using DOS and character based displays.

Hagan: Yeah. And honestly you look at the design for tables. You click on the header to sort it. Sometimes you can click on the header, right click, and you open a little menu of other options. I mean, those patterns really haven’t changed and they work really well. Why fiddle with them?

Jared: Yup. That makes perfect sense to me. Well, Hagan, it is wonderful talking to you. I’m really excited about the class that’s coming up in November. I think it’s going to be a lot of fun. I’m really looking forward to learning all sorts of great stuff.

It sounds like the perfect class for folks who really want to get a handle on how to get that stylistic essence of their individualistic design traits for each developer out of the design so it feels like it was written by one person.

Hagan: Yes. We’re going to work on consistency but we’re also going to work on it being beautiful and elegant and solving people’s problems.

Jared: That sounds excellent. I’m looking forward to it a lot. Thanks for taking the time to talk to us today.

Hagan: Thank you.

Jared: So if you want to take Hagan’s workshop it’s easy. You just go to UIConf.com and you sign up for the three day event and you have to sign up right away because her session’s going to fill up. I got to tell you that. It always does. So UIConf.com. That’ll be November seven through nine.

Hagan’s going to do a full day workshop on the ninth on dealing with complex applications, how you make complex applications so much simpler. So I’m looking forward to that. Thank you Hagan for spending the time with us today and I’d like to thank the audience for once again encouraging our behavior. Take care. We’ll talk to you soon.

As we use a multitude of devices to access the same content, we expect a similar experience across platforms. If you have a great user experience on the desktop, it would be easy to rationalize that your mobile experience, for example, shouldn’t be painful. User experience professionals now need to consider how and where their applications and content are being accessed more than ever before.

Bill Scott knows this. Bill is the Director of UI Engineering at Netflix. Users can access Netflix on TVs, mobile devices, tablets, not to mention on the desktop. Bill believes that it’s not just the devices themselves, but also the context in which they are used that designers need to keep in mind. Developing rich interactions across all of these platforms can be a daunting task. Employing design patterns can help ensure that your users have a great experience wherever they use your product. Patterns develop a common vocabulary and create a shared understanding amongst the team.

Bill will be sharing more of his thoughts as well as examples of some patterns that work well, and some that don’t work so well, in his full-day workshop at the User Interface 16 Conference in Boston, November 7-9. Bill’s is only one of seven workshops at the conference. For more details visit UIconf.com.

Here’s an excerpt from the podcast.

“…It’s really about that shared understanding concept, where engineers have a shared understanding of business and design, and designers have the other two and et cetera. And marketing, you know, even educating them on what developers go through and what their process is at a very high level, gets everybody in the same ballpark where they really understand each other and get a sense for what’s hard, what’s easy, get a sense for the time crunch, get a sense for all those sort of things.

It sounds pretty touchy-feely, but I like the term “shared understanding.” I think that sort of captures the essence of it. You could put as much process or as little process to shared understanding. It could be very detailed wire-frames, or it could be just a hallway conversation, depending on what is needed for that organization in that context…”

Listen to the podcast to hear Bill address these points:

• Are design patterns about establishing a vocabulary?
• Is there any truth to the idea that patterns stifle innovation?
• Are patterns used more to lay out a path than to declare “absolute rules of engagement”?
• Do you ever push something out that is less than optimal and rework from there?
• How do you ensure that what you hand over gets implemented as you intend it to?
• Do you employ “hack days” to generate new ideas?

Do you use design patterns? Share your thoughts with us in our comments section.

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

Full Transcript.

Jared Spool: Welcome, once again, everybody to our current episode of the SpoolCast. I have with me today the wonderful Bill Scott, Director of UI Engineering at Netflix. And he’s going to be speaking at our User Interface 16 Conference on Monday, November 7th. The conference itself goes from Monday to Wednesday, November 9th, but he’ll be speaking in a full-day workshop on designing rich, interactive experiences, and that’s what we’re going to talk about today.

Bill, welcome.

Bill Scott: Hey, I’m glad to be here.

Jared: I’m glad to have you here. So, let’s just start talking here. I’ve known you for a really long time. You and I go way back. You were at Yahoo and before that at Sabre, and you’ve sort of always been in the center of what’s been happening in terms of this rich interaction stuff. Really bringing out over the web and through devices the ability to control and give access to data through all sorts of gestures beyond just a simple click of a button or a link.

How did you come to pick all that stuff up? What was your journey like?

Bill: I think my start, just to real quick go way back, was running one of the first games for the Macintosh actually, a game called GATO Submarine Simulation.

Jared: Oh yeah!

Bill: That was in 1985… early ’85, late ’84. And it was this whole thing of, we’ve got this new world with a mouse, with menus and icons, and how do you actually design a game? We didn’t actually have any examples in front of us, but we just thought we’d take the best of what was in that world and meld it into a video game.

And you know, I feel like we were pretty successful. That game was actually a best seller, number one on the best selling list for a while and at least the top ten the first year or two. Not a lot of sales compared to today’s market, but a lot for back then.

That really got me hooked on the power of — for example, we could add a mission editor for the submarines, right, and that wasn’t in part of the original spec. We just added that because we thought, well, with drag and drop and stuff you could create your own islands. You could create your own paths for the bad guys to come, and you know we added path editors and such like that. It was just so much easier to do with the mouse and everything. That sort of got me hooked.

And then, over time, I was always designing and developing together, because in the late 80s and early 80s and early 90s, there weren’t really that many disciplines that were pure user experience. You had to be in HCI or something like that. So it was always very pragmatic and always kind of tried to understand what were these emerging patterns? What could you do with technology, because there was always kind of a limit to what you could do.

That just kind of evolved over time into thinking about patterns. I remember discovering Christopher Alexander’s book on design patterns, and then finding some of Jenifer Tidwell’s work on cataloguing patterns for rich experiences, you know, for the desktop. That got me thinking.

Then as I moved to the web, I immediately went back to sticks and mud, because there was no way to do anything. You had that horrible request/response cycle, and you couldn’t do anything without refreshing the page. So we immediately started using some of the stuff in IE to get around that. This is early 2000, 2001, whatever. And then we finally, when Ajax came on the scene, when Google Maps came out, it really became possible.

So, at Sabre we were building a rich library, an Ajax library that would allow normal developers you know, that weren’t UI developers to actually create pretty good experiences without having to think too much about it. And so it behooved us to catalogue those patterns, and so we started documenting those and we started building a JavaScript library that we could release to the public, which was a slice of what we were doing at Sabre. That became Rico, which was one of the early Ajax libraries.

And in that we just saw the melding of showing examples of patterns as well as implementing those patterns. Because design patterns were a good way to bridge the gap, really, between design and engineering, because it creates a vocabulary. It names things that are hard to describe otherwise, instead of saying, “Well, you can take you mouse and you can click something.”

Of course, we have drag and drop, and we can say that in shorthand. That was a very early form of that in the early 80s. But as you go forward, things you know, page slides and hovers, accordions, and all those sort of things like that, and when are they good and when are they bad. I have sort of this reductionist mindset anyway, where I try to reduce things to simplicity. Maybe that comes from a software background, too, but I felt it played real well with the patterns.

Then, when I came to Yahoo and joined there as the Ajax evangelist, the Yahoo pattern library had already been started by Erin Malone and Matt Laycock. They had done a great job, but most of the patterns were really of the older school because this had just started emerging.

So I just started writing patterns for that pattern library. I had about 50 or 60 I added that were new, that were rich, and I started just cataloguing like crazy. At that time, in 2005, at Yahoo we were just starting to experiment with Ajax and get really into it and what could you do with the web, and it just led to more and more cataloguing.

Then, because I had actually written most of the patterns in the library, or at least half of them, I said to Erin Malone that, “Well, maybe I should, in addition to my other job, just take over the pattern library” since Matt was moving to something else. And so I did, and then we launched it as a public pattern library and got a lot of great feedback from what we put out.

And that just kind of kept me going down that path of doing that. But I’ve always felt like patterns were really about being able to take something and boil it down into just a few words so that I didn’t have to explain it over and over again, and you could just make it part of your toolbox.

Jared: Well, and this is interesting to me, because I was just discussing with somebody this week that I thought that a big piece of the value that comes from patterns just comes in establishing the language, the vocabulary. The sort of discussion of, what is it we’re trying to do, and what is that subtlety and nuance? And the more complicated these devices get, the more that subtlety and nuance happens.

Do you think that design patterns are really about that vocabulary creation, or is there another value that comes out of them that I’m missing?

Bill: No, that’s exactly right. And when we released the Yahoo design pattern library, you know, it wasn’t about, “Oh, hey, this is the only way to do it.” It was more about, “This is what we’re discovering. Let’s start a dialogue about this.”

There are people out there who are very, very semantic about the way they define patterns and go about and document those patterns. I appreciate those folks. I’m not one of those folks, because it’s like getting too far in the meta where you’re straining in a nat. And the reality, people just need examples. And I felt like that was actually the biggest contribution I was making was just collecting lots and lots of examples and putting those in the screen casts so that people could see those and associate those with an idea.

And then, once you have that picture there, that vocabulary, something somebody can see, you can talk about the nuance of it. You can talk about, well, why does it work in this situation and not this other situation? Because design is all about that nuance and the context.

And just exposing people that haven’t been through the design-thinking process, that maybe come from another background, there’s some very objective things but there’s also a subjective piece to it. The objective part is these patterns, but the subjective is how you apply them. And I think that helps a lot of people who especially don’t come from a design background. I think it helps people with a design background, too, but I know that what I’ve shared a lot seems to resonate especially with developers.

Jared: One of the things that came up in this conversation that I was having was that one of the folks felt that they’d seen design patterns used as a way to sort of stifle innovation. I’ve never seen it that way. His thinking was that the organizations that were using these patterns were being so rigorous about documenting and enforcing the patterns, more in a style-guide notion, that people couldn’t do things that made sense to do that fell outside of the patterns.

Whereas, when I’ve seen them used, they get used in less of an enforcement mode and more of a, “Here are what your options could be, and here’s the language you use to describe it. And if you come up with something better, that’s great. Just document it and add it back into the library.”

Bill: My hunch is that there definitely are groups like that, just like any bureaucracy. You have the police mindset, and you have the “I’m here to assist” mindset. When they become a resource, they’re good. When they become a stifling set of rules that have lost their context, right? That’s the whole thing. And you can’t crystallize these things. You can’t define every nuance and every context in those patterns. They get way too unwieldy.

I do know, in chatting with a few people, I’ve seen people try to go down that path, and I’ve tried to encourage them: “Don’t get hung up on the enforcement side of it. Really get excited about assisting and helping the teams and providing them with lots of resources and a common vocabulary. If you did just that, you would be successful.” But some people start to feel like they get measured by–they’re a central group in an organization. I was talking to a company a few months ago that’ll remain unnamed. A large social network. But anyway.

Jared: [laughs]

Bill: Anyway, I won’t go any further. Because there’s several of those, so I can leave it like that.

The people in the group were not of the ilk to do that, but I think they were feeling pressure that, well, shouldn’t they be getting more adoption? They were asking, “When you were at Yahoo, what was the adoption rate?” I said, “Not really that great, with our central guidelines and our central practices, but everybody grabbed the patterns idea and took it from a vocabulary perspective. So…”

Jared: Yeah, I mean, do you think that it’s really about making the designer and the teams that they work in a bit smarter and a bit more savvy, in terms of being able to talk about what they’re trying to do and sort of laying out a path that is proven, more than it’s about declaring what the absolute rules of engagement are?

Bill: That’s right. Yeah. Whenever you have groups that are seeking the best idea, the best solution, things work well. When people put some kind of stake in the ground, well, it’s like our political system today, right? You’ve got the two parties. It’s almost that same sort of mindset, where it’s no longer about solving problems; it’s about posturing and position. And I hate it. When the patterns come that way, I get very uninterested.

At Yahoo, we had a user group that I set up for pattern authors to join and I quickly lost interest in that mail list because there were these endless discussions about what was the canonical pattern, a pattern for a pattern.

Jared: [laughs] Oh God, that sounds miserable. [laughs]

Bill: And arguments about what kind of examples should you have, and whether they were four sections you should have versus eight sections. I don’t care. At the end of the day, the business has got to be successful, and design and engineering’s about bringing something to life.

Jared: Customers are not going to get excited because you’ve defined your patterns rigorously.

Bill: It reminds me of, this is back in the software world. I worked with a very bright engineer who had gotten the Gang of Four book, “Design Patterns for Software,” which was the first, really, application of Christopher Alexander’s patterns into the field of technology, and it’s a great, classic book. This was back in about, oh, probably ’94, ’93, something like that.

And one day he came around the corner and he had this big smile on his face, and he had the book in his hand and he was shaking it back and forth, and he says, “I did it!” I said, [laughs] “What did you do?” And he goes, “I’ve implemented all the patterns in this book in our software.” [laughs]

And a few years later, I’d left that company and I came back–actually, it was Sabre–and I came back, and through a quirk of a bunch of funding changes, for a while I ended up taking over his code, and was not a happy person, because that did not make better software, just applying [laughs] all the patterns blindly. So, same thing with design.

Jared: Yep. So, to sort of change directions here for a second, the work you’re doing at Netflix now, you’re involved in a lot of the day-to-day production of what goes out on the Netflix site, right?

Bill: That’s right, yeah. My job right now is much more focused. On purpose, I took a more focused role around acquisition. I hadn’t worked in that area before with marketing. And so it’s really around the sign-up flow and it’s around account services, probably what, in some ways, is seen as the less sexy stuff. I was involved with the member side for a good, long while, and still am tangentially.

But I just find it kind of fascinating to see just how fickle–that’s maybe one way to put it–the whole acquisition and conversion channel is. So it’s been an interesting education in that.

Jared: By acquisition and conversion, we’re talking about getting new people to realize that Netflix exists and then converting them into customers. And you guys have been moving into new countries, too, right?

Bill: That’s right. We’ve announced that we’re going into 43 countries in Latin America, and that will be in the not-too-distant future we will be launching that.

Jared: So there’s lots of new customers to acquire.

Bill: That’s right, and they’re different. They don’t have the same bandwidth. They don’t have the same movie watching habits, TV habits. They don’t have the same devices. They don’t have the same kind of payment methods. There’s a whole bunch of things that vary. Cultural differences, how you state things, you know all those sort of things come into play.

Jared: So now, what are you learning in terms of the rich interaction stuff that you can draw on to use in this new role that you’re focused on over there at Netflix?

Bill: Well, one thing we tried… And it’s interesting. This is a good example of where, even though you can do something, it may not be the thing that really works. So I’ll give more of a counter example I guess.

One of the things we experimented with was a single-page sign-up. So that, you just come to the page itself and you know, you do everything in one page and you’re signed up, that’s it. We’ve seen success around that with hotels and other things that have gone to a very simple flow like that.

The thing is, when we did that we actually saw a drop in acquisition, and our theory on that is because people need that second screen. They get the first screen, they put their email and a password in, and they need the second screen to really digest the whole payment area. And then, once they’ve done the payment they’re done. We’ve simplified the flow down to just the two steps and the confirmation.

But to get to that one step, we’re not there yet, and we’ve tried a few things. I think people need that break, go to the next page, digest the payment, feel comfortable that, this next step I’m going to actually be paying and not doing it in a one-step process.

So, even though we were doing a rich experience there, it ended up not actually working. We’ll definitely revisit it again with some different approaches.

Jared: Yeah, I mean, by bumping into these things you get a chance to learn what works better going forward. How do you get everybody involved in understanding what the goals are so you don’t push something out that is less than optimal? Or, do you push stuff out that’s less than optimal and then you just sort of regroup and figure it out?

Bill: Oh, yeah. That’s one of the mantras here is to fail often and fail fast. Everything you try is an experiment. A lot of times you don’t have full confidence. You have misgivings about some of the stuff you’re going to try. But you know you have enough volume that with customers, especially around the acquisition channel, you’ve got some pretty clear metrics about success or failure.

It doesn’t mean that, for example, that one-page sign-up would never work. We just may not have hit on the right way to do it yet, right? So you can’t throw out the whole concept. You can only say, “Well, with these particular tests it didn’t work.”

So what we do though is, you know marketing does a good job they’re, in essence, like our product managers providing us with a business context. And Netflix as a whole, there’s not any business information that’s not shared all the way down. It’s not just limited at the director level; it goes all the way down to employees.

So, everybody’s kept up to date on all the strategies and purposes and what we’re doing. There’s nothing hidden from the employees, which I think is really good. A lot of organizations don’t understand why the decisions are being made, and we have a very open culture about that. I think that kind of starts right at the top.

And then the business ideas are there, and then design and engineering understand that early. And then, in the process of, you know, raising issues and having conversations, it’s not like one team is just dictating and somebody goes off in a corner and implements without any knowledge. I’ve seen that happen in the past too many times, but we don’t do that.

Jared: Right. How do you make sure that when you’re designing something up and you’re handing it over to the folks who are going to implement this thing that … I guess there are two issues, right? One is, is that what you’re asking can be implemented, and second, that they get it enough that they can go off and do it the way you intend it to be happening?

Bill: Well, some of the things we’ve done in the past that have worked really well in that is, for a while to get everybody on the same page, we started having round tables where we get design and engineering together and have conversations.

Because design may put together their Photoshop assets in such a way that it actually causes a lot more work on the developers. And also, developers maybe have ideas or techniques that the design team doesn’t know about that are possible that are actually pretty easy to do that they could make part of their bag of tricks.

So, having an open forum that design and engineering can get together pretty informally, and not driven from top down but more bottom up. Anybody in the team can bring up a topic and make that the topic, or several topics, for the conversation. What that does is it gets vocabulary out in the open.

I remember the member design team. Some of the people in the member design team like to use the term “lockup,” because they came from an advertising background, describing the area where you have a box shot of the movie with the rating and whatever else goes around the particular movie title.

They call that a lockup, and half the developers didn&