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.

Hagan Rivers is a walking encyclopedia of web app design knowledge. A frequent speaker at our events, she has an amazing knack for making the highly complex digestible and easy to understand. Examining the structure of your application can reveal the places where your users struggle and provide you with opportunities.

In today’s UIEtips, we’re reprinting an interview that I had with Hagan about web application design. It was a fun discussion, talking about how she’s come up with the concepts, such as hubs, interviews, and her technique for diagramming the structure of web apps.

Read the article, Discovering Web App Structure: A Discussion with Hagan Rivers.

Hagan will also be bringing her expertise to an upcoming UIE Virtual Seminar, Designing Dashboards: The Do’s, Don’ts, and D’ohs!. She’ll show you a bunch of dashboards. And she’ll give you tips for helping stakeholders understand the implementation benefits and drawbacks of seemingly simple components, from graphs to customizable panels. You won’t want to miss it!

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.

In many ways, data visualization will take a message and make it more succinct. A good visualization can simplify the most complicated data, and often provide an interactive component with the user that a string of words can’t accomplish. The right data visualization will save the user time and provide a better experience.

In today’s UIEtips, Noah Iliinsky explores what makes data visualization so interesting. You might be surprised that biology has something to do with it.

Read the article, Why Visualization.

If you’re looking to tell a story through visualization, you’ll want to join us for Noah’s upcoming UIE Virtual Seminar on Thursday, February 2. Noah will show you how to choose an appropriate story for visualization then how to tell it. Learn more about his seminar.

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.

Opinion wars can get messy. They can stop a team in its tracks. And the worst thing about them is they can’t be won. There is never a winner in an opinion war.

The problem with opinion wars is their foundation. Let’s say you and I are in an opinion war. You strongly think that we should do some thing and I strongly think that thing absolutely the wrong thing to do.

For you to swing me over to agreeing with you that we should do that thing, you’d need to sway my opinion. And, if I’m going to convince you it’s wrong, I’ll need to sway yours.

However, swaying opinions is practically impossible. I’d like to think I’m a smart dude and my opinion is not just some random, unconsidered thought. Instead, I’ve based my opinion on my life’s experiences, which you haven’t had. Similarly, you’re a smart dude or dudette and your opinion is based on your life’s experiences, which I haven’t had.

To sway my opinion, you’d have to convince me to put aside everything my life’s experiences are telling me about this situation and take, completely on faith, your opinions. These are based on your life’s experiences, which I didn’t have. That’s really, really hard for me to do. It’s hard for anyone to do.

Opinion wars can’t be won. The only way to move past them is to subvert them.

Using Data to Subvert Opinion Wars

One way to subvert an opinion war is with data. In a design process, the data usually comes from user research.

If I believe there a right way to design something and your experience tells you that would be a sucky design, we have an opinion war. However, if we can get a prototype of that design in front of users, we’ll get real data to make the decision. We’ll no longer be working off our own opinions and experiences.

In almost every case where I’ve seen an opinion war, data about the users has completely dissipated it. Quite frequently, the data proves that neither side was completely right and that there was a completely different way to think about the problem.

All Hail The Arbitrator

Another approach to solving opinion wars is to appoint an final arbitrator. This person is chartered by the team to make decisions and every decision they make is final, no matter what others think about it.

We use this at UIE a lot. Each project has an owner. The owner makes all the final decisions for their project.

Often the project owner isn’t senior in the organization. In fact, they can be the person with the least seniority. They are not expected to ask permission. However, when they aren’t sure, they should ask advice.

Often the advice is conflicting and, occasionally, it’s strongly held. It’s this arbitrator’s responsibility to listen to all the advice and give it serious consideration. More importantly, it’s their responsibility to make the decision.

We’ve established a culture that says it’s the right thing to do make a decision, even if that decision turns out not to go the way people wanted. Even if that decision turns out, in the long run, to have not been the best approach. This is because a decision that moves us forward is better than getting stalled.

Opinion wars can kill a great project. Care needs to be taken to ensure they don’t get in the way.

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.

Physicists figured this out, creating a data model of the rush-hour traffic. They then compared the data points to that of the moving spring. The results looked practically identical. They can use this information to help design new systems to relieve traffic congestion.

Models like this help us know how to design better. They tell us why the same patterns keep forming before us and give us hints to take advantage of their predictive behaviors.

Here are some of the models we regularly use here at UIE:

The Kano Model

Made by Noriaka Kano, this model shows us the relationship of a customers satisfaction to the effort and investment we make our designs. We use this model to predict when a feature is something that will delight our users and when it’ll be a basic expectation, and the most important point: most delighters eventually become basic expectations.

Market Maturity

One of the first models we created, this shows the stages a technology goes through, with regard to how it’s market receives it. We’ve used this model to understand how an organization’s management perceives the importance of user experience. It also helps us prevent fatal timing mistakes, where competitors can overtake market leaders because they miss important cues.

The Four Stages of Competence

Noel Bursch’s model that describes how someone moves from incompetence to skill mastery. This model is a recent favorite of ours for explaining how to help our users master complex designs.

The Magic Escalator of Acquired Knowledge

We created this model to help teams understand how users perceive a design’s complexity. It shows us how to simplify designs and what happens when we introduce major changes.

The Scent of Information

This model shows us how users move through an information-rich web site. We can use it to predict when a design is easy to navigate and where it’s putting up obstacles to users getting into trouble.

