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.

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!

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.

You’ll Learn to:

• Play the project game in a different way
• Replace passive collaboration with active collaboration
• Integrate UI design with user stories
• Make UX planning part of the project rhythm

You already know that UX decisions touch every part of a project. But integrating them with Agile to communicate, estimate, and deliver the product is critical to winning.

After this seminar, you’ll be ready to knock it out of the park.

The Next Step Series

The Next Step Series will feature Rosenfeld Media authors covering critical user experience topics just like they do in their Rosenfeld Media books. And by teaming up with UIE, you’ll experience the great format and quality production values you’ve come to expect from our 90 minute-long live seminars.

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.

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?

Of all the major airlines, United has the best service out of Boston. The only other options if you need to travel all over the country are American, Delta, and US Airways. Those three options deliver far worse service than United does.

This means, if I was included in a UA Net Promoter survey, I’d give them a 7 or above. That’s a good score for Net Promoter.

My score is a great demonstration of why Net Promoter doesn’t work. You see, I hate United Airlines. With a passion. As airlines go, they are really quite bad. I fly them almost every week and almost every trip, I have some experience with poor service and a bad relationship. Granted, there have been some trips where nothing bad happened, but nothing remarkably good happened either.

However, my trips with American, Delta, and US Airways are much worse. I will continue to fly United until someone better comes along, but I don’t expect that to happen any time soon. (I do like Virgin America a lot, and JetBlue or Southwest, but they don’t fly where I need them go as reliably as United, so I can’t use them often.)

I’m not recommending United Airlines because I like them. I’m recommending them because they are better than the other choices.

Net Promoter isn’t scoring my loyalty, because I’m not loyal. (I’m trapped, which is quite different.)

It’s not capturing my overall dissatisfaction with the airline. In fact, if everyone answers the survey for the same reasons I do, they look pretty good.

I think Net Promoter Score is an ineffective instrument for measuring how your customers feel about you. A better instrument is something more rigorous, like the Gallup CE11 Customer Engagement Score.

The CE11 has eleven questions, which we weight (as a Guttman Scale), including a Net Promoter-like referral question. But that referral question is weighted low, with questions like “Do you think [the brand] would take care of you if there was a problem?” or “I’m proud to be a customer of [the brand].” There are businesses that I’d score high on these other questions, but United Airlines wouldn’t be one of them.

These days, many of our clients are relying on the Net Promoter instrument (and its close brethren) to assess how they are meeting their customers needs. We warn the teams we’re working with to be careful — they may not be getting a complete picture of what’s happening and how their customers are experiencing their designs.

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.

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.

That’s what the legal secretary told me when we were studying her firm’s intranet home page. In fact, the page was pretty sparse in layout. The text was nicely laid out in a readable font, with different weights given to headings and body text. Overall, it was organized and readable. Cluttered just didn’t seem like the right word.

Yet, the legal secretary was quite firm on this. She wasn’t the only one. Half of the firm’s employees we interviewed used the word “clutter” to describe the page that looked anything but cluttered to us.

It might be tempting to rework this home page with more whitespace, more organization, more emphasis on the visual design. However, that wouldn’t have produced any better results.

Over the years, we’ve learned that users have a different meaning of “clutter” than the designers do. It’s not the visual design the users are reacting to. It’s the actual content.

The law firm employees were telling us that the page didn’t have links and resources they needed. The page was full of stuff — mostly things the firm’s marketing group wanted everyone to know — but very little of what was on the page helped the employees do their jobs. Everything they needed was on the intranet, and they knew it, but the home page didn’t lead them to it.

The page was cluttered.

Clutter is what happens when we fill a page with things the user doesn’t care about. Replace the useless stuff with links, copy, and content the users really want, and the page suddenly becomes uncluttered.

Dictionary.com’s definition of Clutter is found on a page, ironically, filled with clutter.

That’s exactly what we did at the law firm. Our design team uncovered those resources the users needed and organized the page to have exactly what the users needed to do their jobs well.

Those users loved the new page. In our evaluations, nobody used the word clutter. They used words like useful, helpful, and awesome.

Here’s the best part: We put the old and new pages side-by-side. The new page definitely had more text, less whitespace, and more dense information design. Yet, when we asked the users to tell us which one was more cluttered, they were unamimous: the old design was the cluttered design.

Are your users complaining about clutter? Maybe you should look at what they actually are seeing.

Now, if we’re building enterprise accounting software, why do we need to know whether Mary has a schnauzer or Wilbur drives a Hummer? There’s nothing those details will help us in the design.

Every detail in a persona description should help inform decisions in the design. Because of that detail, we should have no trouble saying what we’d do. When we’re working on accounting software, knowing they are a PC or a Mac user could be important. Knowing that our persona visits their customers and need up-to-the-minute inventory data on the road is likely to be critical. But what does it matter what car they drive?

I call this problem the “Dog and Hummer Trap.” It’s when the design teams takes their persona descriptions just a little too far.

However, this client team was different. They were designing a searchable database of home improvement projects.

Pets and cars, in fact, are important. The team wanted to have a way to identify “pet friendly” projects, where they provided special instructions for keeping safe from the hazards of construction.

They also wanted to help users figure out how they’ll get the materials home. A SUV carries more than an Mini Cooper, so the make of car matters.

The Dog and Hummer Trap isn’t specifically about dogs and cars. It’s about making sure you’re focusing on those details that’ll make a difference in the design.

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.

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?

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 released the video, they received a fax (!) with a purchase order for the Knowledge Navigator. Now they can finally fill the order.

In the next UIE Virtual Seminar, Rich Rutter gets you started with JQuery—assuming no prior knowledge—and shows you lots of examples, hints, and tricks. Just 5 minutes into this seminar, you’ll see JQuery in action and have something you can use in your own wireframes.

Employ Simple Show and Hide Techniques

The essence of JQuery is to find something and do something to it. This technique easily shows different page states so your team and test participants can “do things” to your design.

• See, step-by-step, how to put this simple, yet useful example of JQuery in action
• Use modules and plug-ins to make your design to do simple things, without worrying about the performance of production code

Toggle Wireframe Annotations

Add notes to your interactive design.

• Turn your comments on or off depending on who’s viewing your design
• Add lists, comments, or direction for developers and others who need to work with your design

Fake Simple Ajax Interactions

Without creating production level code, get your design to quickly and easily do its thing—click something and change occurs—for your developer or client.

• Replicate what happens when you click something like a “favorite button”
• Fill in all the steps of an Ajax interaction such as a slight delay or adding different page states on a single page

Get Started with JQuery UI Widgets

Rich will introduce a library with options and widgets that you can easily put in place. In many cases you’ll see how to simulate what the full interaction could be.

• Explore modal dialogues, an intrusive piece of interaction and a good example of something you want to test: Do I really need a modal, or is a link better?
• Get more examples: Prototyping calendars, lightboxes, and more.

Rich will show you the power of combining discreet interactions together with a complex interaction.

Regardless of your JavaScript experience, this seminar will be a great way to start using JQuery and take your interactive skills to the next level. JQuery gives us a clean, interactive feel, and can be the difference between a slick design and something annoying or disruptive. It brings rich interactivity to your HTML and CSS3.

Rich will incorporate complex interaction examples along with providing excellent sources of documentation and tutorials for your toolbox. The seminar will keep theory to the bare minimum and focus on getting you started with practical takeaways you can use straight away.

The real power in what you’ll learn is getting very close to a final look and feel of your intended design with just a bit of effort and without having to build the whole application. Get over the initial hurdle of the JQuery learning curve and gain momentum in your design process. Join us for JQuery for UX Designers.

As we use a multitude of devices to access the same content, we expect a similar experience across platforms. If you have a great user experience on the desktop, it would be easy to rationalize that your mobile experience, for example, shouldn’t be painful. User experience professionals now need to consider how and where their applications and content are being accessed more than ever before.

Bill Scott knows this. Bill is the Director of UI Engineering at Netflix. Users can access Netflix on TVs, mobile devices, tablets, not to mention on the desktop. Bill believes that it’s not just the devices themselves, but also the context in which they are used that designers need to keep in mind. Developing rich interactions across all of these platforms can be a daunting task. Employing design patterns can help ensure that your users have a great experience wherever they use your product. Patterns develop a common vocabulary and create a shared understanding amongst the team.

Bill will be sharing more of his thoughts as well as examples of some patterns that work well, and some that don’t work so well, in his full-day workshop at the User Interface 16 Conference in Boston, November 7-9. Bill’s is only one of seven workshops at the conference. For more details visit UIconf.com.

Here’s an excerpt from the podcast.

“…It’s really about that shared understanding concept, where engineers have a shared understanding of business and design, and designers have the other two and et cetera. And marketing, you know, even educating them on what developers go through and what their process is at a very high level, gets everybody in the same ballpark where they really understand each other and get a sense for what’s hard, what’s easy, get a sense for the time crunch, get a sense for all those sort of things.

It sounds pretty touchy-feely, but I like the term “shared understanding.” I think that sort of captures the essence of it. You could put as much process or as little process to shared understanding. It could be very detailed wire-frames, or it could be just a hallway conversation, depending on what is needed for that organization in that context…”

Listen to the podcast to hear Bill address these points:

• Are design patterns about establishing a vocabulary?
• Is there any truth to the idea that patterns stifle innovation?
• Are patterns used more to lay out a path than to declare “absolute rules of engagement”?
• Do you ever push something out that is less than optimal and rework from there?
• How do you ensure that what you hand over gets implemented as you intend it to?
• Do you employ “hack days” to generate new ideas?

Do you use design patterns? Share your thoughts with us in our comments section.

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

Full Transcript.

Jared Spool: Welcome, once again, everybody to our current episode of the SpoolCast. I have with me today the wonderful Bill Scott, Director of UI Engineering at Netflix. And he’s going to be speaking at our User Interface 16 Conference on Monday, November 7th. The conference itself goes from Monday to Wednesday, November 9th, but he’ll be speaking in a full-day workshop on designing rich, interactive experiences, and that’s what we’re going to talk about today.

Bill, welcome.

Bill Scott: Hey, I’m glad to be here.

Jared: I’m glad to have you here. So, let’s just start talking here. I’ve known you for a really long time. You and I go way back. You were at Yahoo and before that at Sabre, and you’ve sort of always been in the center of what’s been happening in terms of this rich interaction stuff. Really bringing out over the web and through devices the ability to control and give access to data through all sorts of gestures beyond just a simple click of a button or a link.

How did you come to pick all that stuff up? What was your journey like?

Bill: I think my start, just to real quick go way back, was running one of the first games for the Macintosh actually, a game called GATO Submarine Simulation.

Jared: Oh yeah!

Bill: That was in 1985… early ’85, late ’84. And it was this whole thing of, we’ve got this new world with a mouse, with menus and icons, and how do you actually design a game? We didn’t actually have any examples in front of us, but we just thought we’d take the best of what was in that world and meld it into a video game.

And you know, I feel like we were pretty successful. That game was actually a best seller, number one on the best selling list for a while and at least the top ten the first year or two. Not a lot of sales compared to today’s market, but a lot for back then.

That really got me hooked on the power of — for example, we could add a mission editor for the submarines, right, and that wasn’t in part of the original spec. We just added that because we thought, well, with drag and drop and stuff you could create your own islands. You could create your own paths for the bad guys to come, and you know we added path editors and such like that. It was just so much easier to do with the mouse and everything. That sort of got me hooked.

And then, over time, I was always designing and developing together, because in the late 80s and early 80s and early 90s, there weren’t really that many disciplines that were pure user experience. You had to be in HCI or something like that. So it was always very pragmatic and always kind of tried to understand what were these emerging patterns? What could you do with technology, because there was always kind of a limit to what you could do.

That just kind of evolved over time into thinking about patterns. I remember discovering Christopher Alexander’s book on design patterns, and then finding some of Jenifer Tidwell’s work on cataloguing patterns for rich experiences, you know, for the desktop. That got me thinking.

Then as I moved to the web, I immediately went back to sticks and mud, because there was no way to do anything. You had that horrible request/response cycle, and you couldn’t do anything without refreshing the page. So we immediately started using some of the stuff in IE to get around that. This is early 2000, 2001, whatever. And then we finally, when Ajax came on the scene, when Google Maps came out, it really became possible.

So, at Sabre we were building a rich library, an Ajax library that would allow normal developers you know, that weren’t UI developers to actually create pretty good experiences without having to think too much about it. And so it behooved us to catalogue those patterns, and so we started documenting those and we started building a JavaScript library that we could release to the public, which was a slice of what we were doing at Sabre. That became Rico, which was one of the early Ajax libraries.

And in that we just saw the melding of showing examples of patterns as well as implementing those patterns. Because design patterns were a good way to bridge the gap, really, between design and engineering, because it creates a vocabulary. It names things that are hard to describe otherwise, instead of saying, “Well, you can take you mouse and you can click something.”

Of course, we have drag and drop, and we can say that in shorthand. That was a very early form of that in the early 80s. But as you go forward, things you know, page slides and hovers, accordions, and all those sort of things like that, and when are they good and when are they bad. I have sort of this reductionist mindset anyway, where I try to reduce things to simplicity. Maybe that comes from a software background, too, but I felt it played real well with the patterns.

Then, when I came to Yahoo and joined there as the Ajax evangelist, the Yahoo pattern library had already been started by Erin Malone and Matt Laycock. They had done a great job, but most of the patterns were really of the older school because this had just started emerging.

So I just started writing patterns for that pattern library. I had about 50 or 60 I added that were new, that were rich, and I started just cataloguing like crazy. At that time, in 2005, at Yahoo we were just starting to experiment with Ajax and get really into it and what could you do with the web, and it just led to more and more cataloguing.

Then, because I had actually written most of the patterns in the library, or at least half of them, I said to Erin Malone that, “Well, maybe I should, in addition to my other job, just take over the pattern library” since Matt was moving to something else. And so I did, and then we launched it as a public pattern library and got a lot of great feedback from what we put out.

And that just kind of kept me going down that path of doing that. But I’ve always felt like patterns were really about being able to take something and boil it down into just a few words so that I didn’t have to explain it over and over again, and you could just make it part of your toolbox.

Jared: Well, and this is interesting to me, because I was just discussing with somebody this week that I thought that a big piece of the value that comes from patterns just comes in establishing the language, the vocabulary. The sort of discussion of, what is it we’re trying to do, and what is that subtlety and nuance? And the more complicated these devices get, the more that subtlety and nuance happens.

Do you think that design patterns are really about that vocabulary creation, or is there another value that comes out of them that I’m missing?

Bill: No, that’s exactly right. And when we released the Yahoo design pattern library, you know, it wasn’t about, “Oh, hey, this is the only way to do it.” It was more about, “This is what we’re discovering. Let’s start a dialogue about this.”

There are people out there who are very, very semantic about the way they define patterns and go about and document those patterns. I appreciate those folks. I’m not one of those folks, because it’s like getting too far in the meta where you’re straining in a nat. And the reality, people just need examples. And I felt like that was actually the biggest contribution I was making was just collecting lots and lots of examples and putting those in the screen casts so that people could see those and associate those with an idea.

And then, once you have that picture there, that vocabulary, something somebody can see, you can talk about the nuance of it. You can talk about, well, why does it work in this situation and not this other situation? Because design is all about that nuance and the context.

And just exposing people that haven’t been through the design-thinking process, that maybe come from another background, there’s some very objective things but there’s also a subjective piece to it. The objective part is these patterns, but the subjective is how you apply them. And I think that helps a lot of people who especially don’t come from a design background. I think it helps people with a design background, too, but I know that what I’ve shared a lot seems to resonate especially with developers.

Jared: One of the things that came up in this conversation that I was having was that one of the folks felt that they’d seen design patterns used as a way to sort of stifle innovation. I’ve never seen it that way. His thinking was that the organizations that were using these patterns were being so rigorous about documenting and enforcing the patterns, more in a style-guide notion, that people couldn’t do things that made sense to do that fell outside of the patterns.

Whereas, when I’ve seen them used, they get used in less of an enforcement mode and more of a, “Here are what your options could be, and here’s the language you use to describe it. And if you come up with something better, that’s great. Just document it and add it back into the library.”

Bill: My hunch is that there definitely are groups like that, just like any bureaucracy. You have the police mindset, and you have the “I’m here to assist” mindset. When they become a resource, they’re good. When they become a stifling set of rules that have lost their context, right? That’s the whole thing. And you can’t crystallize these things. You can’t define every nuance and every context in those patterns. They get way too unwieldy.

I do know, in chatting with a few people, I’ve seen people try to go down that path, and I’ve tried to encourage them: “Don’t get hung up on the enforcement side of it. Really get excited about assisting and helping the teams and providing them with lots of resources and a common vocabulary. If you did just that, you would be successful.” But some people start to feel like they get measured by–they’re a central group in an organization. I was talking to a company a few months ago that’ll remain unnamed. A large social network. But anyway.

