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.

The world of mobile design is new, and therefore, scary for many. The comforts of designing for the desktop disappear when we have to deal with these portable, tiny devices. Even the way we design – the processes and techniques we’ve honed over many years of practice – suddenly doesn’t work the same. We need to think about our work in new ways. Very scary.

Yet this scary new world also brings tremendous opportunity. Thanks to the pioneers in this space, there’s a new appreciation for the value of design. That new appreciation gives us room to rejigger the broken parts of how we’ve designed in the past. And that’s really exciting.

In this week’s UIEtips, I explore both the scary and the exciting that comes with mobile design. Join me as I look at four areas where designers will face challenges and opportunities in the coming year.

Read the article: UX & Mobile Design – 2012′s Challenges and Opportunities.

If you’re facing these mobile design challenges and opportunities, then you’re in for a real treat. We’ve just announced our new spring conference: UX Immersion 2012, which has a focus on creating great mobile designs. You’ll want to consider one or two of the in-depth, full-day workshops by Rachel Hinman, Luke Wroblewski, or James Robertson. These folks will help you overcome the challenges and take advantage of the opportunities. See the entire UX Immersion program.

How are you dealing with the challenges of mobile design? How have you taken advantage of the opportunities? Leave your thoughts below.

You’re about to see a project we’ve been working on for several months. A brand new conference bringing the newest, most critical thinking around two separate and important topics: mobile design and Agile development.

These experts will dive deep and get to the nitty-gritty details that will make you a stronger and more valuable UX Pro.

Agile Process

• Hugh Beyer – UX Design Inside Agile Development
• Jeff Gothelf – Lean UX: A Radical Approach to Integrating Design into Agile
• Dave McFarland – Demystifying jQuery for Agile Prototyping

Mobile Design

• Rachel Hinman – Creating Great Mobile User Experiences
• Luke Wroblewski – A Detailed Look at Designing Mobile Inputs
• James Robertson – Innovative Mobile Intranet Designs for Your Enterprise

Get First Dibs on a Seat When You Become a VIP

There are only 100 specially priced $1,349 spots available for the 3-day UX Immersion Conference. One of them can be yours.

VIPs will receive a special link to access registration on Monday, January 30. Everyone else will have to wait until Tuesday night to save their spot.

So be sure to get on the VIP list and start exploring the UX Immersion Conference.

Users’ behaviors change based on how they view digital content. The desktop computer is no longer the norm for reading content and conducting web interactions. As a designer you must think about designing for the plethora of mobile devices now available. It’s not a question of whether to consider mobile design, it’s a matter of actually planning and implementing it now.

And how we communicate our designs is shifting. Agile threw a wrench into wireframes and the solid set of deliverables that would serve as a contract. More and more, design teams are testing out the idea of a collaborative journey where design and development are working together in short sprints.

However, one major core UX principle has not changed: put the user first, think about who they are and what they need, and build to their tasks.

3 Intense Days to Make You a Stronger UX Pro

We thought about all of this when we were putting together the UX Immersion Conference 2012 – Agile/Mobile happening in Portland, OR, April 23-25, 2012. Our vision for this event is to bring the newest, most critical thinking around two separate and important topics: mobile design and the Agile process. We’re not presenting brief introductions and sending everyone on their way. We want UX pros to get an in-depth understanding of what’s new and what’s changing.

We’ve carefully designed the UX Immersion program to get you completely up to speed on where we are in these new worlds. You’ll learn the latest techniques for dealing with a UX process in an Agile environment. You’ll discover what it takes to build usable, useful, and delightful mobile apps that work within the ever-changing standards.

We’ve assembled an amazing team of leading-edge thinkers on these new forces. These folks have been pioneering these areas. They are the thought-leaders that everyone goes to for the tough problems. And, importantly, they are excellent teachers who can make a day of this material really fun and engaging. Who are they? You’ll find out really soon.

Get on the VIP List

Later this week, the UX Immersion 2012 – Agile/Mobile web site will launch. On January 30, registration will open exclusively to those on the VIP list (believe me, you want to be be on the VIP list). These folks will get the first shot at the 100 seats available at the lowest conference price. Starting at 5:00 pm, January 31, we open registration to everyone.

Become a VIP by signing up for the UX Immersion email list. As a VIP you’re guaranteed the lowest conference price, a conference gift, and other special perks. You can also follow us on Twitter for the latest conference updates and news.

We’ll see you in Portland in April.

Join us in Portland, Oregon April 23-25. Immerse yourself in 2 full days of workshops from renowned UX specialists and one day of short talks full of tips, techniques, and case studies.

Want to know more? Sign up on our email list and we’ll send you the latest information as soon as it’s available! We promise not to share your address. We hate spam too.

In his UIE Virtual Seminar, Telling the Right Story with Data Visualizations, Noah will provide demo data to teach you how to effectively conceptualize, plan, and ultimately design powerful visualizations that tell the right story. But be advised: you’ll never look at data the same way again.

You’ll learn to:

• Decide what story to tell with your abundance of data
• Choose the best data for telling that story effectively
• Select which encodings best align with the data
• Design visualizations that clearly convey meaning

If you’ve read all the blog posts and still find yourself stumped with how to design visualizations of complex data, then this seminar is right up your alley. Get a step-by-step guide to reviewing, choosing, and designing effective data visualizations.

We’re bringing back Noah Iliinsky to follow up one of the most popular UIE Virtual Seminars of 2011—Information Visualization: Letting Data Tell the Story. Register for his February seminar with the code VISUALIZATION, and we’ll send you access to his first 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.

Back December 2011, we asked your help in naming our brand new conference. There weren’t a lot of details other than it’s a 3-day consisting of full-day workshops and one day of short talks all focusing on two separate themes – mobile design and Agile. Like all the UIE events, we’re loading this conference with field-leading, edge-defining, top-caliber speakers providing you with techniques to immediately make a difference with your designs and inspiring insights.

We certainly weren’t disappointed with the response. We received over 450 entries.

Many of the suggestions consisted of creating a new word. Mogility, MoAgile, Magile, and Magility were popular entries.

Some folks went the acronym route. Magic: The Mobile – Agile Conference, MAID: Mobile Agile Insight & Design, MAX: Mobile Agile Experience, and MoMMA:Masters of Mobile Media and Agile.

All these submissions provided ammo for another round of name brain storming in our office. These names (some submitted, some we thought of) made the final cut.

• Be Agile, Go Mobile Conference 2012
• Adaptation: The Mobile & Agile Conference
• Adapt UX: The Mobile & Agile Conference
• BAM – Best Practices for Agile and Mobile
• UIE Trends: The UX Conference for Mobile & Agile
• Scrums and Thumbs: UX Conference for Agile and Mobile
• POP UX 2012: UX in Agile and Mobile
• UX Immersion 2012: Agile and Mobile

So how do you choose the right name, one that’ll be the forefront of the event’s brand? To make our decision, we turned to the same techniques we use for prioritizing large amounts of user data.

The Process

As with any good process, we first needed to figure out how we’d know if we did a good job. We needed success criteria. So we went about identifying the qualities of a good UIE event name.

As we looked at names we sorta liked and ones we didn’t like as much, we started discussing how they were different from each other. That gave us some perspectives: we wanted the name to be remarkable, but not too cute. It needed to be easy for someone to sell to their boss, since many folks will need to ask to come.

We knew that it had to convey the theme of the conference. A name that was easy to use in promotional materials. And that it conveyed it was associated with UX. In all, we ended up with a list of 8 attributes. But it would be impossible to find a name that matched all of those. So we needed a way to figure out which attributes were most important.

(Coming up with attributes like this is the same way we figure out what makes one study participant different from another, when we’re creating personas. We make playing cards for each participant, pull out two cards, and ask “What’s different between them?” and “What’s the same?”)

We used another technique from our client work: we gave each attribute a weight. Every person on the team assigned a number from 1 to 5, where 5 is a must-have quality and 1 is a nice-to-have.

To come up with a group consensus, we used a two-step voting process. First, everyone gives a number. Then we discussed any differences. (Why did Brian give that one a 2? Why did I give the same thing a 4?) Finally, everyone voted again (because the discussion changes people’s minds) and we chose the mode average. (Some people use median average, but that creates crazy precision that I don’t think is necessary.)

We then put our final cut of names through the criteria to see how they scored. Three names all scored pretty high. Our next step was to see how a designer would use the name in the logo. After seeing some initial sketches, it became clear what to name this new conference.

And the name is…

Are you ready? Here it is: UX Immersion 2012 Conference—Mobile/Agile.

It fit all our top criteria and we liked how we can easily shorten it to UX Immersion. (In the office we’ve already shortened it to IMUX or if you want to be Yoda like – UXIM.)

The web site will be up soon. In the meantime, if you want to get updates about the conference, sign up on our email list.

The Winners of the Contest

No one submitted this name directly, however four people submitted names that started with UX. No entries had immersion in the name. Since we can only have one winner, we decided to do a drawing among submissions from these 4 individuals. Congratulations to Gary Anderson. The other three people will receive runner-up prizes of the newly released UI16 OnDemand.

Finally, as promised, we drew three email addresses at random for the virtual seminar give away: Carol Roberts, Marci Kenneda, Chris Eklud.

Thanks to everyone who participated. Be sure to follow us on Twitter for the latest updates on the UX Immersion 2012 Conference—Mobile/Agile.

You’ll hear the latest insights on:

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

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

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

Order UI16 OnDemand today!

During the spring of 2012, (hint: probably late April) we’re producing a new conference. We’re still putting it together, so we can’t share too many details.

I can reveal this: It’s gonna be about the best practices around designing mobile and incorporating agile into your work environment.

Over the 3-day conference, attendees will choose from a variety of full-day workshops, 90-minute talks, and keynote presentations. It’ll have the kind of field-leading, edge-defining, top-caliber speakers you’ve come to expect from a UIE event, jam-packed with techniques to immediately make a difference with your designs and inspiring insights.

It needs a name. The MoAgile Thingy just doesn’t flow right.

We don’t know what to call this 3-day thing. For lack of anything better, we keep calling it the “MoAgile Thingy”, but we’re dubious that’ll play well outside our walls.

Unlike the last year couple years, this won’t be a conference that goes on tour. This new conference will only occur in one city during 2012.

Give our Thingy a name. Win a free registration.

Would you like to come to our Thingy for free? If so, help us find a better name.

We’re holding a contest. If we like your name, you get to come for free. And 3 people who enter will win a free UIE Virtual Seminar of their choice (live or a recorded one).

Send your entries (as many as you want) to contest@uie.com by midnight (EST) on December 22, 2011. Any ideas are good ideas.

We’ll pick three email addresses out of all the submissions at random and send instructions on how to pick your virtual seminar.

And, if we love your event name enough to use it, you can be our guest at the MoAgile Thingy (or whatever you called it)! How cool would that be?!? (You’ll walk around the event, pointing at every badge and sign, telling everyone around you, “I came up with that!”)

Please, help name our thingy and send your ideas by midnight, December 22!

Now, what they are building is usually some made-up project, constructed to practice the techniques. The actual results of the design don’t really matter, but, in a great workshop, the students become engaged and put a lot of energy into what they’re building.

At the end of the workshop, they want to show all their hard work. And everyone wants to have a glimpse of what the other folks in the class have done, to see how their design compares to other efforts.

In my workshops, I’ve tried a bunch of different approaches to the sharing. I’ve held walk-around show-and-tell, where people stand by their work. It’s like at a poster session or science fair, while others see what’s they’ve done. Unfortunately, the person who has to explain the work doesn’t get to see what others have done.

I also have tried having each team give a short presentation. It’s interesting for the first couple, but then, because everyone has worked on the same thing, it starts to drag on. Presenters don’t stick to their time limits and their presentations tend to be dry. The pain is compounded because all this happens at the end of a busy day, when everyone is exhausted by being in an all-day workshop.

Kevin Hoffman has a unique way of handling this. In his UI16 Workshop on Conducting Effective Kickoff Meetings, he had his attendees work on a design to practice the various kickoff meeting techniques he was teaching. At the end of the day, they’d all worked hard on their projects.

To show their work, he had them give presentations, Pecha Kucha style. That means they have to give their presentations using 5 slides which automatically advance every 30 seconds. One slide is a picture that Kevin took of their work, while the other four slides are clever art that the visual designers at Happy Cog put together. They don’t see the slides until the audience does and then have to make up a tie-in to their thinking, right on the spot.

The result was an entertaining set of short presentations. We got to see the work, while people had some fun improvising to the slides. Because Kevin only does this with four teams, it goes by very quickly.

I’ll be using the Pecha Kucha style presentation in my next project-based workshop.

[Update: Kevin tells me he borrowed this technique from Luke Wroblewski.]

Here are some of the slides that Kevin used, created by the Happy Cog visual designers: Chris Cashdollar, Yesenia Perez Cruz, Brian Warren, and Kevin Sharon. Imagine presenting your own work, having to work these images into your description of why you made the choices you did. How fun is that?

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

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

Read the article, On UX Leadership.

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

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

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

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

How to get the free recordings?

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

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

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

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

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

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

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

Mobile is the “hot topic” these days. It’s increasingly at the front of designers’ minds. In a world where the power and capabilities of the device in your pocket are so great, the possibilities become somewhat astounding. The mobile landscape is changing so rapidly that it makes developing a formal strategy to “figure mobile out” all but impossible.

Luke Wroblewski is at the forefront of the mobile design movement. He suggests that it’s better to put something, anything, out there and see how it fares. Excessive planning in the mobile space leads to missing opportunity after opportunity. Taking advantage of the market as it is today and the capabilities of these devices can lead to the refinement and evolution of your product.

Luke will be conducting a full-day workshop full of his thoughts on mobile, including why you should design for mobile first, at the User Interface 16 Conference, November 7-9 in Boston. Learn more about Luke’s and the other 7 full-day workshops at UIConf.com.

Here’s an excerpt from the podcast.

“…today, [mobile] devices have a lot of constraints based on the ergonomics. They’ve got a small screen. In many situations, you’re using them in environments where there’s other stuff going on. You’re not hunkered down at a desk for an extended period of time.

You may be at home on the couch watching TV, or you may be in a line somewhere, or passing some time in, hopefully, not the car. So there’s these constraints. Low bandwidth is another constraint. And when you use the devices, you familiarize yourself with what those constraints are.

But there’s also a lot of opportunities in terms of capabilities. And if you use lots of apps, you can see, how are they using the accelerometer? What have they done with front and rear-facing cameras? How are they using location in order to deliver information? How are they using the video port, the camera, the audio input? All those things can open up new ideas about how to take advantage of those capabilities in your service.

This is a device that you can use pretty much anywhere and everywhere. You have it with you all the time. Coverage of networks is way better than it’s been. And so, through the fact that you have it with you everywhere and anywhere and you can pull it out and access a network and access assets, all these new use cases emerge that you didn’t have before…”

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

• What is the alternative to sitting and planning your mobile strategy?
• Where should teams start to familiarize themselves with mobile?
• Is there an advantage to playing with as many apps as you can to learn about the interaction design?
• What are some things that make good mobile design stand out?
• What is the benefit of desktop operating systems emulating features on touch-based devices?
• How is multi-platform emergence affecting approaches to design?

Do you design for mobile? Share your thoughts with us in our comments section.

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

Full Transcript.

Jared Spool: Welcome, everyone, to an episode of the “SpoolCast”. Today I have the amazingly awesome Luke Wroblewski, who is going to be speaking at UI16, our User Interface Conference.

It’s coming up this November. He’s going to be giving a full-day workshop on designing for mobile, a really hot topic. And he is the guy I know that knows the most about mobile, and I’m very happy he’s here today.

Hello, Luke.

Luke Wroblewski: Hello, Jared. Thank you for having me.

Jared: Thanks for being here. So let’s just get into this. I’ve got all these clients now, who are pushing hard on their mobile, and they’re really trying to get there, but it’s really hard to figure out what to do right.

There are some crazy things that people have been trying to do. What are some crazy things that you have seen organizations do with their mobile implementations, particularly organizations that should have known better?

Luke: If they’re doing small, crazy things, at least doing something, I think that’s OK. The biggest issue I’ve seen is people running around and making PowerPoint deck after PowerPoint deck, trying to figure out their mobile strategy.

Jared: I saw that! I saw a guy on the plane. I’m sitting in the aisle, and then there’s someone in the middle, and this guy’s in the window, and he is editing up a PowerPoint deck of a mobile app.

And then, every 20 minutes, taking his laptop and passing it to the woman in the window behind him. [laughs] And then they would have some conversation, and then he would come back and he’d make more changes to it.

Luke: Wow. So there you go. And real-time, on the plane, even.

Jared: On the plane. [laughs]

Luke: It’s gotten to the point that I make this joke when I go and talk, especially at corporations. I say, “The worst thing you could be doing is just sitting around making PowerPoint.”

And pretty much inevitably, I always get this nervous laughter and someone coming up to me after the meeting: “You just nailed what’s going on over here! How did you know?”

[laughter]

Luke: I know because it’s pretty much what everybody’s doing.

Jared: Wow. And so what’s so nutty about that? On the surface, it sounds like a great prototyping tool.

Luke: [laughs] Well for building an app within it, sure. But when you spend all your time trying to imagine the future of mobile and planning accordingly and not taking a move until you’ve got everything nailed, then you’re just missing opportunity after opportunity right now.

And frankly, if you look at the space, I think it’s changing so dramatically day after day that any strategy, long-term, you put together is likely to get pretty disrupted.

Just looking at the past few weeks, right, we had HP getting out of WebOS, killing their tablets. We had Google buying Motorola. We had Steve Jobs resigning.

It was just bombshell after bombshell after bombshell in terms of what’s going on in mobile.

And so I think, when you get in this mode of all you’re doing is planning and things keep changing on you, you just keep planning, planning, planning; you never actually do anything.

So what you’re describing, where the guy’s actually designing an app, in whatever prototyping tool he needs, I think that’s great.

My concern is more along the lines of, “Hey, we’re planning out this large architecture. Hey, we need this long-term road map.” While I’m not completely ragging on planning, I think it’s very, very possible for organizations, especially bigger organizations, to just get stuck in that phase and never get out of it.

Jared: Yeah. So the alternative is what, then?

Luke: The alternative is just to put something out there and see what happens. If you actually look at the big companies that are currently doing well in mobile, that’s what they did.

So I keep hearing stories of a small, rogue, or interested team just went out and made an app or a mobile website, and all of a sudden it started taking off, and now that has gained a lot of momentum in the company and they’re taking off from it.

So one of the, perhaps, biggest examples is eBay. eBay was one of the first ones to pull together an iPhone app. And that was essentially a product manager, designer, and they worked with outside contractors just because they were really interested in it and wanted to make something there.

And you look now; eBay has 50 percent of mobile commerce in the US, and 70 percent of that is coming from their iPhone app.

At least as far as I hear the stories, I wasn’t there, obviously, this wasn’t some huge effort in terms of strategy and planning. It was rolling up your sleeves, making something and getting it out there.

I heard a similar story, for example, from Expedia. For a long time, I used Expedia, the travel site’s mobile app as an example of “Look at how focused their mobile experience is compared to their desktop Web experience.”

And I heard from someone after one of these talks that that app was created in their R and D Department by, again, two or three guys who were just really interested in, passionate about the space, and now they’re taking a lot of what they learned from there and applying it to the desktop and other places.

So this “just roll up your sleeves and do something,” I think the type of market it is and the type of environment it is lends itself a lot more to that kind of effort.

Jared: The folks over at Disney, there was an article recently published that had this visualization of all the Disney mobile apps, and there’s like 35 or 40 different Disney mobile apps.

Is there a point where just getting out there and doing it and having all these different parts of your organization just trying something gets in the way, and that maybe you should be sitting back and saying, “Well, do we have a strategy here?”

Luke: Yeah. Well, once you hit the point where you’ve actually done something. I guess I should clarify. I’m talking about people who are trying to, “figure mobile out.”

Jared: Right.

Luke: There’s organizations that have been in there from the beginning and have done a ton and they’ve learned a lot.

And once you’ve learned a lot and you understand, if they’ve got 35 apps, they probably know which ones are being used. They probably know where they’re getting new customers, where they’re making money, which platforms are working for them.

They have a crap-pile of information upon which they can start to build a strategy.

Jared: Right.

Luke: Whereas if you’ve never done anything, and all you’re doing is thinking about the re-architecture, which is going to take you two to three months, you’re not as well-positioned to actually develop a strategy because you don’t have any data, you don’t have any examples; you don’t know what people are actually doing with it, and so on.

And I do see, actually, a lot of companies are in the state that you’re talking about, in that they tried a bunch of things, released stuff, and now they’re looking at, “Well, how can we streamline this a bit? What are ways we can integrate this a bit more? What are the services that are actually sticking? What are the things that are not sticking?”

Jared: But the fact is, they did it, they got out there, they made it work for themselves.

And they didn’t really concern themselves too much whether they were leaving this sort of legacy trail of apps that they could be retiring at some point or disbanding.

Luke: I suspect a lot of those apps, to be frank, come from marketing organizations. And if you look at the trail of micro-sites emblazoned on the Web, right, you see a similar trend.

It’s the same kind of thing. People treated apps a lot like that, in that they would basically say, “Hey, the iPhone app is a new micro-site. Let’s just put them out there for a promotion or a service or a movie, whatever.”

But I’m also pretty confident that Disney has some core applications, representative of the brand and that are targeted at specific age groups and things like that.

Jared: Yeah, they do. They have some guides for moving around the theme parks and a restaurant finder and stuff like that.

Luke: I think they also have a core Disney app as well, because I believe my son watches videos on it. [laughs]

Jared: Oh, yeah. Yeah, I would think they do.

Luke: I think some of that detritus of all these different apps does come from this “treat the app as a micro-site” kind of approach.

But I see that decreasing now, because, as you said, people are looking at it and saying, “OK, well, these things are really low-value.” Once they drop off like an App Store list, they don’t really gain that much traction anymore.

This is why doing kind of gets you to learn. There is, for example, a whole suite of Disney individual, standalone books as apps.

Jared: Right. OK, yeah.

Luke: That’s all about selling a brand, right? So you’ve got the “Winnie the Pooh” book. You’ve got the Pixar “Cars” book. You’ve got interactive puzzle games associated with those brands.

Again, I don’t know exactly what’s going on in Disney, but my suspicion is they put out one of those, probably working with a third-party vendor. And if that format sticks, then they’ll throw other brands against that format.

So, put like a “Winnie the Pooh” jigsaw puzzle book. If that one works, then use that same stack to put another brand, like “Cars 2″ or “Toy Story,” on it.

Jared: Yeah, OK. So they are getting something out there. They’re seeing how well it works, they’re seeing what works well and what doesn’t, and then coming back and saying, “OK, let’s do another one and see what works there.”

It’s the standard iteration, “go as fast as you can” type process.

Luke: Yeah. And again, it’s that kind of environment. This is not a mature market right now. In a mature market, you don’t see the types of things that happened over the past three weeks.

You don’t see huge shifts in something like WebSearch, for example. The brands are pretty much established. We already had all that shakeout with Microsoft and AOL and Yahoo and who knows who.

Jared: Altavista and Ask and …

Luke: You’re familiar with this sort of trend of technology, right?

Jared: Yeah.

Luke: Where you have this period where there’s lots of very big moves, people are figuring out, and then over time things stabilize a bit more and there’s a little less change.

We’re not in that phase yet. [laughs] Things have definitely not stabilized yet. So iteration and constantly putting things out there and seeing what’s working is, I believe, the mode to be in.

Jared: When you’re doing that, when you’re coming to mobile first, you don’t want to treat it as if you’ve never seen it before. So if you’re in a team, let’s say you’re working at a hospital that has decided that they need to get something mobile out there.

So if you’re talking to the IT team at the hospital, what do you recommend they do for first steps, in terms of getting themselves familiar? Do they just go out and study what’s happening on the Web, or do they just start building something, or is there some cross between it? Where do they start?

Luke: I guess there’s a couple of ways to answer that. From a development perspective, I think it matters what they’re most comfortable with, development-wise.

The majority of companies that I interact with and see all have websites and Web presences. So starting to build something on the mobile Web is a very, very fast way for many organizations to prototype and put stuff out there, because they already know how to do HTML, CSS, JavaScript.

They can run it on a bunch of different devices, and they can simulate the form factor, simulate the interactions, and get a lot of things going. You can’t do everything, obviously, on the mobile Web that you can do in an app. So usually that’s a good place to start, technology-wise.

Then, in terms of overall adoption and use, if you don’t have a specific audience and a specific platform, which few people do but some do, you basically go by overall usage numbers.

And so, highest engagement still remains the iOS platform, and then you fall back to Android, and things drop off after there.

And with the transition with BlackBerry, maybe there’s something viable there, maybe Windows will stumble into something. But those don’t really look like very big plays right now.

So you can sort of prioritize what you do technology-wise, and then actually determining what to do with the product and the service you’re offering is exactly the process you’re talking about.

I don’t think it’s necessarily anything new. Know your audience. Observe real behaviors. All the design stuff that we’ve been talking about since I don’t know when applies here as well.

Jared: Do you think that there’s a real advantage to playing with as many different mobile applications as you can get your hands on and learning the lingua franca of the interaction designs?

Luke: What’s different about mobile, I guess, is an interesting question to talk about. And I think there’s three things that really make mobile very different.

The devices, and when we’re talking mobile here, I’m not blurring the line between these laptop, tablet, all kinds of things. I’m literally talking about things that are in your pocket pretty much all day. Very, very mobile.

So, today, those devices have a lot of constraints based on the ergonomics. They’ve got a small screen. In many situations, you’re using them in environments where there’s other stuff going on. You’re not hunkered down at a desk for an extended period of time.

You may be at home on the couch watching TV, or you may be in a line somewhere, or passing some time in, hopefully, not the car.

So there’s these constraints. Low bandwidth is another constraint. And when you use the devices, you familiarize yourself with what those constraints are.

But there’s also a lot of opportunities in terms of capabilities.

And if you use lots of apps, as you describe, then you can see, how are they using the accelerometer? What have they done with front and rear-facing cameras? How are they using location in order to deliver information? How are they using the video port, the camera, the audio input?

All those things can open up new ideas about how to take advantage of those capabilities in your service. So it’s these constraints. It’s these capabilities.

And then the third thing, which is sort of simple but I think it’s also the most powerful of this, is this is a device that you can use pretty much anywhere and everywhere. You have it with you all the time. Coverage of networks is way better than it’s been. It’s not perfect by any means.

And so, through the fact that you have it with you everywhere and anywhere and you can pull it out and access a network and access assets, all these new use cases emerge that you didn’t have before.

And that involves things like when inspiration strikes you can do something. You can do something in all sorts of different situations and contexts and environments and places, and increasingly between devices. This is a very interesting area.

I was talking to someone on the traditional-appliance manufacturing side of the coin. And we were talking about, “Well, why doesn’t the appliance interact with my smartphone?”

If you have either an RFID tag or a QR code, so if it’s got a maintenance issue, I can just point my smartphone camera at the QR code it generates on its screen and it tells me exactly the service that it needs.

Or better yet, fills out the whole form for me and I just hit a button and the technician comes and fixes it. But I can’t do that necessarily, without being able to have these devices with me anywhere and everywhere I am, and that’s a huge determining factor of new uses for them.

Jared: That’s really interesting, because what this really talks to is we can get very creative very quickly once we have a chance to just start to play with this.

It reminds me of the time when I heard the stories of Jeff Hawkins, who founded Palm, which, in essence, was one of the first mobile devices.

He just took a block of wood, and he carried it around in his pocket. And he would literally take the block of wood out and pretend to take notes on it or look something up and just figure out, did it make sense at that moment.

So it sounds to me like, if you got something simple up and running that you could carry in your pocket and then you could actually use it the way your users would use it and go through those scenarios, you would quickly learn where it works and where it doesn’t.

Luke: Yeah. And this takes us right back to where we started. That’s the kind of rapid iteration, “just do things” I’m talking about. That’s going to get you much closer to the mark of what your product should be doing and how than iterating in PowerPoint for hours, or days or weeks or months.

Again, I’m not dismissing the planning phase, but because these devices root you in real-world use, just to go back to the eBay example, some of the testing they did on that eBay iPhone app was they actually went to a Fry’s or a Circuit City or Best Buy with the device, went back to the back of the store and tried to use it for things like price comparison.

They were looking at these things. And they realized really, really fast that, hey, even though there’s great networks outside and within buildings, once you’re in these kinds of environments, they’ve really got to double down on performance because it wasn’t good enough to hit these core use cases where people were going to use them.

Jared: That’s really interesting. So the issue was that because the signal was so diminished inside the building, you had to minimize the amount of data that was being transferred radically to make it still a useful, functional item in that low-signal space.

Luke: There’s actually a lot of great stories from this eBay iPhone app. Karlyn Neel, who I worked with at eBay, gave a talk.

And actually, I wrote all this up, so everything I’m referencing here you can actually go and look up in this “One-Billion-Dollar iPhone App.” [laughs]

Jared: We’ll put a link to that in the show notes.

Luke: Great. That’s the really interesting thing. I mean, this one iPhone app did about two billion in sales last year.

Jared: Wow! OK.

Luke: So all that testing and that rapid iteration and just getting it out there, I think, really worked well for them.

Jared: That’s a lot better than all the fart apps that are out there.

Luke: [laughs] Yeah, I think so.

Jared: Two billion in sales. That’s crazy!

Luke: That is crazy. Single iPhone app.

Jared: Yeah. Yeah, wow. OK, so that makes sense. So now, what are some other things that you’ve been collecting that make good mobile design stand out that designers really want to look into?

Luke: Actually, this is a nice segue to what we’re talking about with the conference, because I’ve been really taking a hard look at what are the things that make mobile different.

How do these constraints, capabilities, and the ability to interact with these devices anywhere and everywhere, what do those do to what we know traditionally about input, about navigation, about organization, about even things like menu design, layout?

All this stuff, I think, gets impacted, and we need to take a step back and say, “OK, let’s rethink how we think about gathering input because of these constraints, capabilities, and modes of use.”

Let’s step back and think about, “Well, how do we think about navigation menus and IA in our organization because of these constraints, capabilities, and modes of use?”

I personally am very, very self-nervous that I want to apply too much of what I know already on the desktop Web to this new environment.

So I constantly keep slapping myself and pulling myself back and saying, “Hey, just because it works over here, is this really what you’re going to do on mobile?”

The thing that keeps resonating in the back of my head it feels like we’re in a similar transition to when we went from print to Web, and the first reaction of everybody was to take what works in print and put it on the Web.

Jared: Yeah. Yeah.

Luke: It’s a very, very similar situation now. Take what works on the desktop Web and put it on mobile; put it inside mobile apps and things like that. And again, there’s different capabilities and new things that you can do, so that doesn’t always make sense.

Jared: So what’s an example that you’ve seen recently of someone who just sort of blindly moved over and they probably shouldn’t have?

Luke: I don’t know if I can name a specific name, but I can tell you how to identify something like that.

Jared: OK, yeah.

Luke: If you go and hit a mobile-optimized experience, and at the top of the screen there’s about five navigation-bar headers, with menu options that take up, I don’t know, 50 percent of this tiny little screen and you can’t actually see any content, that’s generally an example of someone just porting over what they had on the desktop onto mobile.

Jared: Yeah, OK. The funny thing is that those five layers of navigation at the top of the screen probably didn’t work on the desktop either.

Luke: Yeah. [laughs] Exactly. And then you get breadcrumbs and all this other stuff, just really porting over everything that they had from the desktop over to mobile.

Another telltale sign is I have this one example that I reference a lot around a university’s mobile Web experience.

What they had on there was a letter from the president, a photo gallery of life on campus, alumni in the news. All the sort of irrelevant promotional stuff that litters desktop Web experiences and nothing that actually considered modes of use on the phone.

The most stereotypical, generic example you can think of is a campus map. You think if you’re going to take the time to build out a new UI or experience for your university for mobile devices, you’d give people a way to get around the university.

Jared: Yeah, you would think.

Luke: You’d think, but they didn’t have that.

Jared: Wow.

Luke: And things like that. Things which are task-based and allow you to get stuff done as you’re out and about in the real world. All that stuff is absent in situations where they just take what they have on the desktop and port it over.

You don’t see anything taking advantage of these capabilities and modes of behavior. It’s just the same content, smaller layout.

Jared: So, keeping this idea of just sort of saying, “OK, what is the key piece here? Let’s not focus on the chrome.”

This is one of the things, right? Because what happens to folks who work, particularly in larger organizations, is that because every group is responsible for their own content, they say, “Well, we’re not responsible for that.

“We’re just responsible for the stuff the content gets poured into. So we’re just going to focus on this shell, this chrome that we put around things, and that’s what we design. And we don’t really know.”

And so you get a lot of sort of lorem ipsum style designs where the thing that the user actually comes for, the thing that the user actually cares about, is actually not part of the design process.

And that gets them into trouble. That’s still true in mobile, and it probably gets really magnified in mobile, I would think.

Luke: Absolutely. I think you nailed it.

I have this rant about wireframes because when I look at the vast majority of wireframes, images which are content are represented as a box with an X through it.

Text and the actual copy or information, or even detailed data, is usually a line. It’s not even text. Or it’s filled with lorem ipsum.

So it’s all fake and the things that actually are, “real” are navigation menus.

And so what you get is you end up with these designs that have a whole bunch of navigation menus all over the place, because that’s what people are iterating on during the design phase.

To your point, they’re playing with the shell instead of playing with the actual content.

And I think mobile, and in particular, actually, at a broader level, touch-based interactions and these natural user-interface principles really magnify this issue because on those types of devices, you can directly interact with the content.

People start to expect that. Once all the stuff starts taking away from the content and you start putting buttons and navigation menus and everything all over the place, it starts to feel more and more foreign.

And especially when you have smaller screens, you get more and more frustrated that you can’t actually get to the content.

Jared: Yeah. I see myself doing this. So I’ve got this Canon camera, and it has the capability for me to see, on the little digital screen that comes on the back of the camera, nine pictures at once. So I can press a button and now I can see the last nine pictures I worked with.

And the way you’re supposed to interact with it is you use the little arrow keys on the back of the camera. If I want to get to the upper left-hand corner, I have to scroll back and then scroll up and then push the OK button and I get it. So it’s like eight keystrokes to get to a picture.

But I find myself unconsciously just trying to push the picture on the screen, move my finger over and push the picture, and I want to interact with that data directly. And of course, my camera predates the touch-screen movement of the iPhone.

But I think people are growing to have this expectation that they can just interact with this data that way, when it’s in that form factor.

Luke: Yeah. A more interesting piece of that, at least to me, is you and I have grown up and used all kinds of different input formats and devices.

Look at people who just started on touch. So my two and a half year old, he goes up to any screen and he expects it to be a touch-based screen.

Jared: I’ve heard that. That if you grow up in a household with a touch screen you think any glass surface is a touch screen.

Luke: Right. So those are your expectations. I love doing this quote, but anytime he sees sort of like a GUI menu, he comes and grabs me. He’s like, “What the hell is this? Fix this thing.” Because it feels really foreign in that environment.

Jared: That’s really interesting. Yeah, I think you really do have to be immersed in that language of the natural user interface as it’s sort of becoming called, this new thing. What’s your take on Apple reversing the scrollbars on Lion to match what’s happening on the touch devices?

Luke: I saw a great phrase recently which is, “Apple is going to take us kicking and screaming into this next generation of UI whether we like it or not.” Because they actually make pretty bold moves in these areas, and that’s a great example.

Jared: Well but Windows 8 looks is looking like it’s getting that way too. Right?

Luke: Yeah. I saw some really confusing stuff about Windows 8 recently.

Jared: Yeah. They backed away from that. So the original Windows 8 thing that they showed, what, about six months ago, was really this very touch-centric interface.

And then just like last week or something they said, “Well, actually you’ll be able to switch between that and the old way of doing things.” And it’s like, “Ooh.”

Luke: Which I don’t get. So I would like to see that. Because of you look at those two screenshots, it’s like Microsoft Office 2012, the one with the ribbon-type interactions for Explorer and then what looks like Windows Phone seven for the touch-based viewing and toggling between those two seems quite, I don’t know. I would love to see how that works.

Jared: It reminds me of the old saying, “Standards are great, there are so many to choose from.”

And it sounds like Microsoft is taking this middle road where they say, “Well, OK, you get to choose what which standards you have.” But that’s just going to create all sorts of wacky interaction and confusion.

Luke: To go back to the point around how Apple is taking the stuff from the iPhone and adopting it to Lion, I think people are starting to expect the way things work on their mobile devices to work that way on a desktop.

Chris Messina recently posted a thing where he said, “I think I just double tapped my space bar the laptop expecting it to insert a period and a space.”

Jared: I have done that.

Luke: Yeah, because you do that on the phone all the time. You go space, space and it inserts a period and spaces over. And now you go to the laptop and you do it and you’re like, “Wait. Why didn’t this do that?”

Jared: Right.

Luke: So it’s amazing the way we start to reprogram ourselves through continued use of these other devices. If you just plot out the trend line, more people are going to be interacting with their mobile phones more often than they do their laptops outside of very core professionals.

So yeah, the behaviors you get on the mobile device are probably going to become the dominant ones. And those are the ones that are going to influence what you expect in other places, hence the transition of scrollbars online.

Jared: I think so. So from an application developer perspective this really means that we can’t just limit ourselves to a single platform anymore.

We have to become versant in all the platforms that are out there and have a census to how people are switching between them.

And understand that there’s a good chance that our app is being used in more than one platform by the same person often simultaneously in some ways.

Luke: Yep. And so there’s two things that I like to talk about with that idea. One is, it’s becoming very, very clear that a cross-channel user, AKA someone that uses your desktop app, your mobile website, and your, I don’t know, your Chumby app or something like that.

[laughter]

Luke: Not only are they a better user because they use you in three different channels so they add up to more time, but in each of those channels they are higher use than somebody who’s only using a single channel.

So the stat I always pull up because it’s the biggest one, Facebook has 250 million mobile users. The people who that use Facebook on mobile are twice as active on Facebook on the desktop as those who do not use Facebook on the mobile.

Jared: That’s really interesting. Yeah, Netflix was reporting something very similar. And they worked really hard so that if you’re watching it on your TV and you pause it, and then you go and you bring up the same movie on your iPad, it picks up right where it left off on the TV.

Luke: Netflix is actually pretty fascinating. I remember at the Web App Summit you guys put on, Bill Scott made a couple comments around how there’s all this debate in Netflix about whether they should have the same experience across all their devices in terms of UI.

Or if they should be optimized for the capabilities and constraints. And they have this notion of user posture across all devices.

And what he quoted was that in all the testing they’ve done it always comes out that the device optimized UI performs better than something that’s generic across everything.

Jared: Right.

Luke: And I think that applies to how you represent the interface. But at the same time, there’s seamlessness between your data and your interactions and your state across all those different interfaces.

So it’s sort of like the same but different, is really the right answer. Because you want the interactions, the core value, your data, all that stuff to be the same. But the way you interact with it should be influenced by what the device can or can’t do.

Jared: That makes perfect sense. That makes perfect sense. So, people coming to your full-day workshop.

You’re going to walk through a lot of what you’ve been learning. Particularly with your recent explorations doing the whole Bagcheck experience, which was a gorgeous experience.

Which, it’s interesting how you were co-developing this desktop-based experience alongside doing a mobile experience. And you started with using mobile Web for it.

I remember early on you told me that eventually you would expect it to be a mobile app. But you were using the mobile Web so that you could get to the functionality and understand what the users needed faster and you could react to it faster instead of having to go through the App Store cycle, right?

Luke: Right. Exactly. It’s actually even more complex than that I guess. We started out by building a command line version first. AKA, we built the API.

So what we would do is really think about, “What are the different objects? How are people going to interact with those objects?” And we would build a core functionality which we could interact with through command line.

So the first things we actually did when we were testing … this is kind of silly. But the first interactivity and “usability” testing we did was in the command line. [laughs]

And from there we took that command line and we gave it a bit of a front-end in a mobile Web experience. And then subsequently we built a desktop experience after that.

But the mobile Web experience, one of the reasons why we did that first was because we had again, these tight constraints, but also because we could interact with it anywhere and everywhere.

So we would literally be out in the evenings. I used it when I went on vacation. Just trying to figure out what are the modes of behavior, very similar to the eBay example we talked about earlier.

What are the modes of behavior that makes sense with this service? And once we thought we had that tuned then we went over to the desktop and said, “OK, well, let’s take what we learned and develop a larger screen more in-depth kind of immersive experience for it.”

Jared: So by going that sort of command line which got you to the essential functionality and it said, “These are the transactions what we will have with the server.”

And then, in essence, it sound like you put a nice pretty skin on it and built it out from there for your mobile experience.

And then you went to the desktop and said, “OK, what does the desktop need to have that borrows from that mobile experience and what does it have to have that’s unique to the desktop?” Is that sort of the evolution?

Luke: Yeah, definitely. And with the desktop too. I mean, you just have different kinds of capabilities.

So you’ve got a lot of screen space. So we were able to do things which are more like asynchronous editing, which is very hard to do on mobile because you just have this small screen.

You can’t have multiple pieces of say, like a creation tool open simultaneously and allow you to switch between them. You tend to be locked into a mode or a state because that’s all the room you have.

So when we took it to the desktop all of sudden we were able to do things that were a lot more asynchronous, that were more multi-modal if you will.

And we were also able to do a bit more automation on stuff because we had nicer connections in the bandwidth pipes overall.

So for example, one of the things we did on desktop, which we didn’t do on mobile, was on a desktop we would go and build out a listing of all your stuff using metadata you have on other services.

We said, “OK. Well tell us who you are on Flickr,” and we’d go and find all the camera gear you use on Flickr and essentially build out this list for you in this full-screen interactive mode.

Whereas on the mobile, we built something that we didn’t have on desktop, which was you can go and scan the barcode of an item to input it, which is pretty awkward and clunky in most people’s laptop and desktop experiences.

So those two things were separate to the platform. Long term, maybe we could have morphed the two. Certain things just made more sense.

Like the barcode. You could pick up the phone; point it at an object really easily. So that makes a lot of sense on mobile. So that app had that functionality.

Jared: Well, I mean, it all sounds great. And I’m really looking forward to your workshop at the conference. And I’m very excited because you’re really going to get into the core details as to how people make this happen.

You’re going to talk specific about gestures and how Hover works, and doing input, and displaying data, and all that stuff.

So it’s going to give people a really solid background and starting place for the language of what works and what doesn’t.

Luke: Yeah. I wouldn’t come unless you want to get really into the details of how to do these things.

Jared: OK. So we’ll tell people to stay away unless they really need to do that.

It’s key that they don’t come unless they really want to know that stuff.

So that’s excellent. And people love your workshops, so that’s great.

Luke, I want to thank you for taking the time to talk to us today. This has been really fascinating and hearing these stories of how you guys did this and what’s going on in the mobile space has been really a lot of fun. Thank you.

Luke: Thank you. My pleasure.

Jared: So everybody, you can hear Luke at the User Interface 16 Conference, which is going to be November 7th through 9th in Boston, Massachusetts. He’s going to be doing a full-day workshop on designing for mobile.

And you now know why we chose him to be the guy to do this because he’s done this stuff. He knows what he’s talking about. So you definitely want to see that.

You can find out all about that at Uiconf.com. We’ll love to see you there.

Again, Luke, thank you very much for spending this time with us.

And I want to thank the audience for listening. And as always, thank you for encouraging our behavior here at User Interface Engineering. We’ll talk to you next time.

Our goal, of course, is to learn everything we can. We need to leverage the research time to ensure we’re filling our brains with the information. Then we’ll need to create great designs.

In today’s UIEtips, I look back at an article from last year. I talk about three questions I’ve learned not to ask in sessions. By avoiding these questions, we get to the information we need faster.

Read the article, 3 Questions You Shouldn’t Ask During User Research.

Dive deeper into user research with Steve Portigal’s workshop Immersive Field Research Techniques at the User Interface 16 Conference, November 7-9, 2011. Steve will show you simple and effective field techniques for a deeper look at your users.

And once you’ve learned what you need from your research, you’ll want to put it in a format that helps you speed through your design process. That’s exactly what scenarios help you do and, coincidentally, why we’ve asked Kim Goodwin to return to this year’s User Interface 16 Conference to repeat her popular workshop on Designing with Scenarios. She’ll teach us how to make scenarios work.

You can find out about Kim, Steve, and the other great UI16 experts at UICONF.com.

Have you compiled your own questions that you shouldn’t ask? Share your list below.

It’s easy for applications to get overcomplicated and bogged down with data – especially in an enterprise setting. It’s hard to keep track of so many different things. When dashboards and widgets are employed, the goal is to make your life easier, but often that’s not the result. The solution—simplify these applications for specific use cases and give the right people the right information they need for their given task.

Hagan Rivers, of Two Rivers Consulting, spends her time meeting with teams to show them exactly how to streamline these complex applications. Whether it’s an app for managing purchase orders or hospital patients, there is a lot to consider. Hagan expresses the value of taking a step back and sifting through the complexity. This allows you to untangle the necessary bits to arrive at a better focus.

We have 8 full-day workshops at the User Interface 16 Conference in Boston, November 7-9. Hagan is bringing her expertise to one of those workshops, showcasing the methods she uses to create consistent, beautiful applications. For more details about the conference visit UIconf.com.

Here’s an excerpt from the podcast.

“…there are certain expectations we have about where buttons should be. The “OK” button is the one that’s bigger and brighter and more clickable, and the “Cancel” button is less so and they’re in a certain position. And toolbars go above tables. And the first thing is usually new or something like that. Like, if you didn’t have the language cues, how much of just the layout and the organization and the arrangement of things would lend the pattern to you.

And sometimes I show people screenshots of Japanese GUIs. And I ask them to really look at it, because they get so used to just reading the labels, especially the developers. They’re very good about actually reading everything on the screen. Users are not.

But the developers read the text on the screen. They say, “Well, it’s obvious, it says in the help text right there.” Yeah, but, OK, don’t read the text, just look at it and see what you can learn…”

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

• How do you identify and prevent unnecessary complexity?
• What is the value of “hand-holding” when a customer is experiencing a product for the first time?
• If a design isn’t in a standard pattern, can consistency alleviate any potential confusion?
• Are there exercises that teams can do to develop patterns?
• What is the best way to implement dashboards?
• Are there patterns on mobile that are making their way back to the desktop and other places?

Do you have experience with complex applications? Share your thoughts with us in our comments section.

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

Full Transcript.

Jared Spool: Welcome, everyone to another episode of the SpoolCast. I am very happy, because today I have one of my favoritest people in the entire wide world of the UX space, Ms. Hagan Rivers, who is going to be speaking at the User Interface 16 Conference, which is going to be in Boston November 7th through 9th, and she’s doing a full day workshop on the 9th called “Simplifying Complex Applications.” And I’m very excited that we get a chance to talk to her today about just this topic. Welcome, Hagan.