Core vs. Ring

An old model that we’re finding useful in today’s world, as it explains how people behave differently when they’re doing something that’s core to their experience versus something that’s ancillary. It helps predict how much someone will stick with a bad design and when they’ll just give up.

Hands vs. Brains

This model talks about the people teams want to hire and how to best employ them. It predicts why some smart employees struggle in some jobs while others thrive.

Design Decision Styles

This model outlines five different styles for making design decisions. Using it, we can identify what a team needs to do to inform their decision making process. It also helps us tell when there’s a mismatch in the team’s composition or approach.

When we’re working with teams, we regularly mix and match the models. Complicated problems can usually be explained by combining several models, until we get new ideas for the solutions that move us forward.

What models have you been using? How are the useful?

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.

You’ll hear the latest insights on:

• Web forms and user input from Luke Wroblewski
• Application maps from Hagan Rivers
• Kickoff meetings from Kevin Hoffman
• UX leadership from Kim Goodwin
• Design principles from Bill Scott
• User culture from Steve Portigal
• CSS3 from Stephanie and Greg Rewis
• The value of UX in an organization from Brandon Schauer
• Making design intuitive from Jared Spool

Whether you refer to it for a quick reference or you schedule a group meeting to view one of the talks, it’s always available to you and your team, whenever you need it.

Special Pricing for a Limited Time
Until February 2, you can save $50 and purchase UI16 OnDemand for just $189.

Order UI16 OnDemand today!

Hidden interactions often frustrate users, as can be seen in any number of the online forums where game players get stuck with puzzles like this one. It’s even worse for non-game applications, where users aren’t interested in solving challenges, instead focused on getting their work done.

Gesture-based interfaces, like those we see in the growing world of touch interactions are often included without any visual clues for the users. How are users supposed to know they can take advantage of them?

In today’s UIEtips, I share some of the discussion Josh Clark, author of Tapworthy, and I had around this topic. We explore what the new world of touch gestures brings to designers, and how they have to be prepared for the demands of this new technology. Josh and I got into several important issues about how designers need to develop a new sense of touch, as it were.

Read the article, Developing a Designer’s Sense of Touch.

Next Thursday, you’ll want to join us for Josh’s new UIE Virtual Seminar, Buttons Are A Hack: The New Rules of Designing for Touch. Josh will show you how touch takes us beyond the desktop metaphor and buttons, and what you need to know to design for that journey. You don’t want to miss this!

I’ve been thinking about this question for a while now. Something was bothering me and I think I’ve figure it out.

Instead of thinking about ‘early adopters’ and ‘normals’ as if they are two homogeneous groups, I think it’s better to look at the motivations that trigger someone to buy into a new technology or solution at various points in the release timeline.  Here’s some of our research findings, as we try to understand when people take to new stuff:

People Who Are First

In our research, we’ve found three main reasons that someone adopts a product or service early on.

Being First to Gain Social Status

Many of the answers describing early adopters are talking about a select group of people who are the first to acquire new technologies and solutions — those with the motivation to be amongst the first. In our research, there are common themes of drivers for this motivation. 

These individuals tend to drive their social status by knowing the latest-and-greatest in what’s happening in the tech space. The people we’ve interviewed tell us they enjoy the thrill of having something before others, of knowing details about what’s happening, and of partaking in the ‘insider’ community of the tech world.

For these individuals, it’s a passionate avocation, sometimes professional, to collect and promote their newest items. They don’t need the products for what they do, they just want them to be at the leading edge of use. You can think of it like movie reviewers — they go to practically every movie, to serve as an informed authority for others in their influence circles on how good it is and what the salient features are.

These folks aren’t very loyal customers. In our research, they infrequently use something once another item comes out to replace it. (Plus, if they develop enough of a reputation, they are often given the first version, so they don’t even provide the initial revenue.) They are, in effect, an extension of the marketing machine for the product.

Being First as Product Research

There’s another group we found in our research: those folks who want to be first because they need to keep up for professional reasons. They are almost always in the tech community (or in fringe communities, like financial analysts that study the tech world). They buy the new to understand the core of the innovations that are happening.

Their interest isn’t in use, but in reverse engineering, on some level. They want to see what makes it tick and how to exploit any good ideas for other projects they may have.

These aren’t very loyal customers either. They don’t really care about the product or the company that made it, beyond what salient innovations they can take away.

Being First to Solve An Active Need

Unlike the other two categories above, this group jumps at a new product or service because it promises to solve a need they find very pressing. For these folks, they’re currently feeling pain and the new product or service is a solution.

Recently, we’ve seen this with the Toyota Prius (need: be more environmentally friendly and reduce gas consumption), Apple iPod (need: have music more available), Apple iPhone (need: a better mobile experience), TiVo (need: time-shifted television watching), Dropbox (need: share files across devices and with colleagues), and Cirque du Soleil (need: a grown-up circus).

What’s interesting is the folks who buy into these products early on don’t typically buy into just any products early. They have a real need and are willing to take the risks of the early product to resolve it.

This group isn’t responsive to brands per se, though a successful outcome will strengthen brand engagement. They don’t automatically buy other products from the same brand. (For example, most strongly-pleased iPhone customers didn’t purchase Apple TV, even though it’s a sister product.)