Jared: [laughs]

Bill: Anyway, I won’t go any further. Because there’s several of those, so I can leave it like that.

The people in the group were not of the ilk to do that, but I think they were feeling pressure that, well, shouldn’t they be getting more adoption? They were asking, “When you were at Yahoo, what was the adoption rate?” I said, “Not really that great, with our central guidelines and our central practices, but everybody grabbed the patterns idea and took it from a vocabulary perspective. So…”

Jared: Yeah, I mean, do you think that it’s really about making the designer and the teams that they work in a bit smarter and a bit more savvy, in terms of being able to talk about what they’re trying to do and sort of laying out a path that is proven, more than it’s about declaring what the absolute rules of engagement are?

Bill: That’s right. Yeah. Whenever you have groups that are seeking the best idea, the best solution, things work well. When people put some kind of stake in the ground, well, it’s like our political system today, right? You’ve got the two parties. It’s almost that same sort of mindset, where it’s no longer about solving problems; it’s about posturing and position. And I hate it. When the patterns come that way, I get very uninterested.

At Yahoo, we had a user group that I set up for pattern authors to join and I quickly lost interest in that mail list because there were these endless discussions about what was the canonical pattern, a pattern for a pattern.

Jared: [laughs] Oh God, that sounds miserable. [laughs]

Bill: And arguments about what kind of examples should you have, and whether they were four sections you should have versus eight sections. I don’t care. At the end of the day, the business has got to be successful, and design and engineering’s about bringing something to life.

Jared: Customers are not going to get excited because you’ve defined your patterns rigorously.

Bill: It reminds me of, this is back in the software world. I worked with a very bright engineer who had gotten the Gang of Four book, “Design Patterns for Software,” which was the first, really, application of Christopher Alexander’s patterns into the field of technology, and it’s a great, classic book. This was back in about, oh, probably ’94, ’93, something like that.

And one day he came around the corner and he had this big smile on his face, and he had the book in his hand and he was shaking it back and forth, and he says, “I did it!” I said, [laughs] “What did you do?” And he goes, “I’ve implemented all the patterns in this book in our software.” [laughs]

And a few years later, I’d left that company and I came back–actually, it was Sabre–and I came back, and through a quirk of a bunch of funding changes, for a while I ended up taking over his code, and was not a happy person, because that did not make better software, just applying [laughs] all the patterns blindly. So, same thing with design.

Jared: Yep. So, to sort of change directions here for a second, the work you’re doing at Netflix now, you’re involved in a lot of the day-to-day production of what goes out on the Netflix site, right?

Bill: That’s right, yeah. My job right now is much more focused. On purpose, I took a more focused role around acquisition. I hadn’t worked in that area before with marketing. And so it’s really around the sign-up flow and it’s around account services, probably what, in some ways, is seen as the less sexy stuff. I was involved with the member side for a good, long while, and still am tangentially.

But I just find it kind of fascinating to see just how fickle–that’s maybe one way to put it–the whole acquisition and conversion channel is. So it’s been an interesting education in that.

Jared: By acquisition and conversion, we’re talking about getting new people to realize that Netflix exists and then converting them into customers. And you guys have been moving into new countries, too, right?

Bill: That’s right. We’ve announced that we’re going into 43 countries in Latin America, and that will be in the not-too-distant future we will be launching that.

Jared: So there’s lots of new customers to acquire.

Bill: That’s right, and they’re different. They don’t have the same bandwidth. They don’t have the same movie watching habits, TV habits. They don’t have the same devices. They don’t have the same kind of payment methods. There’s a whole bunch of things that vary. Cultural differences, how you state things, you know all those sort of things come into play.

Jared: So now, what are you learning in terms of the rich interaction stuff that you can draw on to use in this new role that you’re focused on over there at Netflix?

Bill: Well, one thing we tried… And it’s interesting. This is a good example of where, even though you can do something, it may not be the thing that really works. So I’ll give more of a counter example I guess.

One of the things we experimented with was a single-page sign-up. So that, you just come to the page itself and you know, you do everything in one page and you’re signed up, that’s it. We’ve seen success around that with hotels and other things that have gone to a very simple flow like that.

The thing is, when we did that we actually saw a drop in acquisition, and our theory on that is because people need that second screen. They get the first screen, they put their email and a password in, and they need the second screen to really digest the whole payment area. And then, once they’ve done the payment they’re done. We’ve simplified the flow down to just the two steps and the confirmation.

But to get to that one step, we’re not there yet, and we’ve tried a few things. I think people need that break, go to the next page, digest the payment, feel comfortable that, this next step I’m going to actually be paying and not doing it in a one-step process.

So, even though we were doing a rich experience there, it ended up not actually working. We’ll definitely revisit it again with some different approaches.

Jared: Yeah, I mean, by bumping into these things you get a chance to learn what works better going forward. How do you get everybody involved in understanding what the goals are so you don’t push something out that is less than optimal? Or, do you push stuff out that’s less than optimal and then you just sort of regroup and figure it out?

Bill: Oh, yeah. That’s one of the mantras here is to fail often and fail fast. Everything you try is an experiment. A lot of times you don’t have full confidence. You have misgivings about some of the stuff you’re going to try. But you know you have enough volume that with customers, especially around the acquisition channel, you’ve got some pretty clear metrics about success or failure.

It doesn’t mean that, for example, that one-page sign-up would never work. We just may not have hit on the right way to do it yet, right? So you can’t throw out the whole concept. You can only say, “Well, with these particular tests it didn’t work.”

So what we do though is, you know marketing does a good job they’re, in essence, like our product managers providing us with a business context. And Netflix as a whole, there’s not any business information that’s not shared all the way down. It’s not just limited at the director level; it goes all the way down to employees.

So, everybody’s kept up to date on all the strategies and purposes and what we’re doing. There’s nothing hidden from the employees, which I think is really good. A lot of organizations don’t understand why the decisions are being made, and we have a very open culture about that. I think that kind of starts right at the top.

And then the business ideas are there, and then design and engineering understand that early. And then, in the process of, you know, raising issues and having conversations, it’s not like one team is just dictating and somebody goes off in a corner and implements without any knowledge. I’ve seen that happen in the past too many times, but we don’t do that.

Jared: Right. How do you make sure that when you’re designing something up and you’re handing it over to the folks who are going to implement this thing that … I guess there are two issues, right? One is, is that what you’re asking can be implemented, and second, that they get it enough that they can go off and do it the way you intend it to be happening?

Bill: Well, some of the things we’ve done in the past that have worked really well in that is, for a while to get everybody on the same page, we started having round tables where we get design and engineering together and have conversations.

Because design may put together their Photoshop assets in such a way that it actually causes a lot more work on the developers. And also, developers maybe have ideas or techniques that the design team doesn’t know about that are possible that are actually pretty easy to do that they could make part of their bag of tricks.

So, having an open forum that design and engineering can get together pretty informally, and not driven from top down but more bottom up. Anybody in the team can bring up a topic and make that the topic, or several topics, for the conversation. What that does is it gets vocabulary out in the open.

I remember the member design team. Some of the people in the member design team like to use the term “lockup,” because they came from an advertising background, describing the area where you have a box shot of the movie with the rating and whatever else goes around the particular movie title.

They call that a lockup, and half the developers didn’t know what the heck a lockup was, and once that was explained with the background … That came out through the round tables. I don’t think it would have ever come out and disseminated in normal hallway conversations or anyone would have sent an email about it.

It’s putting people together. It sounds pretty simple, but actually it’s one of those things we forget. It’s sort of like, how do you understand users? Well, you get with users, right? Obviously there’s more to it than that, but often those very, very simple things don’t happen.

So like, for example, the brand marketing design team, I’ve spent time with them. I did an HTML5 presentation, CSS3, et cetera and walked them through what is possible first on WebKit, because our TVs and our devices, our new devices that we’re going onto, most of them support WebKits, so we have all the capability of WebKit for those.

And then for the website, you know, what are the current browsers we’re supporting? What can they do in the HTML5 world and CSS3 world, et cetera, versus what can be done in flash? And those sort of conversations have been really helpful to them.

So, it’s really about that shared understanding concept, where engineers have a shared understanding of business and design, and designers have the other two and et cetera. And marketing, you know, even educating them on what developers go through and what their process is at a very high level, gets everybody in the same ballpark where they really understand each other and get a sense for what’s hard, what’s easy, get a sense for the time crunch, get a sense for all those sort of things.

It sounds pretty touchy-feely, but I like the term “shared understanding.” I think that sort of captures the essence of it. You could put as much process or as little process to shared understanding. It could be very detailed wire-frames, or it could be just a hallway conversation, depending on what is needed for that organization in that context.

Jared: I think that the shared understanding has got to be critical. And I think, when I look at the organizations that we work with that really struggle at getting good designs out, you can go back to surprises that happen in the process, where it comes from people not having that shared understanding, you know, “What do you mean that’s difficult to implement? You did it over there.” Or, “How come that’s going to take five weeks? Isn’t it just a simple changing of a few words?”

They just don’t have a sense of what’s going on. Of course, on the other end, it’s the devs and designers saying, “What do you mean that when you click here, it has to go to this other screen you didn’t tell us about, or it has to produce a message, or you’re going to want to extend this in the future to have these other options?”

Bill: That’s right. Yeah, exactly.

Jared: And so that shared understanding piece really does make a lot of sense. One question I have in terms of this is you had shared with me a while back that you guys were doing all this cool hack day stuff. Do you still do that on the acquisition side? You have a hack day type thing that happens?

Bill: Well, it happens company-wide. So it happens with facilities, where they may be doing something around hacking the phones. [laughs] It could be the content team, hacking stuff down in Beverly Hills, hacking together with some engineers. I did a hack with them a year or so back where you could go to Google Map and zoom in somewhere and see all the films that were shot in that location. Right?

Jared: Oh, cool.

Bill: And then, for fun, I added a little extra dimension in it where there was two little buttons. One was Mars and one was the moon. You could click on Mars, it brought in a Google Earth plug-in and flew you out to Mars and showed you some of the movies that were shot on Mars. [laughs]

Jared: Very cool.

Bill: [laughs] It was a joke.

We’ve had a number of things come out of the hack days. One thing we continue to test is how to find related content really easy, kind of like the six degrees of separation, Kevin Bacon kind of thing, right? We had a “more like this” kind of feature that came in in one of the hack days, where you have a page where the movie sits in the middle and then all the other movies that are related to it in some fashion are around it, and then you click one of those, it slides to the middle and more come out around it. We actually implemented it on the site. It didn’t test too well.

Of course, what we find out often with the media consumption we do is that anything that feels complicated at all, people don’t tend to do. It has to be really simple. But what’s happened is that thought has continued to have, I don’t know, at least maybe six or eight different incarnations. None of them have actually fully worked yet.

We have one example on the device that worked better than control. And on device, on our TVs–PS3, I think it was, we were testing this–you had a row showing up on your TV, and when you move your arrow back and forth and land on a movie or a TV show, below it, the next row, is all the related content. And if you go down to one of those and select it, then the row below it becomes related to it. So it’s almost like a tree navigation, but it’s just rows, right? That actually did pretty well.

The problem is, how do you integrate that back into something like the normal experience, where you’re showing just, here are your areas of interest, which we call sub-genres, or micro-genres, we’ve built and based out of your taste input and what you watched and stuff, like quirky, funny movies from the 1700s. I don’t know.

Jared: [laughs]

Bill: So, how do you tie that into that? So there’s some tests around doing that that are coming out to play with that.

Jared: So the neat thing about the hack days is, do you feel that has a huge effect on the shared understanding? I mean, do things sort of burst out of that and people go, “Oh”?

Bill: Yeah, I do. I think there’s a lot of stuff, like some technologies on the edge, that not everybody’s getting a chance to play with that somebody brings in. Like when the Kinect stuff first came out, you know, there was a pretty cool hack around that and sort of opened some thinking up around some other stuff.

Real early on, some guys had hacked the iPhone so you could control the Roku player with it. And those were quite interesting. But a lot of it is just you sort of get a chance to see what other people consider to be problems they’re trying to be solve. Right? What are the itches that are trying to be scratched around the organization? And I think that’s pretty helpful.

Jared: So in November, you’re going to join us and spend an entire day sharing this wealth of knowledge you have, and the stuff that went into your book and a variety of insights and details and videos and techniques on building interactive stuff. You’re going to show us how to deal with the flow in the application, how to deal with input, how to deal with responsiveness and all the sort of techniques that you’ve put together. I’m really looking forward to this session.

Bill: I am, too. I did a workshop similar to this, but this has more material, especially now adding a little bit with the device world and tablet and TV and mobile back in Lisbon. And the workshop went really, really well, and people seemed to really enjoy it. I know it sold out really fast. So I’m hoping the same interest is here in this. I believe it will be.

Jared: I think it will.

Bill: And really, I guess people that are considering whether to come to something like this, my goal is to make it as pragmatic as possible. When people hear “patterns,” sometimes they think of the theoretical. It’s not at all. It’s really just about lots and lots of examples that work well and don’t work well. And when you come out of the workshop, what you really should have, I think, is just a pretty rich vocabulary of what’s possible and what maybe to avoid, and then you can go back and share that with the team and have a toolbox. Expanding your toolbox is really what it’s about.

Jared: Cool. I’m looking forward to getting my toolbox expanded.

Bill: [laughs]

Jared: Excellent. Thanks for taking the time to talk about this with me today.

Bill: I’m always happy to talk, Jared.

Jared: Excellent.

Bill: And to talk with you is icing on the cake.

Jared: There you go. And I want to thank our audience for joining us today and for supporting everything we do. And, as always, thank you for encouraging our behavior. You can see Bill at the User Interface 16 Conference in November. November 7th through 9th. You can find out details about that at uiconf.com. Hope to see you there. Thank you very much.

Everybody strives to arrive at the end of a project with a great design. But often times the “brilliant idea” isn’t easy to communicate and takes a long time to develop. Brandon Schauer believes that you can develop techniques to help this communication, arriving at good design in shorter amounts of time.

Brandon is President and Managing Director at Adaptive Path. He feels making your ideas tangible is key. By putting your ideas on paper and post-its, and getting everyone participating, you create a collaborative environment that allows these ideas to grow and develop. Brandon also feels that the ideas should require some explanation in order to bring that understanding to the entire team.

As luck would have it, Brandon will be teaching the Good Design Faster workshop at the User Interface 16 Conference in Boston, November 7-9. He’ll be showcasing his approaches to developing innovative designs in record time during this full-day workshop. For more details about Brandon’s and the other 7 full-day workshops, visit UIConf.com.

Here’s an excerpt from the podcast.

“…You really have to attack the most critical part of the problem first. And so you often end up [with] what I would call donut prototyping or donut solutions. You build out a ring of all the things you already know to be true. Like, we know the style guide that we’re going to be applying to this. We know the constraints of the platform. Let’s just go ahead and start filling all those parts of the puzzle in, and you build this donut around the true core part of the problem. You feel like you’re going to slowly sneak up on it, because you’re constraining all the other variables.

You really need to chase after that center of the donut, that really big unknown part of the problem, first. Usually that has to do with the big cases of flow. Like, how big is this experience? How do we structure it? What’s the first thing people encounter? How do we make sure they recognize the true differentiators? Or the real true strengths of what this new product or service brings?

You think you’re going to sneak up on it by filling in all the known parts. Ultimately you get to it, but that’s too late to solve the problem…”

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

• Whose job is it to bring out the product ideas?
• Should you get executives and developers involved with sketching and coming up with ideas?
• Should you filter the ideas or get them all on the table?
• What value do games have in the generative process?
• What are some of the biggest obstacles teams face when generating ideas?
• What’s the difference between a flow and a wireframe?
• Do the sketch boards live on throughout the project?
• What do you do when the team has different opinions about user needs due to lack of data?

What are your experiences with generating ideas during the design process? Share your thoughts in our comments section.

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

Full Transcript.

Jared Spool: Welcome, everyone, to another episode of the SpoolCast. And I am speaking to you today from our lovely offices in North Andover, Massachusetts. And on the other side of the country, in their lovely offices at Adaptive Path, I have the fabulous Brandon Schauer. Brandon, how are you today?

Brandon Schauer: I’m good, I’m good. I have a little bit of a cold, but hopefully that’ll bring the deeper, sexier voice to the audience.

Jared: Yes, well it’s working for me right now. So, Brandon, I hope you know this, but the rest of our audience may not. If you don’t know this, then I’ve screwed up somehow. You’re speaking at our upcoming User Interface 16 conference. You’re giving the “Good Design Faster” workshop. Did you know that?

Brandon: I did, and in fact, I would even say I’m happily speaking. I’ve been part of one UIE conference before, and was very excited to meet the folks there and I liked the talent and some of the ideas that even the folks brought forward to the workshop, so I’m looking forward to getting engaged with you all again.

