Conversion rate’s big crime is it focuses purely on pressing the purchase button, independent of the quality of the experience.

— Jared M. Spool (@jmspool) May 13, 2012

Immediately, I received several responses, all of them showing the common misunderstandings that people have about conversion rates.

The conversion rate has become a standard metric for many online businesses. I’ve seen clients watch it every day, looking at the variations they see and asking questions about why it changes (or doesn’t).

Unfortunately, conversion rate is probably one of the most dangerous and mis-used metrics available to site designers to measure how good their site is. They apply it as if it is telling them something and, worse, when they optimize for it, they can create a site that looks like crap and produces undesirable customers.

This is the first post in a series on using conversion rates, hopefully to clear up the common misunderstandings and help designers find better ways to measure their site’s success. In this episode, we’ll look at the basic nature of what a conversion rate is and why it’s such a crappy metric.

Avoid Ratios For Metrics

Conversion rate is a ratio. It’s the number of people who purchase (or sign up or whatever your “call to action” button does) divided by the number of visitors to the site or page. If you have a 15,000 people buy products out of the 1,000,000 people who visited your site, you’ll have a conversion rate of 1.5%.

Ratios are a problem because either the numerator (people who buy) or the denominator (people who visit) can change. Let’s say you still have 15,000 purchasers, but because of a “successful” marketing push, you end up bringing 2,000,000 visitors to the site. Now, you made the same amount of money from those 15,000 purchasers. But your conversion rate dropped to 0.75%.

Because it’s a ratio, you don’t have control over which side changes. The theory is that it should be uniform, but as we’ll see in other posts in this series, that rarely happens.

This means conversion rates often fluctuate for no discernible reason. It can be 1.5% one day, 0.75% the next, and 3.0% the next. This would just be a normal variation based on what’s happening with the visitors being attracted to the site. And this normal variation makes it hard to tell when something is broken or out of whack.

For any e-commerce site, I have the perfect advice on how to raise their conversion rate significantly. All they have to do is stop marketing. Once they stop marketing, the number of visitors will drop to only those who are already loyal customers.

Because those visitors are loyal, they are probably only coming to buy something. The ratio of purchasers to visitors will skyrocket. Sales will likely drop, but conversion will go sky-high.

Sounds great, right? That’s the other problem with the conversion rate ratio: it’s not at all related to the other business operations.

I have a little game I like to play with executives. I’ll put to doors on the screen. I’ll tell the execs that they can choose one door. Behind the first door is an increased conversion rate, but no increase in sales (in fact, a likely decrease). Behind the second door is a decreased conversion rate, but an increase in sales. Which would they like?

Every executive I’ve ever talked to has asked for the increased sales. My next question is then: Why focus on conversion rate then? That’s when I get that deer-in-headlights look, followed by a reduced focus on the conversion rate metric.

In the next installment, we’ll look at why not every visitor is someone you want as a customer.

I’ve learned that you can tell that a team is taking advantage of well-done critiques by the new, personalized language they are now sporting. They have a set of terms and phrases that only have meaning to them, but the meaning is deep and thoughtful.

I saw an example of this from Kate Brigham, as she talked about the work her team at PatientsLikeMe was doing. They had a term they used to describe the buttons on their pages: lickable. Lickable buttons are buttons that look like bright colored candies and are so vividly yummy, you just want to lick them.

They started employing these lickable buttons to get past the dull, mechanical look of the operating-system-supplied checkboxes and radio buttons. Lickable buttons are fun. They encourage pressing. They don’t look formidable, which is important when PatientsLikeMe’s designs are asking their users about serious things, like how much pain or fatigue they’re feeling due to their chronic illness.

What’s neat about this button nomenclature is that it’s 100% PatientsLikeMe. I’m not 100% sure of the origin story, but it sounded to me like it emerged during a critique session when the brightly colored buttons first made their appearance in a design. Someone made the comment about how they looked so delicious and the name just stuck.

This is often how these things work. Someone just says it and it catches on immediately. That’s the first stage.

That’s cool, but what happens next really excites me. The PatientsLikeMe team decided that being lickable is a good goal for future designs. Whatever that means.

Now, the team has the duty of exploring the true boundaries of the term. What does it really mean to be ideally lickable? When are buttons not quite lickable enough? When have they gone past the ideal lickability into something too undesirable?

It’s in these conversations where the team gets a chance to explore what design is really about. Well-run critique sessions let a designer bring proposed designs to the table, and the team discusses how close to an ideal notion of their design the can get.

This testing of the boundaries cements the language and gives everyone a way to talk about design in a positive, ever-learning fashion. The team grows as a result and the designs get better.

Critique is hard. Well-run critique is really hard. But the payoff is wonderful, because the team moves beyond the specifics of the designs into learning what makes a great design. Once that happens, you can see the output of the team jump to a new level.

That’s really exciting.

Kim Goodwin tells us that scenarios put the design into the context of how and why the user will interact with it. In 2011 Kim presented a UIE Virtual Seminar, Designing with Scenarios: Putting Your Personas to Work.

Today’s UIEtips article is based on a discussion UIE’s Adam Churchill had with Kim. It’s based on two questions from the seminar: Do you need data to effectively do scenarios, and what’s the difference between scenarios and storyboarding?

Read the article Designing with Scenarios: Putting Personas to Work.

Since personas are a tool and not your goal, there are lots of useful things you can do with them. In our May 22 Next Step Virtual Seminar, The Characteristics of Effective Personas, Whitney Quesenbery will show you more clever ways to make your personas actionable and weave them into your work.

What’s your experience with scenarios? Are you using data when developing them? Share your thoughts with us below.

Maybe so. Yet, that wasn’t the part that interested me the most. What interested me was something completely different.

A few months ago, I had conducted usability tests on the online service produced by the presenters’ company’s — the very one they showed in their presentation. Our study looked at several sites, asking shoppers to buy the products and services offered, looking for what each site does well and where their weaknesses were. It was really insightful on many different levels.

In our study, we watched more than a dozen of the presenters’ company’s own customers attempt to buy products. While many were successful, a surprising number weren’t, even though this company is the biggest in its industry (and hailed by many as the most successful). Their site looks slick, but when folks sat down to use it for its primary goal, it’s design put up a ton of frustrating obstacles.

In many cases, the users thought they ordered the product they wanted, only to discover upon receipt that it wasn’t at all what they wanted. As we watched those shoppers make their orders, we could see that they would not get what they wanted. Yet, the design of the site was so convoluted and confusing that the shopper never detected the problem until it was too late.

That’s why, when I was sitting in the conference presentation, I was quite surprised by what the presenters showed. All the examples were not things that made the shopping experience difficult. They were not things that were giving their customers problems. They were little things that, if dramatically improved, wouldn’t, in my opinion, affect the overall experience of the site or the satisfaction of customers buying their products.

I get that the presenters probably didn’t want to reveal their secret sauce to an audience of a hundred or so user experience professionals who might (like me) be working for their competitors. Maybe they were also working on the problems I saw in our study, but didn’t want to talk about that publicly.

However, the A/B tests they presented showed they were applying a ton of effort to optimize things that weren’t close to the things we saw preventing sales on their site. If the message was that A/B testing helps, I didn’t get that because I saw them futzing around with tweaking insignificant button text when there were huge deficiencies in the design that they still haven’t resolved.

Maybe the presenter’s team is working on these things that are wrecking their shopping experience? Maybe they aren’t using A/B tests for these hard problems? I don’t know.

Yet I’ve seen this before: A/B tests are fun and they easily become part of the dog-and-pony show. They give numbers and a clear, easy-to-see winner. They get execs and stakeholders excited, because “improvement” is easy to spot. But are we doing damage to our mission when we give so much attention to these tests of trivial design changes?

Part of this might be because the presenters were determining their winners by using the wrong measure. Conversion rate has lots of problems as a measure of success, but its big crime is that it focuses purely on the pressing of the purchase button. It doesn’t measure whether the users are happy with that purchase or whether they are delighted with the product they finally received and the way they received it. It’s easy to optimize for conversion while sacrificing a great experience. Conversion ≠ Delight.

We should be careful about how we show off tools like A/B tests. Someone might think we don’t actually care about the users’ experiences, as we optimize for overly simplistic measurements.

A data visualization, when done well, can be an incredibly powerful way to communicate information. It ultimately boils down to the choices you make in how to design and present the data. If you make the wrong choice you can run the risk of not accurately displaying the data or struggling to effectively tell its story.

Brian Suda, author of A Practical Guide to Designing with Data, believes experimentation is a big part of arriving at the right choices. As ideas end up on the cutting room floor, not only do you arrive at a great visualization, but you’re building your toolbox along the way. This practice and experimentation leaves you with a template to apply to future projects.

Essentially, arriving at the right choices now allows you to make better choices later. If you learn the best ways to represent different types of data, you can then apply that knowledge to any data sets you may have to visualize.

Brian will be sharing his insights on data visualizations in his virtual seminar, The Design Choices You Make for Information: How to Create Great Data Visualizations, on Thursday, May 17. You won’t want to miss out on Brian’s pragmatic tips and techniques. Save your spot in Brian’s seminar.

As always, we love to hear what you’re thinking. Share your thoughts with us in our comments section.

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

For the past few years, we’ve been researching why so many persona projects have such dismal results. We discovered there are basic factors that are critical for a project’s success, yet most teams ignored them.

In today’s UIEtips, I look back at an article that discusses five of these factors. We look at the role of research, who should be involved in the personas, and other essentials that differentiates between a successful persona project and a failed one. I’m sure you’ll find it helpful for planning your projects.

Read the article: Five Factors for Successful Persona Projects

If you’re looking to get more out of personas, you’ll want to tune in to Whitney Quesenbery’s May 22 Next Step virtual seminar, 7 things You Can Do with Your Personas. Whitney will tell you the 7 characteristics of effective personas and describe how to use them for improving user experiences. Learn more about this virtual seminar.

Have you tried to use personas in your projects? What have you found to be the keys to your project’s success (or the reason for your project’s demise)? We’d love to hear your thoughts below.

A while back, I wrote about the advantages of self design and the alternatives to self design. Of course, to be successful at self design, you have to use your design practically every day and you have to have a base of people just like you that’s big enough to support whatever business model pays for your work. That way, when something in annoying in the design, you’ll discover it quickly. And when you fix it for yourself, you’re also fixing it for a large enough user base.

A big problem with self design is that it doesn’t deal with things that you won’t do frequently with the design. One of those things is using the design for the first time, because, well, you can only do that once.

You see this in a lot of self-designed products: the initial user experience is rough, never explaining why you’d use any of the key functions, and hardly ever giving the user a great way to get started. Because self-designers rarely are working from a blank slate, the initial process of populating the application with data is not as smooth as the usage patterns once you get going. The entire getting-started process is really difficult.

While self design can help work out the rough edges of daily use effectively, design teams need to step away from the self-design approach to something more activity-focused for that out-of-box experience. Creating a process that usability tests with people new to the design will help keep things balanced.

With frequent and regular usability testing, you can answer questions like “Do people understand what this is for?” “Do they see how it can help them?” “Do they know how to get started?” “Are they overwhelmed by the functionality or choices?”

It’s ok to use self design to move a project along. It’s best to combine it with other types of decision styles, such as activity-focused design. This will keep the project balanced.

Mobile phones used to be big and bulky. Then we found ways to make them smaller and pack more stuff into them. Now we walk around with multi-purpose computers in our pockets. And guess what? We use them more than ever for things we never imagined we could do.

What if we did that same thing for our UX processes? What if we could “smallify” important artifacts to make them easier to carry around? Would we use them more for things we can’t imagine?

In this week’s UIEtips, I talk about the Short-Form Creative Brief – a compact design artifact we found in use by a team we’ve been working with. This tiny little document, which is small enough to carry around and pull out when needed, has changed how the team creates designs. It can change your life too.

Read the article, The Magical Short-Form Creative Brief

What do you do to keep your team on the same page during your design meetings? What design artifacts have you made smaller and easier to use? We’d love to learn from your experiences. Leave a comment below.

Great timing on this, as I am dealing with the same issue with a test I’m currently running. Do you have any guidelines for how to approach question wording? Other than running the same test multiple times with different wording, how do you know when task failure is the fault of your IA or the way the question is worded?

A great technique is to adopt an interview-based task design approach. You start by interviewing your participants to ask them about their previous experiences and current needs.

For example, if we were testing the IKEA site for it’s navigation, we’d recruit people who either have purchased IKEA furniture or are likely to do so in the near future. Then, during the first 15 to 25 minutes of the session, we’d interview them about their furniture buying process and desires.

In that interview, we’d get them to use all their own terms and define their own tasks. If it’s something they’ve done in the past, we ask them to re-enact it for us. If it’s something they’re planning in the near future, we look for them to show us how they think they’ll do it.

The trick is that we let them tell us the words they use. After you’ve done this with a few users, it’s likely you’ll hone in on some generic ways to formulate the tasks that don’t influence the tasks’ outcome as directly.

Back in 2006, I wrote about interview-based tasks and recorded a podcast about how to do them. Interview-based tasks have become a very important part of our usability toolbox, specifically to deal with this problem.

Our initial stab had simple tasks. One of them was “Find a bookcase for your living room that can hold 200 books.” Seems straightforward and nearly everyone completed the task easily. In fact, it seemed too easy.

It turned out that after reading the task instructions (we often write them on paper instead of delivering them orally, so the participant can refer back), every participant did exactly the same thing. They clicked in the search box on the IKEA home page and typed Bookcases. From here, it was pretty easy to get to the right product.

Yet, it was because everyone did the exact same behavior that made the UX hairs on the back of our neck tingle. That didn’t seem right.

In a second round of studies, we changed the task description to something more context-rich, avoiding any clues as to what to type in to the search engine. We ended up with:

“You’ve just moved into a new place with a living room that you love because of its expansive walls. Now, you just need someplace to put those 200 prized books that you’ve had in boxes forever. How would you do that?”

As we suspected, our participants’ behaviors changed. A couple folks typed bookcase into the search box. Others typed shelves, book shelves, book shelf, and one shelves for books. And others didn’t type anything into the search box, but clicked on the navigation links on the page, including storage systems. Most (but not all) found success using their own strategies.

What was happening was that we had guided the users with the wording of our task. By changing the wording, we saw different usability results. The design was the same, yet the results changed because of what we asked the users to do.

The wording we choose for our tasks is a critical component of the research we do, yet we hardly ever see any discussion of how to do it right or what happens when we get it wrong. If we want to make sure we’re guiding our teams in the right direction, we definitely need to nail the right research at the start.

Yet how often do we hear, “Could you give me some feedback on this design I’ve been working on?” It’s likely to be the most requested activity, but we do little to get better at it. Good critique skills are to be revered, but many of us haven’t learned what it takes, putting our projects at risk and driving walls between team members.

Recently, I’ve been discussing critique skills with some clients and it reminded me of an article we published back in September 2008, What Goes into a Well-Done Critique. It’s an important topic that doesn’t get a lot of attention. So I thought it was worth a second look. After studying the practices of design teams, we noticed that there are specific elements always present in a well-performed critique. Today’s article describes what we’ve seen in our travels.

And, as it turns out, this Thursday’s UIE Virtual Seminar given by Adam Connor is Discussing Design: The Art of Critique. Adam will describe how to give, receive, and act upon feedback while confidently guiding your projects through beneficial feedback loops. Learn more about Adam’s seminar here.

Read the article, What Goes into a Well-Done Critique?

What elements do you think make a great critique? How has your team incorporated them into regular practice? We’d love to hear your stories and thoughts. Leave us your thoughts below

Content is everywhere. With the amount of content users are confronted with everyday it can be challenging to garner their attention. Compounding this problem is the fact that designers and developers are often tasked with writing content that end users see. This can be an intimidating prospect if you’re unaccustomed to crafting copy.

Luckily, Steph Hay, Co-Founder of FastCustomer comes to the rescue in her virtual seminar, Writing Content for Usability, full of her tips for writing compelling content. She explains that choosing the right words and tone are essential to getting users to take action. The audience asked a bunch of great questions during the live seminar and Steph joins Adam Churchill to address the ones that we didn’t have time for in the podcast.

Here’s an excerpt from the podcast.

“…focusing on a very specific audience is really the first step of writing compelling content. Then really considering that medium that you’re going to be using to communicate with that audience is the second step. How are you going to communicate on a homepage or a website or on Twitter or on a blog?

And then, how can you also use additional media, email for example, to help tell a story and compliment your message, which really takes some of the pressure off of you having to write everything you could possibly write for that audience in that one little spot that you’re probably writing content for.

Then, finally, when it came to focus, considering that network of folks around you who are going to help influence your message really needs to be a part of your defining focus, but at the very start before you write a single word on content. That first step of focus then leads into the compelling content. Compelling content that has these four characteristics really actually helps a user make the decision to take an action…”

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

• Is there a difference between Marketing Content and Usable Content?
• When should content be considered?
• Are there tools or activities that you recommend that help copywriters and designers work together in creating design and copy?
• If you take a task based approach, is it more about what the site visitor wants to accomplish than who they are?
• How do you avoid redundant content if you’re tailoring for more than one audience?
• Are there tips for those who design government websites?
• What type of voice should be used when trying to get users to complete a transaction?

As always, we love to hear what you’re thinking. Share your thoughts with us in our comments section.