In some cases, the active need is because their existing solution is slowly killing them through what we call the “death of a thousand cuts.” They are feeling increasing pain with their existing solution and are looking for any compelling reason to move away.

Of the three groups I’ve mentioned so far, this is the only one who actually uses the product for more than experimentation. Unlike the other groups, the folks in this group’s successes and pain points are similar to what you’ll see with later groups. These are the folks to design for.

People Who Wait

What you’re calling the “normals” are people who wait to purchase after a new product or service is introduced. Like the folks who buy immediately, our research has shown there are several types of these people.

Waiting Because Unaware of Latent Needs

Like the folks solving for an active need, these people also have a need for the product or service. The problem is that they don’t realize that need yet. They are experiencing the same pains, but they haven’t actively identified that a solution exists, let alone the product or service that’s on the market.

Often, it isn’t until someone close to them, who encounters the same pains, shares how they’ve solved it with the product or service. Since they aren’t looking for the solution directly, they often are immune to any marketing beyond word-of-mouth. Even then, they might have to hear it from several members of their cohort before they act.

For these folks, the design needs to help convert the latent need to an active need. Once these people see the benefits from the point of view of an active need, they’ll be more likely to try out the product or service. The first interactions with the product or service need to address that need directly, without any friction or interference.

Waiting Because Of Perceived Cost Of Change

Change is costly for folks. For that reason, many typically approach it cautiously. Since people remember pain more vividly than pleasure, the pain of their previous changes are often upmost on their mind. A new product or service has to talk directly to the pain from that change to reach these people.

The cost of change comes in many forms. There’s the monetary implications of purchasing something new versus keeping the old thing. Free trials and other “try me” promotions can help with the money, but don’t get over the other forms automatically.

Also, there’s a cost of moving data and procedures to the new thing. For computer-based products, people have a ton of data they’d need to migrate over. They also have routines and rituals in their life that make the transition difficult. (For example, someone moving from one email client to another has to adjust their morning-check-and-reply rituals.) Designers who plan out this transition do much better than those who leave it to the user to figure out.

Another cost of change is the loss of competence with the new product. Using their existing solution, they’ve accrued a comfortable competence level that lets the product or service disappear, while the new one they have to learn everything all over again. (One of the smartest things Microsoft ever did was, when releasing Excel 3.0, creating a separate manual called Microsoft Excel for Lotus 1-2-3 Users. This guide directly translated the competence of the Lotus user to the new product.)

Waiting Out The Product Lifetime

A small, but firm group are the folks who, once have a working solution, will refuse to change until the product or service completely dies and is no longer an option. These folks will resist any new product or service until whatever they are doing just can’t be done.

In our research, we found successful design teams have each team member spend a minimum of two hours every six weeks watch real users interacting with either their design or a competitor’s design. The most successful teams have even more frequent exposure hours.

When team members watch someone use the design, several things happen. First, they gain empathy with that person — empathy that makes them sensitive to frustrations and delights the design imparts. That empathy is critical for setting design priorities, as we try to eliminate those frustrations and amplify the delights.

Second, the team picks up the culture of use. They learn the language the users use. They learn how users approach different parts of the design. They learn the goals of the users, and how the design fits into the users’ daily life.

Third, the team develops a design language to describe the differences between good and bad. Having the real experiences of real users as a common understanding breaks each team member of always referring to their own experiences. Instead of saying, “this is how I’d use it,” they can now say, “this is how Mary, who we saw last week, might use it.”

Fourth, because the exposure happens frequently over a long period of time, the team members see how their design attempts are working. It creates a feedback loop in their design process, where they learn when their design changes created the improved user experience they were seeking.

Innovation happens when you add value for the user. Teams with more exposure to how real people use their designs can more easily see opportunities for innovation. They can try new ideas to whittle away the users’ frustration and see how those ideas pan out. This makes them smarter and more informed, so they make better decisions in the long run.

In our research on personas, we’ve found this works best when the personas are based on real people doing real things. We regularly take teams into the field to meet their users and watch them interact in their own environments. We then capture the interesting bits to assemble our personas. We know we’ve done a great job when we can point to any element of the persona description and talk about the different real users we observed, doing and saying the same things.

What happens when we can’t do the research with the real users? Tamara Adlin does something she calls Ad-Hoc Personas, where the team gathers all the information they already know without doing any new research. Kim Goodwin does something similar that she calls Provisional Personas.

Because we often already know a lot about the people we’ve been selling our product to and supporting, we can build a decent picture of what they are like and what they need. If we combine different viewpoints, like those from sales, training, and support, it’s possible to surface a lot of interesting details to design with.

However, these aren’t as rich as the fully-researched personas we started with. It’s hard to separate out the mythology that forms around users from the reality. The advantage of going into the field is we can see where that mythology breaks down.

It’s possible we could go even farther away from the research by creating personas that are complete fiction. The team could ask, “What do imagine users might be like?” and “What do we think those users might do?” I guess it’s possible personas crafted from complete fiction like this can inspire the team to innovation, but it’s likely not better than self design, which would at a minimum have checks and balances of contact with someone using it.

The “persona purists” argue that completely fictional personas aren’t real personas at all. Their argument is that when we dilute the research component that goes behind the persona, we take risks that a design built from those personas won’t fit the needs of real users as well.

At UIE, we’ve seen multiple teams go down this fictional road, then end up with descriptions that nobody believed in. The team didn’t rally around it and the personas turned out to be a wasted effort. Because they were labeled “personas”, it was impossible to get those teams to buy into a subsequent well-researched persona project. They were completely turned off by the idea of personas and were against any future investment in them.

Should we come up with a different name for those things we create from pure fiction, like “user caricatures” or “fictional users”? (When I asked Kim Goodwin if she had a name for completely fictional personas, she called them “creative writing class exercise.” That sums it up pretty well, I think.) Should we go to efforts to explain that things without research aren’t personas?

What about the Ad-hoc Personas or Provisional Personas? Should we stop calling them personas too?

We don’t want personas to become diluted so much that the term doesn’t have meaning. How do we protect the value of these tools without getting lost in semantic mumbo-jumbo?

She concluded her post with this comment:

I’ve grown tired of people taking common sense, labeling it and then trying to christen it as a new process.

What jumped out at me was her implication that, just because it’s something she’s been doing, it must be common sense. I’ve heard this sort of thinking a lot. I guess it depends on the definition of common sense that you’re using.

There are two definitions I can see here:

1. Common sense is what I know to be true and how I judge the world.
2. Common sense is what is most commonly believed to be true and how most people judge the world.

These two definitions can only be simultaneously true if I believe the same things as the majority of people out there. Otherwise, they are in conflict.

Now, I’m at an interesting vantage point. As a researcher, I study what people believe. One area I study is what designers believe, particularly about creating great designs.

What I’ve learned in my research is that there are lots of different beliefs out there. Finding a majority belief is rare. And often, when we do, it’s not something that makes for the best designs.

Many folks are looking at Lean UX right now and saying what Lorena is saying: “It’s something I’ve been doing for years. What’s the big deal? Why do we have to give it a special name?”

But it’s not something the majority of teams I study are doing. Most are doing something more waterfall-ish, even when working in an Agile or Agile-ish environment. To them, this thinking is new. It’s novel. And it’s certainly not, from their perspective, common sense.

There’s an old saying: “There is nothing more uncommon than common sense.”

I’m wondering if we play the “it’s just common sense” a little too quickly and if that hurts our work.

Unconscious incompetence is the first of the Four Stages of Competence. In this stage, someone doesn’t realize just how much they don’t know. It’s a blissful state and, frankly a place that is wonderful.

Imagine not knowing what you don’t know. You can do practically anything you want and never run into the boundaries of quality. (As my former work colleague, Will Schroeder, used to say: “Once you remove quality from the requirements, everything becomes a whole lot easier.”)

Lots of what we call “unintended design” — design that’s the result of people focusing on the internal architecture or outside requirements instead of on the users’ experience — is the result of unconscious incompetence. When a team produces a horrific design, they don’t realize there’s a better way.

When I started in the computer field, almost all design was this way. Whatever way the code fell was how the design ended up. If the user had to jump through hoops to do simple things, well, too bad. They’ll learn how to use it in the training or read the manual or something. Or they’ll write up a software bug report and we’ll do something to fix it. (Or dismiss it as a PEBCAK error.)

An organization can get away with unconscious incompetence as long as all of its competitors are the same way. However, once a competitor becomes competent, the ballgame changes. Suddenly, there’s a pressure to learn what it takes — to become competent at the design process themselves.

It’s this transition that we see lots of organizations today. They are moving away from the bliss of not knowing to the stress and frustration of suddenly realizing there’s a ton they don’t know. It’s a painful transition, but one that is the start of an often fruitful journey.

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.]

I’ve met many of unconsciously competent users in my research. They are fast and efficient. When people talk about “power users”, these are the folks they have in mind.

Now, imagine what happens when you make a sudden, major change to your design — a change that rethinks and redistributes all the functionality and the way it’s used. Suddenly, those unconsciously competent users can no longer rely on their knowledge of the design. They have to think about things that they never had to think about.

That severe change you made to the design rendered those users, at best, consciously competent, and, at worst, consciously incompetent. They now have to think about how they get their work done, in addition to what they are trying to do.

In the worst case, they can’t figure out the new design because it’s so radically different from the design they are used to. Even if the new design is more efficient than past designs for other users, these users are rendered helpless because they are forced back to a world where they have to learn the interface.

This sudden loss of competence is even worse when, as often happens, there is no new functionality in the design. They are slowed down and made to feel incompetent without any new benefits.

If you really want to piss them off, do this as a software as a service (SaaS) automatic upgrade where they get no choice on the timing. At least, when a desktop app makes this type of severe design change, the user controls when they install it. But with SaaS, the service provide decides on the transition date, often without any warning or preparation.

If you’re wondering why your most effective users are really upset about sudden upgrades, I’d look to a sudden loss of competence.

This year was no exception, and one conversation that stood out was a quick discussion I had with Kim Goodwin, author of Designing in the Digital Age and who gave her workshop on designing with scenarios. While we were talking, we got on the topic of what questions designers need to know to create great designs.

Kim’s thinking is there are only five questions that are essential to creating great designs:

1. What is the user trying to accomplish?
2. What does the user need to know to accomplish their goal?
3. How should the user feel as they accomplish it?
4. How does the current design (or alternative) currently make them feel?
5. What did they do to accomplish it?

She boils it down to three essential components: Accomplish, Know, and Feel. If you understand what your user wants to accomplish, what they need to know, and how they want to feel, you’re well on your way discovering what’s necessary for your design to be great.