Jared: Yeah, so, this is going to be in Boston, November 7th through 9th. It’s the second year that – or is it the third year? I’m trying to remember now. Leah did this twice, I think, before. Leah Buley had done this in the past, but you’re bringing it to us this year, and I’m very excited to have you doing that, because you bring a whole different sort of viewpoint to it. It’s a great workshop, and it was our highest rated workshop the last couple years. And I expect it to be the same this year.

And what’s really interesting about it – I remember walking in on the session at the end of last year. There was all this stuff on the walls. They had been busy designing… There were a hundred and some odd people in the room, and they just didn’t stop designing from the moment they walked in, in the morning, to the end of the day. It’s probably the most productive workshop there. If we could somehow turn that into electricity, we could actually power the entire conference.

Brandon: Awesome. Yeah, I think volume is certainly one of the techniques we’re using to get to “Good Design Faster,” and so you see a lot of it and you feel a lot of it. I think that’s one of the exciting things for folks is the ability to take that same sort of energy, then take it home with them and put it into the work they’re doing every day, and spread that kind of energy internally.

It’s something our clients love when we’re engaging with them that way, and I think there’s a reason why some of the techniques of “Good Design Faster” have really started to permeate through our practices in the industry.

Jared: Now, the point of this workshop is to give people a set of tools – a whole boatload of tools, in fact – to be able to take a project and just get to the really good ideas as fast as possible. And in a lot of teams that I work with, the team seemed to struggle with knowing whose job that is. Is it the product owner or the product manager or you know do the executives get together and sort of hand down the Tablets of Thought that is going to go be in the product? Is it going to be the marketing people? Does it come directly from the customers? Is that what the designer’s supposed to do? There seems to be all this question around whose job is it to bring out the product ideas?

And my sense is that you’ve got a big opinion on this.

Brandon: Well, I’d say, we would all love to hear, like, “It’s the designer’s responsibility. It’s the user experience people’s responsibility to bring forth the product idea.”

I think that’s crap. I think that it depends greatly – I think there’s a lot of creativity and a lot of ideas that exist in all sorts of different disciplines. Sometimes a great idea comes from someone on the front line who’s seeing and hearing about the customer support problems every day.

Sometimes it can be a clairvoyant rare leader who really knows what’s necessary. Sometimes a good product solution needs some technical creativity, someone who realizes the possibility of how to solve a customer need that no one else knew could even be done, but they have the technical know-how and insight to see a really technically creative solution for a product.

So, from my perspective, the user experience designer can do a lot to create the right situation for great product ideas to emerge, that the user experience designer can bring customer requirements to the forefront to make sure that customer need and the customer voice is part of what’s injected into a session to find the right ideas.

But then the right ideas really need to be made tangible, so that the brilliant idea you have isn’t stuck in your head, but everyone can see it. And I think that’s too often the case is that I can talk about a brilliant idea, but no one else quite gets it. Everyone has their interpretation stuck in their head.

So the more we can do to get our ideas out there and make them tangible so that everyone can point, look at, and even make them better, that’s great, and the tendency to which we can also get great ideas out there and then move on to the next great idea, which is often even better of an idea. That’s what we really need to pursue.

So, the fact that one lone function within an organization can really possess all the great product ideas – I think that’s what “Good Design Faster” is built to thwart, is get around that belief and allow ideas to come from wherever they might be able to come from, and for everybody to be able to evaluate which ones are really the great ideas.

Jared: When you say “make them tangible,” we’re not talking some 120 page UI design spec here.

Brandon: Exactly. I think the faster you can get your ideas tangible at the lowest resolution possible, the better you’re going to be able to get to the idea that really makes a difference. So we’re talking Post-It note size ideas scribbled – and we like it when everyone’s participating in drawing, when everyone has a pen in their hands, regardless of you’re background or discipline or comfort level with it.

An idea shouldn’t be something that you can put in from of the average Joe on the street and that Joe or Josephine knows exactly what you’re talking about without interpretation. We like ideas to take a little bit of, “Hey! Look at these couple of boxes here. Here’s what I’m thinking is going on here.” But it still has some richness to it, that you’ve really captured an idea, put it out there in the world for everyone to see, even at a low resolution, so that you can look across a lot of ideas, you know? A dozen, two dozen ideas before you really find out which one’s the core idea that really works.

Jared: So, when you’re putting all these ideas out there, you’ve got everybody on the team doing that at this point, right? So you’ve got, if you’ve got executives in the room, they’re doing some of that, and if you’ve got other folks from the various projects, you know, developers or whatever – they’re also drawing and sketching and putting these ideas out there?

Brandon: Absolutely. I think the more the better, if you can really host a situation like that within an organization. It works really, really well. What we like to do is bring the customer voice, the need, so it’s not endless sketching of anything, but that you’ve actually prescribed a particular type of flow for a particular type of user to stimulate the right kind of ideas. So you really have to kind of cultivate the right kind of idea generation session.

But then also separate the generative from the evaluative. Before anyone starts questioning whether an idea is good or not, let’s get a lot out there on the table. And it doesn’t really matter where it comes from, which function within the organization, as long as it’s out there on the table. You can find out pretty quickly ideas start to merge and ownership even starts to fade away. That it’s not really clear who brought up the idea, but really the value becomes the idea itself and how appropriate it is.

So making it tangible stops it from becoming the idea that’s attached to the highest opinion in the room or the most senior person in the room. It becomes which one really works and which one doesn’t.

Jared: When you’re saying “generative,” are you talking about just trying to get really good ideas on the table, or is this without any sort of filtering?

Brandon: I think it’s without a terrible lot of filters. Like I said, you do want to provide a framework, a setting by which people can come up with the right sort of ideas.

Sure, some crazy ideas certainly have had their place and can help you move on to maybe things that are more appropriate. But if you know who the user is we’re designing for, what their motivations and behaviors are, what possible technologies you might be looking at to address those needs, you’re probably going to have some pretty productive ideas within some of those constraints, but great design solutions can come out of smart provision of constraints.

But I think at that point, we’re really then looking for generating as much within some certain boundaries, so just think – what would be a good food reverse recipe application for a hand-held device, let’s say, for a tablet? You might just assign the problem of, “OK. You’ve got these foods in your refrigerator. You’re trying to figure out what you could cook with them. What’s the starting screen? What’s the first moment with that kind of an application that you might have?”

There are a dozen, several dozens of ways you might design that first moment for a particular type of user.

Jared: I believe it’s agreeing to the terms and conditions, isn’t it?

[laughter]

Brandon: Absolutely. And figuring out the – do you pay for a $1.99 now or after the trial?

Jared: Exactly, exactly. Plus, signing up for our email!

[laughter]

Brandon: Because that’s the first moment you want to have.

Jared: That’s the first moment – is to sign up to find out if you want to get our email forever.

Brandon: But, exactly, that helps you get through, like, “Oh, wait. Those are the stupid ideas that we might add on.” So what’s the real first moment we want to design for? How do you really start someone into letting them know that the potential of the application but without trying to tell them everything, to convince them of your marketing plan, to build in retention right away? How do you just let them know this is a great start and explore that space fully to find the right very first moment?

Jared: Do you play games like that? What’s the worst possible experience we could design? And then sort of go back and say, “OK. What’s the essence of that?”

Brandon: I think there are all types of techniques to get the generative process going. I mean, we’ll teach several within the “Good Design Faster” workshop. Some, like just wordless – the ability to look through a dozen, dozens and dozens of types of interactions that are common, so is cover flow a way to introduce the first moment? Is progressive reveal the way to present the first moment? Is information visualization?

So there are all these kinds of devices that could help stimulate new ways of trying out that first moment with people. We use spectrums. We use inspirational libraries from other design moments, well-designed moments to drive our thinking. So it can be everywhere from the silly to the more purposeful or pragmatic approaches to really try to spread out your thinking.

The important idea is get over that first idea. That first idea – the one that’s been in your head since the start of the project is kind of the killer. If you move right ahead to a high resolution version of that, you’re never going to move away to the next great idea. And time after time, I find that the really great ideas are not the first one that comes out of your head. It’s the third, fourth, seventh, tenth idea that you’ve really found. That the not-so-obvious, blatantly obvious solution, but the one that really works.

Jared: But I really like that first idea.

Brandon: Isn’t it lovely? Isn’t it the one you hold onto and you kind of dream at at night and you…

Jared: I’ve been thinking about that one forever.

Brandon: You just can’t wait to unload it on everyone, and them kind of shine radiance back upon your brilliance and acknowledge you for how smart you are.

Jared: Well, it’s just like Amazon, right? So, we’re just going to do it like Amazon does it. After all, they do it really well.

Brandon: And that argument works out well and it sells it so well internally that – why deviate?

Jared: Exactly, exactly.

So, there seem to be… Like the first idea problem, there seem to be a whole set of obstacles that teams run into when they are trying to get to a good design. What are some of the ones that you’ve seen?

Brandon: I see the desire to move into high fidelity quickly. I would say the tendency to jump into the visual mock up, the high fidelity wire frame where you’re starting to worry a whole lot about spatial relationships. You start thinking about how exactly do we phrase this sentence to introduce this screen? What do we call something? When that may not be where the true nature of the problem lies.

You really have to attack the most critical part of the problem first, and so you often end up what I would call, like, donut prototyping or donut solutions. You build out a ring, the donut, of all the things you already know to be true. Like, OK, we know the style guide that we’re going to be applying to this. We know the constraints of the platform. Let’s just go ahead and start filling all those parts of the puzzle in, and you build this donut around the true core part of the problem. You feel like you’re going to slowly sneak up on it, because you’re constraining all the other variables.

You really need to chase after that center of the donut, that really big unknown part of the problem first. Usually that has to do with the big cases of flow. Like, you know, how big is this experience? How do we structure it? What’s the first thing people encounter? How do we make sure they recognize the true differentiators? Or the real true strengths of what this new product or service brings? Those are the big unknowns often.

And the sooner you can tackle those quickly, rather than filling in all the knowns – the style guides that contribute to the platform, the obvious components of the functionality. But you forget to work on the real core of the problem, that center of the donut, that’s really the unknown. You think you’re going to sneak up on it by filling in all the known parts. Ultimately you get to it, but that’s too late to solve the problem.

I see a lot of teams doing that, where they go ahead and fill in the obvious stuff and wait to solve the really challenging part of a problem much later. Those are often things dealing with flow or scope of the solution. Or how do you really crystallize the value prop through interactions that people have with a product or service? Those are the really hard things that people need to tackle earliest. And so how can you bring a team to that kind of thinking really, really quickly?

Other types of problems I see – people not paying attention to flow. They pay a lot of attention to individual screens or to, you know, core important parts of the navigation. But what is the flow of the experience really like? What is the peak moment in a series of interactions you have with someone? What’s really the best moment that really needs to stand out because it’s what this service, this organization does really well? And how do you end the experience really strongly?

We as interaction designers should be incredibly good at that and incredibly good at hosting sessions to work on that. Yet, we get very much stuck in just sort of key frame moments of the experience. I think some of the processes we’ll be teaching at Good Design Faster will be a lot about, how do you look at flows of interaction, not just these little crystallized moments?

Jared: This was a question I had. What’s the difference between a flow and a wireframe?

Brandon: Yeah, I think wireframe, in many ways, is that evil monster that Good Design Faster is trying to battle against, that a lot of time and attention is placed on wireframes and really nailing down the perfect layouts and the perfect points of information and information design for one. Good Design Faster says, “Let’s pay attention more to the flow. How do you go from start to end in the experience so that each moment is building upon the earlier one?” And with, of course, increased level of interaction through HTML5 and all the other things we’ve been using technology-wise, you’ve got to pay attention to those things. Because the difference in… Let’s just take Google’s new style of search ahead that they’re using where the page is refreshing while you’re typing. That’s almost a totally different experience than the old world of search. Instead, these little moments of interaction can matter a great deal to how a product or a service is really being perceived.

So if you’re not working in a medium that allows for that, if you’re not paying attention to how a product or service unfolds over time with the user, then you’re really not doing interaction design justice.

Jared: Yeah so, a lot of the design today you know involves all these gesture based activities where you’re scrolling, or you’re dragging, or you’re putting two fingers and spreading them apart, and all that sort of thing. The flows… If I understand it, what you’re saying is the flows represent the behaviors that the design’s going to have there, whereas wireframes are just these sort of static – you use the word key frames. They’re sort of these snapshots in time of where it’s at, but it’s hard to know how something gets from point A to point B. Did I get that right?

Brandon: Exactly right. I think we see where expectations are heading. I think I’ve seen a couple of reports of US consumers actually spending more time on a mobile device now than they do on a desktop or web interaction. And so, the expectations are going towards great simplicity. And I think that’s going to spread from mobile back to web and other kinds of interactions.

And so, people really expect the interface to almost teach them or naturally afford all the things they want it to be able to do. These types of interactions of – what does this swipe allow me to do, how does this interaction respond, and little moments – become really, really key to making sure the product’s successful. And without having a way to model that, it becomes very difficult to ensure.

So those wireframes, those just kind of state changes of the web circa 1995, we really need to break those kind of mediums for thinking about what we’re going to design and move over to much more highly interactive design tools. Those don’t have to be the prototyping tools that some of us are also very familiar with – the Axures and things like that – that allow for still higher fidelity type of prototyping.

A lot of times those don’t allow for a lot of exploration around what is the best idea. You move very quickly into rounding corners rather than still trying to explore what is the right flow. That’s what we’re trying to develop as a technique is something that teams can share, we can work through interactive solutions, but you can bring in great breadth to your thinking as well.

I think another challenge that this helps address is a little bit of the Agile mentality that a lot of your experience designers and UX teams are starting to approach. Internally, they’re finding their development teams are using Agile. They’re being asked to do things like Sprint Zero. How do we feed a natural process?

Good Design Faster is something that fits into a sprint style scenario of how do we quickly get to a lot of ideas, find the right one, and then take that one set of bright ideas into a higher fidelity wireframes, or things that can be provided to a tech dev team.

Jared: Yeah, and I think that the Agile thing is a really good point. As you said, you know, a lot of folks are sort of getting into that. It’s very rare now at one of our events that when someone says, “How many people here are using some form of Agile,” that the majority of the audience doesn’t raise their hand. It’s really very common, yet Agile was never designed with any sort of design process baked in. So it’s always this sense that you’re gluing it on the side.

The workshop technique that you teach, it really does feel to me like it would be a great way to get an Agile team started in terms of thinking about what they want to do with their Sprints from a design perspective versus a technical perspective. Have you found that to be the case?

Brandon: Exactly, yeah. And even some of the techniques we use, we use one of the things called sketch board for really putting your ideas tangibly out into the world, organizing them, and working with a group to evaluate what are the best ideas. It really feels a lot like a scrum board whereby you’re tracking end-user storage through the process, and which ones are being implemented, and that sort of thing.

It’s really kind of the design mate to a scrum board of, what are all the ideas we have? Which ones are the best to implement now? How do they connect together into an overall flow? You can always go back to that board again to find the next best idea. It really provides that Agile type of feel of knowing what your choices are, being able to figure out which ones you want to prioritize and feed into a development spread.

Jared: So the sketch boards, they live throughout the project, right? You put them up on the wall in war room and they just keep coming. They’re not just a product of this workshop and then when you’re done you take a picture of them, store it on a server somewhere, and never come back to it.

Brandon: Exactly. I think when I’ve seen sketch boards out there in the wild – meaning after people have gone through the Good Design Faster workshop and then shared some of their work with us – that’s one of the things that is most evident that people are finding a lot of value in. You can even do some sketch board word searches on Flickr and find some nice galleries and pools of those kinds of photos that people have compiled of showing what it’s like in their actual work environment.

It’s something that can live on. It’s something that you can track in terms of how much of this envisioned experience has gotten implemented at this point. Then keep on migrating, keep on moving along to find, what’s the point in the flow that we next need to move on? Maybe even track analytics in terms of, what’s the constraint or the bottleneck in this funnel of conversion from one side of the sketch board to the other, so that you know which part you really want to attack as a UX team.

Jared: I’m going to bet it’s that terms and conditions screen that I was so hoping would be the first part of the experience.

Brandon: Maybe that’s it. You start with a really terrible experience to show how much you’re improving it over time.

Jared: Well there you go. That keeps management there. If you could come up with some solid metrics to go with that, everybody would be very happy.

Speaking of metrics, you mentioned that when you’re in this process, you’re having conversations about who the user is and what they’re trying to do. Are you discovering that in the Good Design Faster workshop? Or is that something you have to bring to the workshop and have already researched? What happens when the team has different opinions on what that is because they don’t have very good data?

Brandon: I think this is something we’re assuming that someone is bringing to the Good Design Faster workshop. The process of Good Design Faster and sketch boarding is that there’s some base level of understanding of who the customer is, a very top level understanding of “what is this product?” What might its value proposition be? I think you’re much more successful than executing good design with a little bit of alignment already.

