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

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

Here’s an excerpt from the podcast.

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

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

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

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

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

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

Full Transcript.

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

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

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

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

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

Adam: That would be awesome.

Lou: Excellent.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Lou: My pleasure.

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

We started out with 100 spots, but already we’re down to 80 for the UX Immersion 2012 Conference in Portland, OR April 23-25.

You can register at the lowest rate of $1,349 to secure one of the remaining 80 spots. After these spots are gone, the price increases by $300.

We’re not surprised at how fast these spots are going. Once you see the full-day workshop topics and amazing speakers, you’ll want to grab your own spot.

Spend 3 intensive days devouring the latest UX techniques in 2 important areas: Agile development and mobile design.

The goodies that come with your registration

• Two full-day workshops: You’ll choose among 3 Agile and 3 mobile design focused workshops
• One day of Featured Talks: Hear from each of the workshop presenters, 2 case study presentations, and a keynote from our very own Jared M. Spool
• Complete conference materials: We’ll send you the PDFs of every talk and workshop just before you leave for the conference
• Recordings of the Featured Talks: After the conference you can relive every Featured Talk at your office with your entire team

Learn more about UX Immersion 2012

Save your seat before they’re gone

Now is the time to act. Register now and we’ll guarantee you get into the workshops of your choice. You’ll get to choose your workshops at the end of February.

$1,349 is the lowest possible price. Don’t miss it.

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.

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

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

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

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

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

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

Full Transcript.

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

Noah, welcome.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Noah: Yeah. This is a dangerous network here.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Jared: Yeah. [laughs]

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

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

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

Jared: Oh, OK.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Jared: [laughs]

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

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

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

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

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

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

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

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

Noah: Thanks, Jared.

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

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.

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

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

Read the article, Why Visualization.

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

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

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

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

Here’s an excerpt from the podcast.

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

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

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

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

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

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

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

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

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

Full Transcript.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

But ultimately their usage would be really helpful.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Jeff: My pleasure. I hope that was helpful.

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

The latest of the obviously obvious findings we’ve come up with? That teams who don’t have a shared understanding of their design rarely succeed at producing a great product. See? It’s obvious.

Yet it surprises me that quite frequently the obvious is not what people do. Many teams that we’ve studied don’t pay attention to whether they have a shared understanding or not. They don’t create a process to ensure everyone is on the same page. Then they wonder why their results aren’t what they want.

In today’s UIEtips, I describe the two types of shared understanding we uncovered and how one of them is far more likely to end with a successful design. I’m betting this is an article that will create some interesting discussions amongst your team.

Read the article: Attaining a Collaborative Shared Understanding.

A collaborative shared understanding is a key component of successful Agile projects. Fortunately, on January 24, Anders Ramsay will be sharing his techniques for helping teams collaborate in his UIE Virtual Seminar, Designing with Agile. Bring your team and learn the best techniques.

Have you transitioned from a contractual approach to a collaborative approach to attaining shared understanding? We’d love to hear how it went (or is going). Leave us a note below.

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.

In the last installment, we talked about the distinction between Hands contractors and Brains consultants. Hands are brought in by the team as an extra resource to complete work the team already knows how to do. Brains are brought in by the team to provide expertise and insight on the best way to do something the team is struggling with.

Hands and Brains require completely different skills, have different approaches, and run into different challenges. Knowing which you want to be is important.

The Role of Hands

The UX professionals who make great Hands are passionate about producing stuff. Whether it’s a pile of wireframes or a boatload of usability test sessions, they can crank through them. More importantly, they tackle every single piece of the project joyfully and proudly.

The thing to remember is someone who signs up to be Hands typically doesn’t get to say how the project is done. The team decides that up front, often before the project is started. It’s up to the Hands to match the work exactly, making it impossible to know which elements came from the Hands and which came from other team members.

When it comes to how the work is done, creativity and previous experience aren’t playing big roles. In fact, they are frowned upon. While the team focuses on getting everything done by the end project, they don’t want to step back and take the time to rethink what they are doing.

The Hands will get management’s attention if they have tricks and techniques for speeding up production, while keeping the results indistinguishable from what’s been done so far. An experienced Hands contractor brings speed and agility, while playing the chameleon to match the work of their temporary teammates.

Bring in the Brains

This is a complete opposite to the Brains—who aren’t about production at all, but instead about strategy. The Brains, when at the top of their game, are the sheriffs, coming in to clean up the town. When a team is stuck and not making progress, and it feels like they’ve tried everything without results, they call in the Brains.

Unlike the Hands, the Brains doesn’t make a good producer. Their value is squandered if they spend the bulk of their project time churning out similar items. Of course, if the team is struggling with what to produce and how, the Brains can get them started, showing them the technique and coaching them through the work. But, in this scenario, the Brains quickly backs away, as soon as it’s clear the team members can produce their own results. (Some Brains will bring Hands into the project at this point, working jointly.)

Instead, the Brains’ real value is in strategic understanding of the situation. The Brains looks at the entire scope of the project, studies the goals, and assesses the team’s capabilities and flaws.

Then the Brains suggests a new plan. They get the team started on the plan. They train the team on the tricks and techniques that will get them through that plan. Then they leave town, just like the sheriff, to go off and clean up the next team’s mess.

Why The Difference Matters

Great Hands know how to produce. Great Brains know how to analyze and persuade. They are completely different sets of skills. Hands and Brains require different personalities. It’s very rare to find one person who does both.

The Brains aren’t challenged by production work. Once they’ve done one screen or conducted one test session, they’re ready to move on to something completely different. The Brains love the variety of the tasks—coming in to something new. The Brains love seeing problems and solutions nobody else seems to see. The Brains are energized when those problems are particularly gnarly and the solutions are deviously elegant.

The Hands struggle with strategy. They always feel they’re the wrong people to ask—that someone else should’ve figured this all out by now. They thrive on having a set of constraints, a schedule, and a near impossible pile of similar things to do. They love to crank through the work, seeing the Done Pile grow while watching the To Do Pile shrink. They don’t mind their work blending with the rest of the team’s—their contribution becoming invisible to anyone outside the team. They are energized by completion.

In other words, Hands thrive on walking into a project that’s well defined while the Brains thrive on walking into a project that’s poorly understood. That’s why it’s difficult to be both. It’s a very rare person who thrives on both definition and chaos. For everyone else, they need to choose one or the other.

I’ve seen managers who have tried to have one individual contributor play both the Hands and the Brains. Often this is because of resource constraints or not realizing there’s a difference. Unfortunately, this inevitably ends in disaster, because of the opposing strengths and weaknesses of Hands and Brains. Don’t fall into this trap.

What do you thrive on? What energizes you? Where do you get frustrated? Understanding this will help you figure out if you are suited for the Hands or if you ought to be the Brains.

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.

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

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

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

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

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

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

Using Data to Subvert Opinion Wars

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

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

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

All Hail The Arbitrator

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

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

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

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

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

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

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

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

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

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

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

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

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

Full Transcript.

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

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

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

Jared: Excellent. Anders, how are you doing?

Anders: Good, good. How are you?

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

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

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

Anders: Yes.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Anders: Yep.

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

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

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

Back in March 2011, Josh Clark presented a virtual seminar on mobile design where he discussed the importance of designing tapworthy mobile apps. In this article, we look at two of the questions addressed in the podcast follow up: Should content on mobile website differ from their big screen counterparts, and Josh’s opinion on native web apps versus mobile web apps. The follow up podcast covered even more material so you may want to give it a listen or read the transcript.

Read the article: Mobile Design- Content and the great Web-based vs. Native Debate

Josh’s virtual seminar on Designing Tapworthy Mobile Apps (which you can view a recording of) was so well received, we asked him to do another one. This Thursday, January 12, Josh is presenting Button Are a Hack, The New Rules of Designing for Touch. Learn more about this seminar.

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

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

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

The Kano Model

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

Market Maturity

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

The Four Stages of Competence

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

The Magic Escalator of Acquired Knowledge

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

The Scent of Information

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

Core vs. Ring

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

Hands vs. Brains

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

Design Decision Styles

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

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

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

That doesn’t mean co-located teams will always succeed – they don’t. It doesn’t mean that remote teams will always fail – they don’t either. In fact, we’ve met some awesome teams where team members are remote. (The folks at EightShapes immediately come to mind!)

Design is hard. Great design is really hard.

Teams need to rally every bit of energy they have to work together to produce great designs. They need to talk with each other. They need to see each other’s work.

We’ve observed that teams that work closely together create a common vocabulary. That vocabulary creates words and phrases that separate good design decisions from not-so-good ones. It helps the team discuss what’s on track for their design, versus what’s a distraction.

It’s also critical that teams is regularly discuss their emerging vision. This vision gives team members direction when making tough decisions. As things tiptoe up the borders of that vision, the teams needs a channel for expressing their thoughts.

