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.

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.

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.

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.

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.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

She concluded her post with this comment:

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

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

There are two definitions I can see here:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

It’s not too different in our world of design. There’s a lot of long-forgotten “old thinking” which is relevant with today’s thinking. In today’s article, I share an old model that has appeared on my radar over the last few years.

If you hang out with me, you’ve probably heard me say, “Good judgment comes from experience, and experience comes from bad judgments.” Today’s article describes a model that explains how that maxim actually works. The model is called The Four Stages of Competence, and has a myriad of uses in our design work.

Read the article: The Flexibility of the Four Stages of Competence.

What old thinking have you discovered lately? How do these four stages fit into your design work? We’d love to hear your thoughts below.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Read the article, On UX Leadership.

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

That’s not the case when you bring Adapative Path’s CEO, Brandon Schauer into the picture. Brandon has a way of getting an entire team—executives, designers, developers, marketers all producing dozens and dozens of ideas. He does this through a group of excerises and tools you’ll find in a workshop called Good Design Faster.

In today’s article, we look at an excerpt from an interview I had with Brandon back in September. Brandon shares his methods on how to get your team producing many ideas, what makes ideas tangible, and why it’s critical to move past the first idea.

Read the article, Good Design Faster – An Interview with Brandon Schauer.

This article is just a small taste of what the Good Design Faster workshop is all about. On Wednesday, November 9, Brandon will share a lot more on Good Design Faster at an all day workshop at the User Interface 16 Conference in Boston.

How do you motivate your team to get innovative? Share you thoughts below.

Dave Gray, founder of XPLANE, and co-author of the book Gamestorming: A Playbook for Innovators, Rulebreakers and Changemakers, is known for his sketching and brainstorming techniques. At last year’s User Interface 15 Conference, Dave gave a 90-minute talk called Gamestorming: A Grammar for Creativity and Innovation. In light of the fact that Dave will be joining us for an October 20 virtual seminar, we’re presenting a sample of his UI15 talk for this podcast.

The cubicle is a staple in many modern workplaces. It came into existence to give workers their own individual spaces to do their work as efficiently as possible. The drawback to this is it all but kills collaboration and stifles creativity. Dave challenges the accepted idea of workplaces as factories. He suggests that moving toward modeling work as a “collaboratory” will help open the black box of design to others within the organization.

Gamestorming can allow collaboration to happen. It quickly gets a lot of people working together, sharing ideas, and getting creative. Words may be tricky because you’re not certain if someone has interpreted what you’ve said the way you meant it. The beauty of Gamestorming is it gets people to think visually and physically express their thoughts and ideas on paper.

Another technique that Dave talks about is Bodystorming. Instead of sketching ideas out on paper, with Bodystorming you physically act out an experience. One example that Dave points out is a group that was attempting to address the problem of disposable coffee cups. By actually creating a mock experience of waiting in line and then ordering your morning coffee, they were able to generate a number of ideas for improvements to the cup itself. These improvements in turn made the entire experience better.

You won’t want to miss Dave’s virtual seminar Brainstorming Games for Team Creativity–Gamestorming. Dave will showcase techniques that get the entire team involved in the design process. You’ll see how to keep the energy level among your team high and arrive at consensus and get results faster. You can add lifetime access to the recording of this seminar by using the promotion code GAMES.