Hagan Rivers: Thank you, Jared. It’s good to be here.

Jared: So, I have a question for you which are why we’re doing this, because I have a bunch of questions for you. Lately I’ve been working with these teams that have these designs that have been going on six, seven, eight years, right? So they’ve been around for a while, and they’ve got dozens of designers and developers who are working on this.

And just a few weeks ago, we’re watching actually a training video, so it’s a video of a customer being trained. And it’s a beautiful way to watch people use a design, because you see what the trainer is doing. They’re walking the user through the various aspects of the design, and you get to see the screens. You get to see how the new user is responding to all these things.

And one of the things I’m noticing is that as every part of the interface pops up as the trainer is walking through it. Each one has sort of a different signature look. They’re all maintenance screens, right? So, you know, one’s a customer screen – these are places where you have classes, so one’s a class setup screen, one’s an instructor screen, and each one has a capability to make changes and save, but the way you make changes and save in one screen is a “save” button, let’s say, and it’s at the top of the screen.

On the next screen, it was an “update” link that was at the bottom of the screen, and each one was different, and as we went through these, I began to realize that I could actually start to pick out which developer had probably developed which set of screens. I didn’t know the developer by name, but I knew that screens one, seven and nine were all probably developed by the same guy, because they had the same basic look to them, but screens two, five and six were done by somebody else.

And, of course, all this made the trainer’s job that much more crazy, because every time they had to sort of explain a different way of doing it. And so I’m realizing that entropy takes over and these designs become this giant hairball of complexity, and I was wondering, do you have any suggestions? What could you tell teams to do that would sort of prevent this hairball from growing as nattily as it does?

Hagan: To make it never happen in the first place?

Jared: Well, maybe, but at least to start to identify that it’s happening and maybe prevent it. I don’t know.

Hagan: Yeah. I mean, I see these apps all the time. When I meet with new clients, they demo their apps, and I see the same thing. I can tell which screens which parts of the development team did. I can tell you how many different developers there are working on the GUIs, you know?

Jared: Exactly, exactly, yeah.

Hagan: And each one has their little pet peeve about they don’t like to call it the “OK” button. They think “save” is clearer, so they always say “save,” or whatever. They all have their thing going.

And as new features get added, especially as you talked about in the preferences and stuff like that, that’s where the developers tend to do a lot of design work. They just sort of throw whatever they think works onto those screens.

So, actually, it’s interesting you talk about the training, because I did some work with a client last year, and I went and took their training. I acted as a customer and I just said, “I want to attend your training classes.” And I got so much great material there, because as we went through screens, there were all these places where the trainer had to stop and tell us what was weird about that screen, and I would take notes. I’d go, “OK. We need to fix that.”

And we’d go to the next, and they’d say, “Well, on this screen, you have to be sure to click this button first.” And I’d go, “OK. Well, we got to fix that,” you know?

Jared: Yeah, so one of the things we’ve been doing with clients is when we take these video tapes and we actually start dividing up the tape into pieces, and any place where the trainer is in essence helping the customer get value – so, in other words, that particular thing, like the customer setting up their first account or their first class or putting in their first instructor, right? They’re getting value from that, and so we call that “goal time.”

But the places where the trainer is sort of explaining – like there was one option that took about – we counted it – it was about six minutes to explain that you should always keep this number set to one. Whatever you do, don’t change it, but then went on to explain why it was there and why it might not be one for people who weren’t you, but you should always have it as one.

Hagan: Yeah, don’t touch it.

Jared: Exactly. And so we call that “tool time,” right? So that’s the time that you have to just sort of deal with the tool. And you can actually measure how good your UI is doing by the ratio of tool time to goal time, right?

And if you keep reducing tool time and increasing goal time during the training session, you’re getting real value, because there is value to hand-holding a customer through their first experience for some of these high end products. But that hand-holding is different than mine field avoidance lessons.

Hagan: That’s right. That’s right. Yeah, I mean, a lot of the apps I work on are really complicated. They’re not apps that you can typically just hunt through the web and find them. They’re the kinds of apps that are installed in enterprises, so apps for managing purchase orders or patients at a hospital or ticket systems for managing help desks – stuff like that. I mean, big, big apps, and they’re complicated, and they do often have training.

And you’re right – there’s this tool time is like just spent trying to dig through what is quirky about this app. And there are always a lot of internal inconsistencies, and I always tell folks, like, “Just pick one.” I mean, in a way, it doesn’t even matter which pattern you pick for your forms – just pick one and use that one again and again. Like, yes, they obviously can make improvements later, but the inconsistencies just throw everybody for a loop.

It hits you in training, but it hits them in QA. It hits them in documentation. It hits them all the time when they are being inconsistent.

Jared: Yeah. I think there is something to that, right, because you can have something that is illogical but consistent and it works, right? The old start button on Windows XP, right? It didn’t make sense that to shut down your machine, you press the start button except that once you learned it, it just work. It just always worked.

Hagan: That’s right. And so, if your app has, the OK button as a link on the upper right hand corner, you know that’s not how most folks do it. That’s not the standard pattern. But if you do it in every one of your screen, people will learn it and will just do it. It will be fine. But if you change it every single form, you are creating much more work. And the other thing is you are creating more engineering work. I mean if you have to recreate how you deform submission for every single form, that’s a ton of effort that’s wasted.

Jared: Well, one thing that gets me is on the American Airline site. I can go on for hours about the American Airlines. I mean but on the American Airlines site; they have this convention where the OK button is a red button. How do you like that?

Hagan: I love that.

Jared: In the lower right hand corner, it’s the farthest most right button, except occasionally, the start over button is that button.

Hagan: I’m sure the ramifications of clicking that are a lot of fun.

Jared: Yeah. If you are like me and you are trying to make a reservation quickly and you do it 20 times a year, it drives you nuts when you hit start over and you didn’t mean to. It’s like, “UGH!”

Hagan: Yeah. To answer your first question like the hair ball of complexity. I think if you do what I do. When I first meet with a client, I go around and I talk to the folks in their sales team. I talk to the folks in the support engineering. I talk to the folks that helped us. I talk to trainers and as I talked to them, they’ll tell you about these inconsistencies and they know them because they are working directly with the customer trying to deal with them.

They spend a lot of their time dealing with them every day. And you know, I see those and that’s why I know why the products got the hair ball of complexity in addition to looking at it myself. One of the first things we tackle is these patterns. They are trying to create very standardize ways to do things that you use throughout your application. The one way to do a form, one way to do a chooser, one general way to present a toolbar over a table, so that you don’t have to reinvent that all the time.

You don’t have to retrain people all the time. These complicated Apps, it’s hard enough just to understand how to work the App and do the real tasks. Much less have to wade through a complicated, difficult to use UI.

Jared: Yeah, I think they are creating a library of patterns. It’s really a good idea. People ask me this. There are now a handful of sort of general purpose patterns that people put together. Jennifer Tedwill put one together. There’s a guy in Germany who’s got a really extensive site. I don’t remember how to pronounce it. It’s German so everything I know about German I learned from Hogan’s Heroes. Which is probably not the best way to model an entire culture.

Hagan: I think that was all deliberately mispronounced.