However, where I think Mr. Gruber gets it wrong is the value to the internal design team. The Apple Knowledge Navigator created a ton of discussion internally and set the company off on a 23-year journey that now brings us some amazing technology, which was impossible to imagine back in 1987 when the video first came out.

When an experience vision, like the Knowledge Navigator video, works, it gives the teams a chance to ask the question, “Am I getting closer to that design?” with every decision they make. It helps the team, as a whole, understand where it’s trying to go.

When teams don’t have a vision like that, each person is walking around with a different understanding of what the end of the journey should look like. When there’s no common understanding on what that end point looks like, each decisions is evaluated on a different criteria and the resulting products end up looking like crap.

I think the Microsoft and RIM videos are interesting. However, there’s too much in there. Apple’s Knowledge Navigator was simple in its delivery, covering only a few concepts. There are so many concepts in each of these new videos that I find it hard to believe the design teams can talk about what they are really trying to say.

I’m also betting that Microsoft and RIM have made classic mistakes: the visions represented in these videos are not put together by the teams that will be working towards them. They were likely created by marketing folks (and, even more likely, by outside agencies with no connection to the internal product development and design teams). It’s possible that the developers and designers at these companies saw the videos at the same time we did.

Unless the design and development teams have a voice in what their future is, they are unlikely to buy into it and will probably take their designs in a different direction. Team collaboration on the vision is critical for success.

I don’t think these visions need to be publicized to be useful. And, as Mr. Gruber asserts, it’s brings into focus the failings of the current products when they do.

However, there is real gold in having a solid vision and these videos can be a great way to represent that vision within the organization.

However, if we didn’t make proper arrangements before we took the job, it’s very likely we can’t show much of our work to anyone. Consultants, contractors, and full-time employees are usually covered (in the US at least, but most other places as well) by a “work for hire” agreement, which means that the people we work for own all the work product we produce.

Wireframes, sketches, and other deliverables are not ours to show. If the final design isn’t publicly visible, such as internal application, there might not be any evidence of what we’ve done.

This puts us in an uncomfortable position when it comes time to show our work to a prospective employer. How do we show what we’re capable of when we don’t have access to our work?

Some have advised that you can put your company’s work files into a “for your eyes only” confidential portfolio, asking the hiring manager to keep what they see a secret. While it’s unlikely you’ll get caught doing this, does it send the message you want to someone thinking about hiring you? After all, it could be interpreted that you don’t take company policies, like confidentiality, seriously and that may not be a great first impression.

Fortunately, a smart hiring manager should understand this dilemma well. They’ve seen others with it and probably have faced it themselves when they interviewed at the company. Those smart hiring managers will look for other evidence of your talents and skills.

What can you put into your portfolio when your work is all locked up?

The simple answer: Fill your portfolio with stories.

When we’ve talked to the hiring managers behind some of the best design teams, we’ve seen that they are less interested in the final products and more interested in how the candidate got to those products. They’re interested in the story behind each design more than the designs themselves.

A good hiring manager wants to hear what the project goals were. They want to hear what you were given to start with. They want to hear the major challenges you faced, and how you overcame them. They’re interested in who else was on the project and how well you worked together. They want to hear about that guy who was always in the way and what you did to work around his objections and obstacles.

A great design portfolio tells the story about your designs, even if it can’t really say much about the design’s specifics.

To prove you know what the work products are, you can fake those. You can create wireframes, sketches, and other deliverables for side projects. In addition, you can mockup what your work would’ve looked like, without giving away the details that your employer wants to keep secret.

But the best designers talk about their journey. And the ones with the best stories are the ones that get hired. Especially when the new job is filled with exciting adventures.

One cause is that we tend to think of complexity as a holistic effect. We try to decide if the entire design is complex or not. However, it’s easier to realize where your design is baffling your users if you hone in on what your users do and don’t know, and what they need to know to accomplish their objective.

In today’s UIEtips, I explore a simple visualization tool we invented to help teams and stakeholders see where their designs are too complex for their users and what they can do about it. I call this tool the Magic Escalator of Acquired Knowledge and, as you’ll see, it can be quite effective for getting the entire team working on making an easier-to-use design.

Read the article, Riding the Magic Escalator of Acquired Knowledge.

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.

But that’s different than a critical exploration of what we’re trying to do. Where we learn what it takes to make a great design. Where we explore both the problem space and the possible design solutions.

I ask teams whether they do critiques. “Oh, yes. All the time,” they tell me.

However, when I ask them what it is they do, it’s basically a meeting where someone’s work is criticized for what it’s missing. It’s a meeting where people who haven’t given the design problem or solution much thought, until that moment, rip apart the work of someone who has.

These critical design reviews are miserable experiences. Everyone completely dreads them. The experience makes them feel like crap. And then it’s time to schedule another one.

I’ve been working with teams to change that. We’ve taken the traditional studio critique process and brought it into the modern world.

What makes a critique different from a critical design review is we are not there to find flaws. We’re there to learn from the design and to explore where it works well and where it could be improved.

In a well-run critique, we explicitly separate out the discussion of “What are we trying to do with this design?” from the discussion of “Does this rendition accomplish it?” By separating out these two pieces, we avoid digging into the designer’s work just because they unaware of a critical requirement or need.

The critique technique we use has a structure. First, we start each session with a brief introduction to the technique, for all those folks who are participating for the first time.