[ Subscribe to our podcast via ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Dave Gray: ..from a business perspective. Business people have a tendency to think of design as something that’s kind of a black box. “We have a department for that. We have a team that does that.”

And we typically want to kind of separate them from the rest of the organization, right? Because it’s kind of crazy and we don’t look inside the box that often, it’s a little crazy in there.

I mean, who feels like they’re in that box and the senior people don’t necessarily want to look in or know what’s going on, they just want good things coming out of the box? Anyone identify with that?

Because we’re in the box, right, we’re the design people. But what we’re finding more and more is that we can’t just do our design inside of our black box, we have to engage with a lot more people than we used to.

We have to engage with the organization, with customers, with other people in organization. I mean, raise your hand if you need other people who are outside of your team to get your job done. Yeah. I mean, almost everybody.

So this black box has to be something that we need to open up and that’s what Gamestorming’s about. It’s about taking those things that we do as designers and making them more accessible to groups instead of individuals.

So this is a woman named Elizabeth Gould. She discovered something called neurogenesis. Raise your hand if you learned in school that brain cells don’t regenerate. I learned that in school. You don’t take drugs, right, because if you take drugs, you’ll kill your brain cells and they won’t grow back.

Well, if you have taken drugs, I have good news for you.

[laughing]

Brain cells do grow back, and this woman, Elizabeth Gould, a researcher at Princeton University, discovered this in 1999. And it was an unexpected discovery, because there had been a lot of research done that proved that brain cells don’t regenerate.

Here’s the thing – almost all that research had been done on lab animals, who were kept in cages and they weren’t in their natural environment and they weren’t creatively stimulated at all. Basically it was like taking a prison population and thinking that it represents humanity, right?

So here’s a question I have for you – does this look like anything you’ve ever seen at work?

[laughing]

Right? OK, there’s my reveal. All right, so here’s the thing. If we wanted to design our workplaces to inhibit and stifle creativity, to kill brain cells literally, we couldn’t have done better than the modern office cubicle.

So this is one of the reasons I’m going to have you actually standing up and using your body today, because that’s part of what’s killing creativity is being in the gray box and trying to get your work done.

All these things were designed to make work as efficient as possible, not to make work as creative as possible. So we have to find ways to break down these barriers if we want to get more creative at work.

The model for work or the metaphor for work that we’ve been working under for a long time, and a habit that we have to break, is thinking of work as a factory. And, you know, think of it – in a lot of ways, we’re always mapping, processes we’re doing work flows. A lot of those kind of ideas, and I’m not saying that work flows and processes aren’t important, but they aren’t everything, right?

So we need to move from thinking of our workplaces as factories, even to the point where, “We’re going to make a creativity factory, and you’re going to be in charge of the initial thing, and then you’re going to be in charge of the next thing and the next thing,” and start thinking of them as collaboratories, where we have to get comfortable with a little bit more chaos and mash-up in the process, because that’s the kind of thing that helps creativity happen.

These are some snapshots that I took of people Gamestorming. This is just very simply a survey, except it’s done with sticky notes with a physical group in a room. So a very quick way to get a lot of people helping and participating and answering questions.

A couple of pictures of just people doing creative work, getting into the Gamestorming process. I mean, does this look like something you’d like to see more of at work? Raise your hand.

No? Come on, raise your hand, you liars.

[laughing]

OK, it looks a little crazy, it looks a little chaotic, and I’ll explain to you a little bit what these people are doing, but when we were writing the book, that’s actually a paper prototype of a toilet seat. Yes.

[laughs]

Alright, when we were writing the book, my co-authors and I convened about 50 people in a conference center to actually work on all the ideas and prototype all the stuff in the book. And I want to tell you a story of something that happened there.

50 people come together in a conference center, they’re staying there. They’re going to have basically two or three days with them. In the early stages we did a game called Poster Session, which we are going to do today together.

And the idea behind Poster Session is everybody makes kind of an infographic style poster that explains something that they’re interested in, something they’re excited about or something that they want to propose as a project, et cetera.

This guy, who’s not a designer, had the issue that he cared about, which was disposable coffee cups. Millions of us go to coffee shops every day, we buy our coffee in disposable cups, we drink our coffee and we throw the cups away.

Now, that adds up to a lot of waste and a lot of problems, because they’re hard to recycle and so forth. And here he was coming in, he said, “You guys have design skills, this Gamestorming stuff is about innovation and creativity. I don’t have the answer. I have the problem. The problem is we need better disposable cups.”

That’s what he thought the problem was. “I don’t want to blame the people who are throwing away the cups, there’s got to be something we can do to make a better cup that’s just easier for people carry around and use and re-use, instead of them using all these paper cups.”

So he said, “I challenge you to help me with this, help me do this.”

So the survey that I mentioned earlier was part of that activity. So he got some people with him to work on this project that he cares about, and they started by doing kind of a survey of like, “What’s your coffee experience like?”

They designed some questions, they had people answer the questions, and one of the things I heard from them was, “Doing a survey in this way was actually very helpful, because I got to see more of the thinking process, as people answered the questions with the sticky notes, than I would have if it was just an online survey. So we actually went and changed some of the questions and were able to adjust as we were getting feedback.”

Now, it’s not necessarily what you would do for a research survey, but for a quick and dirty getting a feel for things, and of course most of us do know what it feels like to go get a coffee in the morning, and most of us use disposable cups, that they were able to do that.

The next exercise that we did with them is something called Bodystorming, and this is a picture of people Bodystorming. Raise your hand if you’ve done this or heard about it.

Bodystorming is simply a kind of improvisational role play where instead of designing your product on paper, you actually design it by working it out with other people in real time, in real space.

So this person is the iPhone, OK? You can see the iPhone there. And we have the user. And these are people who are aspects of the application. This guy’s looking up whatever he’s going to be doing next.

So it’s a very quick way to prototype a system and really get a feel for how does it feel to interact? How does it feel? Get a flavor for it. And it’s a kind of a play that’s helping us figure out what’s on the other side of that? What’s the better iPhone look like? What’s the next generation look like?

We could play with those things and tweak them until we start to get a feeling for something that then we can go a little bit deeper on. So it’s a way of sketching. This is a way of sketching.

So the Betacup team, that was their name, this guy, Tony Daniels, he had actually named his problem the Betacup design project. So what they decided to do in their Bodystorming was they were going to set up a Starbucks, and they’re going to feel out the system. So they have barista, this is the Starbucks here, this is the asshole, see?

So they actually, what they did was they set up the Starbucks and they started role playing what it feels like to be in the line, to go through, to experience this, to try and figure out, “How can we fix the cup? What is it that we can do with the cup?”

And they came up with some pretty cool ideas, just by tweaking the system a little bit. And one of the things they discovered was, “Wow, it sucks to be in line behind the asshole, because he’s taking forever, he doesn’t know what he wants. You’re waiting in line, you’re waiting in line.”

So they came up with this idea where your cup would also be your loyalty card and your credit card and everything else, so you’d have your order built into your cup, so when you came to order, you could skip the whole line, you just put your cup at the end. They picked it up, they had your order in there, they had your loyalty program in there. All they had to do was swipe the cup and they could put it into the system and it would come out the other end with your stuff.

So there’s all these benefits to that, like you could pick up three or four cups from your co-workers, you know, and you wouldn’t have to remember their orders, because it would be built into their cup, right?

So they had actually kind of thought about a lot of cool benefits.

So after the event, a lot of these people that we had in were bloggers and social media people and so forth, so they actually posted about it on the Internet. “This is our Betacup Bodystorm, these are the ideas that we have.”

And it was, you know, people were reading it, people were like, “Oh, this is kind of interesting.” And who would be reading this but Starbucks, the VP of Sustainability at Starbucks saw the video. This is like a really rough, shaky, hand-held two-minute video of the, excuse my language, I’m saying it because it’s the language they use – “The asshole in the Starbucks line,” and the way they acted the thing out.

This was the guy they had on their radar. They wanted to get a meeting with him. They had wanted to get a meeting with him forever, and he called them.

Now, What’s interesting about this? Well, when you’re doing innovation work, you don’t know what you don’t know when you begin the project, so you’re learning as you go.

So first they thought, “We’re going to make a better cup, it’s all about the cup.” But then they started looking at the system, and they said, “Actually, what we need to work on is not just the cup but the whole system around the cup, and make the system work better.”

And then from there it became the social system. The thing that the Starbucks guy was excited about was not the particular solution that they had come up with. He was interested in the whole social engagement factor about how they got all these people connected to trying to solve this problem together, collaboratively. He was interested in the wisdom of crowds stuff.

So there’s actually now a Starbucks competition. It’s a $20,000 Betacup prize. They’ve already awarded it once. There’s winners and everything. This came out of just people getting into a room and not knowing what they were going to do together…

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

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

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

How to get the free recordings?

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

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

Story mapping is a way to build a model of user experiences. More than that, in the Agile context, it allows you to tactically plan for what should go into each release. It is a way to get everyone on the team thinking and talking about user experience. Getting people into a discussion mode starts to create a very collaborative environment.

Jeff Patton is a consultant and expert in Agile development. In his sold out virtual seminar, Story Mapping for UX Practitioners: Tying Agile and UX Together, Jeff outlined how to create a story map and how it fits into the Agile process. Jeff ran short of time to answer all the questions during the seminar, so Adam Churchill caught up with him to answer those remaining for this podcast.

Here’s an excerpt from the podcast.

“…A lot of the answers to selling [story mapping] is, to not, just get started. If people can see and physically engage with something big and something they can touch, [the answer is] to get it up there and get them to engage in it.

I’ve seen a lot of folks spend a lot of time trying to introduce the concept to people, trying to convince people it’s a good idea for them to do it. If you’re a user experience person, build one of these maps on the wall, physically in your area, and if you’ve got someone to collaborate, lead them over to it and say, “This is what I’m seeing happen. The person using our product is doing this, this, and this. And here’s where the real pains are.”

And when I’m working with people on these things, I really watch closely for their body language. I watch for people to start to point and start to use words like “here” and “there” and “down here” and start to engage with it. I’ve found that these things end up selling themselves. Trying to sell it doesn’t work.

There are a lot of products that are hard to sell. And I think I’ve heard from people talking about TiVo this way. TiVo has a hard time telling people what their product does and why you like it, but you use it and you know why you like it. And it does better being sold via word of mouth, or maybe you just have to experience it…”

Tune in to the podcast to hear Jeff address these points:

• Who do you have build the story map?
• How do you get the right people in the room?
• How do you story map when you’re designing with multiple personas in mind?
• How many users should you interview prior to building the story map?
• How do you ensure non-functional requirements don’t fall through the cracks?
• How do you scale this process to different-sized projects?

Do you incorporate UX into and Agile environment? Share your thoughts with us in our comments section.

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

Full Transcript.

Adam Churchill: Hello, everyone. Welcome to another episode of the SpoolCast. Jeff Patton recently joined us for a Virtual Seminar titled “Story Mapping for UX Practitioners: Tying Agile and UX Together.” Now, the seminar sold out, and the activity we were watching in both the Adobe Connect room as well as the Twitter stream was a lot of fun to watch. Lots of good comments, lots of good questions.

Jeff’s seminar spoke directly to folks working in an Agile environment who struggle with knitting user-experience design practices together with the iterative process they work in.

Jeff’s graciously offered to come back and tackle some of the questions we didn’t get to address in the seminar. If you didn’t listen to this particular seminar, you can get access to the recording in UIE’s growing User Experience Training Library, which presently has over 70 recorded seminars from wonderful topic experts just like Jeff Patton.

Hello, Jeff. Welcome back.

Jeff Patton: Hello. How are you doing today?

Adam: I’m doing very well. We had a lot of fun yesterday, didn’t we?

Jeff: We did have a lot of fun. We packed a lot into a short amount of time.

Adam: Well, let’s get right to it. For those who weren’t able to join us yesterday, can you give them an overview of what we did talk about?

Jeff: Yeah. My goal was to introduce people to a practice, something that I’ve been doing for a lot of years and something that’s growing in popularity. A lot of people are doing this. We focused on story mapping. And for a UX person, I’ll tell them story mapping is a way to build a map of user experience, something like task analysis.

I’ve seen lots of flavors of task analysis that yield sort of a map that looks like a story map. But if you’re working in an Agile context, you’ve got to build a backlog and come up with a bit of a tactical plan for what we’re going to put into a release and how we break it down into bits and pieces to build.

So we talked about that idea of a story map and how it sort of plugs that hole. And the big benefits, for me, are we’re able to tactically plan and execute like we need to do in an Agile context, and we’re able to get everybody thinking about user experience. So, for me, this is why it’s a bit of a bridge-gapping practice.

So during that talk, we talked, basically, about what an experience map was and how to quickly create those. And then we went into a lot of depth about what user stories are and what they aren’t. And one of the biggest misconceptions, or one of the questions I hear constantly, is “How do I write good stories?” One of the points to make about stories is they’re called stories because they were meant to be heard. They were meant to be discussed and talked about, and how they’re written isn’t as big an issue as what people talk about and what pictures they form in their heads.

Definitely, we have to write things down, but the form that we write them is really contextual. Then, when we combine these ideas, of the idea of a story or the things that we talk about and the idea of something like an experience map that lets us see the big picture, that’s where we get the story map.

After introducing that idea, we talked about the basics of how you build a map. Start by getting the big picture, what I would call the backbone of the map, down, and some of the details, then how we pile in lots of details. And then, where we ended up with was talking about how we use that simple square structure of a story map to carve out or slice up a product into incremental product releases.

This is where I think the shape of the map shines. It arranges information left-to-right based upon users’ experience and decomposes it top-to-bottom into parts. And when I slice it left-to-right, I start planning or thinking about releases in holistic product slices. And I get better releases. I get both thinner releases, releases that have less in them, and more comprehensive releases, releases that really satisfy users’ needs.

That’s where we ended up. There was a last tail-end section that I came into the seminar hoping that I could fold time or do a lot more than we did. And the section we didn’t get talked about tactically working with story maps, and tactically working with stories for that matter, during Agile-style iterative and incremental development.

Adam: Well, let’s get to some of those questions that we didn’t get to answer yesterday. There was a question about, how do you sell to the group, and how do you get started with that group?

Jeff: A lot of the answers to selling it is to not, to just get started. If people can see and physically engage with something big and something they can touch, it’s to get it up there and get them to engage in it.

I’ve seen a lot of folks spend a lot of time trying to introduce the concept to people, trying to convince people it’s a good idea for them to do it. If you’re a user-experience person, build one of these maps on the wall, physically in your area, and if you’ve got someone you’ve got to collaborate, lead them over to it and say, “This is what I’m seeing happen. The person using our product is doing this, this and this, and here’s where the real pains are.”

And when I’m working with people on these things, I really watch closely for their body language. I watch for people to start to point and start to use words like “here” and “there” and “down here” and start to engage with it. I’ve found that these things end up selling themselves, and trying to sell it doesn’t work.

There are a lot of products that are hard to sell. And I think I’ve heard from people talking about TiVo this way. TiVo has a hard time telling people what their product does and why you like it, but you use it and you know why you like it. And it does better being sold via word of mouth, or maybe you just have to experience it. Does that make sense?

Adam: It does. It does. And yeah, there’s a list of products like that. Twitter would be, I guess, another good example. You don’t really understand what it is until you use it.

Jeff: Yeah. Yes. Something like that.

One of the key points out of yesterday’s discussion was, and several people pinged me afterwards, and I’d asked them, “What were your takeaways from this?” And I strongly made the points that it’s not what’s written on paper that matters; it’s what’s in people’s heads that matters. We’re working really hard to collaborate together and form shared understanding in people’s heads, and that’s a value that people don’t focus on much, and it’s a real benefit we get out of these big, simple models on the wall.

Adam: So, Jeff, who do you have to have in the room to build the story map? Do you involve clients, the development team, the user-experience designers? Who’s in the room?

Jeff: What’s interesting about a story map is–well, I’ll go back. I’m lazy. I don’t want to build multiple things. A story map, initially, for me, is about thinking through and understanding user experience. Subsequently, it’s about explaining user experience to other people. And then when we start breaking things down and planning, it starts to be, well, about that, about planning and about tactically figuring out how we’re going to get this product built. And there’s different audiences for each one of those activities, as you can imagine.

When initially using the story map to kind of understand what I’m doing, maybe this is a habit I picked up from working in an Agile context. I like to pair, and I’ve seen a lot of designers that focus on pairing. And there’s an old Yogi Berra quote: “Pair up in threes.” So I like these small groups of two, three, sometimes four, to think through and build things. It’s a single-pizza-sized group. These are the people you want to pull together, that have some understanding, to initially build the map.

Once you’ve got a map initially built or initially structured, then I want to start to pull in other people with different kinds of experience, different sorts of subject-matter experts, and I want to vet my understanding with them, and I want to add to it and change it and richen it up. If, by building the map, I see I’ve got holes, and I’ve got to go out and do more research or learn more, then I might do that and come back and fatten up the map that way.

Then, once I’ve got a little bit of a map that starts to explain a product, oftentimes we’ve got to share that with other stakeholders or share the vision of what we’re getting with this product with other people. So we’ll bring people in. And the purpose is not to add to the map or validate it so much as use the map to explain, “This is how we see people using this new product, and this is the flow of that use, and this is how it breaks down into pieces.

Then, downstream, when we have to start taking this apart and planning it, that’s when we want to pull more engineers and more QA people, other people that know, tactically, what it’s going to take to get this thing built, into the room.

So it’s not if all those other people should be involved. It’s more of a when they should be involved.

Adam: Any tricks to helping you understand if you’ve got the right people in the room?

Jeff: Adam, looking back, there was a question. And I’m going to repeat somebody’s question. What if a key stakeholder, a product manager, checks out of the process and starts thinking, “That’s not my job. It’s engineering’s job”? And the reason I’m bringing them up is, how to tell you’ve got the right people in the room, sometimes they sort of vote with their focus, and if they’re losing focus, they may very well be the wrong people.

Now, getting the right people in the room. One of the things I’ll focus on is a team, I leverage a mantra and often draw a Venn diagram that looks at these three concerns: valuable, usable, and feasible. Valuable to the organization building the product, usable to the people that end up using it, and feasible to build.

Now, strictly speaking, if it were just building a map of user experience, I could just focus on people who understand users and how they work with things, and the right people to initially build the map could be just user-experience people. Some organizations just have business analysts that take care of that capability.

But I want people in the room that are also thinking with their business hats on and really gaining some empathy and understanding for users. And while they may not be contributing to the map, I want them in the room.

Then there’s a dysfunction I commonly see and everybody commonly sees. A business comes up with a great idea. User experience works out the details of how users need to work with it. And then we produce all those details for engineering and engineering says, “That’s going to take a long time to build.” And then we go back to the drawing board because it far exceeds the budget that we’ve got.

Having engineering in the room earlier on gives us early warning for that, and oftentimes gives us perfectly reasonable ways we could do things that would be cheaper, more cost-effective to build and still satisfies users and still reaches the business needs.

The right people in the room for me is a balanced team that includes someone who understands some engineering concerns, someone who understands business concerns, and initially, when we’re building out the experience, people that deeply understand users’ experience today and then the experience we’re striving for with the new product.

Adam: Edwin wanted to know how you do the story mapping when you’re designing with multiple personas in mind.

Jeff: That’s a great question, and I’m glad you asked it. I’ll answer another question first, or point out another concern first, and then answer it a little bit more squarely.

There’s a standard user story template that’s used by a lot of people in Agile development. It’s the, as a kind of user, I want to have something do something so that I get some benefit. And that template, in the “as a,” it seems to call for one answer there. And for me, I’m always looking at the product from the perspective of multiple personas or different kinds of people that would use the same functionality and have different concerns when they’re doing so.

Edwin’s question was, how do you story-map when you’re designing with multiple persona’s in mind? The story map is about the product and it’s about the experience. Gosh, it’s a little bit about both. You need one map because you’re going to build one product.

Initially, to get the shape of the map in place, I’ll think through it from the perspective of one persona and get the backbone and the basic shape of the map going, and the basic shape of the map starts to reveal the shape of the product. And then I’ll grab other personas with different concerns and walk through it from their perspective and see if it breaks it, changes it, does other things.

And to remind people that this product is for multiple personas, at the top of a story map, we’ve got big activities that break down into users’ tasks, and those break down into the tactical details of what we might build. Right above those activities or above sections of the map, I’ll post those multiple personas or hang them there, so that people can see, clearly, these big activities in this map serve these different personas, and they have different concerns.

Let me give one more detail here. Some folks that are building an application where multiple personas use the same functionality will go through and tag all the stories. They’ll tag their personas each with different-color dots, let’s say, and then go through and tag all the functionality that’s particularly relevant to one persona with that color dot.

This does a little bit of an analysis so that we can see that for these personas, they’re really concerned about this functionality; these personas are concerned with this other functionality. And we can see a bit of overlap that way, too.

Adam: So when you’re doing that research, how many users do you need to interview to know that you’ve got what you need to build the story map?

Jeff: Research is a troublesome thing for me. I’ll be honest with you. I came to doing what might be more rigorous user-experience work in about 2001. Before that, I was just spending a lot of time with users and building stuff, and I didn’t know that I was doing research. I would spend a lot of times with users using the software. Maybe I didn’t know that was contextual inquiry. So it wasn’t so rigorous. It was after 2001, when I dug in deep, that I started realizing, to be rigorous, I probably should be doing a few other things.

Now, if I fast-forward, I often find that organizations don’t do any research, because to do it rigorously takes a lot of time. So they go back to doing what they were always going to do, and they follow what I heard Jared call the MSU process, or “making stuff up,” only Jared didn’t use the word “stuff.”

Adam: [laughs]

Jeff: So, how many users. In working with some folks, for every distinct audience segment or role, I’ve heard general guidelines of three to 10 people. And it depends on how much variation there are in those roles, so if I were covering half a dozen roles, I might be interviewing lots of people.

However, one of the strategies I leverage when initially building personas and initially building story maps is to leverage tacit knowledge that’s in the room. Pruitt and Adlin talk about building assumption-based personas, and I build assumption-based story maps and assumption-based personas. By initially building a story map, we make clear what we do and don’t know, and then we can look back at this and say, “Gosh, where is our information hazy?”

Then let’s design a research plan that helps us not just learn about people. Since we’re modeling work or activity with a story map, my research plan can be very focused on the specific activities where I don’t know anything. And more importantly, if we’ve got businesspeople in the room, we’re looking for this intersection between stuff I don’t know and stuff that matters a lot, and that’s where we’re going to focus. [laughs]

Adam: Jeff, just a couple questions on nonfunctional requirements. And Ariadna asks, “If story mapping mostly concerns itself with functional requirements, how do you ensure that some nonfunctional requirements don’t fall between the cracks?”

Jeff: That’s a great question, and that’s a great question that’s applicable in any software-development process or any scheme to try and get your head around what requirements are for what to build.

So I don’t know if I have any fabulous answers. And one of the shortcomings sometimes with user stories in general is, I mentioned the initial idea of user stories, where you write down something and have a discussion, and out of that discussion comes the details of specifically what to build, and over time, the goal is to get smaller and smaller stories so that we could build smaller and smaller things.

When you look at nonfunctional requirements, the things that automatically pop to mind for me are things like scalability and performance and usability and all those things that people call “ilities.” Security, which doesn’t end in “ility,” that’s one of those also. These are big, cross-cutting concerns. I don’t just implement the scalability story and call it done. They’re quality characteristics of the product, just as usability is.

You don’t measure usability on a single check-box. It’s not necessarily sensible to if we’re concerned about usability of someone accomplishing a whole task.

So, let’s track back. Those sorts of nonfunctional requirements, yeah, we don’t want to lose them, but they’re cross-cutting. They’re big. I find that the story map helps me a lot because they’re often activity-centric, and the story map reveals what those are. So I might have particular scalability and usability and performance concerns in one particular activity and a lot lower scalability-usability-performance concerns in another. One of the things I’ve done personally is go up to that activity level and document or record stuff at that level.

As Ariana asks, how do you keep them from falling through the cracks, or falling through the story so to speak, oddly, it’s not easy to make them stories. They become concerns that we constantly pay attention to during development. We constantly do things to measure usability, maybe by testing, measure scalability by testing, except different kinds of testing.

Then, as we encounter problems, that’s when we get these more emergent, tactical stories that we inject to fix things or make things better. I document the concerns up at the activity level, and I would pay close attention to them during development and inject stories to correct problems as I find them.

Adam: One of our attendees acknowledges that he understands how you break stories into smaller chunks and chunks that you can develop in shorter time frames, but how do you do the same with those usability tasks that encompass full systems, like ease of use?

Jeff: [laughs] I’m looking at Eduardo’s question, and he also has a cool term after that. He says “confusability,” which is a term I’m going to use from here on out. [laughs]

Usability is a nonfunctional requirement. It’s a nonfunctional requirement sometimes. Some people are more focused on the technical nonfunctional requirements, but things like usability is a strong one. And just like other nonfunctional requirements, they’re big. Like Eduardo points out, they’re not localized to a little story.

We have to look at them as a cross-cutting concern. And it’s during this iterative and incremental development, we have to keep asking, “Is this activity usable?” And we add more stuff to it: “Is it still usable?” And we add more stuff to the software: “Is it still usable?” We keep checking that stuff over and over again.

And exactly how and where that goes in Agile software development, and exactly what story card it gets written on, well, there’s no set answer for that, and there’s no one story card it goes on, and it’s not so simple. I find that you’ve just got to keep your head engaged [laughs] while you’re doing this stuff. And again, back to the previous question we talked about, I like documenting those concerns at the activity level, and I like testing for those concerns at the activity level.

Adam: One last question, Jeff, and I know that you and I talked about this one as we were kind of mapping out this podcast. And it’s a bit broad, possibly vague and tough to answer out of context, but I’m going to ask you to give it a shot because I think it’s important for our audience. This technique of story mapping, how do you scale it to different-sized projects?

Jeff: [laughs] When we were talking ahead of time, I winced a little bit, because I get asked this question all the time. I find that different people who ask “How do you scale?” mean very different things.

So when we look at scale with respect to different-sized projects, I hear some people mean we have a lot of people working on this project. In some contexts a lot of people means 20, and in some contexts a lot of people means 200. I know some organizations where they put 20 people on the project, but those 20 people are spread across five different countries.

Scale, for them, isn’t big in terms of number of bodies; it’s big in terms of number of time zones. I hear people talk about scale in terms of how big the product is: “This is something that’s going to take a year-plus to build, and it’s going to take dozens or over 100 developers to build it.” Scale means a lot of different things to different people, and it has to do with size of teams, size of product, geographic distribution, lots of other things.

So, given all that, given the question, my first question is usually to ask people back, what do they mean by scale? What I tend to find, though, is, for big products, for instance, it becomes difficult to build a story map for the entire product. That’s tough.

I’ll find I’ll end up building a lot of local story maps. We’ll break a big product down into separate problems and then map that problem and look at a single experience or a single activity. And I might create a big map for the entire product, but create it at a higher abstraction level. And it becomes more informational. It becomes not tactical. I don’t use it to find the detailed stories to push down to individual teams. Rather, I use it as some way to connect individual pieces that are going on with different teams or different groups of people.

And then one of the questions we answered in the online seminar and I always get asked, what about geographically distributed teams? That’s always an element of scaling also.

At the beginning of this, we talked about these different activities that revolve around a story map, and one of them is initially constructing it and filling it in and doing some planning. I find that nothing beats getting a core, small group of people to initially build that map, and getting them together face-to-face to do that. And even in big, geographically distributed teams, it doesn’t work to get a big group of people together anyway to do it. Get a smaller group of people together, and then the problem becomes, “How do I socialize that with a lot of people?”

And you get excellent story-map visualization practices, like Todd Warfel’s Task Analysis Grid. I don’t want to claim Todd Warfel’s practice as a story-mapping practice, but gosh, that Task Analysis Grid is a perfect representation of a story map that also conjoins a lot of the missing context that’s not always in a story map, like users and where they’re using it and pain points. There’s a lot of great things in that.

If we’ve got a large team, oftentimes it’s a small team that builds the map, and oftentimes we then need to build something that’s more of a design-communication version of a story map, to share that with other people.

Adam, I’ve hit a number of different elements of scaling, and we could probably go deep into that for a while, but it’s a sticky subject.

Adam: Well, Jeff, thanks very much. It was a lot of fun, and I appreciate you circling back with us. To everyone listening in, thanks for joining us and for your support of the UIE Virtual Seminar program.

Even though every designer we talked with had completely different backgrounds, training, and work habits, they all shared one common element—they sketched their work. In addition, they weren’t just sketching their designs. They were sketching their notes in meetings, their conversations with their co-workers, and their understanding of their design research. Sketching was a common medium for a variety of design-related activities.

In this issue of UIEtips, we look back at an article from a year ago. We take a tour of the different activities and the sketches we saw during our research. These sketches solve a multitude of important design problems and are key to becoming a design master. I’m sure you’ll find this as interesting as I do.

Read the article, Why We Sketch.

One of the most popular workshops at last year’s User Interface Conference was Good Design Faster. The workshop had a strong sketching component. Once again we’re offering this workshop, taught by one of its original creators, Brandon Schauer. On November 9 at the User Interface 16 Conference, Brandon will show you how to bring out innovative design ideas in record time. Explore Brandon’s workshop and the 7 other fantastic workshops at UICONF.com.

How do you use sketching in your work? Is this something new or something you’ve been doing for a while? We’d love to hear about your experiences below.

I’ve seen my share of really great designs. However, I’ve also seen many bad designs.

Yet, interestingly enough, I’ve never met anyone who wanted to make a bad design. Nobody said to me, “I’m trying to build the suckiest design out there. Something people will really hate.”

Behind every bad design was a team that wanted to do the right thing. They wanted to make their designs a success. It just didn’t work out that way.

Almost always, it was because something was missing. The designers didn’t know what it would take to get a great design.

Often, they thought they knew. They thought they had the right mix of savvy and intuition to make it work.

Good design, it turns out, is harder than just being a smart guy. You have to know who your users are. You have to know what your users need. You have to know what your technology can and can’t do. You have to know what will truly delight the people you’re designing for.

It goes beyond just knowing stuff. You also need to do stuff and do it well. You have to draw on the language of interaction. You have to experiment and prototype. You have to interpret the feedback you receive and adjust your thinking.

What the folks creating bad designs are missing is good knowledge and skills. Without these, they produce crappy designs.

The good news is we now know, thanks to a ton of research in recent years, what much of the knowledge and skills are. We know how to take designers who regularly produce bad designs and turn them into designers who produce good designs, and eventually, great designs.

It’s a great era to be a designer. There’s so much to learn. There’s so much to do.

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

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

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

Here’s an excerpt from the podcast.

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

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

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

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

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

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

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

Full Transcript.

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

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

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

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

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

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

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

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

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

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

Jared: Exactly, exactly, yeah.

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

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

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

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

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

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

Hagan: Yeah, don’t touch it.

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

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

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

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

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

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

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

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

Hagan: I love that.

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

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

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

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

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

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

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

Hagan: I think that was all deliberately mispronounced.

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

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

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

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

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

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

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

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

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

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

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

Hagan: What guy? What girl?

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

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

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

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

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

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

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

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

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

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

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

Hagan: It's just too generic.

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

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

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

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

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

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

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

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

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

Hagan: Yeah. That'll translate well.

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

Hagan: Ew. [laughs]

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

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

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

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

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

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

Hagan: Wouldn’t that be nice?

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

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

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

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

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

Jared: That’s interesting.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Jared: Sixty four percent of words are spelled correctly.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hagan: Thank you.

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

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

I don’t decide to leave out the baking soda (even though I don’t really know what the baking soda does). Nor do I decide to cut the sugar in half (even though I think lots of sugar is probably bad for me). Why? Because if I did those things, the cake wouldn’t come out well.

This is exactly what we see teams do with their persona and scenario projects.

We see a lot of teams trying to create them. Building out solid personas is a great way to create innovative user experiences, when done well. Yet, many teams choose to sabotage their persona projects, producing something that doesn’t do the job and wastes valuable resources.

There are many recipes for great personas, yet the teams decide to take shortcut, skip steps, or just plain do something that doesn’t make sense. They don’t follow the recipe. Then they complain when the project doesn’t turn out well. And they lose the value that comes from a well-executed persona project.

In this today’s UIEtips, we explore five ways that teams we’ve studied sucked the value away from their persona projects. They seem like obvious things to do right, yet these teams opted to go another way, and then didn’t see the value they were hoping for.

Read the article, 5 Ways To Suck Value Away From Your Persona Projects.

At the User Interface 16 Conference, we’ll be exploring ways to get the most from your design projects, including persona techniques. Kim Goodwin will show us how to get huge value from creating great scenarios to drive our designs. And Steve Portigal will show us how to use field research to uncover insights and produce solid innovations. Check out UI16.

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

Employ Simple Show and Hide Techniques

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

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

Toggle Wireframe Annotations

Add notes to your interactive design.

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

Fake Simple Ajax Interactions

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

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

Get Started with JQuery UI Widgets

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

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

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

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

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

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

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

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

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

Here’s an excerpt from the podcast.

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

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

Listen to the podcast to hear Bill address these points:

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

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

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

Full Transcript.

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

Bill, welcome.

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

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

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

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

Jared: Oh yeah!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Jared: [laughs]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bill: That’s right. Yeah, exactly.

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

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

Jared: Oh, cool.

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

Jared: Very cool.

Bill: [laughs] It was a joke.

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

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

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

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

Jared: [laughs]

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

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

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

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

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

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

Jared: I think it will.

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

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

Bill: [laughs]

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

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

Jared: Excellent.

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

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

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

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

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

Here’s an excerpt from the podcast.

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

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

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

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

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

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

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

Full Transcript.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[laughter]

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

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

[laughter]

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

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

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

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

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

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

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

Jared: But I really like that first idea.

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

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

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

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

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

Jared: Exactly, exactly.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Brandon: Who knew?

Jared: Yeah. Awesome.

Brandon: Living up to the value prop.

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

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

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

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

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

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

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

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

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

Here’s an excerpt from the podcast.

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

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

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

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

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

Do you have experience conducting field research? Share your thoughts in our comments section.

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

Full Transcript.

Jared Spool: Welcome everyone to another episode of the SpoolCast. I am very excited today because we get a chance to talk with one of my favoritest people on the planet, Mr. Steve Portigal. Steve, how are you doing here?

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

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

Steve: DOING. Yes, I know it.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Steve: Isn’t that called AB testing?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Jared: [laughs]

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

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

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

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

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

Jared: Right. [laughs]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Jared: Right. [laughs]

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

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

Steve: Agreed.

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

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

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

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

Jared: See, I thought it was just me.

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

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

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

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

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

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

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

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

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

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

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

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

Steve: That’s so true.

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

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

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

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

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

Jared: [laughs] “Metamorphisical.”

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

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

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

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

Steve: Thank you.

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

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

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

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

Here’s an excerpt from the podcast.

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

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

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

Tune into the podcast to hear Kevin address these questions:

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

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

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

Full Transcript.

Jared Spool: Hello everyone. Welcome to another episode of the SpoolCast. I’m Jared Spool. I’m your cruise director for the day.

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

Kevin, how are you doing?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Jared: I think that’s really neat.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kevin: Yeah. Exactly.

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

Kevin: It was my pleasure.

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

The same can be true in an Agile development process. Often times, the team will start with a piece of the project that isn’t the first thing the user experiences, but instead might be at the end.

In this week’s UIEtips we are revisiting part one of an article we published by Jeff Patton in 2008 on his 12 Best Practices for UX in an Agile Environment. Jeff has been working with Agile teams and user experience professionals to discover the best methods to work together to create great results.

Jeff mentioned that user experience designers on the Agile team end up adopting a similar role to the person who gets the credit of “Continuity” in a film. It becomes their job to make sure the final experience makes sense, even though the order of construction was not linear. This is a huge challenge and one that has come to the forefront as more teams move to an Agile development method.

Read Jeff’s article 12 Best Practices for UX in an Agile Environment – Part 1.

Jeff is also presenting our next virtual seminar Story Mapping for UX Practitioners: Tying Agile & UX Together. If you work in an Agile environment and you’re struggling to weave UX thinking and principles into the iterative process, you’ll definitely want to attend this seminar.

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

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

You’ll learn:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Get Jeff’s Agile Primer:

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

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

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

Here’s an excerpt from the podcast.

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

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

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

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

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

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

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

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

Full Transcript.

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

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

Stephanie Sullivan Rewis: Good. Hey Jared.

Greg Rewis: Doing great, Jared.

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

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

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

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

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

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

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

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

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

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

Greg: And rounded corners.

Stephanie: And drop shadows for everything.

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

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

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

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

Greg: That’s true.

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

Jared: Exactly.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Greg: And you should.

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

Greg: But I do.

Stephanie: However, Greg likes to do those things.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

That makes it even more exciting, I think.

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

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

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

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

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

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

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

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

Stephanie: I adore Modernizr.

Greg: See? I told you.

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

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

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

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

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

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

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

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

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

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

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

Greg: Told you.

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

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

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

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

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

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

Stephanie: Change the color of the text.

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

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

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

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

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

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

And