That being said, I think it can be a little bit of a fine tuning process of being able to look at all the ideas that are possible and saying, you know what, now of everything we’ve thought of maybe you can start to refine and say we can satisfy the needs of user A much better than User B. Or we really need to evolve the value proposition of this product or service because the ideas we’re coming up with point at a different kind of value than what we’ve been theorizing at a strategy level.

I think it can definitely be a tool for fine tuning, evolving, those understandings of who a target user is, but I don’t think it’s a place where you’re going to discover new customer needs that you never knew before. That’s going to be more at spending time actually in the world with end users with customers, not by spending it at a sketch board.

Jared: Well this all sounds really awesome. I’m really looking forward to the workshop. I think there’s a lot of stuff packed into this full day that people walk away with that is really quite useful. I’m really excited about it. Thanks for talking about it with me.

Brandon: Yeah, of course. What I’m excited about is people coming, learning about the technique, and then taking it and doing what really makes it work for them in their organization. We’ll present a lot of different ideas, but I love seeing where some of the techniques go because that’s what really pushes the practice forward. So I’m interested in what people want to do with it.

Jared: Well it’s great, because I know that in past years when we’ve done this workshop at the conference people have told us that it absolutely is something they’re able to go back to their offices and do right away. They see marked improvement in the types of designs they’re producing and the speed at which they get them done. It really is Good Designs Faster.

Brandon: Who knew?

Jared: Yeah. Awesome.

Brandon: Living up to the value prop.

Jared: Exactly. Brandon, thank you so much. For everybody who wants to attend this workshop, you can sign up at uiconf.com. Of course, the conference is going to be in Boston, November 7-9. There are seven other fabulous full day workshops to choose from for the other days plus a day of great presentations from all of our speakers.

It’s really a great conference. Again the URL for that is uiconf.com. That’s the User Interface 16 Conference in Boston, November 7-9.

Brandon, thank you so much for taking time today to talk to us about this.

Brandon: Absolutely. I hope some folks come and learn not just how to do good design faster, but maybe even great design faster.

Jared: That’s fabulous. I want to thank our audience for listening to yet another one and enjoying this. Please, by all means, if you haven’t done so and you have a moment, if you listen to us on the iTunes, go into the iTunes and give us a rating. Tell us what you think, because the ratings help other people find us. And we appreciate that.

Of course, I want to, as always, thank you for encouraging our behavior. We’ll talk to you again. Thank you very much.

Story mapping is a way of organizing Agile user stories that communicate user experience. It allows us to build the collection of stories that become the backlog. Agile expert Jeff Patton will show you how story mapping gives you a tool: a tool to both quickly think through and simply describe the user experience. This strong technique helps you put the big picture of UX and the little pictures of Agile in one place, engaging the developers and stakeholders you’re working with.

Users will always have an experience with your product. Story mapping will pull your UX focus into your organization’s process and ensure that experience is a great one.

You’ll learn:

How to build a story map—something you already use—from scratch

You’ll learn to keep the focus on what people are doing, while decomposing into the things your organization designs, and how development happens.

• Bring user experience to the project early and often, while still letting the Agile folks move forward in their process of breaking everything down into little pieces
• Explore ways of describing user experience with Agile stories, and get involved with the “what to build” part

How to overcome the Agile dogma that often starts projects off on the wrong foot

You’ve heard stories and are suspicious, or maybe even had an experience of your own.

• Make sense and avoid trouble in your projects when talking about the user experience, something seemingly antithetical to the agile process
• Story mapping gives you an intermediate structure to represent both the big business “whys” and the specific development “whats” of what the user is trying to do

Why the story mapping vocabulary can alleviate the lack of common understanding that comes with tying Agile & UX together

Between project management, developers, and the UX contingent, you can get everyone on the same page with the terms you introduce and define.

• Use language that still helps you plan and track progress, but doesn’t lose the user experience
• Succeed in working with others on your team who may not be UX-literate, using story mapping as a conversation piece and a collaborative element

You can put this process in place for projects you’re working on right now

Regardless of how far along your team is on a project, it’s never too late to put this technique in play.

• Take control of current projects. Use story mapping to ensure the user experience is an integral part of the product you deliver.
• Reap the rewards of story mapping when you’re stuck, or unsure of next steps, even several iterations into a project

A team deep in the Agile process need things at a certain time, in a certain way. That’s foreign to the traditional UX effort. Story mapping is a way to merge these two worlds. Jeff will dig into why the two approaches are different, and what user experience professionals will do in this Agile environment.

Start story mapping in your agile environment and you’ll be tightly integrated as active team members in the whole development process, and not added as an afterthought. Others will see you as a critical contributor to the process of what to build, and in framing and delivering your product. Join us on September 1.

Get Jeff’s Agile Primer:

Register before August 25 and get complimentary access to Jeff’s 2009 virtual seminar: An Agile UX Primer. Agile refers to a class of processes, and Jeff’s the guy we turn to for this aspect of the design and development world. It’s not a prerequisite, but it’ll add to your takeaways from Jeff’s seminar on Sept. 1.

Outsourcing your user research work is like outsourcing your vacation.
It gets the job done, but probably won’t have the effects you were seeking.

I usually say this when someone is asking me to do their user research for them. This is something we did quite a bit in the early days of UIE, but don’t do any longer.

Usually, they are asking us to do this to save time, because they don’t have trained folks, or because they are afraid of bias. All these reasons are rational, but there are better ways to deal with them than hiring someone else to do the research on their behalf.

As I said, I founded UIE as a company to do just this. I felt the rational reasons where why companies weren’t conducting their own research. I thought we could offer cost-effective, inexpensive research services to help. User Interface Engineering, in 1988 (it was our 23rd birthday yesterday!), was one of the first companies to make user research services available to other companies.

However, after working with hundreds of teams and providing their research, we started to looking at how effective we were. Were the teams’ designs getting better? Were they doing more research? Were they creating better user experiences?

We were sorely disappointed with our results. While every team told us they really got a lot out of our work, most weren’t improving their designs. They were appreciative of our reports, but hadn’t read them. They enjoyed our presentations, but weren’t really adopting the recommendations. And, most importantly, their culture didn’t change — they weren’t integrating users into their design process any more than before.

It wasn’t only UIE’s clients with this problem. We reached out to organizations using other outsourced user research services and discovered the same results. Hiring the work out wasn’t getting the job done.

We realized that we were missing an important variable in user research: the team’s direct exposure to their users.

When we take a team on a field research project, we introduce the team members to their users and having them spend time seeing them use the product and doing their work. In doing this, we’ve accomplished 90% of the work of the project.

It’s the exposure that changes the way people work. The same is true for usability testing or interviewing users. The direct exposure is the most valuable part of the project.

When you hire out your user research, even to the most competent of user research professionals, you’re losing 90% of the value. The research becomes a game of telephone, where the “away team” (to steal a Star Trek term) learns all about the users and somehow has to communicate back what they’ve learned. No mount of report writing or presentations can replace that lost experience.

Some UX service companies will tell you that they’ll remain part of the team, integrating the knowledge they learned into the design as the project continues. However, that creates an imbalance, where some people on the team know the users well and others have no idea. Those others, who will eventually own the entire design, are working at a disadvantage and won’t be making their design decisions using this critical knowledge.

This is why we now refuse projects where the team wants to outsource their research. We still do plenty of field visits and usability tests with our clients, but only if they come along to every session. If the client team isn’t there, we won’t conduct the session – there’s no point.

For the folks that think they don’t have time to do their own research: You’re better off taking the money you’ll spend on hiring someone and burning it in the back yard. You’ll get the same value in your product.

Seriously, if you want someone else to do your research because you don’t have time, you’ll need to dedicate twice as much time to spend with the researchers, extracting every little thing they learned about your users. Otherwise, you won’t get the value you paid for. It’s not a time saver to go this route at all.

For the folks who feel they don’t have the skills onboard: That’s an easy problem to fix. Training on user research methods is pretty easy. This is the bulk of our consulting work these days. We use a “Watch one, Do one, Teach one” approach. (We stole it from the medical training world). Most teams pick up the skills pretty quick and do a damn good job in just a few weeks.

And for those folks who feel doing your own research introduces a bias: You’re right, but it doesn’t matter. There’s always a bias in research, even when you get a third party to execute it. There’s nothing wrong with biased research, as long as you understand your biases and how to counter act them.

If there’s anything you can outsource, it could be participant recruiting. However, make sure you work with someone trained in UX recruiting, not market research recruiting. UX trained folks (we use Usability Works – they’re awesome!) know how to deliver the information they learn about your users in the process.

That said, you should even try to resist outsourcing your participant recruiting. You learn a lot when you talk to your potential users, even if they don’t qualify for the study. When you’re outsourcing it, you’re flushing a lot of great source material down the toilet.

Once you’re in the habit of doing your own research, you’ll never want to go back. It’s just too awesomely addicting and useful.

More and more, we’re finding ourselves in situations where the design just “has to be right.” No longer, can we just have incremental feature enhancements or small improvements in the design. Our users need to be wow’d and delighted. And adding large fonts in bright colors with rounded corners will only take us so far.

To truly delight our users, we need to dig deep into what is meaningful and valuable to them. Give them something that resonates and they will jump for our design.

We can discover those resonance points by taking our research into the field. We meet the users in their own environments, observing them as they live their lives and do their work. We bring back oodles of data, which, once we analyze and synthesize, we can reveal the delightful essence of new designs.

Steve Portigal has traveled all over the world to do just that. He’s spent thousands of hours in people’s homes, offices, and the other places of their lives, just to learn more about what will delight them. His work with design teams has taught them to mine their rich data sources and uncover a wealth of value and meaning to design for.

Steve’s full-day workshop at UI16 will take you through the entire process. Prepare for a hard day of work, which starts with a real field visit. You’ll bring back observations that you’ll work with for the rest of the day. Under Steve’s expert guidance, you’ll learn the best methods for interviewing users, analyzing the data, and synthesizing the key meaning.

You’ll be ready to head right into the field the moment you get back to your office.

See the other UI16 Spotlights:

You can catch the sneak preview of UI16 at uiconf.com. (And there’s still a few of the sneak preview $1,349 registrations left. Snag one while they are still available.)

Dan Rubin is one half of Webgraph and part of the Sidebar Creative team. He’s a great designer and a fantastic teacher. In his virtual seminar, CSS3 for Everyone, Dan shows examples of web sites currently employing CSS3 well, enhancing the user experience. He also demonstrates how using CSS3 pseudo-elements gives you more flexibility with how you can style elements.

Dan and Adam ran out of time to answer all of the great questions from our audience. So they caught up to address the remaining ones for this podcast.

Here’s an excerpt from the podcast.

“…I recommend checking out dolectures.com built by the folks at Paravel. It’s a beautiful design. But if you view it in a desktop browser, and re-size your browser up and down, make the browser window really small. You’ll see that this is a properly responsive design. [It] uses media queries as well as fluid grids and web fonts and, behind the scenes where needed, they’re using structural CSS to achieve things without having to incorporate JavaScript.

It’s a great example of a site that you could look at and not [realize] it was doing a lot of special stuff. And that’s really the point here. The point isn’t to use CSS3 to throw these bells and whistles around everywhere in plain sight. For it to be useful to us, it has to save us time. It has to improve our work flow and improve our output.

And that’s why it’s exciting to me and to everyone else who’s actively using it now. It saves time, it makes testing easier, and it makes things like responsive web design possible in the first place. It allows us more flexibility, especially if you’re a designer, to kind of have this one-to-one or closer to one-to-one relationship between what you’re doing in a visual design app like Photoshop or Fireworks where you can use opacity.

One of my favorite tricks is to use lots of layers of either black or white and to layer on top of either images or other colors that I’ve set in the design. [I then] use opacity to vary the level of detail and the level of mixture of that color. You can do that in Photoshop and you can transfer that directly to RGBA colors and do the exact same thing without having to do any weird conversions or use your color picker.

Once you start actually doing that and experiencing how that changes your work flow, you realize that it’s not about making things flashy and adding all sorts of animations and transitions and hovers and drop shadows and making everything have a rounded corner. That’s not what it’s about. It’s about how it changes the way and improves the way that you build and design…”

Tune in to the podcast to hear Dan addresses these questions:

• Can images, HTML, and other characters be inserted through the before and after pseudo-elements that you discussed?
• Can you use CSS3 when designing for mobile, specifically iOS and Android?
• Do you have a list of live websites that currently leverage CSS3 well?
• What tools do you use when designing with CSS3?

What are your experiences with CSS3? Share your thoughts with us in our comments section.

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

So much of a project’s success is determined at its start. If the team comes together and sets the stage properly, everything works out smoothly. People end up with a great vision and solid understanding of how the design should turn out.

Yet, a project that doesn’t get off to the right start will often struggle. The team will find themselves in conflict, important requirements often emerge too late, and good ideas get left on the cutting room floor. Unfortunately, in my work, I see too many projects that have gone down this road and find themselves trying hard to get back on track.

A few years back, I was lucky enough to see Kevin Hoffman present his workshop technique for kicking off projects. It was a completely different approach than any I’d seen before. He showed us how interactive exercises, brainstorming games, and collaborative sketching techniques surfaced important details about the project, while elliciting innovative ideas from everyone on the team.

Since then, he’s had the opportunity to refine his methods in his projects at Happy Cog, a leading web design firm. Happy Cog’s clients have been so impressed, they’ve asked him to teach them his techniques so they can kickoff their other projects successfully.

I’m really pleased that we can have Kevin as part of the User Interface 16 Conference program. As we’ve been working on the plans for his full-day workshop, I’ve gotten a glimpse of just how much fun this day will be. Kevin knows his stuff and has packed the day full of both solid theory and practical exercises. It’s almost criminal that something this fun is a critical work skill.

See the other UI16 Spotlights:

You can catch the sneak preview of UI16 at uiconf.com. (And there’s still a few of the sneak preview $1,349 registrations left. Snag one while they are still available.)

What happens over time with applications is a design entropy sets in. As new features are added, they are glued on top of old ones, often with slightly different interfaces. Slowly, the application starts to develop a Frankenstein look-and-feel, which hurts the users and the business.

Teams can avoid all this. Using established, well thought out, and proven user interface design patterns, teams can hedge these problems off before they become unmanageable. Even the worst applications can benefit from the careful hand of applying the best design practices.

There’s no one who knows how to deal with hedging off design entropy than Hagan Rivers. I first met Hagan back in 1995, when she was working for Netscape as one of the world’s first web application designers. Since then, she’s become a world expert in interface design, helping hundreds of teams get their application UIs under control.

I’ve had several opportunities to work with Hagan on various projects. Each time, I walk away learning new design techniquesn and feel smarter about how to tackle even the most complex hairball of an app.

Hagan probably has the biggest collection of application design examples I’ve ever seen. Everytime she delivers her workshops and presentations, she brings out these stunningly amazing sets of both good and bad examples. You can instantly see how changing a design in just a few simple steps can immediately make for a better user experience.

This year, I’ve been working with Hagan on her full-day workshop for the User Interface 16 Conference. She’s putting together a intense program, where you’ll walk through practically every type of interface element, from tables and lists, to working with trees, forms, and wizards. She’ll tackle the gnarly topics of simplifying a complex navigation scheme and creating an effective dashboard display.

Anyone who is fighting design entropy, trying to get their application’s UI under control will be riveted by this in-depth workshop. I’m so happy Hagan’s on our UI16 program and I know you’ll love her session.

See the other UI16 Spotlights:

You can catch the sneak preview of UI16 at uiconf.com. (And there’s still a few of the sneak preview $1,349 registrations left. Snag one while they are still available.)

What is a good success rate for a usability test task?
We just conducted user testing on a site map. So we have success rate percentages for each task. They range from 9% – 51% success (in up to 3 tries). Obviously there are problems. (And no, we didn’t create the site map, which makes me feel good.) But what would be considered a “good” success rate? I want to say over 70% for this test. It is only site map, no content, which will limit the success anyway. Maybe I’m aiming too high?

Thinking in terms of % of completion may not be the right approach. (In fact, I’m hard pressed to come up with a time when it is the right approach.)

You haven’t said anything about who the users are or what the site map information contains. But let’s pretend the users are doctors and nurses and the site map contains the necessary information for them to administer drugs safely. If one of those doctors or nurses doesn’t find the information they need, they could improperly administer a treatment which could kill their patient. What would be an acceptable failure rate under these conditions? I’d say 0% — the system needs to ensure success of every user.

Why is your system any less important? Why would you be willing to tolerate any failures?

The real question isn’t “what is an acceptable level of failures?” The question I think you want is “What’s preventing people from succeeding?”

Instead of looking at how many people succeed versus how many fail, what if you were to analyze the failures themselves. Can you rank and categorize all the things that prevent your users from succeeding? Can you assign a classification that helps you understand whether the problems are life and death (as in the example of doctors and nurses I used above), problems that will lose customers, problems that will cost support money, and problems that are annoying without painful side effects?

This will also help you look at the participants you’re recruiting for your study. How similar are they to real users? How realistic are the tasks you’re asking them to complete? How well does the system, if they make a mistake at the site map, help them still succeed by having guidance for common errors on the content pages themselves? (Such as “If you’re looking for x, click here.” type lateral navigation.)

In the end, you really want to understand the problems real users will encounter. That’s the purpose for the studies. Then you want to explore solutions that resolve those problems. In an ideal world, it’s not that you get 100% task completion, it’s that you have addressed and solved all the problems.

The closer you can get your studies to map true in-the-wild user behavior, the more you’ll understand about the problems you’re uncovering and the solutions that will help. Focus on the problems and their resolution and you’ll get the design to where you’d like it to be.

We’ve identified a bunch of skills that make up user experience design.

Skills necessary in UX teams

These include the core skills:

• Interaction Design
• Information Architecture
• Visual Design
• User Research
• Information Design
• Design Process Management
• Copywriting
• Editing and Curation

Then there are what we call the ‘enterprise skills’:

• Domain Knowledge
• Business Knowledge
• ROI
• Technology
• Marketing
• Social Networks
• Use Cases
• Ethnography
• Analytics
• Agile Methods

Beyond that, there are a collection of soft skills:

• Storytelling
• Sketching
• Critiquing
• Presenting
• Facilitating

And these likely aren’t the complete set for many teams. It’s just the starting list that covers that vast majority of teams we’ve studied. (If you’re not sure what these are, I’ve described each of the core and enterprise skills when I talked about our team assessment process and the soft skills in my article, Five Indispensable Skills for UX Mastery.)

These are the skills that a great UX team needs to succeed. When teams are missing some of these skills, the chances they’ll produce a great UX is diminished.

When Content Strategy burst onto the scene a few years back, we asked ourselves if this was a new skill (or set of skills) that we had to add to our list? After careful study, we decided we didn’t need to.

That’s because what makes up today’s idea of content strategy is covered in this list already. Teams excelling at content strategy are applying these skills to make it happen with copywriting, editing & curation, marketing, domain knowledge, business knowledge, information architecture, and others.

Yet, we felt content strategy was something different than what we’d seen before. That’s why we labeled it a special collection.

People who practice these skills while focused on content strategy will gain experience and knowledge that comes from the attention to those objectives. This is experience and knowledge that will separate them from people who haven’t focused on content strategy, yet practiced the same skills.

The same is true for service design and for what people are now calling lean UX. These are also special collections, aimed at specific objectives. The underlying skills are the same, but the focus makes it special.

I think there’s plenty of room for special collections. It’s a natural outgrowth of our field maturing. There will be specific conferences, books, and other skill-growing materials that emerge to support people diving into these specialties.

It all makes sense and fits into the model we have of what it means to create great experiences. Personally, I’m excited about it.

• Ways to tailor your UX design process to the culture of your organization
• How to conduct research with minimal time and budget
• Techniques to get useful design feedback from stakeholders
• How to make your case in organizations that don’t prioritize design

You’ll be able to put UX principles into practice in any organization, and learn how to make the case for user experience design with results, not theory.

Register with the code UNDERCOVER and add lifetime access
to the recording of this seminar for no extra cost.

The details for you:
UX Design when Time, Money, and Support is Limited with Cennydd Bowles
Thursday, July 21 at 1:30pm ET
1:30pm ET / 12:30pm CT / 11:30am MT / 10:30am PT
90 minute online seminar
Learn more about Cennydd’s seminar or save your spot now!

And one last piece of good news! Thanks to New Riders, we’re giving away copies of Cennydd’s book, UNDERCOVER User Experience Design, to random attendees. Winners will be notified within 24 hours of the live seminar. Join us!

In his thoughtful comment, he stated that he tries to leave the team better than when he arrived, by training them to do the things he does, so they can continue on without him.

“My goal is not to swoop in and save the day, but rather turn those who stay into superheroes. I don’t make products better, I make people better. If agency staff are not doing this, they are most certainly prone to becoming guilty of everything you said here. But if they care about the long-term outcome, they’re leaving clients with much more than deliverables and innovations. They’re leaving clients with a path to better decisions.”

This is exactly what we do in our work with teams, so I think this is a grand goal.

I’m wondering how many design agencies, when they are pitching a project to a client, focus on the “What your team will learn from our work” section of their pitch? Or how many even have such a section?

I’ve sat through many pitches on behalf of our clients. (Teams often hire us to help them choose their agency, because of the knowledge we have on what makes an excellent design.)

I’ve never seen a single “What you’ll learn” section in the pitch. However, I think it should be there.

Hiring clients should demand this from the agencies they are considering. It should be a solid curriculum, with milestones, deliverables, and a list of who is going to learn what. Most importantly, it should talk about everything the team needs to learn, to keep up the good work, once the agency has moved on (and they ALWAYS move on).

I think any agency that makes this a major part of their pitch will have a huge advantage over the competitors who omit it or play it down.

And we’ll get better experiences in the long run.

As we study how teams can best use design principles, we’ve discovered that project specific principles are far more useful than generic overarching principles, which many teams develop. Take Facebook’s published principles, which include generic phrases like clean, human, and universal. Good thing to strive for, for sure.

But how do these principles help the design team? How does a team decide if a design idea is human enough? And if they aren’t for the design team, who are they for?

What we’ve realized is good principles don’t tell the design team what to do. They tell the team what not to do.

A good principle clearly draws a line in the sand, telling you exactly why the majority of ideas you’re looking at won’t cut it. It helps you say, “This isn’t quite there, let’s try again.”

One team we’ve worked with recently was working on a point of sale system for appointment-based businesses. Several operations, such as rescheduling appointments, took time. Watching the receptionists during a rescheduling, the team realized that they had a problem. If another customer called or tried to check out, the receptionist had to make the second customer wait until the rescheduling was done.

The team realized, for their redesign of this functionality, they needed to follow a principle of “Allow for multitasking to handle interruptions.” It’s a simple principle, generated completely from the problems the team saw in their field observations.

What’s beautiful about this principle is it helps the team say NO to ideas. Any design proposal that can’t easily be interrupted for a new appointment or to check a customer out is immediately out of the game.

Sometimes, it might only take a few tweaks to go from “not meeting the principle” to “meets and exceeds.” And that’s perfect — the principle is doing its job of guiding the team to a better design solution.

Years ago, we found when you gave a team of designers a specific problem to solve, they had no trouble coming up with solutions. Solutions are the easy part. Understanding the real problem is the hard part.

An actionable, research-based set of design principles helps a team define and understand the problem. That gives them the power to come up with solutions that really work for the users.

It’s definitely something I said. In fact, I can tell you exactly what I said.

However, to do that, we need to revisit some research we’ve conducted over the last few years. We’ve been looking at the process of making design decisions and realized there are five distinct styles. (If you haven’t read or seen me talk about these, go read about them now. Otherwise this won’t make a lot of sense.)

If you’re a designer, any of these styles can produce great results that delights customers. However, for many, the most advanced styles, activity-focused and experience-focused design, are the more desirable projects. That’s where the really cool stuff happens and where the biggest challenges are found.

And this is where I get in trouble with the agency folks. As we’ve been researching these five styles, we found an interesting finding: agencies can’t do activity-focused or experience-focused design.

Many do self design. Some very successful agencies make a lot of money with genius design. (And there are many that do unintentional design, but they probably shouldn’t brag about that.) However, it seems activity-focused and experience-focused design is out of reach of the agency world.

Now, many agencies try to sell themselves as doing this work. And many agencies get clients to hire them to do this work. That’s not what I’m talking about.

I’m talking about creating successful designs using these decision styles. That doesn’t happen with an agency. It can only happen in-house.

Activity-focused design takes a long time. It requires making an investment. The team accrues knowledge over a long period, studying users and their activities, implementing solutions, and seeing how those solutions work. It takes many iterations to do well.

Most agencies aren’t brought in for long-term iterative work. Eventually, all agencies leave. When they leave, the knowledge the team has gained walks out the door with them. Then the client is left with something they don’t know how to maintain or improve. The project fails.

Experience-focused design is even more difficult. The designs often require changes at touch points all over the organization. For example, for a retail business to create a seamless experience, they’ll have to change things on the web site, in the stores, at the call center, in the distribution centers, and in the merchandizing department.

Agencies can’t have this kind of reach. It takes commitment at all levels. It’s too expensive to teach an agency how your business works. They don’t have the political clout to make the hard decisions.

Sure, a company can hire an agency to give them ideas. Agencies have really smart folks with lots of great ideas. But the long-term, in-depth execution has to come from within. The company has to make the commitment to investing on their own.

Needless to say, statements like this don’t make me popular with agencies. Recently, I’ve found myself sitting in front of agency owners, defending this position. They don’t like it at all.

I could be wrong. (It’s happened before.) It could be that an agency could take over the management and operations of a business and build a fabulous design using activity-focused or experience-focused design. I haven’t found one yet, but it could happen.

I just hope that agency’s contract never ends, because then their (now former) client is screwed.

OK, maybe I’m exaggerating a little. But I am quite frequently asked to convince executives to invest in user experience.

And it may surprise you to learn that I refuse the offer every time. As a policy here at UIE, we only take on work we can guarantee results from. I know from experience that I have no chance in hell to convince any executives of anything, so I politely decline the gig.

“But surely, because of all your success, you must know what it takes to convince an executive to invest in UX?” they always ask.

Actually, I don’t. I’ve been pitching our services for 23 years and I’ve never once successfully convinced an executive of anything.

Our success has always come from projects where the client team, including the senior management, already understood the value of great user experiences. I haven’t convinced them because they didn’t need convincing.

Have you ever met a smoker? Of course you have. Have you ever met a smoker who didn’t know the harmful effects of smoking? I bet not. Every smoker I know is well aware of what smoking does to their bodies, yet they continue to smoke. There are physical, cultural, and behavioral forces that make it hard to quit.

You can’t convince a smoker to quit smoking. They need to just decide they’ll do it. On their own. When they are ready.

It’s the same with executives. Neither I, you, nor anybody else can convince an executive to invest in user experience.

Sure, there may be a few execs that are somehow still unaware of how a delightful, useful, easy-to-use product is better than a frustrating, useless, difficult-to-work product. I haven’t met one in all my years, but they could exist. Even so, I don’t believe a presentation will change their views.

What can you do instead of a presentation?

You can find out what your executives are already convinced of. If they are any good at what they do, they likely have something they want to improve. It’s likely to be related to improving revenues, reducing costs, increasing the number of new customers, increasing the sales from existing customers, or increasing shareholder value.

Good UX can help with each of those things. The problem is that there is no generic, always-saves-the-world process or solution for any of these improvements. If you wanted me to help, I’d have to study your business in-depth to learn how to make improvements in these areas through solid UX investment.

(That’s a project we’ll accept AND guarantee by the way. We’ve done it before, many times. It’s expensive, but it produces great results.)

Once you start talking about what the executives are already convinced of, it becomes easier to get them to make investments. You’re no longer trying to get them to change their focus. You’re playing directly into their main field of attention.

A generic presentation about how Apple or some other company has a great user experience program (or worse, a presentation showing all the bad user experiences in the world), won’t convince anyone of doing anything different.

You’ll need to do something custom. Something specific to their current focus.

And if that doesn’t work, maybe it’s time for you to find someplace else to work. Someplace where the executives are already convinced and want to make the investment. Right now, there are plenty of these opportunities on the market. Why bang your head against a wall when you can be doing those things you love?

Not every job will require that a designer know how to code. However, there are three reasons why learning to code makes you a better designer:

1. You’ll better understand the medium you’re working in. If you know what database queries will be faster than others, you can make the right response time tradeoffs. If you know what’s easy to code and what’s difficult to code, you can get your ideas implemented faster (and more of them, since development time is a limited resource.) Understanding what your medium does well and where isn’t as effective makes for more informed design decisions.
2. Knowing how to code helps you produce better prototypes. The best way to communicate a design idea to your teammates and clients is through an interactive prototype. Producing your own quick prototypes brings your ideas to life sooner, releasing that inner brilliance you’re carrying around and helping everyone see what your designs are really about.
3. Knowing how to code helps you identify bugs and flaws in the production code. As your team’s designs start to come to life, you can play an essential role of helping the developers isolate interaction problems, which means your end product will be the best it can be.

There’s been a lot of debate as to what languages designers should learn to code in. Based on these three reasons, I think it needs to be the languages used by the rest of the team, whatever they may be.

It’s clear from our research that designers who can code bring more to the team and, in the long run, see more of their brilliant work making it through the development process, to the user.

Pam Rodriguez and Luke Wroblewski did a nice job of posting their notes. Thanks guys!

• Steve Portigal on Design Fieldwork: Uncovering Innovation from the Outside In – Pam’s notes, Luke’s notes.
• Kate Brigham on PatientsLikeMe: Adventures with Data Visualizations – Pam’s Notes, Luke’s Notes.
• Luke Wroblewski on Designing Mobile Web Experiences – Pam’s Notes.
• Mike Lee on AARP: Designing a Strategy for Organizational Transformations – Pam’s Notes, Luke’s Notes.
• My presentation on The Essential Principles behind Great Design Principles – Pam’s Notes.

As you can see from the #UIEWAMT Twitter stream, everybody had a great time and we all learned a ton.

There’s one more stop on the 2011 tour – Minneapolis on June 27-28. Use the promo code BLOG and get $100 off the registration price.

See you there!

UIE Web App Masters Tour:
Get $100 off the Minneapolis Masters Tour with the promotion code BLOG.
Minneapolis

If you’re a designer, imagine you had a chance to work with two development teams.

Team 1: One team has top-notch developers who know virtually nothing about design. They can code miracles, but the designs of their applications are horrible and frustrating to use. And they show no desire to learn anything about design — how it’s done, why it’s important, and what makes a good design versus a bad design.

Team 2: The second team also has world-class developers, but these guys are hungry to learn about design. They’ve already taught themselves a fair amount and are truly interested in learning more. In addition to producing amazing code, they are regularly producing applications that look good, work well, and delight users.

As a designer, which team do you think would more fun to work with? The team that has no interest in designing or the one that really enjoys it?

Practically every designer I’ve talked to about this choice has told me, without hesitation, they would love to work with a development team that appreciates good design and wants to learn more about it. Those designers won’t be constantly battling for the simplest of design choices, instead be focusing on the hard problems with a group that wants to see the best outcomes.

Guess what? Developers feel the same way. If they had a choice, they’d rather work with a design team that understands development and craves to learn more, than with a team that doesn’t make any effort to learn what development is all about. Not just simple front-end coding either. They want to work with designers who understand the architecture and infrastructure, who can relate to the challenges they are up against and can appreciate it when the team has pulled off something amazing.

Learning to code doesn’t just give you new skills, it makes you a more desirable team member.

Blogger Pam Rodriguez has done a tremendous job summarizing the first day’s sessions. You can read them here:

• My talk: Mobilism & UX: Inside the Eye of the Perfect Storm
• Bill Scott’s talk: Designing for Mice and Men
• Josh Clark’s talk: Mobile Apps: Native or Web-Based?
• Noah Iliinsky’s talk: The Steps to Beautiful Visualizations
• Julie Zhuo’s talk: Facebook: Data-Informed vs. Data-Driven Design Decisions

Our own Web App Master, Luke Wroblewski, also has some great summaries:

• My talk: Mobilism & UX: Inside the Eye of the Perfect Storm
• Bill Scott’s talk: Designing for Mice and Men
• Josh Clark’s talk: Mobile Apps: Native or Web-Based?
• Noah Iliinsky’s talk: The Steps to Beautiful Visualizations
• Julie Zhuo’s talk: Facebook: Data-Informed vs. Data-Driven Design Decisions

Thanks to Pam and Luke for taking such great notes.

You can follow along with the second day by following the #UIEWAMT hashtag or the UIE Web App Tour attendee and speaker Twitter list.

UIE Web App Masters Tour:
Get $100 off the Minneapolis Masters Tour with the promotion code BLOG.
Seattle · Minneapolis

Mike Lee has to face this challenge. Mike is the Senior Digital Strategy Advisor at AARP. With much of the organization’s 53-year heritage being within “traditional” media realms, shifting its publishing and broadcast businesses into the online world is no small task. In this podcast, Mike joins Jared Spool to discuss some of their design challenges. They also discuss the ways AARP has transitioned to the web, and how they have been exploring and taking advantage of mobile and tablet technologies.

Here’s an excerpt from the podcast.

“…obviously we know and we look very carefully at what the ROI is on the paper side, and I think the inertia that is behind this machine is at least two faceted. One is a good piece, it’s to say, well, it’s working and we’re pretty sure that this mode of doing the paper piece is going to be useful and engaging and accepted for a five to 10 year time frame.

But, for example, our numbers tell us there are about five million members with smart phones. And that number is only going to grow. Our mobile traffic, which is still in the single digit percentages, is showing its 70 percent IOS devices and 20 percent Android devices.

So that number, if it’s five million now out of nearly 40 million members, as it grows, will start to be really interesting and impactful when you start to get into the teens and the 20 percent share. Here’s this group that prefers digital and they want the green, sort of, membership, they want to opt out of paper. We’re not seeing a big rush to that yet, but, I think it’s only inevitable. And we’re seeing that that’s an opportunity.

So, as great as a paper magazine is, and it doesn’t need a battery and it doesn’t crash, and (it’s) ultra high resolution, and you can bookmark it really easily. (It) has page numbers, which the Kindle just only recently added, right?

Digital engagement is extremely compelling, because the person can engage with the organization from wherever they are. And if we do our job correctly, it’s offering the tools that they need, wherever they may be standing…”

Tune into the podcast to hear Mike address theses additional points:

• How do you get an organization as old as AARP to begin to think about new technologies?
• Do you find that you have to argue for good user experience?
• Do you have a dedicated user experience team?
• Are people talking about user experience closer to the beginning of projects now?
• Has there been a change in energy level amongst management teams when it comes to the idea of user experience?

Mike is also one of the Masters joining us for the 2011 Web App Masters Tour. We’re coming to Seattle in May and Minneapolis in June. For more details such as dates, pricing, and agenda, visit UIEtour.com.

UIE Web App Masters Tour:
Get $100 off the Minneapolis Masters Tour with the promotion code BLOG.
Last Stop! Minneapolis

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

Here he tells the story of his brother and how it inspired him to look into the data of 45,000 people who are reporting their daily status with the diseases, drugs, and treatments in their lives. The end result is a “time machine”-like report that helps understand what can really improve the quality of people’s lives. I loved the 1-page summary of their health that patients can take to their doctors, to show exactly what they’ve been doing and how it’s been working.

This video encapsulates exactly what Stephen Anderson talked about in his podcast, The Quest for Emotional Engagement. If we can find a connection between the data we have and what’s meaningful in people’s lives, we can really make a difference to them.

It’s no accident that we’re talking about this at this year’s Web App Masters Tour. I think this is a critical conversation we need to have about how we bring the most out of our designs. On this topic alone, I’m pleased that Stephen Anderson will explore this idea of emotional engagement, Noah Iliinsky will how us how to create great visualizations like the ones Jamie demonstrates, and Kate Brigham will share what it’s like leading PatientsLikeMe’s UX team — making all this a reality for their 45,000+ users.

Register with the promotion code WAMT by March 11, 2011 for any of the Tour cities and pay just $795.

Up until now, mobile has been elusive for us. You see, we don’t talk about a subject just because it’s the latest fad. There are plenty of sources for hype-ridden design topics.

Instead, we wait until real expertise starts to take form. We keep looking for people who have a broad range of experience — the kind of folks who can answer all the difficult questions our audiences will throw at them.

When a topic is in its infancy, at best, the most advanced folks have experience doing one, maybe two designs. They don’t have the breadth of experience to deal with all sorts of difficult situations, only those situations they happened to encounter in their short-lived experience.

Our approach is to wait, to see what comes from it. If it’s just hype, then it goes away quickly, to be replaced by something new. But if it’s real, well, we can identify some experienced talent.

Mobile Emerging

Last year, a new book was all the rage: Josh Clark’s Tapworthy. We loved the book. At last fall’s IDEA conference, I was excited to share the stage with Josh. Turns out, Josh blew the audience away with a presentation on putting together a mobile design strategy. It was clever and information rich — which is perfect for a UIE program. I knew we had to have Josh on our program.

Luke Wroblewski was a top speaker from last year’s inaugural Web App Masters Tour. We had to have him back. Because of his shift from being Yahoo!’s Chief Design Architect to founding his own startup, he’s been thinking a lot about designing for mobile. He’s putting together a great presentation on what’s he’s learning about designing for a mobile experience first. We’ve been working through his outline, and the presentation is quite exciting.

I also reached out directly to Bill Scott, another of last year’s tour top speakers. He’s back at Netflix, now working on their sign-up experience. As we started discussing ideas for his topics, he shared what he’s been working on: making Netflix easy to sign up and manage on a multitude of devices — everything from iPads to Playstations. He’s been deep in making the subtle interactions work, like how you deal with hover and scrolling, with a range of input devices. (Does your app work with an internet-enabled TV remote control?) Turns out there are many general principles that every designer needs to know.

Our tour always includes people in the thick of designing their web-based applications, so we can hear their experiences. AARP has done an amazing job of keeping a 50-year-old organization completely state of the art. Mike Lee and I started hashing out what he could share, and guess what? AARP’s new efforts of shifting their publications and services to a mobile platform was the big story. He’ll share the trials and tribulations of turning the cruise ship to meet the new challenges of the mobile world.

While all of this was going on, I was thinking about what’s happening with experience design overall. It’s clear that there’s an energy around UX design that is far more vibrant than ever before. I wanted to know where that was coming from. As I dug into our research, I realized there are multiple forces making all this happen. And right in the middle of these forces is the world of designing for mobile. These forces are really strong, which means they’ll affect all of us. Want to know what they are? I’ll tell you at the tour.

When I set out for this year’s program, I didn’t expect half of the sessions to have mobile at their core. But here we are and I’m really excited about it. It’ll be a much deeper treatment than any we’ve seen before, which is perfect for the mission of the Web App Masters Tour — to prepare every web-based application designer for the intense challenges ahead.

[By the way, we're just a few weeks away from our Philadelphia stop on the tour. We're also stopping in Seattle and Minneapolis later this spring. Register for any stop by March 11 with the promotion code WAMT and you'll get $300 off the final registration price.]

Register with the promotion code WAMT by March 11, 2011 for any of the Tour cities and pay just $795.

Certain tips and tricks you can only learn from watching the best in the field do what they do. Peeking over the shoulder of an expert can teach you valuable techniques and insights that you won’t find in any book. That is exactly how the designers at Sidebar Creative learn from others.

The Sidebar Creative collective, made up of Dan Rubin, Bryan Veloso, Jonathan Snook, and Steve Smith, build and design some of the best websites and applications out there. They have over 50 years of combined experience they want to share with you. This year, the guys at Sidebar Creative are conducting intensive one day, hands on workshops to fine tune your skills as a web designer.

In this podcast, Bryan Veloso and Dan Rubin join Jared Spool to discuss some of their best tips and techniques they learned from each other.

Here’s an excerpt from the podcast.

“…The basic principles of form, white space, flow, typography, color, shape, and hierarchy, have changed in tiny little ways. But, the great thing is, that they haven’t really had to change in massive ways.

We have different movements and preferences with each decade. But those are all stylistic and we should embrace them.

Our tipping point is a different thing. When we’re looking at the tools, we have to be focused on not what they can do. Not feature lists, but how they can work best to serve us in our workflow and our needs.

If it’s the wrong tool for the job, find a different tool. If there isn’t a different tool, figure out how many different ways you can bend, twist, and break that existing tool. Basically, hack something like Photoshop and the features it provides to do the job you need it to do.

That’s where I think the excitement is on the tool side for people like us. We look at a tool like Photoshop, which has always been built for photographers. We look for all the different ways where we can subvert its features to do what we want to do.

We’re always on the lookout for a tool that can help us do our job better. It’s not about whether you prefer Photoshop or Fireworks, it’s about why you prefer Photoshop or Fireworks.

If the “why” doesn’t tie directly into how easily it allows you to achieve your creative vision and do your job, then it’s not a good enough reason. You’re probably not looking hard enough…”

Tune into the podcast to hear Bryan and Dan cover many points, including:

• Is using a CSS pre-processor, like SAS, a difficult thing to learn?
• How do you determine where a certain tool, like a pre-processor, will be valuable to use?
• How does using CSS3 help eliminate repair time and exhaustive testing?
• What are some of the latest tricks in web design?

Bryan, Dan, and the rest of Sidebar Creative are teaching an all day intensive hands-on workshop of their tips and techniques at the Web Design Masterclass. The workshops are coming to Austin, Philadelphia, and Los Angeles. For more information including dates, prices, and program, visit Web Design Masterclass.

Recorded: February, 2011
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
[ Transcript Available ] ]]> http://www.uie.com/brainsparks/2011/03/01/bryan-veloso-and-dan-rubin-peeking-over-the-shoulder-of-design-experts/feed/ 1 Certain tips and tricks you can only learn from watching the best in the field do what they do. Peeking over the shoulder of an expert can teach you valuable techniques and insights that you won’t find in any book. Certain tips and tricks you can only learn from watching the best in the field do what they do. Peeking over the shoulder of an expert can teach you valuable techniques and insights that you won’t find in any book. That is exactly how the designers at Sidebar Creative learn from each other. Jared M. Spool and User Interface Engineering (UIE) no 33:15 http://www.uie.com/brainsparks/2011/02/22/building-a-five-year-vision/ http://www.uie.com/brainsparks/2011/02/22/building-a-five-year-vision/#comments Tue, 22 Feb 2011 15:13:19 +0000 Jared Spool http://www.uie.com/brainsparks/?p=3448 Jon writes:

I am looking for suggestions of sites that offer good educated guesses about websites / web interactions in the future. We’re working on our five-year plan at our university.

Keep up the great work – your presentations are always informative, feature great web talent, and I always walk away feeling like I’ve learned something!

Hi Jon,

Predicting the future is hard. I suggest you focus on the experience of the users and not the specific design solutions that’ll be five years out.

These could help:

The 3 Steps for Creating an Experience Vision

Knowledge Navigator Deconstructed: Building an Envisionment

Keep those cards and letters coming.

Subscribe to our podcast via

Visual design is often considered an artistic realm. Many times people shy away from design or limit their involvement despite being completely capable of creating a great design. Learning the basics of design can help dispel the notion that it is only for the artistic. According to Dan Rubin, “there’s a big separation between being artistic and being creative.”

Dan is a highly accomplished user interface designer and usability consultant. He conducted a UIE Virtual Seminar called Visual Design Essentials for Non-Designers. So many questions were generated that we couldn’t address them all during the session. Today we’re bringing you the follow up podcast in which Dan tackles those remaining questions.

Here’s an excerpt from the podcast.

“…Design is not just the visuals and the aesthetic aspect of making something look pretty or attractive, while there are some established rules and just psychological principles of what makes something attractive, to most people it is a very subjective thing. You might like a different color palette than I do in a design. Or to one person a lot of visual flourishes might be appealing while to someone else it’s distracting.

But those aren’t the things we’re really talking about. Those are more of the artistic layer of visual design. Picture it in a couple of different layers. Design in its core is about the visual aspects that support the functionality in a given thing. If we’re talking about physical products in the real world or virtual products such as web apps and services the design is what communicates the functionality to the user.

When we talk about interaction design, that’s a more detailed side beyond just the communication, the actual interaction, the give and take. What people will click on and how that behaves.

When we’re working at a lower level, below the behavior, what we actually need to do is provide a foundation for that functionality or for the content. A framework of sorts that allows the user to easily interact with and understand whatever is being communicated. So at its core level, the principles that we were talking about in the virtual seminar are more about how to make something easily communicate its intention.

When we’re talking primarily about good typographical rules and creating a balanced visual hierarchy, those things are not subjective. Those just are. You can guarantee that people will react a certain way to these things. And we’re not actually looking for an emotional connection where we might be with color and the more artistic layer if you will.

That’s the nice thing about design. At its core level it’s not really subjective. It’s just a matter of good balanced decision making and not cluttering things, not overcrowding. A lot of the time people mistake good, basic core design principles for just common sense. Because once you see them applied properly they just do make sense. You can’t imagine them being done any other way…”

To hear more, tune in to the podcast as Dan also answers these questions:

• Do you have any strong opinions on fixed width content areas?
• What tools can non-designers employ to add visual depth?
• When your design is dominated by one specific color, how do you suggest incorporating new color relationships?
• When do you decide to use serif fonts versus sans-serif fonts?
• What are your thoughts on discussing some of the elements of the design with your clients, for example color?

As always, we welcome your opinions. Please share your questions and comments in our comments section.

Groupon generates delight through their clever use of advertising copy for the products they sell. For example, a recent ad for half-price gourmet brownies started with: “Without chocolate, the world would still be under the oppressive rule of the Turnip King and his tasteless parsnip army.” Groupon’s customers regularly say they find the clever copy delightful.

Well, here’s a public guide that explains the basics behind Groupon’s often entertaining copy: The Public Groupon Voice Guide.

Enjoy.

Join us in February, as we kick off the 2011 UX Book Club with the talented and funny Robert Hoekman, Jr.

The 2nd edition of Designing the Obvious just showed up in my mailbox and, wow, I’m excited. The first edition was a great book — so great that I kept lending my copy out and not getting back. I think I bought 5 of them.

Robert’s first edition hit on critical topics for creating great designs. In the second edition, Robert’s expanded the principles and examples to help you with today’s design problems.

I’m can’t wait to read this edition and talk with Robert about it. Please join me on February 1 with your thoughts and questions on the second edition of his classic.

How does this work?

Step #1: Reserve your spot at Eventbrite for the UIE Book Club (it’s free!)
Step #2: Get a copy of Robert’s Designing the Obvious. (Get your copy today at Amazon.)
Step #3: Read the book. Write down your questions.
Step #4: Join us on February 1 at 5by5 TV.
Step #5: Ask Robert your questions.

Thanks to the good folks at Aquent for helping us make all this happen.

Sign up for the UIE Book Club.
We’ll keep you posted with the details you’ll need as the event gets closer.

Subscribe to our podcast via

Design has made a lot of progress in the corporate landscape over the past decade, but many designers still find themselves justifying their existence on a fairly regular basis. Most companies, even those who claim to value design, aren’t taking full advantage of what design can offer them.

In Kim Goodwin’s talk, “Getting Design Into the Corporate DNA” from the 2010 User Interface Conference, she explains that it’s a matter of changing the culture of your organization. Kim understands that this is one of the most complex design problems you will ever have to face, but she can also tell you how to set it in motion.

One of the issues, as Kim points out, is that most businesses have a unit efficiency focus. This causes people to look inward and not share responsibility. It ends up promoting a lack of cooperation as turf wars develop and people begin competing for resources to ensure that their unit, department, or team is doing well rather than the company as a whole. This creates silos within the organization.

The alternative is a user-centered focus, but getting to that point isn’t easy. Kim concedes, shifting the way the entire company thinks is a daunting prospect. But she offers that organizational change is actually, in fact, individual change. She says to think of organizational change like moving a series of pebbles and boulders instead of the entire mountain. The organization is made up of individuals and shifting the organization is a matter of moving those individuals.

But it could be even more attainable than that. As Kim says, “Think about starting an avalanche. If you roll the right rock down the hill, it’s going to start taking others with it. You don’t personally have to touch every rock.” She encourages you to seek out the most influential “rocks” in your organization.

In order to bring change about, you need to be persuasive. Kim mentions that one of the greatest tools of persuasion is the users. She says that getting executives in front of users more often is one of the best ways to get them to begin to think differently about design. The more user exposure that you can get the more they will see the benefit of the design process.

You can also look for teachable moments. By that she means, look for a way to convey any unhappiness or dissatisfaction that your users may have. Then show how design can help improve the problem and give a clear way from Point A to Point B. In the end, it’s human nature to view change as loss. Exhibiting how design can improve things will help alleviate that sense of loss.

The audio to Kim’s full talk is available for purchase with all seven other Featured Talks from the conference as part of UI15 OnDemand. Also included are the handouts and presentation slides from the talks as well as the slides from the each presenters’ full day workshop. Get more information or place your order for UI15 OnDemand.

Have you experienced difficulty illustrating design’s value in your organization? Feel free to share your experiences in the comments section.

As we often do, we delved into our research to see if we could answer what’s new about these terms. We found, while people talk frequently about designing experiences, they rarely discuss what that actually means. We also found that designing for experiences is very different than designing for other results.

In this UIEtips, we’ll look at the differences among these terms and how you design for great experiences. If you’ve been calling yourself a user experience designer, I’m sure you’ll find our research helpful to explain what you do and what it takes.

Read the article, Designing Great Experiences – The Gap Between Activities.

While we’re on the subject of designing User Experiences, Leah Buley, who just rocked the UI15 conference, is our next UIE Virtual Seminar presenter. Her December 9 presentation, Lean Methods for the UX Team of One, is not to be missed.

Have you tried to explain experience design to your co-workers? What’s worked for you? We’d love to hear your thoughts below.

Subscribe to our podcast via