Then the designer describes what they were trying to accomplish with their design. What was the problem? What were the priorities they took under consideration? What did they bring from what they learned in previous critiques?

If everyone in the room agrees, we can move on. However, if someone thinks we’re solving the wrong problem or that we didn’t take the right priorities into account, now’s the time to speak up and discuss it. (Ideally, we would’ve discussed these things before the designer put the hard work into the design iteration.)

Then the designer shows us what they’ve done. They specifically talk to what the design is trying to do, telling us what they were thinking and how they solved the important problems. The goal is to not only show us the final design product, but to give us the thinking behind it, opening up their rationale.

After the designer has shown everyone what they did and why they did it, everyone starts with what they liked. After all, there’s something to like in any designer’s work.

Pointing out the likes isn’t just an exercise to be nice and respectful. It helps everyone understand the qualities that are desirable. (This is one place where criticism-focused design reviews often fail miserably.)

The audience also now can explore the design. Often this is done, not with critical commentary, but with exploratory questions. “Have you thought about how users will share the photos with their friends?” “Have you considered how the application works when there’s no network connectivity?”

By posing their thoughts as questions, the designer can say whether they’d thought about that issue or not. If they have, it gives them a nice chance to talk about their thinking. If they haven’t, well, they just say, “No, hadn’t thought about that yet.”

Of course, we record all the things that come up — what people liked and what questions they had. At the end of the session, we review them, to make sure we’ve captured everyone’s thoughts.

While we avoid group design in these sessions, we do encourage conversation that helps us explore what we’re trying to do. The designer takes what they heard and integrates it into their next iteration, presenting it at the next critique.

Team using this process tell us they get a ton more out of each session, enjoying the process of learning about their designs. It also doesn’t hurt that the designs they’re producing show a marked improvement.

But something is still missing. Though we are making progress and laying groundwork in large organizations, many UX teams still struggle with getting the necessary time and resources to do their jobs as effectively as possible. To continue growing our profession in both influence and in number of good designers, we need to find a sense of leadership.

In today’s UIEtips, we’re reprinting a fabulous UX Magazine article by one of our favorite people, Kim Goodwin. The difference between management and leadership is a great one. Kim believes that UX leadership should contain things such as mentoring and providing vision. Leadership itself is a skill that should be grown along with UX expertise.

Read the article, On UX Leadership.

In addition to her full-day workshop at User Interface 16, Kim will be giving a 90-minute talk, Experience Leadership. Kim will explore how we develop a broad view of what a UX leader is and how we develop both practice leadership and change leadership skills. Join us for UI16, November 7-9 in Boston. You won’t want to miss it!

We had been working on a client project, helping their team redesign their checkout process with some new user research and design techniques.

As we were watching seasoned shoppers buy products in the lab, we noticed that people were getting stuck at a screen right before the checkout process, where they had to authenticate their account. Repeat customers couldn’t remember their user ID and password combination. The site used an email address as the user ID, but many of our repeat customers had set up their accounts years before and couldn’t remember which of their email addresses was the ID.

In the lab, the customers who couldn’t authenticate would either give up or request a password reset. However, the password reset required they remember which email address was their ID, which many couldn’t do. We witnessed a remarkable number of abandonments on the password reset screen.

When the password reset was successful, the customer had to go to their email client, find the reset message (often lost in a spam folder), and click on a link in the email. In the lab, we observed that this was a complex process.

All of this led us to ask if this was only happening in the artificial environment of the lab, because we watching users in our space, not using their own machine. We set out to look at the site’s analytics to see if there were clues to this behavior happening in the real world.

The first thing we asked the analytics team was what percentage of visitors to the authentication page ended up on the reset password request screen. Turns out, they had never instrumented either page. We had to wait three weeks while they instrumented it and we collected a reasonable sample size.

We learned a substantial percentage of customers were requesting password reset, approximately 40%. Two out of every five users was getting stuck and needing their password to be reset.

We then wondered what percentage of those people actually came back to finish the transaction after the reset. Again, we discovered the analytics team hadn’t instrumented the return from the reset. That was another three week delay.

We learned that fewer than 25% of the resets were executed — the user clicked on the reset link and returned to the site. Of those who did execute it, fewer than 20% finished their purchases.

A little math and we could calculate out the amount of revenue being abandoned in the carts by all the people who couldn’t authenticate. That’s where the $300,000,000/year number came from.

Once the team implemented a guest purchase capability (which didn’t require authentication to start the checkout sequence), they saw an immediate jump in sales increase of about $6,000,000 in the first week, which remained constant. Password reset requests dropped by about 80% in that first week and remained constant too.

Authentication pages are usually owned by a different group in the company. In this case, they were owned by IT. IT didn’t have the foresight to instrument these pages.

Until we did this research and asked these questions, nobody knew how many people were dropping off at authentication. Because authentication was between the shopping-cart and the Enter-your-shipping-info pages, everyone thought they were getting a much lower percentage of users clicking the Checkout button than they really were. The site had a huge abandonment on authentication that heretofore had gone undetected.

Analytics only work when we know that they are measuring everything correctly. Working with clients, we regularly discover they aren’t capturing the entire picture, leaving out critical information.

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…

Everyday, more companies are recognizing the value of design. They are realizing they need to have strong design to compete in the marketplace. They see their competitors, even the small ones that don’t offer as full a feature set, are eating away marketshare because they have better designed products.