[Editor's note: The "german guy" is actually dutch and his name is Martijn van Welie. The site is welie.com. Apologies for not getting that right in the recording.

Jared: You're probably right. There are all these third party pattern libraries that are emerging. But I still feel like there's a lot of value in sort of crafting your own library as a team, because you have a lot of really useful discussion about what is a pattern and what do we call that, and it creates a language, which I think is really important.

Hagan: Yeah. I find the same thing. If you just kind of hand an organization a pattern and say, "Here's your pattern library," they don't use it. They just shelve it. It's not their pattern. It is a pattern library, but it doesn't always apply to their apps and it doesn't make sense and they haven't even agreed to use it. So you know, we try to do a conversation with the development team, and I'll go through and I'll find the six different ways they do a chooser screen.

And we'll put them all up on a screen and we'll look at them together and we'll say, "Well, which of these do we think is the best and why?" And I'll tell them why I think which one's the best, and we'll pick one and then we'll get it recorded down in a pattern and we'll start migrating to using that for everybody.

Jared: Do you do an exercise when you do that, because I've done this with teams? Do you do an exercise where you actually say, "OK. Let's just make a list of what's different - let's not assign good or bad here. Let's just make a list of what's different between these different variations so that we can make a catalog of why each one of these things sort of existed?"

Hagan: That's right. You'll learn things, like some chooser that someone did is really good for that particular situation, because he's choosing between maybe hundreds of thousands of items, whereas another one might only for choosing amongst 50 items or a 100 items, and they do different things. And so you say, "Well, OK. When you identify these, it's not that they're good or bad. It's that they're solving different problems."

You start to build your pattern library, say, "Well, whenever we need a chooser for more than 5,000 items, we'll use the giant one, and whenever it's less than that, we'll use this one. And so if you do an exercise, you get them to think about what's making that work? Why did they choose to design it that way? And what's the purpose? What problem is it solving? How does it help the user? Then they understand why they would reuse the pattern. I think that's much stronger way to start building a pattern library than to just grab a book off the shelf.

Jared: I'm thinking this doesn't have to be a difficult thing, right? You could take, like, 15 minutes of a weekly staff meeting and just put up a chooser one week and a form next week, the way you do login authentication the week after that, and just do one a week for 15 weeks and all of a sudden you've got the start of a library.

Hagan: Yeah, it doesn't have to be super hard. I think what happens is a lot of folks get very married to the patterns that they've created and they really feel they've got the best solutions. So sometimes you do need to go out and talk with users and talk with the support folks and see what's really working for people. But most of the time when you ask people to sit down and really look at the design, and compare it to other designs solving similar problems - they're pretty quick to pick up on what needs to be done.

Jared: I have this friend who was a real film buff, and he went and studied all these film classes and would watch every DVD extra where they talked about how they made the thing. And he always wanted to go off and be a filmmaker himself. And I would go to the movies with him, and we'd be sitting in the movie theater, and this exciting thing would be happening on the screen and he'd hit me on the shoulder and he goes, "Did you see that tracking shot? That was like an awesome tracking shot!"

Or we'd be watching a video at home and he would make us go back and rewind something because the zoom was particularly good. And, it's like, "Dude, I just want to watch the guy get the girl." You know?

Hagan: What guy? What girl?

Jared: Yeah, exactly. He had stopped paying attention to any of that. He was looking at what the cameramen was doing the whole time. And so, "I figured out how they did that." And like, we'd have to watch the same scene 15 times.

Hagan: He was interested in the craft, not the product.

Jared: Exactly. Exactly. And I'm wondering if, in fact, that's what we're trying to do here with developers. They can't log into, you know, PayPal without noticing exactly how PayPal does their authentication screen, now, because they're going to pay attention to that level of detail, because we've dissected it.

Hagan: That's right. Yeah, I mean, I think, you need to be able to, kind of, step back. Like, I always think it would be fun to take a piece of software and replace all the English in it with gobbledygook. And see how much of it you could drive.

You know, there are certain expectations we have about, like, where buttons should be. You know, the "OK" button is the one that's bigger and brighter and more clickable, and the "Cancel" button is less so and they're in a certain position. And toolbars go above tables. And the first thing is usually, like, new or something like that. Like, if you didn't have the language cues, how much of just the layout and the organization and the arrangement of things would lend the pattern to you.

And sometimes I show people screenshots of Japanese GUIs and stuff. And I ask them to really look at it, because they get so used to just reading the labels, especially the developers. They're very good about actually reading everything on the screen. Users are not.

But the developers read the text on the screen. And so, they're just like, "Well, it's obvious, it says in the help text right there." Yeah, but, OK, don't read the text, just look at it and see what you can learn.

Jared: That's interesting. I actually found myself in a Dutch police station once in Amsterdam and watched the cop fill out a theft report, a friend of mine had had her purse stolen. And so, we're watching him fill out the theft report, and of course, the screen was entirely in Dutch. And yet I had no trouble following along with what he was doing, because it did follow those sorts of conventions that we're used to.

Hagan: That's right. And I have a theory that if a pattern is working well, the labels are irrelevant. They add supporting information, but you should be able to figure out how to use it without being able to read them.

Jared: Yeah, I think that makes an awful lot of sense. It is really interesting that this idea of being able to use the design independent of the language that's there. And can you drive it that way, basically, through just convention. Makes a lot of sense.

But at the same time, a trap that I see teams falling into, I don't know if you've seen this, is when they try and come up with generic designs and they use "Lorem ipsum" style text. And then, when they plug the real design in.

Hagan: It's just too generic.

Jared: It's too generic. And it doesn't handle the special cases, which is why you need the patterns for the 50,000 item selection, or is this the 3,000 item selection?

Hagan: Right. We'd worked on an app last spring. It had a bunch of wizard based forms for editing. There were a whole bunch of different objects in the system. So, they had, like, 20 different tabbed wizards for editing these 20 different objects.

And so, they all looked the same. I mean, once you opened one up, it was really hard to distinguish them. You know, I told the engineers, we need to put labels at the top, we need to repeat these labels. Like, instead of just saying, "Name," we would say, "User's name." So, it was very clear what name we meant. Or "System's name" or whatever name we were asking for. And they said, "Well, they should know by the context they're in."

And I said, "Well, the language is what gives them the context." We saw regularly, people would open up a screen in our usability study and they would forget what screen they were on. The language is the thing that gives you those cues, oh, I'm working on this. Oh, it needs to know this. And being repetitive, like, there's this real tendency to be really lean in language on some of these apps. And sometimes it's confusing.

Jared: Every pixel costs, right? So, you want to save on those characters.

Hagan: You've got to save, I know, because it might, burns out your monitor. I don't know. But yeah, it's like, there's this appreciation for brevity that doesn't really help users at all. I mean, obviously, you can swing the other way and have full sentences all the time, and that's too much. But there's this desire to be really, really concise in the language, and I think it's disorienting, sometimes.

So, yeah, I don't mean to say, if you use the pattern without seeing words that it would be perfect. But the sort of placement and arrangement of things can be very suggestive. And then, the language kind of adds to the whole context and the behavior layer on top of that. To, sort of, tell you what is this thing? How does it work? What's its relationship to other things in the system? What can you do with it? And that's what the language layer kind of gives you. Of course, the language is really critical.

Jared: Yeah, I think that the more we understand about interfaces, the more we realize that we're basically creating a language that is both visual and verbal with our users. And that the combination of the two is really important.

We saw this early on with icons, where there was this big push to have visual symbols for everything and no words. And we were working on this tool for software developers. The team had come up with this hatchet dripping blood. Which was the "Execute" program icon?

Hagan: Yeah. That'll translate well.

Jared: Yeah, exactly, yeah. A visual pun that just does not work. The funny thing was that we'd have these usability tests and all the male developers that we had come through went, "Oh, that's really cool." And all the female developers go, "Ew. Why?"

Hagan: Ew. [laughs]

Jared: So, that one really split down gender lines. But what we found early on was that when you just had pictures, often people didn’t know what the picture meant. And when you had just words, it wasn’t as good. But the picture and the word together, actually seemed to really work best.

Hagan: Yeah, the pictures give you a differentiator, so when you’re using your kind of positional memory of the toolbar in your head, you remember it’s kind of the fourth or fifth one in, the picture kind of gives you a reference point for your eye to grab onto. At least that’s my theory.

Jared: Well, you know, what was really interesting was we experimented with that. We started moving the icons around, and we found that the position wasn’t as prominent as we thought. In the early Microsoft Office apps, for example, the first icon was open and the second one was save, and the third one was print, or something like that.

But we found that if we moved them around a bit… I mean, if you completely reversed it, if you put open and close on the far right instead of the far left, people would have trouble with it. But if two icons appeared before open and close, nobody was freaked by that. It didn’t have to be the very first icon.

Hagan: Yes, I don’t think positional memory’s that absolute. I think it’s just sort of like, “it comes first-ish neighborhood” memory. But it helps. It’s an important piece of finding stuff again and again, especially in an app you use all day long.

Jared: So what’s your take on dashboards? We have a lot of clients that are doing this sort of dashboard thing, and it sort of starts with some executive declaration of, “I just want one screen that tells me exactly what my business is doing.” And the next thing you know…

Hagan: Wouldn’t that be nice?

Jared: Yes. You’ve got odometers, and speedometers, and temperature gauges. Every physical skeuomorphic gauge that man has ever come up with is now a visual element on this opening screen that nobody understands.

Hagan: Yeah, they’re trying to really create the pilot’s dashboard, which works great for pilots, but not so much for most other folks.

Jared: Except that pilots are intensely trained on those dashboards.

Hagan: That’s correct. That’s why it works for them. They need to know where things are and what to click and what to look at, whereas we present someone with something just as complicated as a pilot’s dashboard and say, here, this helps you know what your whole business is doing! And they scream and run out of the room.

So, dashboards. I can usually tell if a client knows who their users are and what they do just by looking at the dashboard. To me, I think of the dashboard as like an extra layer of navigation, actually. Like, a whole screen devoted to navigating to key parts of the application and bubbling up information from key parts of the application.

Jared: That’s interesting.

Hagan: Yes, so if you know your users, your dashboard, it reflects it. I’ll give you an example, because this is this new idea that I’ve been working on for the last year or two.

So, we worked on an app a couple months ago for managing mailing lists, email lists, and stuff like that. And they had a dashboard, and when you logged in you got this screen, and it showed you your user profile. So it showed you your first name and your last name, and a place to change your password, and those things. And then it showed you a list of the mailing lists you were subscribed to.

This dashboard was the dashboard for the administrator of the mailing lists, mind you. Not an end-user, but the administrator, the person who actually sets them up. So, there was nothing on this dashboard that was of any use to this person. And they had little meters and metrics and stuff, but it was useless. They all clicked right through it and went off to doing stuff.

So we went and talked to some of these users, and we talked to them about what do you do the most often? If you talk with them, after a while they said, well, the biggest problem they have to deal with is updating other people’s email addresses. That’s their number one problem. Like, they send out a message and a bunch of them bounce back as having failed. And they need to know who those people are so they can get it up to date, and they have to look up and manage those users and deal with the failed deliveries.

And then the other thing they do a lot is they send out these mailings. So when we were done, the dashboard now had a quick way to get to a list of users who have disabled email addresses due to delivery failures. So you could just say, 150 people right now, their emails are no good, click here to go straight to them. A quick way to look at users who don’t have email or are out of sync however with the system. We even had a little box right there where you could type in an old email address and a new email address and just push a button, and it would just look it up and do the swap.

So that was, again, we were looking, what’s the common task? And then we had a place for starting new messages and sending them out. So we went out and said, what’s done really commonly, what’s really hard to do, what things do you have trouble finding? And those were all the things we bubbled up and put on the dashboard. And we had some reporting stuff too, but it was mostly like, how many mailing lists do you have, how many total users on each mailing list? Just some very simple metrics, and they were not giant dials, they were just some very straightforward numbers.

So the idea is that the dashboard is like storytelling. It tells you the story of what the app does, and the most frequent things you’re going to do with it. And it navigates you very quickly to those key places to support those tasks. Most dashboards don’t do that.

Jared: Yes, that to me makes a lot of sense. So, you could have it, for instance, if you had items that needed attending, you could have it put the number of items that need your attention in red for those things, much like the way unread messages show up on an iPhone, or something of that sort.

Hagan: Right. For instance, in a lot of apps, you’ll have a list of stuff and you can filter that list. So it’s possible to go in and set up whatever filters you need to find something out. But on the dashboard, you could put five links to the most important filters that the user’s going to need a lot, and it just immediately takes you to that page and applies those filters and gets you up and running. And you don’t have to do anything more complicated than that, it just gets them going and gets them started on their work.

Jared: Yeah, because I think a lot of these sort of visual elements, though, they might demo well just from an “Ooh, that’s very impressive,” the dials and gauges and stuff. I think the amount of information that they communicate for the number of pixels that they use, that sort of data-to-ink ratio is probably pretty low.

Hagan: Yeah, it’s very low. We’ve done a lot of work cleaning those up to try to increase the information density, and it’s really low. The other thing is I think, at least I’m finding with our clients’ customers, you know, a year or two ago, they would just be really wowed by seeing a dashboard covered in these controls. But now, when I go and sit in on sales meetings, I hear them saying, “Well, what is this for? What is it telling me?”

So, the customers are starting to become more critical of these flashy screens and really asking what they’re good for. And I think that’s going to be what drives improvement in the design, is that the customer is getting a little jaded about all those bells and whistles.

Jared: So, we have this definition of the word “clutter.” Every so often, you’ll be sitting in a usability test and a user will tell you, “That screen feels really cluttered to me.” And what we’ve realized is that clutter doesn’t mean high information density. Clutter means there’s a lot of stuff on the screen that I either don’t understand or I don’t care about. And there’s very little stuff that I care about.

And I’ve actually seen screens where we did a before and after of a design. And the before, the user told us, was much more cluttered than the after. But the after had more information on it than the before did. And what made it less cluttered was that all the information we had designed to be relevant to something that user needed.

And so, I think what I’m hearing you say is that these dashboards that don’t do well, that the users are now saying that maybe that’s that clutter effect, right? They’re looking at this dashboard that has a lot of stuff on it, but it’s not stuff that they are interested in in running their business or doing their job or whatever their operation is. And if you replaced it with stuff that was actually, really important.

So, one of the things is, we have this client who has this application. It’s a subscription thing, it’s a monthly subscription thing. So, every night it goes and runs a batch of credit cards for the people who are renewing on that day of the month.

And the first thing every one of these business owners of these customers did is that they would go to the report that told them how that job did, which credit cards got declined, how many got declined. Because that pretty much set their to-do list for the day of who they had to contact and say, “Hey, your card is expired,” or “Your bank’s not accepting this charge anymore and we need a new card or we’re going to have to shut off your service.” And that wasn’t on the dashboard. Right? Yet it was the most important thing that pretty much every customer we went to visit did.

Or just checking to make sure the job ran at all, because there are random nights where, for whatever reason, things don’t go well and nothing was charged, right? And the batch is left hanging, because of some technical error.

And so, having this thing that says, yeah, last night, we ran 23 credit cards and every single one of them cleared, would save, like, A, six clicks, and give something incredibly useful that that person wants to know when they first login in the morning.

Hagan: That’s right. And that’s what I mean about it being kind of a mechanism for bubbling up key information and giving the user a quick way to get into, maybe, deep places in the application to do tasks that they have.

So, I have this funny exercise I do with clients now where we do a demo of their product very early in the process. And they bring up their dashboard screen. And I say, “OK, let’s take a look at this. I’m going to go through this screen, and I’m going to tell you what I think, based on this screen, are the most important things in your app.”

And we go through the screen and it’s mostly garbage. I mean, it’s just sort of like random stuff we’re able to tell you, but has no bearing on things you do, or things you care about. And they quickly realize that they really haven’t given it much thought. They just sort of threw everything on there that they had, rather than spending any time thinking about how people use the app.

Jared: Your content management system has 47,000 letter E’s in it today.

Hagan: Yes, exactly. And those are the kind of stats they’ll give you. And it’s like, thanks.

Jared: Sixty four percent of words are spelled correctly.

Hagan: Yeah. One million three hundred and twenty two pages. Great. OK. Why isn’t it 323? I don’t know. Like, it’s just data and they’re just sort of flooding you with this firehouse of data. And it’s not useful.

Jared: So, you really have to get into the head of the user to figure out how to do a dashboard right.

Hagan: You really do. I mean, you can build your app and never put a dashboard on it. The dashboard is a completely separate layer. It doesn’t do anything that the app doesn’t already do. It doesn’t tell you anything that the app already doesn’t have in it.

So, the question is, why are you putting it on there? If it’s just to be a sales gimmick, yeah, I guess. But I think the clock’s running out on how much people are going to love that in sales calls.

You really want to say, we know our app is complicated, we know there’s a lot there, and we’ve really spent some time studying what our users need to know, and what they need to do, and we’ve incorporated those things here.

Jared: So, one of the things that we’ve been doing when we go out on customer visits is we say, OK, so what’s the first thing you do every day? And we have the person we’re visiting actually walk us through those sorts of first steps. So, if we start to see patterns from one visit to the next, of a first thing that everybody does each day, that, to some extent, is telling us what a good dashboard entry might be.

Hagan: That’s right. And that’s why I say, I can usually tell if my customers know their customers just by looking at their dashboard. If they know what they’re users are doing with their app, and they know what information their users need to have, then their dashboard will show it.

Jared: I wonder if this is one of those places where self design, you know, designing an app that you also use yourself on a regular basis, actually really helps, because you know what you want to see. And if your behavior matches your users’ behaviors, you know, which doesn’t happen that often, but programmers creating tools for other programmers. People who are business owners creating something for other business owners. It does happen.

You can get away with that. But if you’re not in that space where you’re not a user of this thing, the odds of you coming up with what those dashboard things, without doing serious research is probably very slim.

Hagan: So we worked on a help desk application a couple years ago. This was an app where we had some really different types of users, different personas that we were working with. A help desk tickets come in. End users have problems, they submit tickets, and then there are the people running the help desk.

There are the folks that answer the help tickets, the front line worker. What they do with the app is they go through their list and they work through their tickets, right? I mean, that’s their job. Then there’s their manager and their manager might manage 20 or 30 of these people and they want to know things like who’s doing the fastest job of going through these tickets?

Who’s got the longest back log? What do I do when this person’s out on Tuesday and I need to redistribute his tickets? And they were using the same dashboard for both of these user types and they had totally different needs, you know? And so we separated it out. We had two different dashboards.

Sometimes the managers did answer tickets so they would use the ticket answerer’s dashboard sometimes which was a list of your tickets that you were assigned to and helped you deal with that. What’s the highest priority, things like that.

Then there was this separate place that managers could go that would show who are your top performers. Who has the greatest back log of high priority tickets, things like that and they could look it up and find that information really quickly. All that information was already in the app. You could have gone and gotten it any way you wanted but the dashboard collected it all together in one place.

Jared: I would think, also, that the dashboard would be an opportunity to plug other things in that may not be part of the app like server up time statistics and things like that, that would be specific to, “what is the current state of a given server right now” so that if all of a sudden a slew of calls comes in, “hey the system’s not working”, you have this up to date information that says, “oh yeah, we know.”

Hagan: Exactly. The router’s down, we’re dealing with it. Exactly. You can bring in that information. A lot of folks, especially in IT, they like for the dashboard to include information about the app itself. Is the app running properly? Was it able to contact everything it needed to? Sometimes the problem is the app itself is breaking down and so they love to see that information.

Jared: Right. It seems to me that things like dashboards and stuff are going to be moving to mobile platforms, that there’s an opportunity to have a way to bring this up. Are you seeing… now that people are using things like iPad and Android and stuff like that are there patterns there that are coming back into the desktop?

You know, Apple just recently with their newest release changed the direction of scrollbars. Are we going to see some of those visual tropes that have been happening with the IOS operating system are we going to see those starting to come back on the desktop and other places?

Hagan: I definitely think so. They didn’t just change the way scrollbars work, they now hide the scrollbars when you’re not in the scrolling area which is a direct lift off of the IOS platform because they don’t have many pixels. They don’t want to clutter it up by showing you a scrollbar.

Jared: Yeah, I wonder how long that’s going to last because you need some sort of visual clue that there’s more.

Hagan: Yeah, I mean I think the number of patterns we have is always increasing. We always have new problems to solve and the patterns are really just an expression of what we commonly do to solve these problems. And as the interactions evolve and we use different preferences, we use touch, we use different things, the patterns adjust and what we consider normal, changes.

One example on the IOS devices is for instance in a list of phone numbers, so I’ll have a list of people’s names and they’ll have a row for the name and then they’ll have a little circle on the end on the right. If you click anywhere in the row you make the phone call. If you click on the little circle you go edit the address book card for that person, right?

That’s a completely new pattern that was developed on mobile and it would not surprise me if in a year or two we see that coming back to desktop. Stuff like that. So yeah, the pattern space is always increasing. Interestingly, I’ve been putting this class together and a lot of the patterns from desktop from 30 years ago and from web still apply in the mobile space.

So, there’s an enormous amount of overlap between them. I think they’re all converging into one big pattern space that just keeps growing.

Jared: Any of those 30 year old patterns that really shocked you like oh my God we still use that?

Hagan: We still use this basic desktop form for tables. A table with a toolbar above it. That has not changed. Mobile has a little trouble with tables because they’re wide. And so mobile is using more of what I call a list where you don’t really have columns you kind of wrap stuff into thick rows but they still have a toolbar at the top or the bottom. It’s the same idea.

Jared: Yeah, OK. Yeah, it’s true. That goes back to almost pre-Windows days where, yeah, using DOS and character based displays.

Hagan: Yeah. And honestly you look at the design for tables. You click on the header to sort it. Sometimes you can click on the header, right click, and you open a little menu of other options. I mean, those patterns really haven’t changed and they work really well. Why fiddle with them?

Jared: Yup. That makes perfect sense to me. Well, Hagan, it is wonderful talking to you. I’m really excited about the class that’s coming up in November. I think it’s going to be a lot of fun. I’m really looking forward to learning all sorts of great stuff.

It sounds like the perfect class for folks who really want to get a handle on how to get that stylistic essence of their individualistic design traits for each developer out of the design so it feels like it was written by one person.

Hagan: Yes. We’re going to work on consistency but we’re also going to work on it being beautiful and elegant and solving people’s problems.

Jared: That sounds excellent. I’m looking forward to it a lot. Thanks for taking the time to talk to us today.

Hagan: Thank you.

Jared: So if you want to take Hagan’s workshop it’s easy. You just go to UIConf.com and you sign up for the three day event and you have to sign up right away because her session’s going to fill up. I got to tell you that. It always does. So UIConf.com. That’ll be November seven through nine.

Hagan’s going to do a full day workshop on the ninth on dealing with complex applications, how you make complex applications so much simpler. So I’m looking forward to that. Thank you Hagan for spending the time with us today and I’d like to thank the audience for once again encouraging our behavior. Take care. We’ll talk to you soon.

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.

A few weeks ago I interviewed Stephanie (Sullivan) Rewis and Greg Rewis to find out what they’ll cover in their UI16 workshop, Everything a Designer Needs to Know About CSS3 and HTML5. Let me tell you, there’s a lot.

In this article, we explore why rounded corners and drop shadows are such a big deal for both the designer and the SEO specialist. Then we take a look at what a media query is. Finally, we wrap up with why Stephanie and other designers are having a love affair with Modernizr. The podcast covered even more material so you may want to give it a listen or read the transcript.

Read today’s article: A Snapshot on What Designers Need to Know about HTML5 and CSS3

Whether your learning about these new benefits now or are already familiar with them, but don’t know how to put them into action, you’re in luck. Thursday, September 15, Stephanie is giving a 90-minute virtual seminar on how to implement many of the new CSS3 features. You won’t just hear about the benefits, you’ll learn the coding behind it. Think of it as a teaser to Stephanie and Greg’s full-day workshop at the User Interface 16 conference where they’ll dive even deeper showing you how to put HTML5 and CSS3′s new features into practice.

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.

Communicating your design ideas is hard enough. You certainly don’t want to worry about the tools you use to get your message across. So we made a toolkit for you. It’s yours for free when you register for UI16 by September 21.

Your designer’s toolkit contains:

• A high quality sketchpad loaded with different templates to sketch your ideas
• A variety of sketching utensils to give your designs life.
• A mesh bag to keep all those great sketching utensils together.
• An organizer making it easy for you to bring the kit to meetings.

More about your UI16 experience

Besides the designer’s toolkit, your UI16 experience consists of:

1. Two full-days of intensive, deep dive workshops

Each day you’ll be immersed with one of the UX Experts learning the critical skills, tools, and techniques you need to master that topic.

2. One day of insightful 90-minute talks

You’ll get exposure to all the full-day workshop topics and presenters that you didn’t attend.

3. Networking events

Join your peers and the presenters to discuss best practices, success stories, and common issues.

4. Post-conference recordings to share

Relive the experience with your team with audio and video recordings of the featured talks.

5. Complete set of all presentation materials

You’ll receive the presentation slides and materials from each and every workshop and featured talk.

Register for $1,649 by Sept. 21 and get a free designer’s toolkit. Get all the details at UICONF.com

Why you need to be in Boston, November 7-9.

• Invest in your skills

Spend a little money now to increase your skill set. It’s far less expensive for your organization than searching and recruiting new talent with a skill set your team needs. Companies who invest in their employees reap the benefits of your new skills and save money by leveraging your newfound expertise.

• Invest in your site’s experience

Attending UI16 gives you techniques to bring more functionality to your web design right away. The users’ experience will improve which, in turn, brings in more revenue.

• Invest in your attitude

One of the most frequent comments we hear from past attendees is how inspired and motivated they feel after attending the conference. When you return to the office, you’ll be itching to put into action all the cool ideas and techniques you learned.

• Invest in your team

You’re not just educating yourself. You bring back valuable insights, knowledge, skills, and resources that everyone on your team can benefit from and share. A large contingent of attendees conduct formal knowledge-sharing meetings upon their return.

What you and your company get when you attend UI16

A lot comes with the $1,649 registration fee.

• Register now and guarantee your picks for the full-day workshops on Monday and Wednesday (when it’s time to choose them).
• Choose 4 featured talks on Tuesday and be the first to hear a brand new keynote from Jared Spool.
• Receive all the presentation slides and materials from every single workshop and featured talk.
• Get the audio and video recordings post conference from all the featured talks and Jared’s keynote. We encourage you to share these recordings with everyone on your team.
• Share best practices and discover new solutions with fellow attendees and
  speakers at the networking activities.
• Use your new designers toolkit to explore your design ideas.

Learn how UI16 will change the way you work. UICONF.com

You can’t ask people what they want. They can’t tell you. The answer is almost always narrow in focus, concerned with the here and now rather than the future. How do you get them to give you the observations you need to design what they will want? Conducting field research to actually learn about your users can lead to innovative new ideas. Going out into the field provides real opportunities to see what the world surrounding your product is like.

Steve Portigal, Principal of Portigal Consulting, is an expert in conducting field research. He understands the value and unique insights that can come from observing your users actually using your product.

Creating a great user experience starts with field research, that’s why it’s one of the 8 workshops at this year’s User Interface 16 Conference in Boston, November 7-9. And luckily, Steve Portigal is presenting the workshop. Get the details on Steve’s and the other 7 workshops at UICONF.com.

Here’s an excerpt from the podcast.

“… If you are trying to change the game in a certain space, that’s well entrenched, you’d better have a more interesting approach to the field than to say, ‘well what would you want to see different?’

You have to be looking more broadly at people’s behaviors and their needs? What are educated people trying to do, and how are people solving problems? What are the entrenched challenges there? You need to use techniques to gather that information and make sense of that information.

It’s not a ladle that you dip into the soup, right? Scoop. Oh, here’s what people said they want. We’re going to go off and do it. That’s never a way to do breakthrough stuff…”

Tune in to the podcast to hear Steve cover these points:

• Should you ask people what they want or how they’ve molded their world around the products?
• What are the benefits of A/B Testing?
• What do you do when teams jump from observation to design solution without taking time in between?
• Should you do exercises or activities to translate the data that you’ve collected in the field?
• How should someone deal with the anxiety of being in a person’s home or workspace for extended amounts of time?
• What is the value of doing a “pilot” test?

Do you have experience conducting field research? 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. I am very excited today because we get a chance to talk with one of my favoritest people on the planet, Mr. Steve Portigal. Steve, how are you doing here?

Steve Portigal: Great. Who can not be great when they’re framed in such a glorious fashion? So, thank you.

Jared: Awesome. Steve, you probably know this but everyone else might not, you are going to be teaching a full day workshop at UI16 this year. I hope you know this because if you don’t it’s quite a shock I’m sure.

Steve: DOING. Yes, I know it.

Jared: On immersive field research techniques. I’m very excited about this because we haven’t had a field research topic in many years and I know you and I have been talking about this for a long time. It’s really exciting to see people really interested in field research these days.

The amount of interest has been growing radically. And, I was just thinking about this the other day that I think one of the reasons is because no longer can we just depend on incremental improvements, you know, just fixing this feature a little here or running the usability test and cleaning up this dialogue box.

We now, for a lot of organizations in order to really have a full burst into the marketplace or to really have people pay attention they have to have something that is completely ahead of what their competition is doing and the way to do that is to go into the field and see what is being missed by the current products and offerings and what opportunities are there. I don’t know if that’s what you’re seeing in your work.

Steve: Yeah, very much so. I think that, as you say, implementable improvements they’re table stakes. As you say the competitors are going to be doing that at least. Lots of spaces are getting crowded, new spaces are opening up. I think what’s interesting is those are hard problems to solve. There’s not necessarily obviously clear what to go do in the “white space”.

So companies have these massive trajectories, they have momentum, they’re succeeding, many of them are doing really, really well and using design to kind of optimize within that. I think people know from experience, from recent trends that that can be a short lived advantage, that they have to keep working along the “innovation”.

I’m going to put quotes along every six words I say here. Along the “innovation” vector to try to continue to open up new spaces and stay ahead or to get ahead.

Jared: Right, yeah. I mean, one of the things that I’ve been seeing is that, you know, someone the other day on Twitter, I don’t remember who it was, posted that if you are always trying to catch up to your competition you’re always staring at their ass. And I think that if you want to get ahead you’ve got to do some of this research that really gets you out there, really gets you with your customer, really gets a chance to see what the total game is that is happening with where the products today are working and where they’re just completely missing the boat and then designing for that space as you put it.

Steve: There’s a great sort of, what I think of as a great myth around that that maybe we can talk about for a sec. Just the oft repeated idea that you can’t ask people what they want because they can’t tell you so that if you’re in the kind of business and design challenge that we’re talking about where you want to break through and innovate and reinvent something you shouldn’t ask people what they want because they can only talk about what is going on today.

I love hearing that because I feel like I have a good response to that. It’s a conflation of a few things. One is, let’s just say, looking more largely, doing field research to learn about people and asking people what they want. I think if this is not an area that you’re experienced in you think those are the same thing. You think the only thing you can do in field work is to say, “well what do you want?” and then go off and build it.

And most people would say that’s not an effective technique for learning new things. I agree with that on the face of it. If you, you know, are trying to change the game in a certain space that’s well entrenched you’d better have a more interesting approach to the field than to say, “well what would you want to see different?”

You have to be looking more broadly at people’s behaviors and their needs and, you know, what are kind of educated people trying to do and how are people solving problems? What are the entrenched kind of challenges there? And so you need to use techniques to gather that information and make sense of that information.

It’s not a ladle that you dip into the soup, right? Scoop. Oh, here’s what people said they want. We’re going to go off and do it. That’s never a way to do breakthrough stuff. So yeah, I agree when people say don’t ask what people want because they can’t tell you but I don’t agree with the implication of that which is don’t do research to try to innovate.

Jared: Well it’s interesting you put it that way because I took a team out on a bunch of field studies. This is a company that had been in business for six years, they had a very popular product, the customers loved them but they’d never actually been out to watch their customers use their product.

They handle support calls all the time so they know the things people call in for and they use it themselves all the time so they know how they use it but they didn’t and they hadn’t ever gone into the field and seen someone use it.

And I asked the head of development, I said what are you hoping to learn on this? He had a very interesting response. He said, “I’m really hoping to see all the ways that people hack our product, all the ways that they use it in a way that we never intended possibly because we’ve left some big, gaping hole out there or possibly because there’s a use out there we never thought of.
I want to see all of that.”

And I thought that was really open minded for him. It was really sort of out there. And you’re right that sort of, you know… was it Henry Ford? I thought it was Bill Gates who said don’t ask people what they want because if I asked people what they wanted they all would have told me they wanted a start button. Wasn’t that the quote? I think that’s the quote isn’t it?

But it seems to me that there are real opportunities to get out there and just see what the world around your product is like. It’s not so much that you’re asking people what do they want as much as how have they molded their world around the products that are there?

Steve: That’s right. That’s right. In that example and in your story about your clients you’re kind of talking about what’s the research question? What do we want to know?

I think implicit in your story is the business question which is: “what do we want to do?” So I can imagine your client saying we want to change, you know… direct resources toward changing the type of engagement we have with users or redesign the platform to take us 10 years ahead.

There’s obviously some strategic question that’s driving that and then the research question which you created with them or they created in their brief to you is a really helpful one. Then I can imagine your method just falls right out of that. Once you understand that there’s an interesting continuum there.

But you need to surface the business question. You need to surface the research question. What do we want to learn that’s going to help us answer that? Those are, I think, really important to draw the thread between those before you get to methodology. I think that takes a lot of expertise and so asking people what they want I think is just the naivest version of that.

Jared: Right, right. And I think, it’s a cop-out type of business work, right? That sort of, “well we’ll just ask them.” It’s up there with putting 1,000 little knobs and customization things into your design. It’s this way of saying I don’t want to take the effort to learn what these people want so I’m just going to put it out there and let them, in essence tell me.

And then whatever they say I’m going to decide if it’s a good idea or not and then do it. If enough people say it it must be a good idea.

Steve: Isn’t that called AB testing?

Jared: Yeah, yeah. I think AB testing falls into that a lot. Actually, AB testing has the down side that you never get tot hear any why. So all you know is that design 37 beat out designs 36 and 34, so obviously that might be what people want.

The other downside of AB testing is that people often use the absolute wrong measure to determine what is success. So they do something clever like well we got that person to sign up without ever asking if that person will use or value the service in any way that will be long term meaningful to either us or the user.

But we got them to sign up. And you know, we promised them money and their best sexual fantasies and they signed up. Guess what? So I guess our dishwasher repair service is now going to be a hit.

Steve: Unfortunately you know, year over year returns or loyalty, sometimes those fall to a different team. That are, you know, trying too… I’m sure you’ve encountered this all the time. We have our loyalty team working on a loyalty product and we have our conversion team working on sign ups for the product.

And this, the sort of silo in their design efforts based on kind of slicing and dicing, so to speak, the way that “the consumer” is using their products. Of course, no real person segments their experience in that way at all.

They don’t have a difference between interest, conversion, usage, loyalty. So these companies, I think, are trying to divide up hugely complex problems and you know, apply resources to them to try to own every facet of the experience.

I understand that effort but certainly when you look at the whys, as you bring up, the why question applies across all these different parts of the experience and you can’t think of these different aspects of the experience in that vacuum. It becomes very challenging.

To gain any insight about loyalty without gaining insight into conversion. So AB testing sort of proves how to get people to do a thing you think you want them to. We really like when we get to triangulate across methods.

Obviously there’s no one method that’s good for everything so you can find great clues, as you say, if you’re asking the right questions in looking at log data or other sort of very observational, kind of objective measurement things. Then you can get some narratives from people through different types of methods that help you understand why.

You’re not asking one research method to solve the other problem but if you put together a whole series of explorations in an ongoing way, you know, then you’re sort of doing intelligence gathering and you can tie that into insights. Then I think you can really start pushing your designs to solve the problems because you have a more broad-based understanding of them.

Jared: Yeah. I think that’s true. I think that’s true. Now, I’m interested in your thoughts around this idea. So a team goes out and they do research and, like you said, they triangulate their research. So they’re doing field stuff and they’re doing some stuff with their analytics and some other methods too.

All of a sudden they’re producing all this data. Observations and analytical number and all sorts of things are coming in. And it’s really easy for folks to just say oh look, people who see this screen are more likely to click on this button so we should design that way or when we went out in the field we noticed that people kept asking us for this so we should just build that.

And I’m wondering if you’ve encountered this sort of immediate jump from observation to design solution without taking time in-between and what you do about that when you see it?

Steve: Yeah. I think that’s a very serious concern and I think so many times we’re setting up an engagement and we’re kind of warned. Our internal gatekeepers say we have to think about how we tell so-and-so what we’ve seen because we don’t want them to go off and start doing things, that there’s kind of trains in the station that are charging up and ready to… I’m butchering a metaphor here, but…

Jared: [laughs]

Steve: They’re ready to burst out of the gates–there I go, I killed a metaphor–that they sense that around them, and they’ve seen knee-jerk reactions. I think what we do at the outset of a research project is identify what the milestones are and what the output is and what they’ll be able to do with that and try to have that.

Either it’s explicit in the proposal as part of the conversation that we keep having, because people are hungry. They’re hungry for something. Try to keep engaging them in being in the field and sharing fieldwork stories and sharing early kind of thematic things. But we very deliberately do not say, “And maybe you should do X as part of that.”

So in terms of our structuring of our communications and our reporting and so on, we’re trying to set that frame and set that expectation clearly. I don’t mean that’s sufficient to help structure that. It’s funny. I think of actually a counter example where people did act very quickly on…it’s the low-hanging fruit stuff.

And then when we’re out in the field with something, this is a detour on the way to answering your question, which I think is an important one. They were out in the field and watching someone set up piece of…I guess it was sort of an audio/video/computer hardware product.

The instruction manual explained how they should insert the, it was L-I-O-N lithium ion battery. But I think it’s like L, lowercase I, captial O, It’s like a very weird word. It’s a technology word. The person that we were observing just kept talking about the “Lion battery,” and of course had no idea what the “Lion” battery was.

Jared: Right. [laughs]

Steve: The person that was from our client side who was out in the field with us. I think he owns the documentation process. He went back and he took the word “lion” out of it, so it said, “Insert the battery.” It was awesome. I mean I was just so glad to see because they had huge, huge, huge, huge problems that we uncovered through this longer project that required a lot of design efforts to solve. But I was just really gratified to see.

To me that was just a low-hanging fruit. It was very obvious what the problem was. There was no sort of ripple out affect to making changes. It was “Let’s just take that word out.” It was just a nice little edit.

So one thing is that that could be done very, very quickly, like for him to open up a documentation management change order, so that guy owned it. The change was very, very quick. I think it could be rolled out fairly quickly into the next printing or the next run that they were doing of that documentation. So it was an isolated solution to an isolated problem.

Now the fact that they have used that kind of language in their documentation, and of course you know just having worked on these kind of projects that there were many, many, many things like that that were much more complicated and twisted that didn’t necessarily have such easy resolutions.

So I’m not of course excited about people, you know, jumping the gun on everything, but where there were some very clearly actionable pieces that didn’t require the report from the vendor of the research process, fantastic. It was really great. We were clearly being actionable and having impact and giving them examples at a detailed level in a more user-centered way.

That all being said, this was very, very complicated, and it took a lot of work with us all together to kind of unpack the research and make sure that we understood what exactly was going on.

It’s the difference between going from stories and anecdotes and feature requests to understanding something that looks more like a model or a framework or a continuum or a diagram or segmentation. Some way that you can visually or kind of informationally, if you will, include all this stuff together.

I think that’s analysis and synthesis, and that’s a thing that doesn’t necessarily come naturally to designers who are trained to make a translation between an observed need and a design solution. I love that ability the designer’s playing, and I always just want to just slow it down. I think we often run into the consequences of the failure to do that where you know these teams are sitting on a multifaceted compost heap of anecdotes and mythologies.

Jared: I’m writing that down. “Multifaceted compost heap.” That is like the best phrase of the day. [laughs]

Steve: They are looking at all this stuff. Depending what angle you’re looking at, it’s like, “Oh, people want this” or “So-and-so said this.” These myths get created, and it’s hard for anyone in the organization, let alone as a group, to have a coherent sense of what to do. They’re just looking this pile and seeing a glimpse in the sun at that moment.

People will have these pet stories that get kind of retold. Sometimes lurking within this heap are escalated larger-than-life anecdotes. The name of the difficult angry customer that gets repeated over and over again in every conversation. “Well, so-and-so-and-so’s going to…you know how they’re going to react to that.”

We worked with a company that had circulated a video. It was a kind of transactional tool that was often being used in high-pressure market-changing conditions. There was a video circulating of the hands of this person who was using this thing at a rate that you just wouldn’t believe. You’d think the video was sped up.

And you know, so I think on the face of it they’re doing this great thing, right? They’re circulating a challenging use case, but it reaches this kind of status inside, that it’s larger than life. You know, you’re trying to design for Superman, and part of the story of the Superman is that they can’t be designed for because they are so over the top in their performance.

So these “peering into this compost heap” people can kind of, in groups and cultures, create these legends that are trapping them more than anything else. And so you have kind of a divergent mess with these spikes sticking out.

None of it is representative. None of it gives you an integrated, holistic view of what the different types of users, what the different types of users problems are, what the different design strategies are, how to prioritize.

It’s never been folded into anything and kind of elevated up a level where it has structures to it and you can say well there are these different types of folks, here’s how they interrelate, here’s the kinds of problems we’re having, here’s the kinds of issues we’re dealing with.

This is not about… sometimes you’re just trying to reframe what the challenge is. We had a client that was dealing with an easy to install product and it was all about reducing time to install but when we talked with people about that value proposition in their use context they talked about smart.

Kind of in the smart technology, smart home, smart phone use of smart. They kind of pushed back our story that it was about smart. It wasn’t about reducing time. It was about reducing errors and saving me having to go back and fix the install. That was kind of an elevated framework about what is the benefit?

How does this thing that you’re doing fit into the way these people are thinking about their work and what they care about? So, and this is kind of a long ramble, Jared, but it’s about the needs to get from this compost heap, this sprawling mess of stuff where people are grabbing on individual pieces to something that is more holistic, unified, and you know has kind of action items coming out of it.

I’m waving my hands in the air, not that that would help anybody anyway. Doing that aggregation and translation is why, this is a long answer to your question, why do we not want people to jump off and start designing things right away?

It’s because we need to put it together into this larger, generative framework which sounds really smart and hard and time consuming but it is very doable. It just means you need to allow time in that process for that to happen and timing your brain for that to happen and defer or parking lot that jump to solution impulse.

Jared: So to defer that do you use exercises and group activities to get people to take apart the compost heap, as it were, and start to look at the different things and start to measure OK we’ve got the guy whose hands are really fast.

But from a bigger picture what are the other users like and are they like that or are they something different and do we have to design for a continuum of things?

Steve: Yes. I mean the short answer to that is yes. It’s an exercise activity. So you know, I think about doing research with users. There’s sort of these big chunks of activities. One is planning. We kind of already talked about trying too figure out what your research question is, what your business question is, what your methodology is.

There’s all the planning. There’s all the field work. So this is, you know, whatever kind of methods that you’re using, doing that and that is very immersive. That gets your brain going and gets you thinking about… You know, maybe you’re thinking about solutions. I think what we try to do is think about people and get stories about people and new perspectives on people kind of in the mix constantly.

And then the next step is analysis and synthesis. So there’s a phase of work that’s OK so we’ve finished being in the field. We have artifacts, we have experiences, we have video, we have transcript logs, we have reports to go into a new activity that says let’s disassemble all that.

What are even the axes which people are engaging in? What are the factors? What are the extremes? To dump all that and then to start to collate and organize and structure and prototype frameworks. Oh, it seems like there’s a relationship between the maturity of the user and the feature sets that they’re using.

That’s not a very good hypothesis, but it seems like there’s something here where there’s a relationship between these different factors. And it looks like, oh yeah, here’s how it breaks down. Well, no, that’s not actually true. Maybe it’s a relationship between these factors.

You’re sort of experimenting in a guided way. Your gut is driving you, your experience is driving you to look for meaningful ways to organize and structure this stuff. That’s the synthesis part. The analysis is sort of decomposing these stories and these fieldwork experiences into these elements and the synthesis part is putting them back in a new way and building up this framework.

Jared: I think I have an example of this. I was talking to Kate Brigham the other day from PatientsLikeMe and she was telling me that one of the things they’ve noticed was that when people first start using PatientsLikeMe, you know these are folks typically with chronic illnesses or they’re caregiver to someone with a chronic illness, they’re very much about just trying to discover who else out there is like them.

And they’re just, you know, putting in their data about how they’re feeling and they’re getting back data about whether how they’re feeling relates to how other people have felt in similar situations. They’re very much focused on that data and sort of initial connection sort of stuff.

Then they learned that as people use it more and more their attention shifts away from the data stuff and more into the community aspects. They start to have friends who they communicate with on a regular basis through their messaging capabilities. And those people, it’s less about their disease and their complications and it’s more about having these connections and these friendships so the functionality has to shift to this other stuff.

That was something that they observed in studying their user population that there was in fact a change in functionality as people sort of matured with the service.

Steve: That’s a great example, and you can imagine folks not as talented as Kate sort of looking at you know, some — it’s the compost heap again — some set of data, some set of feedback, and not understanding what it is that differentiates user input A and user complaint C to understand what to do about it. Logic is, half of our customers want this kind of change, and half of customers aren’t using this other piece.

Jared: Oh, yeah, well their community members are very, very vocal about the design of the site and tend to discount those things that are aimed towards new members, because they’re long past that. So the types of complaints they get in are very biased towards those more mature feature sets.

Steve: And now that they’ve built this — I’m going to call it a framework — there’s a journey of a user through their relationship with us. As you say, they have different expectations and different interests, and so there’s different designs. The design solution isn’t put feature in for this use case or that use case. It’s creating a product that changes with you or that evolves or that you can find your way through that.

I mean, there are a number of specific types of design solutions that can obviously be built from that, but you’re trying to take those observations and those inputs and build that larger story, at which point there’s some strategies. We’re doing a lot of — in our hand waving conversation here — presumptively on Kate’s behalf…

Jared: Right. [laughs]

Steve: We’re still far from creating design solutions. We’re building what the problem is. I mean, it’s not “we.” Kate did this, but you know advocating for what she’s done. Her team has identified what the design problem is, which is completely different than where they might have started if they were looking at the different types of inputs they were getting — the feedback, the observations, things that weren’t being clicked on. We have to make this button bigger because people aren’t clicking on it enough. Those are naive types of design solutions, because they don’t reflect the deep understanding that you’re relating that Kate and her team have produced.

Jared: Yeah, I think that this idea of slowing down and really trying to understand the problem before you jump to the obvious solution so that you can get a more deeper perspective is really a valuable thing that separates teams that are really good at what they do from those teams that are just really trying to be reactive to the world.

Steve: Agreed.

Jared: So one of the things that I hear from folks when we start to talk about field research is that they get really anxious about having to spend large amounts of time in a customer’s home or in their workspace actually talking to them versus from behind the safety of a double-paned, one way mirror with acoustic tiling, so that they can’t hear you giggle. That idea of being right there — that’s hard for a lot of folks. Do you find that?

Steve: I find it for myself, sure. I think the first interview or first sort of thing that we’re doing at the beginning of any study — I’m just incredibly nervous. You know? And I think this has a lot to do with confidence.

It has a lot to do with personality type. I’m an introvert. I think this puts me into an uncomfortable situation. First one is very scary for me. I actually remember having breathing problems a year ago — not that long ago, and I’m been doing this for a long time — kind of like going up to the door.

But you know, by the end, I mean, it’s kind of like riding a bike for me at this point, but definitely I know what that nervousness at the beginning is.

Jared: See, I thought it was just me.

Steve: We definitely can relate to people that are having their nervousness, right? It is — and as much as you plan for it, it’s always going to go in some way that you don’t expect. You know, I hate to be flip, but I think there is a “just do it” aspect to this.

What’s the worse that can happen in these kind of situations? If the worse that can happen is you get murdered, well there’s probably some reasonable planning that you can do in terms of screening your participants to keep that from happening. I guess the other worse thing is that you piss off a valued customer, and I have worked with financial institutions where we’re not just going to consumers, we’re going to their customers, and it was really charming and eye opening to see how they kind of brought a customer service mentality to research, and I think it was really effective.

It actually helped — it gave them a framework to work within. We’re not going out there to fix their car or something. We’re not performing a service but we’re learning about them in order to advocate for them, in order to do a great job for them, we want to represent them to the institution, we want to represent the institution to them, and that I think was a big part of their culture. I think that was really kind of helpful.

So you know, they didn’t want to piss off customers and have them leave that relationship. So those are worse case scenarios that you can be prepared for.

I think you can get no information or get misleading information, and that’s kind of a risk that you’re taking. And this is, I think, is where practicing, pulling down the information that’s available out there about best practices that you and I are making available that are everywhere, I think, in our field, are ways to mitigate that.

Trying it and reflecting on it — there’s lots of learning that you can do. Watching your videos of yourself do interviews. I just cringe every time I do that, or reading transcripts and seeing the stupid things that I say or bad ways that I ask questions.

Doing it and just have the experience and then reflecting on it, debriefing with your colleagues, talking about what you’d do different. Treating it like a learning process, you know I think it’s something — and also, I’ll just say that being uncomfortable or scared or out of your zone — it’s not the worse thing in the world. If it is, 90 minutes in somebody’s living room — you can, you know, just bear down and say, “OK. In 91 minutes I’ll be done, and I’ll see what I’ve learned from that.”

Because I can think of any number of times that I’ve just been uncomfortable or confused or had my own view of the world pushed on. Some people like to go on rides or go see horror movies. Those are, you know, getting a thrill by taking yourself out of your physical comfort zone or your emotional comfort zone. This, I think, you can look at it that way. I mean, it’s more deliberate and more meaningful, and it’s not for entertainment, but we do have analogs in pushing ourselves that you might look at this in that way.

Jared: Yeah, I think that there’s definitely something to that, and I think that also planning and practice just makes it a little easier, I think, for folks. I’ve found that having a good plan as to what we’re going to ask, so you’re not feeling like you’re improvising from nothing the entire time you’re out there. Of course, you want the conversation with the participant to be natural, but knowing what the goal of the session is and where you want to hit and what points you want to touch on helps a lot.

Steve: I totally agree. I mean, preparing a plan, writing up a plan, creating kind of the archetypal interview. This section takes 20 minutes. This section takes 30 minutes. We’re going to have these props or these activities for 40 minutes here. Checklists — I mean, this, again, depends on your personality type, but what does it take for you to feel confident?

Even if you don’t do anything like that, you’ve at least mentally prototyped what you think the session is going to look like. You’ve got buy in, so you know that your colleagues are confident, because they’ve had input into this. Some people I know do a pilot — because you’re basically hypothesizing that you can have an in-depth conversation with these exercises and these topics in this amount of time, and that you know how to ask about that stuff. So, whether it’s a colleague or friend and family, before you go out into the field, do kind of a participant number zero, and try it out.

Jared: My former colleague, a guy who helped us with a lot of our statistics and things in the early days, Will Schroeder, always used to say, “If you don’t do a pilot or a rehearsal, your first session becomes your pilot or your rehearsal.”

Steve: That’s so true.

Jared: I found that to be very much the case, so there’s a lot of value, particularly if it’s a really important set of sessions and if you’re really concerned that every session go really well, because either each participant’s really important or the people who are observing are really important or you just have so few that you have to make every one work. That’s when a pilot or rehearsal really, really plays an important role, I would think.

Steve: And sometimes you know, these are hard people to get to, so the first one has to be your pilot. But if you build an iteration — I mean, we were meeting with bankers recently and had lots of aspirational methods and we had Post-It notes and we were going to do timelines and get people to rank things and one or two interviews, and we basically didn’t even succeed in deploying any of our plan in the first interview. By the second interview, we were like, “OK. We’ve got to throw a lot of this out,” but we kind of sat down and talked through, “Well, what’s the iteration of our plan look like?”

So, it’s great to have a plan, and we weren’t — you treat it like a hypothesis that you’re testing. I think those first two or three sessions were extremely valuable because we learned what the topics were when we kind of went with it and we weren’t trying to force our guide on them, but we had an overarching architecture, I think, to try to work within. We then were able to just rebuild very quickly after those.

Jared: Yeah, I find that in our research that we’ve done to be the case. Tell me if you find it the same way, that as you do more sessions, the sessions mutate because you’re seeing some patterns and you want to explore them more, because they’re slightly different than the ones you saw before. You’re more attuned to things that are new and different, and maybe they’re things you haven’t covered before that you want to see if you can invoke in the session to see if you got any new responses to it. So there is a metamorphosis that happens.

Steve: Absolutely, yeah. There’s questions that you can’t quite get answers to, so you’re trying a few different ways and you’re re-purposing bits of improv from one into the next. If there are sort of issue here to him, that this is challenging for people and how to help them feel more like, hey, they can go ahead and do this. This isn’t so scary. Maybe just acknowledging that it is iterative, evolving, “metamorphisizing.”

Jared: [laughs] “Metamorphisical.”

Steve: Yeah. [laughter] And that you want to allow for that. You want to debrief. If you had five minutes to debrief about every interview, it would be, I think, two questions. One, what did we learn that surprised us now? And how would we handle the next interview differently? So that you’re debriefing on content — what are we learning? — and on process — how are we doing this? — as much as possible. Those are the two big things to really think about at the highest level.

Jared: That makes perfect sense. Well, everyone’s going to learn about how to do this stuff and get more comfortable with it in your full day workshop. I mean, you’re all going to go out and actually do some field research and then come back and analyze and synthesize the results, and I think it’s going to be a lot of fun. It’s going to be really a very cool day.

Steve: I think it will be great. I think people will be, hopefully, excited and surprised by how far we can get in a day in terms of playing with many, many aspects of this process.

Jared: So if you all want to come and hear Steve, what you need to do is go to the User Interface 16 Conference website, which is uiconf.com. The conference itself is going to be in Boston November 7th through 9th, and we’re very excited about it. It’s going to be a lot of fun. Steve, thanks for taking the time today to talk about all this stuff. This was a lot of fun.

Steve: Thank you.

Jared: And I want to thank our audience for listening, once again. It’s great to have you along with us. And as always, I want to thank you for encouraging our behavior. Take care. We’ll talk to you next time.

A good starting point is crucial. It sets the tone for everything that comes after. All too often, projects are unsuccessful or labor through growing pains because the importance of this starting point was overlooked. When done right, the kickoff to a project will leave the team energized, inspired, and engaged.

Kevin believes that kickoff meetings are the time to identify business strategy as well as company culture. It’s also important to assess any risks associated with the project in the kickoff meeting. Getting as many people involved at the onset of a project will help make the connection between project goals and the brand of the organization. It ensures everyone is on the same page.

Kevin Hoffman is User Experience Director at Happy Cog. Kevin will be presenting a full-day workshop at the User Interface 16 Conference, November 7-9 in Boston. For more details about Kevin’s and the other 7 workshops, visit UIConf.com.

Here’s an excerpt from the podcast.

“…The kickoff meeting gives you a great opportunity to establish a shared vocabulary, some shared vision and really, more than anything, establish culture and your working culture between two or more organizations. By establishing that culture, people are much less likely to become interrupters and more likely to become information resources.

For internal teams, projects tend to run usually a lot longer than they do with consulting projects. So you might be doing a redesign for your main website or for an intranet that could take 18 months or two years, depending on the size and complexity of the organization and the project. And after about six months of anything people get tired.

But if you have a good kickoff meeting where you’re establishing your expectation of energy and kind of being really open with a broad set of stakeholders in your organization in a more workshop collaborative format, it creates a positive energy that people will remember…”

Tune into the podcast to hear Kevin address these questions:

• Do you get others from the organization involved in the meeting than just the core design team?
• Is the meeting as much setting the course for the project as establishing constraints and boundaries?
• What is the goal in establishing a shared vocabulary?
• How long is your typical project kickoff?
• How much work is done prior to the kickoff meeting?
• What can I do to establish a vocabulary and vision if I’m not the one leading the meeting?

Do you have experience facilitating project kickoff meetings? Share your thoughts in our comments section.

Recorded: July, 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’m Jared Spool. I’m your cruise director for the day.

I am very excited to be talking today to Kevin Hoffman who is the Experience Director at Happy Cog and going to be speaking at the User Interface 16 Conference in November of this year, 2011, on creating great kickoff meetings for projects. I’m very happy to be able to talk about that with Kevin today.

Kevin, how are you doing?

Kevin Hoffman: I’m doing well. Thanks for inviting me to hang out this morning.

Jared: Well thank you for joining me and hanging out here.

So, kickoff meetings are this thing that we don’t really think about. You know, when we’re putting together this massive project and we’re thinking about what the design could be and the delivery dates and all this stuff, it’s almost the last thing we think about.

But it turns out that if we don’t do that right, if we don’t get that project started off on the right foot, awful things can happen, right?

Kevin: Yeah, I think so. I think it’s been my experience on both internal teams and doing consulting projects that people put about as much thought into the kickoff meeting as it takes to create that little line on a Gantt chart that shows in a project plan where it’s going to happen.

They’ll decide who needs to be there, but it usually ends up being not dissimilar to an Alcoholics Anonymous meeting where you go around the table and just kind of introduce yourself and your role. If it’s an external consultant, usually you’re introducing people to yourself for the first time, so there may even be some basic orientation like “who is our company?” and “why are we here?” and “who hired you?”

The kind of problems that that will create for a consultant or a third party is that kind of the classic swoop and poop. Where high level stakeholders will be coming in later on in the project because they didn’t know who you were, they didn’t happen to know that this was going on.

The kickoff meeting gives you a great opportunity to establish a lot of shared vocabulary, some shared vision and really, more than anything, establish culture and kind of your working culture between two or more organizations, as the case may be. By establishing that culture, people are much less likely to become interrupters and more likely to become information resources.

As I alluded to before for internal teams, I have a long background working on internal teams in higher ed and non-profits. And the risk for internal teams, I think a kickoff meeting can establish kind of an energy baseline.

For internal teams projects tend to run usually a lot longer than they do with consulting projects. So you might be doing a redesign for your main website or for an intranet that could take 18 months or two years, depending on the size and complexity of the organization and the project. And after about six months of anything people get tired.

But if you have a good kickoff meeting where you’re establishing your expectation of energy and kind of being really open with a broad set of stakeholders in your organization in a more workshop collaborative format. It just kind of creates a positive energy that people will remember.

So a month later when they think of something that’s relevant to the project, they’re going to be excited to talk to you about it.

Jared: So I like this idea of establishing an energy baseline, I mean, just getting everything going on this high energy element, getting people excited.

And the people we’re talking about here are not just the folks who are going to be up to their elbows in pixels and wireframes, you know, the core design team. We’re talking about getting stakeholders and various other folks from the organization involved, right?

Kevin: Yeah, absolutely. I think really … I’ve never seen it work exactly this way, but it kind of, sort of follows this pattern. Where, at Happy Cog, if we’ll do our kickoffs correctly and we have enough time to plan them, which isn’t always the case but it’s usually case, the level of engagement in our partner organizations tends to follow a reverse pyramid. In that, the longer the project goes, the fewer people we’re directly corresponding with.

We want to correspond with a decent number of people at the beginning of a project especially in a meeting, not just via one-on-one interviews or phone conference interviews. We really want to kickoff the project with that first meeting with as many people as possible.

Because we’ve found that as open and honest as people are willing to be our direct contacts, there’s always a larger picture of an organization. That you can only get from talking to as many different appendages on that elephant, as opposed to just kind of taking the elephant’s mouth’s word for it. And having that better picture allows us to identify risks for a project early on, address those risks. And, if we need to, occasionally be really frank about what we may not be able to do, as opposed to it coming up three months down the line.

Jared: I think that’s really neat.

What you’re doing here is this combination of sort of setting out a picture of where you think you want the project to go. While at the same time trying to reveal as many of the constraints that that project’s going to be under. And also set some of the boundaries as to, you know, where things start to get into science fiction and unrealistic expectations.

Kevin: Yeah, absolutely. The other thing I feel like it’s really important to convey in a kickoff meeting, and the way we do workshops generally is that, if we’re taking the time to do a workshop, there are two things that I want to make sure are clear to the participants.

Number one, we’ve taken the time to prepare ourselves for the work at hand. So we don’t like to kick off a project without doing a lot of research. If all we can do is landscape research and just really look at the design problem and how different people are solving it, that’s great. But more than often what we prefer to do is do a lot of one-on-one interviews with stakeholders and some light audience research before we go into that meeting.

So we’re coming into that workshop with a more sophisticated idea of the design problem at hand. But we’re not coming in with the solution. We’re inviting all of these people to this kickoff meeting because we think we have a good idea as to what the problems are. But we really want to collaborate with you and work together to develop the framework for starting to build that solution.

And in a best case scenario for us, usually working with smaller organizations, we’ve seen that actually lead to design decisions during the first meeting. Where, you know, we’ve decided, for example, page priority for a particular page on the site or a particular e-commerce process, where in that kickoff meeting we’ve said, “You know what? This is the primary design goal of this page and these are the three or four most important kinds of content that are going to support it.” And that’s the best case scenario.

But in the worst case scenario, with larger clients if we have a kickoff meeting with, let’s say, 80 or 90 participants which has happened from time to time, that sets kind of a project awareness in a larger organization of 500 people or more, sometimes a lot more.

And that really pays off down the line in terms of people looking forward to the next meeting that they’re going to have with you. And ending up with a really good meeting structure for complex, longer projects where people expect they’re going to have a chance to have their voice heard. And it’s not like they’re fighting to participate in the project.

In fact if you think about it, a big kickoff meeting is great. In that if you open it up, if you kind of have a philosophy of anybody can attend this meeting if they want to, they just have to let us know who they are and it kind of eliminates that, “You didn’t talk to me” vibe.

Jared: I want to talk about for a second something you said at the very beginning which was, this helps the team sort of establish a shared vocabulary and a shared vision. And I’m curious if you could say a little bit more about that shared vocabulary.

Kevin: Sure. We’ve worked with lots of different companies. Sometimes they’re non-profits and smaller, sometimes they’re non-profits and larger. Sometimes they’re for profits and very large. And sometimes they’re startups where they have a decent investment and it’s a small group of people.

What I have found more recently, or I’ve observed more recently, and this is kind of an ongoing observation, is, if I was to generalize. The larger an organization is, seemingly the less time it has to actually remember and pronounce out loud particular phrases and repeated words. And the more things become acronyms.

So, recently we pitched some work to a very well known computer manufacturer and electronics retailer. And in the correspondence alone, I had to sit down with our business development person every couple of minutes and say, “I don’t know what this word is. I don’t know what these three letters mean.”

There was just all kinds of internal jargon that was preventing me from being able to understand what the strategic request was. Because every time I would hit a term that was unique to that culture, I would hit a brick wall and have to say, “I don’t understand what this really means.” And, therefore, how it might affect the strategy I would recommend for this particular project.

So by getting in a room together and being very open and unafraid to say, “Hold on, does everybody know what XYZ is? We keep talking about XYZ.” Nine times out of ten it’s something you already know or it’s something you knew but just forgot. But I would say 10 percent of the time there are some pretty complex ideas that get almost compacted for consumption so that people in an organization can be more efficient.

And when you’re joining that organization, it’s a lot better to collaborate on that learning than it is to send an email requesting a glossary. Because I would say 99 percent of the time those glossaries don’t exist. Those cultures just continue to develop without documentation.

And to really get up to speed and work at the level that our clients expect us to, we need to know what all those things mean. So when I say shared vocabulary, it’s a little bit more on the consulting side, getting up to speed on the vocabulary of the client.

But at the same time, we try to construct activities in a workshop format that allow us to give them kind of a micro taste of what our process is. And what kind of things we’re going to show them over the life of the project. And how we expect feedback to come back to us so that we can use it to continue to iterate on whatever we’re doing.

Jared: So, is some of the vocabulary that you’re also establishing around things like what differentiates a good outcome from a bad outcome? I mean, is there a terminology that sometimes gets created in these workshop meetings that then gets referenced throughout the rest of the project?

Kevin: Yeah, absolutely. We pay close attention to everybody but particularly high level stakeholders. So that, when we deliver strategic recommendations in the form of a brief or in the form of an early prototype, we can reference concepts, specific words, specific ideas that came up in that kickoff meeting.

So there’s a fluid feeling to the process, not that we’re just throwing things over a cubicle wall or across the Basecamp wires as the case may be. We’re actually having a conversation for the duration of the project, and that kickoff meeting is the introductory hello in that conversation. It’s the first date.

In any great relationship, a personal relationship you want to have a first date, ideally, where you feel like you made a connection and you want to build on that connection. So to just throw away your first date as a, “Oh well, we’ve already agreed that we’re going to work together. So let’s just get lunch”, you know, is kind of a waste of everyone’s time and energy.

Jared: And you mentioned also this idea of a shared vision. And I guess some of this we sort of have been not really talking about this. You and I have talked about it before, but we haven’t talked about it here which is, this is not just, you know, a 45 minute meeting that you get together with, right? This is an event that goes on for a considerable amount of time. How long is your typical kickoff workshop?

Kevin: I would say it varies based on the duration of the project.

So if we’re doing a project that exceeds a year, a yearlong or 18 month or two year engagement, our kickoffs generally fall between a full day and two days. If we’re doing projects that are six to nine months a minimum of four hours.

Jared: So you’ve got these things that are four hours to a couple of days and so in this real work is getting done. This isn’t, like you said, this isn’t like an alcoholics anonymous meeting where everyone goes around the room saying, “Hi, I’m Jared and I’ve been at this company for 12 years.” Everyone goes, “Hi Jared.” You guys roll up your sleeves and you do stuff.

Kevin: Yeah. We try to come to come into a kickoff meeting armed with a significant amount of insight into the client’s perspective on the problem and a significant amount of insight into the market that the problem is designed to address. And that includes the audiences that something is intended to reach, but also it includes competitors and even things that are going on in design solutions that are analogous to what we see the problem as being and what our clients are telling us the problem is.

Many, many times it’s been my experience that if you come to a kickoff meeting with something that has nothing to do with the vertical that the clients in. So ,if they’re in widgets and you come in with something going on in cupcake sales that’s completely analogous and makes total sense, that people will be very responsive to that. And they’ll feel like you’ve thought about the problem.

So then during the meeting, the work that we do is we actually say, “So how do we make cupcake sales work for widgets? How do we actually do that?” And that usually takes the form of a lot of sketching and prototyping. It takes the form of a lot of frank discussion about prioritization and understanding the dualities of particular things that people are asking for? One thing I’ve heard a lot of recently is, “We want it to be really easy. We want people to be able to do things in one click and we want it to be obvious.”

“But we also want them to do a lot of cross sell and up sell and make sure they can find any product they need.” And at their core those two things could be done in ways that they would be at odds with each other. So really working on articulating conceptually how we can make those two things happen at the same time. And lots of other design goals and various user interface challenges that we want to hit, we want to address those as well. One example that I can think of from a kickoff meeting not too long ago probably in the last nine months.

There was a workshop that we did about search user interface. So spending a good hour in small groups thinking about what the current search metrics were telling the client, what their referral search metrics were telling the client, not just internal but the referrals as well. And then what they actually wanted people to do as a result of a search. Not just being able to find the thing that they need. Like, I need product X I want to type it into the box and it shows up, but what do they want people to do with product X after that? And how do we design search and search results to balance those user goals with the real business needs that the client had.

Jared: So, this is really interesting to me. So one of the things that I hear you saying is that there is a lot of work that you do before the kickoff. So the kickoff isn’t the very start of the project. It’s not the moment that everybody starts the billable hour clock or you know, gets the first say, “That’s where we started.” You’ve done a whole bunch of work to get into this kickoff meeting.

Kevin: Yeah. Generally during the sales process we try to establish the expectation with clients that before we meet with you we’re going to want to do research and that may take on average about two weeks. Usually we do it in less. But from the time we sign a contract to a kickoff meeting two weeks is reasonable. Now we have I would say a third of the time at Happy Cog and I’m sure this happens on internal teams and with other consultants. You get clients who have a check ready to go and they just want to start tomorrow.

And from time to time we do do that and we try to have enough of a playbook of kickoff activities in our pocket that if we have to jump into a productive meeting quickly with a client where we don’t have a lot of in depth understanding of the problem. We spend a day reading as much as we can and we tend to do a lot more listening in those situations. But most of the time we will spend just to throw out a random number, a minimum of a dozen one hour interviews with key stakeholders. And from time to time upwards of 30 and once or twice many more than that.

Just learning about a client’s organization, learning about the design problem, learning about people’s expectations especially if it’s someone who isn’t necessarily our point of contact but somebody who has a very different perspective on why this project is happening. We want to hear all those things up front. So we can start to connect some dots and identify some of that science fiction as you said.

Jared: And one of the outcomes of this you mentioned was the shared vision. This is something that I’ve noticed with teams that we work with that haven’t done a good job of this upfront. You start talking to people, “So what is this thing going to be like” and everybody is working on a different project. So it sounds like part of your goal with these kickoff meetings is to get everybody walking out of the room believing that you’re all working on the same thing.

Kevin: That would be the best case scenario and I don’t think that’s impossible. I do think that a more realistic way to put it is I want everybody walking out of that room expecting to see a vision in the very near future. And there shouldn’t be anything in the vision that we articulate that doesn’t feel like news to them, like, “I’ve never heard about this before.”

So for example, in a kickoff meeting we might spend some time talking about how social networks or you know, things like Facebook might integrate into a particular experience and why it makes sense or it doesn’t make sense. We won’t articulate a detailed vision for the social component of a project probably until the brief, but they know its coming and they’re ready to read it and tell us what they think.

Jared: OK. So a lot of folks who are listening are probably not in a situation where they can just call a meeting that gets all the stakeholders together and make all this work. They probably work for someone else who is probably leading these kickoff meetings. What advice would you give them for getting those meetings to be productive so you can get that shared vocabulary, you can get that shared vision started and start bringing that out.

Kevin: This is something I don’t think is only related to kickoff meetings. I think there’s a lot of really good techniques and approaches that apply to any kind of meeting situation where things are not going the way you would like them to go. So one of the things that I’ve said in the past and I will still say is that the more you educate yourself about any type of approach for designing human interaction, and I mean in person human interaction not electronic human interaction, in a meeting.

If you know of good ways to build consensus, if you know of good ways to explore a design problem, if you know of good ways to kind of iterate in a discussion or ways to facilitate large numbers of people getting a chance to get their voices heard. The more you know those techniques the more you can rely on them when things don’t go the way you need them to go.

So for example if you’re in a meeting where you feel like the point is to generate ideas and the quantity of ideas is very low, you’re not trying to evaluate quality. If you have sticky notes and sharpies in the room, in your conference room in advance and you’re familiar with KJ technique or other techniques, you can always suggest those as a participant. Like let’s just try this for five or 10 minutes and introduce things that maybe get people out of their comfort zone in such a way that it forces them to refocus their attention on the task at hand, and not just, “Ah, I’m stuck in another meeting” or “I’m stuck in this kickoff meeting.”

So I think that’s the first thing is knowing what some of the things that you’re trying to get out of a kickoff meeting are. Whether it’s problem exploration or consensus or problem definition, and then knowing what the best ways to design human interaction to get at those things are and suggesting them when you need to. The second thing I would say is if you’re a participant and you’re not a leader, you have the right to demand agendas and demand clear agendas.

And if it’s not clear enough or it doesn’t address what you need it to address, you have the right to suggest agendas and say, “I need this item added to this meeting.” Now, inevitably what that leads to more meetings and I realize that. But at the same time if you don’t suggest it you’re really spending just as much time not doing the work that you need to do and not getting the things addressed that you need addressed in order to move forward.

So, you know, I would say sometimes it’s OK to have more meetings or an additional followup meeting for a kickoff meeting as long as you’re getting stuff addressed the way it needs to be addressed. An example of that would be the way normally in which high detailed technical discussions happen with our kickoff meetings. We like to have our developers and our technical experts at our full kickoff meetings which is an expense.

It’s a real expense to have a developer in a room for eight hours focusing on UI and project strategy. But then if we can take someone who’s got that level of knowledge or has been a part of that discussion and then immediately afterwards put them in a smaller discussion that focuses on server architecture and CMS choices and other highly technical issues, our projects have a lot more of singular vision.

And in the future when I’m doing IA work or UI work and I say to a developer, “You know, this is how we need press releases to function and this is how date search works.” Not only do I know the technical things that they have thought about in advance, what systems and what limitations of those systems are, but also they know why it’s important. And that makes that kind of gap that sometimes happens between concept and production much, much smaller.

Jared: Plus they can come back and actually suggest things up that you may have not thought of.

Kevin: Exactly. And that happens a lot with us.

Jared: It feels like that these meetings are very productive and that to some extent there’s this kickoff workshop but it’s just the start of something that goes on for a while. And they’re mini little workshops that happen throughout the project that feed off of that and keep going, right?

Kevin: Yeah. Absolutely. With our larger clients we actually have kickoff by phase. So we have project kickoff, we have IA kickoff, we have visual design kickoff, and we have development kickoff. And we tailor those meeting attendee lists directly towards the amount of cohesion we detect at that point.

So a lot of times our development kickoffs if we know there’s an internal development team, we’ll just invite them to our offices and really go through every single design page by page and say how would we code this? You know? And collaboratively sketch out how the line by line code is going to fall into place. Now I don’t attend all of those meetings. I attend some of them when I can but it’s the same workshop methodology applied to coding and we apply it to visual design and Brand and we apply it to IA but it works at all levels of the project.

Jared: So in essence here what we’re talking about is developing just a great set of facilitation skills and tricks that let you make a group of people in the room be really productive in terms of moving the project forward and getting everybody’s sort of, point of view into the design and the designs direction into the folks.

Kevin: Yeah. Exactly.

Jared: That sounds incredibly useful. Well this has been really, really interesting and I can’t wait for your workshop which is going to be at the User Interface 16 Conference in November in Boston. To our audience if you’re interested in attending that you can get more information on Kevin’s workshop at the UI16 conference site which is cleverly called UI Conf, U-I-C-O-N-F.com. I highly recommend you check that out. Kevin thank you so much for taking time to talk with me today about this.

Kevin: It was my pleasure.

Jared: Excellent. And I want to thank our audience for listening once again and as always I want to thank them for encouraging our behavior. Take care and we’ll talk to you in another Spoolcast.

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.

The introduction of CSS3 and HTML5 brings with it a host of new capabilities. With most modern browsers supporting CSS3 and HTML5, implementing them into your designs is becoming easier. Understanding what is now possible with these new standards can help you create better designs more efficiently and effectively than ever before.

Stephanie Sullivan Rewis and Greg Rewis will be presenting a full day workshop at the User Interface 16 Conference November 7-9 in Boston. They’ll dive into what the introduction of HTML5 and CSS3 means for designers and developers, and what you can accomplish today by putting it into practice.

Here’s an excerpt from the podcast.

“…We’re talking about these capabilities like the drop shadow or the text shadow that up until now have required a designer to go into Photoshop, do it all, export that as a JPG or a transparent PNG or, God forbid, a transparent GIF then hand it off to a developer to implement into the design.

While that’s worked for us perfectly for 15-16 years of web development, the issue is if we all lived in the perfect world where the client said this is what I want. I want it in this size, this is the wording, I will never change it, I promise to never change my mind. Then we wouldn’t even be having this discussion. But as every designer knows, that’s a utopia we’re never going to achieve because clients always change their mind. They always want to tweak

On the viewer’s side, this is an image with no SEO benefit since there’s no selectable text. So if we can create this image using CSS and HTML, then we have it appear correctly and still get SEO benefit from it since it is text.

Not only can we make a change by simply going into a text editor and correcting the spelling, but we also can go into that same text editor and make a few changes to the CSS and completely change or update the look of the design as it’s presented in the browser…”

Tune into the podcast to hear Stephanie and Greg address these points:

• What can designers take advantage of today with these new CSS3/HTML5 standards?
• How have CSS3 media queries changed designing for multiple platforms?
• How does a tool like Modernizr work?
• How do CSS3 and HTML5 help with Accessibility?
• What do designers need to know so their design gets coded as intended?

Do you have experience with CSS3 and HTML5? Share your thoughts in our comments section.

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

Full Transcript.

Jared Spool: Welcome everyone to another episode of the SpoolCast. I have with me today Stephanie Sullivan Rewis and Greg Rewis who are going to be delivering a fabulous workshop at the User Interface 16 conference in Boston.

They’re going to be delivering the workshop on Everything a Designer Needs to Know About CSS3 and HTML5. Hey there Greg and Stephanie. How are you doing today?

Stephanie Sullivan Rewis: Good. Hey Jared.

Greg Rewis: Doing great, Jared.

Jared: So I’m really excited about this workshop and I really wanted you guys on the program this year because what I’m seeing, and you can tell me if you’re seeing the same thing, is that the new changes that are coming down with HTML5 and CSS3, the browsers are finally getting to a point where they’re adopting these things.

So you can actually do much of it, though not all of what’s in the specifications, and because of that there’s all this new power and capabilities and there are all these things that you used to be able to do that you can’t do anymore.

All these things have changed and I think it really behooves a good designer to understand what this is all about so they can talk intelligently with the developers they work with and understand the capabilities and design for them. Is that what you guys are seeing too?

Greg: Absolutely. I think that there’s a lot changing and I think, even more importantly, there’s a lot of confusion out there about what’s changing, you know, what can we do, what can’t we do.

Sort of exactly as you pointed out that we hear a lot in terms of the buzz of HTML5 but then when you dive into it you then you start running into the, “oh, but you can’t do that yet, oh you can’t do that yet, or yes you can do that but only on a Thursday wearing a red shirt.”

You know? So I think that’s probably one of the biggest challenges for designers is trying to cut through the marketing of HTML5, if you will, and actually start seeing both the forest for the trees and the trees within the forest I think, to use some really weird hobbled together analogy.

Steph’s looking at me right now going what? Forest with trees?

Stephanie: No, I got it. I got it. I think, like Greg is saying, you know, HTMl5 does not include CSS3 but the marketing for the new Web 2.0 HTML5 certainly makes you believe everything is under the HTML5 umbrella.

And of course we’ll be talking about all that but CSS3 is a completely different specification and is probably more interesting to designers even than HTML5 itself.

CSS3 is going to give us, or is already giving us, amazing new capabilities for more flexible design, more succinct, light weight design which is always better for SEO and accessibility and things like that.

Greg: And rounded corners.

Stephanie: And drop shadows for everything.

Jared: Oh good. I can put my drop shadow cream away. I store it in my medicine cabinet right next to the make your logo bigger cream.

So along with drop shadows and rounded corners help me understand. So what are some of the things designers could take advantage of today because the browsers are supporting them that come with these new standards?

Greg: I think there you go. Rounded corners. Jared, I mean, once we have rounded corners the world is a utopia, right?

Jared: It absolutely is. It is. I think the whole reason the debt ceiling is having problems is because every chart that they show us has square corners.

Greg: That’s true.

Stephanie: Oh my gosh. We could solve so much.

Jared: Exactly.

Greg: There is certainly, obviously, rounded corners, drop shadows, the text shadow. Those things are obviously going to add in some interesting capabilities, if you will, for designers.

And you know, I’m sure a designer might even, at this moment, be thinking well wait a second, I can do that today. I go into Photoshop, I make a box, and I put a rounded corner on it or I write some text and I put a drop shadow on it.

Sure you do but that’s exactly the problem. You’re in Photoshop and you’re not in a browser. One of the truly, sort of, exciting things for these new CSS3 capabilities is the idea of tearing down the need for images themselves. Now, before the designers go running for the door going oh my God we’re going to have a web without pictures.

That’s not what we’re talking about. We’re talking about these capabilities like the drop shadow or like the text shadow that up until now have required a designer to go into Photoshop, do it all, export that as a JPG or a transparent PNG or, God forbid, a transparent GIF and hand it off to a developer to implement into the design.

While that’s worked for us perfectly for going on 15 years of web development or 16 years, whatever it’s been, the issue is, as any designer out there can relate to, if we all lived in the perfect world where the client said this is what I want. I want it in this size, this is the wording, I will never change it. I promise to never change my mind. Then we wouldn’t even be having this discussion but as every designer knows that’s a utopia we’re never going to achieve because clients always change their mind, always want to tweak.

And in that work load that we’ve had established for these last 15 years that means the designer has to get involved again, even if it’s just, “oh my God I misspelled the boss’s name in the graphic.”

The designer has to go back in, go through the Photoshop, Fireworks, whatever, Illustrator reader, whatever program they’re using, workflow, to re-output that image. Then on the flipside you go OK that’s great. I have time to do that.

I want to do that. On the other side, on the viewer’s side, this is an image. This is not selectable text, for example.

That means I’m not getting any SEO benefit out of the text that’s baked into the pixels of that image. So if we can do things in pure HTML, in the markup of the page, and CSS to give us that creative expression of the drop shadow or whatever it happens to be then we’re benefiting on two sides.

Not only can we make a change by simply going into a text editor and correcting the spelling but we also can go into that same text editor and make a few changes to the CSS and completely change or update the look of the design as it’s presented in the browser.

Stephanie: Right. They may want a green background instead of a blue one or a green gradient. We can do real gradients now with CSS3. Or they decide they want a different font style. We can do real fonts on the web now. Actual web fonts, not the boring Georgia and Verdana and Arial and the things we’re so sick of at this point.

Greg: I’m not sick of Arial. I love Arial.

Stephanie: Yeah, The Little Mermaid. We can actually use real fonts that have licensing that allows us to use them on the web and we’ll talk about that a little more. And change everything from the gradient, the amount of rounding on the corners, or drop shadows, or background colors and fonts all without ever entering a text editor again and that’s a lot of power.

Because everybody knows, like Greg said, clients invariably or bosses invariably change their mind. We’ve also got some amazing things we can do with opacity and RGBA.

Greg: And we can even combine it all by laying it all on top of each other by using multiple backgrounds and things like that that’s really, really exciting as well.

Stephanie: Lots of changes in the backgrounds and borders module. We can do border images. Then, if you really want to get crazy, you can start rotating things and making them move and animating them all with CSS.

Greg: And you should.

Stephanie: No, now I like to say just because you can doesn’t mean you should.

Greg: But I do.

Stephanie: However, Greg likes to do those things.

Jared: Greg has always been a sort of MySpace kind of guy.

Stephanie: Yeah. There will be gratuitous movement when Greg does his portion of the session.

Greg: Every attendee will go out with the knowledge of which one of us actually has a design sense and the answer is not the male part of this partnership.

Jared: So it feels to me like there’s really a lot of really important things in terms of these standards but there are also just a lot of capabilities. You know, some of the stuff that I’ve seen people doing with like drop shadows it takes me a second to look at that and say “Oh wow that’s a really cool effect.”

I’ve seen really neat sort of 3D effects and stuff that was all done by just changing a couple of simple attributes.

Greg: That is one of those areas where you call it out. We’re really on the cutting edge. In terms of, even though I realize that in the specification it does say 3D, I sort of have a beef with them calling it 3D because 3D, for me, is coming out of a 3D program. You know, I’m seeing an Avatar style model and it’s really not that.

It’s more what I like to call “postcards in space”. It’s a two and a half D. I can turn the post card over and see the back side and have something actually on the back side and that is really, really exciting and starting to be embraced by some of the browsers, specifically if you’re in the mobile arena, developing for the IOS or Android platforms.

It’s there. It’s available right now and we can start using that. You’re right, that’s truly amazing when you start thinking about hey wow, that’s not even necessarily a graphic that was exported out of Photoshop but rather is all done live, if you will, rendered by the browser, out of text really.

Stephanie: Greg brings up a good point and that is the point about mobile because many designers are now being pushed to go ahead. And a lot of them, I think, started with print then they get pushed into well now you need to design for the web and now it’s being pushed forward to and let’s add mobile into that or maybe even designing for the TV.

Designing for a lot of different sized screens and experiences. And the interesting thing about mobile is we do have a lot of web kit based browsers there and web kit, in many ways, has some really interesting properties that are web kit only like masking. Masking is you know, a way… it’s just like in Photoshop or Illustrator when you apply a mask and only show a portion of it.

We can do that in web kit browsers now. And mobile, you know, Android and IOS, having so many web kit based browsers, that’s a real bandwidth saver and technique that we can use, or designers can use, right now for those devices.

So there’s a lot of really interesting advanced features in the mobile space that we can actually use today.

Greg: I think if you were to sort of be coming at it in a newbie today I’d almost say it’d be more exciting to head in that direction than on the desktop browser because of the excitement going on in the mobile space.

The best news of it all is we can actually design, one of the other great new capabilities of CSS3 is something called a media query that allows us actually to design for both at the same time and have a responsive response, if you will, to the device that the page is being rendered on or shown on so we can move from the desktop through the tablet space down to the mobile phone in your pocket space all with the same content being adapted through the CSS.

That makes it even more exciting, I think.

Jared: So let me understand the media query thing. So previously, before HTMl5 and CSS3 and many of the servers, you had to do some sort of device detect and then you’d send your phone pages, off your small screens, off to an M dot page which would then have a completely different design and then if you made changes on the site you had to change them in both places simultaneously. But now…

Greg: You were basically maintaining two different versions of the same site.

Jared: Right, right, which had all the implications of that. But now with these media queries I can actually tailor CSS to the different devices.

So I only have one design. It’s semantically marked up and then the CSS decides well if I’m looking at this on this device then I show it this way and if I look at it on this other device I show it that way.

Stephanie: Right. And for the most part that is a good way for many sites to handle.

It’s not to say there won’t be any M dots. There are times where it’s still appropriate to have a completely mobile site but many sites would benefit from the one web approach which I like a lot, the put your content up and then show it in different ways to devices with different capabilities and sizes and resolutions.

Greg: In our session we’ll actually be talking about that because one of the topics that we’ll cover is exactly that, is how do you approach designing for the different style screens and Steph will begin a very, very long explanation about her love affair with something called Modernizr.

Jared: Talk to me about Modernizr because people keep talking about this and I don’t know what it is.

Stephanie: I adore Modernizr.

Greg: See? I told you.

Stephanie: Everything that I’m building right now… Because I am a front end developer and everything I am building right now uses HTML5 or CSS3 to some extent or another depending on, clearly, the client’s browser specs and such. It depends on how far I can take it but I’ve got a couple that are just full bore.

But either way I use Modernizr. I’m very against browser sniffing which means using JavaScript to try to figure out using the UI string or whatever, you know, what browser is this and what should I serve it?

The problem with that is people don’t keep it up and so new browsers are literally coming out every week and sometimes what happens is they’ve got something that your browser sniffing string doesn’t understand and so it kicks the user back to some old, crappy version of the site, if you will, and not the most modern, capable version.

So there are a lot of reasons I don’t like sniffing but hat’s one of the main ones. Modernizr is a JavaScript library. It’s very small. The reason I love it is it checks for the capabilities. It doesn’t sniff for you know, “what user agent is this?” It says, “what is this user agent capable of?” And it’s very simple to use.

It requires a simple class on the HTML element and then you include the JavaScript. What it does is when the user surfs to your site they hit the site, Modernizr tests their browser very quickly and gives you back a whole string of classes on your HTML element.

That will tell you, it’ll say like multiple backgrounds, no CSS transform, and just goes through all the HTML5 and CSS3 new properties and capabilities and gives you feedback on what you can and can’t serve to this browser.

Then you can choose to either progressively enhance and serve something different. Say a browser doesn’t do border image. OK, great. Now I know that. Well then I’m going to write a class using no border image as the first piece of that selector to feed it a plain border image, something more simple.

But the more modern browser that does border image now gets the beautiful experience that is enhanced and then you can also find through JavaScript or serve through JavaScript different scripts to, what I like to call, regressively enhance meaning OK maybe it doesn’t matter if this older browser gets rounded borders and we’re going to leave that one square but it does matter that they can’t do local storage.

So I need to serve a JavaScript that’s going to store that in cookies or something like that.

Then I can store a script loader that says oh there’s no local storage available therefore I’m going to serve this JavaScript only to the older browser. It just gives you a super, fine tuning ability to not throw all the scripts and things you need for your site onto modern browsers that don’t need them.

So the better the browser the better their experience and older browsers can have an enhanced experience with JavaScript or extra CSS or whatever you need to do. I absolutely love it. It’s super powerful.

Greg: Told you.

Jared: This sounds really cool. Now, can this also help me with making sure that the stuff I’m producing is as accessible as it can be?

Stephanie: Yes. It definitely can help with that in that part of accessibility is making sure that everyone can see it. You don’t want to do a CSS3 technique that causes your people not to be able to see things.

Let’s say you have a gradient and some text on it or you’re using a technique that without the technique the text may not be very visible on the background.

If you know that technique is not possible you can feed that browser a nice, high contrast background where something might be missing for them, say a lovely subtle gradient.

Greg: The idea we talked about earlier with a text shadow. Very often you’ll use a text shadow to pull the text out of the background to give it that stand out readability, if you will and if my browser doesn’t have that text shadow capability the text falls into the background and becomes less readable.

So that, you know, that would be one of those situations where I would want to use Modernizr to perhaps swap out that background or in some way…

Stephanie: Change the color of the text.

Greg: Yeah, change the color of the text or whatever that might be to pull that out. So very definitely just from those visual style of techniques but speaking just from just general accessibility that’s one of the other exciting things that it doesn’t get a lot of play, if you will.

It’s not the sexiest of topics to talk about when we do talk about accessibility but it is a very important thing to consider throughout the designs.

As a designer who is approaching a project how do I need to be thinking in order to provide a design that can become accessible in terms of when it becomes code, if you will.

Stephanie: And accessible doesn’t mean… You know, a lot of people think about it as “Oh that means my page works for non-sighted viewers, for blind viewers.” That is not the only thing accessible means. Accessible also means the person with carpal tunnel that needs to tab through your page is able to access all the content and links or the person with low vision, hi that might be me.

Once you’re over 40 let’s face it. We all get lower vision as time goes on. If text size increases, and I’m a big stickler for this, if text sizes are increased by the user you need to make sure your design doesn’t fall apart.

I had a site that I showed in a talk I did yesterday that I built for somebody last month. Really cute design, very whimsical, very beautiful, well designed, very graphical.

And on the home page of her site her navigation, which was real fonts using font face, is all on these little, like, garden vegetable bins that look like they’re sitting on a little…

Greg: Little signs that you see in the gardens.

Stephanie: Yeah, little signs and there’s a bin of corn ad a bin of tomatoes and they have little signs and that happens to be her navigation.

Well, what happens when the person surfs into your site with say 32 pixel base font instead of 16 pixel base font, which is the default, that means they now have giant text on your site and all the cute stuff on the vegetable bins is now blown out all over the page because the vegetable bins are still sitting there.

Well, the beauty of some of our new CSS3 techniques are we have something new called background size and I was actually able to make that page fit the text no matter what size that user is surfing with on their text using a background sizing technique that makes the whole page basically zoom to the size of the text just like a browser would do.

If you hit to increase the text size many browsers will now zoom but if somebody comes into your site with larger text already they don’t zoom and so there are some very simple CSS3 techniques that if you think about it will make your site work and be more flexible and more accessible to all users.

Greg: I think that’s one of the really exciting things right now, Jared, is that you know, because this is all so new you tend to look at a technique or at a specification and you go, “oh, OK, well that’s how we’re going to use this.”

But, the really cool part is because it’s so new we haven’t explored all the different ways to use this and a lot of this is just sort of, you know, creative exploration where you suddenly go, “wow. Hey, wait a second. What if?” and “Can I use this?”

Another simple example that I’ve seen Steph use is using a drop shadow to become a border. You go wait, how can a drop shadow be a border? But you know, there’s some really interesting things you can do with that to even overcome some of the limitations of CSS3 because oh yes there are limitations too.

Stephanie: We have no ability to do multiple borders.

Greg: Yeah, exactly. Something as simple as hey we’ve got multiple backgrounds but we don’t have multiple borders but there’s some really neat tricks that we’ll be talking about in our session on how to overcome those limitations and sort of creatively use some of the new capabilities to do that to give the illusion of what you’re trying to achieve even though you actually did it without doing what you thought it were doing, as it were in the case of a multiple border.

I think that’s one of the really exciting things because this is all so new that we’re seeing a lot of experimentation going on and we’re hopefully going to share with the attendees some of the experimentations that we’ve been doing and the successes that we’ve had with those.

Jared: Yeah I mean, it feels to me like the new specifications give us some really interesting building blocks.

I remember when I was a kid I got my first Lego set and it had just square blocks and the occasional curved thing but it didn’t have all those weird shaped unusual pieces that you get in the Lego set today which all of a sudden gives you this capability to build things you couldn’t build before.

Greg: In other words, your Star Wars Death Star was just a cube?

Jared: It was a cube. It looked a lot like my basic fortress and my GI Joe’s bunker house.

Stephanie: Your castle.

Greg: Exactly.

Stephanie: Right. Exactly. One of the beauties is really experimenting with each site that I build. And sometimes Greg, he will be looking over my shoulder or he’ll be helping me.

I always like to get him to do my JavaScript. He’ll be doing something and he’ll go, “hey, what if you did this?” And then I go, “Oooh.” Then I’ll try something new that I never would have thought of before.

So we kind of feed off of each other. What if you could do this? What if you could do that? So it is kind of an exciting time.

Greg: Except her part of feeding is, “Greg, don’t rotate it that much. Don’t make that move.”

Stephanie: Greg, that doesn’t need to go out of its boundaries just because it can. But seriously you know, it is really fun because there is so much that we’re figuring out.

They give us the spec but it’s up to us to put it through its paces and figure out all the cool things we can actually do with it that are super practical and that really give us flexibility in our designs and, like I’ll say over and over, real text which is so great for real search engine spiders and people needing to use assistive technology.

Jared: So one of the things that you and I talked about when you were explaining to me this session was that there are things that designers can do that make the coder’s life easier and there are things they can do that makes the coders life hell. So the person that’s actually taking the design and translating that into what the browser’s going to see.

And you’re going to talk a little bit during your session about what a good designer needs to know in order to make sure that the design they give to the developer is easy enough to code up that it actually gets implemented the way they want it implemented instead of, you know, reinterpreted.

Greg: That section is going to be called “How A Designer Can Increase Their Lifespan” or “How To Shorten It Very Quickly”.

Jared: So what are some of these things that can get us into trouble if we’re not paying attention?

Stephanie: Well, I basically do work for a lot of different agencies so I work with a lot of different designers. I don’t design myself. And many times, or I should say most of the time…

Greg: Well you don’t design anymore.

Stephanie: I did.

Greg: Because you are a tweak-aholic.

Stephanie: I’m a horrible tweak-aholic and so I find it much more cost effective to pay someone to do the design to get what I want rather than try to do it myself. And you know, there are much better designers than I am, and I learned that early on. I work with a lot of different designers, whether I’m hiring them or I’m being hired by the designers.

And usually, that means I’m getting a PSD. Many, many, most designers work in Photoshop even though I wish they would work in Fireworks. And so Photoshop there are different ways that effects can be created using masks or smart objects or what’s the little drop-down? It’s called effects. Greg, I’m looking at Greg because he knows the Photoshop lingo so much better than me.

Anyway, there are ways to add effects to an object in Photoshop. There are ways to keep it more editable, and one of my biggest complaints is that now we can do real gradients on the web, there is a way that a gradient can be created so that it’s still actually a gradient.

I can open it, and I can see what color did this gradient start and end on, and what color are the stops in this gradient, and what percentage of the gradient did this stop get put on?

There are other ways that gradients can be made where they’re just created as an effect and a bit map, and I have to sample, sample, sample the little bits and try to figure out how to recreate this gradient as code.

And these are the days where Greg probably likes to be in a different office than me because I’m just ready to throw things through the window after awhile.

And so, there are ways to make your coder’s life more simple in the way that you create things, and another one is…

Greg: Can I mention something?

Stephanie: I don’t know if I should let you. Keep it kosher.

Greg: I’m thinking consistency.

Stephanie: Ah, yes, there’s one. I just finished or I’m finishing right now the most beautiful design from a very well respected agency that I was very excited to start on for a startup. Because in my mind there was this assumption that this meant we would have grids and well spaced and thoughtout things, and a certain number of colors of grey text, and a certain consistency to the rounded borders that are everywhere and in their color and size and blah, blah, blah.

What happened was not at all. I have like 18 colors of grey text with a variety of sizes. I have 38… No, no, as of yesterday 39 different gradients that I have had to export because none of them are ever quite the same enough to re-use, and my client has an eagle eye and notices if I don’t use the exact gradient that the designer put.

They’re all shades of gray, essentially, except for a couple.

So, consistency, reusability is really good for your design.

Greg: Another thing that we’re talking about when we talk about screens is how to create certain design elements that can grow or shrink based upon the content that’s going to be poured into them because as designers one of the things that very typically happens is the Lorem Ipsum syndrome.

You’re working with dead text, a dead language, if you will. You’re not working with the real content that’s going to be poured into this design.

Stephanie: And you can make sure that it fits just perfectly.

Greg: Right. All those three boxes that sit side by side on the page are all exactly the same height because you use the same three Lorem Ipsum paragraphs to fit into them.

And so, one of these things that we try to get across to designers is you need to begin to think in terms of that flexibility that the web is built upon. That this is not a magazine design, that I can nail everything down, cut it all out with scissors and paste it up because it’s never going to grow.

This is one of the hardest things, I think, for designers to get their head around, and they still go, OK, but I still want three boxes of equal height right here.

Well we’ll tell them, you can have that, but you’re going to have to give us some reusable elements. It might only be three pixels, please give us more, but it might only be three pixels of vertical color that is the same that we then can use to allow to grow and repeat, you know, in order to adjust for that varying content.

It’s these things that we’re going to try to call out and show through some of Steph’s painful experiences. What went wrong in this design, and how might it have been created to have been much more flexible, much easier to implement from a front end developer’s perspective.

Stephanie: And that only helps the designer because I know how I am about my code. When I hand code off for someone to build a site with it…

Greg: It not only helps the designer.

Stephanie: Right. When I hand my code off to the back end team that’s going to implement the CMS or whomever is going to build the actual site from it, that’s my baby.

I mean, I really want that code to keep its integrity and to stay beautiful and to not get cluttered up, and designers feel the same way about their design. They did things they did for a reason, and they want it implemented.

When they see it on the web, they want it to look like their design. There are things they can do to help assure that that is exactly what happens because I don’t blame them at all. I feel the same way.

Jared: Yeah, no, it makes perfect sense to me, this whole idea that when you have those translations that happen because the way that they designed it doesn’t translate nicely into the code language that you have to put it in.

Then, there’s interpretation, and that interpretation is very likely to change the underlying meaning and intention of the design, and that’s just going to break what the designer wanted to do.

It’s funny we’ve been doing work, the new UI16 website’s being designed by Dave Shea, and I’ve been teasing him about… He’s a fabulous designer, but his mind reading skills really suck. He says, yeah, I keep working on it. He says, I try my hardest. I said, yeah, but…

Stephanie: Actually, I saw that yesterday when you tweeted something, and it looks beautiful.

Jared: Yeah, the site has been great to work with, but there are exactly those things. He’ll come back with some stuff, and we’ve been working with a guy named Marc Amos of Boston Design Studio. He’s coding up Dave Shea’s stuff, and Dave does a fabulous job of handing off.

Few people know CSS like Dave does, so you know, the stuff he hands off comes very close, but there is interpretation that happens. When we get the real copy in there, when things shift around, there is all this sort of translation has to happen, and there’s conversation that has to go back and forth. The way you hand it off really makes a huge difference.

Greg: And the problem is earlier in the work flow that the issue, if you will, is created the more it’s going to snowball even down to the point of certain experiences where Steph handed the code off, and then only to find out that the CSM was not even capable of handling the code that she handed off.

And so, it was one of those things had that been clarified early on in the process, completely different approaches could have been taken.

And so I think, you know, if you really boil it down, in a lot of projects the design is that initial piece. So if we can catch that early on and the designer is creating that integrity early on that is going to, you know, allow itself to be maintained throughout the entire flow process, flow through the tearing it apart, putting it back together in code, and then dumping it into a server or CMS.

If the design integrity is good initially, then it’s going to help avoid all those problems or potential problems downstream.

Stephanie: And one thing that I do when I work with designers and I’m building a site is I look at their beautiful designs and then as I’m breaking an element down to build their component of it, I think, OK, what happens if, let’s say, there’s a name across the top of the little address box.

Well, what happens if that’s a hyphenated really long name, or what happens when this heading wraps to two lines?

I go back to them and I say, what would you expect to happen? What would you expect to see if this happened? Many times their answer is, oh, I didn’t think of that.

Jared: Right.

Stephanie: Well, I hope you could do this because there are so many different ways we can build things. There’s no one true way. So, this is one thing designers need to think about as they’re building their comps is push themselves to put extra text in one box over the other one, put a longer heading somewhere and think through, now what would I like to happen.

The quicker they can transfer that knowledge to the person, the front end developer building, the more solid their design will be in the end because they’re going to have to hand off.

Let’s say they’re building a flexible design, and there’s an image or here’s the one I love. I see this all the time, the pattern of design where you have an image and next to it, and it’s in a box, and next to it in the same box is some text which is the same height as the image. This is a very common design pattern. What happens when there is much more text?

Greg: Or much less.

Stephanie: Right. Much less is a little less of a problem because the image will hold that box open. The bigger problem comes when there’s more text. And now, either the text is going to run out of the box or the text is going to push the box open taller. Now, your image is sitting there looking all cut off hanging in mid-air.

One of the little tricks that designers can do is don’t crop your image the exact size of that box. Give me an image that’s maybe twice the size of the box with the portion that you wish to be shown the height that you show, say, it’s the top portion or it’s the bottom portion.

Maybe, it’s the bottom portion, but you can give me a bunch of sky, you know, extra sky so that if the box grows, the sky shows a little more, or maybe it’s the center of that image, but it can grow on the top and bottom.

I, as a developer, can then situate that image in the box, either centered or the top or the bottom, but there is something more to show so that your design doesn’t break apart. Little tricks like that are super important, especially with imagery for designers to hand us not just cropped exactly what they wish to be seen.

Jared: Right. That makes perfect sense. So, it sounds to me that if I’m a designer and I get my head around how the development process works, what you guys are doing, taking the designs that I’m putting together and translating that, knowing what the capabilities are like CSS3 and HTML5 so that you can take advantage of those capabilities. But also understanding where the design needs to have that sort of flexibility.

Then, that gives me the advantage of making sure my intention is there. It might buy me a little bit more design time because the development time will be cut shorter, and it will just also improve the overall quality of the results, especially in those weird edge conditions.

Stephanie: Right. Absolutely.

Jared: Cool. Well, this has been really fun. I’m really looking forward to the workshop. For those of you who are thinking of coming to Stephanie and Greg’s workshop, it’s going to be November 7th through 9th in Boston at the User Interface 16 Conference.

And you can get more information on that at uiconf.com which is a site that has a lot of great resources on it, and we are very excited about the conference that’s coming up.

This is your first time speaking at the UI16 Conference. We’re really happy that you will be part of it this year.

Greg: You did assure us that Boston will be warm in November, right?

Jared: Oh, it’s going to be awesome. [laughter] You know, this climate change thing has some advantages.

Stephanie: Well, we live in Phoenix, so we’ll be expecting something really lovely.

Jared: Yes, it’s going to be a dry cold. [laughter]

Stephanie: Exactly.

Jared: Oh, November, it’s usually not too bad. Last year we had a bit of rain, but most of the time… The snow doesn’t start until later, so we probably won’t have any snow but you might want to bring your skiing jacket, I’m just thinking.

Stephanie: Excellent.

Greg: I’m glad you didn’t say winter clothes because that just would have been jeans for us.

Jared: That’s probably not it. It’s going to be great to have you. Thank you so much for taking this time to talk to me today about all this.

Stephanie: Thanks for having us, Jared.

Greg: Thank you, Jared.

Jared: I want to thank our audience for listening and, of course, I want to thank them for encouraging our behavior. So, until next time SpoolCast, take care. Thank you.

This is your opportunity to hear all 12 Masters from the Tour give their 75-minute presentations. The OnDemand collection consists of 15 hours of audio recordings, Q&A from the audience, and the Masters presentation decks. It’s a toolkit that you can share with everyone in your office. You can access it any time you want, as often as you want.

Web App Masters OnDemand covers these topics

• Constructing sites for active communities
• Building native device vs. mobile browser-based applications
• Producing beautiful data visualizations
• Using data for design decisions
• Integrating infographics and games to engage your users
• Designing for mobile first
• Handling rich interaction techniques on multiple devices & platforms
• Looking at AARP’s journey into web-based applications
• Conducting successful kickoff meetings
• Finding users’ deepest needs and desires
• Designing Salesforce.com’s Cloud Apps
• Creating great design principles for your team
• Ensuring a positive user experience with mobile

Learn more about Web App Masters OnDemand.

With Web App Masters 2011 OnDemand you’ll get

• Fifteen hours of audio from 12 Masters
• The best of the Q&A from all the tour stops
• Presentation slides from all 12 talks
• Unlimited access to the material any time you want it, as often as you want it

Order Web App Masters 2011 OnDemand now

No pre-ordering and no waiting for a disc. With just a few clicks, you can have Web App Masters OnDemand at your fingertips and start to improve your web apps today.

Purchase Web App Masters OnDemand by August 30, 2011, for $179. After the 30th, the price
increases to $229.

Now go get your bundle of goodness.

Combining storytelling with research data can help you craft realistic scenarios to guide your design process. Getting to know the specific needs of your users allows you to address any potential problems they may have. As a consultant, Kim Goodwin uses her experience and expertise in working with teams to develop effective scenarios. In this podcast, Kim discusses the role that scenarios play in the design process with Jared Spool.

Kim will be part of the User Interface 16 Conference November 7-9 in Boston, MA. She will present a full-day workshop on using scenarios, helping to focus and prioritize. Find out more details about the conference at UIConf.com.

Here’s an excerpt from the podcast.

“…The thing is, a story has a character, somebody with skills, and goals, and feelings, and other real human characteristics. User stories employ roles which are real abstractions of users. A story has a plot, it has a beginning and an end. It has something that starts off the action and some logical conclusion that’s a satisfying ending to the story.

Whereas, user stories are just like… Use cases or scenarios, they’re sequential thinking, which is good. That’s a helpful way to approach interaction because it always happens over time. But they’re often fragments of complete stories…”

Tune in to the podcast to hear Kim cover these points:

• How do you help people start to use personas and scenarios?
• Is it good to use abstract scenarios in conjunction with more specific ones?
• Where do the scenarios come from?
• How important of a skill is storytelling when developing scenarios?
• Have you experimented with breaking teams in to smaller groups in the scenario creation process?
• What are some techniques you’ve used with teams to collect data?
• How do scenarios compare to user stories?

Do you design with scenarios? Share your thoughts in our comments section.

Recorded: July, 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 happy today because I have a chance to talk to my good old friend, Kim Goodwin, who has presented at more of our events, I think, than anybody else on the planet. And she wrote a fabulous book called “Designing for the Digital Age.” She’s going to be presenting at our upcoming User Interface conference, User Interface 16. Kim, can you believe it’s the 16th year?

Kim Goodwin: I know, that’s crazy. I’ve lost count of how many of these things I’ve done.

Jared: I know, I know. It’s really insane. So at User Interface 16, you’re going to be talking about really pulling the value out of using scenarios. Once you have your personas and your scenarios, how do you really get the value out of them? I’m really excited about this workshop because I think scenarios are the sort of untapped treasure that we as designers don’t really use enough.

I try and use them all the time, and I still don’t think I use them enough, because they really do have an effect on every aspect of the design, from the first moment you start to talk about what the hell you’re going to build, all the way through the deployment process. Do you find that to be true, that there’s use everywhere?

Kim: Pretty much. I mean, certainly, if you have a hammer, everything looks like a nail. But I think that scenarios are my go-to design tool. I think if I had to give up every other tool in my kit, I could still get an awful lot done with scenarios.

Jared: Yeah. Now, you and I were talking, and you referenced this great quote of Plato’s, which was, “Those who tell the stories rule society,” which is just brilliant. And of course, the society that many of us live in is our work society. I think that the personas that we create and the scenarios that we use to describe those persona situations are really a great way to get control of a product that possibly has gone astray in other ways. How do you help people start to use personas to bring their design conversations around to what they need to build really great stuff?

Kim: I think there are two ways, fundamentally, that personas and the scenarios they star in really help to drive that conversation. One is that scenarios help you develop and articulate your vision. I think that Plato says, “The people who tell the stories rule society” because… Think about all the great leaders that you’ve heard of in our time. Right?

Martin Luther King didn’t stand up there and say, “Hey, you guys aren’t including us, and civil rights are not what they should be.” He said, instead, “I have a dream.” And he painted a vision, and I think that’s what made him an inspiring leader.

And so, we want to do the same thing in design. We want to inspire people and say, not, “Here’s how all the usability is bad, and you should include design more, whine, whine, whine,” but instead, say, “Look, guys, here’s where we want to go. Wouldn’t that be great if we could build that and really get everyone behind it?”

So I think that’s one part of the story. The other is that, when people start to talk about doing this or that with the product or this or that feature, you can challenge other people on the team to use scenarios so that everybody’s using a shared reference point and speaking the same language. And it gives everybody a shared framework for making good decisions.

Jared: There’s a lot in common with both the points, this idea of a shared reference point and this idea of a vision. Right? Because what I’ve been helping teams with is giving them this idea that one way to construct your vision is really to just understand what the stories are for today’s experiences. What is it like to be a user today? And then, if you got rid of all the nasty, ugly, frustrating bits, what would that experience turn into? How would it change?

And so, there you’ve got, basically, one scenario, one in the dark, dismal, frustrating world of today’s experience, and one in the golden, blue-sky, flower-and-field version of the future where everything just goes smoothly and perfectly.

And so, at one level you have an abstract scenario that would cover both things fairly accurately. And then, you can use those scenarios to dive deep and say, “OK, what changes when it’s frustrating and people have to compensate for that frustration? And what is different when we’ve gotten rid of that frustration, and now they’re getting delighted by everything, and how does that change what they do?”

That distinction, being able to shift from that higher-level, abstract notion down to more specifics, depending on whether you’re in today’s world or a future world, is that something you find yourself doing?

Kim: Actually, not at all.

Jared: Oh, OK.

[laughter]

Kim: I find that part of what works about scenarios is that they’re not abstract.

Jared: OK.

Kim: They’re fairly concrete. They give people handles to grab onto. And I think there’s a lot of value in what you’re talking about, with painting a picture of today, right, and helping everybody understand where processes are broken and that sort of thing.

I tend to do that with research findings and personas and say, “OK, everybody, can we get agreement on the state of the world today? Here’s what we saw in research. Here’s what the goals and pain points and characteristics of our personas are. Do we agree that this is an accurate depiction of reality?”

Because, if I can get agreement on the current state of the world, that gives me a more solid foundation for building the future. Right? Because the last thing I want to have happen when I’m describing a future scenario or showing design is for people to start arguing about what the data is.

So we try to get commitment at that initial level without using scenarios, per se, but say, “Look, here are the pain points we saw in the process. Here are some of the really fabulous quotes that we got out of the research where people are banging their heads against walls. Maybe here are some snippets of video or some photographs that demonstrate those points,” but really using the data to make that visceral, and then in the scenarios, which are focused on the future, saying, “OK, now let’s imagine the better world.”

Jared: Right. I guess I’m curious, where do the scenarios then get pulled out? Because what I was thinking was that, as you were creating the personas, you were sort of documenting the scenarios of today. But it doesn’t sound like that’s what you’re doing.

Kim: Not in great detail. I mean, I think that you could spend a lot of time documenting that. I find that, when it comes to really getting the most value out of your research and design time, I find that’s not the most productive use of time, documenting everything that’s wrong. Because that doesn’t necessarily help us make a lot of progress.

Unless it’s something where you’re really focused on a detailed redesign and you have the FDA looking at everything for approval and so forth, that level of documentation doesn’t serve most teams well, I don’t find. Maybe there’s a white-board sketch of the current process and a highlight of some of the points where it’s broken in general, something like that.

Where you pull the scenarios from is out of your understanding of the users. Right? And it’s not a scientific process. Instead, you’re relying on your human intelligence and your understanding of the goals and the characteristics of those people and saying, “OK, in a magic world, what would this be like?”

And this is an uncomfortable step for some people who want design to be a science. But think about it. When you’re planning a party for a friend or buying a gift for someone, you’re imagining what would be awesome for somebody that you really care about and know very well. You can do that with a fair degree of reliability. Right? And that’s exactly what we’re trying to do for our users is to say, “We know what makes them tick. We know what’s going to make them very happy. So let’s imagine what that might be like.”

Now, that doesn’t mean that we’re not still going to do usability testing and things like that to make sure that we’re right, because we’re not perfect, but we’re going to trust our gut as a foundation to generate. Scenarios are fundamentally generative tools.

Jared: Right. And if you’ve gone out and done your research… When I go out with teams, and we go out and we actually see their customers and we’re in their homes or their offices, and we’re looking at them actually do the things they do every day, it’s pretty easy to see what gets them all excited and giddy and what is dragging them down. When you have that full context to put everything in, it becomes really easy to pull out the scenarios, I’ve found.

Kim: Yeah. When you know your users really well, scenarios are… Certainly, there are a few technique tricks to master. But once you’ve got those down, scenarios are the most natural tool in the world. Because it’s just storytelling, fundamentally. It’s storytelling based on your understanding of the data, but it’s something we’ve all been doing our whole lives, right?

We’ve all been telling stories since we were, what, two, maybe younger than that even? Almost as soon as kids learn to talk, they start to tell stories. And so, we’re not bogged down in drawing UML diagrams and these other things that are kind of alien to how we think and communicate. Instead, we’re using a tool that’s very deeply familiar to us.

Jared: Yeah. I was with a friend who has a two-and-a-half-year-old, and she was telling us this story. It was so rich in detail about everything that went on in the story and all the different pieces of it. We were laughing hysterically because of the details that were coming out. She had imagined this whole world and had no trouble producing that. It’s amazing that we sort of beat that out of ourselves, huh?

Kim: And I think that your use of the word “imagination” is one of the keys because… In our day-to-day work, how often do we get to just imagine what’s great, right?

And because storytelling is a tool that we use early in our lives… This is my personal theory, anyway, not proven scientifically. But I think what we’re doing is… OK, this is going to sound all touchy-feely, but we’re drawing on our childhood selves, in a way. We’re drawing on a time when we were more free to imagine, because we’re using this tool that we probably don’t use that much once we become adults.

Jared: It’s interesting. We’ve been talking a lot lately amongst ourselves about sketching and how we all sketch when we’re little, and then many of us get told that we’re not very good at it so we stop doing it.

Storytelling is sort of the same way. And I’m wondering how much of this idea of creating great experiences really is something that we’re more in-tuned with when we’re younger, because we’re all about play, we’re all about imagining a space that we’re not in that’s a better space for everybody, and then the harsh realities of the world sort of talk us out of that.

Kim: Yeah. Certainly, we’re still applying our adult skills. Right? I mean, we’re applying our knowledge as designers when we tell our scenarios. We’re drawing on design principles and synthesizing that as we go to imagine these things.

So it’s not pure imagination. There’s absolutely craft in there. There’s knowledge and expertise in there. It’s a frame of mind that is intentionally a little bit naive and optimistic to begin with.

This is one of the things that makes people a little crazy when they first try to use scenarios. Because, if you’re in an organization where people are accustomed to jumping to the constraints and the details very quickly, your first pass at scenarios is going to be very high level and optimistic. Let’s ignore the constraints for a little while to imagine what would be awesome to do.

We know that we’re going to throw some of it away. That has to be OK because, unless you’re free to imagine what’s desirable, you’re just going to focus on what’s possible and you’re never going to get to that really amazing solution that you actually could do more easily than you think.

Jared: I think that there is definitely something to this, because a lot of teams really get stuck trying to live inside their constraints. And of course, the really hard, wicked, gnarly problems are ones that are so rich with constraints that all they can do is, with any possible solution, list the 20 reasons why that solution couldn’t possibly work. They get really stuck in that world of what they can’t do and why they’ve tried it before, and why it hasn’t worked.

So now, how is it that you use scenarios to get beyond that space? What do you do with teams when they’re stuck there?

Kim: I think that who’s involved in scenarios is… It’s partly a temperament thing. Most of the time, when I’ve done scenarios, it’s been specifically with other designers who are willing to take on that optimistic mindset because it’s natural to them, or with members of a product team who… Maybe struggle with it a little bit, but they’re willing to try that on.

Occasionally, with people who aren’t used to it, you have to pull them up short in a discussion and say, “Look. We’re thinking optimistically here. Let’s write that down on the whiteboard as a concern we’ll deal with later. Let’s focus on what we love to do.”

I think the key is just that everybody knows the rules at the beginning of the discussion so that you’ve got a small set of people. I think it’s really hard to do scenarios with six or eight people in the room. I think it’s much easier with two or three people in the room because you just don’t have quite as much… You don’t have as much politics and compromise and things like that.

I think that generating is much easier in a small group. Evaluating makes a lot of sense in a bigger group. But I think that, if you can get together and say, “Look. These two or three people have knowledge of the data, they’ve got direct experience with the users,” let’s imagine what’s possible.

Jared: When you have six to eight people, have you ever experimented with breaking them into smaller groups for this scenario creation process and then coming together to share what they’ve got?

Kim: I haven’t really done that because I think that… Competition may work. It may not.

Jared: You could give them separate things to do scenarios on.

Kim: Yeah. I think you can. What I find challenging is it’s hard to actually have six or eight people all of whom have direct experience with the data. And so, then you get people coming up with scenarios based on what they think, rather than what the data really is. It’s a lot harder to get that sort of a group focused not on their own assumptions.

Jared: So it is a key element that you’ve really got to have some real solid data behind the scenarios you’re producing.

Kim: Ideally. Have I done scenarios in cases where we all have shared assumptions and not real data? Sure. They’re perfectly useful tools, even when you don’t have data. But they work a whole lot better when you’ve got some data to back them up.

Jared: What are some techniques that you’ve used with teams to get data?

Kim: To get data?

Jared: Yeah, to get the data for scenarios. Are there certain types of things that are better at pulling data that you’re going to use for scenarios than other things?

Kim: My go-to technique for this kind of stuff is interviews, observation, using techniques that are borrowed from ethnography. I won’t say that it is ethnography because it’s not, strictly speaking.

Going out into user’s context where they’re using competitive products or services, or where they’re using somewhat related tools, if you’re inventing something brand new. Observing what they do, asking them why they do it that way. Seeing what drives them crazy. Those kinds of things… I think that direct, in context, observation is irreplaceable for this kind of design.

Jared: I’ve found the same thing, too. The more direct exposure that the people who are involved in doing the design and creating the scenarios have, the easier a lot of that work comes. Because, like you said, you’re not having a lot of conversation about what you imagine. That makes perfect sense to me.

I’ve been working, lately, with a bunch of teams that seem to be in this mode where they’re focusing on the march of the endless feature list.

Kim: Oh, yes.

Jared: And they don’t seem to have any real direction in their design. They’ve just got this list of things that they’re doing, primarily because their competitors are doing it, or some big customer says they’ll buy 1,000 versions of the thing if they implement this one feature.

Everything that they do tends to add a piece of complexity on top of the complexity that they’ve already added the last 20,000 times they’ve done this. This sort of giant hairball of design emerges.

Is that a situation you’ve found yourself in? And if so, how do you work with the team to get out of that mode?

Kim: Oh, absolutely. I think almost every designer encounters that if they work in more than one place.

I think that the bolting things on feature by feature is a really common approach, I think partly because it’s a way to scope development. Developers think, “Well, this is a capability that’s going to take this kind of effort to code versus that kind of effort to code.” And in that respect, it makes sense.

On the other hand, users don’t really experience feature lists. They experience workflows. They experience start to finish processes. And so, if you really focus on feature lists, I think you get the Winchester Mystery House of products. Right?

There’s a place in San Jose where she was listening to voices and she just starting bolting on stairways that go nowhere and doors that open three stories up into nothingness, windows into closets and things like that.

Jared: I just worked with a product manager that was listening to voices. I think that’s exactly how they were designing.

Kim: It’s true. The thing is that those voices are probably executives or customers. Right?

Jared: I could only hope.

Kim: Yeah, that’s true.

And so, I think where personas and the data behind them come in handy, and where scenarios come in handy, is giving people a focal tool. Instead of looking at the feature list, you can say, “Look. Let’s imagine this better experience. Let’s start idealistic. Let’s take Persona A through these three major things that they’re going to do with our product or our service. Let’s take Persona B through these two things that they’re likely to do with our product or service.”

“Now, let’s compare that to what we think our feature list should be. Hey, look! Our stories uncovered two or three things we haven’t anticipated in our feature list that look pretty important. And look, these other things in our feature list… Hmm. Gosh, those didn’t show up in the scenarios at all. What does that tell us?”

So I think that they’re a great tool for product managers to help prioritize requirements. Product managers right now don’t have a lot of great tools for this. They can go out and try to play innovation games with their customers and give people $30 to spend on features and have them prioritize in the abstract.

I think all of that is much less useful than saying, “Look. Here’s the story of the experience we want to build. Here are the pieces that are integral to that story. Here are the pieces that could be left out and you’d still have a coherent story, and we’ll save those for later on.”

And so, it just gives everybody that decision making framework.

Jared: Now, a lot of what you’ve described sounds very familiar to what Indi Young does with her mental model stuff. She’s got these, basically, two aspects of the design and experience. On the top, she lists all the things people are trying to do. And on the bottom, she lists all the functionality within the product that does that.

You can quickly, using her technique once the chart is built… You can quickly see where you’ve got a lot of things people want to do and not much functionality to support it, and vice versa. Is this fundamentally the same thing, or is this a different spin? Or, is this completely different and I’ve just got it wrong?

Kim: I’d say they’re related. I think one is a very storytelling approach. I think that I tend to follow up the initial scenarios with something closer to what Indi is doing, which is, “Let’s break down the story into the stuff people are trying to do and what that means for our requirements.”

Because once you can agree on a story, you say, “OK. If this is the story we want to accomplish, here’s what we have to be able to do. We need to know this. We need to be able to pull this data from there. We need to be able to connect these two systems that aren’t talking right now. We need to completely overhaul how we do customer intake,” whatever.

And so it’s kind of like, “Here’s the story. Here are the implications of the story. Now which of these can we really take on in the near term?”

The story kind of sells the idea first. It says, “Can’t we all agree this is a great goal? Now let’s get pragmatic about how much of that we can take on and when.” And so, it’s similar.

Jared: And how much you’re already doing, and how far off are you for the things you’re not doing.

Kim: Sure.

Jared: Yeah, that makes a lot of sense.

Now, a lot of things about this story stuff is that folks eventually at some point have to translate this, particularly if they’re doing some sort of agile like process. I’ve come to learn that no one actually does agile, they just do things that they claim isn’t quite agile.

Whenever I talk to someone, I say, “So, are you guys doing any sort of agile development?”

They say, “Well, it’s sort of like agile.” Sometimes they’ll even say, “We don’t do agile the way you’re supposed to.” As far as I know, nobody does it the way you’re supposed to.

Somewhere in there there’s these user stories, often on cards, they’re part of the backlog. They’re this thing that, at some point, sort of drives the development effort and the design effort.

But those stories are not these scenarios, right? You have to get from your scenarios to those user stories in some way. Do I have that right?

Kim: Right. I think the great irony of the term “user stories” is that they’re really not stories.

Jared: And they’re not really about users.

Kim: Right. The thing is, a story has a character, somebody with skills, and goals, and feelings, and other real human characteristics. User stories employ roles which are real abstractions of users. A story has a plot, it has a beginning and an end. It has something that starts off the action and some logical conclusion that’s a satisfying ending to the story.

Whereas, user stories are just like… Use cases or scenarios, they’re sequential thinking, which is good. That’s a helpful way to approach interaction because it always happens over time. But they’re often fragments of complete stories.

So it’s very common to see a user story, something like, “User logs in.” That’s not a story. That user story might tell you, “User enters name, user enters password.” Well, who is that user and why are they logging in, and what is it they’re trying to get to after they log in? So that complete story needs to put that action in context.

Now, that’s not to say that you can’t use user stories. I think that scenarios are completely compatible with waterfall, agile, or whatever custom mix of development approaches you use. Because you can turn scenarios into chunked up user stories very easily. But by doing the scenario first, you get the overall context and the overall flow.

You can also turn them into really detailed use cases documented in 90 pages of UML if you want to. If you’re working on legacy systems and there’s tons of complexity and you want to make sure that you capture every detail, sure, great, do that, but use the scenarios first as a generative tool, as a discussion tool, as a persuasion tool. Get agreement on where you’re going and then break it down into these other ways of chunking that information.

Jared: So if you’re working with an agile team… People talk about this sprint zero activity, the stuff you do before everyone goes heads down and starts coding up their first iteration. So having those scenarios come out of that sprint zero and having those discussions with the team coming out of the sprint zero, that could be really valuable.

Kim: Well, not only the scenarios, but also an initial set of storyboards that illustrate the scenarios. In my experience, by the end of sprint zero, you at least want to be there if not starting to get into the detailed design for sprint one so that you’re a sprint ahead. Trying to do detailed design on something while it’s being coded, that’s still a real challenge.

I think the agile goal of bringing design and development closer together in time is great. Because, if you’re designing something that no developer is going to touch for another three months… Yeah, that doesn’t work so well. But it’s great if you can design it a week or two before it starts getting coded so that design isn’t playing catch up.

But yeah, definitely, at the end of sprint zero, having some storyboards that you can say, “Look, here’s what this ultimately is going to look like, here’s how all the pieces fit together so that everybody understands when they’re designing this piece or that piece how it fits into the whole, how it affects the other pieces,” that makes that whole process a lot less chaotic.

Jared: I’m wondering about this because in an agile world the reason that we want to get design and development closer together is because once we get that first iteration done we’re going to learn stuff and things are going to change.

Once our target users get a chance to play with what we’ve built for a prototype in that first iteration, we’re going learn all sorts of interesting stuff that we couldn’t possibly have predicted before we started that iteration. And that’s why we don’t do those big, heavy design documents where we lay out every radio button for everything in its final form.

But do the scenarios change over that period, or do they tend to stay the same? Have you found, in your experience, that you can have radically different scenarios emerge out of those first few iterations or do the scenarios basically stay the same and become sort of the grounding for what we’re learning about what the users need in there? Am I making any sense whatsoever?

Kim: Let me respond to something you said in the lead up to that question which is, we’re going to learn all kinds of things we couldn’t possibly predict. Really? I don’t know about that. I think that, if you don’t do any research… Oh, yeah, you’re going to learn all kinds of things you couldn’t possibly predict. If you do good research up front, you’re going to learn a few things you couldn’t predict.

Jared: OK, OK, I buy that, yeah.

Kim: Right? So if you’re diving straight into design and development without doing research first… Yeah, iteration is going to be really educational. If you do some research first and design thoughtfully… And I’m not talking about six months developing a detailed spec. But you get to a coherent set of storyboards that everybody can look at and say, “Yeah, we see where that’s going. That looks great,” perhaps we even do a little scenario walk through with some users and get a sense that, “Oh, yeah, that looks like it’ll work,” then you can start to get into spec level design later on if you want to.

But what you learn in those iterations really ought to be polishing and not undermining your fundamental assumptions, because you’ve already figured those out.

Jared: So it would be fair to say then that, if you don’t do good research up front, your first iterations are going to be your research, and they’re a very expensive way to do research.

Kim: Very expensive way to do research, yes.

Jared: So that’s a good argument for getting that good research done up front because you’re not trying to research through code.

Kim: Right. Code is a very expensive medium to throw away compared to a couple pieces of paper.

Jared: Exactly.

Kim: Right? I mean, yeah, great engineers can code really fast. I really love the agile ethic that we learn through coding and it accepts that we also learn through designing which is something that waterfall doesn’t quite culturally accept. Waterfall assumes that you can get the design exactly right before you code anything, and that’s not true. Design is an iterative process, it’s a learning process.

Scenarios will evolve over time. And the way that they’ll evolve is usually not to fundamentally change direction unless you’ve done them very badly and didn’t do your research well.

But what happens with scenarios as they iterate is, they get more detailed. Because your first scenarios… You’re not worried about what list box people are touching in those first scenarios. You’re just trying to get the big stuff right. You’re trying to get a sense of roughly what kind of information are they exchanging with the system. Approximately what are they getting back, and how is that all flowing and what’s the end result?

And so, at that stage, who knows what widget is on the screen. First you’re just trying to figure out what screens do we even have. And so, your scenarios will evolve over time, they’ll get gradually more detailed.

I like to document the handful of early scenarios if there’s time. Later scenarios, well, those are just completely throwaway. You’re sketching at the whiteboard and somebody says, “Well, what if our user wants to do this normal variation on what we’re drawing up here?” And the person with the whiteboard marker says, “Well, I think it would look like this and let’s test that out.”

Well, you just used a scenario. It was a totally throwaway scenario, it was very informal. It’s not something you’re going to waste your time documenting, but it was still a useful tool that you just pulled out and used almost invisibly.

Jared: Right, and if you got good research and you can say, “Well when we went and visited Mary, she was doing this,” that becomes a really powerful story. You can say, “OK, how is she going to do that with this new design, or is it something she still needs to do? Are we going to make it so she doesn’t need to do that anymore?”

Kim: Exactly.

Jared: Which will make her really happy because she hates doing that.

Kim: Right.

Jared: I learned that when I saw Mary.

[laughter]

So it really feels to me like this isn’t really something new, this scenario thing, as much as it is formalizing our activity about things we’re probably already doing in a clumsy, informal way.

I think of it like when you look at professional sports athletes, let’s say a baseball player, they start to deconstruct their stance and how they hold the bat, and how they swing, and at what point in the pitch they make their call and swing.

The coaches for these athletes have very specific language for describing each of these types of things and what the different ways to handle it are. In essence, they’ve formalized… And formalizing has a bad connotation for a lot of people. But they’ve really thought through and said, this is how we handle these types of situations in the way we’re going to do this activity.

It sounds like what you’re doing is saying, “Look, you’re probably already telling stories and you’re probably doing it in a sloppy way. Here is the difference between good stories and bad stories in terms of how effective they are in getting the work done. And here’s how to get your stories more on this direction where they’re working for you and not against you.” Is that a fair description of what we’re doing here with these scenarios?

Kim: I think so. I think it’s actually a fair description of any design technique. I think that something that successful design organizations do over time is they look at their more successful designs and at their more successful projects and compare them to their less successful ones and say, “What did we do differently in these, and where are the patterns in that?” And the stuff that works well, that’s the stuff you want to keep doing.

And so, that’s exactly what I’ll be teaching everybody in the workshop about scenarios is stuff that I’ve seen over time and my teams have seen over time that tends to work pretty well.

Jared: Yeah, you and I were going over the outline for the day and it’s really rich. You’re packing a lot of really fun stuff into this. And it really gets down deep into things like how to deal with different channels of delivery platforms in parts of your organization, how the scenarios go across that, and how much you can use the scenarios to do things like derive the important requirements and figure out what your storyboards should be. It’s really going to be a lot of fun.

Kim: Oh, I hope so.

Jared: I’m really excited about it, I can’t wait to do it. So this has been really an excellent chance for us to talk. I want to thank you for spending this time with us today.

Kim: Oh, thanks for having me.

Jared: And I want to thank all of our listeners. You guys can all hear Kim. She’s done some virtual seminars for us in a variety of things, but other podcasts too, we’ll publish a list of those. But I’ve got to tell you, you don’t want to miss this seminar that she’s going to be doing at the User Interface 16 conference. It’s a full day that dives deep into this area of using scenarios and bringing that out and getting the most out of that.

It’s going to be really a lot of fun and people are going to just walk out of there… You’re just going to go, “Oh, my gosh, this was just so awesome. I can use this right away.” You don’t want to miss that. That’s going to be November 7th through 9th in Boston, Massachusetts. You can find out more information at uiconf.com, that’s uiconf.com. Hope to see you there.

Kim, thank you again.

Kim: Thanks, Jared.

Jared: And thanks to everyone for listening. And as always, thank you for encouraging our behavior. Take care.

This means that a whole bunch of folks will show up in Boston this November to hear some amazing speakers and topics. They’ll explore the latest UX techniques and design insights and have plenty of time to share success and war stories with other designers.

If you want to get all this too, you probably want to sign up before those 28 seats are sold.

Discover the UI16 topics and speakers at UIConf.com..

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