Recorded: March, 2012
[ 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. Recently, Steph Hay joined us for her seminar “Writing Content for Usability”. Designers and developers often have to write content that end users see. In her seminar, Steph explained the four characteristics to compelling content for web and mobile experiences. She left our audience with practical techniques to write more effective, engaging copy that makes people do something like sign up, buy, or simply come back for more.

“Writing Content for Usability” has been added to UIE’s user experience training library, which presently has closing in on 90 recorded seminars from wonderful topic experts just like Steph Hay giving you the tips and techniques you need to create great design. Hi, Steph. Thanks for joining us today.

Steph Hay: Thanks, Adam. I love being here.

Adam: For those that weren’t with us during your virtual seminar, can you give us an overview of your presentation?

Steph: Absolutely. Really what I was getting into was how to go about writing compelling content. As you said already in the intro, and compelling content here is a sort of action-oriented content, the stuff that makes somebody want to do something. So what I outlined was the sort of process by which you might arrive at writing content.

That’s, number one, to focus on audience, medium, and network, and audience being really specific people. One person, if you can imagine that person sitting across the table from you, versus a wide demographic of folks from age 18 to 35. Being able to really focus on a single person sitting across the table from you would allow anybody to write content in an easier way because you actually can understand what that person might be asking, what are the sorts of questions she has, what are the answers that you can provide?

So focusing on an audience and a very specific audience is really the first step of writing compelling content. Then really considering that medium that you’re going to be using to communicate with that audience is the second step. How are you going to communicate on a homepage or a website or on Twitter or on a blog?

And then, how can you also use additional media, email for example, to help tell a story and compliment your message, which really takes some of the pressure off of you having to write everything you could possibly write for that audience in that one little spot that you’re probably writing content for.

Then, finally, when it came to focus considering that network of folks around you who are going to help influence your message that really needs to be a part of your defining focus, but at the very start before you write a single word on content. That first step of focus then leads into the compelling content. The four characteristics of that that I go over in the seminar and provide examples of include helpful, meaningful, result oriented, and confident. Compelling content that has these four characteristics really actually helps a user make the decision to take an action.

The third part of that process after you’ve focused your energies, written helpful, meaningful, result oriented, confident content is to go back and make sure everything is consistent in voice, structure, and tone.

Then, finally, what I did in the seminar is provide a step by step way, a four step approach, that folks can take if they’re actually writing content so they don’t stress out and actually arrive at an end result that’s compelling content that they really need to write more of, in my opinion.

Adam: Steph, is there a difference between Marketing Content and Usable Content?

Steph: Yes. In short, marketing is the content creation and testing process itself and usable is the outcome of that process. In fact, I should have explained this in my seminar because, now that I think about it, a bit of the feedback made me realize that some of the practitioners who attended understand “marketing” as home page content and “usability”, to them, means button content or call to action, which I’d argue is too compartmentalized to sustain.

As a reminder from the seminar, I mentioned those four characteristics of compelling content, meaningful, helpful, result oriented, and confident, and I showed home page screenshots really as apples to apples comparisons of how different organizations are demonstrating those characteristics.

Even if you’re just working on a back end, for example, UI or you’re writing on a technical document or something like that, that apples to apples comparison of the home page was explicitly, actively used by me in order to find that common ground between organizations.

You still have to have some forward face on 99.9 percent of the cases so that forward face tends to be a home page or a landing page. As a reminder, that compelling content that I mentioned intrigues a user to do something. So the problem is that most marketing content is written by someone who hasn’t actually spoken to the typical end user.

That person writes blindly based on what she considers to be interesting rather than by using the kind of language and truly substantive content that I think the end user needs. This is really at the core of content that’s usable. People who read marketing content that’s well written, they get it because they think you, as the person behind that, you get them and you’ve already found what sorts of messages they prefer.

I just want to say that marketing content and usable content don’t describe where content shows up. For example, marketing content isn’t just the headline on a home page or the about page content and usable content isn’t just a button nomenclature or call to action in the side bar.

Marketing content is really any content that’s written for a user and usable content is the outcome of effective marketing content because more users take action and the right action that you want them to take.

Can I use a little case study of something that just happened yesterday?

Adam: Absolutely.

Steph: OK. Cool. So FastCustomer, my startup, we’re doing usability testing yesterday. This is just a mobile application UI that I’m talking about right now. FastCustomer you never have to wait on hold again for customer service. So most people get it. They don’t need to be convinced that they should have this product. They download it. Then they understand that having a button called “Have them call you”, which was very user based language, explicit, came from the user, they didn’t have a hard time understanding that, either.

They pushed the button that said “Have them call you”. They knew someone at a company was going to call them if they pressed that button. But then, we quickly added the response language ourselves and the response language was “Call in Progress” which, during usability testing just yesterday, was making people literally lift the phone to their ears.

So here’s an example of a marketing hook that we used using the user’s language to get an action that we wanted the user to take and that the user wanted to take, but then the response that we wrote out of our own developer minds caused confusion and therefore it really wasn’t usable. Once I saw the users bringing the phone to their ears when really they didn’t need to be I just asked, “What did you think would happen when you first pushed the button?”

And from that, I got the language that I needed in order for the user to understand what was happening to really make it usable fully, which was simply just you can close this app any time. It’ll keep working. They weren’t sure what was actually happening with the call. They thought maybe they had to be on it and they thought maybe if they got another call it would interrupt it and that sort of thing.

So clarity here is a stronger indicator of reuse later than inadvertently introducing confusion because we’re using the wrong lingo. Even though we want them to stay in the app, we really don’t want them to close the app, at the end of the day we really want them to understand what’s happening. That’s really, I think, the best marketing content that we can have out there that’s really, in the end, usable.

Adam: It makes me think of we follow pretty closely the folks at Marketing Experiments. One of the things that Dr. Flint McLaughlin always says is that when you’re thinking about marketing copy versus content is that clarity always trumps persuasion.

Steph: Yeah, man. That was real clear yesterday. My designer, actually, had been there with me to go through the usability testing and we just looked at each other and I just said, “We just have to tell them they can close the app.”

Adam: When it comes to the process of writing content, we had some folks that wanted you to say a bit more about that. You mentioned that content is considered in two places in the typical design process and Sid wanted to know is that typically what you recommend? When should content be considered?

Steph: Yeah so, when I had gone over the process of how content typically is written today it was really born from my experiences in agency and consulting one-on-one with companies where it really starts at the very beginning when you’re thinking about information architecture.

Then, it concludes and it only appears again at the end when you’re actually going through all the pages that you decided to have during the information architecture planning and you realize that there’s content that’s missing on those pages so you hurry up and populate them right before launch.

This is something that I think needs to go away. Content should be considered before the project even starts just by answering the question what do we want our users to know? By doing that, we’ve already considered audience and the outcomes you have to express to them in order for them to care about what you’re saying. So, “what do we want our users to do?”, once they know that, is then the ultimate conversion point.

Without these two questions answered, what do we want users to know and then, secondarily, what do we want users to do once they know that, we’ll just get distracted during the project life cycle from the purpose. Even though there are several answers to each question, that’s OK. It’s just a matter of prioritizing from there.

But thinking about content so literally in the traditional design process as the site map and as the fill in the blank before the site launches, means that technology and creative design are driving at all times. And I think, you know, if I think about the content strategy side of things, inventories are only important if you’re an archival organization. If users won’t make any decisions based on that content, why include it? That’s a real question that you need to ask yourself.

If you happen to have a ton of content and you’re spending energy and time sustaining it rather than it actually helping the user to make a decision. That’s why I advocate for a design process in which every deliverable is brought back to the audience outcomes and goals. Who are we speaking to, what awesome things do we promise them that our competitors don’t, and what do we want this user to do?

Adam: Marley asks this question. Often our audience, our attendees, want to know from experts like yourself what tools or exercises are available for them. In this case, for copywriters and designers, are there tools or activities that you recommend that help them work together in creating design and copy together?

Steph: Yeah. I mean I can only speak from my own personal experience here, but I’ll just tell you what I do in both of these cases. I start with a text file, just a plain text file. I’ve definitely had clients send me comps, mockups of their new site design, and say here’s where we’re at, we need things for this and that. Frankly, I just tend to ignore them because I can’t be distracted by the design right now.

I know you’re being distracted by the design, but I have to think about the user. I typically start with a text file. In fact, for my own personal website at stephaniehay.com, did this for fastcustomer.com, done this for clients’ websites, oh and I know that Ben the Bodyguard, which I used in the seminar as an example, benthebodyguard.com, also followed this sort of process.

I, as a copywriter, created the content in a text file in conversations with the client, with end users, and then handed it to the designer and the designer really built the site around that. It was collaborative in that way, but in this process I started with the content. Once I handed it to the designer and some comps came back, actually, I should say, I made a few UI/UX suggestions in the notations as part of the content.

Otherwise, I left it entirely up to the UX designer to create wire frames around the content itself. In all cases so far, the designer has really loved this process. It’s liberated that person from having to think about the content because it’s already there and that’s what’s ultimately speaking to the user. It’s created a structure and a process around the most important stuff to be communicated without requiring the visuals to lead back to it.

Once I see the wire frames, then, in every case I’ve revised the content. I’m actually not thinking about UX in this case, I’m just revising content where now as I see it’s structured it could be a little tighter here and there or it’s missing something here and there. On a few pages, the designer has suggested different content, which is awesome, so it’s very back and forth and collaborative in that way.

Because the content can’t exist as vibrantly on its own, it evolves with the design and vice versa. It ends up being a much more enjoyable process and then a much more powerful outcome, too.

Adam: Let’s talk about prioritizing the content and messaging. Peter wants you to say a bit more about audience versus tasks. If you take a task based approach it can help when you’re trying to consider, I guess, the fact that it doesn’t really matter who you are, it’s more about what the site visitor wants to accomplish.

Steph: Right, right. No part of the creative process should ignore audience, in my opinion. Whether you’re designing an interface or building features specific to a type of work, you have to consider who is using it and what does that person need to accomplish in whatever task they’re trying to accomplish.

To ignore them when speaking to them, the written word would, I think, do two things. One, result in non-specific, static, boring content that really appeals to no one, which hence is the kind of shitty marketing content that pervades so much of what we must read today out there. Or, two, it complicates the writing process itself by making it a one way conversation which is difficult to write in the first place and, frankly, even more difficult to learn from.

So I’d argue that the audience can never truly be separated from task when it comes to choosing or writing the best content to help that user achieve a goal. That said, I do think there are some UX strongholds that all audiences understand. Using the phrase login, for example, rather than attempting to be different for the sake of being different, using something like access instead, for example. That’s just interjecting weirdness where weirdness doesn’t need to exist.

Or a field name called email address is totally fine, you get it, you don’t have to think about it, the audience rather, than something like where would you prefer to receive email? Most content we create, test, and stress over, which is really what I am addressing a lot in my conversations with folks, isn’t this cut and dry. It’s not choosing that UX stronghold label, for example, that doesn’t really take into consideration audience because it doesn’t need to.

Adam: Brooke wants to know how you avoid redundant content if you’re tailoring for more than one audience. An example here would be the features of a product, right? You might need to craft content that is specific to people that are resellers versus people that are actually the customers or the users of the product.

Steph: Yeah. I think if you have a lot of redundant content a problem may exist more with your IA than with the content itself. If your information architecture is unnecessarily broken out into audience specific verticals that force you to do a lot of redundant content and describing the same product or service then I suggest reorganizing the content around the subject matter itself rather than the audience.

Plus, once you have your content organized around the meaty stuff people are looking for then you can actually do some more granular testing of what’s working and what’s not. In practice, this requires that you choose a primary audience who will be reading that page and that’s really probably the most difficult thing for a lot of these very information heavy organizations and websites is to prioritize a primary audience.

If you can do that, and once you’ve done that, then you can just write the content for that audience. Then any other audience is pulled from that page onto other pages with more detail or different detail or it’s in the content itself but it’s otherwise hidden until clicked, some cute little JavaScript-y thing.

That way, your page is clearly speaking to one audience but offering more info for secondary audiences and beyond who either self-identify themselves as those types of audiences or they need more information they haven’t found yet and you know what that information is and you’ve just compartmentalized it in a way that’s hidden naturally.

Either way, you’ve now learned, assuming you’re tracking clicks, which other audiences are on that page often and what kind of content they’re looking for. I think the real problem, and why so much redundant content exists, is because we assume we’ve got these specific audience types who need to have the content set in this exact way and, in doing so, we actually introduce confusion.

Because, you know, aside from maintaining it being difficult, it’s actually difficult for the user to then sift through and figure out what is relevant for that person versus the other audience over there where it’s sort of saying the same thing but in a little different way.

Adam: Can you take that a step further and explain how folks that are creating government websites might think about that?

Steph: Yeah, yeah. That was a good question that came up during the seminar. It’s almost April 15, right? Having been on the IRS website I can definitely say yes, I have some tips about this. They’re really similar to the ones I just described, which maybe this is just a pipe dream right now.

Anyway, government sites, they’re especially tricky because the variability of audience type is so incredibly vast. But that said, the great aspect of a government site is that it tends to be a focused topic. So most agencies deal with a particular subject matter pretty fully. The best advice I can give is to take your five to 10 most common questions and to structure your site around those topics.

I mean, yes, I know there are plenty more questions that are asked but it’s mind boggling how much information is actually related to just a core 5-10 questions. From a structural standpoint, that means the core pages would include information relevant to nearly all audiences. I would say, ask a question like what policies and rules apply to most people who will be on this page, which is all about this very specific one question of those 5-10.

Include only the information that applies to most people who would be on that very specific page. Then from there, offer a couple buckets, one that’s oriented around audience self-identification, and one oriented around topic. In the case of the IRS, as a small business owner, I just need to know what I’m supposed to do with my quarterly estimated payments and then maybe there are some links on audience type that say if you are a disregarded entity, by the way, you are now called this or whatever.

Now, I’m looking based on audience. Or maybe there’s additional content related to topic so, are you looking for how you should be paying your annual taxes now? Something like that where once I’ve actually taken some action, either identified myself as this particular audience or identified that I need this particular information, now that additional content of yours or I’m taking to another page.

But most of my questions have already been answered by the content that applies to me and a great number of other folks like me. The other thing is taking this approach, which is a true funnel where the most general and overlapping information starts the site and continues getting more granular with each additional action the user takes, and keeps getting narrower then, will help the user feel like she’s going through an information heavy yet guided experience, rather than just being thrown every option and every detail and every link at the top level and expected to make sense of it and sift through it.

Adam: In the seminar, you talked about establishing or maintaining a consistent voice across your content. John’s looking for your best recommendation for getting users to complete a process like completing a transaction. In an example like that, would you use an authoritative voice or more of a personalized? I assume that means more of a conversational type of voice.

Steph: Well when it comes to transactions there’s really no hard and fast rule here, but transactions absolutely require confidence. The details are vitally important. No typos, no big swings in voice from friendly to matter of fact or from, in this case, personalized to authoritative. It just can’t shift. I can’t think that something has changed between the time that I’ve made the decision to start going through this process to the time that I’m actually completing my process.

If your marketing content here that’s successfully led a user into the conversion funnel has a personalized voice, I say just keep it consistent, same with formal/authoritative. The most important thing is that it does not shift so as to make the user stop and wonder if you’ve really paid attention to this process in full which, oh by the way, is probably asking for my credit card, too.

Actually, for example, the other day I signed up to auto refill this Starbucks card I have on my iPhone. This, by the way, is an incredibly smart way to get my money because someone gifted me the card digitally in the first place as a thank you, which then made me download the app which then made me pay, while I was in a Starbucks, for using the app which then was so fun and cool and novel that I never wanted to not use my iPhone to pay at Starbucks which, of course, now made me do this auto reload thing so I never run out of money on my Starbucks.

Anyway, the last screen before I click yes, confirm that I want to auto reload, which I have to do on the web, and P.S. I’ve just given you my debit card number, there was a typo. It said “it’s” instead of “its”. I actually faltered. Now, had my experience not otherwise been so compelling and fun I might not have confirmed things because it’s just such a boob move.

I mean, a typo from Starbucks, who can clearly afford copy editors. This was a totally preventable mistake. My point is just this, that Steve Krug said, “Don’t make me think.” Just don’t make me think. That’s not about taking an action in the first place but also about undoing one that I’m already taking.

Adam: Did that typo in this situation make you question the security or the authenticity of actually who the transaction was happening with?

Steph: You know, the Starbucks brand is so known, it wasn’t really questioning their credibility. It was a literal stop in my process that didn’t have to exist there where I stopped and I said, “Starbucks, seriously? You guys could not review this content?” It was an unnecessary questioning of their process because I work in the web, of their ability to actually capture these sorts of small but important details, important to me as a writer.

The whole point is just about that stop that exists. When you introduced a stop because you have created inconsistency, when you’ve raised a question that is in direct contrast to your credibility. Starbucks, they have the brand to fall back on. There are stores everywhere, you see them. Most of us, we don’t have that, so we can absolutely not raise that credibility question.

Adam: Steph, we talked a little bit about the .gov folks. Let’s switch a little bit to the .edu folks. We heard from the University of Texas libraries and they made a comment that their large academic library has dozens of subject matter experts and about 80 distributed web authors. They’re actually working on style guides but are afraid that alone won’t resolve redundancy issues or, as you were just talking about, inconsistencies that might arise from the tone or content quality.

Steph: OK. You know what, when it comes to voice and content consistency, I think that libraries and similar search based sites have some wiggle room, frankly. And here’s why, because audiences understand that the people who have written the books and research papers and abstracts that they’re searching for are different people.

So I think, in being the sort of body, the umbrella, the glue that holds all of these individual subject matter experts and authors together, the primary charge for the body above that is just to ensure that anything that’s not a subject matter based page sounds like it’s coming from the same brand.

A style guide absolutely can help with this, though depending on how large a site you’ve got, I’d consider limiting those as much as possible and having one person, a writer, edit them. Think about Google, which is arguably the biggest library, or Wikipedia. You go there and you search. That is the core of those things. Any other content around that should be relatively limited and, in that case, it should be, in my opinion, relatively easy, then, to pull one person into a project to go through and make sure there’s a consistency in voice and content.

The rest, however, for libraries and real search heavy types of institutions would be to surface the content as semantically as possible, I think. Various content management systems can help with these, tie into real time content searches coming from Google elsewhere and that sort of thing, but the real core focus of users on these sites is the search.

So I think, you know, not to stress too much about consistency and that, instead more, I think, the focus should be on limiting any pages that aren’t directly tied to search.

Adam: This has been awesome. Let’s sneak in one more question. In the seminar you cited a FlipKey example. They had a headline, “Rooms from $49 a night” and you talked about how that stated the obvious rather than the result for the person that the headline was trying to capture the attention of. Kate wants you to suggest what a better headline might be.

Steph: OK cool. So when I was talking about compelling content one of the characteristics I said was that it need to be results oriented and this is the thing that I think is most problematic and the thing that is most missing which is that people tend to state the obvious of what you’re going to get rather than what the result is of why you should get it from them. It’s a step beyond.

It’s like a bear hug that happens when you find out from somebody you’re thinking about purchasing from that there’s this whole other story behind it, there’s this whole thought about you as the user and what you’re going to get out of it. In the FlipKey example of rooms from $49 a night, that’s not a result. It’s just about the FlipKey promo.

It really has to be about what the user would get beyond what she would get if I went to Hotwire and saw $49 a night on Hotwire. Why should I buy from FlipKey versus Hotwire? I would say a better headline might be something like “The greatest night of your life will only set you back $49″. That, to me, sounds a lot better than “Hotel rooms from $49 a night”.

Adam: Steph, you are the best. Thanks so much for circling back with us. I appreciate it.

Steph: Thanks, Adam, and I appreciate everybody who’s listening out there. You can email me questions, steph@stephaniehay.com and that’s my website, too, stephaniehay.com.

Adam: Yeah, and I guess I should have mentioned this in the intro but at UIE we’re pretty particular about our site copy. We needed some help with it and we turned to someone who we think was the best person to turn to and that’s you. Anybody out there that needs help with their copy Steph’s a great person to turn to but please don’t steal her from us.

Steph: [laughs] No way. It’s impossible. Don’t worry, Adam. Thanks, though. I appreciate it.

Adam: For everyone listening in, thank you for listening and joining us and, of course, for your support of the UIE virtual seminar program. Remember you can get all the details on upcoming seminars at uievs.com.

Choosing that first user research project is critical. If you choose right, you’re the hero that changed the path of things forever. If you choose the wrong thing, then all that selling you’ve done is branded with being ineffectual (or worse, damaging).

In today’s UIEtips, we talk about the different techniques available for starting user research. I share what our favorites are and which ones we avoid.

Read the article, Starting Your User Research.

What techniques did you start your user research with? How did that work for getting people on board and inspired to create change? Leave us your thoughts below.

After all, a project is like an adventure. You start out heading in one direction, then things happen, and you end up growing your knowledge, your skills, and producing something that is brilliant.

It would be interesting to see how someone could create a portfolio that did a fantastic job of telling that adventure story.

What were the obstacles that you encountered? How did they force you to change your plans? What made them particularly gnarly? What piece of brilliance did you bring to the table to overcome them? What lessons did you learn in the process?

Who joined you on your adventure? How did you take advantage of their powers and special abilities? How did you compensate for their weaknesses? How did you resolve conflicts? How did you join forces to bring out something better than you could’ve if you had worked alone?

Where did you get surprised? What was it like to see your vision realized? What are your regrets? What are you particularly proud of?

Talking in terms of a main character that undergoes a change is a great way to approach a portfolio project description. It takes the focus away from the artwork and puts it on what you did to actually realize a design.

It nicely brings out what your special powers and talents are and shows how you compensate for your weaknesses. (After all, we all have weaknesses. Why not talk about them honestly and earnestly?)

Go ahead, tell your story. Show us what you can do.

I was wondering about the viability of integrating this methodology into a design agency that basically ends it’s work with a recommendations document with no real access to the development teams. It sounds like major shifts in people’s understanding of the process are needed to accommodate that.

I sent the question off to Jeff, who supplied this awesome answer:

In an agency context, especially with existing clients, making Lean UX work requires the proper expectation setting up front. From the beginning of the engagement, even before the pitch, start setting the expectation with you client that this engagement will be different. There will be frequent check-ins, reviews, requests for access to customers and no clear, defined scope at the beginning of the engagement. Instead, establish a time box (a period of time for which the agency will be engaged) and agree on a problem statement the agency is being hired to solve. The other key thing to articulate and agree upon with your client is how you will measure success. What metrics will you use to determine that you’ve built the right solution to the problem statement? Once that is agreed upon, the iterative Lean UX process can begin. As you iterate note how your design hypotheses are measuring up against your goals.

At the end of the time box the client gets the best possible solution your team could come up with in that time frame. It will be a better solution than the one you would have scoped out in the traditional up-front heavy planning approach because you will be several iterations into it and have some level of validation to your designs.

What do you think?

As the demand for UX professionals increases, there’s been a renewed discussion on the importance of having a portfolio. There are even some, like Whitney Hess in a recent SxSW panel, who assert that because UX isn’t really about the deliverables, UX pros shouldn’t have a portfolio.

I think quite the opposite. I think that a UX portfolio is an important part of representing what we can do. It’s far more important than a résumé, which is usually just a history of our employment with a few bullets that talk about major accomplishments.

The résumé shows our journey, just like how a map of the world shows the path Magellan took to circumnavigate the globe. But that map doesn’t tell of Magellan’s skill in taking on challenges and overcoming obstacles. That’s what a great portfolio does.

Recently someone showed me some UX designer’s nicely-designed portfolio. It had a beautiful layout and highlighted several deliverables, such as wireframes, sketches, and personas. It even went so far as to explain what a wireframe was and how personas are helpful in the UX process, in case the hiring manager didn’t know those things.

However, what this nicely-designed portfolio failed to do was tell me about the designer’s accomplishments. He didn’t talk about the projects he created the wireframe for. He didn’t say how he developed the personas or how they were used. He didn’t talk about places where the project got complicated and he worked through it, producing an elegant outcome given the constraints.

These are things that smart hiring managers look for. They want to see what you do when faced with challenge, such as a short delivery time, a difficult co-worker, hardware constraints that reduce the design options, or all three at the same time. They want to see the thinking that got you from the idea through to the final design. They want to see what really tested your skills and experience in ways you’ve never been tested before, and how you produced something even you didn’t think you were capable of.

Go ahead. Build an awesome portfolio of your story. Talk about the accomplishments you’re most proud of and don’t leave out any detail that shows what you can do when the world decides to test you. That’s the portfolio of a great designer.

[To be fair to Whitney, she wrote a wonderful article that says all this and more for UX Matters. You should read it.]

In today’s UIEtips, we look back at an article from Steve Portigal. Steve takes a look at how some past participants took him outside of the business questions at hand, and how their life circumstances impacted his client’s business strategy. Each of the four cases Steve describes in the article made a profound affect on how he moved forward during the session and what his client came away with.

Read Steve’s article: What to Expect When You’re Not Expecting It .

On April 17, Steve presents a UIE Virtual Seminar, Championing Contextual Research in Your Organization. He’ll describe the techniques, processes, and discussion points to make sure your design best fits the problem you’re trying to solve.

If you go to enough discussions on accessibility, you’ll hear about this old chestnut: Cuts in the sidewalk curbs, put in for wheelchair access, is also used by people without disabilities, like folks with baby strollers and shopping carts. The idea being that accessibility aids add value to everyone’s experience, when designed well.

Well, in a panel about the secrets of comedy writing, Rory revealed one of the tricks they use for finding all those old pieces of footage that show politicians saying things they probably now regret. It turns out it’s an accessibility aid that’s come to the rescue.

The Daily Show’s staff takes advantage of a software application that searches the text from closed captioning of CSPAN and news programs to find keywords and phrases. The closed captioning, originally designed for the deaf and those with hearing issues, is now used by the staff’s team to provide us with some of the best comedy (and, frankly, investigative journalism) on television.

Who would’ve thought?

In Adam’s seminar you’ll learn to:

• Structure projects to include more feedback loops
• Listen to stakeholder comments with increased objectivity
• Separate problem solving from critical thinking
• Give and receive critiques differently, and for the better

Watch Adam’s 3-minute preview or register today!

Discussing Design: The Art of Critique
with Adam Connor
Thursday, April 26, at 1:30pm ET
1:30pm ET / 12:30pm CT / 11:30am MT / 10:30am PT
90 minute online seminar
Register Now!

In this Next Step seminar, Steve Portigal will give you the talking points to make it happen in your organization. And once you find out how to quell cultural, budgetary, and process resistance to fieldwork, then you can create more analytical designs that make users jump for joy.

You’ll learn to:

• See field research as strong UX design tool
• Advocate for the adoption of contextual research
• Maximize the organizational impact of any research you do
• Engage the rest of the organization in contextual research

See Steve’s 2-minute preview or save your spot.

Championing Contextual Research in Your Organization
with Steve Portigal
We’re creating this seminar in cooperation with Rosenfeld Media
Tuesday, April 17, at 1:30pm ET
1:30pm ET / 12:30pm CT / 11:30am MT / 10:30am PT
90 minute online seminar
Register Now!

Getting data from your users is a fundamental part of creating great user experiences. Surveys are a great way to get feedback and learn about your users. The problem is everyone has sat through a painful, monotonous survey that asked a series of frustrating and seemingly pointless questions. As with anything in UX, if your users sense they’re in for a painful experience they simply won’t engage with your survey.

Caroline Jarrett, author of Forms That Work: Designing Web Forms for Usability and the upcoming Rosenfeld Media book, Surveys That Work, has been writing and presenting on survey design since 2002. In her Next Step Series Virtual Seminar, Designing Effective Surveys, Caroline offers tips on how to entice people to take the survey and keep them engaged to ensure you get accurate answers from them. During the seminar, we ran short on time to answer all of the audience’s questions, so Caroline joins Adam Churchill to tackle the remaining ones for this podcast.

Here’s an excerpt from the podcast.

“…We’re used to using little surveys anyway, but also there’s this idea of triangulating, which is to say, ‘I’m going to run a usability test on this. Perhaps I could do a survey alongside to see if the sort of things I’m seeing in my small sample are actually replicated in larger numbers.’

I can’t emphasize how useful that is. This is why I’ve become a real fan of surveys, particularly for organizations that are becoming a lot more mature in their user experience. After a while, you start to realize you’re seeing a lot of things in your small scale usability test and other one-on-one activities, and you’d like to know, ‘Are they really replicated out there in the same proportion that I’m seeing in these small samples?’ That’s where a survey can be really valuable, helping you check those numbers against each other…”

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

• What tools are available for designing surveys?
• What are the advantages or disadvantages of measuring the Net Promoter Score?
• How can you improve open-ended questions?
• How can you ensure you’re getting quality data if you offer participants a reward?
• Is there a lower limit of responses you need to be confident in a data set?
• How many questions should you have per screen?
• Do demographic questions undermine credibility?
• Can using surveys with other UX methods add extra value?
• Is there a benefit or payoff to designing a complex survey?
• Are there any guidelines to presenting a survey in person?

As always, we love to hear what you’re thinking. Share your thoughts with us in our comments section.

Recorded: March, 2012
[ 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. Last week Caroline Jarrett presented a Next Step Virtual Seminar, Designing Effect Surveys. The Next Step series of seminars are being created with help from the folks at Rosenfeld Media. Why? Well in this case, much of the thinking from the seminar comes from Caroline’s book on survey design, being published later this year by Rosenfeld Media.

This seminar with Caroline has been added to our UIE User Experience Training Library, which has over 85 recorded seminars from wonderful topic experts just like Caroline Jarrett, giving you the tips and techniques you need to create great design. Welcome back, Caroline.

Caroline Jarrett: Oh, I’m delighted to be here, Adam, it’s great.

Adam: For those that weren’t with us in the seminar, could you give us a brief overview of what we covered?

Caroline: Yes, I was talking first of all about how surveys are something that we don’t tend to turn to first as our main option in user experience. They tend to be something where someone comes along and says, “I’m going to do a survey anyway.” But the more I’ve been working with surveys and researching them and finding out about them in general, the more enthusiastic I’ve become. I think they’re a valuable tool that we can have in our toolbox alongside other things.

And so in the seminar, I was thinking about if we’re going to do a survey, how can we actually make it a really good one? And so I presented some tips on how to entice people to take a survey, and then once they’re in the survey, how to get them to engage with the questions they’ve got, and to answer accurately, because you don’t just want data, you want good quality data. We finished off with a few tips around: now you’ve got the data, how do you actually get some good stuff out of that data for your stakeholders.

Adam: Good, let’s get some of the questions that were left over or that we maybe felt were worth readdressing. There were lots of folk in the audience that were looking for your recommendations and thoughts on tools that are available to help design more effective surveys. Can you offer up your thoughts there?

Caroline: That really amused me, because after the seminar, I had a look at the Twitter stream. One of the people who asked that question had actually laid a bet with Twitter that I wouldn’t actually answer it. So I guess he owes me a beer now.

It’s a good question, and the answer I gave, and I think was the right one to give, is that my favorite survey tool is whichever one my client wants me to use, and that can be a whole range of different things. The high-end market research tools tend to be very, very powerful and can do almost anything, but they’re expensive, and they have a very brutal learning curve. In some ways, because you can do anything in them, there’s a temptation to do anything in them. Some of the surveys can end up becoming pretty complicated and unwieldy, which isn’t a great user experience sometimes. But if you really need to do a complicated cross-tabulation, then maybe something like Confirmit or one of the really high-end tools is what you need.

Then right at the other end, I’ve had to work with Word on many occasions. You know? Let’s get those questions coming out, around the organization in Word, and then maybe even present the survey in Word. As we all know, Word isn’t designed as a question and answering tool. There’s lots of things you can’t do very easily in Word either.

Right in the middle are things like SurveyMonkey, SurveyGizmo, those kind of online tools that you can get. I’ve had some pretty good experiences with them as well. Just with most other things, you tend to get what you pay for. If you want to do the free tool, you’ll be able to put something together, but maybe it won’t have some of the bells and whistles that you’d really like. So a slightly evasive answer, but just to give you a sense of the range of things that are available.

Adam: There were some folks in the audience that are struggling with Net Promoter Score. Is that a good thing? Is it a bad thing? What’s your experience with that?

Caroline: It’s both a good and a bad thing. You’ll find people who will say their Net Promoter Score is the ultimate question. I think perhaps I should just step back from the question very briefly, not everyone will be familiar with the Net Promoter Score, just to explain what it is. It’s not about Internet, it’s about net in the sense of if you subtract one figure from another you get a net.

So a Net Promoter is get people to assess whether or not they’d recommend us to their friend on a scale from one to 10. We’ll count people who give a score of nine or 10, which is to say yes, I’d very much recommend you. They’re regarded as the promoters. People who give a score up to six, I think, six or below, are regarded as detractors.

The net promoters, you subtract the percentage of detractors from the percentage of promoters, and you have your net promoters. And you ignore everybody who gave you seven or eight, because they’re in favor of you, but they’re kind of lukewarm in favor of you.

Some organizations find that that one score, it’s convenient to boil everything down to that one score, and just monitor that one score, and that is a key performance indicator, possibly the only performance indicator for their organization. And if you’re in an organization that values Net Promoter Score that much, you’d better get behind it and measure it and really work with it.

I’m a bit skeptical because I tend to be someone who thinks that user experience is very multifaceted, and boiling it down to just one number possibly doesn’t give us a full picture. Also, if you have a bad number, it tells you you’ve got a bad number, but it doesn’t tell you the why of that bad number. So that’s also a bit tricky.

But on the other hand, maybe that gives you the opportunity to come in and say, “I want to use some of my other UX techniques in order to delve into that number.” That’s what a Net Promoter Score is.

Just from the point of view of using a Net Promoter Score as a question in a survey, we have to ask whether that question means as much to the people answering it as it might to the business. There are some things where “I’ll recommend this to a friend” is a really important thing that people would actually do. But there are other things where you’d never recommend it to a friend because you don’t do recommending, and you certainly don’t do recommending of those type of things.

So you might actually be very enthusiastic about the product, but you just might not ever feel the urge to recommend hemorrhoid cream to your pals. You know? That’s not then giving a true measure of the value of that product. I have my skepticism about Net Promoter Score.

Adam: A couple of the questions people asked about open-ended questions, you were talking obviously a lot about the quality of the questions and how they get people to engage with the survey. Chris wants to know what the best way to improve open-ended questions is.

Caroline: So open-ended questions are where you give someone a big text box and they can type in what they like. It might be something like, “Tell us what you like about this service.” First of all, you need to make sure the question you ask is an open question in the sense of giving an open answer. If you ask a question that can be answered with “Yes” or “No”, people might very well be inclined to answer “Yes” or “No”.

I remember one survey which said, “What results are you achieving with this technique?” The answer came back, “Good results,” which was sort of an accurate answer, but not very helpful. You need to try and use the same sort of techniques in creating an open question that you might use on your probing on a usability test. You’re trying to get somebody to open up, “Tell me more about that.” That gives a cue that you’d like a longer answer. Same type of techniques there. Make sure there’s something open.

Make sure the question’s interesting. I’ve covered that a bit in the seminar as well. If it’s something that’s interesting and engages their imagination, they’re more likely to want to give you a longer score.

But also, be wary of the amount of burden you’re putting on people. Answering open questions is actually quite time consuming. And also, if your respondents include people who perhaps aren’t that articulate, or are answering in a second language, or are just a bit rushed then they don’t necessarily have the time to compose a lot of open answers. You want to think about the burden on them, and not give them too much actual typing to do. Be a little sparing on how many of them you ask people.

Adam: Nicki wanted to know about your thoughts about open-ended questions with an edit box for feedback.

Caroline: Right, so that’s the same thing. You’re asking someone for general feedback. Do you want to guide them to the sort of feedback you’re interested in, or do you want to just throw it open to the world, and say “Feed back whatever you like.” Those are the sorts of questions you need to ask yourself.

Which type of feedback is most valuable is a compromise between what do you know or think that users want to tell you, and also what do you know or think your stakeholders will actually make use of? So just giving people a box is an invitation for people to tell you what they think, but there may also be an implicit conversation that says, “Now I’ve told you my whole problem, I expect you to do something with it.”

If they’re going to pour out their heart and soul about some issue, and then it’s going to be ignored, that could also damage the long-term relationship with that customer. It’s a sort of balance of considerations between guiding them to something specific, but also giving them a chance to vent or praise or do what they want to do.

Adam: Colin asks about survey samples that are provided from what he describes as a big panel where participants with prizes, etc. Folks being rewarded to complete surveys like that, they’re often rushing through without thinking carefully. Any tips for making sure that you’re getting the best data from samples like these?

Caroline: That’s been such a hot topic this week in the world of the survey methodologists and market researchers. There’s a blog that I read from the Survey Geek. He posted about a panel that’s been in a recent market research conference, where they had a panel of what they called Professional Respondents.

Professional Respondents is not a polite term, really, in the market research industry, and it’s regarded as being people who are kind of gaming the system, who are answering as many surveys as they possibly can in order to actually make real money from it, rather than a little bit of pin money.

The challenge for the industry of the professional respondent is that some people are rather cynically exploiting it and are signing up to a zillion panels, maybe answering the same survey many different times. When you get your sample, do you know if you’re getting the genuine, real folks out there? Or are you getting people who are just desperately trying to make money at it? That’s perhaps the underlying problem of the panel.

And it’s known that there are some of these people out there, and it’s known that some people will just try and pretend, “This survey’s about owners of BMWs. Well, today I’ll pretend my rust bucket is not just any old rust bucket, it’s actually an ancient beamer.

I’ve done quite a bit of research with respondents who are members of panels, and my experience of them has been they’re really nice folks. They may be trying to earn a buck or two, but nobody ever got rich from being a panelist. They’re probably trying to be as honest as they can, providing you’re not giving them loads and loads and loads of really boring questions.

And so partly in response to that post on the Survey Geek’s blog, actually, it was from a colleague, I wrote my own post, which is to say “Why might your panels be cheating you?” That’s on my survey design blog myself. Because I tend to think that most of the panelists are just people who happen to be a bit opinionated, and don’t mind being paid a little bit of money for answering a few surveys, maybe a few surveys a week.

After saying all that, that would then say when you buy a sample from a panel, you might be getting some professional respondents, you might be getting people who think that answering surveys is fun, and perhaps you should be perhaps a little skeptical, but still use them, because they could be a way of getting in touch with an audience that is hard to reach any other way.

The people that you can’t easily recruit just by hanging around outside your local supermarket or something with a clipboard. It might be that getting that sample in is the only sensible way to do it.

And also, bear in mind that enormous numbers of highly respected brands are using those type of samples to test things out and getting good results from them. So why shouldn’t we as well, you know? It’s an interesting question.

Adam: Susan wants to know when you’re thinking about the number of responses you need to be confident in the data set, is there a lower limit to the number of responses you need?

Caroline: It’s a challenging question in statistics, the sample size, just as it’s a challenging question in user experience. I mean we’ve had debates for years about how many users are enough for a usability test, and in some ways, the same thing applies in surveys.

So it depends on the strength of feeling that you’re trying to investigate, and there’s statistical calculations that will say that if you want to detect an effect size of a certain level, then you can put numbers in a formula, and it will tell you what sample size you need. Then you have to think about your response rate, and say if I need 300 responses, and my response rate is 30 percent, then I’m going to have to do 1,000 invitations in order to get my right level of response.

The levels of response you need from a sample size calculation are nearly always way lower than what you might call face validity. Which face validity is, “Do your stakeholders, and not statisticians, believe in it or not?” And that’s also something we’re familiar in with UX, our stakeholders often don’t believe that the three or five or eight people we have in the usability test is going to be good enough, but we know it is. But how do we convince them?

And the same can be true that people can say, you know, “We have a customer base of 300 million people, how come we can get a decent, reliable, statistical result from sampling 1,000 people? From that, all I can do is say, “You kind of maybe need to look at the number of samples that national political polls use in the US,” Gallup Poll or whatever, probably looking at 1,000 people, and they get reasonably accurate results, within three to five percent.

If you can stand a little bit of risk, if you can stand to be not absolutely accurate, then you can get pretty good results from quite small samples.

Adam: More folks looking for you to sort of quantify their efforts, the team at SuperValu is asking if there is any general guidance regarding the number of survey questions per screen.

Caroline: Right, and I’ve been keeping screenshots of a lot of surveys over the last few years. I’ve noticed that with tools like SurveyMonkey, when people develop those sort of surveys, they often go for large number of questions on one page. When people are using the tools that I was mentioning, like the high-end market research tools like Confirmit, they tend to go for a very small number of questions per page.

Both of them have their merits, and the real expert in the experimental effect of survey design is Mick Couper, that’s spelled C-O-U-P-E-R. His book, which I highly recommend to people, is called Web Survey Design. I made it one of my books of the month on my blog last year because it’s such a highly respected book. He goes into all considerations of balancing out, whether you should have a page design, or whether you should put it all on one page, how you should change pages.

In the end, it probably doesn’t really matter, providing people don’t feel overwhelmed. They can feel overwhelmed in a number of different ways. One of the ways they can feel overwhelmed is if you give them too much on one page at once and they feel, “Gosh, that’s a long page!” Another way they can feel overwhelmed is, “I’ve answered page after page after page, and I don’t seem to be getting there.”

It’s rather like a design of an application or a website, it’s about giving people a sensible chunk of stuff to do, that’s not too much for them to get their heads around at once, and doesn’t seem like keeping them at it for too long. So it’s a question of balance, and I’m afraid there is no definitive answer, like don’t put more than three questions on a page. It’s just not that simple. It’s a question of bringing your design skills that you’re familiar with using in other parts of user experience to design a good experience here as well.

Adam: Our friend Cliff wanted you to say a bit more about a BBC example that you spoke to in a seminar. And he suggested it sounds like they might have used a boilerplate set of demographic questions. Does that in itself tend to undermine credibility? Might survey respondents or site visitors think the only reason they’re asking for that information is because they in turn have information to sell?

Caroline: It could be a question of trust. One of the things I talked about, about enticing people to take a survey is, “It’s a balance.” It’s another question of balance between do they trust you with their information, how much effort they’ve got to put into it, and how much reward they’re going to get back from it. Mostly, we’re offering people the reward of feeling good about telling us stuff. People don’t really feel good about sharing personal information. They’ve become very wary of it.

So in the case that I gave of the BBC survey when they asked me for some demographic information, I was making the point that I’m a big BBC fan, and I do trust them to manage my data very properly, so I was willing to give them that. But in other circumstances, people could be very wary, so hitting them with too much demographic can undermine that level of trust.

The other problem with answering demographic questions is they’re quite boring to answer. Going back to the point I was making about the professional respondents. One of the things that makes you start feeling that you’re being bored is where you’re being asked again and again for the same sort of “Who are you?” type questions, when the reward you’ve been offered for the survey is we’d like to ask for your opinion.

My age isn’t part of my opinion, my age is just a sad fact I have to live with, and I’d just rather it kept getting more than stopped getting more. There’s nothing interesting, and it’s not my opinion. It’s sort of dull to ask people about too much demographics.

You need to try and keep that to the absolute minimum you can, consistent with doing some things like checking “well, did the demographics of this sample approximately match the demographics of the target audience we’re trying to reach?”

Adam: Alicia wants to know if you ever use surveys in conjunction with another UX method that provides extra value, perhaps using the same participants.

Caroline: In fact, many of us use surveys with every usability test. Just yesterday, I was running a usability test, and I was using one type of survey, which is the variation of the Microsoft Reaction Cards that people may have heard of. If you haven’t heard of them, then I’d recommend having a look at Carol Barnum’s excellent talk, which is available on Slideshow about using the Microsoft Reaction Cards.

That’s like a little survey, so part of my test was I just wanted to make sure that I captured some data that was consistent. Another tool that you might be aware of is the System Usability Scale, SUS, which is another well-known little survey tool or questionnaire tool that people use a lot, right there as part of their testing.

We’re used to using little surveys anyway, but also there’s this idea of triangulating, which is to say, “I’m going to run a usability test on this. Perhaps I could do a survey alongside to see if the sort of things I’m seeing in my small sample are actually replicated in larger numbers.”

I can’t emphasize how useful that is. This is why I’ve become a real fan of surveys, particularly for organizations that are becoming a lot more mature in their user experience. After a while, you start to realize you’re seeing a lot of things in your small scale usability test and other one-on-one activities, and you’d like to know, “Are they really replicated out there in the same proportion that I’m seeing in these small samples?” That’s where a survey can be really valuable, is helping you check those numbers against each other. That’s where I think they really start to be worthwhile.

Adam: Paula wants to know if in your work and your experience, have you ever seen a true payoff in designing a complex survey, where there are things like dependencies, show if, the pulling in of previous responses into the next question, that type of thing?

Caroline: I see a lot of them in market research that clients want to test, “Well if you were interested in this, then I want to ask you that or the other.” You can do them, but I’m not at all sure that they’re as worth the effort. You can end up in a bit of a morass of complications, where the complications almost become an end in themselves, and the survey has a tendency to get quite long.

So a bit of skip logic, which is like the if-then, can be very valuable. If someone has told you that they have a religious objection to alcohol, don’t ask them a whole lot of stuff about their drinking habits, it would be insensitive and impolite. Just let them skip over all of that. Those type of things where there might be a few questions which are just going to be completely irrelevant and annoying for somebody.

On the other hand, too much logic in there, and maybe you’re going to lose sight of why you’re really doing it. Maybe you should just let some people jump out of the survey, and then catch another group of people another day, rather than having too much complication.

Adam: Nicki wants to know if you can tell us anything about presenting a survey in person. The example she offers up is if you’re at a sales kiosk or if you’re at a conference.

Caroline: Right, so it’s a great time. You’ve got customers, perhaps they’re quite rare people, and they’ve turned up at some event and you think great, I’ll catch them here. You do have to be so careful of their time. Good, short surveys are so important, and when they’re right there in person, it’s even more important, because they’re not there to do what you want to do, they’re there to do whatever they need to do that day.

You do have to absolutely prune it down to the absolute minimum you possibly can. Respect their time. Also maybe respect the fact that not everyone will want to answer there and then. You might even do a little bait and switch. Give them the opportunity to answer a couple of questions to find out that they’re really interesting, and then say, “Have you some more things you’d like to tell us?” Then give them a card to take away with maybe the URL or an email address so they have an opportunity to add more if they want to.

You’ll lose most people, obviously. I mean, you’ll get a very low response rate to that, but that might be better than alienating people right there and then, and giving them the chance to open up a conversation later, rather than them ruining the conversation now, could be the way to go.

Also, I’ve also been to conferences where I felt a bit overwhelmed and bored, and would’ve loved the opportunity to sit down quietly with a little survey for a few minutes. Maybe that’s just my type of nature. So yeah, you’ve got them there, you can catch them. If you’re careful about their time, then they will actually do things for you.

And one of the best examples I saw of a survey at a conference was at a technical communication conference, the Society of Technical Communications Symposium, and STC people, the technical communicators, all love words, and many of us love word games. And the designer of that survey had included a little game to play. It really hooked people in, and then people would add a couple of extra questions, they enjoyed doing it.

It was a great way, because it was very well designed, just a little game, and people did really respond to it, plus of course the prize drawing that went for it is another big incentive. People do love the opportunity of winning an iPad or something like that. At a fairly small conference, where they can see there’s only a couple of hundred people, they think, “Yeah, I might have a good chance of that.” They can see the actual item right there. That’s another way of getting to increase the perceived reward and more chance of them responding.

Adam: Very interesting stuff. You’ve got a book coming out through Rosenfeld Media later on this year, and one of the things that folks can do, they can go to the Rosenfeld Media site, and actually sign up. Rosenfeld Media will let them know when it’s available. I don’t want to speak for them, but typically Rosenfeld is pretty generous with aggressive discounts and free shipping and all kinds of cool stuff like that. Any other reason why they should sign up to learn more about when your book’s available?

Caroline: Well I mean, going to the Rosenfeld Media site is a good idea in general, because Lou really encourages all of us to blog about our books and respond to questions and those sort of things and it’s a really good policy. Plus there’s some other great Rosenfeld Media books coming out.

But the other thing directly related to surveys is that I do blog about surveys myself there, in general, from time to time. Of course, being very specific, I put a post on the site that has got the slides embedded from this talk, and it’s also got a selection of various resources that I mentioned within the slides, so it saves you digging around in the slides for a link or whatever. I just put the links there together, so you can simply click and be away.

Adam: Excellent. Caroline, thanks for circling back with us, we really appreciate your time.

Caroline: It’s been a pleasure to be here, Adam, thanks so much.

Adam: For those listening in, thanks for joining us, and thanks for your support of the UIE Virtual Seminars. Goodbye for now.

Yet thatʼs exactly what happened in one company. As a result of a merger, they swapped in a new system for everyone to use. Customer service reps with 20 years of experience suddenly found themselves incapable of performing basic functions, frustrating the loyal customers they were trying to serve. What was once a routine order change now needed a call to an understaffed help desk with huge hold times. Nobody was happy.

It was clear to see from this company that a simple focus on user experience could bring great benefit. Identifying simple improvements in the new system could smooth many of the issues, which translated immediately into improved customer service and better business results.

In todayʼs UIEtips, I share four tricks weʼve found work well when looking to improve the user experience of intranets and internal systems. These tricks create a quick list of fixes that reflect nicely on an organizationʼs bottom line. If you do any work on your companyʼs intranet (and you should be), this is a great place to start.

Read today’s article: 4 Tricks To Quick Intranet UX Improvements

While weʼre talking about internal systems, you donʼt want to miss James Robertsonʼs full-day UX Immersion workshop on integrating mobile into your organizationʼs intranet. James has a ton of great examples and a solid workflow on identifying where mobile can boost your intranetʼs effectiveness. Join him on April 25 in Portland, OR. Learn more about James’ workshop.

Workshop Speakers and Topics

• Getting Started with UX Inside Agile Development
  Hugh Beyer shows you how to apply practical techniques to integrate proven UX processes
  through effective communication.
• Lean UX: A Seasoned Approach to Designing in Agile
  Jeff Gothelf teaches Lean UX techniques that will radically change the way you approach
  your design process.
• Demystifying jQuery for Agile Prototyping
  Dave McFarland explains how easy it is to create interactive prototypes in just minutes
  with jQuery.
• Mobile UX: From Principles to Prototypes
  Rachel Hinman dives into the fundamentals and practical techniques for delivering the best
  mobile experiences.
• A Detailed Look at Designing Mobile Input
  Luke Wroblewski explains how to design intuitive mobile forms that help guide your users
  to put the right data in quickly.
• Mobile Design for Enterprise Intranets
  James Robertson reveals how to design great intranet apps using the latest technologies.

Learn more about the workshops and conference at UXIM.com.

Take the Mobile Design or Agile Challenge

How savvy are your agile or mobile design skills? Try your hand at the 9 question quiz and see where you land. Plus you’ll receive recommended resources to increase your Agile or mobile savviness.
Test your hand at the Agile or mobile design quiz.

Get $300 Off the Current Price

Don’t forget to register by Tuesday, April 10 with promotion code UX1649 to save $300.

Each quiz has 9 questions to test your knowledge. At the end of the quiz, you’re rewarded with recommended resources to further your knowledge. Plus you’ll discover if you’re as agile as a ninja warrior or as mobile as Superman.

Take the quiz!

This quiz is brought you by:

A dashboard is often the first screen that a user sees in your UI. The importance of visual design and data visualizations is high. But good looks aside, the dashboard has to meet the users’ needs. Beautiful dashboards are futile if the presented information isn’t useful to the user to accomplish their tasks.

Hagan Rivers has been designing user interfaces for 23 years. She uses her wealth of knowledge and experience to simplify complex applications. In her virtual seminar, Designing Dashboards: The Do’s, Don’ts, and D’ohs!, she shares examples of dashboards that get it right, and some that don’t get it so right. The audience posed a number of great questions during the seminar. We didn’t have time to answer them all, so Hagan joins Adam Churchill to address the remainders in this podcast.

Here’s an excerpt from the podcast.

“…This is a really common problem. You design this dashboard, let’s say it’s a mail dashboard, imagining a user that might have 50 or 100 messages a day, but then you get some user who only has two messages a week and some other user that has 10,000 messages a day and the dashboard breaks because it’s just not flexible enough to handle this. Right?

So you’ve got to think about how to create a dashboard design that can accommodate this varying amount of data. And I think the big thing here is to remember the dashboard is just a summary of what’s going on underneath. I think in the talk I showed a dashboard for an application that was managing alerts that were being sent out to people and there’s a list of alerts in the product that the user has sent out. There are hundreds and hundreds and hundreds of them but in the dashboard we only show the most recent two.

Now a different app might be five or 10 or 20 but you only show a few of the items and then you have a link to say, ‘Well, I want to go look at the rest.’ The nice thing about that is it scales really well…”

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

• What are the detriments of using 3D and pie charts?
• How should you handle pod controls such as minimizing and drag and drop?
• What kinds of widgets will help draw people to an institutional dashboard?
• How do you design for users that have varying volumes of data and frequency of visits?
• Are scrollable dashboards more effective than those that don’t scroll?
• Do tabs work on a dashboard page?
• Does the mouse hover tool tip help with crowded information?
• What if our users all want something different on their dashboards?
• Are there any good examples of dashboards on mobile?

As always, we love to hear what you’re thinking. Share your thoughts with us in our comments section.

Recorded: March, 2012
[ 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 edition of the SpoolCast. Last week, Hagan Rivers joined us for her seminar, “Designing Dashboards.” In it she showed us a whole bunch of dashboards and she gave the audience tips for helping stakeholders understand implementation benefits and drawbacks of seemingly simple components from graphs to customizable panels. We talked about all sorts of fun stuff.

This seminar has been added to UIE’s user experience training library which presently has over 85 recorded seminars from wonderful topic experts just like Hagan giving you the tips and techniques you need to create great design. Hi, Hagan. Welcome back.

Hagan Rivers: Hey, Adam. It’s great to be back.

Adam: So Hagan, for those that couldn’t join us on your seminar can you give us an overview of what you covered?

Hagan: Sure. I’d be happy to. One of the things I wanted to talk about a lot in the seminar is that I see dashboards as being about more than just reporting. I wanted to show examples of dashboards being used to help users do activities. Go to windows, create new things, stuff like that. I introduced with this concept that it is about more than reporting.

And then, I really talked about the three pieces that make dashboard design great. The first is great visual design is important because dashboards are honestly what most people see first so what it looks like really matters. The second thing is having great data visualizations, also really important. And although I mentioned these things, I didn’t really cover them in my talk.

I really focused on my third one which is knowing who your users are and their tasks. I had some examples where I showed dashboards that looked good and have nice visualizations but they’re not very useful so making it useful is really a key piece. Then we ran through a lot of examples. I showed inspirational examples, dashboards that had some great ideas that you might want to grab from, little nuggets to use, and then I showed examples of stuff you probably don’t want to do, some mistakes.

We closed by talking a little bit about customizing dashboards and I tried to convince as many people as possible not to do that but if they decided they wanted to I also pointed out some of the pitfalls and things they’d have to think about in that design.

Adam: Excellent. There were a lot of questions. We tackled plenty in the seminar but there were some left over that we didn’t get to. Let’s take a poke at some of the ones that we have in front of us.

Hagan: Sounds great.

Adam: Adam asks about the detriments of visual noise like pie charts and 3D. He doesn’t like to use them but people that he work with insist upon them or contend that the customers want them. He finds that his data supported objective replies are insufficient to convince people like stakeholders and other folks that he’s working with. I think he’s feeling like he has to justify his dashboards with those visuals. How do you suggest that he approach that?

Hagan: [laughs] He’s got a tough job ahead of him. So there’s a few things I can suggest here. First of all, trying to persuade people of something that they haven’t seen can be hard. So, I often find if your data-supported objective arguments are not enough them the best thing to do is to just show them. Sit down with Photoshop and mock it up how it would look without the noise and the pie charts and the 3D and see if you can communicate… I guess the thing I look for is not only can I communicate just as much information but can I communicate more information in the same space and show it to them and see if that persuades them.

We had a client we did work for, this was three or four years ago, and they had a dashboard and they had like 16 pie charts on the front so the whole thing was basically pie charts.

It was just covered in them and they weren’t telling us a lot of data. There was a little information in them but for density it wasn’t that good. We actually took those 16 pie charts and turned them into a really simple bar graph with 16 bars in it and we were able to actually show much more information in about a sixth of the space. It was so persuasive.

Up until then, they said, “We love pie charts. We’ve got to have pie charts.” When they saw that just said, “Oh my God, this is so much better.” So you know, try to really demonstrate it, don’t just talk about it, and see if you can persuade them that way. But at the same time you’ve got to realize you just can’t stop people from sticking beans up their nose.

If they’re determined to do it they may be not able to listen to any of your arguments so you may have to accept defeat.

Adam: Says the mother of two boys.

Hagan: [laughs] Exactly.

Adam: Jim asked if you could speak a bit about the features for pod control and specifically, he offers up things like minimizing, restoring, maximizing, drag and drop.

Hagan: Right. So, he says pod. Lots of people use different words to describe that box on the dashboard. Some people call it a widget, some people call them pods, I called them elements in my talk, but there’s no agreed upon term for this. I worked with a client who called them apps that you install on your dashboards, sort of hearkening to Apple.

A lot of these little boxes have this header area on the top where they have controls for doing things like minimizing and maximizing, deleting, editing, things like that. And you know, they appear in this little header and it’s funny. Sometimes, I see them as little icons in the header and if I’ve got users who spend a lot of time with dashboards perhaps in multiple products, then they probably get it. They probably know how to use these little icons.

They probably even know what they mean, the little X means close or delete and things like that, but it’s not a lot of users who have that much experience manipulating and fiddling with dashboards. What I actually prefer to do is I have the header area, I have the title for the element, and then I put a little menu icon in there and the menu icon is universally recognized, the little down triangle. Everybody knows that that will open a menu and when you open that up now you can use words to describe the action.

You could say things like edit this widget or delete this widget or whatever you want to do. I think that’s much clearer for people and you don’t have to worry about what they understand and don’t understand. Actually, in the talk I showed an example from Apple’s support groups site and they have a customize your dashboard place and they do exactly that thing.

The header looks very plain and then you go into edit the dashboard mode and that little menu appears and suddenly, you get all these other options there. I think they do a nice job of that if someone wants to go look and see if they like it.

Adam: Our good friends over at UC Berkeley want to know more about the challenge of designing a more institutional portal dashboard where they’re convincing lots of different people to go and there’s potentially a lot of different tasks that those people would do there. They’re doing lots of user research but wonder if you have any other suggestions on how to find dashboard widgets that help draw those people in that they’ve tried to push in that direction.

Hagan: They’re specifically looking to bring more people to the portal so that’s interesting. This is going to sound really pithy, I guess, but the best way to draw people into your dashboard is to be really blindingly useful to them. Even in these institutional portals, human resources and things like that, which seem dull. Sometimes, you can find things that go a little above and beyond what people are able to normally do.

Let me see if I can come up with an example. Let’s say you’re doing a dashboard for HR and one of the things the employee can do there is request vacation time. So you know, you’ve got some link that says request vacation time. But the dashboard could show, for example, maybe the entire year’s calendar with company days that are off, holidays, and also what days the employee’s taken and how many days they have left, a whole little visualization.

First of all, it’s visually attractive so that is going to entice people to look more closely at it but it may be offering something that they have a hard time doing themselves which is like when did I take time off, how much did I take, do I have any days coming up that I know about? That helps them answer some questions.

So I would look for these places where you can take something, even something small, and really make it extremely useful and if you can also make it visually compelling at the same time that’s a double win.

Adam: Mark asks a question. I think he’s asking how you design for different users, different being, how they actually use your dashboards. Specifically, he says how do you design for users that have varying volumes of data and frequency of visits?

Hagan: Yeah. This is a really common problem. You design this dashboard imagining a user that might have, let’s say it’s a mail dashboard, that might have 50 or 100 messages a day but then you get some user who only has two messages a week and some other user that has 10,000 messages a day and the dashboard breaks because it’s just not flexible enough to handle this. Right?

So you’ve got to think about how do you create a dashboard design that can accommodate this really varying amount of data. And I think the big thing here is to remember the dashboard is just a summary of what’s going on underneath. I think in the talk I showed a dashboard for an application that was managing alerts that were being sent out to people and there’s a list of alerts in the product that the user has sent out. There are hundreds and hundreds and hundreds of them but in the dashboard we only show the most recent two.

We just creamed off the top of the list and just took the most recent two. Now a different app might be five or 10 or 20 but you only show a few of the items and then you have a link to say, “Well, I want to go look at the rest.” The nice thing about that is it scales really well. We had users in the that app who would send out maybe one alert a month so the last two would be what they did the last two months.

We had other users who sent out an alert maybe a day or two alerts a day and that was enough for them to be able to see their recent work, too. It scaled really nicely but it always showed the same amount of data. I suppose if you had a user that had never sent an alert, you still have to think about that initial state, that totally blank state of the app. But once you get a little bit of data coming in then it should work no matter what.

Adam: We had some folks that wanted to know more about, I guess, your opinion on scrollable dashboards. What do you think about them? Are they possibly more effective than dashboards that show all of the information above where folks might need to scroll?

Hagan: Right. Everybody’s got this obsession with scrollbars. First of all, I’m not sure what the terror of scrollbars is about. Users are pretty comfortable with the scrollbar. They know how to use them, they’re well understood, they’re a widget that’s been around for a while so I don’t have this knee-jerk, “scrollbars are bad.”

It’s really, really difficult to predict when a scrollbar might appear in your dashboard. Screen sizes vary, we know that, but users resize their browser windows to all sorts of crazy sizes. Really short, really wide, really tall, and any one of those could cause you to need a scrollbar.

I always design in and assume that whatever dashboard I’m building will at some point need scrollbars. Now, that said, you’ve got to be careful because if you have a scrollbar and you have maybe 10 screenfuls of stuff in your dashboard now you have a problem because scrolling, it turns out, is not a great way to keep track of where you are on a page.

If you wanted to quickly jump to a particular widget on your dashboard, the scrollbar is a cruddy way to do that. So if your dashboard gets really, really big, you’ve got to start thinking about breaking it up so the scrolling is not the only way to do it. There are other controls you could use to deal with those broken up pieces but the scrollbar isn’t the best way to find that stuff.

I let the dashboard scroll two or three screenfuls of my target screen size is fine but more than that I want to break it up. I don’t have any particular fear of scrollbars. I think they’re well understood.

Adam: David has a project where his client is very fixated on using tabs for different views of the data. He’s not comfortable with that and wonders if you’ve seen tabs work on dashboard pages?

Hagan: Yeah. This is a subtle and complicated issue. Tabs definitely can have problems. Users don’t see them, they don’t even realize the other tabs are present. They don’t realize that they can switch to other information. Right? So that’s, I think, what he’s alluding to as being his fear. Now, I just said when you have a really big dashboard at some point scrolling is not going to work anymore. If you’ve got a five or 10 page dashboard, you have to break it up.

Let’s say you break it up into five pages. Now, you have five distinct screens and you have to have some kind of navigational control for moving between those screens and you’ve got some choices. Tabs is definitely one of the choices. You could use a dropdown menu or a menu bar. There’s a bunch of different widgets that you could pick to switch between these pages and each one of them has strengths and weaknesses.

Tabs definitely have their own but the menus and the menu bars, they have strengths and weaknesses, too. So rather than saying I think tabs are bad because I’ve seen problems with them how I would approach it is I would say is there something we can do to overcome the problems we know tabs have? If we know, for example, that users miss them then is there something we can do in the design to make sure they don’t?

Add some visual elements. Make sure that they’re aware those tabs exist. And sometimes, you know, an arrow pointing up to the tabs and saying there’s more information in here is really all it needs. So rather than just sort of saying, “I don’t like tabs, they’re bad.” I would sit back and say, “OK, I know they have these limitations. What can I do to overcome those limitations?”

Or perhaps try one of those other widgets. If you really think tabs are bad try the dropdown menus. See what you find there and what their limitations are and how you might overcome those and see which design you might like the best. In the end, sometimes all I do is mockup the different ideas and then walk through them and see what’s the most usable.

I’ve been doing this for 25 plus years and I still sometimes just mockup ideas and play them out on the screen and see what works for me.

Adam: Lots of dashboards suffer from crowded information, crowded data, and Frieda wants to know if you have any suggestions for dealing with the mouse hover tool tip to help with that?

Hagan: Yeah. So a lot of these very interactive, reporting dashboards have charts and graphs and stuff and they use hover to provide information that’s normally found in the legend. So, if you hover on a pie chart wedge, for example, you could see that it’s 19 percent and you could also see that it was $26,000 and you could see the name of the wedge too, that it’s “earnings this quarter” or whatever. So, the hover would give you all this great information.

But there’s a couple problems with the hover. First of all, as Frieda asks, when things are close together it’s hard to get your hover target. If you’re reading a line chart and the lines are right on top of each other and overlapping you can’t be sure you’re hovering on the right element so crowding is a big problem.

The other piece is you have to move the mouse around to get this information. You have to keep chasing after targets to try to learn stuff. So I do have hover in the charts and graphs that I create but I treat it as a secondary, kind of supplemental channel. I use the legends to show what the colors in the pie chart mean or labels or legends, something that’s visible without me touching or moving the mouse on the screen.

I show numbers sometimes on the charts, if I think they’re unreadable in some way. Then I let the hover expand on that. Maybe in the pie chart, I might show the percentage and the name in the legend but only on hover would I learn the actual dollar value, something like that if it’s not information that’s essential. The hover, it can expand on stuff but I’ve got to assume when designing it that the user will never think to hover on the graphic element and what would happen to my design when that happens?

If they miss critical information without hover, then that’s not good. I want to make sure the hover is just supplemental stuff.

Adam: Jason asks what I think is a wonderful question because it’s big, it’s all encompassing, but ultimately it speaks to, I think, what we all want the perfect dashboard to do, right? He asks, “what if we know our users well enough to know that they all want something different on the dashboards?”

Hagan: [laughs] Yeah, that’s a great question. It’s funny because practically every client I’ve worked with that makes a dashboard makes that claim. They all tell me that. All of them. [laughs] I find, honestly, in like 90 percent of the cases, it’s really not true. First, I’ve got to make sure that he’s not part of the 90 percent. Think about the argument you’re making. You’re saying that not only is every user unique, which is a stretch, but that those users are going to be good at building dashboards.

It turns out the skill of building a good dashboard is not easy, even for people who know what they want. It’s hard for them to assemble those pieces. So as the designers and the software engineers and the people who work on the project, you’re actually in the best position to design, for that person, a great dashboard. Even if it was true that all of your users were unique, you would still probably design a better dashboard for them than they would for themselves.

First, I argue that. That you’re really good at dashboard design. The second piece is your users probably aren’t all unique. They might fall into a lot of groups. There might be 15 or 20 different groupings of users or types of dashboards that they want but there are groupings. I always tell these clients why don’t we start by trying to identify, you know, the hundred dashboards you think your clients might want?

I start with 100. We usually end up with like 10 because after that they can’t think of any more. They’ve exhausted every possible idea they have. I say, “OK, come up with a user who doesn’t want to use these 10,” and they can’t so then, I know that first statement wasn’t true. The users don’t all want something different. There are a lot of cases but they are solvable and so we can design those 10 and make them really good.

So I’ve worked with clients where we did exactly that. One client we had almost 20 dashboards but they were all unique and solved really different problems and they were really good and we had no customization and their users never complained because they had what they needed. They were done. And I’ve also worked with clients who don’t design any dashboards really, maybe one in initial one, and then they spend a lot of engineering time building all these customization tools and their users never customize dashboards. They never build them.

It’s too hard or it’s too much work or they just can’t be bothered. That’s not interesting to them. If you had to decide where to invest your time, I would invest it on the side of creating the dashboards for them.

Now, if you make the 20 or 15 or 100 dashboards and your users still want to customize then I think it’s time. By then you’ve built enough of them that you know what kind of customization you need and it’s time to think about that customization design. People do need dashboard customization but it’s a much smaller percentage of people than they think.

Adam: Tom asks about mobile, curious if there are dashboards that you’ve seen for mobile that are good as a reference or any experience you have with this evolving piece of the puzzle.

Hagan: Yeah. Actually, we talked about this during the virtual seminar but at the time I said go look at Google images, which is a pass off of an answer. There are some really nice dashboards being created for mobile. The best ones are on the iPad, as you might expect, where we have more screen real estate.

There’s a bunch being created for website management so Gecko Board is a common one, Go Squared, and I think it’s Duck Board or Ducks Board, I can’t remember. Those three are all basically for managing your website and they give you all sorts of real time information on who’s visiting your website and all of that stuff. They look fantastic. They’re iPad apps.

I think they have iPhone versions as well but they’ve done some really nice dashboard work there. And you know earlier I was talking about the hover stuff. The interesting thing is once you go to touch you lose all the hover information so your dashboard’s got to be ready to work without any kind of hover at all if you’re going to go to the mobile world.

Then also there are some apps like SalesForce. SAP has an app which I think is Business by Design I think it is and they also have built some dashboards that are really nice work both on the iPhone and iPad and on Android as well. Even Facebook, if you look at Facebook now they have this little sidebar that you can open up and it’s got mainly navigational elements. It’ll show you how many of your friends are currently available on chat and it’ll have a count.

It’s a little, tiny dashboard. It’s not a very rich one. A lot of the home screens of iPhone apps and iPad apps are in fact, if you look closely at them, are little dashboards. They get you going using the apps and they give you a little bit of reporting data. Those are some examples that I didn’t talk about during the seminar and now you’ve got them.

Adam: Excellent, Hagan. Thanks so much for taking time out of your busy day to circle back with us.

Hagan: It was a pleasure.

Adam: Thanks everyone for listening in and for your support of the UIE virtual seminar program. Remember you can get all of the details on our virtual seminars at uievs.com.

On April 4, James Robertson will show you the two fundamental questions you’ll need to answer before untangling your unruly intranets. Plus, by seeing loads of successful intranets from around the world, you’ll get solid implementation ideas to help your organization get back on-track, fast.

Some examples of what you’ll learn:

• Understand the 5 purposes of intranets
• Find the right intranet mix for your organization
• Apply field-research techniques to understand staff needs
• Design intranets that are both usable and useful for your organization

Bringing Order to Your Intranet
with James Robertson
Wednesday, April 4, at 1:30pm ET
1:30pm ET / 12:30pm CT / 11:30am MT / 10:30am PT
90 minute online seminar
Register Now!

In today’s tips, Luke Wroblewski shares two techniques to make the process of designing
web applications and sites for multiple devices more manageable: classifying device
experiences and designing/building responsively. I’m sure you’ll find Luke’s article quite
useful.

Read today’s article: Device Experiences & Responsive Design.

We’re very excited to have Luke as part of our UX Immersion Conference in Portland, OR,
April 23-25. Luke’s full day workshop, A Detailed Look at Designing Mobile Inputs, will
help you design intuitive mobile forms that help guide your users to put the right data in
quickly. Learn more about his workshop.

Register for the UX Immersion Conference before Friday, March 30 and save yourself $300.

Workshop Speakers and Topics

Getting Started with UX Inside Agile Development

Hugh Beyer shows you how to apply practical techniques to integrate proven UX processes
through effective communication.

Lean UX: A Seasoned Approach to Designing in Agile

Jeff Gothelf teaches Lean UX techniques that will radically change the way you approach your design process.

Demystifying jQuery for Agile Prototyping

Dave McFarland explains how easy it is to create interactive prototypes in just minutes
with jQuery.

Mobile UX: From Principles to Prototypes

Rachel Hinman dives into the fundamentals and practical techniques for delivering the best mobile experiences.

A Detailed Look at Designing Mobile Input

Luke Wroblewski explains how to design intuitive mobile forms that help guide your users
to put the right data in quickly.

Mobile Design for Enterprise Intranets

James Robertson reveals how to design great intranet apps using the latest technologies.

Learn more about the UX Immersion workshops.

What You Get at the Conference

• Two Full-day Workshops: Dive deep and get to the nitty-gritty details around Agile
  development and mobile design.
• One Day of 90-minute Featured Talks: Hear the experts whose workshops you missed.
• Complete Conference Materials: You’ll get PDFs for every session and workshop.
• Recordings of the Featured Talks: Share every Featured Talk with your team through audio
  and video recordings.
• Networking Opportunities: Meet UX Pros just like yourself, facing the same challenges
  and discovering new solutions.
• Food: Plenty to eat and drink to keep your energy up for all the intense education.

Save your seat before March 30 for $1,649. UXIM.co

We’ve grouped all the UX Immersion speaker podcasts in this one post so you don’t have to search for each individual podcast. These 6 fantastic podcasts are full of sage advice and useful tips on 2 separate and important topics: Mobile design and the Agile process.

Hugh Beyer – Getting Started with UX Inside Agile Development

For those switching to an Agile process, the transition doesn’t always go so smoothly. Suddenly, with things moving so quickly, the role of UX gets lost in the shuffle.

Listen to Hugh’s podcast

Jeff Gothelf – Lean UX: Integrating Design into Agile

Designers and developers find it frustrating to put so much effort into a project and then not see it ship at the end. Using the Lean UX process, you’re constantly validating your designs, especially early in the process.

Listen to Jeff’s podcast

Dave McFarland – jQuery for Agile Prototyping

The lack of technology understanding affects its adoption. This is essentially what happened to JavaScript. Its detractors said it wasn’t a real programming language, and it’s capabilities were ignored. Dave McFarland says that doesn’t have to be the case.

Listen to Dave’s podcast

Rachel Hinman – Creating Great Mobile User Experiences

Mobile is greatly influencing the user experience community. It’s challenging traditional approaches to design. Being a user experience practitioner in this changing environment is a bit scary but makes for an exciting world full of possibility.

Listen to Rachel’s podcast

James Robertson – Innovative Mobile Intranet Design

Intranet access within enterprises is crucial and accessing it with mobile devices is beneficial. However, the vast amount of pages and content is cumbersome and impractical for a mobile setting. Find out what the few essential things users need when using mobile devices.

Listen to James podcast

Luke Wroblewski – Examining Mobile User Input

Touch screen devices are commonplace. It’s now expected that your mobile experience work as well as, if not better than, your desktop experience. With faster connection speeds, cameras, GPS, gyroscopes, and accelerometers, we can deliver information to users in new ways.

Listen to Luke’s podcast

See these UX Experts in Person at UX Immersion in Portland, OR, April 23-25.

On the surface, it feels like when a team moves to an Agile development method, they are also moving to an iterative process. After all, what is a series of sprints but iterations on the design.

In today’s UIEtips, I look at what happens when we try to iterate in an Agile process and, with the help of InContext’s Hugh Beyer, why that doesn’t always work the way we’d hope. Then I look at two approaches that lower the costs of iteration and make them more desirable for Agile teams. If you’re working in Agile, you’ll want to read this one closely.

Read today’s article: Cost Effective Approaches to Iteration in Agile UX.

By the way, I’m the biggest Hugh Beyer fan on the planet. I’m thrilled that he’s doing a full-day workshop for us at this April’s UX Immersion conference in Portland. It’s been a blast working with him on the session, and I know it’s going to be great. Peruse the outline and sign up quickly – space is limited and it’s filling up.

Why you should attend reasons 1-6: The workshops

1. UX Design Inside Agile Development with Hugh Beyer

Apply practical techniques to integrate proven UX processes through effective communication.

2. Mobile UX: From Principles to Prototypes with Rachel Hinman

Get the fundamentals and practical techniques for delivering the best mobile experiences.

3. Lean UX: A Seasoned Approach to Designing in Agile with Jeff Gothelf
   Learn Lean UX techniques that will radically change the way you approach your design process.
4. A Detailed Look at Designing Mobile Input with Luke Wroblewski
   Design intuitive mobile forms that help guide your users to put the right data in quickly.
5. Demystifying jQuery for Agile Prototyping with Dave McFarland
   Discover how easy it is to create interactive prototypes in just minutes with jQuery.
6. Mobile Design for Enterprise Intranets with James Robertson
   Learn how to design great intranet apps using the latest technologies.

Why you should attend reasons 7 – 10: Conference features

7. One day of Featured Talks
   Hear from the speakers whose workshops you aren’t attending on the latest ideas in Agile and mobile design.

8. Complete Conference Materials
   You’ll get PDFs for every session and workshop.
9. Recordings of the Featured Talks
   Relive every Featured Talk at your office with your team through the audio and video recordings.

10. Topic Tables and Networking Reception
    Meet UX Pros just like yourself, facing the same challenges and discovering new solutions.

Bonus reason! Register with the promotion code GIFT and get the designer’s toolkit.

Register by March 29 for the $1,649 price. Learn more at UX-IMMERSION.com.

Change is always an interruption. For those switching to an Agile process, the transition doesn’t always go so smoothly. Suddenly, with things moving so quickly, the role of UX gets lost in the shuffle. User experience is often disregarded in Agile development.

The easiest explanation is: it’s called Agile development. It’s about development, not design. This was the mindset around the time Agile emerged. There wasn’t an appreciation for the challenges of user experience. But now there is a greater understanding of the need to integrate UX into the Agile process.

Hugh Beyer is the Founder and CTO of InContext and author of User-Centered Agile Methods. He coaches teams on how to work UX into Agile development. One important thing to remember is that Agile is relatively new to everyone. Design and development are coming from two different backgrounds and have different approaches. Communication between the two sides is key, both to uncovering those problems with existing solutions, and in working together to tackle those that remain.

Hugh will be joining us in Portland, April 23-25, for UX Immersion. He’ll be presenting a full-day workshop, Getting Started with UX Inside Agile Development, showing how to apply techniques to integrate UX into Agile. Learn more about Hugh’s workshop and explore the entire conference at ux-immersion.com.

As always, we love to hear what you’re thinking. Share your thoughts with us in our comments section.

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

Full Transcript.

Jared Spool: I want to welcome everyone one more time to the SpoolCast. Today I have with me a friend of mine who I’ve known for a really long time, Mr. Hugh Beyer from InContext. He’s going to be speaking at the UX Immersion Conference April 23 to 25 talking about putting UX design inside of Agile development. I’m very pleased that we have a chance to talk today. Hugh, how are you doing?

Hugh Beyer: I’m doing good. How are you?

Jared: I’m doing great. The reason I wanted to talk to you today is that I know that a lot of folks are really sort of struggling with their transition into an Agile process. I mean they were doing really well. They had their workflows really down. They were producing great designs. They were doing these fabulous deliverables that the teams seemed to really be happy with.

And then everybody shifts to Agile, and all of a sudden everything is much faster. The deliverables don’t seem to work anymore. There doesn’t seem to be any way to have a coherent thinking about the design process. This is, of course, compounded by the fact that Agile is new for everybody, so the development teams are just getting their feet wet at the same time. Is that a struggle you see a lot of folks having, or is that just an unusual thing?

Hugh: Oh, they’re in very good company. Actually, I first became aware of this as a problem, and it was a surprise to me, when I ran into Catherine Courage at a KI Conference, which now must be like six years ago at least. She was at Salesforce still at the time. At that point you weren’t seeing a lot of Agile in the work place. Salesforce had started using it. They were one of the early adopters and really went in whole hog, but not a lot of other people at the time were using it.

And I had been following Agile since the very early days and thinking, “Wow, this is a really cool development process. Finally, they’ve come up with something that actually might work and might make sense,” and hoping that I’d be able to get involved one of these days.

When Catherine Courage said to me, “Oh, OK. This is what we’re doing,” and I said, “Oh, terrific. Wonderful. Is it great?” She said, “No, [laughs] it’s horrible,” and she started to describe exactly the problems that everybody has. “We had a way of working with the engineering team. Now we don’t. They respected us for what we could do. Suddenly now they’re doing this new stuff, and they don’t know how to listen to us anymore.”

So that was my first introduction to why this whole thing might not be as smooth as I’d thought it might be, this whole integration of the two approaches because my attitude was they go together like, I don’t know, bread and cheese, and everybody ought to be happy as a result. So it was a surprise to me, but it’s very common.

Jared: My understanding of the basis of Agile is that there’s a lot of iteration that happens, and we’ve always in the UX world been really happy with iteration. We like trying an idea out and refining it and trying it. So theoretically it should work together well.

Hugh: Well, yeah. And of course, everything works well in theory, but in practice it’s a different story. The thing is there’s two things which you have to separate. One is there are theoretical conflicts between Agile well done and UX well done, and they do have to be reconciled. They’re real, and it’s not useful to anybody to pretend that they’re not. So that’s one thing.

But the other thing is Agile as it’s put into practice is not Agile in theory. Agile as it’s put in practice, typically, introduces a whole additional layer of issues and problems, which we also then have to deal with. So when you say Agile is based on iteration, yeah, well, sort of. But mostly not. In other words, nearly everybody is doing short sprints of two, three, four weeks, and that’s good. And people are keeping within their time boxes pretty well, and that’s good and disciplined.

But iteration, which means going back and re-working a particular piece of the system until it’s right? That is just as painful as it ever was. One of the things I enjoy doing when I’m talking to a group of Agile practitioners is I tell them, “OK, so you guys, how many of you get to iterate a particular piece of functionality through three sprints until you get it right?” No one raises their hands.

“Two sprints?” No one raises their hands. “OK, one sprint?” Right? OK, now I get some hands. So the idea that you’re going to go back and re-work functionality is hard–organizationally hard, emotionally hard, and practically hard because then your schedule slips. So yeah, we like the idea of iteration. The actuality of iteration, not so much.

Jared: What does a UX person have to start to get their head around in order to start working with these Agile teams and this sort of new way of thinking? What is the magic that has to happen there?

Hugh: Well, there are two things. One is to have an appreciation for the merits of the technique, and then to have an appreciation for the difficult situation that your developers are in. Then you can start to see how you can actually contribute to the solution from their point of view, which is different from contributing to the solution, right? You have to actually solve problems they know they have in order for them to start listening.

Let me take those in order. One, I got excited about Agile because it’s an approach to development that makes a whole lot of sense. First, it’s people oriented. Second, it is based on the idea of iteration. Third, and actually most important, it’s based on the idea that on every iteration you get real customer feedback and you change your direction based on that feedback.

If you’re really doing those things, then this is a terrific approach to doing development. It keeps you from getting very far off and it gives you a way to include the customer feedback that can actually affect what happens in development. A lot of very important products have been built this way, in fact, without knowing that that’s what was happening. I’m thinking of things like VisiCalc, WordPerfect, and so forth.

Jared: Right. The problem with iteration, is it a problem of the teams aren’t following the Agile process as it was intended, and therefore they’re not doing the right things? Or is it the case that we’re missing some sort of cues or moments to get that iteration to happen?

Hugh: They’re following the Agile process, they aren’t following the Agile intent. So they’re doing all of the steps, right? But the steps say you’re going to get real, valid customer feedback, and then you’re going to change based on that. Because people are coming out of a traditional development paradigm, the easiest way to switch over to Agile, Agile in quotes, is you timebox everything in two, three, four, weeks, or however long you make the sprints.

You work out your functionality ahead of time, like in a PRD, just the way you always did, and then you plan that functionality into your sprints, using some vague idea of velocity, and then you go. It’s just like traditional development except for you’ve got a base level every sprint. What that mentality leads to is, if I don’t get all of my functionality implemented in this sprint that was planned and pushes into the next sprint, I have slipped. I am bad.

Jared: Yeah. I saw this. I had a team I was working with. They had a chart on the wall that had already spelled out the functionality for all their sprints for the next four months, and there was no room for slippage. If the sprint didn’t do what it was supposed to do, it screwed up everything that followed it.

Hugh: Exactly. Not only that, but there’s no room for discovering that half your stories weren’t actually needed by the users, and a couple of stories which you didn’t think to write, are actually critical. You could reduce the work you have to do to have a successful product by 75 percent if you just refocused your efforts on the things that are most important.

That was the whole point of Agile, was that you discover more about what you need to do as you go. If you’re not doing that, OK, you may have a more disciplined development process, which is not nothing, but you won’t get the full benefit of going to an Agile approach.

Jared: So it seems to me that that conversion process, from the way you were doing it to this new Agile thing, that’s a really tricky period for people on the development side, and no wonder on the UX side, it seems like just chaos to us.

Hugh: Yes. Exactly. It shouldn’t be chaos. At least it should be a development process. I talked to a client recently who has a very strong UX group, good relationships between the UX side and the development side. They described their Agile process to me, which was pretty much what I had just described to you, and they said, “What should we do?”

I said, “The first thing to do is to figure out if you’re broken, because you have a well disciplined development process, you’ve got a well disciplined user experience process based on real customer data, and if it’s working for you, then fine. You’re not Agile, but, you know, there’s no sin in that.”

It shouldn’t be chaos, right? If it is chaos, it’s because of the transition, because of trying to adopt new ways of doing things. That’s the problem of not changing your head. The problem of changing your head is, you don’t really know what you’re changing it to until you have experience with it.

You go, “OK. This is Agile. It’s not traditional development. We throw out all the old rules. Don’t really know what the new rules are or how to apply them, but the old rules are gone. Therefore, nothing that we did before applies anymore.” This is the kind of problem that Catherine was talking to me about, and that so many people are experiencing.

Yeah. I know you, UX group, you want time to design, but we don’t do up front design anymore, so be Agile with the rest of us and just give us something with no real time to do it because we’re not thinking about how much time it takes to do it.

It doesn’t help, by the way, that a lot of UX activities are totally invisible to the development side so they really don’t know what it takes to develop a UI. They really don’t know what it takes to gather customer data or to develop our information infrastructure. All of that looks like invisible magic and of course if you aren’t an expert in a domain then you are pretty much guaranteed to devalue the amount of work and expertise required to do things in that domain.

It’s very easy to go, “yeah, yeah, just throw something together, OK”, and not realize why that doesn’t make sense. The other thing that we have to do is we have to listen for where they’re reaching for the new rules and help them see how the UX activities are actually critical to implementing agile in any rational kind of way.

Jared: That’s interesting that you mention that because my understanding was that the original world of agile really didn’t think about UX. That, you know, if you read through the documents it doesn’t talk about it. I remember talking to some instructors and Scrum masters and folks and say how do you get the user experience parts of this in? They really didn’t understand how to do that.

Every so often someone mumbles the phrase Sprint Zero under their breath but there was really this confusion around that because it felt like Agile didn’t take user experience into consideration because it really was about sort of getting your IT process down.

Hugh: IT or even if you’re developing a product the purest statement of this was given to me by Ron Jeffries, who is one of the early Agile pioneers, and I’m in love with Ron. He is the programmer’s programmer, the custy, old coder architect type.

Jared: He’s a great guy. I met him once.

Hugh: Yeah. And he said, “You know what? Agile development is about development. It’s not about figuring out what to build, it’s not about designing pretty UIs, it’s about writing code. If you want to design something else and call it Agile something else, fine, go away and call it agile something else. It’s not agile development.”

His idea was, “tell me what to build, I’ll build it, and I’ll build it in short iterations with quick checks against users”, he didn’t have a clear sense of who users are but that’s OK, developers don’t, and make sure that what we produce is useful. But in the end the whole design question, using design in our sense, of the function and structure of the thing that we’re building, simply wasn’t apparent to him as a problem or at least not as a problem that he needed to solve.

Now that was, you know, five years ago. Things have evolved a lot since then, but that’s where Agile came from. It simply did not appreciate the whole UX problem as a problem in their domain at all.

Jared: So given that, are we just spreading UX on top like icing on a cake or is there a way to infuse it like a good Boston cream pie?

Hugh: Yeah. One of the fun things about Agile is back in the waterfall world you could spread UI/UX on top like icing on a cake and you know, it was still a lousy cake but you could do it. The thing about Agile is you can’t even do it anymore and that’s what people are running into. You have to be integrated into the development process or you’re just completely broken.

Jared: Is it the case that we actually had flaws in our old process but Agile is like a magnifying lens, just to keep adding metaphors to this conversation?

Hugh: Yeah, yeah, and we know it, right? We all ran around saying we’re too late in the process, we’re putting lipstick on a pig, they should get us involved earlier, they should get us involved during functional specs, they should get us involved in the PRD.

Jared: Oh yeah, I remember those days.

Hugh: Yeah. We were always trying to push ourselves upstream. The thing about Agile is there is no upstream. Upstream is downstream. Here we are. Our problem is that until we get to the point where people recognize there’s a piece of design that simply has to happen as a chunk we will continue to be broken and that’s a problem we will continue to have to try to solve.

One of the interesting things that’s happening right now, actually, is the whole introduction of lean techniques, Kanban and so forth. Just as Agile’s original conception of UX was crude at the beginning, their conception of work flow was crude. Their conception of work flow was you have a sprint, you put a story in a sprint, you work on it, it pops out of the sprint, you’re done. That’s work flow.

What Kanban gives us is a more sophisticated way of thinking of the stages of design that a particular feature, say, needs to go through. A traditional Agilest, of course, gets chills down their spine as soon as you say stages of design because that implies waterfall but, in fact, what Kanban does is it lets you think about how to have stages and still be Agile. Since what we do definitely wants to be one of those stages that helps us talk about how we can fit into this Agile process.

Jared: When you say stages of design what do you mean?

Hugh: In our case it will be do the customer research, figure out what the customer really needs at this point, do the high level design in terms of what’s the function and structure which can be tested and iterated using our rough prototypes, do the UI design which can also be tested and iterated using our more fine detailed prototypes, and then doing the transition of that engineering which then has the engineering tasks in it.

There’s multiple tasks and Agile folks have known this, they just haven’t known how to think about it. Every user story ends up getting split up into multiple engineering tasks and those engineering tasks can have dependencies on each other. But up until now they all get thrown into the bucket called sprint and that’s all you know how to think about.

With Kanban, you can go OK these get thrown in that bucket and have to be done before those which get thrown in the next bucket which have to get done before those which get thrown in the bucket after that and, by the way, you want to minimize waste which is to say work in progress in all of those buckets. You’ve got many more tools to think about how you’re planning your development string.

Jared: Where does this Kanban thing come from?

Hugh: This is another Japanese thing. I will admit that I am prejudiced ever since total quality deployment or the total quality movement and quality function deployment and all that stuff. The Japanese love huge wall charts and many, many detailed processes which require tracking every last little tiny piece. So I was suspicious of Kanban. You can use it that way. You could indeed use it, and I have a suspicion that the Japanese do, but you don’t have to.

The basic concepts are actually quite interesting from an Agile approach.

Jared: And so typically when folks are bringing their user experience part into this this idea of integrating with the team’s Kanban process and helping them integrate that process into their development process, that’s a way in.

Hugh: Exactly. Another thing I always tell UX folks is your tasks have got to be on the engineer’s charts because if they are not then they are invisible and you’re not part of the team and nobody cares about you and they shouldn’t because who are you? Right?

Jared: These are things like the burn down chart?

Hugh: The burn down chart and a work in progress chart. Usually what teams will do is when a story gets accepted into a sprint they will break it down into shorter tasks for engineering planning. Some teams will just take the story as a whole but usually not. The UX tasks need to be part of that. And this usually means that you actually have to get your team to look a sprint ahead so that you can start your work a sprint ahead.

As soon as you start talking about Kanban, now you’ve broken down those sprint boundaries so it becomes much easier to say OK, we’ve got to start the UX tasks here because if we don’t the story isn’t going to be ready for development here. So it’s easier to see how all of that lays out.

Jared: And so once you get your head around that, how do you keep the big picture of the design in play? Doesn’t all these breaking things up into little stories and sprints focus people on the micro tasks without keeping the whole in play?

Hugh: Maybe a little bit like totally, absolutely, yeah. Yeah, no question. And it was extremely helpful that at Agile 2011, the big agile conference, one of the big agile gurus stood up at the key note and said, “You know what? You need to be a Spring Zero,” which is their way of talking about upfront design which doesn’t sound scary to them.

“You need to do a Sprint Zero and it’s probably going to be a couple of months. It is not going to be two weeks. If you don’t do that and think about what you’re building and how it’s going to be structured you are going to be in trouble down the road.” So there is beginning to be some acceptance in the Agile community for that. It will take a while to trickle down and you still have a lot of people running around talking about big design upfront.

There it’s important to remember that they are working against a real problem, what was a real problem. Spend six months, nine months, a year developing gigantic specs, half of which are obsolete before they’re written, which require a huge amount of work and time investment which is not value for the customer and which end up specing something which isn’t useful anymore. That’s the problem they were addressing and it was a real problem. We were addressing it in our way but they were a different community.

They have no appreciation for how we were addressing it or what we bring to the table because different community, developers, it’s always been the case, it will always be the case. From our point of view we have to understand that the big upfront design isn’t even really addressed at us. We were just caught in the backwash. It was addressed at the product managers and the project managers and management in general who were mandating these huge, difficult documentation sets that, in the end, weren’t really doing anything good for anybody.

Jared: In this Sprint Zero, I’m really interested in this idea. The thing you said, the not value to the customer. How do we make sure that everything we’re doing in that Sprint Zero is getting close to value for the customer?

Hugh: If you’re talking to me, because you keep going back to the customer. If what you’re doing doesn’t need to be tested with your customer then ask yourself very seriously why you’re doing it. In contextual design the process starts with a bunch of contextual inquiries and then there’s what we call consolidation envisioning which is analysis of your data and then you go back to the customer with paper prototypes of your initial ideas.

For us, that’s the big danger place, that consolidation and visioning because we’re not talking to the customers during that period. We’re always flogging ourselves to go how do we shorten that time? How can we go back and test our concepts? How can we test sooner? As long as you’re going back to the customer and testing something new you must have been designing something that was valuable or figuring out something that they’re doing which will be important to you so you can design later.

The real thing with Agile is that never ends. From the moment of your first very rough conceptual prototype to the moment that you ship code you can sell you’re testing all the way through. You’re checking with your customer all the way through. That’s the end state that we’re working towards with our clients is the point where you don’t even have to wait for working code to do the iterations with your customers.

Jared: All this customer involvement, this is stuff that the user research world has been really good at. Suddenly they’re really valuable all the way through the development process.

Hugh: That’s right. They can be. The trouble is that the developers are working very hard to solve problems we have solved 10 years ago only they don’t know. The first Agile conference I went to the keynote speaker, who I won’t name, stood up and said, “You know, it is beginning to be apparent that there are some issues around dealing with the customer on the team and the best way to talk to them and to encourage their involvement and we don’t know how to solve those. That would be a good research project.”

We’re already in this millennium. It’s 2000, 2001, 2002, somewhere in there. We’ve had the solution to this problem for 10 years at that point but it’s a different community and they simply didn’t have the same background. So you know, we’ve got to introduce it not like they’re stupid, because they’re not, but like this is news to them and, by the way, it should be good news. Not to get all evangelical on you there.

Jared: No, I think this is a real opportunity because suddenly they have this part of their process that dovetails nicely with stuff we’ve been trying to do for a long time.

Hugh: Exactly and we solve problems that they don’t know how to solve. The good engineers, anyway, at this point are aware that a user is not a customer and a stakeholder isn’t either. They’re aware that doing a two hour demo at the end of a sprint really isn’t getting them good feedback. We now have experience reports on the Agile side, on the development side, saying you know what? No stakeholder was ever unhappy at our end of sprint demos and yet our product failed.

So there is enough experience out there at this point for a listening for better solutions. Since we have those solutions if we can show them how they can actually fit into their development process and they don’t have to abandon all the good things about Agile in order to use them then we’ve got a good story and they’ll be willing to listen to it.

Jared: Well, this is all really, really neat. It seems to me that the beginning of a project, this Sprint Zero time, what we do as UX folks actually changes as we move through the project and when we get towards the end game it’s gotten very different by the time we get there so we have to be very adaptable through the sprints. It’s not just keep doing the same thing in these three week cycles.

Hugh: That’s right and we always did. The difference is that now we have more of an opportunity to because we have to be more involved throughout the process. If you’re talking to me about designing a process then you’re talking about an upfront phase in which you’re learning about the customer I call, teaching the customer representative on the team how to be a customer.

That’s your field research, that’s your analysis, that’s your high level conceptual design of the solution because in the end you always have an idea of what you want to build. Dan Bricklin had the idea of what a spreadsheet should look like well before he started VisiCalc and it took 20 years to actually produce something close to his vision but that’s another story.

So we always start with some concept of what we’re going to build at which point agile development can start, but at that point we’re still doing the detailed UI design, we’re still doing the last rounds of iteration with the customers, and at the same time we’re still coaching the developers on the exact meaning of the designs that we produce and we’re still having to test what they’ve created with customers.

So we’ve got way more to do. We’ve got to do it all at the same time. By the way, one of the things about that is what we produce also has to change. The communication with developers, remember, itself has to be less about documents and more about sitting down with people and talking through the design and saying look, this works this way and this works that way and expecting them to call you up and say, “Oh, I have a snag. What should happen in this case?”

Then you have to come up with an answer off the cuff because if you don’t they’ll come up with an answer off of their cuff and their cuff’s not as good as yours. So what we do in terms of our interaction with them has to change as well.

Jared: The challenge is for a UX professional moving to Agile, at the one time there’s this whole new language, there’s this whole new way of thinking, but at the same time it feels like there’s a lot that’s familiar. There’s a lot that we know how to do and we just have to hone it and understand how it plugs in and understand how to change our vocabulary to match the agile speak that goes out there but at the same time know how what we do brings value to the game.

Hugh: That’s right. One, we do have to look very hard at our own practices. Some, not all, UX teams are very invested in their product where their product is the pretty picture measured to the pixel and the full specification and so forth. That’s not going to survive in an Agile environment. In an Agile environment the product has to be your understanding, your design, and your conversation with the developer.

One of the fun things about agile and one of the reasons why I like it is because this is the first time you’ve got a development community which is talking about the human practice. You go to an Agile conference and fully half the sessions are about how people talk to people. Right? For the first time you’ve got these tree huggers who are really getting into how do you make people effective. And this means that they’re going to be more willing to talk to you, they’re going to expect to talk to you, they’re going to expect you to be visible, and they’re going to expect you to be underfoot.

You have to live up to those expectations if you want to have influence on the team.

Jared: That implies that we have to be able to focus on a specific team and not do this sort of generalized one UX person to 7,000 team thing that I see in so many organizations where everybody’s spread so thin they can’t do any good anywhere.

Hugh: That is the big problem, yeah, and a couple of things about that. One is if you can, so you’ve got a few UX people supporting way too many teams but those UX people are the people who can have a view across the whole product suite.

Jared: Oh, good point, yeah.

Hugh: If you can actually make them a team, pull out some of their time, declare an architectural spike, that’s Agile terms for go away and don’t bother me for a sprint because I’m thinking. If you can declare a UX architectural spike where all the UX people come together and look across all the products and make some coherence that can recover some of that holistic view that we miss otherwise.

The other thing that you have to do is you have to go look, I’m a member of the team, I’m a legitimate member of the team, and therefore my problems are the teams problems. You have to show up to the meetings and you have to share your status. If your status is I simply cannot produce a dozen different UIs in the scope of this sprint then that becomes the team’s problem.

What you might need to do is do triage. You might do the most important UI so you might say engineers, you know what? Do it like that other product, copy this, do something simple, and let that go. You may need to do some coaching of them as opposed to doing everything yourself. In the end you’re not going to be able to add all of this to your plate and support all the teams you’re currently supporting and do it all yourself and stay sane.

Jared: Right. Well, I’m really looking forward to your workshop. I think it’s a great chance to learn what I need to learn and for other UX professionals to learn what they need to learn in order to really do a great job of design inside agile development and it really sounds like you’re going to help us walk through what that really means in an effective, positive way. So I’m really looking for that. That’s going to be April 23 in Portland, Oregon at the UX Immersion Conference and it sounds like it’s going to be a lot of fun.

Hugh: I expect it to be.

Jared: Excellent. Hugh, thank you for taking the time to help me understand this agile thing just a little better.

Hugh: My pleasure.

Jared: I want to thank our audience for sitting through another one of our SpoolCasts and I hope you enjoyed it. Thanks again for encouraging our behavior. We’ll talk to you later. Take care.

The right data can be more effective than words when it comes to telling a story. Even if you have the data, you have to present it in the correct manner. Choosing the right axes, colors and placement are all a big part of putting together a great visualization.

In his virtual seminar, Telling the Right Story with Data Visualizations, Noah Iliinsky demonstrates what goes into creating an effective visualization, even building one in front of the audience. The audience asks a bunch of great questions during the seminar, and Noah joins Adam Churchill to tackle the remaining ones for this podcast.

Here’s an excerpt from the podcast.

“…The key [to qualitative data] is really understanding what the relationships you want to reveal are. Because it’s usually about the relationships in the data. It’s usually about the hierarchy, the sequence, the influence, or the affinity, or some other way that the data relates to each other. And when you think about how those can relate, then you can put some ordering onto the page in a way that makes sense.

One example that I like to give for this is a menu in a restaurant. We think, well, that’s not really data at all, but it is. It’s ordered data. It’s ranked data. Usually, what happens on a menu is, you’re looking at things and they are ordered by what course, they’re ordered chronologically.

You’re probably going to start with an appetizer, you might have a soup or a salad course there. Maybe if you’re in Italy, you’d do, like, a light pasta dish. And then, you have entrees, and then, finally at the end, you have desserts. And so, a menu really has an axis, has a time axis and we don’t think about it like that. But that’s what they’re using to organize, to clump the data into rational chunks…”

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

• What distinguishes a data visualization from an infographic?
• Are there any good tools for culling through a large chunk of data?
• Are there particular tools or software to apply encodings to visualizations?
• What happens when you have a lot of data but aren’t sure of the story you want to tell?
• Does requirement come before specification?
• How do you prioritize what to tweak when building a visualization?
• How does the process change when your dealing with only qualitative data?
• Is it better to tell a story or tell the truth?

As always, we love to hear what you’re thinking. Share your thoughts with us in our comments section.

Recorded: February, 2012
[ 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 edition of the SpoolCast. A few weeks ago, Noah Iliinsky joined us for his seminar, “Telling the Right Story with Data Visualizations.” In it he showed our audience how to effectively conceptualize, plan, and ultimately design powerful visualizations that tell the right story. Probably one of the neatest parts of this seminar is he actually built one, step by step, for us. That seminar, as are the rest of our seminars, have been added to the UIE User Experience Training Library that’s presently over 85 recorded seminars, from wonderful topic experts just like Noah, giving you the tips and techniques you need to create great design.

Hey, Noah, welcome back.

Noah Iliinsky: Hi, Adam. Thanks.

Adam: So, for those that weren’t with us for your presentation, can you give us an overview?

Noah: Sure. We talked about the process of really understanding what your data is and how you want to think about it and how you want to present it, as sort of the precursor to actually doing the design of the visualization. And that earlier part should be very familiar to people who are used to doing any portion of a user experience design process.

So, for the first part, when we were considering what we had and what we wanted to do with it, the key considerations were things like, who was our audience? What are their needs? What functionality or what knowledge do they need to take away from this visual so that they can go do their work, so that they can make the right decisions? What action do they need to be able to take?

We also needed to know about the data itself, whether it was time-series data, whether it was qualitative data, if it was quantitative, whether things were ordered, not ordered, all these different things. We need to have a deeper, intimate knowledge of the shape of the data so that we can encode it properly.

And finally, the thing that sort of drives the entire concept of doing a visualization is, as a designer, what is our goal? Is our goal to convince someone that our product is superior? Is our goal to provide a specific kind of knowledge or specific answers to the audience, who is our customer? Is our goal to just give a summary of what’s going on so that other people can just feel like they are informed? So keeping our goal in mind, also, is one of these fundamental drivers.

So, again, the three fundamental considerations are the audience, their needs, their use cases, all that sort of thing, sort of the usual user experience considerations; the data itself, the shape of it, the flavor of it, call it what you want, but what kind of data we have, how much of it we have, and how it relates to itself; and then, finally, our goals as the designer, what it is we’re trying to achieve by creating this visual. So that’s the inputs. That’s the first part.

When you have all that, you can then take these inputs and begin to conceive of the sort of answer you would like to create. I talk about that like it’s a spec for the visualization, where the spec is specific enough that it tells you some things about what data you’re going to be needing to include, which also means what data you can exclude because you don’t need to use it all necessarily. Extra data that’s not useful is also called noise. So the spec’s going to tell you things like what data to include and what the relationships you want to reveal are.

So, for example, the spec that we used in the virtual seminar, the statement of purpose that was the spec that we used to create this visual was, “How have changes in health-care spending affected life expectancy in different countries between 1995 and 2009?” So that’s a statement that refers to the data, refers to the relationship, gives us some boundaries in terms of the time frame. It was not the world’s most perfect spec. There’s some ambiguity left in it, which was done on purpose because it left us room to kind of play with the relationships that were there and see which of the different relationships available in the data were going to be the most important or the most useful.

But it also gave us some very specific data to include, gave us the boundaries of the years that we were going to include, which also, in that case, meant excluding some of the data that we didn’t have, we didn’t have as much consistency with. For example, we didn’t have data points further back in time for a lot of the countries, and so we didn’t include that.

So that’s the first part. Understand your inputs. Write a spec that kind of gives you some definition. The other thing, by the way, that the spec gives you is it gives you guidance. It tells you a direction to start in, and it lets you test what you’ve created against your goals. If you can answer the question or satisfy the statement that is the spec with the visualization that you’ve created, you’re probably on the right track.

So that’s part one. That’s what we call what to visualize, how to decide what it is we’re doing.

Part two, the second phase, is actually doing the visualization, actually taking this data that you’ve got and starting to make marks on a page, starting to define what do colors mean, what does placement mean, what the size and shape and all these other things mean, where are we going to put the labels. And that is based on several years, decades, of research that’s been done into cognitive psychology and how people perceive relative placement and differences in color and social constructs around “What does bigger mean?” or “What does green versus red mean?” all these things.

So the way you start the how to visualize, the very first thing you do there is you choose your axes. And you want to choose axes that are going to reveal the relationship that is the key interaction. So this is why scatter plots, for example, are so powerful and commonly used is they show the key interaction between the values on the X-axis and the values on the Y-axis. So I strongly advocate for well-defined axes and really thinking about those in the first place, because they sort of define the scope of your world, the boundaries of what you can create.

And then, once you’ve got those, once you’ve got the data points defined in your world based on the axes, you can start to add other, different dimensions of data. And the way that we choose the visual encodings for those other, different dimensions of data is we want to understand sort of the flavor of the data. Earlier, when I was talking about the data as an input, we want to understand things like, is the data well-ordered or not? If it’s ordered, is it quantitative, or is it just ranked? If it’s not ordered, is it categorical? Is it qualitative? Is there a relationship there?

The reason we want to know this about the data is because we want to choose a visual property that is compatible with the data. If we have qualitative data, we want to choose visual properties that are going to be more qualitative or categorical. If we have quantitative data, we want to choose a visual property that can represent those quantities effectively.

The research has been done. We know what those visual properties are and how they map and have actually drawn up a table of this. My table is one of a large number of these tables that’s been drawn in history. But if people are interested in this, and I highly recommend printing this out and pinning it up on the wall of your cubicle, if you go to complexdiagrams.com–that’s my blog–complexdiagrams.com/properties, and there’s a one-page PDF there that you can just print out, and it lists the visual properties and the characteristics of the visual properties, and it also tells you what sort of data is best used to encode.

So you use something like this to guide the subsequent addition of more dimensions of data onto your visualization. And then, of course, as with all design practices, the answer is iterate, iterate, iterate. You’re going to put some things on the page and say, “You know, that’s just not quite right. It’s not working for me. Let’s try something else.” And this was actually something I did quite a lot of in the virtual seminar, as people will remember.

We tried some best guesses initially and then looked at it, saw that the best guesses were not as accurate or were not as useful as we had hoped and started to make some changes, started to iterate the process to get more interesting, more useful results that were actually more informative. And that was based on perceiving what was actually there in the data rather than what we hoped or believed might be there.

So, that’s the overview of the virtual seminar.

Adam: Well, let’s get to some of those questions that we didn’t have time to tackle in the seminar. Ann wants to know how you distinguish a data visualization from an infographic.

Noah: That’s a great question. This is a question that is still debatable in the industry and in people who are involved in this. My personal favorite definition, and one that has become widely adopted among people whose work I respect and people whose thinking I respect, is it’s one of sort of content density and origin. And these things go together.

Data visualizations tend to be very data-rich, hundreds or thousands or millions of data points. They tend to be generated with software. So, somebody is saying, “These are my axes. This is how I want the graph to look.” But they’re not in there with a mouse putting down a point for every graph. They’re generated through a graphing tool, whether it’s Excel, whether it’s Tableau, whether it’s R, or some other software package. And what that means is you can create a new version, you can update, you can add data, you can make changes to it very quickly.

So that’s what we call a data visualization. Tends to be data-rich. Tends to be, obviously, guided by the designer but not hand-drawn. Every pixel is not put on the page intentionally. And they’re flexible. They’re easy to update. So that’s a data visualization.

The other end of the spectrum is infographics. Infographics tend to be much more highly illustrated and have a much lower quantity of data. So, there are some terrible infographics that are fairly common on the web these days. There’s also a number of quite good ones. Infographics tend to have a relatively small number of data points, maybe 10, in that number, tens, perhaps, of data points being represented. They tend to be highly illustrated. It tends to be something where somebody, perhaps a graphic designer, actually went into a drawing tool, like Adobe Illustrator, and drew this graph, put some text or some caption on it, made a nice fade, maybe they added some glossy effects to it, put some narration, some supporting text, and then there’s the next graph.

And so these infographics tend to have a much smaller amount of data, they tend to be hand-generated, and they have, typically, much more effort put into the aesthetic presentation.

Now, the drawback to that is that if the data changes or you want to add a different data set or you want to reuse the same framework, the same sort of structure for something entirely different, there’s a lot of manual effort that goes into re-plotting it, putting the data on the page a second time, because it was manually created rather than algorithmically created with software in the first place.

That’s the definition I like of infographics versus data visualizations.

Adam: Noah, there were lots of questions from our audience about the tools that you use to do these things. First, what tools do you use to actually get your head around the big chunk of data? Are there tools that you recommend or that you use for playing with it and culling through it?

Noah: Personally, I just start with a spreadsheet, whether that’s Excel. I’m on a Mac, so I usually use Numbers if I can. Nothing wrong with a spreadsheet for just sort of first approach to the data. If you’re someone who’s got access to more sophisticated tools or access to a statistics background, you can use a package like R, which is an open-source statistics package that’s very popular and well-supported. Or if you’ve got academic access to something like SPSS or one of these other professional stats packages, those are also a great answer. But really, there’s nothing wrong with just Excel or anything else, just a very basic spreadsheet to kind of see what’s there, just to get a sense of the scope of your data, what rows and columns you’ve got, whether the data’s complete or it’s got holes in it, that sort of thing.

Adam: There were questions on, once you’ve got the data pulled out and you want to create your visualization, what software or tools do you use to generate those? And in particular, in the seminar you spent a lot of time talking about the different types of encodings. Are there tools to apply those, and is that something that you can do in Excel?

Noah: Yeah, there’s a lot of different tools that you can use, and it depends a lot on what you’re comfortable with, what you have access to, how much data you’re dealing with. For off-the-shelf visual drawing, nothing wrong with Excel. Well, I should take that back. There’s a few things wrong with Excel. All of the defaults in Excel are wrong: the axes, the fact that it makes everything 3D, the colors that it chooses, the labels, the default graph styles. Most of the things in Excel are wrong. You absolutely can use Excel to draw good graphics, but you need to know what you’re doing. You need to, for example, refer back to that table that I drew up to make sure that your encodings and your labels and your positions and shapes and whatnot are actually going to be useful to your audience, not distracting. So Excel’s a fine place to start with that, or, again, Numbers, or whatever spreadsheet tool you prefer.

If you’re on the Windows platform or you can get access to a Windows platform, there’s a fantastic tool, happens to be from Seattle, called Tableau, which is a really excellent visual analysis and data visualization software. And because it has been designed specifically to be for data visualization, all those defaults that I just mentioned in Excel, that are wrong in Excel, they get right in Tableau. And Tableau’s just a really nice package. There’s a free version of it called Tableau Public, which you can download and play with. So that’s a great tool.

Like I said before, there’s an open-source statistics package called R, like the letter R, and there’s some good graphing tools for that, although that’s a little more sophisticated. And then, in the realm of software, my favorite tool for that is a JavaScript library called D3.js. It strikes a really nice balance between giving you a lot of flexibility, to draw any kind of graph you can think of, but also a really nice framework, to make the hard parts of those a little bit easier and allow you to focus on the work that you really want to do.

For people who are more interested in things like data art or a little more free-form representations of data, the best language out there these days is probably Processing. And that also is a very well-supported, free, open-source tool, as is D3.

For just sketching and kind of playing with ideas, if I don’t want to be throwing my whole data set around, I usually start with pencil and paper. That’s a great place to start. On the Mac, I use OmniGraphSketcher, just to kind of roughly say, “Well, if we do a bar graph or a stacked bar graph, I want it to look like this. And if we do a line graph, I want it to look like that.”

For qualitative relationships, for things like influence and flow charts–I do actually do this a lot with flow-through software or flow-through interface–I do all that in OmniGraffle. And OmniGraffle is actually probably my favorite piece of software in the world. I’ve been using it constantly for like nine years or something, and it’s just so well-designed. Love that tool a lot.

Back in the day, before D3 came along, I used to do some of my data munging in Perl and output it in a format called Dot. Dot is a format for drawing directed graphs, and once you have your data in this Dot format, you can visualize it with a piece of software called Graphviz, which is another open-source tool. Graphviz is also incorporated in OmniGraffle, so if you’re on a Mac and you use OmniGraffle, you can format your directed graphs in the Dot language and then just open them up in OmniGraffle, and it’ll do the initial layout pass. And I like that process a lot, too, because then it lets you go in and manually modify in a familiar environment like OmniGraffle.

Most of these tools that I just mentioned are listed also on my website, complexdiagrams.com/about. And that also has a section on the tools that I tend to use.

Adam: Jeremy wants you to talk more about when you’ve got a situation where there’s lots of internal data but you’re just not quite sure what the story you want to tell is yet.

Noah: That’s a really excellent question also. A lot of what I talked about in terms of picking the right encodings and putting it on the page just so all assumes you already know what it is you’re trying to show. And Jeremy’s question gets at the very real notion that a lot of the time you don’t know what’s there, you don’t know what you want to show.

This is a different context. This is a context where you’re then looking more at the exploration end of things rather than the presentation or the explanation end of things. If you’re still exploring, you get the freedom to be a little more rough with it. You don’t have to worry quite so much about showing all the data quite yet or getting the colors just perfect. Instead, you can kind of be a little sloppy in the presentation, because if it’s just for you or just for a small team, then you can play with the axes, you can play with what data to include and exclude.

The question of how do you know what to do? It’s a little bit of intuition. It’s a little bit driven by your goals. It’s a little bit driven by experimentation. So, if you take your goals and say, “Well, these are kind of the relationships I think that I’m interested in,” maybe you do a really quick graph in Excel and you see if that relationship exists.

Again, this is the process that I actually went through in the virtual seminar. I sort of did a best guess for my first pass at what the axes should look like. And it turned out that it wasn’t very interesting, and so I had to make some modifications there. That’s a very real example that happens all the time. You say, “Oh, we’re going to graph it this way,” and you make that graph and it’s not useful. And so then you have to start thinking about, what else might be in the data, might be represented by the data? What else might be interesting to learn from the data? Are there other factors that you didn’t get data for that might be influencing the situation?

So, like I said, it’s a little bit of context, a little bit of letting what you can see guide you. It’s a little bit of intuition, of just your awareness of the big picture. And again, it’s always going to be guided by the sort of underlying motivation of, “Why are we here? What are we looking for?” Because probably you’re looking for something. If somebody says, “Here’s my data. Graph it,” they usually have some kind of a notion or some kind of a motivation of, “This is the particular kind of answer that we think is going to be useful. This is the particular kind of relationship that we would like to understand better.”

So you’ve usually got some kind of guiding light there to set you off in a particular direction and kind of get you started. And then, yeah, from there, iterate, take the feedback from what you see, iterate again, keep going. That’s how a design works, again and again.

Adam: The Qualcomm UX group asks, shouldn’t requirement come before specification?

Noah: The answer to that is, it depends. And the reason I say that is because, if you already are in a situation where you know exactly what it is you want to learn from your data, absolutely. You’ve got some requirements that say, “This is what we want to learn, and that’s going to inform the spec.” And then the spec itself is what’s going to tell you what to draw, which data to include, where to put it on the axes, that kind of thing.

The flip side of the situation is when you don’t exactly know what the requirements are. This goes back to Jeremy’s question. You don’t exactly know what the requirements are. You know that there’s probably something interesting in there, but you’re not quite sure what it is, and so you can’t make a requirement. So you sort of make up a spec. You make up a best-guess spec, you play with it, and then, like I said, you allow what you can see there to inform your subsequent iterations and your subsequent experimentation with the data that you’ve got available.

Adam: In the second half of the presentation you were, again, in front of the audience, you were literally building a visualization for us. And during that time, Veronica wanted you to say more about how you were deciding which things to tweak. And I guess I’ll add, how did you prioritize those decisions?

Noah: Sure. This, again, is similar to Jeremy’s question of, how do you figure out what the story is? This is a little bit different than that. We knew what relationship we wanted to reveal, but we were trying to figure out how to let the data show us that. And what happened was, with our first best guess, the interesting data points, the outliers, we knew were not about the relationship that we were looking for.

So we were looking at the relationship between changes in health-care spending and changes in life expectancy. And instead, what we saw, initially, was these huge outliers, where there was large changes in life expectancy, where either countries where a war had begun, a war had ended, or there had been a lot of HIV/AIDS in those countries. Those were things that were radically changing life expectancies for better or for worse, much, much more so than the smaller life expectancy changes that were happening in response to changes in funding on health care spending.

So even when we took those outliers out of the picture, the data wasn’t clear. And going back to Veronica’s question, how do you decide which to tweak, then? As people may recall, I tried a couple of different strategies. One was trying to just clump the data by region or by economic tier, rather than showing all the countries, because with all the countries there, it was just kind of a mess, it was kind of a glob of data with no clear trending.

So, one attempt was to clarify by doing some clumping, which is a great strategy, by the way, if you can do that. Another attempt was to change the axes, because we decided that maybe the initial declaration, of this should be this axis, and that should be that axis, wasn’t the best choice of axes. And tried a couple of different tweak of the axes.

So, the response, how did I choose what to tweak? I was attempting to address the specific deficits of what I had in front of me. The specific deficit I had in front of me was, all the data was in the clump, so we tried to clarify that by changing the axis to spread that out a little bit, and changing the density by grouping the data into geographic regions, economic regions, rather than showing data points for 150 or 200 countries all at once.

So, a little bit of intuition, again. And a little bit of looking at the problem with what’s right in front of you and saying, what would make what’s right in front of me, easier to understand? Do I need less density? Do I need these to be spread in a different way? Do I need some color-coding to kind of pull out the layer that’s interesting to me?

And then, you experiment. You iterate with those changes that you think might be useful. If those changes aren’t useful, you try some different ones and see what happens.

Adam: Dan asks the question, “How does the process change if you’re dealing with only qualitative data?” And Noah, correct me if I’m wrong, I think this question came up during the first half when you were talking about massive data set, you can’t use it all, you need to kind of pull out the right pieces to tell the right story. Is that your recollection as well?

Noah: Yeah, I think so, when we were talking about all the numerical manipulation you might have to do. And he said, “What if you don’t have numbers? What if you’ve only got qualitative data?”

I am particularly fascinated by qualitative data. Diagramming qualitative data was how I ended up getting into the whole world of data visualization.

Qualitative data is really fascinating to me, because unlike quantitative data, numerical data, where we’ve got a lot of standards about graphs and conventions, about when you use this graph and when you use that graph. We have a lot of good tools, we have a lot of good examples. We understand the best practices, even though they’re not universally followed. We have a really good understanding of how to draw pictures of numbers.

We don’t have a lot of conventions, we don’t have a lot of standard metaphors around pictures of qualitative data. That tends to be relationship data, is what that tends to be. The things that influence other things, things that have some affinity.

You can sometimes get rank or order out of qualitative data if you’re looking at something like a process where things, where you have to follow a sequence, or where you’re looking at an org chart or a hierarchy where you can say, this is someone who’s at the very top. This is someone who’s second tier, this is someone who’s third tier.

You may not be able to say that the second tier is twice as good as the third tier, and the first tier is six times as good as the second tier. You may not have that level of quantification, but if you’ve got some ordering, that’s a really useful lever that you can use with your qualitative data.

But what it comes down to, typically, with the qualitative data, is you’ve often got to invent a new metaphor, unless you’re working in some standard metaphor, like a family tree or an org chart, where we already understand what those are, typically. But a lot of the time, with qualitative data, you’ve got to invent a new metaphor and you’ve got to teach that metaphor before you can start talking about your data. And that provides a little more of a challenge to a designer, a little higher barrier to success.

But I really like those situations, because I find that level of creative engagement really juicy when you can look at what you’ve got. The key there is really understanding what the relationships you want to reveal are. Because it’s usually about the relationships in the data. It’s usually about the hierarchy, the sequence, the influence, or the affinity, or some other way that the data relates to each other. And when you think about how those can relate, then you can put some ordering onto the page in a way that makes sense.

One example that I like to give for this is a menu in a restaurant. We think, well, that’s not really data at all, but it is. It’s ordered data. It’s ranked data. Usually, what happens on a menu is, you’re looking at things and they are ordered by what course, they’re ordered chronologically.

You’re probably going to start with an appetizer, you might have a soup or a salad course there. Maybe if you’re in Italy, you’d do, like, a light pasta dish. And then, you have entrees, and then, finally at the end, you have desserts. And so, a menu really has an axis, has a time axis and we don’t think about it like that. But that’s what they’re using to organize, to clump the data into rational chunks.

If you ever sat down in restaurant and everything was ordered alphabetically, it wouldn’t make much sense. You’d have to search through the whole menu to find an appetizer, to find a salad, rather than knowing where to look. You can sort everything on a menu by price, but that would be a little strange, also. You’d probably get things like entrees clumped close together and drinks clumped close together. But again, those relationships don’t make much sense.

Where, if you’re saying, I’m going to clump my menu items by what course they’re for, which, again, maps to the time of consumption, you’ve got some relationship there that helps you group the data and put it together in a way that is going to allow the audience to make some sense of it, to find what they’re looking for a little more easily.

So, again, when it comes to qualitative data, it’s all about, what are the underlying relationships in the data that are going to be interesting and important and useful to my audience? And then, how do I choose a grouping, an ordering, an arrangement on the page, an axis that reveals those key relationships or key properties of the data?

Note, by the way, when I say axis here, I don’t necessarily mean it’s got to go from 0 to 100, like it does if it’s a graph or if it’s something that’s quantitative. You can perfectly legitimately do qualitative axes, whether it’s ranked from most important to least important, or whether it’s categorical. We have our three categories of desserts. On the left, we have pies, in the middle, we have cakes, on the right, we have ice creams. Right?

That’s an axis where that grouping is powerful and useful, but it’s not ordered, it’s not quantified, it’s not ranked, it’s just, we’re going to say, this particular axis is grouped into three parts, and you can find different things in these three parts.

So, the process is going to be different, certainly, you’re going to be looking at some different favorite portions of the properties table that I mentioned. But relationships. Understand relationships, understand what’s value and interesting in that regard, that it is similar to quantitative data.

Adam: The team at Turner broadcasting was hoping you could speak a bit about the difference between motivations of telling a story and telling the truth.

Noah: This is a subtle difference, this is a gray area. There certainly are people who would argue that any sort of bias, any sort of motivation or perspective or point of view, anything like that is going to, you know, impugn your pure, rational objectivity. And I’m not entirely convinced of that.

I have a physics degree, I have a strong respect for the virtue and the integrity of the data. I also think that the data, as a stand-alone entity, does not have as much value as the data that has some context. And I’m assuming, because it’s coming from Turner Broadcasting, that these are people who have some journalistic context for their question.

There are definitely situations where the data is being tortured, the data is being manipulated to show a specific point of view, to support a particular argument. And it’s not inherently bad to have the data, the truth of the data support a particular point of view. It’s a problem when, the way that the data is represented or the way that the data is edited, the way that the graph is put together, it’s a problem when those are done in such a way as to distort the meaning that is there in the data.

So, if some data points are omitted, if the zero is removed from the axis of a graph to take what otherwise would be a relatively flat slope and make it look much steeper. Obviously, if data is just made up. If you’re only showing a short time span that omits a longer context. These are all, sort of, the classic traditional ways of taking data that doesn’t tell the story you want it to, and making it look like it tells a story that you do want it to.

I think it’s great when the truth of the data supports the truth of the story. And we should, as savvy consumers of data and savvy designers of data, be aware that you can lie with data just like you can lie with words. As designers, one would hope that you would tell the story that reveals the truth and the integrity of the data, rather than selecting data and manipulating data to support the story that you would like to tell.

This, obviously, is not always going to be the case, but I’m sure that any of the fabulous listeners to this particular podcast and attendees to the seminar have only the highest integrity and would never use data for evil. But instead, would be willing to change their story, change their point of view if the truth of the data reflected a truth that was not the one that they were hoping to see.

Adam: Very complex.

Noah: As all things involving humans and communication are.

Adam: Well, Noah, this was great. Thank you for taking time out of your day to circle back with us and answer some of the questions we had for our audience.

Noah: My pleasure, Adam. It’s always a treat to be here.

Adam: To folks who are listening in, thank you so much. And thanks for your support of the UIE Virtual Seminar program. You can get all the details on upcoming seminars at uievs.com.

Some of those challenges come up pretty fast. Often, the first one a UX Pro encounters is the realization that you can’t just shrink down the desktop experience and expect it to work. Mobile brings out a need to curate the experience in a way that we didn’t need to do with our desktop interfaces. (It turns out that those desktop interfaces truly could use some curation, but all those pixels let us get away without doing it.)

Another challenge is realizing that what you do away from your desktop machine changes how you think about the problem. Looking up a restaurant’s location at a desktop machine is very different than looking it up in a mobile context, such as in a cab while on the phone trying to give directions to someone who is lost on their way there. Looking up a product description and reviews on an e-commerce site is different when you’re in the store, standing in front of a competitor’s product. Identifying these mobile contexts and designing for them can provide a challenge that stretches even the saviest UX Pro’s skills.

Then, once the UX Pro gets into the design cycles, another challenge is figuring out if they’ve come up with a natural interface in a world with touch, accelerometers, cameras, and location aware devices. It’s easy to get sucked into the trap of focusing on the hardware instead of thinking of the user’s experience.

There are ways to navigate all these challenges (and the others that mobile design presents). A solid understanding of the principles of mobile design and a process that helps with quick iterations, including fast and simple prototyping techniques, gets the UX Pro a rocket boost in the right direction.

We’ve seen this in Rachel Hinman’s work. When she was at Adaptive Path, and now in her work at Nokia, she was one of the first to talk about these challenges and how to navigate them. She was one of the first people we reached out to when we were putting together our UX Immersion program, and was tickled when she said she would put together a full-day workshop to help UX Pros get that necessary boost.

If you’re moving your UX work to include mobile design, you owe it to yourself to look closely at Rachel’s full-day workshop. It’ll provide just what you need to take on the challenges you’re facing.

Rachel Hinman has packed a ton of mobile design awesomeness into her full-day workshop, Mobile UX: From Principles to Prototypes, at the UX Immersion conference in Portland on April 23.

In today’s UIEtips, we have one of the foremost experts on mobile and intranets. James Robertson shares some tips on planning and delivering enterprise mobility. I’m sure you’ll find this article a great place to start if you’ve been thinking about mobile within the enterprise.

Read the article, Making Sense of Mobile Within the Enterprise.

We’re lucky to have James participate in two different UIE events. On April 4, James presents, Bringing Order to Your Intranet, a 90-minute online seminar. He’ll also be conducting a full-day workshop, Mobile Design for Enterprise Intranets, at the UX Immersion conference on April 25.

Then, suddenly, you hear that “A word” – Agile. Suddenly, nothing fits any more. There are no requirements. The focus is on producing code quickly. Nobody is talking about the big picture. UX doesn’t seem to have any place in the process. It feels like we’ve taken a step backwards, into a time before UX.

The thing is that it doesn’t have to be this way. UX and Agile work well together, if you know how. In fact, when done really well, it’s a much better way to get results than any other development process.

An Agile process, integrated with UX, needs to have explicit design points. The UX folks need to completely understand how Agile works and how their team is implementing it, as almost every implementation is unique to the organization. And the rest of the team needs to see how UX can improve the productivity of their work and the quality of their results.

This is why we’ve asked Hugh Beyer to give us a full day to immersing ourselves in integrating UX into an Agile process. He’s got a ton of experience making this works with all types of teams and he’ll share the best techniques and tricks for making it work. It’s perfect for the UX Pro who wants to get back to that point where everything is in order and completely under control.

Take a look at everything Hugh Beyer is covering in Getting Started With UX Inside Agile Development, his full-day workshop at the UX Immersion Conference on April 23.

Touchscreen devices are commonplace. It’s now expected that your mobile experience work as well as, if not better than, your desktop experience. With faster connection speeds, cameras, GPS, gyroscopes, and accelerometers, we can deliver information to users in new ways. But we can also receive information from them as well.

Luke Wroblewski, author of Web Form Design and Mobile First, believes we have yet to harness the full capability of input on mobile devices. As mobile becomes a viable access point to the web, users are less likely to complete time consuming tasks, like filling out forms. Simply porting over your sign up or checkout flow isn’t a solution. As Luke puts it, “If it’s an issue on your website, it’s going to be 2X or sometimes even 10X the issue for your mobile experience.”

Instead of requiring users to enter information with their keyboards, we can take advantage of types of input that the desktop doesn’t afford us. As evidenced by the inclusion of Siri on the iPhone 4S, input is not limited to thumbs and fingers. Many apps are utilizing built-in cameras and GPS to provide immediate information, such as Yelp’s augmented reality feature, Monocle. Luke believes we can go even further. Pressure sensitivity, fingerprint recognition, and radio frequency ID chips are just some of the things Luke mentions as future possibilities.

At UX Immersion 2012, Luke will be presenting a full-day workshop about designing user inputs on mobile devices. Learn more about Luke’s workshop or the entire conference at UX-Immersion.com.

As always, we love to hear what you’re thinking. Share your thoughts with us in our comments section.

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

Full Transcript.

Jared Spool: Hello, everyone. I want to welcome you all to yet another episode of the SpoolCast. And if you’ve been listening to the SpoolCast for any amount of time, you have definitely heard the wonderful and fabulous Luke Wroblewski.

He is joining us today, this time from the city of Quebec. Luke is going to be speaking at our upcoming UX Immersion Conference, which is going to be in Portland on April 23 through 25. He’s going to be doing a workshop on designing user inputs on the mobile devices. Luke, welcome.

Luke Wroblewski: Thank you, thank you. Pleasure to be here.

Jared: And so we have talked so many times that I thought it just would be cool to find out what the hell is keeping you still interested in all this stuff?

Luke: Well, it changes faster than I can keep up with it, is the fascinating thing. Even if you just look at some of the recent announcements, so this Google X project with these HUD glasses that’s supposedly coming out.

Jared: Yeah! Yes, that sounds so cool. Everybody’s been talking about “Minority Report” being the interface of the future, but I think it’s likely to be “Top Gun.” [laughs]

Luke: Yes, or “Dog the Bounty Hunter,” if you will.

Jared: Yes. Right! [laughs] Oh, that’s weird.

Luke: So take your pick. I mean the reports from “The New York Times” said these glasses look like the Oakley Thumps, which are his trademark eyewear there.

Jared: Wow, OK, OK. But I still want a helmet with a nickname on it.

Luke: What would your nickname be?

Jared: Smeagol? No. [laughs]

Luke: Smeagol. Not tough enough.

Jared: No, probably not. Hotdog’s already taken. So, these glasses, I’ve only heard little bits about them. I haven’t heard much about them. What’s the big deal about this, what’s got you excited about it?

Luke: Well, it’s nothing that’s gotten me excited about it. This is one of those concepts that I think has been around for many, many years. You go out to MIT and you see a lot of guys that kind of look like cyborg, with the glasses on, some sort of wearable computing that’s overly bulky. They just look really strange.

So people have been working in this space for a long time, and they’ve even gotten pretty high resolution displays on some of these glasses. At some point, somebody’s going to come out with it. Why not Google? It feels aligned with the Android vibe.

But I’m not 100% convinced that that is the future. I’m trying to be very open-minded and optimistic about it, but I have a hard time really picturing how it would work.

Jared: It feels to me a little bit like a solution in search of a problem.

Luke: Yeah, it could be. And you know there’s a guy who used to work at Apple on the iPad, Bret Victor. He wrote this really interesting post out there, just going on a rant about objects on glass. I don’t know if you saw this, I can dig up the URL.

He just took all these future vision pieces where everybody’s describing icons and interfaces on various screens, on various pieces of glass throughout our life. You see these videos from Microsoft, from Dow-Corning, who makes glass. You see them from Nokia, you see them from RIM. You see them from everybody.

He just took a very different slant at it and said, “Well, why are we so focused on this glass? Why don’t we focus on all of the properties that we have in our hands? We’re just barely scratching the surface of what we can do with the amount of dexterity we have in our hands. From pressure, from touch sensitivity, and all this.”

I sort of like that mode of thinking. Ultimately, there’s only going to be so many screens we can slather in our lives, right? We may have to think about different ways of gathering input that take advantage of what the human body can do very well.

Jared: This is interesting, because Bill Buxton talked about this 15, 20 years ago. I remember him giving a speech in 1989. I remember it like it was yesterday. In his speech, he said — think back, this is the Macintosh days and stuff.

He says, “If aliens were to land on this planet 20,000 years from now and they were to dig up today’s civilization and they were to find one of our computers, they would assume that we didn’t have very good eyes. And we only had one finger because our mouse only had one button. And we couldn’t exert much pressure because the buttons that we use on the computers don’t do anything other than do on and off. And we didn’t use our feet for anything, we didn’t use the rest of our bodies for anything.”

He was talking about that same sort of thing. He expressed that when you play piano, you’re using all ten fingers and the amount of pressure that you press, and you also use your feet at the same time. You’re taking much fuller advantage of your body. And that gets us back to the “Minority Report” thing.

Luke: Yeah. I think Bill’s been saying the same thing for the past 15 years, because I caught him at Microsoft’s MIX conference. He was saying the same stuff, just basically outlining that natural user interfaces should use the stuff that we’ve learned to do through a lifetime of living.

They actually had a nice example on stage that I thought did that. It was a four by four foot, again, screen, but the software they had running on it was this software called Rembrandt by Microsoft. And it was painting software, and the painting software did respond to ten fingers of touch, it responded to touch sensitivity, to sort of pressure a bit.

So you could, if you were an oil painter, if you will, could go up to the screen and use the techniques, the physical techniques that you use to paint in oil, to paint on this screen. You didn’t have to go through and learn the interface. You just start doing what you did naturally with your fingers, both of your hands.

Jared: Yeah. I think that’s interesting, and I can see that for things where traditionally there is this physical medium. But when you talk about the types of stuff that we mostly do on computers, like look things up or spreadsheets or stuff like that, we’ve not used our whole body for that. In fact, some people don’t even use their brains for that.

Luke: [laughs] Especially the spreadsheet part.

Jared: [laughs] Yeah. So I wonder how you move gestures and those types of things into spaces where they haven’t existed before.

Luke: Yeah, and kind of how you bring people up to speed on that. Because it takes a long time to learn to play the piano. It takes a very long time to learn to paint. How much time are people going to invest in all the things computers allow them to do?

Jared: That’s a really good point. The piano thing starts with a lot of scales, and painting starts with a lot of very basic brush technique. You practice and you practice and you practice and you practice. We haven’t really had in technology a culture of practice.

Luke: No. Outside of touch typing, right?

Jared: Or gaming.

Luke: Yeah. Gaming gets a lot of practice.

Jared: Well I mean, and seriously, gaming does get a lot of practice, right? Because the way you master a game is by running through those early levels over and over and over again until you’ve mastered those basic maneuvers. That is an essence of a lot of games.

Luke: Yeah, absolutely. And on this very related topic, Josh Clark, who talks a lot about how we get people to discover gestures, he’s lately been giving a presentation titled “Buttons Are a Hack.” And in there, he lays out all these principles from games as ways to get people to learn and use gestures.

He talks about things like leveling up, coaching, so on and so forth, taking these patterns of education that remain fun. Because a game can’t make you feel like it’s work to learn it, right?

Jared: Right.

Luke: It’s a game, it’s got to be fun.

Jared: He gave that presentation for one of our virtual seminars about a month and a half ago. It was awesome.

Luke: It’s interesting to see that same theme come up.

Jared: For sure.

Luke: Ironically, today, or yesterday I think, Apple’s new CEO Tim Cook was talking at I think the shareholder’s meeting, and he made this announcement that said, “Apple’s going to release products today that are going to blow your mind.”

So I said, “Wow, what’s going to blow my mind from Apple?” I went back to my blog, which I’ve been writing for a couple years now, and I went back to 2007 to a post I have it written about a couple patents Apple had put together. This was 2007, you know like, pre-iPhone release.

If you looked through the patents you saw in there “multi-touch gesture surface.” You saw a patent for the thing that became the Magic Mouse, the multi-touch mouse. You saw a patent for the radial wheel as a virtual interface. You saw this list of things that now, almost five years later from 2007, they’ve released a lot of them.

I was thinking to myself, well, what are they going to do to blow your mind? I looked at a couple patents from 2009, 2010, and there was really interesting things with haptic feedback, so adding more physical tactile responses to interactions with devices.

There was a bunch of stuff around recognizing fingerprints within a touch interface, so you don’t just know that you have a finger down, you know which finger, you know whose finger, which starts to get even more interesting. There were a couple things around interactions with radio frequency ID tags.

And the fascinating thing to me about looking through that was, these are all forms of input that they have these patents around. Right? So input is really this big driver of the next wave of computing, if you will. This was reinforced for me very recently by a post from this organization called Asymco.

There’s a guy, Horace Dediu, who does market analysis, and he makes these fascinating graphs about what’s happening in computers and technology, and in particular mobile. He did one analysis where he showed when there’s a major change in user interface input, the market players just absolutely change dramatically.

The most recent example of this was with the iPhone with the change of the UI going to a whole touch based UI. That completely disrupted the market. Apple and Android came in and took over, and Blackberry and Nokia and all these other incumbents completely fell off.

The power of this different form of input, whether you buy into that analysis or not, could be quite dramatic.

Jared: Oh, I think that’s really interesting. Let me think about that for a second. When the mouse came out, that changed a lot of things. For example, pre-mouse, Word Perfect was the big word processor, and post-mouse it was Word. And the mouse played a huge role in that, because it changed the way you interacted with the screen and this idea of what we would call WYSIWIG, what you see is what you get word processing became key. Whereas pre-mouse you had to have all these special codes to do simple things, because you couldn’t do select and then bold and then render it in a bold space. So I think there’s something to that. I think that in fact there are shifts, if you look at this stuff that I hadn’t thought about in that way.

Luke: Yes, I mean, I’ve been fascinated with input for years, as you know. I wrote a book about web forms. Who does that? [laughs]

Jared: Yes, only crazy people.

Luke: [laughs] At the UX Immersion event, I’m going to be doing a whole workshop kind of around input on mobile devices. And in all cases, it’s often shocking to me how little attention people pay to this stuff. Everybody’s so focused on layout and making the page look good that they just bypass the most crucial element of stuff, which is letting people contribute, letting people provide their input into these systems, making it a two-way conversation.

Jared: I wonder if some of it’s because of the lack of portfolioable stuff, right? You know, you can’t put an input field in your portfolio like you can put a really nice layout.

Luke: Yeah, I mean that could be. But the role of interaction design is definitely gaining a lot more traction, right? And people are out there hiring interaction designers. So I don’t expect these interaction designers to be showing wireframes as their portfolio. If they are, these are going to be really boring sessions [laughs], with all boxes and arrows all day long. You’d think they’d show some innovation in areas like input. You know, here’s how I kind of rethought a common flow, or here’s how we solved this input scenario to be quicker and faster.

Jared: I think that as we become really smart about input…And you know, one of the things that you’ve done a fabulous job on is helping us create a sort of language around input and the different ways of thinking about it, and the subtleties and nuances that go on. I mean, that’s really the key to any sort of advanced design endeavor is to have a way of talking about it to the developers, to the other people you work with, in such a way that you can say, OK, this works this way versus this other way, and I can see the difference.

And so, because you’ve done such a good job of putting together this visual language, as it were, of how different input gets different results, I think that it’ll become easier for people to start to promote what sort of innovation and advancement they put on their own applications. And that’ll go into their portfolio and give them some real sort of street cred and value.

Luke: Yes, I sure hope so. But the statistics sort of tell a bit of a different story. You know, if you look at something like ecommerce checkout, right? In 2011, 75 percent of all ecommerce carts were abandoned. That sounds really bad, but the worse news is, in 2010 it was 71 percent, because somehow we got worse. And we’ve been doing this for 20 years or so now, right, on the Internet.

And not only that we’ve been doing this for 20 years, ecommerce as a business, people thrive off of that transaction, off of the checkout form. So I’ve been doing a lot of analysis, and this has sort of led me to my interest in the topic we’re going to have at the event. I’ve been doing all this analysis, and all these companies that now are moving into mobile commerce, if you will, they’re just taking their checkout forms and making sure the layout works on mobile devices. And so they’re basically bringing over all the problems they had before to a smaller screen where there’s a bigger magnifying lens, if you will, on usability problems. Because, you know, the screen’s smaller, you’re using your fingers, bandwidth is an issue. You may be in any kind of environment possible instead of usually at a desk or a table with some level of privacy.

And so, these problems get magnified. And companies that literally make their living off of checkout, the only thinking they’re doing is relaying it out, as you point out. There’s so many things that you can do to kind of optimize this stuff, and in particular on mobile there’s new opportunities, new limitations. And once again, you can really take a very critical look at these things that are a core to your business and make them run a hell of a lot smoother. I’m just shocked sometimes that I don’t see that effort, right?

Jared: Do you think some of it is because it’s so hard to watch someone use your app in a mobile world that you don’t really see how much frustration you’re creating when you create some of these wacky mobile input forms? There was an example I saw you show recently where one of the forms was asking for you to put in three different types of phone numbers, with extensions!

Luke: Yeah, yeah. Your mobile number has an extension, right?

Jared: And your fax number had an extension.

Luke: [laughs] Yeah, “daytime fax” as extension. Yes, some of this is just ludicrous, is my point. And that example you’re citing, that’s one of the largest computer companies in the world doing that. You’d think they have the talent or the thinking to, you know, cover small issues like that. So it’s either they don’t know that it’s an issue… Although at this point there’s tons of data out there that shows even optional fields inside of key flows like that can trip people up pretty strongly.

I often cite that Expedia example where they had one optional field. They removed it, they got $12 million more in revenue overnight, and they found like 50 to 60 of these things in their checkout form.

Jared: That’s incredible.

Luke: Just the sheer fact that they found 50 to 60 things, right? That shows you how much opportunity there is out there. I’m guessing not all of them were $12 million ones, but hey…

Jared: No, but you know, it all adds up, right? A million here, a million there, pretty soon it’s real money.

Luke: Yeah, yeah, absolutely. And if you do it right, double-digit increases are not uncommon. I mean, there is data that got sent out around Tiffany’s, who just, all they did was make their website mobile-friendly. They sort of optimized the layout. And they saw transactions jump 30 percent. I doubt they even did anything with making checkout or making any of these core processes better. They just dealt with the layout issue. So even baby steps like that can help. Just imagine how much a real focus on these things can help.

Jared: You know, my interest always is in, how do people get a chance to watch their users go through this so that they have a real understanding as to where those pain points are, and what could come out that could be causing issues? Have you looked at that at all, sort of the way to spend time watching users use your mobile apps?

Luke: Yeah, well, in terms of the rigors around the usability aspect of those things, no. But my general approach to kind of gaining insight on this is twofold. One, I really like to trust actual behavior. And so for example, when we had out last startup we built this real-time system which would log every page view, every keystroke almost, all this stuff, so we could see in real time how people were actually using it. And that was our window into our applications universe, if you will, at any point in time. Because it was, look through the looking glass and see in real time what people were doing, where they were tripping up and how they were having problems.

And though that data stream was immensely valuable at seeing actual behavior, every now and then you hit a point where you couldn’t interpret what was going on, and then you had to go and talk to somebody. And that’s the second piece to me is, when you see something you don’t understand, or when you have an area that you have general questions around, then going and talking to a few people can really open up insights that you might not have had otherwise.

I personally am not a very big formal usability testing person. Maybe I’m just really strongly biased, because I’ve seen, you know, six to seven years of it at big Internet companies, which consisted of bringing people in a room in a very scripted regimen, publishing a report that then sits on people’s desks and doesn’t do anything.

Jared: Yes, that’s not the way to do it though, right?

Luke: No, I’ve been really burned by that, right? So I’m a lot more of a fan of, let’s see actual behavior, and let’s go and talk to people when we have questions. And some of the formality around the testing, at least me personally, I’m not very…

Jared: Yeah, but when you were working on Bagcheck, right, before Twitter marched into your life and gobbled you up…

Luke: Yes.

Jared: When you were working on Bagcheck, you spent time talking to folks and getting feedback and…

Luke: Oh yeah, absolutely. Just not in a kind of like formal usability test.

Jared: Yeah, but the formal usability testing is overrated, for sure. But to me, what’s interesting is this idea of, as someone who’s developing a website, being able to actually see what’s happening, and particularly around mobile input, right? How do I learn what’s hanging people up? What’s getting in the way? I mean, the Expedia thing is a great example, right? How do you figure out that it’s the optional fields that are hanging you up?

Luke: Right, so one part of that is the quantitative analytic stuff, right? You see those real-time logs and you see a bunch of drop-off happening in one place. And the other part of it is actually talking to people.

Jared: The drop-off doesn’t tell you why, though.

Luke: Right, that gives you the what, and then if you don’t know the what yourself…because sometimes the what is relatively easy. You see there’s a bug, right? And you see somebody, they keep clicking on this button. You look at that button, oh crap, the code’s wrong. So sometimes you can figure it out yourself. If you can’t, then you’re actually going to have to talk to people.

And in the mobile space, sometimes that talking is a lot more workflow…not workflow, but the real world use case-based. As an example, when the eBay team was developing their iPhone app — which was hugely successful for them, they did like $2 billion in sales off of it in just a single year, and in 2011 their mobile sales where $5 billion — I think the iPhone app was responsible for at least 70 percent of that.

So when they were developing that app, which that’s a lot of money [laughs] off a single mobile experience…

Jared: Really? I hope they paid that developer at least a billion.

Luke: [laughs] I really doubt it.

[laughter]

Luke: But that’s not how much they made. That’s how much they sold off of it, right? Global merchant…

Jared: Oh, I see. OK.

Luke: …it’s called. GMV.

Jared: That’s true. Knowing eBay, they probably actually didn’t make very much at all.

[laughter]

Luke: I’m sure they’re doing OK.

[laughter]

Luke: Anyhow, when they were building it, one of the things that they did was they actually went into stores with this application. Very early on they tried to do price comparisons in the back of a Fry’s or the back of a Best Buy if you will. They really quickly saw how network connections can break down back there.

Then they took that back to the office where they’re in their sterile high network connectivity environment and made a bunch of changes to address that real-world use case.

Jared: Yeah, so OK. So that makes a lot of sense that going focused that way and seeing what’s going on, trying it out. You know, it’s interesting. I was having a conversation the other day with someone about the analytics you can use for figuring out user experience stuff. I don’t know. Maybe you can tell me if this is the way you feel.

I’ve come to the conclusion that the generic packages that are out there that are put together by the big analytics companies may work great for campaign monitoring. But it’s really hard to get any detail, and you really have to instrument your applications specifically for what you’re trying to do and not use Omniture or Webtrends or any of these things because they don’t really provide much value in that UX space. I don’t know if you found that.

Luke: With our startup, we built all our own, right? We sort of did that on purpose because we had very specials interests in what we tracked and how we tracked it. I recently had this aha moment when I was working on building out my own server [laughs] over the past few weeks or so. It dawned on me that this is the back stage part of the show, right? You design the back stage as much as you design the front stage.

In order for you to really have a sense of how the front stage, how the performance can work really, really well, you’ve got to adapt that back stage. And it’s custom for everybody, right? There’s no generic back stage package you can just set up and it’ll work for everything. I think this is a very similar situation on websites, right? Because ultimately, if all you’re doing is measuring page views, then you start to get into, I think, really negative behaviors around optimizing for page views.

So what you really want to do, rather than tracking these standard analytics things, is actually have your own personal metrics. What are the things that matter to the type of experience you’re trying to create? Most off-the-shelf packages won’t give you that.

Like eBay, for example, tracks how many people buy things on their mobile apps, which turns out it was about three a second. How many people buy cars using their mobile products? Which is about 2,600 a week. How many people sell things using their mobile products? Which is around 700,000.

Jared: They sell 2,600 cars on their mobile app?

Luke: A week.

Jared: A week?

Luke: Yeah.

Jared: That’s crazy.

Luke: Yeah, and this is this bigger thing. I keep hearing from people. I go and talk to people about mobile, like “Oh, yeah. Well, we didn’t include that because we don’t think people are going to do that on mobile.” I say, “Guess how many cars eBay sells a week on mobile devices?” “Well, I don’t know. Like 10?” “No, not frickin’ 10. [laughs] 2,600.”

Jared: 2,600 cars on mobile devices. That’s nuts!

Luke: That is nuts. The bigger story there though, and this is the one that has been gotten really lost is they may close the deal on the mobile device, but maybe they started the research on a desktop. Maybe they looked at pictures on their iPad. Maybe they went into a dealership and looked at a comparable car. This is the world people live in now, that they have access to the network and to digital information in all parts of their lives.

The way they go through workflows is a much more complicated cross-device sort of a structure than what we used to do before, right? It used to be that your digital strategy before was make a website. Then for a little while it would be like, “Oh, let’s make a mobile app.”

Even now when people think about mobile, the big strategic decision for them is native app versus mobile website. Lost in that, if that’s how narrow your focus is, is really the experience people have between your desktop website, between your mobile website, between the app, between going to your physical store, right? Between going to some other location that’s related to whatever service or content you have.

Jared: Yeah. You know, just the other day I was sitting in a Starbucks having a conversation with an old friend, and he just out of nowhere he starts talking about this book he read that changed his life. So while he’s sitting here, I’m looking it up on Amazon. And I press the one-click button, and boom! The next day I have that book in my office.

Luke: Yeah, absolutely.

Jared: It didn’t change my life though.

[laughter]

Luke: That’s a shame.

Jared: But you know, we live in the future, right?

Luke: Yeah. No, totally.

Jared: This whole being able to, in a coffee shop, without moving my ass out of the seat, buy a book that someone mentioned 45 seconds earlier.

Luke: Yeah, and that brings us back full circle to what we were talking about. People just copying over checkout to the mobile device. If you want to take advantage of opportunities for input like that, if you are a book seller who’s not Amazon for example and you have a checkout flow, wouldn’t you want somebody to be able to instantly within that minute purchase it?

There’s techniques that can get you down, if you’re buying a digital item, to like three input fields to buy something on a mobile website from three pages of 10 or 20 fields each. I personally think those [laughs] techniques are worth the effort because you can do things like you just described, right? That shouldn’t just be the domain of one company, Amazon. Otherwise Amazon’s going to crush everybody even more than they’re crushing them now.

Jared: Yeah. Yeah, I think that’s absolutely right. There’s lots of interesting things that are happening that way. Intuit has this cool app where you take a picture of your W-2 form, your tax form that you get from your employer. And it automatically scans it in, parses it, and starts your tax return. If you have a simple tax return where in fact you only work for the one dude and that’s all your income, you’re 99 percent done with your taxes by just taking a picture of the form.

Luke: And that is so sweet. That’s input, right? That’s a totally different way to think about input. Just to say, it’s just all these fancy high tech take-a-picture-scan-it sort of solutions, right? The basics as well still matter and, in fact, the basics probably matter even more. I hope more people come around to that. [laughs]

Jared: We have this idea that we’ve been working on here at UIE, which we call tool time. Tool time is the opposite of goal time. Goal time is thinking about the things in life and working on the things in life that make you happy and really energize you. Tool time are the time you have to spend to just make the tool get you to the point where you can do the goal time stuff.

So filling out your shipping address and your billing address doesn’t make the purchasing any sweeter, right? If you spent twice as much time putting in your phone number and your credit card number, you’re not any happier with the product that you just got. So that’s all tool time. And I think a lot of what mobile does is it really amplifies the pain and the agony of tool time in a way that we haven’t seen before.

Luke: Yup, that’s what I call the giant magnifying lens on your issues, right? If it’s an issue on your website, it’s going to be like a 2X or sometimes even a 10X issue on your mobile experience.

Jared: Oh, that’s really smart. I like that. I’m going to steal that.

Luke: Yeah, steal away.

Jared: [laughs] That’s really cool. Oh, Luke. This is awesome! So your workshop at UX Immersion is basically going to help everybody figure out how to eliminate all this tool time from their applications and do input in these innovative, clever, awesome ways.

Luke: Yeah, that’s exactly right. We’re going to talk about all the basic stuff that we’re ranting around, and then I’m going to get into showing lots and lots of examples of the more innovative stuff, talk about some of the technologies underneath it so people know how to work with this, right? If you want to work in this medium, I think it helps to understand the structure of it a little bit and what are the opportunities so you can go and apply it to what you’re doing.

For a lot of people it’s a black box right now, right? Like “Phone does cool thing.” But if you understand some of those capabilities, I think you can get to some really cool design ideas.

Jared: I think that’s awesome. I think that’s really incredible. I’m looking forward to it. I’m very excited about it. I’m glad you’re going to be there. I am going to be there. We’ve already had a whole bunch of folks sign up, and there are still seats left but they’re going fast. I’m very excited about it.

Luke: Great. Me, too.

Jared: OK, so everybody, if you have not signed up and you want to attend Luke’s workshop, it’s going to be at the UX Immersion Conference April 23 through 25 in Portland, Oregon. You can find out all about it at UXIM.co or just go to the UIE.com site and hunt around aimlessly until you find the icon that says “UX Immersion” on it.

You will then find your way to all of this great stuff that’s happening in Portland, and Luke will be there. Luke, thank you again for taking this time to talk to us today from beautiful Quebec.

Luke: Yes, it actually is quite beautiful here.

Jared: Yes, yes. It’s rainy and miserable here in Boston.

Luke: [laughs] Sorry to hear that. [laughs]

Jared: We’re having a Portland winter [laughs] in honor of the UX Immersion Conference. But no, thank you very much for spending this time today and making me a smarter dude.

Luke: My pleasure as always. Thank you.

Jared: Once again, I want to thank everyone for encouraging our behavior, and we’ll talk to you later. Take care.

Which one would more likely produce a portfolio of great designs over time? Our research suggests the proficient prototyper will beat the innovator.

The prototyper has the advantage of quick iterations on their side. While their initial designs won’t be anything special, they can get immediate feedback, make changes, and try again. Over time, their designs will evolve into something quite special.

In today’s UIEtips, I explore how prototyping is coming back as an important design tool. Starting with a brief history of prototyping and why it went away for a while. We look at how the best teams are making investments in mastering multiple prototyping methods, to give themselves the best flexibility.

Read today’s article: Prototyping’s Resurgence – Communicating the Designer’s Intent

At our April UX Immersion Conference, Dave McFarland has put together a full-day workshop to help any designer learn to become proficient using JavaScript and jQuery, two of today’s most powerful prototyping tools. See Dave’s workshop details.

You’ll be the envy of all your co-workers

Register by March 13 and you receive a free designer’s toolkit filled with the following items:

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

Find out more about the toolkit.

Immersive Education makes you a better UX Pro

At the UX Immersion conference you’ll choose from 6 different full-day workshops on Agile development or mobile design. Plus you’ll have a full day of 90-minute talks to catch some of the material from other workshops you didn’t choose.

Explore the full UX Immersion Conference agenda.

With mobile, you simply can’t have as much content on your pages as you do on the desktop. Intranet access within enterprises is crucial and accessing it with mobile devices is beneficial. However, the vast amount of pages and content is cumbersome and impractical for a mobile setting.

James Robertson asks, what are the few essential things users need while they are away from their desks? Addressing this question allows you to pare down the experience to fit the mobile context. Providing quick access, through just a couple of taps, to content that may otherwise be buried on the desktop.

Surprising to some, much of the innovation in mobile intranet design is coming from university and government organizations, notes James. They are finding ways to address the fact that users may be accessing the intranet from different devices, making delivery a challenge. This “bring your own device” culture, as James calls it, also offers new opportunities for the richer interfaces of iPhones and Android devices in corporate settings.

James will be teaching a full day workshop, Innovative Mobile Intranet Designs for Your Enterprise, at the UX Immersion Conference April 23-25 in Portland, OR. Learn more about his workshop and the rest of the UX Immersion Conference at UX-Immersion.com.

As always, we love to hear what you’re thinking. Share your thoughts with us in our comments section.

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

Full Transcript.

Jared Spool: Welcome everyone. I have with me a real treat today. We have James Robertson, from Step Two Designs, all the way from Sydney, Australia, which sounds far away, but actually I’m much closer because I’m, interestingly enough, in New Zealand today.

But this sort of Southern Pacific exercise here is to talk about some really exciting stuff that’s happening in the mobile intranet design space. James is probably the person on this planet who knows most about what people are doing in that space because he runs a fabulous set of innovation awards for intranets every year. James, welcome.

James Robertson: Good morning, Jared. How are you?

Jared: I’m fine. Now, at the UX Immersion Conference, you’re going to do this whole day event on mobile intranet design and what makes them innovative and stuff. A lot of what you you’re going to be talking about came out of the awards that you put together, right?

James: Yeah, that’s right.

Jared: Tell us a little bit about these awards.

James: Yeah, we’ve been running the awards for, oh, five years now. I guess a few years ago we said, “Look. Mobile, it’s big. Clearly, it’s big. Everyone has an iPhone or an Android now.” and this is a few years ago.

So this year we outlined the themes we’re looking for, the exciting stuff we’re expecting to see, one of them is mobile, and we got nothing. And that was disappointing.

So next year we said, “Right. We didn’t get anything last year, but look, you’ve had a whole year for this now, so this year, this year is surely the year.” and we got… nothing.

But last year, last year I think the enterprises finally caught up with the consumer space, it moves a little bit more slowly, and we’ve started now to see some really interesting stuff.

Jared: So, the types of stuff that you’ve been getting now is coming in and it’s really focused on a bunch of different areas, right? Some of it is productivity related stuff and some of it is looking at taking advantage of things that you can do when you’re not at your desk.

James: Yeah, that’s right. We had a few really remarkable entries: one was from UK Parliament, another one was from Queensland University of Technology, and the third was The Five, which is a big multinational. Certainly for the first two, they’d independently come up with the one critical question, which is, what are the handful of things that staff need when they’re away from their desk?

Because what you don’t need, you don’t need a mobile version of your intranet. You know your 5,000, 10,000, 100,000 page intranet is not the easiest thing to use, even on a big screen, and my goodness, we don’t need that on a mobile.

So I think both these organizations, both Parliament and QUT, both said, “Wait a second. What are the few things, the six or eight things that the people need, that they require when they’re actually wandering about or at meetings?”

And they came up with quite different answers, but, as you say, it’s a lot about productivity, it’s a lot about having access to some of their key tools. I mean some stuff is obvious, things like having access to your staff directory on your mobile.

You think about how many times you might need to look up a phone number when you’re not at your desk. You’re running late to a meeting and you need to give someone a ring, or you’re in a meeting and want to pass across a number, or you’re on the bus, or you’re at a client site.

And yet, I’m amazed at how many organizations don’t yet have this on their mobiles for staff. I mean it is such the killer app. So hopefully, with some examples now of what this looks like — and by the way, it looks incredibly simple — hopefully now we’re going to see a lot more organizations do this kind of stuff.

Jared: Well, I’m intrigued that, of the three organizations that you mentioned, one of them is a government organization, another one is a university organization.

These are not what I typically think of, and maybe it’s just an unfair stereotype on my part, but it’s not what I think of as organizations that invest in leading edge technologies and are out there before the big multinationals and the organizations that are focused on squeaking out profit out of every corner and looking for the technology capabilities to do that. Here you have organizations that in both cases, if I’m not mistaken, are hundreds of years old, right?

James: Mm-hmm, yeah, that’s right.

Jared: And so, these organizations predate technology, let alone mobile technology, and yet, they are doing some of the work on the forefront.

James: Yeah it’s funny. I think, to a certain extent, they’ve become innovative because they had no money, they certainly had no budget. Let me take the UK Parliament example, that was delivered in a hurry, because, you may have heard, there was a small change of government in the UK and a few new Parliamentarians came in.

So there was this small window of opportunity to deliver some new capability for all these fresh faces. They basically had a guy in a Metallica T-shirt, I’m reliably informed, sitting in a corner for a couple of months, who just wrote the mobile interface with a budget of nothing.

Likewise with the university, on the central team there was a couple of guys working on the side as a hobby, and again, they cranked it out in a couple of months. That was I think the thing that really jumped out to me, was that the really elegant solution is the simplest. It’s one of those solutions you look at and you go, “Gee whiz, why didn’t I think of that?”

But by simplifying down, rather than going, you know, “Hey, we need this massive enterprise strategy. We need to spend millions of dollars going off deploying new tools and buying stuff from vendors.” these organizations went, “Well wait a second. It’s just the web, right? It’s HTML, mobile-friendly HTML, but we know how to do HTML. And it’s a handful of pages, really great pages, but this can’t be that hard.” And it isn’t.

Jared: So is that what much of the stuff you’re seeing is these days is web based mobile versus native apps?

James: Yeah, I think it is. I mean, talking with the award winners in my travels, they were confronted by the fact that there are a pile of different devices floating around organizations, obviously Blackberrys originally, particularly in bigger corporates.

But if you look at, say, UK Parliament, they told this really funny story, at least it’s funny to the English. But they talk about, well, each of the Parliamentary parties was given a mobile device, as a standard thing. And so the question was, I guess, what did people get?

The Tories, which is a kind of conservative party, what did they get? They got a Blackberry. OK. So then Labour, which is, in theory, the more left wing party, or central party I guess, what did they get? Well, they got iPhones. Then the liberal democrats, the Lib Dems, who are definitely the left wing group, who are definitively not the two other parties, what did they get? Well, not what the other two parties got, so they all got Androids.

Jared: Wow.

James: So now you’ve got three groups, three stereotypical purchases. There’s now three groups with three different phone technologies, so you cannot deliver an app. So to get cross-platform compatibility, really, web’s the way to go, and that is, of course, you can do more and more with HTML5 as time goes on. And as you see organizations, I guess, noticeably, like IBM and Cisco and people like this starting to do BYOD, bring your own device.

Jared: Yeah, I was going to ask you about that. A lot of folks are for their corporate enterprise, this is a really different strategy than what they had on the desktop. A lot of people can’t use their home computer on the desktop except VPN-ing in, and even then they’re not guaranteed it’s going to work.

Because IT controls all the systems and as a result lots of folks run on technology that is now dated by years, big and bulky and slow, because it’s too costly to replace all that hardware. But, in mobile, it sounds like now you use whatever you’re bringing with you, right?

You use the phone in your pocket, or the iPad Tablet, so that means less control over the final delivery device by the IT folks, right?

James: That’s the theory. There have been a small number of high profile organizations that have gone down this route. I think the primary driver for this is not the millennials that I’ve heard written about in various articles, but it’s actually the senior executives.

The senior executives have all said, “I want an iPad.” or, “I’ve already bought an iPad and I’ve bought my iPhone and I want this to work on the network.”

That’s great in the sense that, as you say, it starts to close the gap between the incredible consumer technology and the pitiful enterprise technology. I feel like desktops in enterprises are still running Windows XP, in many cases.

So it may be great, right? We’re going to finally get the enterprise into the modern age, but it’s a hell of a challenge. I mean it puts immense pressure on IT. It puts immense pressure on web teams and intranet teams who are suddenly told, “Well, the CEO has got his iPad and next week he wants to be able to not just read his emails, but get his briefing notes for the executive retreat. Can you please deliver something?”

But there’s also a lot of very valid questions about security, about what happens if phones are stolen, or even just support and compatibility. So I think, as a minimum, we’re going to have to deliver enterprise functionality via HTML, because if BYOD isn’t in place it is certainly threatened.

But there’s a big learning curve I think for organizations to work out really what this means and how to actually deliver it in some practical way.

Jared: In addition to the contact address book app that you talked about, what are some of the other interesting things you were seeing in the award submissions?

James: It’s a few things. At Parliament it’s about the Enunciator, which is a strangely named thing that does have several hundred years worth of history. It’s the announcement of what is happening at this moment in the Houses of Parliament, so what bill is being debated in the houses or what question is being covered in committees.

It’s up on the screens all over the place, including in a pub down the road apparently. But the MPs absolutely need to know this, because the bells ring, and there are actual bells and they ring, and then they’ve got a certain number of minutes to get into the chambers before they close the doors and they vote, so you need to know exactly what’s happening.

So this is their killer app on the phone, is that they might be out in a restaurant or in a meeting room, almost certainly not at their desk, having secret meetings and back door negotiations and [laughs] all the rest of the…

Jared: Like you do.

James: Yeah, as one does. So in their phone then they’re able to say at any given point what’s happening. That’s a republishing of content that already exists on the intranet, so it’s not a duplication. In the university example I think that’s even more compelling. There’s a couple of screens that has things like exam results. See it just says “exam results,” and you go in. There’s a list of the subjects, and you click on the subject and you find that there is your exam result.

That’s interesting for two reasons. First off, it’s not “My Exam Results”, all that ghastly stuff you get on intranets you know, “My Favorites,” “My Tools,” which of course are not my tools. They’re set corporately. There’s a kind of fake personalization. Well, you don’t get that on the phone. It’s just “Exam Results” because of course our phones are personal devices.

Of course it’s my exam results. It’s my phone. It’s in my pocket or in my handbag. So it starts to really recognize that these are absolutely personal devices now, and we need to treat them as such. So that really starts to transform the way we deliver information compared to the clunky way we do on the desktop.

And it also means, the other exciting thing about that is, say you look at it and OK, there’s the exam results, something that students probably care a fair bit about. There’s two clicks to get there, and it’s just presented. Now if you look at what you get in the desktop, then, well, there’s your e-learning system, your LRMS. And you go into that and no doubt there’s a click from the intranet home page, and then you hopefully don’t have to put in a new username and password.

Then you’re in this whole system, and it’s going to be either Blackboard or Moodle and the cast of universities. Much clicking later you will eventually find your way to the area of courses and course information. Much more clicking later you eventually get to the exam results. If you look at what intranet teams have been asking for, it’s like, “Well, can we on our ‘student portals’ have that stuff on the home page?”

“Oh, no. No, no, no,” says IT. “That would be way too costly. It’s complex. Look. If we do that kind of integration, there will be problems with upgrading. Oh, no. Look. Look. No. All we can do is link to it.” Yet it’s on the mobile. It is, in fact, integrated off the back end. It has just quietly drawn stuff out via APIs. It’s easy.

Now, I think, I wonder whether there’s going to be a reverse takeover from mobile to desktop, where people go, “Well, wait a second. If it’s this simple on my mobile, because it has to be that simple, why is it so awful on the desktop?”

Jared: Yeah, it’s interesting that you say that because that’s a question that’s come up before. Luke Wroblewski has been talking about that, too. His thinking is that if you design mobile first, then suddenly it changes the way you design your other experiences like your desktop experience. I think that there really is something to this.

I mean we’ve seen it so much that Apple has changed the way you scroll on the desktop to match what was going on on their IOS devices, which that was not an easy decision to make.

James: Yeah, that’s awful. I’ve just upgraded, and can I just say…

[laughter]

James: …I’m complaining. So I think where done properly, yes, and that example I think is horrendous. But you’re right. I think Luke’s spot on because you can’t waffle on a mobile device. You can’t deliver 500 pages of stuff where five would suffice. I think it forces a focus on simplicity and also I think productivity.

That mindset, if applied to the desktop, would transform a lot of what we do particularly in enterprises where there is a lot of very clunky user experience.

Jared: It seems to me that in the intranet world where budgets are often very constrained and projects have to be turned around very quickly that taking this idea of looking at that mobile experience first, figuring out what those essentials are, that would pay off really well. Particularly because you’re doing it in HTML, transferring that back into what you use on the bigger-screen devices, that’s got to pay off pretty fast I would think.

James: Yeah. The 80/20 rule applies here. There’s absolutely no question that 20 percent of tasks generate 80 percent of the usage within organizations. Yet the funny thing is most intranets spend their majority of time on the 80 percent and not the 20 percent. So huge amounts of time are spent sort of structuring or restructuring corporate services areas, HR policies, finance documentation, and stuff like this.

But that’s not the stuff that people need to do frequently. Often it’s actually out at the front line and in operational areas where people are out doing tasks dozens or hundreds of times a day. If we take that principle from the mobile as you say of focusing on a few key things and designing them well, then I think we could generate immense productivity gains within organizations.

If there’s one message I think from this year’s award-winners, is that great design, great solutions, doesn’t cost much. In fact often the less you spend the better the [laughs] solution. That’s I guess been a key thing for all five of the years of the innovation awards, not just on mobiles more generally, is to get people to realized they don’t have to do big solutions, that actually a collection of small well-focused solutions often gets a much better result.

Jared: I wonder if this is how it plays out, right? When you do a small solution, typically first you don’t have the whole eyes of the organization on you every moment because you’re not spending a billion, gazillion dollar budget, right?

You’re doing some sort of thing, and you get a chance to put it out there. Because it was small, it didn’t take a long time to get out, which means that you get feedback pretty quick. And because it’s small you probably get feedback just from a handful of folks, but it’s really good feedback. And you can then change it because it’s small. It doesn’t take much effort to change.

And then you’re iterating a lot more instead of having to get it right the first time type mentality. As a result, the end product after all that iteration and after all that really quick change involves you learning so much about what works and what doesn’t that it makes it easy to do other small projects. Do you think all of that becomes true?

James: Oh, absolutely, and Parliament provides a great example of that I think. I mean they talked about one of their expected killer apps was maps of the Houses of Parliament because it’s four or 500 year-old building. Actually they’ve got multiple buildings, and they would get lost a lot. So they thought, “Right. Maps. Maps on the mobile device. Brilliant! Now they can possibly even tell you where you are.”

So they worked at this, and then fairly soon though, the security people popped up and had a quiet word and said, “Well, look. Actually, maps. You are aware that the Houses of Parliament are the number one terrorist target in the UK and that it’s actually a state crime to release accurate maps to people who are not staff?”

Jared: Really?

James: So it’s like, “Ah.”

Jared: [laughs]

James: So they talked with security, and I added extra security on the devices. Frankly, I ended up having to reduce the level of detail of the maps. So what they actually delivered were crap maps.

Jared: [laughs]

James: And look. As it turns out, crap maps aren’t that useful. In practice some new MPs discovered there’s a, you know, policeman or a security person practically inside of anywhere they go. They can just ask directions. But they didn’t spend a lot of money on this, and to your point, they launched it. Version two, well, they’re going to take it out, and they’re actually asking them to allow them to simplify the security access to the mobile device.

And you know, had they done more research, had they had more time for more research, they may have uncovered that. But even without that, they’ve learned valuable lessons. They can make improvements. They’ve already got a pile of new opportunities on the horizon including giving iPads to all MPs, which has got a bit of news coverage. So yeah, that success has bred more success, and I think that’s absolutely the point that you’re making.

Jared: Well, I’m very excited about the workshop that you’re going to be teaching at the UX Immersion Conference in Portland in April because it’s really the first time that I know where any major user experience conference has looked at mobile intranet design in any detail. And because I think there’s so much opportunity in this space, I think it’s going to be great that it’s on the program.

More importantly, I think it’s great that you’re the one who’s leading the workshop because all the experience that you have in this and all the folks you’ve talked to I think will really help people create really great designs and do it in a way that meets budget and gets productivity out there without having to, like you said, put in these billion-dollar vendor contracts.

James: Yeah, and I think I’m looking forward to making the participants work hard because I have high expectations about the brilliant folks that will be attending. We’re going to collectively work hard. We’re going to be as a room scribbling designs and looking at what the future of enterprise mobility looks like. I know I’m going to learn an awful lot as well.

Jared: I think that’s really exciting. I love when we have a chance to do a full-day workshop on a topic like this because you really do get to the areas of this that are filled with subtlety and nuance that you really can’t cover in a half an hour or a 45-minute talk. My sense is that what separates these award-winners from folks who just do a meager job is really that sort of nuanced design element that takes something from being crap as you put it and make it into something really useful.

James: Yeah. I think it’s design, and I think it’s value. It’s business value that they deliver, and that’s definitely what we’ll be exploring in the workshop.

Jared: Well, fabulous. Fabulous. So everybody, if you want to hear more from James, you definitely want to sign up for his workshop at the UX Immersion Conference, which is going to be at Portland on April 23-25. You can find out more information at Uxim.co. James, thanks for taking this time to talk with me from all the way in Sydney.

James: My pleasure. Thank you for interviewing me all the way from Wellington, New Zealand.

Jared: Yes, yes. [laughs] I came just to do this interview. It was easier than trying to do it from home.

James: I’m honored.

Jared: [laughs] And I want to thank our audience for spending another bit of time with us, and I hope you enjoyed it. Thank you for encouraging our behavior. Talk to you soon. Take care.

With this new program, we’re trying to fill a huge unmet need: How do we bring today’s UX Professionals to a new level of producing great designs? How do we, in just a few days, give them the skills, knowledge, and confidence to go off and create really great stuff as the world around them is changing?

With that mission in mind, we set off, like we do, to research what today’s UX Pros are most in need of. We knew we had to carefully select our format, topics, and speakers, to make sure we really delivered something that would move the needle.

While there’s a growing amount of UX resources out there, it’s hard to find the really great stuff. Sure, you can go to any number of conferences, workshops, and UX magazine web sites. However, we found it hard to get an in-depth understanding on a topic. It always feels like, just when the article or conference session starts to get interesting, it ends, leaving with a ton of unanswered questions.

This is why we focused on building an event around full-day workshops. In this age of shortening conference sessions to 20-minute TED-talk-style presentations (or the even shorter 5-minute Ignite formats), we’re giving each expert six full hours to get deep into their topic.

The beauty of full-day workshops is you can get into the subtleties and nuances of a topic. At UX Immersion (or UXIM as we’ve come to talk about it), each expert speaker spends about an hour with the big-picture overview, just as they should. That leaves five full hours of workshop to get into the nitty-gritty details.

Because of the full-day format, each attendee gets a chance to do something we don’t often get to do in our day-to-day work: practice our craft. Each workshop has specially crafted activities to give you a chance to exercise the skills you just acquired, under the guidance of the workshop’s expert leader.

There’s another advantage of the full-day format that we love: you get to ask detailed questions. The make-or-break aspects of our work require an understanding of all those details that go into our current situation. With the time, you can pose your trickiest questions to the expert and bring home solid take aways: new strategies, clever approaches, and the depth of experience you can only get when people really get when they have a common language and understanding.

We didn’t pick this year’s UXIM topics — mobile design and Agile development — at random. Practically every UX Pro we’ve talked to is dealing with one or both of these areas (or will be very soon). And those topics require the depth of understanding to work down to the make-or-break details. They are perfect for the full-day format.

And we didn’t pick this year’s UXIM workshop presenters — Rachel Hinman, Hugh Beyer, Jeff Gothelf, Luke Wroblewski, Dave McFarland, and James Robertson — by accident. These guys are the best in the business and fabulous instructors to boot. They are the perfect folks to be learning from, since they know their stuff and communicate it so brilliantly.

That’s why we’re so excited about April’s conference. If you’re a UX Pro and you see yourself dealing with either mobile design or Agile development in your future, you need to get yourself to the 2012 UX Immersion conference. You don’t want to leave yourself behind while your peers are leveling up their UX skillets.

[Register by the end of today, 29 Feb 2012, and you'll save yourself $300 on the full conference price. Details at the UX Immersion site.]

As we were talking, I had suggested that a UX Design Library was a snapshot of what the team felt the future of the design would be like. “Oh, no!” Nathan exclaimed. “I strongly disagree with that idea.” He went on to say that the library really was a snapshot of the past, not the future. A great library represents the best and most promising pieces of the design, so that future work could take advantage of what can be done.

Creating a library that works for the team isn’t technically challenging. However, to ensure its a success, there are important considerations and steps that the team needs to make.

In today’s UIEtips, we look back at an article from Nathan. In the article, he walks us through the process of creating a library. He’s broken it down into four doable steps (and even has a fabulous poster-grade visualization of the process). You’re really going to enjoy his article.

Read today’s article, How to Create a UX Library.

Every conversation I have with Nathan is eye opening and amazing. That’s why I eagerly agreed to work with him again on a new virtual seminar, Start Full Screen: Organize, Communicate, & Annotate HTML Prototypes. We love Nathan’s thought process around libraries, and we’re sure his thinking on HTML prototypes will be enlightening.

And as a bonus, when you register for this virtual seminar, you’ll get EightShapes’ CSS & JavaScript library along with a sample HTML prototype that demonstrates all the concepts covered.

Lean UX can eliminate the contractual obligations inherent with specification documents and other deliverables. Designers and developers find it frustrating to put so much effort into a project then not see it ship at the end. Using the Lean UX process, you’re constantly validating your designs, especially early in the process. This motivates the team to work towards the same end goal.

Jeff Gothelf spearheaded this approach during his time at TheLadders. Through his own experience and through coaching other organizations, Jeff notes that teams implementing this process focus on a collaborative working process. Having the entire team on the same page allows for success in shipping better products, earlier.

A key part of attaining this efficiency and shared understanding is pairing designers and developers. By working so closely together, they engage in a consistent and open dialogue. Not only do they learn each other’s craft, they also work towards the right solution.

Jeff will be joining us to present a full-day workshop, Lean UX: A Radical Approach to Integrating Design into Agile at the UX Immersion 2012 Conference, April 23-25, in Portland, OR. He’ll focus on integrating UX into an Agile process. Learn more about UX Immersion.

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

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

Full Transcript.

Jared Spool: Welcome, everyone, to another episode of the SpoolCast. And I have returning here Jeff Gothelf, who is now out on his own and at… what is the name of your new company? It’s so new I don’t even know the name of your company.

Jeff Gothelf: It’s called Proof.

Jared: Proof. Proof as in half the alcohol.

Jeff: Yes, exactly right.

Jared: Awesome. And Jeff is going to be speaking at our upcoming UX Immersion Conference, which is going to be April 23rd through 25th in Portland, Oregon, and he is one of the sort of thought leaders behind this whole Lean UX thing that’s been happening that we’ve been very interested in, because it’s got some really interesting attributes to it.

A few weeks ago, he and I had a chance to record a podcast where he sort of explained what the Lean UX thing is, and if you haven’t listened to that, we’ll put a link to it in the show notes.

But today I wanted to talk to him about sort of the downstream effects that happen when you get this stuff in here, because I’ve been realizing that this is really powerful, and there’s really something to it. So I’m very excited about what Lean UX means. It’s a new way of thinking about your process and everything.

So Jeff, welcome.

Jeff: Thank you, Jared, happy to be here.

Jared: And so, just sort of quick recap, Lean UX in 17 words or less.

Jeff: Oh wow, uh… Wait, that was three words right there.

Jared: Yeah.

Jeff: Lean UX is a rethinking of the software design philosophies and methodologies, moving away from the contractual obligations of spec documents and focusing really more on validating your designs through building products and experiments.

So in essence, your designs are hypotheses; let’s validate or invalidate those hypotheses as quickly as possible so that we can spend time going down the right path and less time going down the wrong paths.

Jared: Yeah, so you’ve actually had a chance, when you were at TheLadders, you sort of put this into play there, right?

Jeff: Yes, absolutely.

Jared: And then you’ve also been coaching and working with other organizations that are putting this into play. And they’re all seeing really positive results, and that’s what’s got me all excited about it.

Jeff: Yeah, the end results of this are really, really impressive. I mean, the most demotivating thing any team can undergo is to work on a project and then not have it ship. Nothing demotivates designers or developers or anyone else who’s involved with a particular project, is to work on it and then not have it ship.

And what I think is really powerful about Lean UX is that because you are validating your ideas early and often, when you get to the end of a project, when you are ready to ship, the thing actually ships. And that is a very powerful motivator for a team as they’re working towards some kind of end goal.

And when I’ve done this with teams at TheLadders, and I’ve helped other organizations put these teams in place, those teams who have successfully implemented the process have built a collaborative working process between designers and developers and marketers and product managers and business owners have been able to ship product, first of all, much sooner than they would have in the past, and to much greater efficacy. And so they’ve seen greater success, and the learnings that they get help them improve and refine the products on a much more regular basis.

And so then what you see happening is whatever problem statements or whatever metrics those teams are tasked with moving forward, they begin to actively move the needle on that. And that is impossible to hide within an organization, so whether or not they’re publicly touting their wins or not, the organization begins to see that there is success happening with this group over here.

And so what happens after that, what’s really interesting is that the other teams in the organization start peeking, kind of looking over the wall, looking over the cube wall or looking at other teams, and saying, “Hey, what are those guys doing? How are they doing it? Why are they able to move their metrics so significantly in such a short amount of time, whereas we haven’t actually done a thing to move our project forward?”

And I’ve seen this happen. The team becomes the envy of the organization, and ultimately, when that gets recognized by senior management, that team becomes the model upon which other teams and really the entire organization’s methodology is based on. It’s extremely rewarding, and a very powerful win for the Lean UX process.

Jared: So this is really interesting to me. And so let’s go back to what you were saying about shipping, we’ll start there.

So there are a lot of teams where something ends up shipping, but it doesn’t look anything like what the designers had in their head at the time that they turned it over to development, right? You know, in the traditional waterfall process of design and development, you work on all these documents, and you try and specify everything out to formulate this, what’s in essence a contract.

We say we want this to be built, you as the developers, you promise to build this thing that we want to be build, and we give it over to you, we pass it over the wall. And then development goes off, and some months later, through the rumor mill, you’ll hear, “Hey, guess what? That thing you worked on, it’s shipping next week.” And then you get a chance to see it, and it’s like, “whoa, that’s not what I did.”

Jeff: Yes.

Jared: Right? So help me understand, does Lean UX help in that scenario because we get much closer to what the shipping version will look like?

Jeff: Yeah, absolutely. And the reason for that is because there’s a shared understanding across the entire team almost from the get-go as to what exactly is being built and why it’s being built that way and the decision history that went into that.

And so as you iterate through this lightweight design process that’s focused on really just gaining as much insight and feedback as possible, you’re pulling in the other members of the team and you’re saying, “OK, we ran this sketch, what do you guys think?” and they give you some feedback. “Well, when we showed it to customers, they said X, when we showed it to business owners, they said Y, so together, we’ve decided to kind of move it forward in this particular direction.”

And as that’s happening, the entire team is coming along during that… it’s not a negotiation process, right? Whereas in the old days, like you said, it’s a contractual binding between the team that says, “I wrote this down, now you go build it this way,” and that’s really kind of where the beginning of the negotiation process starts with development and anybody who was traditionally downstream from UX and design.

When you employ Lean UX, what I’ve seen happen is the teams are in constant conversation around what this thing is going to look like, how it’s going to evolve, why it’s going to be that way, which is really critical, right, why. It’s not because the designer said so or because the business owner demanded it, it’s a combination of those factors, technical feasibility, input from the team, input from customers. And the team builds this shared understanding of what the end result is and what it should be.

And what’s extremely powerful is that they’ve set off to solve this problem together. Instead of saying go build this particular solution, the team has together come up with the right solution. And so there’s a greater buy-in from developers, from product managers, et cetera, and there’s a much heavier investment in the quality and the efficiency of getting the work out, and so they know all along the way what this thing is going to look like, there are no surprises.

Jared: That no surprises thing I think is huge, right? Because it’s really what snags a lot of folks. You know, the developers are surprised because they didn’t know this requirement was coming, the designers are surprised because nobody told them that they had to design for this implementation constraint.

You know, it’s really interesting, I was talking with one of the folks who worked on Google+, and we were talking about the constraints that she was under as she was designing it. She said, “You know, all my constraints came from engineers. I didn’t have any constraints from the business owners. All my constraints came from, ‘I don’t think we can do that technically.’”

And in a lot of organizations, the developers aren’t even in the conversations when they’re creating design, so those constraints don’t surface until they see these deliverables, and then they’re like, “How the hell are we going to do that?”

Jeff: Yeah, it’s really interesting. I’ve actually seen the opposite happen. When the developers are integrated into the ideation or the creation phase with designers the way that Lean UX advocates, I’ve seen developers come up and actually suggest features and suggest fixes and suggest UX enhancements. It’s not for the sake of, “Hey, I want to do it too,” it’s more, “Hey, I started building this idea, and I thought this would be really helpful in here.”

And it’s actually a very empowering conversation to have with a developer, because all of a sudden, you’re talking about the same things and almost in the same terms. They’re familiar with your language, they’re familiar with the toolset, they’re familiar with the users, because they’ve seen the users react to these products, and that has been one of the other most powerful things that I’ve seen come out of this process.

Jared: So a lot of the feedback I get from sort of folks who’ve been doing design for a really long time is that, “well, developers don’t know how to design”, right? ,”And if we let them design, they’re going to produce crappy stuff, that’s why we have designers in the first place come into the scene.”

And the other sort of objectionish-type thing I hear is, “well, if the developers start designing, what do we bring to the table?” When you were implementing this, did you ever see an instance where a designer somehow became suddenly obsolete?

Jeff: Absolutely not. Absolutely not. No, in fact, I’ve seen them only become more and more valuable.

Look, design is very tangible. Everybody feels like they have an opinion on it, they can see it, they like blue, they don’t like yellow, they think the button should be to the right or to the left. Everybody can have that opinion because the interface is so tangible.

But when you start to bring the team into the design process, and you show them everything that goes into that design process, the balancing of user needs, business needs, and brand and usability and mental models and motivations and psychology, they start to recognize the value of the designer, the strengths and everything that goes into creating these.

And so they will suggest things that perhaps they think will make the experience better, but they always have deferred back to the designer to say, “Do you think this makes sense?” or, “Does that work?” In this particular process, when they’ve been involved, they never bypass the designer and say, “OK, we’ve got this. We know how to design. Thanks for telling us how to put the pixels in the right order, we’ll see you later.” I’ve never seen that happen.

Jared: So is what’s happening, the developer maybe brings an idea to the table, and some of that idea actually has potential, but other parts of it, the designer says, “Oh, yeah, I immediately can see flaws in that.”

And now you have a way to have a conversation, I’m thinking, that says we can establish a vocabulary, we can establish an understanding, and I can help you as a developer understand what I know as a designer might work, might not work. Plus we can then create some experiment and see if either of us are correct, and suddenly we’ve got this collaboration thing happening, and we have this sort of shared understanding of what is possible, what works, what doesn’t work, in a way that you wouldn’t get when you’re siloed, right?

Jeff: That’s right. That’s the key, is that it’s not just, “Well, I’m the designer, I know what’s best, so you be quiet and just do what I say.” It’s more along the lines of hey, I’m the designer, you’ve seen everything that I do and what goes into all these decisions, so let me give you my opinion about this particular feature or this particular suggestion. And let’s validate this. It’s easy enough to run an experiment, let’s validate this with customers, or with stakeholders, or whatever the need is, and bring in that extra perspective that then says not only is designer instinct and designer expertise at play here, but there’s actual validation from the market and from the field.

Jared: And another thing that jumps into my mind is that from a distance, and we’ve all run into this, right, design is this color and font aesthetic thing, right? It’s the, “oh, what designers do is they put the nice layer of shininess on top of the wires so that when everybody looks at it, it looks like a real thing.”

But we as designers know that in fact, that’s the least important thing we bring to the table. The most important thing we’re bringing to the table is what is the right flow, are we asking the right questions, is the language on the screen the right screen? From a visual design standpoint, it’s not even aesthetics as much as it is prioritization of information, you know, is the most important thing jumping off the screen while the least important things are just whispering at the user at the moment they need it?

When you have the designers, the developers, and the business owners all in the same room sort of working on this collaboratively, suddenly all that subtly and nuance as to what design is about, that surfaces doesn’t it? I mean that stuff becomes transparent.

Jeff: Absolutely. That’s exactly what I was getting at. The value of the designer becomes even more evident when the collaboration is working at the highest levels. The expertise and the different disciplines that all go into software design and user experience design start to emerge and become very obvious to the team.

There is a much more… I don’t want to say legitimate, but it’s a conversation where it’s no longer us versus them. It’s more, “Well, these are the competencies that I bring to the team. Just because my title says ‘designer’ I actually bring in these different competencies.”

There is a recognition among the team that those competencies add value and that they justify opinions and suggestions through that expertise.

The conversation becomes much, much different and much more productive and less combative. Like I said, it’s much less of a negotiation than a conversation around what’s the best thing for the user and the business during this particular transaction?

Jared: OK, so I like this idea. I mean, I can imagine this scenario happening, right? A problem manifests itself. I’m the designer. You’re the developer. We both go off and take our own stabs really quick over a matter of minutes at what we think the solutions are.

You as the developer bring a solution to the table that’s pretty good, but I bring in a solution from my experience in having dealt with these sorts of things before that takes it to a level that’s beyond what the developer is seeing.

Suddenly as a developer you say, “Wow! I see where you got to, and I see how much better it is. I see how you got there, but in a million years I wouldn’t have been able to do that.”

I took a cooking class a few months ago, and I know how to cook. I love cooking, and I spend a lot of time in the kitchen. But this person could do things that I never even imagined one could do in the kitchen. He could slice onions faster than me in a way that I’ve never been able to do and things like that, and just to combine ingredients.

I was like, “Wow!” I was really impressed at that level of brilliance that, of course, I wouldn’t see if I just tasted the final meal. It’s a level of… You’re right. It’s some sort of collaborative transparency that doesn’t have a real good word for it. But it’s an appreciation.

Jeff: It is, and the more you have that and the closer you work with your teammates and the more these siloed walls erode, that transparency builds trust. And with that trust comes an even greater acceptance of the other team members’ competencies and the values that they bring in. So again, the same thing holds true for developers as well.

Jared: Yeah, I was thinking that. I was thinking it goes the other way.

Jeff: Just because their title is “developer” it doesn’t mean that they actually don’t have any design sense or that they don’t have any business sense. It just happens to be the field that they’ve chosen, but we should be open to hearing all of those opinions from the team as you get to know them and as you begin to trust them.

Jared: Oh, that’s interesting because I can see that. But I was thinking that as a designer I could learn a lot about development. I could learn more about what’s technically possible.

Like if we’re moving to a mobile platform, and this is one of my first times working in mobile but you had a lot of experience working in mobile, suddenly I could learn a whole bunch of things about that environment that I wouldn’t have known before and what is possible, what isn’t possible, what’s easy, and what’s hard.

Suddenly, I’d be learning sitting next to you in a way that I wouldn’t get if I just saw your final product at the end without seeing the process.

Jeff: Absolutely. I mean that’s another huge benefit of this transparency. As you’re sitting there with the designer and I advocate for designer developer pairing on projects so that you’re both learning each other’s crafts right away from each other. Obviously, at the end of that particular process you actually have a product as opposed to a document describing a product.

But as you’re doing that you’re learning things like the challenges of rounded corners and drop shadows [laughs] and et cetera and everything else that goes into building applications. That informs the design process moving forward. So it’s absolutely a very symbiotic relationship there.

Jared: Right, right. I remember when I first started doing design work, one of the things that I had to learn was that some dialogue boxes populate very fast, and others, because of the way the underlying database architecture works, you can’t populate quickly at all because you have to go off and look at every record and there are millions of records.

Whereas some, maybe you have some keys or shortcuts that let you get to that data really fast and sort of cache. It wasn’t until we started to build it that I could start to tell which types of queries were going to be fast and which ones were slow. I would be very bad at predicting that.

And of course, that speed thing is essential to good design, yet it doesn’t show up in wireframes. It doesn’t show up in most of the design deliverables that traditional UX design has. Then you end up with very sluggish systems when you don’t want them to be.

Jeff: Yeah, it’s easy to forget, but it’s critical to remember that the user experience of the product is not only the pixels, the workflows, the words, and the transactions. But it’s the systems underneath it that, to your point, make it snappy, make it responsive, make the transitions interesting, make things flip, make things turn [laughs] over, et cetera.

All of those things make up a portion of the user experience, and without a true understanding of our partners in development as to how those things happen, we still create these artificial confrontations. Unnecessary confrontations.

Jared: Yeah, and I wonder if you’ve ever had this experience, which I had a few months ago, where we were talking about a design idea. The immediate developer’s reaction was, “Yeah, we can’t do that. We can’t do that.” Then he had what I call a “shower moment,” where he came in the next morning.

He says, “You know, I was thinking in the shower this morning, and I came up with a way to do this.” Sure enough he’d solved the problem. Sometimes you need that away time to think about it but then come back and go, “Oh, OK. That’s how we do it.”

Jeff: The key is to build those relationships in your team to inspire those shower moments and to make your teammates care about the experience and the customer as much as you do so that when they are not at work they’re thinking about how to solve these problems.

Jared: Now that I hear you say it, I’m thinking we need a new term for “shower moment.”

Jeff: [laughs]

Jared: Something about that just is on the verge of creepiness. We’ll have to come up with another way to do it.

[laughter]

Jared: OK, so now the last thing I want to talk about here. So you mentioned how other teams in the organization think about all this, and it reminded me of something that one of our clients is doing. So we have a client that’s got dozens and dozens of Agile Scrum teams throughout their organization, and this is all new for them, right? So they’re all moving to Agile. It’s all a new first time thing.

I want to point out here that you and I have talked about how Lean UX isn’t specific to Agile. But if you’re in an Agile environment, man, it can really help. So these guys are looking at this. So they’ve been looking at doing Lean UX-like stuff. They’re going out and taking their developers, their business owners, and their whole Scrum team out to visit customers and they’re doing all this stuff.

But they’re not doing it across the organization all at once. They’re doing it one or two teams at a time. Like I said, they have dozens, right?

So this is going to take a long time for them. So the way they did it was they got a couple of teams that were really feeling the pain of not having a good process and not producing and not shipping and all of this craziness.

They found a couple teams that were really feeling that pain, and they said, “Hey. We’ve got this new experimental process. We want to do this just with you.” They said, “OK, let’s try it.” They went off and then they did it. Within weeks you could start to see the progress. I mean, you could see them sketching and working together and creating this UX stuff.

Other teams started to notice, so they said, “OK. We want to do this.” Here’s the crazy thing. The folks behind this, the people who were driving it, said, “Uh, no.”

Jeff: [laughs]

Jared: “It takes a lot of energy. We can only train a few teams at a time, so of the 10 or 20 teams that are really interested in this now, we’re only going to pick two. So we’re going to come up with a little contest, and you guys have to actually prove that you are worthy of learning this technique.”

Jeff: Wow.

Jared: OK? Man, did that make everyone nuts to have it! [laughs]

Jeff: Wow, that’s really interesting, to keep a process away! I’ve never heard teams clamoring, [laughs] competing to use a particular process. That’s fantastic I guess. [laughs]

Jared: Right. So once they finally got it, they were in this mindset not of, “Oh, my God! We have another process we have to learn. Oh, this is going to be awful.” They were like, “Finally we were picked!”

[laughter]

Jared: “We’re going to get to do this”, right? “And then we will be one of the ones who know it, and everybody else won’t be.” It magnified that sort of envy thing you were talking about earlier.

Jeff: Yeah, that’s amazing, and especially with so many teams to drive them to want to do that because I can imagine with an organization that large it’s difficult to see if one or two teams are doing this, they could hear about it. They may not interact with that team on a regular basis, so this is a good way to drive demand for that type of collaboration through an organization. That’s really interesting.

Jared: Well, one of the other things that really appealed to me about it is it signaled that we understand that not all teams are ready for this, right? Maybe the work you’re working on can’t be disrupted even by a moment because it would slow you down from an already critical path thing, and management is staring over you. Or maybe you’re not feeling the pain of whatever problems this new thing solves is.

It’s that open acknowledgment. But at the same time it also says, “Look. We have limited resources to roll this thing out, and we’re going to do it right. We’re not going to rush it and then screw it up and then not do it well across the organization.”

I could see that happening that if you tried to do too much at once with too many teams, nobody does it well. Then people blame it and say, “See? I didn’t work.”

Jeff: Yeah, especially if it’s a big organization with dozens of teams. You can’t coach the entire organization all at once and try to be successful. It’s just too much to the point they are doing it is focused on one or two teams, make sure they’re nailing it, and then move on to the next two teams and the next two teams and the next two teams.

My guess is that, as you go through the organization, the actual amount of coaching that you have to do becomes less and less, becomes a much more prevalent approach to doing work in that organization.

Jared: Yeah, and here’s another thing they were doing that was really cool. They were taking key members from other teams that were not on critical path, and they were basically putting them into the teams they were training. So when they were training a team, it was the original team’s members plus two or three other people who were not from that team but from other teams that would be there in the future.

Those people were like the foreign exchange thing. They were the kids from Germany. They were coming in, and they were participating in this as if they were team members for the duration of the project. Then they went back to their teams. Now, when they go back to their teams, they look at their processes and say, “You know, there are ways we can do this.”

Even though that team hasn’t been completely trained or learned how to do this, these guys are bringing that message back. And they’re cross-pollinating through the organization, and that seemed to really help a lot, too.

Jeff: Yeah, we actually attempted that at TheLadders where we would bring in folks from other teams onto the Lean UX teams and have them sit through our standup meetings and go through a project or two with us. They got a sense of it, and that helped at least plant the seed of the Lean UX process.

Then when they went back to their teams, they could at least start softening the beachhead a little bit for when we got over to that team to try to actually coach them explicitly on that. So they laid the foundation for the transition, and we did find that to be very helpful.

Jared: Cool. Yeah, this is all very exciting. I really am very excited about Lean UX in general, and I’m very excited to see your workshop coming up. So this has been really fun. Thanks for taking this time out of your day to talk to me about this.

Jeff: My pleasure, Jared. It’s been a lot of fun for me as well.

Jared: Cool. So everybody, if you are really working to get better designs out the door to actually ship them and to really make a difference, you want to find out what this Lean UX thing is all about. You’ll have a chance to do that at the UX Immersion Conference that’s going to be in Portland April 23 through 25.

Jeff Gothelf here is going to be speaking. He’s going to do a full-day workshop on this Lean UX stuff. You’ll work your way through an entire project and get a chance to experience it. Jeff, thanks for spending the time with us.

Jeff: Thanks for having me again, Jared. It’s been great.

Jared: And everybody else, thank you very much for encouraging our behavior. Hopefully we’ll see you in Portland. If not, see you on the next SpoolCast. Thank you very much.

During the podcast, Jared references a previous podcast he recorded with Jeff. You can listen to that podcast on our blog.

Don’t miss out on the newest, most critical thinking around two separate and important UX topics: mobile design and the Agile process.

You’ll pick from 6 different all-day workshops for April 23 and April 25. On April 24, you’ll attend a day of featured talks.

Agile Workshops

• 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 Workshops

• 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

Discover the UX Immersion Conference at UXIM.co.

In today’s UIEtips, Jeff Gothelf compares the lessons that the Karate Kid experiences to how you adapt Agile into UX. I think you’ll find this comparion interesting and enlightening.

Read the article, What The Karate Kid Can Teach Us About Agile and UX.

We know switching to an Agile process is challenging. That’s why we decided to concentrate half the UX Immersion conference around Agile. This first-time event features three full-day workshops by experts Hugh Beyer, Jeff Gothelf, and David McFarland, who will deliver in-depth training to get us ready to handle whatever Agile wants to throw at us. There are still a few special price seats available. Learn more at UXIM.co

There’s a belief that user experience insight is lacking in Agile development. Trying to shoehorn UX practices into an Agile process results in a lot of frustration. Often, developers build stuff faster than the designers can design it. The whole process often focuses on the delivery more than the quality of the experience.

Anders Ramsay believes that UX and Agile can coexist. In his virtual seminar, Designing with Agile, Anders shared examples and techniques of how to apply Agile thinking to UX design. He says that you have to step back from specific Agile methods, such as Scrum and XP, and really look at the underlying ideas. Anders didn’t have time to answer all of the questions from our audience during the seminar, so he joins Adam Churchill to tackle the remaining ones in this podcast.

Here’s an excerpt from the podcast.

“…in an Agile approach there’s less of a focus on the up front visioning. You still do it, but you do it just more intensively and getting back to this metaphor of the rapid passing game, what you might do is have a number of very short intensive workshops at the very beginning of your project.

What you’re doing there is very quickly capturing or involving a shared understanding among your team members, but you’re also careful about not trying to create what I call too much imagination overhead. Meaning that you’re starting to generate all these big vision documents or descriptions of this big future project.

Instead, you just do an absolute minimum of that and focus on people having a shared understanding of what they’re imagining the end product to be. Then, there’s much more focus on outcome…”

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

• In an Agile process, how do you leave room for the “big picture”?
• How and when do you include the users?
• How do you run kickoff workshops and who participates?
• What’s the difference between an ideation clearinghouse and a design studio?
• How do you adapt Agile methods to remote teams?
• How do activities like the ideation clearinghouse integrate into Agile development and fit within the sprint schedule?
• Does the user experience interaction designer facilitate these activities?
• If UX is not involved in the pre-work before sprints begin, can you still apply these techniques?

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

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

Full Transcript.

Adam Churchill: Welcome, everyone, to another episode of the Spoolcast.

Anders Ramsay recently kicked off our Next Step Virtual Seminar Series with his presentation titled Designing with Agile. We’re creating this Next Step Series with the help from the folks at Rosenfeld Media. Why? Well, much of the thinking in this seminar comes from Anders’s book, Designing With Agile, Lean User Experience For A Successful Product. That’s being published later this year by Rosenfeld Media.

So, UX design and Agile can be a frustrating experience when teams are more focused on delivery over the quality of the experience. But, the thinking underlying major agile methods such as XP or Scrum can be applied to UX design, too.

In the seminar, Anders showed the audience exactly how. The seminar has been added to UIE’s user experience training library which presently has over 85 recorded seminars from wonderful topic experts just like Anders Ramsay giving you the tips and techniques you need to create great design.

Hello, Anders. Welcome back.

Anders Ramsay: Hey, how’s it going, Adam?

Adam: It’s going very well. For those that weren’t listening during the presentation, can you give those folks an overview?

Anders: Sure. So, one of the things that has been a theme of a lot of UX designers that have been adopting Agile methods is that they’ve been discovering a lot of dysfunction, a lot of frustration as part of their adoption process.

So, for example, one of the common frustrations that they find is they get stuck trying to deliver all these features for a group of developers who are just building stuff faster than they’re able to design it. That, really, is just an example of a dysfunctional dynamic between the user experience designer and the rest of the development team. It just really isn’t a healthy way of working.

The source of that really is based on you look at the origin of Agile and the way that Agile methods were designed. They were really designed in a different world where it was a much more task oriented world, enterprise oriented world, and where, quite frankly, user experience really was not front and center.

So, these methods don’t really have the UX practice in mind. So, when you try to kind of wedge user experience design into, for example, what I would call kind of a classic kind of Scrum approach, even though I want to be clear Scrum is not about a specific process but it is a framework for a way of working and it is, as such, very delivery oriented. So, it doesn’t really have a lot of explicit places for where UX will fit in. So therefore, you get a lot of frustration for a UX designer who is trying to fit their practice into this.

So, in my talk what we discussed was how to step back from the specific methods like Scrum and XP and look at the underlying thinking that became the basis for Scrum. So, Scrum specifically was based on the idea of thinking of software as a kind of a rugby game and this quick intensive passing game.

If you’re able to do that or really understand what that means, and we discuss that in some detail in our webinar, then that provides you with a lot of tools that you can use. So, we went through a number of specific tools, collaborative chartering, ideation clearinghouse, a more healthy UX oriented way of using stories, and a number of other methods in this webinar and I guess that’s an overview and that will allow UX designers to be more effective in integrating how they work.

Adam: Excellent. Well, let’s get to some of these questions.

Robert and some other folks asked about Agile and how it sort of fits into the big picture. Agile seems so focused on cranking things out. How do you leave space for the big picture?

Anders: So, in an Agile approach there’s less of a focus on the up front visioning. You still do it, but you do it just more intensively and using sort of, getting back to this metaphor of the rapid passing game, so what you might do is have a number of very short intensive workshops at the very beginning of your project.

What you’re doing there is very quickly capturing or involving a shared understanding among your team members but you’re also careful about not trying to create what I call too much imagination overhead, meaning that you’re starting to generate all these big vision documents or descriptions of this big future project.

Instead, you just do an absolute minimum of that and focus really on just people having a shared understanding of what they’re imagining the end product to be. Then, there’s much more focus on outcome.

So instead of visioning up front, we have a minimum vision, then we start to build something and then we compare that to that minimal vision we built, and we work in these intensive cycles. It’s much more outcome-oriented, goal-oriented looking at the result of what we thought we were designing and how it compares to what we think we’re designing. That makes for a much more integrated way of working.

Some examples of these visioning activities is the ideation clearinghouse which we talked about in the webinar as well as other methods like product box, elevator pitch workshops, and so forth which are other methods that have been developed specifically for this purpose.

Adam: A number of folks wanted to know how and when you include the users.

Anders: This is kind of interrelated, similar to visioning. We do do some user research upfront but rather than have this user research phase it’s more of something that’s more of a continuous part of the design. It’s based on an understanding that you can’t really understand your users, you can only understand them to a degree, and users aren’t really going to be able to tell you what they want or what they don’t want or what really is the feature that they’re looking for.

You really need to just do a minimum of that work and then actually start to build something that they can respond to. This is a little bit taking a page from the lean start-up movement in which we establish some kind of hypothesis about the users and the establishment of that hypothesis might be based on some user research but we also might just pull it out of thin air. We have a business idea or something.

Then we devise some form of an experiment. That experiment may involve, certainly, going out and talking to users initially and the experiment may simply be a conversation. Then it gets increasingly higher fidelity so it goes from that to maybe presenting them with a paper prototype and then we start to show them a real prototype in increasingly higher fidelity and obviously want to be able to move as quickly as possible to working in an actual product.

This, again, similar to the big picture, it’s more outcome-oriented and less reliant on a large amount of upfront, intensive research before we actually start building. The big shift really is you can look at it two ways. You can either look at it as reducing your user research phase or moving development into your research phase. It’s just a question of there’s more overlap that happens there.

Adam: Tell us about how you run your kick-off style workshops and who’s typically participating in those?

Anders: The kick-off workshops in terms of when, obviously you want to run them during a project kick-off, as soon as the project begins, but it’s also something that that style of workshop, which we discuss in the webinar in more detail, is something that you probably want to run something similar on a regular recurring basis. For example, in preparation for a new release, possibly in preparation for a new sprint.

Certainly if the business has in any way pivoted, again to borrow a lean start-up term. Pivoted means simply that they have, based on some kind of finding, either from feedback from customers or what the case may be, they’ve found their initial business hypothesis to not be valid and have made some change, a fundamental change in their direction. Therefore, we probably need to revisit our vision because the purpose of this kick-off workshop is to establish a shared understanding across the team members as well as debugging any differences in understanding.

For example, maybe the business has this one idea about what the product will be and then developers are able to debug that and say, “Well, that’s cool, but this one thing that you’re planning on doing we don’t think that’s technically feasible,” whatever the case may be.

But they may also be more ad hoc so it’s not so much a kick-off style workshop, it’s just workshops in general. You have a continuous cadence or just a recurring set of periods where you are doing workshops, intensive group collaboration, as part of how you design, especially in preparation for each sprint but then during the sprint you might do some kind of ad hoc workshop as well.

Adam: So you brought up this idea of the ideation clearinghouse. Can you tell us the difference? What’s the difference between an ideation clearinghouse and a design studio?

Anders: An ideation clearinghouse is just a variation of a design studio. A design studio is becoming an increasingly more broadly practiced methodology, sort of a structured, highly collaborative sketching that tends to be more convergent. As a team you’re iterating and converging on a single solution that then will become the basis of design for let’s say a sprint or something.

An ideation clearinghouse is almost the opposite. You want to capture what is the full range of ideas that are out there among our stakeholders and that’s particularly of interest when you are at the beginning of the project and you are just meeting with the business sponsors. It’s incredibly valuable to understand what, for example, the CEO and the CFO and the CTO or all the other executive sponsors of the project, what they are imagining the end product to look like at that point.

Because I can guarantee you that whatever you present to them, may be one month or two months down the road, sometimes they may disappear from the project, they will be evaluating that based on this imaginary idea that they have of the project. That imaginary idea may not make any sense, it may not be good design. It doesn’t matter. What matters is that you have to understand it and be aware of it. That’s the purpose of an ideation clearinghouse.

It’s just research. It’s an example really of user research but more at the sponsorship level and it’s done very intensively sort of in the spirit of a design studio workshop model.

Adam: There were a number of questions about remote or distributed teams. And reality is, that’s what a lot of design teams are facing these days, that their multiple people working collaboratively are in multiple locations. How do they adapt these methods for their remote teams?

Anders: One thing that’s really important to understand here is that if you are working with a remote or distributed team then you are effectivley… Whoever structured your project is either one of two possibilities. Either the project foundation is based on a very deep rooted, Industrial Age mindset basically saying that people on a team are sort of these interchangeable widgets and all you need to do is go and find the cheapest widget and it doesn’t matter where they’re located. You know, “Oh, we have cheap widgets in some offshore location.”

It’s very important to be mindful that when you build a house on a bad foundation no matter how good work you may do that there’s a fundamental problem there. But that said, there’s still ways that you can work within that kind of flawed framework. One way is just to be Agile wherever you are so each team, wherever they’re located, is practicing good Agile methods. They have a really open, accessible team room with open documents and they share information maybe in an Agile way.

One technique that has been used quite widely, especially for teams in different time zones, is the team in one time zone let’s say they do a three hour whiteboarding session. At the end of the three hour whiteboarding session somebody holds up a video camera and somebody in that room does a five minute summary in front of the whiteboard of that entire session and then they share that video and that becomes this distillation of everything that was said.

But of course what’s lost there is the back and forth between the team members but it’s much better than nothing. Other things you can do is strategic co-location. For example, try to have some kind of co-location at the beginning of the project or at whatever point you begin the project try to find a way to get into the budget to bring up this one team member in one direction or another.

You can do what I call sort of a team member exchange program. For example, early on you can have a UX designer or front end developer from the offshore team be co-located and then as you move into development the UX designer basically becomes the specification document and basically travels to the offshore location for a period. You know, these are things that cost money but it’s one way to address it.

In my opinion, the only way to be successful if you’re remote or distributed is this sort of heroic vigilance and highly, highly adept skilled and experienced team members. That is why, for example, 37signals or somebody like them at that level of skill, they’re able to work being distributed because they’re all very senior and they’re very, very skilled at what they do and that allows you to overcome that.

Adam: Adam and Gabby both ask questions in regards to how these activities actually integrate into agile development and how do they fit in with the sprint schedule?

Anders: So the question itself, how do these activities integrate in, it’s a little bit like if you have a musician in a band asking, you know, let’s say the bass player asks the guitar player, “So at what part of the song do I play bass and what part of the song do you play guitar?” That obviously would be sort of absurd. The guitar player’s like, “We both play the song but sometimes I’m playing, sometimes you’re playing, sometimes we’re playing at the same time.”

It’s the same thing with this integration. To use a development term, it’s equivalent to the concept of continuous integration. You are working, basically, in continuous cycles of a back and forth passing game. Now initially, the ball may be more in the UX designer’s court and as we move to development the ball may be more in the developer’s court but there is not this idea of, for example, do you do activities at the beginning of a sprint or sort of a point in time when you do them.

You can just talk about there’s maybe a greater intensity of UX early on and a greater intensity of development as you move into sprints but it still is a continual back and forth. The specifics of that, those are things that I talk about, specific examples of how you do that. Those are the kind of things I talk about in the webinar such as cross-functional pairing, design studio and so forth. There are patterns but in general it’s a continuous back and forth passing game.

Adam: There are some questions about the designer as facilitator. Randy wants to know who facilitates these activities? Is it the user experience interaction designer?

Anders: It may be and it certainly should be for certain parts. This is, in my opinion, a key shift in skillset from maybe a traditional UX designer who is maybe more focused in terms of being really strong at creating clear, crisp documents and giving good presentations and being able to do really good user interviews and so forth. Those things aren’t necessarily less important but there’s an increased emphasis on being able to collaborate either individually one-on-one at a pairing level or at a team or group level as a facilitator.

Now in terms of who should be doing this, in my opinion it actually should be encouraged for all team members to, at some point, be the facilitator because whoever is facilitating is required to really have an understanding of the project. So you should certainly encourage, for example, developers to take over and maybe conduct a design studio session or whatever the case may be.

I would recommend that you try to democratize that and not have too much of an expectation that it’s always going to be the UX designer. Everybody on the team, ideally, should feel comfortable facilitating. And depending on what you’re doing you might have a different person doing it.

I also wanted to touch on another thing that somebody else asked about if this only is something that would work if you’re an outside consultant and it’s just too much of a culture shift for in-house UX folks. I would just firmly reject that notion. That basically seems to imply that if you’re in the organization where you’re working in a traditional way then that’s it, it’s over and you can’t then do anything about it.

What you really need to do there, it’s a combination of a top down and bottom up shift that you will have to work through. Keep in mind that Agile is, to quote the opening sentence I think it’s in “Extreme Programming”, I’m not sure, but Agile is about social change. It’s very fundamental. You are changing the culture of the organization but you can certainly do that from within and the way you do it from within is two simultaneous tracks.

One is you find a group of energetic, motivated people who really want to make a change and are interested in forming a team, sort of a pilot team, within the company to do this. Then you find an executive sponsor who can give this team the safety that they need to be able to work in a way that may not be conventional within the organization.

An example of that is let’s say in this company everybody normally submits a weekly progress report or has to create all these documents or people need to be resourced and allocated in a certain way. You would find an executive sponsor that allows you to work in a little bit of a bubble and to work in this culturally different way.

Then if you are able to be successful, which hopefully you’ll be able to be if you really are motivated and energized and really pursue this. Possibly you may also want to have a coach that helps you to get the ball rolling. But nothing breeds success like success or nothing succeeds like success I should say. If others in the company see this team as a living testimonial to this different way of working that can be the spark for generating the momentum within the company and how to make change.

I’d also recommend that you check out Mike Cohn, his book “Succeeding With Agile”. He talks about this in depth on how to enable or realize this type of social change. Certainly, it is, to get back to this question, designer as facilitator or if it’s something that you can only do from within I just absolutely reject it. It is certainly something that is intended for companies to undergo but it is the transformation. It is social and cultural transformation.

Adam: The fine folks at Deloitte have a question. If user experience is not involved in the pre-work before the sprints begin can you still apply these techniques?

Anders: Absolutely. You need to conduct them when UX does come on board. So the good news is, it’s not that challenging to make the case for it because these are very rapid, intensive methods but if you come on board and it’s clear that there has not been kind of a shared understanding across the team members of what the project vision is, team members do not feel like there’s a clear sense of collaboration and they’re just separated people doing the relay race, you can certainly just do it whenever you join the team.

I’ve done it on several projects where I came on board, it was clear this due diligence work had not been done, and we just did a kick-off at that time. We maybe didn’t call it a kick-off. You can frame it and couch it in a way that will be politically expedient but still do the actual activities. Absolutely.

I’m sorry, in terms of how you might modify them that’s really hard to say. That’s going to be tied to the specific situation. So I would recommend, that’s really going to be a judgment call for this particular illustration actually.

Adam: All right, Anders, that was fantastic, as was your virtual seminar, so thanks for circling back with us.

Anders: Fantastic. Thank you.

Adam: To our listeners, thanks for listening in and for your support of the UIE Virtual Seminar Next Step Series Program. Thanks. Goodbye for now.

Technologies are often misunderstood at their outset. This misunderstanding leads to a lack of adoption. This lack of adoption leads to the technology not reaching its full potential or not being utilized in useful ways. This is essentially what happened to JavaScript. Detractors said it wasn’t a real programming language, and its capabilities were ignored.

Dave McFarland notes that Google’s use of JavaScript in Google Maps makes a lot of people take notice. People began to see what you could do with JavaScript and began exploring. The emergence of JavaScript libraries, such as jQuery, has further expanded the reach, making complex programming tasks much simpler.

Dave is a web developer, author, and teacher. He says that for designers, jumping to the programming side is easy when you have libraries and plugins. JQuery uses a familiar syntax that designers know from CSS. Creating rich, interactive prototypes becomes a reality for designers. Even though the code may not be 100% production-ready, it greatly increases the speed of the whole process. Listen to Jared Spool’s interview with Dave to pick up tips on using jQuery for Agile prototyping.

At UX Immersion 2012, Dave will be presenting a full day workshop on Demystifying jQuery for Agile Prototyping. Find out more about the conference.

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

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

Full Transcript.

Jared Spool: Welcome, everyone. Today on the SpoolCast, I have with me Dave McFarland, who is going to be speaking at our upcoming UX Immersion event, which is going to be in Portland in April, April 23rd through 25th. And Dave is going to be giving a full-day workshop on JavaScript and jQuery for designers. And I got a chance to see Dave present at the WebVisions Conference in Portland.

And if you are thinking that you might want to learn how to program in JavaScript and jQuery so you can be doing prototyping and other great things, this is absolutely a fabulous workshop. He starts at ground zero and just moves right up, and you’re going to love it.

But today we’re going to talk about what it’s like to be programming as a designer, and all those things. And I have with me here Dave McFarland. Hey, Dave.

Dave McFarland: Hi, Jared.

Jared: So, how long have you been using JavaScript and the likes?

Dave: Yes, well, let’s see. I started learning JavaScript I think maybe 13 years ago, no, maybe about 14 years ago, so in the very early days. And I’ve been teaching it for about 11 years. So I’ve pretty much seen the entire evolution of the language from its early incarnations for making little sprites appear all over the screen, or annoying little tickers at the bottom of your status bar, to what we have today with JavaScript and kind of advanced web application functionality that JavaScript provides.

Jared: I’m realizing I don’t really know the background of JavaScript. When did it first show up? Did it live in places other than browsers before?

Dave: Well, it was, you know, introduced by Netscape, I believe in 1995, though I’m not totally sure if that’s true.

Jared: Not too long after Netscape had its browser in the world, so it wasn’t there for the first versions, but it did appear pretty soon after that, then.

Dave: Yes, and initially it was called LiveScript. And apparently the legend behind all this is that somebody in marketing talked to somebody at Sun Microsystems, who were pushing their Java programming language, and that was seen as the next great thing that was going to revolutionize computing. And they said, wow, that Java has a lot of buzz behind it, so maybe we should ride its coattails. And somehow they made some sort of agreement with Sun to sort of use the name, so JavaScript was named after Java, even though in reality it’s not based on Java.

There are many differences between the languages, so it’s not really Java. So it’s caused endless confusion, especially for my students. That’s one thing I teach immediately, like the first day of a JavaScript programming class, is that JavaScript is not Java. So when they have their job interview, don’t accidentally say they’re Java programmers, because not only will they confuse their employer, but they might end up having to do some programming that they don’t know what it is [laughs] .

Jared: Right, yeah. So, is the JavaScript of today remarkably different than those first versions?

Dave: Yeah, certainly. I mean, there’s been kind of a convergence of things that have happened to make JavaScript now really one of the premiere programming languages. Not just on the web, but really as something worth learning, even just as a technical thing.

So in the early days, I mean, first off, not every browser had it. So basically Netscape created it, it was an open standard, so it was available to others. And Internet Explorer developed their own variant called Jscript. So we suffered through a lot of browser incompatibilities where JavaScript worked in completely different environments, and so programming it was a bear. You’d basically have to learn all the nuances of the different browsers and then write code that would basically work depending on which browser was looking at your web page.

Jared: Oh, and that never happened with anything other than JavaScript.

Dave: [laughs] Right, yes, never. So that was like a huge thing, and there were fundamental differences in just kind of how you would do basic JavaScript things like events, which is where the browser will react to something that a person does, like clicking or mousing over something. And there were two fundamentally different ways to do it, whether you were programming for IE or for other browsers.

I think another thing that happened is that there was just a lack of an imagination, that people didn’t really know what JavaScript could do. So there were a lot of dinky little things in the early days, sort of cutesy visual things that weren’t really about usability. In fact, if anything probably were negative or negatively impacted the usability of a site. Things like the little sparkles that would trail your cursor as you moved your mouse around.

And so I think people didn’t know what it could do, so they just did a lot of sort of glitzy little things that weren’t very useful. And I think it really took Google to step up with Google Maps for people to see that, wow, JavaScript can do these really amazing things that improve the usability of a site, in fact, are fundamentally important to how the site works.

Google Maps is such an incredible example, because it draws in a lot of different technologies, Ajax being one of them, so that you can get this kind of real, immediate interactive feel where you were just grabbing a map and scrolling across, dragging it across your screen.

And for those who are listening to this who are maybe younger and did not live in the days before that, we had other maps like MapQuest, where basically you would click, and then you would wait, and the screen would refresh, and you’d get a new chunk of a map. And then you would click again, and then you would wait, and the screen would refresh, and it was a very kind of staccato rhythm, not a very fun experience, and not very interactive, and certainly slow. And I think Google Maps really changed people’s perspective on how immediate the user interface for websites could be and how fast they could react to users.

Jared: Yeah, I remember when Google Maps came out, it was all abuzz. And that was really when this idea of being a front-end developer became fashionable, that you would actually be developing code to run on the browser that wouldn’t be running on some server in the background. And it was a different language, and you had different constraints, and you had all these synchronization issues you had to worry about. So that’s about the time when that really became very popular. If you could do that kind of magic that Google Maps did, you were really desirable in the marketplace.

Dave: Yes, and I think another thing that Google did is, it made JavaScript OK for computer scientists. Like, I think there was always a prejudice against JavaScript as not being a real programming language, not having a lot of the things that you’ll find in Java or C++, or other traditional programming languages. So I think there was not a big pool of talent exploring what JavaScript could do, because there was sort of a prejudice that it wasn’t a real language, so people were spending their times with server-side languages and things like that. And I think once Google said, look, we’re Google, we know technology, we’re using JavaScript, people really sort of took notice.

And then I think that’s really been part of the rebirth of JavaScript, is all of these really smart programmers jumping on board with JavaScript and doing really amazing things with it, and, you know, making money [laughs] with their web applications and their programming skills.

Jared: I’m interested sort of in the timeline, because all of a sudden, designers are talking about using JavaScript. I’m meeting more and more designers, there’s this whole discussion that’s going on about designers that can code are more valuable in the marketplace. So this shift from developers using it to do production code to designers using it to do things like prototyping, that’s a recent thing.

Dave: Yeah, yeah. And I mean, that owes a lot to the emergence of JavaScript libraries. Things like Prototype and script.aculo.us, or MooTools, and jQuery, of course. JavaScript library is basically a JavaScript program that simplifies lots of common programming tasks, web programming tasks. In addition, JavaScript libraries fix these cross-browser incompatibilities. So basically, using a library you can program one thing, and it’s going to work in Internet Explorer, and it’ll work in Chrome, and it’ll work in Firefox and Opera, because the library sort of takes into consideration any of these differences that these browsers have.

And because of that, the sort of technical barrier of entry to programming is greatly reduced. I mean, with jQuery you can in just, you know, a couple lines of code do some stuff that’s really amazing that if you didn’t have jQuery you basically would have to write hundreds of lines of code and have a really deep knowledge, not just of JavaScript, but of browser differences.

Jared: So having these tools really simplifies the programming for something like a Prototype. So if I want to mock up, let’s say I wanted to make a message-handling thing, like a Gmail like interface for messages in my application. If I want to mock it up so I have new messages, and composing a message, and sorting the messages and stuff, now that I have these libraries, that becomes much easier to do, right?

Dave: Yeah, yeah. So, jQuery in particular sort of has a mission to make JavaScript programming easier for web designers. So a lot of the ways that you interact with jQuery will be familiar to web designers. For example, a lot of what JavaScript programming is about, especially UI programming is, taking elements on a page and changing them.

Maybe animating them, or hiding them, or showing them for example with a tabbed panel, you’ll have lots of different HTML elements on the page, but only some are visible at one moment, like the one tab that you have selected. You can click on another tab and you’ll see another panel. So basically, you’re hiding and showing HTML elements.

And jQuery uses CSS syntax, or cascading style sheet syntax, for selecting those page elements that you’re going to hide and show. So if you’re a web designer and you know CSS, then jumping into jQuery, there’s all this familiar terrain that you can sort of draw your knowledge. It’ll be familiar to start using it, because it’s talking the language of CSS that you understand.

In addition, it just has these helper functions. Things like Animate, which will animate something on a screen, or make it fade out or fade in, which are really rather complex things to do programmatically. But all that technical difficulty is hidden behind a single function, and one little line of code does this cool stuff. And so it’s really much simpler for designers just to sort of jump on board and start doing pretty amazing things.

Jared: Yes, the folks that I’ve seen who are now rocking the prototype world, really it almost felt like they had this huge fear about it. Like, they were going to put on a blindfold and just jump off into the deep end. And then they got in there, and they’re like, hey, wait a second, this is actually pretty easy. Why do you think there’s all this sort of mysticism about how complicated it is?

Dave: Well, I mean I think it traditionally was complicated. I mean, JavaScript programming was hard. So I think without a library like jQuery, jumping into JavaScript programming is really, really, really complex. When I was approaching my publisher, O’Reilly, to write the first edition of my JavaScript book, you know, they wanted me to write a JavaScript book, and I said, “well, I’ll write one, I love JavaScript. But I’ll tell you, I don’t want to do it unless I bundle in a whole discussion about a library as well.”

And they are like, “why would we do that, you know, JavaScript is the hot thing. We don’t want to pigeonhole it into a single library.” And I said, “well, I could write a 1,000-page JavaScript book — in fact, there are 1,000-page JavaScript books — that by the time somebody was done reading it, they wouldn’t be able to do that much. You know, they would know a lot about different web browsers, and they know a lot about JavaScript. But getting actually down to creating the code for really incredible user interfaces would be another book, because it’s so complex.”

But with a library like jQuery, you can skip so much stuff with JavaScript and jump into doing really powerful visual user interface design. When jQuery was really starting out and getting a lot of traction, there were a lot of JavaScript programmers in the blogosphere who were poo-pooing it, or saying, “yeah, it’s a great place for a beginner to start. And, it’s kind of cool, but it adds all this code, so if you just know JavaScript you’re good.”

Within six months, the majority of those bloggers were changing their tune and essentially saying, you know, jQuery or one of the other competing libraries are so incredibly useful and make development so much faster that even these people who were hardcore JavaScript programmers started using libraries like jQuery because it really just cut their development time by tenfold.

Jared: And so, the things that jQuery does, as I understand it, there’s basic jQuery, and then there’s plugins, right? And the plugins aren’t created by the same people who created jQuery. They’re like open source, people are doing them all the time. Have I got that right?

Dave: Yeah, exactly right. I would say that’s another reason why jQuery has so much traction, is that not only do we have jQuery, which makes programming JavaScript much simpler, but even that can be hard. I mean programming is programming. There’s a lot of stuff conceptually in it that isn’t always easy for a designer to understand–you know, even things like variables. Certainly things like loops can be complex things for a designer to handle. So given that you’ve got jQuery–even that might be a little bit hard.

So the next thing that makes jQuery so enticing is that there are other programmers out there creating these Plugins, which range anywhere from a simple little thing for styling tables to really complex things like tapped panels or a calender widget for selecting dates in a form–for example, like a sign-up form for making reservations. And with these plugins, a designer can really just include the jQuery file, which is a JavaScript file, include the library file, and then add a tiny bit of code and suddenly transform their entire page.

So you’ll see a lot of designers who really don’t even consider themselves JavaScript programmers at all, being able to leverage jQuery, plugins and a tiny bit of code that they’ve learned to build fully functional–either a prototype or a complete website with lots of kind of interactive functionality.

Jared: It seems to be really cool, because once you get a prototype running that sort of represents what you intend to build and you can sit down with your developers, and you could say, “This is what I’d like to see us build,” right? It doesn’t even matter if the code you produce as a designer is production-ready. It’s no different than if you gave them some sort of specification or some hand sketches or something done in Photoshop, from the perspective of the developer, because they’re going to start from scratch with things they need to do for the production-ready environment. But the fact that you can create a prototype that shows what you intend and shows all the interactions–that to me seems really, really powerful.

Dave: Yeah. And I mean, you could develop something that you just sort of hand off and say, “This is exactly what I want.” And they could then, if they felt like the code wasn’t good enough, they could easily optimize it or rewrite it to fit you know, the technical standards of the organization. But, yes, we are definitely moving far beyond the days where, “Here’s my Photoshop files, guys. Why don’t you flip through and see this is the next thing that happens on the page when you interact with it.”

I mean designers can build fully interactive prototypes. And now it’s becoming much more common for designers to not even think of Illustrator or Photoshop as the beginning grounds for web design, but actually just jumping into a text editor and building HTML as the starting point for their designs.

Jared: Yeah, I was talking over the weekend with Nathan Curtis, who’s one of the designers at a firm called EightShapes. Two years ago everything they were doing was resulting in PDFs. They’d create these very ornate PDFs, they love InDesign, and they were creating these very ornate PDFs that described everything in the application. And he taught himself very quickly JavaScript and HTML and CSS.

And now he says he lives in TextMate all day and he produces code. And they get ideas done five times as fast. The developers love it because they can go in and they can look at what he did and they know the dimensions of things and they see the interactions of things. Even if they have to convert the code for their own environment, they’re able to pick that up really fast.

I was with a team and we were doing sketches, and then we went home for the day. We came in the next day, and one of the guys had worked for a couple hours and he actually had a rough working version of what we had sketched out. I asked him how long he’d spent on it, and he said, “It was only about an hour, because everything we were doing was already ready-made in terms of plugins and base functionality.” I said, “Have you been doing this for a long time?” He says, “No, I just picked it up a few weeks ago. I just got into jQuery for the first time. I’ve never written any programs before in my life. It’s just so easy.” Do you think that’s typical or is that unusual?

Dave: Oh no, I hear that all the time. It’s incredibly empowering for technically inclined designers to jump over that hurdle where they feel like they can’t program to being able to do really, really amazing things. I see a lot of people sort of say, “Oh, these plugins, what a handicap they are. Basically you’re not learning the underlying technology.” I see all of these kind of enabling technologies as really a starting point for real programming. I see a lot of people who sort of–they get into jQuery. They start using the plugins. They’re learning more and more about JavaScript and jQuery, and at a certain point they become dissatisfied with what plugins can do, because they now grok the entire JavaScript world.

They start programming their own. They start making their own plugins. Or they’ll take a plugin and they’ll rewrite it. I think this sort of entry level enabling technologies are amazing. They help generate a new breed of programmer that we wouldn’t normally have, because the barrier to entry was so high in the past, and now it’s so low that people can get really jazzed and they start to ramp up their own skill set in a way that’s really comfortable for them. They become better and better programmers.

Jared: Yeah, I mean this makes perfect sense to me. Do you have a Trader Joe’s near you?

Dave: Oh, yeah.

Jared: We have them here and one of the things that I’ve recently learned is that you can do amazing things with Trader Joe’s stuff, right. One of the first recipes I learned involved taking their tapenade, which is this mixture–I don’t make tapenade. It’s got…

Dave: Olives, right?

Jared: Sometimes it’s olives, vegetables, and–I don’t know. It’s just this sort of relish, I guess, is what you would think of it as. You take a jar of that and you put it in pasta and chicken, and all of a sudden you’ve got this amazing dish. It’s a restaurant-quality dish. And the thing was, when you were talking about plugins for jQuery, I was thinking of the same thing. I actually don’t know how to make tapenade, but I can actually delight my family with this amazing dish that I throw together after work in about 10 minutes for no effort. And they’re like, “Oh, my gosh, this is awesome.” And I’m like, “Yeah, I emptied a jar of tapenade…”

[laughter]

Jared: “…whatever that is.” That’s like programming with plugins. I don’t know how the plugin works, but it does everything I need it to do, so who cares?

Dave: Right, right yeah.

Jared: Frankly, I don’t know how the processor moves bits around but I can get it to do my email. So you know, I don’t seem to be handicapped because I don’t actually know how that’s working.

Dave: Yes. I don’t know if you saw this article on the Inc website for Inc.Magazine. I think it was January 2. They had an article, “The Value of the Designer Who Codes.” It’s about having designers who know how to code, or engineers who are designers as well. They talk about Quora, a social answer network. A lot of the people there are designers and engineers, and they don’t use Photoshop. They use text editors to code and design, and since they’re all sort of into the technology, they can all talk. They’re all on the same page.

You don’t have that same kind of communication divide that often happens between a design team and an engineering team when you’re so separated by your disciplines. And I think that’s another really neat thing about people who learn jQuery, learn JavaScript. Even if they don’t go the full distance to become masters of that and programmers, once they understand it, they can talk it. They can talk to engineers, and they can talk to technical people. And the ability to sort of have a dialog around UI stuff, especially the technical parts of implementing UI stuff, it really helps the whole process of building web applications.

Jared: I’m hearing from our clients–and you can tell me if you hear this–is that when you have some organizations that have sort of not been very sophisticated on the front end because the designers don’t know how to code and the back end folk haven’t done that much with front end development. So they tend to have like that old MapQuest interface, where you click and you wait and you click and you wait.

And then a designer starts to do stuff with just some prototypes in jQuery, and they whip it up really fast. That actually sometimes motivates those back end guys to actually say, “OK, if this guy can do it we should be able to do it.” And then suddenly the whole–you know what they say, a rising tide raises all boats. Everybody has suddenly got more front end skills, and they’re realizing that this isn’t as complicated as we thought it would be.

Dave: Yeah, no, I think that’s an excellent point, because I think we talk about maybe designers feeling intimidated about programming. I think there are back end people who are intimidated or at least don’t understand the front end experience. They don’t understand the interactive experience. Things like PHP is not an event-driven programming language. It’s not about somebody clicking on something, or moving their mouse, or interacting with different page element.

So there’s a really different mindset in those types of programming. I think as server side people get more introduced to jQuery and to plugins, for them that demystifies the front end programming experience. You’re bringing in more talent. You’re bringing in these back end programmers, who are now like, “Wow, I get it. I can do this.” And they learn JavaScript, and they start doing really cool stuff as well.

Jared: Yes, I think that there’s a lot of interesting stuff that’s happening here, and I’m really excited about it. You and I were talking last week about the workshop that you’re going to be doing at the UX Immersion Conference. I was surprised at how much you’re packing into this day, where basically people who just know a bit of HTML, and CSS and a little bit about how the DOM works and stuff–they can go from just that knowledge to doing all these cool things in JavaScript and jQuery because it is really that straightforward.

Dave: Yeah, yeah, no, I mean at the end of the day, people can start adding all sorts of interesting user interface elements. The ubiquitous slider that we now see on home pages, where you’ve got some picture and content, and then it — zoom — slides away. There’s another picture, more content, and you can click and dive deeper into the site. That’s like all over the place. And with jQuery, there’s a variety of plugins to help with that. And in my workshop, I’ll show one of them. Really with some very simple HTML and this plugin, you can put that pretty jazzy effect right on your home page in a matter of minutes.

Jared: That’s just amazing to me. It’s great. I mean once we get prototypes so effective it really does give us a way to talk about our designs. There’s an old saying which is talking about design is like doing interpretive dance about jazz.

Dave: [laughs] Right.

Jared: And having a design that you can actually play with, that you click on things, you can see what it does next, and you can sit down next to your developer and you can say, “OK, this is what I want to have happen.” They can take the mouse and they click on it and they can see what it does next, and they go, “Got it.” That’s got to speed things up by light years.

Dave: Yeah.

Jared: Though I guess light years is a distance.

Dave: Yeah. So maybe not light years but light…

Jared: Light something.

Dave: …something.

Jared: Yes. Some unit of speed.

Dave: Yeah. Programming person-hours.

Jared: Yes. [laughs]

Dave: And I think one of the things is when you can rapidly build an interface, you can test that interface and innovate. And I think what we’re probably going to see is because of things like jQuery, where we can rapidly throw up an interface, we can test it, we can view it and we can imagine the next step, we’re going to see a lot of really interesting evolution of user interface design and usability patterns that’ll come out of the ease of use of a lot of these JavaScript libraries.

Jared: Yeah, I’m really looking forward to it. And I’m looking forward to your workshop. I want to come out being a Ninja JavaScript coder.

Dave: All right. I will do my best to allow you to be a Ninja.

Jared: OK. Awesome. David, thank you very much.

Dave: All right. Thanks, Jared.

Jared: If you guys are as fascinated by this as I am, then you’re going to want to join David in his full day workshop at the UX Immersion Conference. It’s going to be in Portland April 23rd through 25th. You can find more details about that by tootling around our website at uie.com. There will be a link to the conference there. And once again, as always, I want to thank you all for encouraging our behavior, and we’ll talk to you next time. Take care.

At first, Agile can feel like a battlefield. It challenges everything we know about how to do a great job of building fabulous designs. And yes, there’s a lot that we need to consider and adjust in how we go about our business. Some might even say one step forward and three steps backwards, as we have to find our place inside the development process all over again.

Yet the move to Agile is quite a gift for UX professionals. Designers love to work inside tight constraints and Agile provides plenty of them. Those constraints mean we can redesign our design process, from the top, in a way that is best suited for this new world. That’s pretty exciting.

In today’s UIEtips, I explore some of this year’s oncoming challenges and emerging opportunities that we’re seeing when integrating a UX process inside Agile development. I think you’ll agree that there’s a lot of exciting opportunities ahead, along with some challenges we can really sink our teeth into.

Read the article: UX and Agile Development: 2012′s Challenges and Opportunities

It was directly with these challenges and opportunities in mind that we designed our 2012 UX Immersion Conference. This first-time event features three full-day workshops by experts Hugh Beyer, Jeff Gothelf, and David McFarland, who will deliver in-depth training to get us ready to handle whatever Agile wants to throw at us. There are still a few special price seats available. Learn more at about UX Immersion 2012.

You’ll walk away knowing how to package your project prototypes, then tailor conversations to be of and around the experiences rather than walking through a document. And with the registration comes both EightShapes’ CSS & JavaScript library and a sample HTML prototype that demonstrates all the concepts covered.

You’ll learn to:

• Build HTML prototypes and organize them systematically
• Break designs into small, reusable components
• Use an HTML prototype to communicate an entire experience
• Annotate and collaborate using basic markup

If you’re an enthusiastic proponent of efficient and responsive design, then register now. Because you’ll achieve both more quickly with Nathan’s guidance.

These special online seminars are created in cooperation with our friends at EightShapes.

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

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

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

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

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

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

Full Transcript.

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

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

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

Hi, Rachel!

Rachel Hinman: Hello!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Rachel: Yes.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[laughter]

Rachel: I’d say.

[laughter]

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

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

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

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

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

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

Rachel: My pleasure. Thank you.

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

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

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

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

Here’s an excerpt from the podcast.

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

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

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

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

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

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

Full Transcript.

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

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

Hey, Josh, welcome back.

Josh Clark: So happy to be here.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Adam: Josh, awesome stuff.

Josh: Thank you, sir.

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

In her seminar on February 28, 10 Tips for Designing Effective Surveys, Caroline Jarrett will talk about how to rescue already-in-progress surveys and strengthen their performance, as well as how to approach new surveys from scratch. The next time you need your surveys to obtain useful user data, you’ll have some practical ideas on how to get the best from them.

You’ll learn to:

• Entice site visitors to participate in surveys
• Get users to engage with your questions
• Help your users answer questions accurately
• Deliver survey feedback to stakeholders

If you’ve ever heard, “Let’s do a survey,” then register now so you can learn to obtain insights through a pragmatic method that facilitates clearer decision-making.

We’re creating the Next Step Series in cooperation with Rosenfeld Media.

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

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

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

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

Join us on February 23 for Designing Dashboards: The Do’s, Don’ts, and D’ohs! Designing a new UI? Evolving an existing one? You’ll walk away from this session knowing how to make your dashboard what it needs to be.

You’ll learn to:

• Determine what’s succeeding or failing in your dashboard
• Create a strategy for overhauling your dashboard
  or making a new one
• Prevent interaction pitfalls by focusing on tasks
• Design customizable dashboards that don’t suck

Whether you’ve got an onerous dashboard on your hands or you’re charged with designing a new one from scratch, then you simply can’t afford to miss Hagan’s practical and information-packed seminar on dashboard design.

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

Full Transcript.

Jared Spool: Hello, everyone. Welcome to another episode of the SpoolCast. And I have with me today Jeff Gothelf, and he is delivering a seminar for us, coming up, called “Lean UX: Getting Out of the Deliverables Business.”

Jeff and I decided to have a little podcast before our seminar, because there was a whole bunch of things that we wanted to talk about. In particular, for the last few months, I’ve been trying to get my head around what this Lean UX thing is, because every time I talk to different people I get different definitions. And I have a lot of friends and clients who are coming to me saying, “So tell me, what do you think this thing is?” And frankly, I’m still sort of figuring it out myself, and so I thought I would go to the source of all this and we would find out what Lean UX is all about. So that’s why I brought Jeff here.

Jeff, welcome.

Jeff Gothelf: Thanks, Jared. I’m really happy to be here.

Jared: Excellent. So, before we get into the Lean things, I’m assuming that life existed for you before Lean UX was on the scene. So, the pre-Lean days, I guess, back maybe when you had a little bit more weight than you do now.

Jeff: [laughs]

Jared: What precipitated all this? What was before that?

Jeff: Sure. So my career spans a variety of software companies, both large and small, and agency work, consulting work. So in the 14, 15 years I’ve been working, I’ve been around the block as far as the type of companies and the type of projects and the type of clients and so forth. And almost without fail, up until the last three or so years, we worked in what is known as a waterfall design. Whether it was a consulting gig or an internal gig at AOL or at Fidelity, wherever I worked, it was waterfall. It was gated design. It was the “define, design, develop, test, and deploy” methodology that’s defined the software development life cycle for the last 35, 40 years.

So that was my background coming into this. This was the way we had always worked. And there was discussions of Agile here and there on the outskirts of things, but my experience, primarily, has been waterfall.

Jared: Yeah. Well, I mean, Agile’s been around since about 2003 or so, but a lot of organizations really didn’t take to it until recently, right? It feels to me like it’s sort of a new thing, Agile in general, I’m saying.

Jeff: It’s 10 years old, and the momentum that it’s picked up in the last five years largely exceeds the momentum it had in the first five years of its existence. And I think that that’s largely driven by what we’re seeing in the market with the startup economy, the drive to innovate, the drive to get products to market faster, that the traditional ways of developing software seem to be falling short.

And so companies are reaching for other ways to get quality software to market faster, and Agile was there and is now finding its footing amongst a bunch of companies, as a philosophy, initially, and then through the various methodologies that embody that philosophy, like Scrum or Extreme Programming.

Jared: Yeah, OK. So let’s go back. This is a few years back. You’re deep in the waterfall world. And what sort of pain was typical of those days that sort of led to the thinking behind this Lean UX thing?

Jeff: The nature of a gated process is that it’s very, very siloed. Somebody does their work, and when they’re done, they hand you something, and then you do your work. And so the pain that we were feeling, we would design for months on end, with very little validation from users that we were actually heading towards the right thing. There were changes at the whim of executives. So executives would simply say, “OK, I don’t like red. Make it blue. Put that button over there,” with really no real reason or validation for that except whatever drove that particular demand from them.

Jared: That sounds to me like the old executive swoop-and-poop.

Jeff: Exactly. Exactly. And the seagulls were everywhere. Certainly everywhere in the waterfall worlds that I lived in. And then, ultimately, our focus was never the experience. Even though it felt like we were designing an experience or a product, we were actually designing a document. It was a document that depicted that product, the spec. And there was this feeling of empowerment: “Well, if it’s in the spec and I get everyone to sign off on that spec, then that’s what’s going to get built, and that’s the perfect vision that I have for this product.”

And then, in reality, the spec takes such a beating in the approval process, and then in the development process even worse, that I can’t remember a project where more than 50 percent of the spec actually got built as depicted in that document.

And that’s extremely frustrating for designers and doesn’t really get at what the customers need. Right? You’re developing for this document, which the developer needs to then go and build something that hopefully will work for someone down the line. And so you’re potentially building irrelevant products, and that was the outcome of a lot of the projects that I worked on.

Jared: So, when did this idea sort of come to you of what you now think of as Lean UX?

Jeff: TheLadders, where I work today, was a waterfall company, a startup, working waterfall, when I joined over three years ago. And as that company transitioned from waterfall to Agile, as the head of the user experience team, I took it upon myself to figure out how to integrate UX into Agile. So the roots of this really came from an Agile transition. Now, it doesn’t necessarily mean that Lean UX can only work in Agile, but the foundation, for me, came from figuring out how to take the Agile approach and make user experience work in it, which was a very challenging, and I think still is, a very challenging dilemma for a lot of companies.

Jared: Yeah. My take on this is that Agile was never really considered to be a user experience design tool or a process, right? I mean it was all about creating code more efficiently, and it was all about the code part of it.

Jeff: Absolutely. It was created by a bunch of developers. Actually, I was in Utah this summer for the 10th anniversary of the Agile Conference, and many of the signatories of “The Agile Manifesto” were there. It was kind of a big deal for them. Again, very, very few designers, very few UX folks. There is a UX stage at that conference these days, but again, it’s still not even a main point of consideration for folks considering this, certainly not at its inception either.

Jared: Right. And that makes sense, right? It was never a big center for it in the waterfall world either. I mean that was one of the complaints that we had was that waterfall didn’t really take UX into account in any sophisticated way, most of the time, when people did it either.

Jeff: But ultimately, we did get the design phase, right? The big, upfront design phase, that chunk of time, whether it was a week or three weeks or three months, that designers got to do their thing. They may not have understood what that thing was, but they got time to do it before the developers started doing their thing.

Jared: In the more enlightened projects, for sure. I think there’s still many, many projects where there wasn’t a designer to be seen, and it just got built the way it got built based on what the developers did. But yeah, that definitely makes sense.

But you’re right. In Agile, it feels like the design part is never there. In fact, I’ve had countless number of people tell me that they’ve been in some sort of Agile or Scrum Master training or something, and they’ve gone up to the instructor and said, “So, where does the UX stuff come in?” And they just get that sort of deer-in-the-headlights look from the instructor.

Jeff: And it happens a lot, and because there is no clear methodology. Now, there are several books that are being written on the topic. But the bottom line is this: I think there is a level of assertion that a senior UX practitioner needs to take in an Agile environment in order to make it work. I think, because of the developer-centric nature of Agile and because of the momentum that that has inside an organization, it’s easy for UX to get steamrolled by that process. And so there’s a level of self-determination that the UX folks in that environment need to take in order to inject themselves into that process.

Jared: OK. So here you were at TheLadders, and you guys were putting this Agile thing into play, and you were trying to figure out, “How do I get my UX stuff into that?”

Jeff: Yes. And so I’m doing research. I’m speaking with people who, in theory, have made Agile and UX work. I’m reading heartbreaking stories of Agile and UX failure on the web. And then I’m also paying attention to a gentleman on the West Coast named Eric Ries, who’s talking about this concept of the Lean startup. And Eric has been kind of the poster boy for this particular movement, and he’s written a book on it. And what he’s saying is resonating with me. It’s really interesting.

In essence, if you listen to what Eric’s saying and you read his book, he’s describing user experience and user research and, you know, getting out of the building and talking to customers and validating your assumptions. But his focus was: do the least amount of work necessary to reach those validations.

And that really hit home, for me, in figuring out how to get this UX integration into Agile. Because we’re working in such short cycles, and with a much smaller level of scope, what was the minimum amount of work that my team could do in order to keep feeding the dev machine? Developers can’t sit idle. You have to keep giving giving them work to do, keep giving them code to write. What was the minimum amount of work that we could do to keep that machine going and make sure that we’re developing valid products for our customers and for our business? And that’s really where a lot of these ideas came from.

Jared: So it really did come out of Eric Ries’s Lean startup stuff, which, in turn, came out of Toyota’s Lean manufacturing stuff. Right?

Jeff: Yeah, that was definitely part of the inspiration, kind of helped me figure out how to mix these two things that weren’t necessarily meant to go together initially.

Jared: OK. So that makes a lot of sense as to, then, why that term got on there. And I know that there’s a lot of confusion about it, right? There’s a whole world of people who think that Lean UX means, basically, taking shortcuts left and right. But that’s not what it is. It’s this idea of doing very short iterations, very focused work, cutting out any sort of fat that might be in your process that isn’t advancing that question of, “What is it that our customers and our users need us to build?” And then give that to developers, get it in front of them, and then see if, in fact, that really worked. Right? I mean, that’s sort of what we’re talking about here.

Jeff: Yes. Really, the two fundamental, I think, pillars of Lean UX, in the way that I’m defining it in my writings and in my talks and stuff, is that designs are hypotheses. No matter how great of a designer you actually are, whatever you put forward is a hypothesis. And so you need to validate that hypothesis, both from a business perspective and a customer perspective. And so you want to minimize the amount of time that you’re spending pursuing the wrong hypotheses.

Jared: That’s excellent. That’s excellent.

Jeff: Hence, the Lean aspect of it. The more waste I can cut out, the more wrong paths I can figure out quickly, the sooner I’ll find the right path. And what’s really interesting is that as you do this, as you discover that right path, if you do this in a collaborative fashion, you build a shared understanding across your entire team.

And with that shared understanding comes less of a need for the thick design documentation and the deliverables. So the reliance on the spec, to tell the team what we’re building and why we’re building it and what it needs to do, diminishes as the team understands why we’re pursuing certain paths and not others.

Jared: OK. That makes perfect sense to me. I remember for a long time thinking that every design is a prototype. Which is sort of the same thing here, right? So, Microsoft, when they finish the last version of Word, that’s really a prototype for the next version of Word, because they’re going to go off and study how people use Word to figure out what features to build, what items to go into it. They don’t just sit down and, for version 11 of Word, think to themselves, “Well, we’ve never done a word processor before…” They’ve got 10 versions of prototypes that they’ve built and shipped, and then there are all the prototypes that they built that they didn’t ship that go into this.

So, when you say it’s a hypothesis, it’s sort of along the same thinking there, that, in essence, you’re constantly trying something out and then learning from it for the next thing you’re going to do.

Jeff: Yes, absolutely. The main difference between Word is that you’re doing this in as short a cycle as possible, on an 18-month cycle, to figure out what that delta is for the next iteration.

Jared: Absolutely. So this, to me, seems quite smart, right? It’s very much looking at bringing down the time that it takes in order to get to the information you need, to know what you should be building.

Jeff: Yes. That’s exactly right.

Jared: OK. So that’s basically it. That’s the essence, and then everything that you do when you say “I’m going to practice Lean UX” are the activities you do to get to that shorter state.

Jeff: Yes. And it’s a significant shift in the way that many designers are used to working. So there’s this mentality, and I think it’s been built into designers, especially folks who spend a lot of time in agencies, but also internal folks, that they have to get it right the first time. The first design has to be right, and if I get it wrong, I’m going to lose the client, or they’re not going to like it. They’re not going to believe that I’m a good designer.

And so there’s this need to put something very polished and final out as the first iteration. And I’m pushing back on that and saying let’s reeducate our clients, let’s reeducate our stakeholders, and say, “Guess what? No one else in the process has to get it right the first time. Designers don’t have to do that either. Let’s get these ideas, these raw ideas, out early. Let’s validate them, as a team, understand why we’re making these design decisions, and get to the right path as quickly as possible.”

Jared: So one of the things that I’ve seen in teams — you can tell me if you see this with the people you’ve worked with — is this mentality that we have to get everything into whatever this next iteration of what we’re building is, because the world is actually going to end the day after. And if we don’t get it in, we will never have a chance to get it in next.

It’s not just the designers putting it into their designs, but it’s the whole product mentality of the next release has to have every possible feature we can think of. There’s all this sort of cramming stuff in, then when you give yourself permission to say, “No, this is not the end of the world. We will have many other times to get this right. What we want to do is figure out whether we’re going in the right direction or not.”

That permission to not have to get everything into the design, not have to get anything into the release suddenly frees you to really focus on putting something out there and getting some feedback, and then learning from that.

Jeff: Yeah, and that there are two organizational commitments that you need to make that a success. This has to be built into the culture or introduced into the culture of the organization in which you work.

One is the freedom to fail, so that there has to be a sense that if this is wrong, I’m not going to get canned. I’m not going to lose my job if I get this wrong. And then the idea of iterations, the idea of saying, “We’re going to incrementally improve this and iterate on this idea over the course of a couple of weeks, a couple of months, a couple of years” — whatever it is, whatever is relevant for that context.

But without that iterative approach the idea fails, because again, without that, then the designers have all the burden of getting it right the first time. So the iterative approach has to be built in there, and then the freedom to get it wrong the first couple of times also has to be in there.

Jared: So this idea, you’re trying to do things as fast as possible. You’re trying to get as many iterations into your release as possible. Each iteration allows you to micro correct and get to the right place.

What I hear you saying is that you have to be OK with the fact that sometimes you’re going to go off in the wrong direction. But because you’re going very quickly and each iteration is, in essence, pretty small, you’re not going to go off in a majorly wrong direction; you’re just going to go off in a small wrong direction and you can correct for that. The fact is that you’ve learned something and that’s really valuable.

Jeff: Yeah, and that’s the key. The key is to make the iterations short. Again, minimizing the waste, staying lean — this is kind of tying back to the whole Toyota thing — and designing the minimum amount that you have to to communicate your idea to your target audience.

So whoever you’re trying to validate with today or tomorrow, design the least amount that you have to to communicate your idea to that person. So for some people that could be a Word document. For other people it’s a whiteboard sketch. For others it’s a fully coded prototype. You have to understand who you’re trying to get validation from as you’re working towards these iterations.

Jared: Yeah. OK. I’m beginning to get this here. So when I talk to folks, some people seem to think that Lean UX is the latest Methodology, with a big M. It’s this packaged thing that has predefined processes and rules and things to do.

Then others are telling me, “No, no, no, no, no. It’s a mindset. It’s just a way of thinking. There are no set processes and rules. It’s just an attitude.” It’s sort of like being a hippy. “With no rules, man, we’re just going to go with flow.” It’s The Dude abides, type thing. Then there are others who are saying, “OK, there’s nothing new here. This is what we’ve always been doing. Someone’s just slapped a brand name on it and we’re running with it because it sells to executives.” Where are you sitting in that?

Jeff: So here’s the way I see it. The way I see it is this, I’ve laid out an example methodology in the work that I’ve published to date on Lean UX. That is one way that this process could work. If that process works for you contextually, that’s fantastic. In that case you can see it as a methodology.

But ultimately what happens in my experience is as you practice this methodology as a ritual over and over, it becomes a mindset. It becomes a way of thinking about software development and software design that’s different from the way that many organizations are working today. So by practicing the methodology, it becomes a mindset.

Now for me, as I was coming up with these ideas, I said, “This is really working for me well inside TheLadders. I really want to publish this and see what the community thinks about this.” As I was figuring out how to lay this out, I needed a wrapper for it. I needed a handle, something to put around it that said, “This is the thing.” Agile UX felt a little compartmentalized because I truly believed that this process can work in non-Agile environments as well.

So Lean UX, coming out of the work that I was getting from Eric Ries and others, seemed to be the right idea for wrapping. It’s just as a wrapper for me. It’s a handle for all of these ideas to go into one spot.

Now if people have been doing this — and some people have definitely come up to me and said, “Hey, I’ve been doing this for years” — that’s fantastic. And I’m jealous of that. I wish that I had spent the bulk of my career working this way. But there are many, many, many practitioners who don’t actually work this way who would like to work this way and introduce this concept to their teams.

Jared: OK. Yeah, so I get it. What it reminds me of is sort of like what happens in a professional kitchen. So a new chef comes into a well-established kitchen that’s run by a very competent head chef. That head chef has a way of doing things. If you’re a new chef, you’re not going to tell that guy who has been doing this for 30 years how to run his restaurant. If you’re smart, you’re just going to shut up and you’re going to do it his way and in essence learn his methodology.

But over time you’re going to internalize that and start to be able to do the things that he needs you to do his way. At some point you’re going to go off and open your own restaurant. You’re going to take that even further and do it your way, but it’s going to have those influences of that early person on it.

Jeff: Absolutely. I mean it’s the Karate Kid thing, right? He comes in every day and he tells him to paint the fence. He doesn’t understand why he’s painting the fence. Every day, paint the fence, paint the fence, paint the fence. Then all of a sudden he knows karate and then he goes off and he puts the pieces together that he learned when he was waxing on and painting the fence, etc., to build his own version of karate.

Jared: So what you’re saying is if designers read your book and follow what you say, they’re going to get a really cute girl.

Jeff: [laughs] At the end, yes. Yes.

Jared: And beat up the bully.

Jeff: Yes, yes.

Jared: OK. Now we know the purpose of Lean UX.

[laughter]

Jeff: It’s the purpose of everything, isn’t it?

Jared: Yes, I guess it is. Now that you mention it, yeah. Perfect. OK.

So it really does seem like there’s a pony in here, right? There is something to this; this isn’t just some branding of some activities that have been well-established. There is something here that’s different than what people are doing who aren’t really paying attention to their process.

And it’s important because — this is what I think — we could think of this almost as a statement that’s been running through my head for the last few days as I’ve been putting all this together. That statement is this — tell me how this works for you — UX in Agile is a question, right? We don’t really know, if you just look at it at the outset, if you look at what Agile processes are all about, there really is not a discussion of UX.

So there’s a question here. How do we do UX in Agile? And Lean UX is one answer to that.

Jeff: That’s correct. Lean UX is an answer to that. If it makes sense in your organization, it’s a great place to start. But it’s not the only place that it could work. I mean even within waterfall organizations I think Lean UX can make a lot of improvements. But it’s definitely a great place to start if you’re looking to integrate UX into Agile.

Jared: I think that one of the things that’s really nice about it is that unlike other approaches to UX, Lean UX to some extent sounds like you’ve built the techniques and the tricks from the ground up to fit in an Agile framework versus retrofitting old stuff into this new, faster way of developing.

Jeff: That’s correct. That was the genesis of this.

Jared: OK. So while there’s a lot of stuff that is in Lean UX that comes from other traditional UX practices, everything’s been rethought to say, “OK, it has to meet these constraints of really fast iterations, to work within the sprints, to be able to produce stuff really, really quickly.”

Jeff: Yes. The constraints really don’t waste effort on paths that will not ultimately yield some sort of value. That value could be learnings, it could be software, it could be customer dollars, whatever it is. But minimize the time spent on those avenues.

Jared: OK. This is all feeling very, very comfortable for me, and very smart I might add. You’re a very smart dude.

Jeff: Thanks, man.

Jared: Here’s a thought, just something to end on here. Do you think that Lean UX is actually a starting point and maybe five or 10 years from now we will have transitioned into something else? Or do you think that this is something that’s got even longer legs to it that will be around for a long time?

Jeff: I think this is it. I think we’re done. I think I’ve defined the end of it. [laughs]

Jared: Oh, OK. Good. OK. Pop open that bottle of wine. Let’s celebrate.

Jeff: That’s it. Let’s move on.

[laughter]

Jeff: No, I sincerely hope that this is the beginning of an evolution towards a few things. First of all is the evolution of the user experience practice as stewards of the product and facilitators of experience design. I’m not saying we should stop designing, but greater facilitation of the creation of that experience itself.

Even more importantly, a significant tearing down of the walls. Tear down, man. Tear down the walls between teams, between developers and designers and product managers and business analysts and stakeholders. Really breaking down those silos and focusing on working as a cohesive unit towards solving a business problem.

What happens when you achieve that, and what I hope to see this evolve into is higher output teams that are more productive and that are wasting less effort and creating better products in the end. But I definitely see this as an evolution in the way that we work with our counterparts in software development.

Jared: Yeah, this makes perfect sense to me. I was working with a client just a few weeks ago. They have a group of designers who spend weeks and weeks and weeks producing these multipage documents that describe 12 or 14 new things that they want in the next release. Then they meet with somebody who then says, “You know what, we can only do half of those.” Then they collaborate together on what the “half of those” things are.

Then that group of people goes and meets with somebody else who says, “You know, we can only do half of that.” By the time they’re done they only get to do two things that actually get into the release after they’ve done all this work of producing all these documents. None of the design feels coherent when it’s done because it’s this hodgepodge of random things that were chosen because they could fit it into the execution schedule. It felt so broken to me. I see that over and over and over again.

It does feel to me like if you have everybody talking, and it sounds like what you’re talking about is that developers are understanding what design is about and participating in the design. The designers are understanding what it takes to get something developed and are participating in the development cycles so that it’s these tight little iterations instead of these really long 12 or 18-month processes. That just changes everything when you do that.

Jeff: Absolutely. What the Lean UX approach really espouses to do is to build transparency into the design process. By building that transparency and demystifying the black box of design, there’s a sense of trust that begins to grow between the different teams, between the different team members. It’s through that trust that higher productivity happens,that that shared understanding can develop, and that less CYA tactics, where I’m not running a lot of code until that wireframe is fully signed off, happens. Less of that happens because there’s a trust between the team members.

Jared: OK. Yeah. That just sounds so awesome.

[laughter]

Jeff: I think so, too.

Jared: That’s what’s happening at TheLadders. That’s what you’re doing, right? This isn’t just a wish; this is how you’re getting stuff done, right?

Jeff: Yes. We’ve had this in place for a while now, for well over a year. We’ve refined it and iterated on it and figured out how to make it work. What I’m really honing now is how to export it. So we’ve gotten one or two teams working very, very tightly together, working very, very well. How do we take that, how do we bottle that up and export it to the next team and the next team and so forth? That’s the big challenge that I’m facing right now.

Jared: That sounds really cool. That sounds really cool. So now, December 7th, you’re going to be doing a virtual seminar for us.

Jeff: Yes. I’m very excited.

Jared: So just really quick, what are some of the key pieces that people are going to get out of that seminar that makes this all worthwhile here?

Jeff: Absolutely. We’ll cover very explicitly what Lean UX is and what this core process is, and again, the foundational process that you can take and build off of and how that works. We’ll cover how to engage developers and stakeholders and other members of the team as well as customers in a leaner fashion and what to do with that feedback.

At the end of it, I’ll do two things. I’ll go through a case study that shows how we actually took this approach and scaled it up to a large portion of TheLadders organization to solve some business problems. Then at the end of the presentation I’ll give five very tactical things that everyone who attends the webinar can apply literally the next day or that afternoon at work, to start trying these things out and see how they work out within their organization.

Jared: That’s incredible. I’m very excited about it. I can’t wait to hear it. Thanks for taking the time and helping me understand about this Lean UX thing.

Jeff: My pleasure, Jared. Thank you for having me.

Jared: So as you heard, December 7th you can come and hear Jeff talk about getting out of the deliverables business with Lean UX at the UIE Virtual Seminar. You can found all of that out at uievs.com for UIE Virtual Seminar. Check it out. We’ll love to have you there.

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.