Teams working remotely limit their communication channels. (This is even worse when the time zones are skewed, especially for those teams that span across oceans.) Establishing the common vocabulary and reinforcing the vision becomes increasingly difficult with remote teams. It’s not impossible, but the amount of extra effort is formidable.

We’re still collecting and analyzing our data on this, but our early results seem very clear. You’re more likely to produce a great design when you’re all in the same space, talking to each other. (War rooms are great for this, especially if you have lots of wall space to hang work-in-progress and have impromptu discussions.)

The next best thing is to have everyone be remote, but in the same (or a very close) time zone. Physically getting together at regular intervals can help quite a bit. (It’s even more helpful if your first project can be co-located.)

Teams talk about using remote conferencing tools, but they aren’t the same. The weird delays that come make simple things like telling a joke more difficult. These meetings adopt a false sense of formality because the changes in how the group interacts. It’s an expensive substitute that doesn’t really live up to its promise.

From our data, the worst case scenario seems to be when some people co-located and some remote. The remote people, not privy to the local conversations, become a type of second-class citizen. These teams seem to have the most trouble producing great results.

If you have any say in the matter, you want to aim for a co-located design team. If you can’t do that, then forcing everyone to be remote might be the next best option.

This is really hard for organizations that aren’t located where all the good talent is, or for those designers who are in places where they can’t be near the rest of their teams. Unfortunately, we’re not seeing any good options here for those folks.

It sucks, but those teams face a much harder challenge that teams that have the luxury of co-location. Great design is hard enough when we’re all in one place.

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

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

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

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

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

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

Full Transcript.

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

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

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

Josh, how you doing there?

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

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

Jared: Oh, I didn’t realize that.

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

Jared: Well, yes, in Internet years.

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

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

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

Jared: Yes, indeed.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Josh: Oh, here it is.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I just made that up now, by the way.

Jared: I like that, I like that.

Josh: You can have it for free.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Jared: Oh, interesting.

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

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

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

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

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

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

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

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

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

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

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

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

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

Josh: Right. Or at least, hokey pokey.

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

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

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

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

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

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

Josh: Right.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Jared: Yes, it was very gnomish.

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

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

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

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

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

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

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

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

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

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

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

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

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

Jared: Huh.

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

Jared: Seriously? Like an electric eel?

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

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

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

Jared: A platypus powered toaster.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Josh: You’re making me dizzy.

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

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

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

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

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

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

Josh: My birthday.

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

Josh: Thanks for having me.

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

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

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

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

Here’s an excerpt from the podcast.

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

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

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

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

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

Full Transcript.

Adam Churchill: Hello everyone. Welcome to another episode of the SpoolCast. Earlier this fall Richard Rutter joined us for a virtual seminar titled, “JQuery for UX Designers.” There were lots of good questions and comments. And we decided to have a followup conversation that we could make available as a podcast for you. Richard’s seminar spoke to how JQuery facilitates the vital steps of designing and testing interactive wireframes. Specifically, the complex interactions of today’s modern websites and web applications.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Richard: You’re welcome.

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

You’ll hear the latest insights on:

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

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

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

Order UI16 OnDemand today!

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

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

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

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

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

Look at any young and accomplished musician or artist. Or at those twenty-something sports stars. They are obviously talented.

Yet, how much of a role does their talent really play in what they do?

That 12-year-old pianist who is dazzling the audience with her Bach concertos – sure, she has talent. But look closely and you’ll see someone who has been practicing for years. She took classes and sat at the keyboard for hours every day.

While talent is something we’re born with, skills are something we pick up. Study hard, practice often, and given enough time, a person achieves mastery.

In design, this is certainly the case. I’ve met designers who demonstrated their stuff easily, but most of them did that after years of practice. They worked hard to learn the tools, to become literate in the ways of design. They always study the work of others, first by mimicking to master the technique, then adopting it to make it their own style.

It’s true that talent may get them to mastery faster. It might push their mastery beyond that of their peers.

Yet, everyone I’ve met who is really great (and I’ve met a lot of great designers), got there because they worked at it. It wasn’t natural.

Breadth of experience is another thing those great designers all share. Mixing up the projects, mixing up the teams they work with, mixing up the customers they design for – all that brings experience.

Every time they change something up, they have to re-evaluate what they believe to be true. They have to tweak their skills to the new environment. What used to work well now doesn’t work as well. They have to ask, “what do we need to do differently?”

Hang around me long enough and you’ll hear me utter one of my favorite aphorisms: “Good judgement comes from experience and experience comes from bad judgements.” I’ve observed that great designers make smart decisions quickly. They have years of practice at making decisions. They have a breadth of experience. They can recognize important patterns. They constantly practicing their basic skills.

Don’t worry that you’re not talented enough: get out there anyways. Learn the skills. Practice them constantly. Change up your environment to gain new experiences. This is the path to being great.

Talent only differentiates us when we’ve already mastered skills and had a breadth of experiences. What separates the great designers from everyone else today isn’t their talent — it’s their skill and experience. Talent is the least important of those three attributes.

What’s the difference between contracting and consulting? One major difference comes down to whether the job is handwork or brainwork. Whether you’re an “innie” or an “outie,” this is applicable.

Innies are UX professionals who work inside an organization. Even though they are part of the company, they are still consultants. They are brought on to projects with the intent of lending their skills to move the project forward. Sometimes they stay with one project for its duration, or sometimes they juggle multiple projects at once. Either way, they aren’t really part of the long-term team in the same way others are — they move from team to team and are only there when their skills are in demand.

Handwork and Brainwork

Innies and outies have a lot in common. One thing they share is the need to distinguish whether a project is handwork or brainwork.

Handwork is when the hiring team knows what they want; they just lack the right number of hands to get it all done. Let’s say the team needs new screens designed. They know what the screens are and how they should work. They’ve built many screens before, quite successfully, so it’s not a problem of knowing what to do.

The problem is they don’t have enough hands to get the job done. All of their internal resources are otherwise occupied, thereby stalling the screen-production piece of the project. In this case, they hire a contractor—someone who will come in and help them crank out more screens. This is handwork.

But there’s another way the project could go down. What if our hypothetical team doesn’t know what the screens are or how they should work? What if they don’t have the experience of building screens before and lack the confidence and skills to get started efficiently?

In this case, they need someone to help them come up with a strategy for identifying which screens need work and how to tackle them. In fact, once that strategy is set and they understand what the project needs to be finished, they may have, internal to the team, all the resources necessary to complete it.

This is when they hire an outside consultant; someone who will bring in expertise and skills the team doesn’t otherwise have. This we call brainwork.

Hiring Hands and Brains

It’s quite critical, as a UX consultant (whether you’re an innie or outie), to distinguish between handwork and brainwork—yet the distinction is often not discussed. As I talk to people who are looking to expand their careers, what I discover is they are often trapped doing handwork when what they really want to do is brainwork. (Occasionally, I meet someone who prefers to do handwork to brainwork, but that is quite rare.)

Handwork, for the most part, is commodity work. Once you qualify the basic skills, it really doesn’t matter who does it. It doesn’t take imagination. Previous experience, for the most part, doesn’t play a role in the quality of the output.

If the team needs to produce 100 wireframes and they have a pool of 20 people who are capable of producing those wireframe to their specifications, then it doesn’t matter which of those people you hire. Hire the one who charges the lowest rate, has the nicest personality, and produces the cleanest deliverables.

Brainwork, on the other hand, is where your expertise and experience come into play. If the team doesn’t know what a wireframe is or how to decide what they should do, they’ll want someone who can give them solid advice. It they’re smart, they’ll be selective about who they hire, looking for someone with a track record of helping other teams in comparable situations, and they’ll pay top dollar for their help.

Maybe the team’s leadership is mistaken and they shouldn’t be doing wireframes at all? Well, someone hired to do brain work will have earned the respect and authority to say, “You know, there’s a better way to do this” and the team will listen. (Occasionally, they’ll even revise their plans, but that’s another column for another day.)

However, if that same person was hired to do handwork, there’s no way the leadership will pay attention. It’s wasted breath (or worse, seen as belligerence that may result in removal from the project). Handwork is hired for hands, not brains. Please keep your brains to yourself.

UX professionals who do handwork are what we call the Hands. They’re a rare and valuable breed. Find someone who loves being the Hands and you have a production machine.

The Brains are what we call folks who provide great brainwork. Prospective employers have to be more discriminating when hiring the Brains, because their advice will drive the results, either to success or to failure.

Hiring managers should know which they want. Get the right person for the job and you’ll have a successful project. You need to distinguish between Hands contractors and Brains consultants. In the next installment, I’ll talk about the qualities that separate a great Hands contractor from a great Brains consultant.