No place manifests this more than Silicon Valley. Designers, especially good ones, can call their shots there. Companies are in a bidding war for talent.

That means, if you’re a good designer, you have to ask yourself: are you in the right place, right now?

Milton Glaser gave a speech a few years back. He talked about two types of relationships: those that energize and those that exhaust. Milton said he learned, the hard way, that he needed to regularly prune away those relationships that exhaust, focusing on the ones that energize. That was his advice to happiness.

If you’re a good designer, are you in a place where your work energizes you? Or does the organization you work for exhaust you, because it hasn’t realized how important design is to its own success?

Now, it’s not that every day will be free of frustration. But if you’re regularly energized, it’s much easier to face the tough challenges. When you’re exhausted by your work every day, the challenges often feel insurmountable.

When a company doesn’t get the importance of design, it’s rough being a designer there. You constantly have to explain what you do. You have to fight for the simplest things, like the time and resources to do research (and often fail). You see, everyday, how your work could be so much better if you had the right tools, the right support, and enough time to make it work.

It’s scary to think about change. But right now, the timing is right for designers. If the job you’re in isn’t the right one, you owe it to yourself to look at what your options could be.

If you decide you should explore the world of opportunities, think about what you’d want in your next job. A company that values design will push off a ship date because the product’s not well enough designed. Ask if the company has ever done that — that demonstrates whether they have their priorities aligned with yours. Delaying a launch is a hard call. Having done it means they are serious.

Look for other evidence they understand design. Do they take the time to do research? Is everyone in the team involved? Do they iterate frequently? Are they learning good things from each iteration?

These are the signs that a company wants to learn what the best designs are. That yearning to learn makes the workplace really exciting for designers who are innately curious and autodidactic.

It’s a good time to be a designer. Every day should energize you. Are you doing everything you can to make sure that happens? After all, you owe it to yourself.

I remember always being impressed with the pictures and talking about the Colosseum and the Roman Forum. Yet nothing could prepare me for my first trip to Rome. It wasn’t anything like the pictures.

I think this is exactly the same feeling that designers have when they visit their users for the first time. Sure, they’ve heard about users and what they’re like through the various sales and support channels. Maybe they even met one or two in their travels.

But seeing your users really work with the design is a whole different world. It changes the way you work and think about what you’re building.

In today’s UIEtips, I explain why I love taking teams out on their first site visits. It’s really exciting to see the transformation the designers undergo as they open up a new world. The metamorphosis they go through is really fun and exciting.

Read the article Why I Love Taking Teams On Field Visits.

If you’ve always wanted to go on your own field visits, you’ll want to get the best techniques from Steve Portigal, who is a master at these things. His User Interface 16 Conference full-day workshop will be a ton of fun. You’ll go on your own site visit and analyze the results – an amazing education. Check out how much fun it’ll be.

I asked (on the Twitters, of course) what was the first application to use the pull-to-refresh gesture. My world of followers suggested it was the original Tweetie app, which was then acquired by the Twitter overlords. Since Tweetie, it’s shown up in a bunch of apps on my iPhone. I’m told it’s also on apps all over those Android phones that everyone talks about.

What’s interesting about the pull-to-refresh gesture is how natural it feels. Need more stuff, pull down on the list. Very simple. Very intuitive.

Well, it’s only intuitive if you know about it. You see, the problem is the gesture has no affordance (a hint or clue that the function exists). There’s no way to know where pull-to-refresh is implemented. Anyone who has learned the gesture has probably experienced the pull-to-do-nothing function in all the apps where it’s not implemented. Suddenly, something that’s novel has become a basic expectation, just like Kano taught us it would.

If you didn’t know about pull-to-refresh, how would you learn it’s in your app? For the most point, it requires you learn it from someone else.

Someone who leans over and says, “Hey, did you know you can update your list by just pulling down on your thumb?”

“No Way!” is the usual response, followed by the now-common thumb maneuver. “Cool!” is what comes next.

And it happens. Just like that. We’ve just transmitted the functionality, socially.

Pull-to-refresh isn’t the only socially-transmitted functionality. In years past, it’s how I’ve seen people learn about drag-and-drop in applications. It’s how they learn about special keys, like F5 for refresh or F1 for help. A lot of functionality has been transmitted from one person to the next, socially.

There’s nothing wrong with socially-transmitted functionality, as long as it’s not something the user needs (they can use the design just fine without it) and you have users that talk with each other. The problem comes from when you, as a designer, know about an functionality that only transmits socially, it’s hard to realize that people around you haven’t caught on yet. Just because it’s in your pattern library doesn’t mean your users will know about it.

[A note about accessibility: socially-transmitted functionality is rarely accessible in itself, as it usually has no way for a screen reader to work. For accessibility reasons, you probably want alternative access.]

In a recent site visit, I watched users struggle with navigating around a web app because the return-to-main-menu function was a not-obvious icon that looked like decoration to the untrained eye. All the developers observing the visit knew about it, but this collection of users hadn’t been infected with the knowledge of the functionality, and therefore didn’t use it. Their alternative: sign out of the app and back in again, which returned them to the top-level menu. (Boy, did that ever elicit a sigh of wonderment from the observation party!)

Do you have socially-transmitted functionality in your design? Are they things that users can live without and will be delighted when they hear about it from a friend?

We’re celebrating this year’s User Interface 16 Conference’s fantastic program by giving everyone access to last year’s great show. The recordings and slide decks contain these great topics:

• Engaging team members in the design process
• Developing a content strategy
• Designing for mobile
• Evangelizing design within the corporate culture
• Understanding styles of decision making
• Incorporating testing and prototyping
• Making successful personas
• Evolving design ideas
• Creating a UX library

You’ll hear from these top UX experts: Luke Wroblewski, Kristina Halvorson, Nathan Curtis, Dan Rubin, Leah Buley, Dave Gray, Kim Goodwin, Tamara Adlin, and Jared Spool.

How to get the free recordings?

It’s easy. Just sign up by October 13, 11:59 PM ET and you’ll get last year’s UI15 talks and materials for free. No tricks, no gimmicks. We’ll send you an email with details on how to access this bundle of goodness.

Now hurry and get last year’s UI15 recordings before October 13, 11:59 pm ET.

She’s been a designer for a long while now, having worked on some impressive projects and developed real skills. As she described the different projects, I could tell, however, that something was missing: how would she grow?

Don’t get me wrong. Each project was pretty neat and jam-packed full of cool challenges that every talented designer would want to sink their teeth into.

I suggested she direct her search in a different direction. I told her to focus on who her next manager should be.

In my job, I get to meet a lot of great designers, some of whom are working on projects that, to an outsider, might be considered dull: accounting applications, chemical analysis equipment, and even tax forms. Yet, they love their work, not because of the subject matter of the project, but because they have a great manager that makes every day fun and challenging (in the good way).

I’ve also met designers who are working on some of today’s sexiest design problems — working with the latest technologies on cutting edge, high visibility, society-changing designs. And they’re miserable because they have a manager that makes each day hard and frustrating.

When you have a great manager, the project barely matters. And when you have a crappy manager, the project barely matters.

The advice I’m giving to senior, more experienced folks is not to think about their next project as much as they think about their next manager. What traits should that manager have? How do they support their team? When things get rough, how do they deliver guidance? Do they regularly give out praise? Do they take a deep interest in the work and in their employee’s future?

I recommend folks interview the entire team and learn what it’s like to work for that manager. What happens when the going gets tough? What examples are there of team members growing, learning, and getting encouragement? Do team members talk about how the manager exhibits the desired traits?

My good friend, Amy Jackson, who works as a talent agent for wünderkind UX designers, suggests you take it a step further and ask the hiring manager for his or her references. Amy says to tell them you want to make the right decision and you need to check them out. Her thinking is that if the hiring manager isn’t secure enough give out sound references, they may be sending a signal. I think there’s something to that.

Great managers are what make a job great. Are you thinking about what you’d like to see in your next manager?

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.

Right now, few things are hotter topics that mobile in the design world. With the burst of smartphone and tablet technology, the mobile design landscape has just exploded.

With this new landscape comes a new way of thinking about design. It’s no longer about filling every pixel on the screen and implementing a multitude of different functionality.

The smaller screen demands that we hone our functionality down to it’s bare essentials. It means letting the content drive what we do, instead of putting the actions first. And it requires we rethink the basics of interaction, as touch gestures offer more flexibility than the mouse pointer.

Nobody has thought more about what it means to design for mobile that Luke Wroblewski. For the past few years, he’s been touring the world with a detailed explanation of what it takes do create great mobile experiences.

We’re really excited that he’s joining us for UI16. If you think mobile is in your future, you need to make sure you attend his full-day workshop. There you’ll learn everything there is to know about making a fabulous, interactive mobile web experience.

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.

Back in 1987, Apple (under the direction of John Sculley, not Steve Jobs), released a video of what Apple products could be like in the future. Called the Knowledge Navigator, it showed a sci-fi mythical tablet computer from 23 years in the future (yup, 2010) that the user talks with to get things done.

Fast forward 24 years and Apple releases Siri with the new iPhone 4S. Siri is an assistant that takes voice commands and acts on them. If you haven’t seen Siri, here’s a demo.

Now, as far as I know, Siri is only available on the iPhone 4S. However, that’s likely temporary, as I don’t believe there’s anything that prevents it from showing up on other platforms, like the iPad.

And once it shows up on the iPad, Apple will have fulfilled it’s 1987 quest. All the components of the original Knowledge Navigator are now available and for less than $500.

In ’87 — when we all used big, boxy CRTs on bulky, loud, slow desktop processors without any notion of communications beyond 9,600 baud (14.4 came in 1991) — there was no way you could have a small, tablet computer to do all the things in that video. Knowledge Navigator was complete science fiction to everyone at that point. Computers couldn’t speak. You couldn’t imagine face-to-face video conferencing across the planet, let alone collaborative workspaces. None of that had been invented yet, except as sci fi.

Yet, if we look close, it’s the path Apple has been on for 24 years. We’ve seen the baby steps. With the introduction of the Mac Book, then the iPhone, followed by the iPad, we got our table. The interwebs provided the connectivity, where Apple focused on its Airport wireless products to get the components tiny. Innovations like built-in cameras and Facetime made the video conferencing a reality.

And now Siri completes the journey. Siri isn’t quite the bow-tied dude who can order a cake for your mother’s birthday party, but it’s damn close. (And I’m not convinced we need avatars to believe the computer is speaking. I think Second-Life ruined avatars for everyone, except those who enjoy online virtual sex.)

In 1987, when Apple first rele