SEO and User Experience shouldn’t be at odds with one another. That’s what Vanessa Fox and Tamara Adlin tell us in this week’s SpoolCast with Jared Spool. Vanessa is the founder of Nine By Blue, author of Marketing in the Age of Google, and a former Googler herself. Tamara is the founder of adlin, inc, author of multiple books on personas, and a former customer experience leader at Amazon. Vanessa and Tamara are giving a full-day workshop on using business-driven personas to create holistic search and experience strategies at the User Interface 15 Conference. In this podcast, you’ll get a taste of what they’ve been working on.

When you make something usable, it naturally attracts search engines. That may fly in the face of some of the SEO talk you’ve heard. Vanessa tells us not to build your site with search algorithms in mind. Algorithms change. Instead you should build your site towards the aim of the search.

Tamara suggests building our sites around conversations with our users. That’s what the search engines reward. What problem does your product or service solve? Answer your customers’ questions on your site, and you’ll be found.

You need a holistic process across the silos.

A big stumbling block to this common sense approach to UX is corporate politics. People are naturally most concerned about their silo of the company. Tamara and Vanessa believe a good UX consultant will see the silo and ask everyone to step back and ask “What are the business goals”? It seems silly, but it’s effective. No UX or SEO will succeed without that clarity, says Tamara.

We’re thrilled to have Vanessa and Tamara give a full-day workshop on embracing SEO and UX through personas. We hope you’ll join us there. You can learn more about this topic and workshop in the podcast. Don’t forget to leave us your questions and comments here, below.

Explore Tamara and Vanessa’s workshop and the full conference program. Register for UI15 by November 5 with promotion code BLOGPOST and get $400 off.

The thinking is that once the heavy snows cut off the roads, fresh shipments of dairy and bakery products won’t get through. This thinking sends everybody rushing to the market to buy the remaining inventories, with some of the more nefarious market owners raising prices in response. All it takes is the whisper of a storm to create instant scarcity of these critical items.

While we don’t have an online equivalent of a French Toast Alert System, designers can use scarcity to encourage their users to take advantage of offers and functionality. In today’s UIEtips, we discuss what happens when we promote scarcity in our designs in the first of a two-part article written by Stephen P. Anderson. Stephen has been studying sites that use scarcity to their advantage, in turn making the sites more fun to use and more compelling to interact with. I’m sure you’ll find his examples as fascinating as I do.

Read the article: Playing Hard to Get – Using Scarcity to Influence Behavior – Part 1

Scarcity is just one technique we can use to take advantage of people’s desire for playfulness and their natural curiosity. Stephen is exploring several of these techniques in his upcoming online UIE Virtual Seminar, Leveraging Seductive Interaction Design on Thursday, November 4. We always find Stephen’s ideas to be
inspirational and thought provoking, giving us new ways to put fun into our designs. You won’t want to miss Stephen’s seminar.

Have you encountered designs that use scarcity? How about different ways to encourage users to act and participate? We’d love to see your examples. Share them below.

Subscribe to our podcast via

User Experience is a growing field. When a company starts incorporating user experience design, it often begins with one person. Our colleague, Leah Buley of Adaptive Path, has been researching this situation for a couple of years, and she’s found many interesting things.

We brought Leah to User Interface 14 to present her “UX Team of One”, and it was one of the most discussed sessions. We’ve asked her to return to User Interface 15 this year, to present her updated take on the subject. In this podcast she and Jared Spool compare their observations and experiences with small teams and UX-teams of one.

When someone takes up the mantle of UX within their company, they are quickly overwhelmed. They’re often a detail-oriented person who quickly builds a to-do list that’s just not doable for one person. Leah suggests the first thing to do is shift into the role of a design facilitator. A facilitator recruits her non-designer colleagues to help determine the necessary components of an experience.

You are going to do better design work, and lay a foundation for more user experience work in any organization… if you can invite other people into the process.

Jared adds that UXers often are more social, outgoing people. That is a helpful trait for facilitation. But beyond that, it’s a skill set that improves with practice. Leah agrees, adding that facilitation is a mindset as much as anything else. When you’re bringing non-designers into the process, Leah suggests setting your personal investment aside (perhaps even your ego). Listen for ideas that spring organically from your colleagues. Your colleagues provide helpful insight while you open the black box of design to them. Giving them a voice in the process also helps build their understanding of user experience.

Leah suggested two techniques that aid in collecting valuable feedback. One idea comes from Edward de Bono’s Six Thinking Hats. Leah suggested that the “black hat” mindset is useful to help pull concerns out of your colleagues. Black hat, in this instance, means being cautious and looking for potential problems. Your aim is to pull the group’s fears out of hiding, so people can be completely frank in your discussions.

Her second technique, graphic recording, helps you document the group’s thoughts in a meaningful manner. You can see examples of graphic recording at Sunni Brown’s Web site and in this promotional animation for Steven Johnson’s new book Where Ideas Come From. Graphic recording allows you to collect and share everyone’s input. This way you have a record, and people feel their concerns are being addressed. When you move concerns out of the way, people contribute more freely.

Tune into the podcast for more from Leah. We hope you join us for Leah’s How to be a User Experience Team of One and Good Design Faster: New Techniques for Creative Ideas at UIE’s User Interface 15 Conference. As always, leave your questions and comments below.

Explore Leah’s workshop and the full conference program. Register for UI15 by November 1 with promotion code BLOGPOST and get $400 off.

Subscribe to our podcast via

Kim Goodwin

Scenarios are comprehensive stories that describe how a persona interacts with your product or service. They are a powerful design tool that allows you to make intelligent design decisions based on your user research.

If there is a grand dutchess of personas, scenarios, and design processes, it’s Kim Goodwin. That’s why we asked Kim to do a workshop on turning user research into action at UI15. In this podcast, Jared Spool spoke with her about that workshop and some common myths surrounding scenarios.

Jared suggests that scenarios have grown out of necessity. Requirement documentation simply doesn’t cut it when starting the design process. Beyond what’s “needed”, you need user research. Kim says that requirements are flawed without user input.

“Let’s all start from a shared understanding of our users.”

Two common misunderstandings about scenarios involve their relationship to Agile processes. It’s easy to believe that Agile and scenarios are not compatible. If you have your designers and developers sitting down together on day one, you can’t have part of the work done ahead, right? Kim asks, why not? Placing research and scenarios in front of your designers and developers gives them a great starting point.

Some people confuse Agile’s user stories with scenarios. They are not the same, but they are compatible. Scenarios are all encompassing. One of their strengths is that they can span your company’s silos. A customer doesn’t see you as a series of departments, they see you as one brand. Within an Agile environment, your web team will not likely be designing both a web feature and a physical retail procedure simultaneously. Therefore, you can carve out the relevant bits of the scenario to create your user story for your current sprint.

“How hard is it for a three-year-old to make up a story? Storytelling is such a natural human tool… it’s really very easy.”

One complaint about scenarios is that they take too long to create. But Kim reports she uses them on even the smallest projects with tight schedules. Even if it’s just one afternoon with a few key stakeholders, she puts a lot of value in building shared assumptions about who the users are.

There is more ground covered in the interview. Listen to the podcast or read the transcript for more scenario mythbusting. Kim, who is a masterful teacher, also describes what she has in store for her full-day scenario workshop at User Interface 15, “Designing with Scenarios: Putting Personas to Work”

Explore Kim’s workshop and the full conference program. Register for UI15 by October 19 with promotion code BLOGPOST and get $400 off.

Subscribe to our podcast via

Luke Wroblewski

Luke Wroblewski is one of UIE’s top-rated speakers. He’ll join us at User Interface 15 in November to teach the cutting edge, research-informed, best practices for taking advantage of rich interactions. He’ll cover web forms, instantaneous sign-up processes, gradual engagement, and much more. He also has a heap of thought-provoking data and analysis of mobile Web tech and trends.

To give you a taste of that talk, Jared had a chance to speak with Luke about some of the latest trends, good and bad, in web input. Listen in to the podcast or check out the transcript.

Jared led off the discussion, by diving into one of Google’s latest public innovations, Google Instant. If you’ve missed the hubbub, Google Instant starts searching and returning suggested queries as you type.  Luke saw this technology developed during his time at Yahoo!, back in 2005. They ended up not using the technique on Yahoo!’s search because it can increase the load on the servers ten-fold.

We see this type-ahead search springing up across the web. The trick, as Luke saw first hand with Yahoo’s internal development, is doing it well. Doing so requires painstaking attention to detail, and the search itself must be tuned to the content of the site. The algorithms Google uses against their data might be very different from what an e-commerce site with only 400 products would use to provide a similar experience.

I think the ideas are really the easy part. It’s the actual implementation and details of making that idea come to life. That’s the hard part. Anyone can make these kind of off-hand comments, “We should do that”.

Luke notes that type-ahead search works quite well on Apple.com, returning intelligent results from their support pages, all as you type. The live results even feature inline images. What makes Apple’s execution of the idea notable is that they didn’t just do what everyone else is doing (suggest queries), but they adapted the idea to their site’s context.

Jared and Luke continue the discussion in the podcast, including more on in-line, dynamic interactions, like at Quora.com. They also chat about innovations in web input, where your users can instantly have their content on your site without entering it again and again. Lastly, they discuss what Luke has in store for his full-day workshop at User Interface 15. It’s a great discussion you won’t want to miss. Don’t forget to come back here and let us know your comments and questions about the topic!

Explore Luke’s workshop and the full conference program. Register for UI15 by October 19 with promotion code BLOGPOST and get $400 off.

Subscribe to our podcast via

Few people have thought about search, and all that it encompasses, like Mark Burrell. Mark’s the Worldwide Lead for User Experience at Endeca, the company that builds search applications for many of the sites you use every day. These guys know search, and Mark is tasked with making the search experience humane.

With his vast experience with search applications, he oversees the Endeca User Interface Design Pattern Library, which attempts to catalog many of the most successful interface patterns for search. The goal is to make user and designer’s lives easier—and their searches more effective.

Which is exactly why we asked him to join Peter Morville for a UIE Virtual Seminar on Search and Discovery Patterns, back in January of this year. Today we’re revisiting the topic by sharing the follow up podcast Jared Spool recorded with Mark. Jared and Mark discuss a few bonus questions from the seminar. Below are a few highlights from the podcast.

Much of the challenge in search lies in sorting through results in a meaningful way. There are a number of interface components that sites use to accomplish this, and one is the range slider. You may have seen them on sites like Kayak.com. But are these intuitive for the users? Mark says they can be, but the devil is in the details. Designing the search experience is complex and there aren’t simple answers. Used correctly, range sliders can be useful.

“Determine what information is critical for the people you’re designing for and make that salient.”
-Mark Burrell

One size doesn’t fit all. One question asked, should you use different patterns for different audiences? There is not just one right answer to this question, but you need to know your audience and their scenarios, Mark says. Different interfaces or patterns for different types of searchers can be an effective decision.

One example of this is with Intranets. Mark says there’s a surprising amount of overlap between design for Intranets and public-facing sites. But there are advantages to knowing your audience intimately, as with an Intranet. You can tune your search and interface for specific groups within your company. A great example is in searching for human resources information. An average employee searching for “insurance forms” might expect to get a list of the relevant forms for her to fill out.

But if this search comes from an HR employee, her scenario is almost certainly different. She might rather see recently updated forms or policy documents that pertain to the forms, instead of the forms themselves. Leveraging our existing knowledge of who is searching can lead to powerful modifications.

There is much more in the podcast, including a discussion of combining searching and browsing, the complexities of designing components that denote AND vs. OR searches, and the good and the bad with “type ahead” assisted search. Tune in, and then let us hear your questions and thoughts in the comments below.

Recently, a new kind of manifestation has emerged: redesigning. Professional designers, frustrated by the experiences they are having with the airlines’ deliverables, are voluntarily redesigning web sites and boarding passes. They are publishing their pleas for a better experience online and getting a great response.

Most recently, it was Zach Klein’s redesign of Delta’s club portal that caught my attention. Before that, it was Tyler Thompson’s redesign of the Delta boarding pass. And it all started with Dustin Curtis’s redesign of American Airline’s home page.

In each case, these talented designers took time away from their work and life to help the airlines develop a better experience. While the world of professional graphic artists insists that “spec work” is an evil that refuses to compensate designers for the value of their efforts, these designers are donating their time to persuade multi-billion dollar companies on the benefits of good design. And, the worst of it is, those companies aren’t listening.

Original Delta Sky Club Portal Page

Look at the Zach’s redesign of the Delta Sky Club’s portal site. The original page design had nothing to do with the club members current context and experience. Here you have someone sitting in a club in Salt Lake City, on their way to New York City, yet the weather is for Atlanta. There’s a link to a story about saving $600 on a Bermuda vacation and another that presumably lists all the club locations in airports around the world. And there’s an ad for a $74,000 Porche.

Redesigned Delta Sky Club Portal by Zach Evans

Zach felt these weren’t the most important things for someone who just checked into the club. His redesign had, in big, easy-to-read text, the departure time, gate, seat, and arrival time of the next travel leg. It contains information on nearby food options, whether the flight has wifi and tv, the length of the flight, upgrade status, and which baggage claim area. These are all things important to a traveler in flight.

It’s a clean, well-thought through design, even though Zach claims he only spent an hour (the time in the club) thinking about it and designing it out. It keeps Delta’s brand in place while delivering an effective experience for a seasoned Delta traveler.

Tyler Thompson’s Redesigned Delta Boarding Pass

Tyler’s redesign of the boarding passes followed the same themes as Zach’s. He took the existing cluttered information and, through color, grid, and typography, cleaned up it up, making it easy for a passenger to get to the information that’s most important: Flight, Gate, departure time, seat, and zone. Others joined in, with their own suggested designs. Each design took important requirements into account, such as making the TSA’s job easier for the info they need to find.

It all started with Dustin’s redesign of the AA.com site. In the blog post, he wrote, “The experience was so bad that I vowed never to fly your airline again.” He continued, “If I was running a company with the distinction and history of American Airlines, I would be embarrassed — no ashamed — to have a website with a customer experience as terrible as the one you have now. How does your CEO, Gerard J. Arpey, justify treating customers this way? Why does your board of directors approve of this? Your website is abusive to your customers, it is limiting your revenue possibilities, and it is permanently destroying the brand and image of your company in the mind of every visitor.”

Dustin Curtis’s Redesigned AA.com home page

He took their cluttered, ad-ridden pages and cleaned them up to provide a simple experience for making new reservations, finding great deals, checking flight status, and getting to your account details. He’s even left a place for the CEO to talk about their new image (hee!) and the multiplicity of other options that one finds at a big airline, like access to the route map and a link for getting refunds.

How bad does an industry need to let its customer experience get before it starts to listen? And, here, the listening isn’t hard. These talented customers are telling the folks they would prefer to do business with exactly how to make their experience better.

The world is filled with talented designers. Which is less expensive? Letting your experience degrade to the point of frustration for every customer? Or hiring the designers who can help you provide a great design?

Subscribe to our podcast via

This week, calling in from beautiful Salt Lake City, Utah, is Grady Kelly. Grady is inspired by Seth Godin’s new book, Linchpin. He wants to know how UX professionals can work to become indispensable team members and not just another cog in the machine.

Jared believes that indispensability starts with demonstrating the value of your work. Usability improvements reduce frustration and create delight. Have metrics in place that document that progression as your designs are implemented. Are your changes reducing calls to support or increasing sales? Showing those metrics is concrete evidence.

Robert believes just being a user experience professional makes you more than a cog. Set a goal for yourself in your organization, and measure your progress. Reach out to teammates with help, educate them on UX, and build trust. Then, when people come to you for help and their suggestions improve, you know you’ve made a positive impact.

Tune in to the podcast for the full story. Don’t forget, if you have a serious UX question, send it in and Jared Spool and Robert Hoekman, Jr. will answer it with a healthy dose of levity. Please send your deep, vexing questions to us at userability@uie.com. We’d love to feature you on the show!

Subscribe to our podcast via

It’s becoming common to see behavioral cues in everyday web applications. Designers are looking to encourage certain actions, and are turning to the principles of behavioral psychology to achieve their goals. No longer solely the domain of social and gaming apps, you can leverage many of these in your daily work.

Stephen Anderson is the first person we think of when it comes to these kinds of interactions. Stephen is an independent consultant and creator of the Mental Notes, a set of reference cards with design insights from the world of psychology.

Stephen is one of the most popular speakers at the Web App Masters Tour and we want to share a sample of his talk, Designing Seductive Business Apps. In this portion of his talk, he presents three concepts: Scarcity, Set Completion and the Feedback Loop.

[ Download the complete set of this section's slides and follow along. (6MB PDF) ]

Scarcity

Scarcity is a concept we’re all familiar with. When something desirable is rare—like gold—the more valuable it is. When someone is considering the purchase of something, its availability is an important factor in the decision.

Set Completion

Set Completion is something we see all around us. When was the last time you saw a fast food ad where the restaurant was offering a give away? Collectible glasses and kids meal toys are two common ones. Usually there are several different version of the giveaway, and you’re encouraged to “Collect all five!” The closer we are to having a full set, the stronger the urge to complete the set.

The Feedback Loop

The Feedback Loop is essentially “cause and effect.” When we see our actions have an immediate effect on a situation, we are likely to become engaged. Have you ever walked in front of a TV display at a retail store and noticed you were on the TV? It probably stopped you in your tracks. In web apps, the more immediate the effects of our actions are seen, the more engaging the interaction can be.

The article quickly became one of the most popular articles we’ve ever published. People love the fact that a small design change could be linked to a huge increase in revenues. It’s the ultimate ROI story.

Yet in our research at User Interface Engineering, we see these kinds of increases all the time. And $300 million isn’t anywhere close to the biggest.

In today’s UIEtips article, we look back at another article from 2009. Here, I talk about a design element whose income contribution is possibly 10 times larger. It’s a simple question on the Amazon site—one you’ve probably seen a thousand times—yet it is critical to the success of the business.

Unlike the previous story, where we worked on the project, this story comes from our research of Amazon, independent of any projects we’ve done for them. Therefore, our revenue projections are estimates this time. But even if we’re off by an order of magnitude, it’s still an impressive number that tells us how a well thought-out design can make a big difference.

Read today’s article, The Magic Behind Amazon’s 2.7 Billion Dollar Question.

Increasing the effectiveness of a design is exactly what we’re talking about at the UIE Web App Masters Tour. We still have stops in Philadelphia and Seattle. Learn more about the 9 Masters presenting in each city at www.UIETour.com.

Have you had any design changes that had a big impact on your organization’s bottom line? We’d love to hear your stories. Share your thoughts below.

Until May 21, register for Philadelphia or Seattle and get $100 off when you use the promotion code TOURBLOG. Learn more about the tour at www.UIETour.com

Subscribe to our podcast via

It seems we’ve failed to offend our international audience sufficiently, so this week we’ll try again by chatting with Jay Vidyarthi, a designer hailing form Montréal, Québec, Canada. Jay is working on a project with social design aspects. He’s helping design a site where the goal is to build “an involved and contributing community of users.” He wants to know if there are any user experience techniques to encourage participation.

Jared and Robert think human psychology is the place to start. They discuss a couple of recent issues in the social web realm, like the launch of Google Buzz. They suggest a few books which examine the intersection of psych and web design, including Joshua Porter’s Designing for the Social Web, and Christian Crumlish and Erin Malone’s Designing Social Interfaces.

Tune in to see if Robert and Jared manage to help Jay with an answer without offending our friendly neighbors to the north.

Have a serious UX question? Send it in and Jared Spool and Robert Hoekman, Jr. will answer it with a healthy dose of levity. Please send your deep, vexing questions to us at userability@uie.com. We’d love to feature you on the show!

Thankfully, Dan Rubin can show you the simple steps to create solid visual design. Dan is a talented designer in his own right, but has a special knack for teaching visual design for people without an artistic background. That’s why we’ve asked him to present our next UIE Virtual Seminar, Visual Design Essentials for Non-Designers, on May 13, 2010. He’ll teach you how to recognize common design mistakes and effective ways to make your site look good, whether you’re a natural artist or not.

Register with the promotion code BRAINSPARKS and get lifetime access to the recording of this seminar at no extra cost. Anyone in your organization can watch it whenever they want, as often as they want.

How do you create a visual design that matches your great ideas? When you look at a web page, and something isn’t quite right, how do you know what to do about it? We’d love to hear your thoughts on this. What tips or tricks can you share that have helped you improve your visual design?

Forms are crucial for users to complete many online transactions, ranging from sign-up forms for introducing new customers to your site, to checkout forms for finalizing your users’ purchases.

In this week’s UIEtips, we’re republishing part 1 of an article written by Luke Wroblewski. He’s one of our favorite experts on web form design. Luke discusses tips for improving web forms and impacting user success. Stay tuned next week for Part II.

Read Luke’s article: Web Form Design in the Wild, Part 1

Web forms are one of the most challenging design problems. In our next UIE Virtual Seminar, Luke shares his thoughts and solutions on 6 important aspects of web form design gleaned from hundreds of questions and issues designers presented to him. Learn more about Luke’s webinar, Answered! Your Top Questions on Web Form Design.

Do you have any best practices for designing forms? What usability problems have you encountered with your web forms? I’d love to hear about your experiences. Share your thoughts with us and join the conversation below.

Subscribe to our podcast via

It is a good Friday indeed, because the Userability Podcast is back from hiatus! We have several all-new episodes in the pipeline that you’ll see in the coming weeks.

This week’s episode features guest Mohammed Alaa, calling in all the way from Cairo, Egypt. Mohammed is a UI designer who wants to expand his skills to include more from experience design. He asked two questions:

• I mostly work with business applications. I want to convince my manager and my client of how important it is to have a plan for usability testing, during the process of creating the project. How?
• My current position is as a user interface designer. And I would love to know if there is any specific course of study to become a user experience designer? And what’s the difference between a UI designer and a UX designer?

Two questions means twice the ridiculousness as Robert and Jared stall for time with their replies. Eventually, they arrive at useful advice for Mohammed (and perhaps you) even if there was a hike involved getting there.

Have a serious UX question? Send it in and Jared Spool and Robert Hoekman, Jr. will answer it with a healthy dose of levity. Please send your deep, vexing questions to us at userability@uie.com. We’d love to feature you on the show!

Prototyping is an iterative process. You discover what works, what needs improving, and opportunities for new ideas. The earlier you learn about a design change, the easier it is to implement, and the less costly that change will be. Prototyping allows your team to explore ideas before you invest in them.

In this seminar, Todd Zaki Warfel, a recognized leader in the design-research and usability fields, will explore his Eight Guiding Principles for prototyping. These principles are the foundation for more effective prototyping, and will improve your design process whether you’re a seasoned prototyper or just getting your feet wet.

Register before March 24 to get your free personal PDF copy of Todd’s book, Prototyping, A Practitioners Guide, and lifetime access to Fred Beecher’s seminar, The Whys, Whats, and Hows of Prototyping.

Tell us how prototyping fits into your design process. Do you have an example where something in the design was caught early and saved a bunch of money? Or one where something was identified late and cost money? What is your experience with prototyping, and how do you sell it to the rest of the team? Or your stakeholders? Share your thoughts and experiences below. We’d love to hear them!

Subscribe to our podcast via

Julie Zhuo

When Facebook tweaks anything, it gets coverage across the IT and design realms, and sometimes the Wall Street Journal and New York Times. If the users don’t like the changes, they form protest groups… how can a team operate under such a public microscope?

Julie Zhuo knows. She is the Product Design Manager at Facebook. As the principal designer behind the Facebook Platform and Facebook Connect experiences, she’s contributed to the last two major site redesigns. She also leads the front-end user interface engineering team. On her watch the site grew from 8 million college kids to 350 million people across the globe.

Jared Spool had a chance to chat with Julie recently. The stories she shared, from behind the scenes, are fascinating. When was the last time a throng of people gathered outside your office because you changed a feature on your site? Julie tells that story in the podcast, plus touches upon:

• The early years of innovation and launching features fast, and without testing
• Taking major design risks in front of a large, passionate audience
• How they moved to a strong routine of metrics, A/B tests, usability testing and staged rollouts
• …and much more

Julie talks about the transition from the run-and-gun design strategy that Facebook once used to roll out new features fast, and how it evolved to a more measured approach, while still moving quickly:

We are cognizant of the fact that every time we make a change, the initial user reaction is going to be a little bit negative. That’s why listening to feedback really matters. If all of the feedback is basically, “I don’t like this change because it’s different,” then maybe that’s a sentiment that will go away once people use it regularly.

But if the feedback is, “I don’t like this change because now I can’t find my applications,” or “I can’t find chat,” or “I can’t find messages.” Then that’s a real wake-up call for us that we really need to examine this change and see if we’ve regressed in making it easier and better for users.

They progressed to a test first, launch second strategy, that in some sensitive cases involved a lot of testing.

Last December we launched a change to privacy, and so when you logged into Facebook one day, you got a little privacy dialogue that said, “Hey Facebook is making some changes to privacy. Please revisit your privacy settings.”

That is not going to take that long to build. Right? It doesn’t take that long to design, it’s just one little dialog. But the process for us getting to that final point was months and months, because we knew privacy is such a sensitive topic for people that we wanted to be absolutely sure that what we were doing people would be comfortable with. It was the right thing to do.

Maybe four or five months prior to our launch, we were already bringing people in. We hadn’t even started building the pod. It wasn’t really even designed. We were just showing them a little text dialog with the language that we were going to use and with a lot of different options for how we would present this messaging to them.

These are like paper, low-fi prototypes, nowhere near what the final product will be. But prior to us even building and getting nice mocks from everyone, we already had at least five sessions with a bunch of users testing about 30 different versions of the language and the messaging for this dialog.

So many companies struggle with building the proper amounts of user research into their design process, but so few do it with so many users and so much public attention. Julie’s stories are fascinating case studies that should prove valuable to your own organization.

Julie has many more stories from behind the scenes at Facebook which she’ll share with us in San Diego at the UIE Web App Masters Tour. Join us for her Design Lessons from 350 Million session.

Are you struggling to balance the need to launch features fast with the necessary user research? Let us know in the comments.

Subscribe to our podcast via

How can we design systems that encourage the behaviors we want?

One of the bleeding edge ideas we’ll be talking about at the UIE Web App Masters Tour is adding motivation to web applications. How do you encourage user behavior through the design of your web app? It may initially sound a bit far-fetched, but there’s an industry that’s been shaping its customers’ behavior since the beginning: the gaming industry.

Stephen Anderson

Stephen Anderson is a consultant and a thought leader on the idea of motivating user behavior through design. He and Jared Spool sat down sat down for a discussion as part of our series of interviews with the Web App Masters.

Stephen’s developing a deck of cards to aid designers in brainstorming their designs, with consideration to behavioral cues. He calls them Mental Notes Stephen says,

“We focus on things like visual design, usability, or the information architecture and we forget about, ‘Oh yeah, there was that thing about gifting or curiosity or the peak-end rule.’ This is really a way to apply intention, or a way to intentionally remind people to use some of these, or try to leverage these.

These are ideas about human behavior and how humans respond to different ideas or different stimulus. So my idea is why aren’t we applying these to web design? We’re applying them to marketing, to retail, to interpersonal relationships, and to dating.

A lot of these ideas are nothing new, but I think we’re just now reaching the point where we’re thinking more consciously about how can I apply something like recognition over recall to web design?”

Stephen also gets into how we can use these persuasive or seductive ideas into shaping the initial engagement a web app has with its user.

“Attention is so scarce today that people spend 30 seconds on something, and they might not see the value or see why it could be useful to them in those 30 seconds. So my focus started shifting from the product itself to that initial engagement, that initial interaction, and how do we make that first experience a lot more seductive, so people stick around long enough to see that you really do have something worthwhile here?

Going back to real world analogies, think about if you were doing those not with a system online, but with a human. The human could be very straightforward, very to-the-point, in asking the questions, or that human could be very personable, and maybe crack a joke, or ask you how you are doing, do these things to be more personable. …why can’t these systems adopt some of those similar ideas?”

Stephen mentioned an internal corporate knowledge-sharing web app that he was involved with. The company used a lot of game-type incentives to encourage employee participation, but many of the most successful attributes are some of the most counter-intuitive. For example, to add content to some pages, employees had to “pay”. And this encouraged participation. They paid with points they accumulated doing other tasks within the system, like answering co-workers’ questions. Employees would attempt to answer the questions first so they could gain points before someone else beat them to it.

“…they described, in very qualitative ways, how you earn karma (“points” in this example) and how you get better at this game or this system. But they were not explicit with what activities you do and how many points you get for each. And I think that was very smart.”

We appear to be at the very cusp of adding psychology and a touch of gaming into web apps. From the friendly copy tone on Flickr to the full-on game strategy employed in Stephen’s example, it’s clear there’s a lot of potential here. You’ll want to listen to the entire interview and of course, you’re not going to want to miss Stephen present his talk, The Art & Science of Seductive Interactions, at our UIE Web App Masters Tour. It’s going to be impressive.

Stephen Anderson is just one of the incredible speakers we’ll be hosting during the Web App Masters Tour. Learn more about our locations dates and speakers at UIETour.com.

Are you building your web apps with an eye towards motivating specific behaviors? Let us know in the comments!

We’ve lined up two more Masters for our UIE Web App Masters Tour. We’re thrilled to announce Bill Scott and Ken Kellogg will be joining us.

Bill Scott

First, let me say this: Bill is the nicest person on the entire planet. You’ll notice this the moment you talk to him. But that’s not why we invited him.

I wanted him on the Masters Tour because he’s brilliant, particularly when it comes to design patterns for web-based applications. Bill spoke at our Web App Summit a few years back and dazzled the audience with his presentation on Anti Patterns—things you shouldn’t do when designing.

In addition to co-authoring the book, Designing Web Interfaces: Principles and Patterns for Rich Interactions, Bill is also the Director of UI Engineering at Netflix. All of these things add up to one thing: you’re going to love his insights. Bill will be with us in all four cities.

Ken Kellogg

Managing the design of a $6.5 billion a year website is no easy challenge. Especially when that website is owned by one of the oldest, most respected brands in the world. While many of us deal with the battle of old ways against modern thinking, this is on an epic scale.

That’s why I wanted you to hear from Ken Kellogg, who sits directly in the middle of that battle, as the Director of User Research for Marriott International. Ken is currently guiding major design changes through Marriott.com and will report, first hand, what that has been like. His stories will inspire you. You can hear Ken talk about his experiences at every stop on our tour.

It’s coming together.

Bill and Ken join a great slate, including Doug Bowman, Stephen Anderson, Julie Zhuo, and Christian Crumlish. Oh, I’ll be there too (but you probably knew that).

Just a few more presenters to go and we’ll have a full program. This is getting exciting now.

Get Notified As More Details Come Along

What’s that? You want to be notified on additional details and registration? No problem, just leave us your email address and we’ll send you a quick note when we have more information.

Julie Zhuo

The designers at Facebook try hard to make Facebook users happy. It’s a hard-to-please audience, and there’s 350 million of them. As Facebook’s Product Design Manager, Julie is at the front of the storm, designing for the site that’s grown from 8 million college students to its current worldwide audience.

She’ll be sharing some of her team’s successful and not-so-successful design experiences, so we can all learn from their experience. The interesting part is that many of the problems they face are just like the ones we face, and their solutions are quite creative. You’ll hear Julie’s experiences at our San Diego stop on the tour.

Christian Crumlish

Many web applications, whether on intranets or public facing, involve making connections with other people. From the address book and contact list, to messaging and content sharing, we see more web apps helping people communicate and collaborate.

We can’t think of a better person, to introduce social features into your web-based applications, than Christian. Working with his co-author, Erin Malone, they have compiled an amazing library of patterns in their new book, Designing Social Interfaces. We’re excited to have him as one of our masters on this tour and can’t wait to hear what wisdom he’ll be sharing with us. We’re fortunate that Christian will be at each stop of the tour.

Stay tuned. We should have more additions to the program tomorrow. And we’re adding more to the site every day, as we get ready for the launch in a few days! Watch along at uietour.com.

Join us January 12 for our next webinar: Leveraging Search & Discovery Patterns For Great Online Experiences, with Peter Morville and Mark Burrell.

The abundance and variety of search implementations present a challenge to designers: How do we leverage the behaviors our users are developing to ensure they find the content they’re seeking? By understanding how people interact with search implementations, we can create effective designs that deliver great experiences for both searching and discovering.

We couldn’t have timed this seminar better. In just a few weeks, Peter Morville will put his new book, Search Patterns, to press. And Mark Burrell and his team at Endeca have been working hard to release their new UI Design Pattern Library for Search & Discovery. So, this is the perfect time to talk about how to leverage patterns for better search designs.

This seminar is perfect for you, if you’re working on providing the best experience with your site’s search implementation. Bring your entire team and schedule extra time to talk about what you’ve learned—you’ll want to implement Peter and Mark’s ideas right away.

This winter, Peter’s new book, Search Patterns, published by O’Reilly, will hit the stores. But you won’t have to buy it, because as soon as it comes off the press, we’ll send you a copy—just because you attended this seminar.

Thanks to Peter, Mark, and the great folks at Endeca, we can include this must-have book. We’ve seen an early draft and we’re amazed by Peter’s talent to explain these topics so clearly. The beautiful full-color illustrations and screen shots don’t hurt either.

Register your team today, and reserve your copy of Search Patterns.

Do you use design patterns? What questions do you have about them? Where do you go, or where would you go to find them? Share your thoughts and experiences below.

At year’s end, it’s common to reflect and revisit what you’ve done. We thought about the articles that had the biggest impact and really got people thinking.

Even if some readers didn’t agree with our conclusions, it started a discussion and brought awareness to some important user experience issues.

Here are the 5 favorite articles from 2009