[Don't forget to read part 2. After this article was originally published, there was a little confusion. I try to clear it up here.]

Fast Forward Four Months…

We’d like to thank you for doing a fantastic job as our 2012 Winter Business Intern. You started with a thorough analysis of the purchasing patterns in our UIE Virtual Seminar series. This led to some amazing insights on how we could restructure the program, which helped us with key initiatives we launched this spring.

At the same time, you put together a marvelous weekly social media outreach strategy. Once you started executing it, we saw a real lift in the conversations we’ve had with our customers, which has had a direct affect on our bottom line.

When you turned your keen attention to compiling the history of our revenue sources for the last few years, you uncovered some interesting patterns about who our customers are and how they like doing business with us. We’ll use those insights to drive new products for years to come.

You also created a database of our marketing partnerships, to help us know who to contact and what they’re interested in. This makes it easy for us to make our partners aware of our latest offerings.

To top it off, you’ve even helped us document our business development process to make life easier for future interns.

Thanks for your energy and enthusiasm during your internship. We know you’ll succeed at your future ventures.

Now Back To Today…

If you’d like this to be your story, send us your resume with a half-page write up of your most significant business accomplishment. While we’re less concerned with your skills and qualifications, we won’t compromise on your ability to deliver team results. We’ll be back to you in 24 hours if you have what it takes to achieve something special.

You might even want to check out our web site for some insight into what we’re doing. We think you’ll be excited by where we are today and the challenge to get us where we’re going.

You will work in our North Andover offices. (Sorry, we don’t hire remote employees.) We’ll provide all the equipment you need, including Apple hardware and Mac software to bring out the best in your talents and skills.

Send your resume and write-up to: BusinessInternJob@uie.com

or

Jared M. Spool, CEO
User Interface Engineering
510 Turnpike Street, Suite 102
North Andover, MA 01845

Fast Forward Four Months…

We’d like to thank you for doing a fantastic job as our 2012 Winter Web Developer Intern. You’ve driven the launch of a new web site for our latest conference. You worked your magical HTML5, CSS3, and Javascript/JQuery skills to get us a slick, good looking, easy-to-use site. You updated it with new content as we got closer to the event and, because of you, the event was a success.

Your site development skills are top-notch. You’ve helped us clean up some of our old PHP server scripts, removing outdated advertising and content from the site.

You also helped us migrate our UIE Virtual Seminar pages to our new ExpressionEngine-based Content Management System. We were impressed with how quickly you picked up on what we were doing and the improvements you made.

To top it off, you’ve even helped us document our Git-based design and development process to make life easier for future interns.

Thanks for your energy and enthusiasm during your internship. We know you’ll succeed at your future ventures.

Now Back To Today…

If you’d like this to be your story, send us your resume with a half-page write up of your most significant web development accomplishment. While we’re less concerned with your skills and qualifications, we won’t compromise on your ability to deliver team results. We’ll be back to you in 24 hours if you have what it takes to achieve something special.

You might even want to check out our web site for some insight into what we’re doing. We think you’ll be excited by where we are today and the challenge to get us where we’re going.

You will work in our North Andover offices. (Sorry, we don’t hire remote employees.) We’ll provide all the equipment you need, including Apple hardware and Mac software to bring out the best in your talents and skills.

Send your resume and write-up to: WebDevInternJob@uie.com

or

Jared M. Spool, CEO
User Interface Engineering
510 Turnpike Street, Suite 102
North Andover, MA 01845

There’s value in listening and reading everything we produced in 2011. But we know time is a factor. So in the last UIEtips for 2011, we decided to share the 5 most popular blog posts and articles.

Here they are, in no particular order, the most popular articles and blogposts published during 2011.

Why I can’t convince executives to invest in UX (and neither can you)

Blog post published June 8, 2011, by Jared M. Spool

Every few weeks, a phone call or email comes out of the blue, asking me to perform magic. The inquirer always wants the same thing: to stand up in front of a room filled with their executives, delighting them with a presentation that will make them rise to their feet cheering. This audience will then burst out of the room, demanding their subordinates to invest everything in a whole-scale, no-holds-barred user experience effort that will revolutionize the company, the products, and the world.

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

And it may surprise you to learn that I refuse the offer every time.

Read more about Jared’s rationale behind, Why I can’t convince executives to invest in UX.

6 Epic Forces Battling Your Mega Menus

Published August 24, 2011, by Jared M. Spool

“This is a perfect opportunity for us to use that mega menu we wanted to try out.” That’s what I heard a few weeks ago, sitting in a client meeting.

The client was dealing with balancing a lot of navigation while keeping their home page free for the important messages they want everyone to see. A mega menu – those large multi-column layered menus that pop up when you hover over the navigation – seemed like just the ticket.

However, our research shows mega menus come at a price. In this article, I talk about the epic forces that are constantly in battle with any mega menu implementation, preventing the users from getting value.

Read the article, 6 Epic Forces Battling Your Mega Menus.

Beans and Noses

Blog post published July 8, 2011, by Jared M. Spool

Over the years, I’ve received a lot of great advice. One piece of advice I keep coming back to is about managing expectations. It came from an old friend, just a few days after I’d started my consulting practice.

He was a seasoned consultant himself and I had asked him what I should know, just starting out. He told me his First Rule of Consulting:

No matter how much you try, you can’t stop people from sticking beans up their nose.

That was it. Beans up the nose. Really.

At the time, I thought he was nuts. Now, I’ve come to realize those are words to live by.

Find out more on what Jared means regarding beans and noses.

Creating Great Design Principles: 6 Counter-intuitive Tests

Published March 1, 2011, by Jared M. Spool

The excitement in the room was electric. Everyone was waiting for the big moment. Finally,
it was here.

For six months, the team had been working on their new design principles. In closed meetings, they were hashing out what they were going to do and how it would be different. Now, the project manager was walking to the front and revealing the fruits of their labors.

Easy to use. Enjoyable. Innovative.

People were shuffling in their seats. Really? Six months for this? “But, we’ve got executive buy-in. That took a lot of work,” the project manager defended. Right, because who could argue against ‘innovative’?

We’ve seen this scenario play out way too often. Teams create principles that prove too generic to be useful in any design decisions.

Learn about the six tests that separate out generic design principles from those that really work for a team in the article, Creating Great Design Principles: 6 Counter-intuitive Tests.

Do Users Change Their Settings

Blog post published September 14, 2011, by Jared M. Spool

Back in the early days of PC computing, we were interested in how people used all those options, controls, and settings that software designers put into their applications. How much do users customize their applications?

We embarked on a little experiment. We asked a ton of people to send us their settings file for Microsoft Word. At the time, MS Word stored all the settings in a file named something like config.ini, so we asked people to locate that file on their hard disk and email it to us. Several hundred folks did just that.

We then wrote a program to analyze the files, counting up how many people had changed the 150+ settings in the applications and which settings they had changed.

What we found was really interesting.

Read more about what our research discovered.

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

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

People Who Are First

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

Being First to Gain Social Status

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

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

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

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

Being First as Product Research

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

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

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

Being First to Solve An Active Need

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

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

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

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

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

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

People Who Wait

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

Waiting Because Unaware of Latent Needs

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

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

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

Waiting Because Of Perceived Cost Of Change

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

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

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

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

Waiting Out The Product Lifetime

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

Now I look at the basic usability test protocol like it’s a column of wet clay, ready to be molded into exactly the research instrument we need. Over the years, we’ve invented, borrowed, and stolen different variations, all to help us better understand our users and what we’re designing.

In today’s UIEtips, I talk about five of our favorite variations. You’ll see how we bend and twist basic techniques to discover new things about what we’re designing.

Read the article: Bending the Protocols – Useful Variations on Usability Tests

What are your favorite variations on usability testing? Tell us below what you’re doing.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ok, that’s kind of a lame riddle, but it’s accurate nonetheless. When we get a wrapped present, we hope the unwrapping will produce something that delights us.

The same is true when clicking on a search result. We anticipate it will serve our needs and provide everything we’re seeking.

Unfortunately, much of the time, it doesn’t. The shame is it’s completely preventable—careful thought and design could’ve resulted in a delightful user experience.

In today’s UIEtips, we look back at an article from December 2009. I talk about some perils we’ve seen when users clicked on sponsored links, only to be disappointed by the results. Two years later our findings are still the same.

Read the article, Three Perils with Search Landing Pages.

How do you determine what ads to show when search is involved? Share your thoughts with
us below.

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

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

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

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

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

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

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

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

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

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

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!

She concluded her post with this comment:

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

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

There are two definitions I can see here:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What’s really fascinating about this article is the back story. The client had hired us because they were concerned about checkout-process abandonment. Their analytics were showing a 13% drop off in sales, which, based on the average value of the abandoned shopping carts, was worth about $1.2 million a year in additional revenue.

Checkout-process abandonment is common in e-commerce sites and something that you can easily detect with your site’s usage logs. You just look at the number of people who get to the first screen and then the number of people who actually complete the transaction. Everyone who doesn’t make it is considered an abandoned cart.

When the team contacted us, they’d already pretty much decided what the problem was and how they were going to fix it, even though they had never watched any shoppers make purchases. And they were dead wrong. Not only was their fix not going to help, our research showed that it was going to increase abandonment.

Two weeks of usability testing on the live site (and on competitors’ sites), followed by two weeks of iterative paper prototype testing produced a streamlined checkout process, which, once implemented, showed a dramatic increase in revenues. It’s amazing what you’ll learn when you actually watch your users.

Today’s article talks about the bulk of that increase — how a simple change to a common screen produced $300,000,000 of additional revenue over the next year. I’m sure you’ll find it interesting.

You can also read more on the back story of the $300 Million Button on the Brain Sparks blog.

Have you seen results from changes to your forms? We’d love to hear your experiences. Share them with us below.

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

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

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

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

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

As our clients are moving to more rapid development processes, like Agile’s Scrum, their design teams are looking for ways to infuse their UX work into the process. My recent research shows that Lean UX is one way to get there and it’s getting lots of traction through out the UX community.

In this week’s UIEtips, I discuss what’s been happening to our design processes and why I think Lean UX has real potential to change the way we approach our work. I’m sure you’ll enjoy it.

Read the article: Is There Any Meat on This Lean UX Thing?

As an extra bonus, coming up on Wednesday, December 7, we’ve invited Jeff Gothelf to talk about how he’s using it to get his company, The Ladders, out of the deliverables business. If you’re working in Agile or another fast-moving environment and want to know core essential techniques for good design, you won’t want to miss this virtual seminar. Read the details.

What’s your take on Lean UX? Is it something you’ve been working with? How has it helped you? Share your thoughts below.

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

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

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

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

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

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

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

As we study what makes teams successful, we realize that the successful teams aren’t doing anything new or novel. Their success is solidly based on a fundamental that many of the struggling teams have forgotten: good design decisions come from informed members of the team.

A significant difference that’s come about in this new agile world is team integration. No longer is UX design owned by the UX designers: everyone on the team now has design responsibilities. That means that everyone needs to understand what the design is trying to do.

When we talked to the teams from the successful organizations, we found a common theme: they used a framework to make sure their teammates have all the information they need. We’ve codified this framework as UX Layers, which span from the big picture of a long-term vision all the way down to the details of individual user stories for developing the next sprint.

In today’s UIEtips, we look back at an article from May of this year. We explore the UX Layers, looking at how they each fit together. Whether you’re currently doing Agile development, planning to move there, or still working in a waterfall world, I think you’ll find this framework will help ensure you’ve got all the information you need to create great designs.

Read the article, Essential UX Layers for Agile and Lean Design Teams.

Want to know more about how Lean UX contributes to working faster, smarter, and happier? Explore our next UIE Virtual Seminar on Wednesday, December 7 with Jeff Gothelf, Lean UX: Getting Out of the Deliverables Business.

Has your team tried a similar framework for ensuring every team member is making informed decisions? Let us know your thoughts and questions below.

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?

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

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

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

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

It’s not too different in our world of design. There’s a lot of long-forgotten “old thinking” which is relevant with today’s thinking. In today’s article, I share an old model that has appeared on my radar over the last few years.

If you hang out with me, you’ve probably heard me say, “Good judgment comes from experience, and experience comes from bad judgments.” Today’s article describes a model that explains how that maxim actually works. The model is called The Four Stages of Competence, and has a myriad of uses in our design work.

Read the article: The Flexibility of the Four Stages of Competence.

What old thinking have you discovered lately? How do these four stages fit into your design work? We’d love to hear your thoughts below.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The simple answer: Fill your portfolio with stories.

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

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

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

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

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

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

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

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

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

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

The page was cluttered.

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

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

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

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

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

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

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

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

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

Now, these are often implemented with a checkbox that says something like “I have read and agree to the terms and conditions.” Most of us know that hardly anybody reads and everybody just checks off the box. (Once, I watched my dad, a lawyer, check the box without reading. “It’s probably unenforceable,” he told me.)

But on this new Amex site, there’s a different implementation of this control. Sure, there’s a checkbox, but it’s grayed out. The only way to enable it for checking is to scroll to the bottom of the agreement.

The Amex Biz Travel site greys out the checkbox until the user scrolls to the bottom.

Now, as is also standard, the agreement is presented in a tiny little scrolling text box that shows about 200 words at a time. And, as is also standard, the agreement is a whopping 7,243 words (13 pages in a standard document) long.

Therefore, scrolling through this box takes a fair amount of effort. It’s unlikely that scrolling will encourage anyone to read the document. It’s just an extra hoop to jump through to continue the farce of pretending that the user has “read” whatever it is their agreeing to.

Apparently, the lawyers at Amex think that by having me scroll to the bottom, they can claim that I had every opportunity to read and agree to the terms. Therefore, if there’s something down the road I want to sue them about, I gave up that right with my scrolling action. (It’s unlikely any sensible judge will buy this argument, but it’s just as unlikely that any suit against them will get in front of a judge.)

Of course, the best way to do this would be to be honest with your users and treat them with respect. Amex could write the terms in simple language and give users a chance to really understand what they are agreeing to.

The problem with a design solution like the “scroll to agree” implementation is that it won’t be good enough. What happens when some other lawyer at Amex (or whereever) discovers that users don’t read it when they scroll to the bottom and therefore don’t understand what they are agreeing to? They’ll put in some other ridiculous control, where you’ll have to enter a secret code or recite poetry or something.

At some point, we, as designers, have to stand up and say, “This isn’t really doing what you think it’s doing. It’s just making our relationship with our users worse.” When do we do that?

I’d like to start now.

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

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

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

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

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

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

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

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

Full Transcript.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Read the article, On UX Leadership.

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

That’s not the case when you bring Adapative Path’s CEO, Brandon Schauer into the picture. Brandon has a way of getting an entire team—executives, designers, developers, marketers all producing dozens and dozens of ideas. He does this through a group of excerises and tools you’ll find in a workshop called Good Design Faster.

In today’s article, we look at an excerpt from an interview I had with Brandon back in September. Brandon shares his methods on how to get your team producing many ideas, what makes ideas tangible, and why it’s critical to move past the first idea.

Read the article, Good Design Faster – An Interview with Brandon Schauer.

This article is just a small taste of what the Good Design Faster workshop is all about. On Wednesday, November 9, Brandon will share a lot more on Good Design Faster at an all day workshop at the User Interface 16 Conference in Boston.

How do you motivate your team to get innovative? Share you thoughts below.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Full Transcript.

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

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

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

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

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

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

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

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

[laughing]

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

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

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

[laughing]

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

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

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

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

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

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

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

No? Come on, raise your hand, you liars.

[laughing]

OK, it looks a little crazy, it looks a little chaotic, and I’ll explain to you a little bit what these people are doing, but when we were writing the book, that’s actually a paper prototype of a toilet seat. Yes.

[laughs]

Alright, when we were writing the book, my co-authors and I convened about 50 people in a conference center to actually work on all the ideas and prototype all the stuff in the book. And I want to tell you a story of something that happened there.

50 people come together in a conference center, they’re staying there. They’re going to have basically two or three days with them. In the early stages we did a game called Poster Session, which we are going to do today together.

And the idea behind Poster Session is everybody makes kind of an infographic style poster that explains something that they’re interested in, something they’re excited about or something that they want to propose as a project, et cetera.

This guy, who’s not a designer, had the issue that he cared about, which was disposable coffee cups. Millions of us go to coffee shops every day, we buy our coffee in disposable cups, we drink our coffee and we throw the cups away.

Now, that adds up to a lot of waste and a lot of problems, because they’re hard to recycle and so forth. And here he was coming in, he said, “You guys have design skills, this Gamestorming stuff is about innovation and creativity. I don’t have the answer. I have the problem. The problem is we need better disposable cups.”

That’s what he thought the problem was. “I don’t want to blame the people who are throwing away the cups, there’s got to be something we can do to make a better cup that’s just easier for people carry around and use and re-use, instead of them using all these paper cups.”

So he said, “I challenge you to help me with this, help me do this.”

So the survey that I mentioned earlier was part of that activity. So he got some people with him to work on this project that he cares about, and they started by doing kind of a survey of like, “What’s your coffee experience like?”

They designed some questions, they had people answer the questions, and one of the things I heard from them was, “Doing a survey in this way was actually very helpful, because I got to see more of the thinking process, as people answered the questions with the sticky notes, than I would have if it was just an online survey. So we actually went and changed some of the questions and were able to adjust as we were getting feedback.”

Now, it’s not necessarily what you would do for a research survey, but for a quick and dirty getting a feel for things, and of course most of us do know what it feels like to go get a coffee in the morning, and most of us use disposable cups, that they were able to do that.

The next exercise that we did with them is something called Bodystorming, and this is a picture of people Bodystorming. Raise your hand if you’ve done this or heard about it.

Bodystorming is simply a kind of improvisational role play where instead of designing your product on paper, you actually design it by working it out with other people in real time, in real space.

So this person is the iPhone, OK? You can see the iPhone there. And we have the user. And these are people who are aspects of the application. This guy’s looking up whatever he’s going to be doing next.

So it’s a very quick way to prototype a system and really get a feel for how does it feel to interact? How does it feel? Get a flavor for it. And it’s a kind of a play that’s helping us figure out what’s on the other side of that? What’s the better iPhone look like? What’s the next generation look like?

We could play with those things and tweak them until we start to get a feeling for something that then we can go a little bit deeper on. So it’s a way of sketching. This is a way of sketching.

So the Betacup team, that was their name, this guy, Tony Daniels, he had actually named his problem the Betacup design project. So what they decided to do in their Bodystorming was they were going to set up a Starbucks, and they’re going to feel out the system. So they have barista, this is the Starbucks here, this is the asshole, see?

So they actually, what they did was they set up the Starbucks and they started role playing what it feels like to be in the line, to go through, to experience this, to try and figure out, “How can we fix the cup? What is it that we can do with the cup?”

And they came up with some pretty cool ideas, just by tweaking the system a little bit. And one of the things they discovered was, “Wow, it sucks to be in line behind the asshole, because he’s taking forever, he doesn’t know what he wants. You’re waiting in line, you’re waiting in line.”

So they came up with this idea where your cup would also be your loyalty card and your credit card and everything else, so you’d have your order built into your cup, so when you came to order, you could skip the whole line, you just put your cup at the end. They picked it up, they had your order in there, they had your loyalty program in there. All they had to do was swipe the cup and they could put it into the system and it would come out the other end with your stuff.

So there’s all these benefits to that, like you could pick up three or four cups from your co-workers, you know, and you wouldn’t have to remember their orders, because it would be built into their cup, right?

So they had actually kind of thought about a lot of cool benefits.

So after the event, a lot of these people that we had in were bloggers and social media people and so forth, so they actually posted about it on the Internet. “This is our Betacup Bodystorm, these are the ideas that we have.”

And it was, you know, people were reading it, people were like, “Oh, this is kind of interesting.” And who would be reading this but Starbucks, the VP of Sustainability at Starbucks saw the video. This is like a really rough, shaky, hand-held two-minute video of the, excuse my language, I’m saying it because it’s the language they use – “The asshole in the Starbucks line,” and the way they acted the thing out.

This was the guy they had on their radar. They wanted to get a meeting with him. They had wanted to get a meeting with him forever, and he called them.

Now, What’s interesting about this? Well, when you’re doing innovation work, you don’t know what you don’t know when you begin the project, so you’re learning as you go.

So first they thought, “We’re going to make a better cup, it’s all about the cup.” But then they started looking at the system, and they said, “Actually, what we need to work on is not just the cup but the whole system around the cup, and make the system work better.”

And then from there it became the social system. The thing that the Starbucks guy was excited about was not the particular solution that they had come up with. He was interested in the whole social engagement factor about how they got all these people connected to trying to solve this problem together, collaboratively. He was interested in the wisdom of crowds stuff.

So there’s actually now a Starbucks competition. It’s a $20,000 Betacup prize. They’ve already awarded it once. There’s winners and everything. This came out of just people getting into a room and not knowing what they were going to do together…

Everyday, more companies are recognizing the value of design. They are realizing they need to have strong design to compete in the marketplace. They see their competitors, even the small ones that don’t offer as full a feature set, are eating away marketshare because they have better designed products.

No place manifests this more than Silicon Valley. Designers, especially good ones, can call their shots there. Companies are in a bidding war for talent.

That means, if you’re a good designer, you have to ask yourself: are you in the right place, right now?

Milton Glaser gave a speech a few years back. He talked about two types of relationships: those that energize and those that exhaust. Milton said he learned, the hard way, that he needed to regularly prune away those relationships that exhaust, focusing on the ones that energize. That was his advice to happiness.

If you’re a good designer, are you in a place where your work energizes you? Or does the organization you work for exhaust you, because it hasn’t realized how important design is to its own success?

Now, it’s not that every day will be free of frustration. But if you’re regularly energized, it’s much easier to face the tough challenges. When you’re exhausted by your work every day, the challenges often feel insurmountable.

When a company doesn’t get the importance of design, it’s rough being a designer there. You constantly have to explain what you do. You have to fight for the simplest things, like the time and resources to do research (and often fail). You see, everyday, how your work could be so much better if you had the right tools, the right support, and enough time to make it work.

It’s scary to think about change. But right now, the timing is right for designers. If the job you’re in isn’t the right one, you owe it to yourself to look at what your options could be.

If you decide you should explore the world of opportunities, think about what you’d want in your next job. A company that values design will push off a ship date because the product’s not well enough designed. Ask if the company has ever done that — that demonstrates whether they have their priorities aligned with yours. Delaying a launch is a hard call. Having done it means they are serious.

Look for other evidence they understand design. Do they take the time to do research? Is everyone in the team involved? Do they iterate frequently? Are they learning good things from each iteration?

These are the signs that a company wants to learn what the best designs are. That yearning to learn makes the workplace really exciting for designers who are innately curious and autodidactic.

It’s a good time to be a designer. Every day should energize you. Are you doing everything you can to make sure that happens? After all, you owe it to yourself.

I remember always being impressed with the pictures and talking about the Colosseum and the Roman Forum. Yet nothing could prepare me for my first trip to Rome. It wasn’t anything like the pictures.

I think this is exactly the same feeling that designers have when they visit their users for the first time. Sure, they’ve heard about users and what they’re like through the various sales and support channels. Maybe they even met one or two in their travels.

But seeing your users really work with the design is a whole different world. It changes the way you work and think about what you’re building.

In today’s UIEtips, I explain why I love taking teams out on their first site visits. It’s really exciting to see the transformation the designers undergo as they open up a new world. The metamorphosis they go through is really fun and exciting.

Read the article Why I Love Taking Teams On Field Visits.

If you’ve always wanted to go on your own field visits, you’ll want to get the best techniques from Steve Portigal, who is a master at these things. His User Interface 16 Conference full-day workshop will be a ton of fun. You’ll go on your own site visit and analyze the results – an amazing education. Check out how much fun it’ll be.

I asked (on the Twitters, of course) what was the first application to use the pull-to-refresh gesture. My world of followers suggested it was the original Tweetie app, which was then acquired by the Twitter overlords. Since Tweetie, it’s shown up in a bunch of apps on my iPhone. I’m told it’s also on apps all over those Android phones that everyone talks about.

What’s interesting about the pull-to-refresh gesture is how natural it feels. Need more stuff, pull down on the list. Very simple. Very intuitive.

Well, it’s only intuitive if you know about it. You see, the problem is the gesture has no affordance (a hint or clue that the function exists). There’s no way to know where pull-to-refresh is implemented. Anyone who has learned the gesture has probably experienced the pull-to-do-nothing function in all the apps where it’s not implemented. Suddenly, something that’s novel has become a basic expectation, just like Kano taught us it would.

If you didn’t know about pull-to-refresh, how would you learn it’s in your app? For the most point, it requires you learn it from someone else.

Someone who leans over and says, “Hey, did you know you can update your list by just pulling down on your thumb?”

“No Way!” is the usual response, followed by the now-common thumb maneuver. “Cool!” is what comes next.

And it happens. Just like that. We’ve just transmitted the functionality, socially.

Pull-to-refresh isn’t the only socially-transmitted functionality. In years past, it’s how I’ve seen people learn about drag-and-drop in applications. It’s how they learn about special keys, like F5 for refresh or F1 for help. A lot of functionality has been transmitted from one person to the next, socially.

There’s nothing wrong with socially-transmitted functionality, as long as it’s not something the user needs (they can use the design just fine without it) and you have users that talk with each other. The problem comes from when you, as a designer, know about an functionality that only transmits socially, it’s hard to realize that people around you haven’t caught on yet. Just because it’s in your pattern library doesn’t mean your users will know about it.

[A note about accessibility: socially-transmitted functionality is rarely accessible in itself, as it usually has no way for a screen reader to work. For accessibility reasons, you probably want alternative access.]

In a recent site visit, I watched users struggle with navigating around a web app because the return-to-main-menu function was a not-obvious icon that looked like decoration to the untrained eye. All the developers observing the visit knew about it, but this collection of users hadn’t been infected with the knowledge of the functionality, and therefore didn’t use it. Their alternative: sign out of the app and back in again, which returned them to the top-level menu. (Boy, did that ever elicit a sigh of wonderment from the observation party!)

Do you have socially-transmitted functionality in your design? Are they things that users can live without and will be delighted when they hear about it from a friend?

We’re celebrating this year’s User Interface 16 Conference’s fantastic program by giving everyone access to last year’s great show. The recordings and slide decks contain these great topics:

• Engaging team members in the design process
• Developing a content strategy
• Designing for mobile
• Evangelizing design within the corporate culture
• Understanding styles of decision making
• Incorporating testing and prototyping
• Making successful personas
• Evolving design ideas
• Creating a UX library

You’ll hear from these top UX experts: Luke Wroblewski, Kristina Halvorson, Nathan Curtis, Dan Rubin, Leah Buley, Dave Gray, Kim Goodwin, Tamara Adlin, and Jared Spool.

How to get the free recordings?

It’s easy. Just sign up by October 13, 11:59 PM ET and you’ll get last year’s UI15 talks and materials for free. No tricks, no gimmicks. We’ll send you an email with details on how to access this bundle of goodness.

Now hurry and get last year’s UI15 recordings before October 13, 11:59 pm ET.

She’s been a designer for a long while now, having worked on some impressive projects and developed real skills. As she described the different projects, I could tell, however, that something was missing: how would she grow?

Don’t get me wrong. Each project was pretty neat and jam-packed full of cool challenges that every talented designer would want to sink their teeth into.

I suggested she direct her search in a different direction. I told her to focus on who her next manager should be.

In my job, I get to meet a lot of great designers, some of whom are working on projects that, to an outsider, might be considered dull: accounting applications, chemical analysis equipment, and even tax forms. Yet, they love their work, not because of the subject matter of the project, but because they have a great manager that makes every day fun and challenging (in the good way).

I’ve also met designers who are working on some of today’s sexiest design problems — working with the latest technologies on cutting edge, high visibility, society-changing designs. And they’re miserable because they have a manager that makes each day hard and frustrating.

When you have a great manager, the project barely matters. And when you have a crappy manager, the project barely matters.

The advice I’m giving to senior, more experienced folks is not to think about their next project as much as they think about their next manager. What traits should that manager have? How do they support their team? When things get rough, how do they deliver guidance? Do they regularly give out praise? Do they take a deep interest in the work and in their employee’s future?

I recommend folks interview the entire team and learn what it’s like to work for that manager. What happens when the going gets tough? What examples are there of team members growing, learning, and getting encouragement? Do team members talk about how the manager exhibits the desired traits?

My good friend, Amy Jackson, who works as a talent agent for wünderkind UX designers, suggests you take it a step further and ask the hiring manager for his or her references. Amy says to tell them you want to make the right decision and you need to check them out. Her thinking is that if the hiring manager isn’t secure enough give out sound references, they may be sending a signal. I think there’s something to that.

Great managers are what make a job great. Are you thinking about what you’d like to see in your next manager?

Story mapping is a way to build a model of user experiences. More than that, in the Agile context, it allows you to tactically plan for what should go into each release. It is a way to get everyone on the team thinking and talking about user experience. Getting people into a discussion mode starts to create a very collaborative environment.

Jeff Patton is a consultant and expert in Agile development. In his sold out virtual seminar, Story Mapping for UX Practitioners: Tying Agile and UX Together, Jeff outlined how to create a story map and how it fits into the Agile process. Jeff ran short of time to answer all the questions during the seminar, so Adam Churchill caught up with him to answer those remaining for this podcast.

Here’s an excerpt from the podcast.

“…A lot of the answers to selling [story mapping] is, to not, just get started. If people can see and physically engage with something big and something they can touch, [the answer is] to get it up there and get them to engage in it.

I’ve seen a lot of folks spend a lot of time trying to introduce the concept to people, trying to convince people it’s a good idea for them to do it. If you’re a user experience person, build one of these maps on the wall, physically in your area, and if you’ve got someone to collaborate, lead them over to it and say, “This is what I’m seeing happen. The person using our product is doing this, this, and this. And here’s where the real pains are.”

And when I’m working with people on these things, I really watch closely for their body language. I watch for people to start to point and start to use words like “here” and “there” and “down here” and start to engage with it. I’ve found that these things end up selling themselves. Trying to sell it doesn’t work.

There are a lot of products that are hard to sell. And I think I’ve heard from people talking about TiVo this way. TiVo has a hard time telling people what their product does and why you like it, but you use it and you know why you like it. And it does better being sold via word of mouth, or maybe you just have to experience it…”

Tune in to the podcast to hear Jeff address these points:

• Who do you have build the story map?
• How do you get the right people in the room?
• How do you story map when you’re designing with multiple personas in mind?
• How many users should you interview prior to building the story map?
• How do you ensure non-functional requirements don’t fall through the cracks?
• How do you scale this process to different-sized projects?

Do you incorporate UX into and Agile environment? Share your thoughts with us in our comments section.

Recorded: September, 2011
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Adam Churchill: Hello, everyone. Welcome to another episode of the SpoolCast. Jeff Patton recently joined us for a Virtual Seminar titled “Story Mapping for UX Practitioners: Tying Agile and UX Together.” Now, the seminar sold out, and the activity we were watching in both the Adobe Connect room as well as the Twitter stream was a lot of fun to watch. Lots of good comments, lots of good questions.

Jeff’s seminar spoke directly to folks working in an Agile environment who struggle with knitting user-experience design practices together with the iterative process they work in.

Jeff’s graciously offered to come back and tackle some of the questions we didn’t get to address in the seminar. If you didn’t listen to this particular seminar, you can get access to the recording in UIE’s growing User Experience Training Library, which presently has over 70 recorded seminars from wonderful topic experts just like Jeff Patton.

Hello, Jeff. Welcome back.

Jeff Patton: Hello. How are you doing today?

Adam: I’m doing very well. We had a lot of fun yesterday, didn’t we?

Jeff: We did have a lot of fun. We packed a lot into a short amount of time.

Adam: Well, let’s get right to it. For those who weren’t able to join us yesterday, can you give them an overview of what we did talk about?

Jeff: Yeah. My goal was to introduce people to a practice, something that I’ve been doing for a lot of years and something that’s growing in popularity. A lot of people are doing this. We focused on story mapping. And for a UX person, I’ll tell them story mapping is a way to build a map of user experience, something like task analysis.

I’ve seen lots of flavors of task analysis that yield sort of a map that looks like a story map. But if you’re working in an Agile context, you’ve got to build a backlog and come up with a bit of a tactical plan for what we’re going to put into a release and how we break it down into bits and pieces to build.

So we talked about that idea of a story map and how it sort of plugs that hole. And the big benefits, for me, are we’re able to tactically plan and execute like we need to do in an Agile context, and we’re able to get everybody thinking about user experience. So, for me, this is why it’s a bit of a bridge-gapping practice.

So during that talk, we talked, basically, about what an experience map was and how to quickly create those. And then we went into a lot of depth about what user stories are and what they aren’t. And one of the biggest misconceptions, or one of the questions I hear constantly, is “How do I write good stories?” One of the points to make about stories is they’re called stories because they were meant to be heard. They were meant to be discussed and talked about, and how they’re written isn’t as big an issue as what people talk about and what pictures they form in their heads.

Definitely, we have to write things down, but the form that we write them is really contextual. Then, when we combine these ideas, of the idea of a story or the things that we talk about and the idea of something like an experience map that lets us see the big picture, that’s where we get the story map.

After introducing that idea, we talked about the basics of how you build a map. Start by getting the big picture, what I would call the backbone of the map, down, and some of the details, then how we pile in lots of details. And then, where we ended up with was talking about how we use that simple square structure of a story map to carve out or slice up a product into incremental product releases.

This is where I think the shape of the map shines. It arranges information left-to-right based upon users’ experience and decomposes it top-to-bottom into parts. And when I slice it left-to-right, I start planning or thinking about releases in holistic product slices. And I get better releases. I get both thinner releases, releases that have less in them, and more comprehensive releases, releases that really satisfy users’ needs.

That’s where we ended up. There was a last tail-end section that I came into the seminar hoping that I could fold time or do a lot more than we did. And the section we didn’t get talked about tactically working with story maps, and tactically working with stories for that matter, during Agile-style iterative and incremental development.

Adam: Well, let’s get to some of those questions that we didn’t get to answer yesterday. There was a question about, how do you sell to the group, and how do you get started with that group?

Jeff: A lot of the answers to selling it is to not, to just get started. If people can see and physically engage with something big and something they can touch, it’s to get it up there and get them to engage in it.

I’ve seen a lot of folks spend a lot of time trying to introduce the concept to people, trying to convince people it’s a good idea for them to do it. If you’re a user-experience person, build one of these maps on the wall, physically in your area, and if you’ve got someone you’ve got to collaborate, lead them over to it and say, “This is what I’m seeing happen. The person using our product is doing this, this and this, and here’s where the real pains are.”

And when I’m working with people on these things, I really watch closely for their body language. I watch for people to start to point and start to use words like “here” and “there” and “down here” and start to engage with it. I’ve found that these things end up selling themselves, and trying to sell it doesn’t work.

There are a lot of products that are hard to sell. And I think I’ve heard from people talking about TiVo this way. TiVo has a hard time telling people what their product does and why you like it, but you use it and you know why you like it. And it does better being sold via word of mouth, or maybe you just have to experience it. Does that make sense?

Adam: It does. It does. And yeah, there’s a list of products like that. Twitter would be, I guess, another good example. You don’t really understand what it is until you use it.

Jeff: Yeah. Yes. Something like that.

One of the key points out of yesterday’s discussion was, and several people pinged me afterwards, and I’d asked them, “What were your takeaways from this?” And I strongly made the points that it’s not what’s written on paper that matters; it’s what’s in people’s heads that matters. We’re working really hard to collaborate together and form shared understanding in people’s heads, and that’s a value that people don’t focus on much, and it’s a real benefit we get out of these big, simple models on the wall.

Adam: So, Jeff, who do you have to have in the room to build the story map? Do you involve clients, the development team, the user-experience designers? Who’s in the room?

Jeff: What’s interesting about a story map is–well, I’ll go back. I’m lazy. I don’t want to build multiple things. A story map, initially, for me, is about thinking through and understanding user experience. Subsequently, it’s about explaining user experience to other people. And then when we start breaking things down and planning, it starts to be, well, about that, about planning and about tactically figuring out how we’re going to get this product built. And there’s different audiences for each one of those activities, as you can imagine.

When initially using the story map to kind of understand what I’m doing, maybe this is a habit I picked up from working in an Agile context. I like to pair, and I’ve seen a lot of designers that focus on pairing. And there’s an old Yogi Berra quote: “Pair up in threes.” So I like these small groups of two, three, sometimes four, to think through and build things. It’s a single-pizza-sized group. These are the people you want to pull together, that have some understanding, to initially build the map.

Once you’ve got a map initially built or initially structured, then I want to start to pull in other people with different kinds of experience, different sorts of subject-matter experts, and I want to vet my understanding with them, and I want to add to it and change it and richen it up. If, by building the map, I see I’ve got holes, and I’ve got to go out and do more research or learn more, then I might do that and come back and fatten up the map that way.

Then, once I’ve got a little bit of a map that starts to explain a product, oftentimes we’ve got to share that with other stakeholders or share the vision of what we’re getting with this product with other people. So we’ll bring people in. And the purpose is not to add to the map or validate it so much as use the map to explain, “This is how we see people using this new product, and this is the flow of that use, and this is how it breaks down into pieces.

Then, downstream, when we have to start taking this apart and planning it, that’s when we want to pull more engineers and more QA people, other people that know, tactically, what it’s going to take to get this thing built, into the room.

So it’s not if all those other people should be involved. It’s more of a when they should be involved.

Adam: Any tricks to helping you understand if you’ve got the right people in the room?

Jeff: Adam, looking back, there was a question. And I’m going to repeat somebody’s question. What if a key stakeholder, a product manager, checks out of the process and starts thinking, “That’s not my job. It’s engineering’s job”? And the reason I’m bringing them up is, how to tell you’ve got the right people in the room, sometimes they sort of vote with their focus, and if they’re losing focus, they may very well be the wrong people.

Now, getting the right people in the room. One of the things I’ll focus on is a team, I leverage a mantra and often draw a Venn diagram that looks at these three concerns: valuable, usable, and feasible. Valuable to the organization building the product, usable to the people that end up using it, and feasible to build.

Now, strictly speaking, if it were just building a map of user experience, I could just focus on people who understand users and how they work with things, and the right people to initially build the map could be just user-experience people. Some organizations just have business analysts that take care of that capability.

But I want people in the room that are also thinking with their business hats on and really gaining some empathy and understanding for users. And while they may not be contributing to the map, I want them in the room.

Then there’s a dysfunction I commonly see and everybody commonly sees. A business comes up with a great idea. User experience works out the details of how users need to work with it. And then we produce all those details for engineering and engineering says, “That’s going to take a long time to build.” And then we go back to the drawing board because it far exceeds the budget that we’ve got.

Having engineering in the room earlier on gives us early warning for that, and oftentimes gives us perfectly reasonable ways we could do things that would be cheaper, more cost-effective to build and still satisfies users and still reaches the business needs.

The right people in the room for me is a balanced team that includes someone who understands some engineering concerns, someone who understands business concerns, and initially, when we’re building out the experience, people that deeply understand users’ experience today and then the experience we’re striving for with the new product.

Adam: Edwin wanted to know how you do the story mapping when you’re designing with multiple personas in mind.

Jeff: That’s a great question, and I’m glad you asked it. I’ll answer another question first, or point out another concern first, and then answer it a little bit more squarely.

There’s a standard user story template that’s used by a lot of people in Agile development. It’s the, as a kind of user, I want to have something do something so that I get some benefit. And that template, in the “as a,” it seems to call for one answer there. And for me, I’m always looking at the product from the perspective of multiple personas or different kinds of people that would use the same functionality and have different concerns when they’re doing so.

Edwin’s question was, how do you story-map when you’re designing with multiple persona’s in mind? The story map is about the product and it’s about the experience. Gosh, it’s a little bit about both. You need one map because you’re going to build one product.

Initially, to get the shape of the map in place, I’ll think through it from the perspective of one persona and get the backbone and the basic shape of the map going, and the basic shape of the map starts to reveal the shape of the product. And then I’ll grab other personas with different concerns and walk through it from their perspective and see if it breaks it, changes it, does other things.

And to remind people that this product is for multiple personas, at the top of a story map, we’ve got big activities that break down into users’ tasks, and those break down into the tactical details of what we might build. Right above those activities or above sections of the map, I’ll post those multiple personas or hang them there, so that people can see, clearly, these big activities in this map serve these different personas, and they have different concerns.

Let me give one more detail here. Some folks that are building an application where multiple personas use the same functionality will go through and tag all the stories. They’ll tag their personas each with different-color dots, let’s say, and then go through and tag all the functionality that’s particularly relevant to one persona with that color dot.

This does a little bit of an analysis so that we can see that for these personas, they’re really concerned about this functionality; these personas are concerned with this other functionality. And we can see a bit of overlap that way, too.

Adam: So when you’re doing that research, how many users do you need to interview to know that you’ve got what you need to build the story map?

Jeff: Research is a troublesome thing for me. I’ll be honest with you. I came to doing what might be more rigorous user-experience work in about 2001. Before that, I was just spending a lot of time with users and building stuff, and I didn’t know that I was doing research. I would spend a lot of times with users using the software. Maybe I didn’t know that was contextual inquiry. So it wasn’t so rigorous. It was after 2001, when I dug in deep, that I started realizing, to be rigorous, I probably should be doing a few other things.

Now, if I fast-forward, I often find that organizations don’t do any research, because to do it rigorously takes a lot of time. So they go back to doing what they were always going to do, and they follow what I heard Jared call the MSU process, or “making stuff up,” only Jared didn’t use the word “stuff.”

Adam: [laughs]

Jeff: So, how many users. In working with some folks, for every distinct audience segment or role, I’ve heard general guidelines of three to 10 people. And it depends on how much variation there are in those roles, so if I were covering half a dozen roles, I might be interviewing lots of people.

However, one of the strategies I leverage when initially building personas and initially building story maps is to leverage tacit knowledge that’s in the room. Pruitt and Adlin talk about building assumption-based personas, and I build assumption-based story maps and assumption-based personas. By initially building a story map, we make clear what we do and don’t know, and then we can look back at this and say, “Gosh, where is our information hazy?”

Then let’s design a research plan that helps us not just learn about people. Since we’re modeling work or activity with a story map, my research plan can be very focused on the specific activities where I don’t know anything. And more importantly, if we’ve got businesspeople in the room, we’re looking for this intersection between stuff I don’t know and stuff that matters a lot, and that’s where we’re going to focus. [laughs]

Adam: Jeff, just a couple questions on nonfunctional requirements. And Ariadna asks, “If story mapping mostly concerns itself with functional requirements, how do you ensure that some nonfunctional requirements don’t fall between the cracks?”

Jeff: That’s a great question, and that’s a great question that’s applicable in any software-development process or any scheme to try and get your head around what requirements are for what to build.

So I don’t know if I have any fabulous answers. And one of the shortcomings sometimes with user stories in general is, I mentioned the initial idea of user stories, where you write down something and have a discussion, and out of that discussion comes the details of specifically what to build, and over time, the goal is to get smaller and smaller stories so that we could build smaller and smaller things.

When you look at nonfunctional requirements, the things that automatically pop to mind for me are things like scalability and performance and usability and all those things that people call “ilities.” Security, which doesn’t end in “ility,” that’s one of those also. These are big, cross-cutting concerns. I don’t just implement the scalability story and call it done. They’re quality characteristics of the product, just as usability is.

You don’t measure usability on a single check-box. It’s not necessarily sensible to if we’re concerned about usability of someone accomplishing a whole task.

So, let’s track back. Those sorts of nonfunctional requirements, yeah, we don’t want to lose them, but they’re cross-cutting. They’re big. I find that the story map helps me a lot because they’re often activity-centric, and the story map reveals what those are. So I might have particular scalability and usability and performance concerns in one particular activity and a lot lower scalability-usability-performance concerns in another. One of the things I’ve done personally is go up to that activity level and document or record stuff at that level.

As Ariana asks, how do you keep them from falling through the cracks, or falling through the story so to speak, oddly, it’s not easy to make them stories. They become concerns that we constantly pay attention to during development. We constantly do things to measure usability, maybe by testing, measure scalability by testing, except different kinds of testing.

Then, as we encounter problems, that’s when we get these more emergent, tactical stories that we inject to fix things or make things better. I document the concerns up at the activity level, and I would pay close attention to them during development and inject stories to correct problems as I find them.

Adam: One of our attendees acknowledges that he understands how you break stories into smaller chunks and chunks that you can develop in shorter time frames, but how do you do the same with those usability tasks that encompass full systems, like ease of use?

Jeff: [laughs] I’m looking at Eduardo’s question, and he also has a cool term after that. He says “confusability,” which is a term I’m going to use from here on out. [laughs]

Usability is a nonfunctional requirement. It’s a nonfunctional requirement sometimes. Some people are more focused on the technical nonfunctional requirements, but things like usability is a strong one. And just like other nonfunctional requirements, they’re big. Like Eduardo points out, they’re not localized to a little story.

We have to look at them as a cross-cutting concern. And it’s during this iterative and incremental development, we have to keep asking, “Is this activity usable?” And we add more stuff to it: “Is it still usable?” And we add more stuff to the software: “Is it still usable?” We keep checking that stuff over and over again.

And exactly how and where that goes in Agile software development, and exactly what story card it gets written on, well, there’s no set answer for that, and there’s no one story card it goes on, and it’s not so simple. I find that you’ve just got to keep your head engaged [laughs] while you’re doing this stuff. And again, back to the previous question we talked about, I like documenting those concerns at the activity level, and I like testing for those concerns at the activity level.

Adam: One last question, Jeff, and I know that you and I talked about this one as we were kind of mapping out this podcast. And it’s a bit broad, possibly vague and tough to answer out of context, but I’m going to ask you to give it a shot because I think it’s important for our audience. This technique of story mapping, how do you scale it to different-sized projects?

Jeff: [laughs] When we were talking ahead of time, I winced a little bit, because I get asked this question all the time. I find that different people who ask “How do you scale?” mean very different things.

So when we look at scale with respect to different-sized projects, I hear some people mean we have a lot of people working on this project. In some contexts a lot of people means 20, and in some contexts a lot of people means 200. I know some organizations where they put 20 people on the project, but those 20 people are spread across five different countries.

Scale, for them, isn’t big in terms of number of bodies; it’s big in terms of number of time zones. I hear people talk about scale in terms of how big the product is: “This is something that’s going to take a year-plus to build, and it’s going to take dozens or over 100 developers to build it.” Scale means a lot of different things to different people, and it has to do with size of teams, size of product, geographic distribution, lots of other things.

So, given all that, given the question, my first question is usually to ask people back, what do they mean by scale? What I tend to find, though, is, for big products, for instance, it becomes difficult to build a story map for the entire product. That’s tough.

I’ll find I’ll end up building a lot of local story maps. We’ll break a big product down into separate problems and then map that problem and look at a single experience or a single activity. And I might create a big map for the entire product, but create it at a higher abstraction level. And it becomes more informational. It becomes not tactical. I don’t use it to find the detailed stories to push down to individual teams. Rather, I use it as some way to connect individual pieces that are going on with different teams or different groups of people.

And then one of the questions we answered in the online seminar and I always get asked, what about geographically distributed teams? That’s always an element of scaling also.

At the beginning of this, we talked about these different activities that revolve around a story map, and one of them is initially constructing it and filling it in and doing some planning. I find that nothing beats getting a core, small group of people to initially build that map, and getting them together face-to-face to do that. And even in big, geographically distributed teams, it doesn’t work to get a big group of people together anyway to do it. Get a smaller group of people together, and then the problem becomes, “How do I socialize that with a lot of people?”

And you get excellent story-map visualization practices, like Todd Warfel’s Task Analysis Grid. I don’t want to claim Todd Warfel’s practice as a story-mapping practice, but gosh, that Task Analysis Grid is a perfect representation of a story map that also conjoins a lot of the missing context that’s not always in a story map, like users and where they’re using it and pain points. There’s a lot of great things in that.

If we’ve got a large team, oftentimes it’s a small team that builds the map, and oftentimes we then need to build something that’s more of a design-communication version of a story map, to share that with other people.

Adam, I’ve hit a number of different elements of scaling, and we could probably go deep into that for a while, but it’s a sticky subject.

Adam: Well, Jeff, thanks very much. It was a lot of fun, and I appreciate you circling back with us. To everyone listening in, thanks for joining us and for your support of the UIE Virtual Seminar program.

Right now, few things are hotter topics that mobile in the design world. With the burst of smartphone and tablet technology, the mobile design landscape has just exploded.

With this new landscape comes a new way of thinking about design. It’s no longer about filling every pixel on the screen and implementing a multitude of different functionality.

The smaller screen demands that we hone our functionality down to it’s bare essentials. It means letting the content drive what we do, instead of putting the actions first. And it requires we rethink the basics of interaction, as touch gestures offer more flexibility than the mouse pointer.

Nobody has thought more about what it means to design for mobile that Luke Wroblewski. For the past few years, he’s been touring the world with a detailed explanation of what it takes do create great mobile experiences.

We’re really excited that he’s joining us for UI16. If you think mobile is in your future, you need to make sure you attend his full-day workshop. There you’ll learn everything there is to know about making a fabulous, interactive mobile web experience.

Mobile is the “hot topic” these days. It’s increasingly at the front of designers’ minds. In a world where the power and capabilities of the device in your pocket are so great, the possibilities become somewhat astounding. The mobile landscape is changing so rapidly that it makes developing a formal strategy to “figure mobile out” all but impossible.

Luke Wroblewski is at the forefront of the mobile design movement. He suggests that it’s better to put something, anything, out there and see how it fares. Excessive planning in the mobile space leads to missing opportunity after opportunity. Taking advantage of the market as it is today and the capabilities of these devices can lead to the refinement and evolution of your product.

Luke will be conducting a full-day workshop full of his thoughts on mobile, including why you should design for mobile first, at the User Interface 16 Conference, November 7-9 in Boston. Learn more about Luke’s and the other 7 full-day workshops at UIConf.com.

Here’s an excerpt from the podcast.

“…today, [mobile] devices have a lot of constraints based on the ergonomics. They’ve got a small screen. In many situations, you’re using them in environments where there’s other stuff going on. You’re not hunkered down at a desk for an extended period of time.

You may be at home on the couch watching TV, or you may be in a line somewhere, or passing some time in, hopefully, not the car. So there’s these constraints. Low bandwidth is another constraint. And when you use the devices, you familiarize yourself with what those constraints are.

But there’s also a lot of opportunities in terms of capabilities. And if you use lots of apps, you can see, how are they using the accelerometer? What have they done with front and rear-facing cameras? How are they using location in order to deliver information? How are they using the video port, the camera, the audio input? All those things can open up new ideas about how to take advantage of those capabilities in your service.

This is a device that you can use pretty much anywhere and everywhere. You have it with you all the time. Coverage of networks is way better than it’s been. And so, through the fact that you have it with you everywhere and anywhere and you can pull it out and access a network and access assets, all these new use cases emerge that you didn’t have before…”

Tune in to the podcast to hear Luke answer these questions:

• What is the alternative to sitting and planning your mobile strategy?
• Where should teams start to familiarize themselves with mobile?
• Is there an advantage to playing with as many apps as you can to learn about the interaction design?
• What are some things that make good mobile design stand out?
• What is the benefit of desktop operating systems emulating features on touch-based devices?
• How is multi-platform emergence affecting approaches to design?

Do you design for mobile? Share your thoughts with us in our comments section.

Recorded: September, 2011
[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Jared Spool: Welcome, everyone, to an episode of the “SpoolCast”. Today I have the amazingly awesome Luke Wroblewski, who is going to be speaking at UI16, our User Interface Conference.

It’s coming up this November. He’s going to be giving a full-day workshop on designing for mobile, a really hot topic. And he is the guy I know that knows the most about mobile, and I’m very happy he’s here today.

Hello, Luke.

Luke Wroblewski: