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.

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

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

The Role of Hands

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

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

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

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

Bring in the Brains

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

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

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

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

Why The Difference Matters

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

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

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

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

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

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

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.

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.

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

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

Handwork and Brainwork

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

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

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

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

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

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

Hiring Hands and Brains

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

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

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

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

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

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

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

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

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

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

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.]

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

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

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

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

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

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

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

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

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

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

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

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

Everyday, more companies are recognizing the value of design. They are realizing they need to have strong design to compete in the marketplace. They see their competitors, even the small ones that don’t offer as full a feature set, are eating away marketshare because they have better designed products.

No place manifests this more than Silicon Valley. Designers, especially good ones, can call their shots there. Companies are in a bidding war for talent.

That means, if you’re a good designer, you have to ask yourself: are you in the right place, right now?

Milton Glaser gave a speech a few years back. He talked about two types of relationships: those that energize and those that exhaust. Milton said he learned, the hard way, that he needed to regularly prune away those relationships that exhaust, focusing on the ones that energize. That was his advice to happiness.

If you’re a good designer, are you in a place where your work energizes you? Or does the organization you work for exhaust you, because it hasn’t realized how important design is to its own success?

Now, it’s not that every day will be free of frustration. But if you’re regularly energized, it’s much easier to face the tough challenges. When you’re exhausted by your work every day, the challenges often feel insurmountable.

When a company doesn’t get the importance of design, it’s rough being a designer there. You constantly have to explain what you do. You have to fight for the simplest things, like the time and resources to do research (and often fail). You see, everyday, how your work could be so much better if you had the right tools, the right support, and enough time to make it work.

It’s scary to think about change. But right now, the timing is right for designers. If the job you’re in isn’t the right one, you owe it to yourself to look at what your options could be.

If you decide you should explore the world of opportunities, think about what you’d want in your next job. A company that values design will push off a ship date because the product’s not well enough designed. Ask if the company has ever done that — that demonstrates whether they have their priorities aligned with yours. Delaying a launch is a hard call. Having done it means they are serious.

Look for other evidence they understand design. Do they take the time to do research? Is everyone in the team involved? Do they iterate frequently? Are they learning good things from each iteration?

These are the signs that a company wants to learn what the best designs are. That yearning to learn makes the workplace really exciting for designers who are innately curious and autodidactic.

It’s a good time to be a designer. Every day should energize you. Are you doing everything you can to make sure that happens? After all, you owe it to yourself.

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

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

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

How to get the free recordings?

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

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

She’s been a designer for a long while now, having worked on some impressive projects and developed real skills. As she described the different projects, I could tell, however, that something was missing: how would she grow?

Don’t get me wrong. Each project was pretty neat and jam-packed full of cool challenges that every talented designer would want to sink their teeth into.

I suggested she direct her search in a different direction. I told her to focus on who her next manager should be.

In my job, I get to meet a lot of great designers, some of whom are working on projects that, to an outsider, might be considered dull: accounting applications, chemical analysis equipment, and even tax forms. Yet, they love their work, not because of the subject matter of the project, but because they have a great manager that makes every day fun and challenging (in the good way).

I’ve also met designers who are working on some of today’s sexiest design problems — working with the latest technologies on cutting edge, high visibility, society-changing designs. And they’re miserable because they have a manager that makes each day hard and frustrating.

When you have a great manager, the project barely matters. And when you have a crappy manager, the project barely matters.

The advice I’m giving to senior, more experienced folks is not to think about their next project as much as they think about their next manager. What traits should that manager have? How do they support their team? When things get rough, how do they deliver guidance? Do they regularly give out praise? Do they take a deep interest in the work and in their employee’s future?

I recommend folks interview the entire team and learn what it’s like to work for that manager. What happens when the going gets tough? What examples are there of team members growing, learning, and getting encouragement? Do team members talk about how the manager exhibits the desired traits?

My good friend, Amy Jackson, who works as a talent agent for wünderkind UX designers, suggests you take it a step further and ask the hiring manager for his or her references. Amy says to tell them you want to make the right decision and you need to check them out. Her thinking is that if the hiring manager isn’t secure enough give out sound references, they may be sending a signal. I think there’s something to that.

Great managers are what make a job great. Are you thinking about what you’d like to see in your next manager?

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.

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.

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

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

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

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

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

See the other UI16 Spotlights:

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

These experts will dive deep and get to the nitty-gritty details that make any designer a UX pro. Look at the intensive full-day workshops we’re putting together for you.

• Brandon Schauer: Immerse your team in an innovative design process that produces refined design ideas in record time.
• Kevin Hoffman: Facilitate productive and insightful kickoff workshops to start your projects with everything you need.
• Hagan Rivers: Employ best practices to simplify your most complex applications with state-of-the-art UI techniques.
• Steve Portigal: Drive your design with effective field research to deliver innovative results.
• Bill Scott: Discover the latest rich interaction techniques for engaging user experiences.
• Kim Goodwin: Compose compelling stories that drive a realistic design process from start to finish.
• Stephanie Sullivan Rewis and Greg Rewis: Enhance your designs with HTML5 and CSS3 without sacrificing your design goals.
• Luke Wroblewski: Integrate mobile design’s best practices and techniques into your process.

Get more information on the workshop topics and speakers at UICONF.com.

Details on the Sneak Preview Site

In the next few weeks, more details about the agenda and workshop will emerge. However, you can get a view into our special sneak preview site now.

And because the site is in the sneak preview mode, we’re offering a sneak preview price – our lowest price, of $1,349.

On Wednesday, July 27 at 1:00 pm, registration will open.

There are 100 spots available at the special low price of $1,349. Once they are gone, they are gone and you’ll have to buy one of the more expensive spots.

There is a way to get a jump start on registration, and learn about exclusive offers and the latest UI16 news. Add your email to the UI16 list at UICONF.com and you’ll automatically get added to the priority group.

Now go see the 8 different design workshops we have in store for you at UICONF.com.

“Hi. I’m a designer at [a big deal company] and I’m considering leaving. The problem I have is my employer has made it very clear I can’t use anything I’ve done here in my portfolio. What should I do?”

The work product lockdown is something many designers face, as they grow their careers and try out new opportunities. It’s natural that prospective future employers will want to see what you’ve done. It’s hard to show them when your designs, sketches, and deliverables are locked up behind a corporate non-disclosure agreement.

In future posts, I’m planning on talking about what people can show in their portfolio if they don’t have work products available (or even if they do), and what the best hiring managers look for when reviewing a portfolio.

However, today I want to talk about this from a different angle: Making it part of the hiring agreement.

I think every designer (especially every experienced, senior designer) considering a job at a new organization should ask explicitly about the hiring organization’s policy on including the work in future portfolios. Their answer should be on the table and negotiated, just like salary and benefits.

When should you ask?

In any hiring process, there’s two stages: The first stage is when you, as the candidate, get the hiring manager and company to fall in love with you. It’s all about showing what you can do and how you’ll help them achieve their goals for the position. You’re goal in this stage is to get the company to think you’re the most awesome person ever for their position and they should jump through every hoop to get you on board.

The second stage is when the company gets you to fall in love with them. Their goal in this stage is to prove to you that they are the best place ever.

It’s in the second stage that we can talk about the portfolio, between when they fall in love with you and when you are deciding the job is the right next step. It’s quite within the rules to say, “What’s your policy on employees including screen shots, sketches, and other work deliverables in their portfolio?”

The hiring manager may not know. It may be something they’ll have to ask HR or even the legal office about. At small companies, they have never even considered the question because you’re the first to ask.

However, it’s a really fair question. And, frankly, any answer is a fair answer.

They might say they want to protect their designs from getting in the hands of the competitors. Therefore their policy is to refuse permission to publish work (especially unreleased design work).

Public companies, who have trouble when future plans are leaked, thereby creating a possibility of “insider information” getting out, are very likely to refuse this without including a Safe Harbor statement. (A safe harbor statement basically says that investors shouldn’t use the information as any indication that the company intends to do anything with it.)

Or they might say they have no problem with you putting the documents into your portfolio, but they’d prefer that you don’t put it in a publicly accessible place, like a web site that anyone can get to. They might like you to only show it to people on an as needed basis, asking those individuals to not share it beyond their own team.

Ideally, they come back and say it’s perfectly fine. There’s not reason you can’t take your work with you as you grown your career. (After all, they benefited from your previous employer’s generosity in this matter. Pay it forward.)

Any of these answers are ok. The point isn’t that you badger them into heading in a direction that they aren’t comfortable with. The point is they tell you, up front, before you take the job.

Once you know, you can decide if this is a deal breaker or not. The fact that you asked tells the hiring manager that it’s an important detail to you. That you’re thinking about your long-term career.

(Of course, one argument is that it sends a message that you’re thinking about leaving the company even before you got the job. Personally, I think that’s ok. In this day and age, we don’t expect life time employees. Any company in denial of that fact may not be the kind of place we want to work. It’s good for an employer to realize that each employee has a choice to stay or go.)

As a discipline, our goal is to bring awareness to the hiring companies. To let them know that this issue is an important one for many professionals.

We’ll know we’ve succeeded when hiring companies start putting their openness to including work products in portfolios into their recruiting ads. When they cite unlocked work products as a benefit of choosing them to work there, we’ve arrived.

Then, someday, this will disappear as an issue, as it becomes part of the standard way we all do business.

As I suggested in my post on special collections, I think there is something to Lean UX. It was created as a response to Lean Startups, a movement that I think has merit too.

Lean UX is about reducing deliverables and moving towards thinking about the design. While there are no new skills to add to our UX skill list, there’s a line of thinking that is special to Lean UX that you don’t see when people aren’t practicing it.

Primarily, it’s about getting the UX practice as close to the development cycle as you can. It tends to focus on building working prototypes and getting feedback quickly.

Of course, regular UX has always wanted to have fast iterations, but the waterfall approach of specifying design requirements and working out complete designs before coding starts has been pervasive in many organizations.

The deal is that startups can’t afford a lot of “thinking” time associated with a waterfall-esque design process. They have a limited runway (the time it takes to launch a product) and they need designs fast.

Before Lean UX, the startup method of design was to just take whatever emerged from the architecture of the system. Developers were frequently creating the screens themselves, often without any consideration for what we’d call “design.” Their goal was to get something – anything – up and running as soon as possible.

Lean UX says, “we can help get something better.” It brings a deliberate design ethic to the startup process. However, it has to live within the limited runway environment, therefore it can’t be expensive and time consuming. Designs have to come quickly.

Someone who has spent time designing in this world will develop experience and knowledge that’ll provide value. UX professionals that haven’t had a chance to gain this specific flavor of experience will struggle in the startup world.

Interestingly, I think we’ll see a lot of what happens in lean UX environments feeding back into our thinking in non-lean environments. Hopefully, we’ll start to question the footprint of our processes and ask which deliverables are really necessary. Maybe the real contribution of lean UX is making us all aware of how un-lean much of our work really is.

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

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

That was it. Beans up the nose. Really.

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

The idea is blindingly simple, actually. Every so often, you’ll run into someone with beans who has, for no good reason, decided to put them up their own nose. Way up there. In a place where beans should not go.

Now, there is no logical explanation for this. There is no way to say, “Yes, I can see exactly why you’d want to do that.” They came to this decision all on their own. The way they got to this decision defies logic.

Yet, here they are. Waiting for the moment when the bean goes up the nose.

And here’s the thing: As an observer of this decision’s outcome, all we can do is cringe. We can try to argue. We can explain in the utmost rational terms why this is a bad idea. We can physically grab their arm and shake the bean from it.

Yet, if they are intent on sticking the bean up the nose, up the nose it will go. There’s nothing you can do to stop it. Pure and simple.

I’m sure you run into them all the time. You’re in a room and someone with power has decided to do something that just doesn’t make sense. You’ve tried logic. You’ve tried rational discourse. Yet, they are intent.

Beans and noses. We have beans. We have a nose. They must be united.

Time and time again, I come across situations where I think, “OMG! They are trying to stick beans up their nose!” It explains what’s happening and what I should do next.

The only thing I can do in a beans-and-noses situation (notice my clever use of flight-attendant grammar forms?) is wait. Wait until the bean is in its final resting place. Then, with a calmness only seen in yoga instructors, I can turn the nose owner and ask, “So, how is that working for you? Did it do everything you’d hoped?”

Of course, if they answer they enjoyed it and it was wonderful, then they are not someone I can relate to or help in any way.

However, if sticking a bean deep into their nostril doesn’t meet the very high expectations they’d had, I can now start talking alternative approaches to reaching those expectations.

Often, when I see an oncoming beans-and-noses scenario unfolding before me, I’ll ask about those expectations. How will they know if it’s successful? What will life be like once the bean is firmly implanted?

Maybe, by talking about the outcome, they might see alternative ways of achieving it that won’t result in the misery that comes from a nasal-based legume implantation experience. They might realize they have choices before they commit the act.

That only works half the time. The other half, the bean starts its wayward journey.

That’s when I move on. I decide I can’t be of further help and go take my skills, experience, and knowledge to others. Others that aren’t about to stick beans up their noses. There are plenty of those. And it’s much less frustrating for everyone involved.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

See you there!

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

To understand what it takes to create great designs, we’ve spent time with dozens of teams, some of whom are great at getting creative engaging designs out the door. And some that, well, could use a little more practice. Or something.

And we now have a handle on what that something is. In today’s UIEtips, I talk about an important difference between the best and not-so-best teams. Read the article to find out who should be on your team.

What are you doing to keep your team as productive as possible? How are you embracing your extended design team members? Leave your ideas and thoughts below.

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

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

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

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

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

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

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

Interestingly, it isn’t the designers who get to decide if coding is a valuable skill. It’s the hiring managers. And right now, based on today’s jobs market, it’s pretty clear where they stand. Many want to hire super designers—designers who can also code.

While hiring super designers has always been floating around, the real demand has come recently out of Silicon Valley startups. With a couple of high-profile design successes, like Apple and Mint.com, the investors and entrepreneurs in the Valley now have a new appreciation for the work of designers.

Startups, however, try to run as lean as possible, so they look for talent with a broad set of skills. The thinking among the Valley folk is, if they can get someone who does both, they can get their product from concept to ship with an ideal set of resources. Otherwise they’d have to hire two people. Or do without one.

We’ve proven for years that you can ship a product without a designer. Many companies have done that, and while it doesn’t make for a great result, it does ship. However, it’s much harder to ship a software product without a coder, if not near impossible.

That’s why, right now, there are dozens of startups looking to pay big bucks to find the coding super designer. The demand is high and those designers who have proven, practiced coding skills can demand a higher salary than those who don’t.

What about the non-startup portion of the hiring world? Right now, the established organizations find it easier to have larger teams with separate developers and designers.

Yet, that doesn’t make the designer that can code any less valuable to them. A team with two coding designers is more flexible and capable than a team with one non-coding designer and a non-designing developer. The flexible team can produce well-designed results better and faster.

Coding and designing are collections of skills. What we’ve learned is teams with a better distribution of skills, not segmented by roles, produce better results. Having a team filled with individuals who can both code and design will be more effective in the long run than a team where the skills are divided up.

If you’re a designer, you don’t have to learn to code. But if you do, and you get good at it, you’ll find more opportunities as time goes on.

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

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

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

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

Thanks to Pam and Luke for taking such great notes.

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

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

The Most Valuable UX Person In The World

She builds her wireframes with real wire from ancient hand-smelted Ukranian steel.
Her worst personas could kick the ass of your best personas.
His pattern library is now in the Library of Congress.
When she explains good design visuals, the only thing Edward Tufte can add is “What she said.”
He’s organized his wine cellar in order of awesome.
Wikileaks is ready to release her sketchbooks just because they’re cool.
He only sketches on the front of the napkin.
He built the world’s biggest web site, using only his left hand.
Last season’s American Idol featured her concept maps.
His research finds customers desire to research his behavior.
He is the only person Don Norman agrees with.
She makes her own icons out of straw.
Software bugs specifically ask for her to fix them.
He defined the damn thing, then moved on.
Her study participants screen themselves. Out.
Her interactions are the basis for everyone else’s designs.
Scalpers sell tickets to his project kickoff meetings.
He is already coding in HTML6. And has been for a decade.

They are the most valuable UX person in the world.
“Design well, my friend.”

What would you add to this list? Leave your own ideas of the Most Valuable UX Person In The World in the comments. I’ll be sprinkling your best suggestions through out my presentation, giving you full credit.

Oh, by the way, the early bird price for the Summit ends this Friday, February 18. Sign up here. I’d love to see you there.

The goal is to get great ideas on the table and to get everyone excited by the potential of this new undertaking. We want everyone to be heard and have a chance to get their thinking out.

In today’s UIEtips, I explore two techniques I often use to help me get team ideas out and on the table. They are simple to execute and powerful when done well. I wanted you to have a chance to try them yourselves.

Read the article, Equalizing Opinions – Two Simple Tricks for Meeting Facilitators.

When it comes to Kickoff meetings, we’re in love with what Kevin Hoffman has to say. He’s been exploring how folks bring their projects into being and has put together a collection of masterful techniques. You’ll want to tune in to Kevin’s UIE Virtual Seminar on Kickoff Meetings, this Thursday, February 3 at 1:30pm ET. See all the details.

What tricks do you use for getting everyone’s opinions out during your meetings? Share your techniques below.

On Monday, we published part 1 of an article by Kevin Hoffman, Kick Ass Kickoff Meetings. In the article, Kevin explains the advance work that should take place prior to the kickoff meeting, and the type of questions you should ask your stakeholders. You may want to read part 1 before reading part 2.

In part 2, Kevin dives deep into a plethora of exercises to use in kickoff meetings including a design studio activity. He also gives a list of suggestions on how a virtual participant can feel more present at the meeting.

Read the conclusion of Kick Ass Kickoff Meetings.

After reading part 1 and 2, you’re well on your way to producing kick ass kickoff meetings. But there’s one more resource that can help you. Kevin will be delivering our next virtual seminar on this very topic. He’ll share lots of great examples and the lessons the team at Happy Cog learned from one too many expensive and unproductive kickoffs. Learn more about Kevin’s seminar.

What do you do to jump-start the kickoff meetings and prevent them from being a ho-hum meetings? Share your thoughts with us below.

He invited all the key players from various departments. As they started filing into the room he started hearing murmurs of, “Here we go again, a useless kickoff meeting.” Eyes were rolling before the meeting even started, and half the attendees were checking their email, working on something else, or tweeting.

If only Joe had done his homework and read Kevin Hoffman’s article, Kick Ass Kickoff Meetings. Everything would have started differently.

Our good friend, Kevin Hoffman, contends that too many kickoff meetings squander the busiest, most expensive people’s time reiterating what everyone already knows. His challenge is that if every meeting is an opportunity, why waste your first, most important one?

In today’s UIEtips, were sharing an article Kevin wrote that caught our attention. We split the article into 2 parts. In part 1, Kevin explains the advance work that should take place prior to the kickoff meeting, and the type of questions you should ask your stakeholders. This article will start you down the path to better kickoff meetings.

Read the article, Kick Ass Kickoff Meetings.

It just so happens Kevin will be delivering our next virtual seminar on this very topic. He’ll share lots of great examples and the lessons the team at Happy Cog learned from one too many expensive and unproductive kickoffs. Learn more about Kevin’s seminar.

How do you prepare for kickoff meetings? What techniques do you employ to be sure team members leave those meetings full of ideas to explore? Share your thoughts with us below.

My thinking about Hands and Brains have come from a distinction between, in my mind, contracting and consulting work. We get a ton of calls at UIE to help people with usability and design work, but it’s clear after a few moments of discussion with the prospective client that they’re looking for contracting—someone to do the work for them and not for consulting—someone to show them how to get them to the next level.

UIE doesn’t do contracting, but lots of folks do, so I’m always on the lookout for people who are great contractors. Understanding the distinction is really important and I wrote the Johnny Holland essays to help create a language around the two types.

Apparently, I hit a nerve, because a lot of folks have been reacting to the piece in ways I didn’t expect. I wanted to take a moment and discuss some of those reactions.

What If I Do Both?

This seems to be the biggest reaction, by far. Someone who is an information architect, for example, says they are quite capable of doing both the Hands work and the Brains work. So, why should they have to choose one?

It’s true that you can be quite capable of doing both. However, most projects don’t want or need both. They either want Hands, because they don’t have enough resources and need the work completed. Or they want Brains, because they are stuck and can’t figure out how to bring their designs to a new level.

So, it’s important, when talking about a potential project to discover which one it requires, then decide, do I want to do that? Doing one basically traps you for that client—once they see you as Hands, you’l always be Hands to them. Same for Brains. It’s important to make your choice carefully.

Strategy Is Good, But Without Execution, It Fails

100% Correct. But that doesn’t mean the people who do strategy are the ones doing the execution. In fact, almost always, it’s the wrong thing to do.

The strategy has to include how the job will get done. The strategist has to know who will do the execution work.

Many Brains consultants will help find the Hands contractors/employees to get the job done. They’ll help build the team with those who are the most capable.

Execution is key but being the one doing the execution isn’t.

To Be Great At Brains, I Have To Master Hands

Absolutely. Brains have to know how to do the work of Hands. It’s gotta be second nature. They’ve got to understand how it’s done and what excellent work looks like.

However, once you start doing Brains work, it’s rare you’ll do that work again. You need to know what to expect from the Hands who will be working for you, but you won’t do it yourself.

Think of the executive chef in a restaurant. They have to know how to prep and cook every recipe. But that doesn’t mean they do that for every meal. In fact, it’s a bad use of resources and talent.

This is All About the Economics

Doing Hands work takes a long time, because it’s rigorous production work. Brains work doesn’t take as long, to deliver the same value to the team.

Hands work, because it takes longer, charges a smaller hourly rate. Brains work, because it’s shorter, charges more. Often two to three times as much (or more). Where Hands work might charge $50 to $75 per hour, Brains will charge $150 to $300 per hour. (Many really good Brains consultants charge a *lot* more.) A Hand’s engagement could last months or even years. Brain’s engagements rarely go beyond weeks and are sometimes only a few days or hours.

This is why, at the client, you can’t do both. If you try to do both Brains and Hands work on a project, you’ve got a rate mismatch. You’re either charging too little or too much for part of the work you’re doing. (And explaining to the client why you’re changing rates in the middle won’t be easy.)

Even if you love doing both, you need to decide where you’re want to focus. Go for the joy of seeing your work produced by delivering great Hands work. Have the excitement of creative big-picture problem solving with awesome Brains work. Pick your pleasure and go for it.

Amy responded to people’s enthusiasm with this interesting point:

“For me there’s also a difference between the act of curation (pulling disparate ideas together, making meaning and creating opportunities for experience) and being a Curator (capital ‘C’).”

I agree with Amy completely about the difference between curation and curators. However, this isn’t a unique pairing.

Amy was commenting on the difference between the skills and the roles. What we’ve found is that you have to separate the two, then, if you want to create great user experiences, ditch the roles and focus on the skills.

Amy continued:

“In my experience in museums, curators (at large institutions) tend to wear one hat and they are often seen as arbitrators of culture and taste and, with a few exceptions, slightly out of touch with the average gallery visitor. […] I love museums and think the curatorial role is crucially important; but it tends to happen in a bit of an ivory tower and is driven by the academic interests of the person filling the role, which may not necessarily be what the community wants or needs.”

Because of her museum background, Amy has obviously had issues with people in the role of curator. But that doesn’t mean curation can’t work. You shouldn’t blame DVD players for bad Jim Carrey movies, I always say.

The focus on roles happen when we’ve got a severely uneven distribution of skills across the organization. When this happens, we find the small group who have the skills necessary to accomplish something and we appoint them with the roles. Others, who have different skills, get appointed with other roles. The thinking behind this age-old approach is that if the person with the role can apply their rich skills to the problem, they’ll move the work forward.

But anyone who has been watching the World Cup this week has seen one thing: vuvuzelas are annoying as hell. Ok, that’s true, but there’s a second thing: if the ball comes your way, you kick it. You don’t say, it’s not my job to kick it, so I’m going to wait until my team mate with that role gets here.

To do this well, everyone on the team has to have basic skills. And to be in the World Cup, those “basic skills” have to be at the top level.

So, when we’re talking about a content strategy effort, there’s another approach that’s emerging from the organizations that are doing the best: everyone on the team has to have World Cup-class basic skills. They all have to know what it’s about and how to deal with the ball when it comes their way.

In terms of curation, you can’t have a single curator who going to do a crappy job, playing to internal politics, and focusing on their own goals instead of the users or the organizations. Instead, the entire team, under the auspices of good, focused leadership, curates the content. They work as a team.

To this end, if content strategy is going to succeed, the community needs to know how they’ll get every team members skills dialed up to world-class levels. Once they do that, they’ll see a world of difference.

No ivory tower or self-serving academic interests here. This is the real world, baby.

For the past 10 years, Jared Spool and our research team at User Interface Engineering studied the secrets behind successful teams and the factors driving their results. In late March, Jared kicked off the Web App Masters Tour in San Diego sharing this research with attendees.

Once again, Luke Wroblewski did a great job capturing Jared’s presentation. We’re reprinting Luke’s blog post from LukeW Ideation and Design.

Here is Luke’s take on Jared’s presentation.

In his opening presentation at the Web App Masters Tour in San Diego, CA, Jared Spool outlined how design organizations can deliver the holistic experiences Web applications users increasingly expect.

• It’s no longer about the application—its about the experience. When done well, good design is invisible. To illustrate, you only think about the air conditioning when it is not working.
• Web applications are at the intersection of user needs, business goals, and what the technology allows us to do. The design process is about compromise. We need to constantly make decisions that balance these objectives.
• Jared’s team researched 60 different organizations that created good user experiences. They found that size, organizational structure, process, management, etc. did not determine what drove great product design.
• Vision, Feedback, and Culture were the three elements that were consistently present in teams that delivered good experiences.
• Vision: can everyone on the team describe the experience of using your product five years from now? What is the design you are working towards?
• Feedback: in the last six weeks, have you spent at least two hours watching someone use your design or a competitor’s design? You need team members to have first-hand exposure to people using your product. Many teams don’t use the products they design.
• Two hours gives you enough time to see the subtleties and nuances of how people use products. It has to be recent (last six weeks) or else it is forgotten. Once you start to see the same problems over and over again, you focus and fix them. The best organizations do this weekly.
• You can gather feedback with usability testing, field studies, and first-hand persona development. But the key part is exposure. Try to increase hours and frequency. Don’t think in terms of number of participants—think in terms of exposure (hours and frequency).
• Design agents to impact experience: core team (makes the bulk of the decisions) and secondary agents (impact the total experience customers have).
• Culture: in the last six weeks, have you rewarded someone for a major design failure? Every failure is an opportunity to learn. When you celebrate failure, you get to ask some questions—what did we learn about our users, ourselves, our product?
• As the number of things people need to consider for Web applications has increased, the size of the teams has actually decreased.
• The best organizations thought in terms of people’s skills not roles. They worked on building everyone’s skills by giving people opportunities to learn.
• Curation and editing are key skills for Web application design. Need to be vigilant about removing what is not necessary. Curation is as much about what isn’t included as what is.
• Designing for embraceable change: when people learn to use something, it’s hard to change existing behaviors.
• The kitchen cabinet problem: people know what is in their kitchen cabinets. If we change where things are—people’s existing routines are disrupted.
• User assistance can help people through change.

You can hear more about the research Jared and the UIE team did, along with another presentation from Jared, Turning Back to the Future, at the Web App Masters Tour. The Tour continues in Minneapolis, April 27-28, Philadelphia, June 7-8, and Seattle on July 12-13. Learn more about the program at www.UIETour.com

Until April 29, register for any of the Tour cities for $795 when you use the promotion code TOURBLOG. Learn more about the tour at www.UIETour.com

Ken Kellogg’s podcast talks about navigating the design process within a large corporate world, and how customer research plays an integral part of new designs. Listen to Ken’s podcast.

In Christian Crumlish and Erin Malone’s podcast, they talk about the huge collection of social design elements in their book. Christian and Erin also cover social communities and where the growth of “social in” is occurring. Listen to Christian and Erin’s podcast.

Did you miss parts 1-3 of the interview series? We showcased these Masters:

• Part 1 – Julie Zhuo on how Facebook handles design changes. And Bill Scott taking a look at design patterns and rich interactions. Here’s the post to part 1.
• Part 2 – Hagan Rivers’ new approach to designing web app navigation. And Stephen Anderson on how to encourage user behavior with the design of your web app. Read the post to part 2.
• Part 3 – Jason Fried discusses 37signals’ design and development process. And Luke Wroblewski on how to make web forms less intimidating. Here’s the post to part 3.

If you enjoyed the Web App Masters interview series, then you’ll want to explore the Web App Masters Tour. It’s two days of inspiring presentations with a perfect blend of theory and practice. The Tour stops in Minneapolis, Philadelphia, and Seattle. Learn more about the dates and program at www.UIETour.com.

Until April 23, you can register for any of the Tour cities for $795 when you use the promotion code TOURBLOG. Learn more about the tour at www.UIETour.com

(Oh, and by the way, our last event sold out, so you’ll want to Register your team early!)

When you spend time with your customers, it’s an opportunity to learn how to move your design forward. You don’t want to leave important information “on the table”—information that can give you a more complete understanding of how to move your vision forward. You might act on incomplete detail that creates risk when it forces you to guess what the users need. Worse, the partial insight you have may take your design team in the wrong direction.

User research is an expensive endeavor. Make sure you’re prepared to get the most out of every minute that you’re with your users. Come home with a deep insight into their thinking, their lives, and how you can change their experience for the better.

Steve Portigal will show your team the art of asking the question. You might visit the user in their office or home, have them come to you for a usability test, or even have a chance encounter at a trade show or while waiting for an airplane. Do you know what to ask? Do you know what to listen for, to extract the critical detail of what they can tell you about your design?

Steve will help you prepare your team for any opportunity, be it formal user research or less structured, ad-hoc research. He’ll also give you tips on how to work with your stakeholders and executives, who may also be meeting potential customers and users, so they know what to ask and how to listen—integrating their efforts into the research team. (Wouldn’t it be great if they understood why you’re doing what you’re doing?)

Get your team asking good questions, the right questions, with this fantastic seminar. Honing this skill will be a great addition to their Toolbox. Register your team before January 19, with the promotion code TOOLBOX, and I’ll also send you the link to a fabulous webinar Kate Gomoll did for us, Field Studies: The Ultimate Tool in Your Usability Toolbox.

Are you prepared for meeting someone who could be using your next design? How do you make sure you get into their head, learn what their life is all about, and get the information you need to build something truly innovative and delightful? We’d love to hear your ideas and about your experiences below.

Julie Zhuo

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

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

Christian Crumlish

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

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

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

On January 7 Peter Morville will discuss Search Design Patterns, and in the same session, Mark Burrell will tell you how to then use them.

Later in the month, on January 28, Steve Portigal will present to you his thoughts on studying your users in their own context, Ethnography.

During last year’s UIE Roadshow, our audiences couldn’t get enough on the topic of personas. So, on February 18, we’ve asked Tamara Adlin to talk about The Power of Ad-hoc Personas. Personas can be your ticket to lasting organizational clarity… and it doesn’t take a ton of costly research.

With his book, Prototyping: A Practitioner’s Guide just hitting the bookstore shelves, Todd Zaki Warfel will help you flesh out your design ideas, test your assumptions, and gather real-time feedback from users on March 29.

In the Spring, look for Kristina Halvorson to help you with your content strategy and Louis Rosenfeld to dive deep on Search Analytics. And there is much more in the works.

Until December 3, you can still sign your team up for the UIE Virtual Seminar Subscription programs . Not only is it a tremendous savings, but you get the benefit of lifetime access to each recording and the ease of registering and paying just one time.

We also plan to unveil our plan for our User Experience Training Library. Believe it or not, there is a method to our madness.

Have you ever attended a UIE Virtual Seminar? What do you like best about them? How has your team maximized what it gets out of these learning events? Share your thoughts and experiences below.

Subscribe to our podcast via

How many IBM or General Electric television ads do we need to see before we are groaning at the mention of the word “innovation”? It’s too late for me, personally. But that doesn’t mean real innovation is dead. Steve Jobs has been quoted saying Apple will innovate their way through tight times. This past week Apple announced record revenues for the past quarter on impressive sales of premium products that aren’t supposed to sell well during down times. How are they flourishing while their competition is not?

How can you bring real innovation into your projects? That’s what I asked Scott Berkun when we spoke earlier this month. Scott is one of our favorite speakers on the topic of innovation and project management. He tells us you have to be opportunistic and start small. High-priority challenges may be a tempting place to start, but he suggested to first look at low-hanging fruit. You can build momentum for positive change by racking up a number of small wins that together move the project in the right direction. Having these small successes under your belt gives you more influence when attempting larger changes later on.

True innovation starts with you allowing yourself to be creative and recording your ideas religiously in a safe place like a notebook or sketchpad. Don’t self-censor, either. Initial precision and “getting it right” are the antithesis of creativity. It’s essential to let the ideas flow, and your ideas will improve as you continue to record them. Your journal is an incubator of ideas. Not every idea will be a success, and some will be terrible! But Scott says that’s OK. When an opportunity for change arises, you’ll have a treasure trove of ideas to pick though.

Once you have an idea, you need to involve other people to make it happen. The key differentiator in successful, innovative environments is group trust. People need to feel they are safe to share ideas with their team. If you work in an environment where you’re fearful of this, find one person on your team who is the most enthusiastic and try sharing with them. Once you have other people on board with your idea, you’ll have an easier time sharing it with others.

A common difficulty is honest and constructive critique among teams and individuals. This is an area where the most successful teams have excelled. Good critiques take practice and trust within your team. This usually requires time and commitment.

What experiences have you had trying to introduce new ideas? Politics and “we’ve tried that before” getting in the way? Let us hear about it in the comments.

User experience research lives or dies by the appropriateness of the participants in the study.

UX researchers just don’t talk about actively recruiting, do they?  Many researchers ignore it, throwing it over the wall to an agency. It’s complicated, time consuming, and nerve-wracking. In this UIE Virtual Seminar, you’ll learn four strategic steps to make recruiting a fun, useful, and interesting benefit to user research.

If you are involved with user research projects and spend any amount of time worrying about getting the right people in the room, then this UIE Virtual Seminar is for you.

Find out more about Dana’s seminar and register?

Or learn more about our usability testing bundle which includes two seminars and the UIE report, “Recruiting Without Fear.”

Tell us how you source and screen participants? What concerns do you have about the recruiting process? Share your thoughts, questions, and concerns below.

In this popular presentation, Ethan Marcotte teaches about the collaborative process through four detailed case studies. The case studies demonstrate important before and after detail of the lesson to be learned. They also happen to be major sites you know of and can visit today: The Today Show, The 2008 Sundance Film Festival, W3C, and New York Magazine.

If you’re a designer, a developer, or manage a team, you’ll want to see this presentation. Ethan will show you ways to be successful in critical project transitions. There’s no better person to see both sides of the designer/developer relationship than Ethan Marcotte. Many in our industry greatly respect him and consider him to be someone who does groundbreaking work. Ethan has worked with New York Magazine, Harvard University, Disney, and State Street Bank, just to name a few.

UIE Virtual Seminar
Comps vs. Code: Case Studies on Collaboration Between Site Designers & Developers
with Ethan Marcotte
Thursday July 30, 2009, 1:30pm ET
90-minute online presentation

Read more about Comps vs. Code, or see the 3-minute preview Ethan put together, to help you understand what to expect out of this seminar.

Using the model is easy. First, you ask a few questions to determine where the organization’s products are relative to their market maturity. The theory then tells you what recommendations are most likely to get attention.

For example, getting resources to conduct in-depth user research on users and scenarios is much easier in stage 3 (experience) than it is in stage 1 (technology) and stage 2 (features). In those stages, it’s easier to find a corporate champion for feature-focused, lightweight research.

This UIEtips contains part one of a two-part article on the Market Maturity model. I describe the first two stages, sharing how to identify if that’s where your team is, and what project priorities will make the most sense. I hope you enjoy it.

Read today’s UIEtips article.

The Market Maturity model is just one of several perspectives  I’m sharing at the upcoming UIE Roadshow: Secrets Behind Designing Great User Experiences. There’s still room in the Seattle, Denver, and DC full-day workshops. Register with the promotion code SHOW09 and get $75 off the price. 

Is your team dealing with stage 1 (technology) or stage 2 (features) issues? If so, what’s your strategy been? We’d love to hear your thoughts. Share them with us below. 

You may have noticed that the last two UIEtips articles concentrated on UX teams. The first article was on Building and Managing a Successful UX Team. The second article was Five Techniques for Getting Buy-In for Usability Testing. Following the rule of three principal, I’m focusing this next article, once again, on the UX team. Today’s article goes back to December 2007 and concentrates on various skills required for a successful UX team.

Over the last 9 years, we’ve been looking carefully at how to put a user experience team together. We’ve studied dozens of teams, some that are very good at production great designs, while others regularly struggle to produce anything that makes users happy. As we’ve looked at the differences between the teams, we’ve started to notice some patterns.

One emerging pattern focuses on the skills found in the team. While it’s a no-brainer to say that the more skilled the team, the better the results, it’s more difficult to hone in on the specific skills that make a difference.

Our research has isolated eighteen skills that the best teams all master. We’ve divided these into two groups: Core UX Skills that are unique to the user experience process and Enterprise UX Skills that the team shares with other parts of the organization, such as marketing, IT, and product management.

In this issue of UIEtips, I describe these skills and a simple method for assessing where a team is at. Managers can use this assessment to identify areas of improvements for the team as a whole and individual members.

Read today’s article.

Have you assessed your team’s capabilities? What techniques have you used? Are there skills you think are important that aren’t on the list? We’d love to hear from you. Leave your thoughts below.

[If you manage a UX team, or you're part of a UX team, I think you'll find our next UIE Virtual Seminar of great interest. This Wednesday, June 17, Sarah Bloomer will present Upgrading Your UX Team. Some of the topics Sarah will touch on in this Virtual Seminar include: the key ingredients of developing a successful UX team, how to setup your team, and where it fits within the organization. Learn more about the next UIE Virtual Seminar.]

Knowing how to identify and communicate the value of a User Experience project will gain you design strategy approval and support throughout the organization. Most organizations we work with understand the need for UX efforts, yet they still struggle with how to best incorporate the team into the development process.

Back in 2006, former UIE staff member, Christine Perfetti interviewed Sarah Bloomer and Susan Wolfe, two premier User Experience experts, to discuss how organizations can make their UX practices a success. I find this interview is still dead-on three years later.

One of the most frequent questions we’re asked is how do you go about setting up a UX team. What criteria should I use in the hiring processes, and how do I get executive buy-in on the UX vision?  To answer these questions, and many others, we’ve asked Sarah Bloomer to present our next UIE Virtual Seminar, Upgrading Your UX Team. We’re offering the recording of this presentation at no additional cost when you register with the promotion code MYARCHIVE.

Are you challenged with building a UX team within your organization? Is your team struggling to get support and buy-in from your organization? How have you gotten your organization onboard? Join the discussion below.

Want help in developing that solid strategy? We’ve asked Sarah Bloomer, a User Experience professional who’s helped several companies set up internal UX teams, to help you do exactly that. You’ll learn 4 strategies to deal with resistance to your team’s efforts. If management has difficulty understanding how the vision and strategy are shared throughout the organization, then you’ll definitely want them to attend this UIE Virtual Seminar. And don’t forget, if you have team members that can’t attend the live date, register with the promotion code MYARCHIVE to get lifetime access to the recording. Register today!

UIE Virtual Seminar
Upgrading your UX Team
with Sarah Bloomer
Wednesday, June 17, 2009, 1:30pm ET
90-minute online presentation

Sarah put together a great preview for you, to help you understand what to expect out of this seminar.
Click here to visit the site page with the preview.

In advance of the presentation, we’d love to hear from you. As a team member or team leader, what are your biggest challenges? What sort of resistance do you meet, and how do you overcome it? What is your organization’s culture like, and what opportunities exist there? We’d love to hear your thoughts, questions, and concerns. Please share your thoughts below.

All these questions are addressed in the conclusion of our series on top articles on Experience Design. If you missed out on part 1, we covered these articles:

• Market Maturity: A four-stage frame work based on where products are in the marketing place
• Top Priorities for Talking Horses: Three top priorities designers should focus on to make sure your their web site works
• The Road to Recommendation: Four steps to go through when creating a recommendation for change. 

In today’s UIEtips, we have four articles related to Experience Design. The first article, The 3 Qs for Great Experience Design, discusses three questions to help us determine if a team will produce designs that deliver great experiences. The second article, Getting the Most from Design Deliverables, looks at three goals when developing design deliverables. The third article, Designing Embraceable Change, addresses how to handle major design changes with your users. And our last article, Five Design Decision Styles. What’s Yours? explores different decision processes when developing designs.

As always, please share your thoughts with us. We’d like to know how you communicate your design deliverables, determine your design decision style, and hear how you communicate major change with your users? Join the discussion about this week’s topic below.

Looking to take your user experience team to the next level? Check out the UIE Roadshow! We’re excited to continue our new UIE Roadshow: Secrets Behind Designing Great User Experiences, a full-day workshop, based on 10 years of our extensive research. Register with the promotion code SHOW09 and save $75.

To help you understand what you can expect out of this seminar, Scott has put together a preview for you:

Don’t miss this presentation! Register with the promotion code THREEPOINTS and get both our lowest rate of $99, and lifetime access to the recording of this talk at no additional cost. Share it with others in your organization to watch whenever they want, as often as they want.

In advance of the presentation, we’d love to hear from you. How is failure perceived in your organization? When is the last time you celebrated a failure? Or do you think failure should be avoided at all costs? When failure does happen, how does your team address it, or is it the “white elephant in the room?” Share your thoughts below.

Determine if this seminar is right for you and your team by reviewing  Jared’s preview, just press the green “play” arrow.

As an added incentive to attend, use the Promotion Code MYARCHIVE to receive free lifetime access to the recorded presentation. You or anyone in your organization can watch it whenever you want, as often as you want!

Register Today!

In advance of the presentation, we’d love to hear from you. How does your team currently come to consensus, and how can you be sure the right decision has been made?  What criteria is used for your decision making?  How do you get everyone on board, and how do you overcome objections?  Share your thoughts below.

Several weeks later, I submitted Is IT Ready for Experience Design? I wrote this essay for IT managers and CIOs looking to understand what it means to create great experiences for customers.

Now, as a holiday gift, Cutter is letting me give our friends (that includes you) a complimentary PDF of the entire special journal issue, IT Usability: Bridging the Gap Between Machines and People. If you’d like to get it, just go to this page on the Cutter site and follow the instructions.

Warning: The Cutter folks ask for information before you download. I don’t know what they do with this, but I’m betting they use it for the forces of good and not to support the axis of evil. Proceed at your own risk. (It’s ok with me if Bill Gates downloads a bunch of copies. Not that I’m suggesting you falsify information. Wink. Wink.)

While the successful team needs all of these disciplines, there are more of them than most teams have members. This creates a challenge as teams need to spread the experience, knowledge, and skills across multiple team members, turning them from specialists into generalists.

In today’s UIEtips article, I share some of our recent findings in how teams make the call: when should they hire a specialist and when will a generalist work better? Whether you’re a team manager or someone looking to direct their career choices, I think our findings will interest you.

Read the article – Ideal UX Team Makeup: Specialists, Generalists, or Compartmentalists.

What does your organization do to embrace its failures? We’d love to hear from you. Share your thoughts below.

• Because of the economic downturn (due to the rising fuel costs and mortgage market crisis), some companies are laying off and some are disappearing outright.
• Because executives understand the competitive value of creating great experiences, user experience professionals are in great demand.

This convergence means you should have your resume and references up to date. Even if you’re likely only to change jobs within your current organization, having these prepared can make the difference between having a choice and missing an opportunity.

As a hiring manager, I often find people don’t really know how to prepare their references well. This podcast, from the fine folks at Manager Tools, does a great job of explaining how to recruit, prepare, and share your references. It should be a must for anyone who thinks they’d like to grow into a new job, either in the near or far future.

The podcast blurb:

This cast tells you how to handle requests for your references when engaged in a job search.

Even though “References Available Upon Request” is no longer a good idea, reference CHECKING is on the rise and will only increase in the coming years. It seems like since resumes don’t include the age-old line — the why of which we’ll share — somehow far too many job seekers are caught off-guard by reference requests. Ahh, Horstman’s Christmas Rule!

We’ll tell you how to manage and share your references in this cast. And hey, if you’re maintaining your network, this one is EASY!

Sharing Your References at Manager-Tools.com

Testing Your Critiquing Skills: Site Navigation
Date: Wednesday, September 24th, 2008
Time: 1pm ET / Noon CT / 11am MT / 10am PT

When looking over someone else’s design, how do you ensure you’re delivering valuable insights that bring new perspectives to the table?

The best critique not only delivers value to the original designer, but to everyone involved, because it raises the discourse to the underlying fundamentals and goals, not just the specifics of color and font size. Learning to critique well is like many other skills: the more you practice, the better you get.

You’ll know you’ve delivered a great critique when:

* The designer is receptive and engaged in the discussion, instead of being defensive and argumentative
* The designer becomes introspective and talks about how they want to revisit some of the underlying precepts of the design
* Other team members use the critique to look at other on-going work

You can read the full seminar details here.

“We’re struggling with how to measure how well we are innovating […] Are we innovating better this year than last year? How would I know?”

If you work in a larger company and you haven’t heard a statement like this, you’re going to. Innovation has become such a buzzword, it’s nearly meaningless. But that doesn’t mean innovation itself is dead. In this week’s show, we sat down with Scott Berkun, the dynamic speaker and author of “The Myths of Innovation.”

Innovation is critical, but it’s not being defined for those folks challenged with implementing it. Innovation is hard work. Scott asks that we face facts here; to find big, new ideas that will change things for the better will never be easy.

OK, how do we innovate? Scott suggests that the key word is risk. The best organizations (Google, Apple, Pixar and 3M are offered as examples) promote this through a culture where it’s OK to take risks, where failure is acceptable if valuable lessons can be learned. Whenever risks can be taken in a safe environment innovation is much more likely to be successful.

Often times middle management is actually the key to fostering this environment. They see the organizational “big picture” and can shield the front line workers who are challenged with focusing on the work. It allows for in-house entrepreneurship, allowing for creativity and flexibility outside of their traditional responsibilities. Google’s “20% time” is a popular example of time where employees can branch out on self-made projects. In Google’s case, it gave birth to products like GMail.

Innovation happens in both small and large organizations, but in large companies, it takes dedicated resources, and the expectation of some amount of failure. Scott has found that in organizations resistant to change, you can find success in pitching that innovation is the tradition of the company.

As for Innovation and User Experience, in the early design stage there’s a delicate balance between collecting data from users and knowing where to take calculated risks that may run counter to the data. When taking a different approach, don’t be afraid to step out on a limb. Then test to see if it works.

Of course, this is just a taste of the half hour discussion we had, so you’ll want to listen to the entire thing to get the most of Scott’s insights on the subject.

[ You can hear Scott Berkun speak more about Innovation at the User Interface 13 Conference in Cambridge, MA — October 13-16, 2008. The structure of his workshop, The Myths of Innovation: How to Lead Breakthrough Projects, will be broken out into the following:
• What does a breakthrough mean?
• Training from the history of great innovation
• Jargon and terms in the business of innovation, and how to deal with them
• Creative thinking
For more information about UI13, check out our conference site, UIConf.com ]

Does your organization foster innovation as well as it could? Share your questions and experiences with innovation in the comments.

In the June 2008 issue of the Harvard Business Review, there is a super article by IDEO’s Tim Brown on what it takes to bring innovation down to the execution. Tim’s solution: Design Thinking.

Tim tells us that Design Thinking is:

a discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.

Anyone who is immersed in UX design will find familiar comfort in Tim’s descriptions of how this works. There’s nothing new is how he goes about it. It’s just that he’s done a great job of explaining what we do in business terms that executives can understand.

For example, the Tim explains why prototypes are important to an organization’s understanding of the problems they are trying to solve through design:

Prototypes should command only as much time, effort, and investment as are needed to generate useful feedback and evolve an idea. The more “finished” a prototype seems, the less likely its creators will be to pay attention to and profit from feedback. The goal of prototyping isn’t to finish. It is to learn about the strengths and weaknesses of the idea and to identify new directions that further prototypes might take.

If you don’t have a Harvard Business Review premium subscription, it will cost you $6.50 to get the PDF of this article. However, if you are looking for a good way to help your senior management team understand the value of design, this article will be well worth it.

Access the Harvard Business Review Article, Design Thinking by Tim Brown.

It was a brilliant idea, if only Blockbuster had thought of it first. Five years earlier, a little west coast startup named Netflix came up with the idea of home-delivered DVDs. The little startup slayed the established consumer giant by delivering a new and innovative product.

Our clients regularly discuss Netflix’s story. They ask us how they can make their company’s products and services just as successful. Among our recommendations, we always tell these folks to read Scott
Berkun’s research on innovation. Scott, the author of the popular book, the Myths of Innovation, is the expert we recommend clients talk to when they’re struggling to develop innovative designs.

In this week’s issue of our email newsletter, UIEtips, we’ve asked Scott to share an excellent article he’s written on innovation. In his article, Scott offers practical secrets to help you build new and innovative products. I think you’ll really enjoy it.

Read Scott’s article: How to Innovate Right Now.

Are you challenged with creating new products that recreate and capture the market? Is your team struggling to develop innovative designs? Share your thoughts below.

Scott’s research on innovation has led him down the path of studying failure. In particular, why designers fail. You shouldn’t miss his upcoming UIE Virtual Seminar on Why Designers Fail and What to Do About It on April 14, 2009. Learn why you should celebrate failure.

What many people don’t know is that Flickr wasn’t originally a site for sharing photos. It was originally conceived as an online game, “The Game Neverending.” But when the design team started facing business obstacles with the game, they quickly shifted their priorities and recognized the value of the photosharing application. As a result, Flickr fundamentally changed the way we look at web applications.

At UIE, we hear all the time from clients working to build products and sites that capture the market, hoping to duplicate the success of sites such as Flickr. If you’re challenged with creating innovative designs, you’ll really want to read Scott Berkun’s writings on the subject. Scott is the author of the book, “The Myths of Innovation,” and an expert when it comes to the history of innovation.

Also, in this week’s article for our email newsletter, we’re republishing a great interview UIE’s Christine Perfetti conducted with Scott last year about his research in the area of innovation. This is one of our most popular articles. If you missed it, I think you’ll really enjoy it.

You can check out Christine’s interview with Scott here.

How does your design team go about developing innovative designs? Please share your thoughts below.

In this podcast, I had the pleasure of speaking with Sean Kane. Sean helped build one of the world’s most successful web applications as the Director of UI Engineering at Netflix. Last year, Sean left Netflix to co-found Get Listed, a start-up that is going to revolutionize the job search business.

Moving from a mature organization that understands the role of experience design to a brand-new start-up environment without any of the same infrastructure or support can be a real challenge. A challenge that is not unlike the challenge that many UX practitioners face when trying to bootstrap their user experience efforts in a growing organization.

I asked Sean to reflect a little on his previous experience at Netflix and about the challenges he’s facing at Get Listed. We started by talking about Netflix’s culture of metrics and the impact it has on their design. We then discussed the culture shock he’s experienced as he moved to this new gig. Finally, we talked about building both a web app and and a web app team from scratch.

It was interesting to see how the impact of his experience at Netflix is reflecting the decisions he’s making while shaping his new startup environment. I believe anyone who is building out their own user experience efforts will find Sean’s thoughts inspiring.

I think you’ll enjoy this podcast. We look forward to your questions and thoughts. Let us know what you think in the comments!

[Note: We had prepared this podcast to be released earlier this year, but due to schedule conflicts, its release was delayed. As a result, the intro mentions the very successful 2008 Web App Summit as if it's still to come. But don't worry: we'll have another one next year, so stay tuned!]

I’ve posted the slides above and have synched it up with audio from the conference. (Unfortunately, there was a mic-input problem during the recording and they ended up using the built-in mics instead of the sounds system. So, the recording is noisy and unintelligible in places. Sorry about that.)

Here’s the description of the talk:

Journey to the Center of Design

User-centered design was born in the 1980s, amidst a world filled with frustration with blinking VCR clocks and computer command lines. Up until this time, developers focused on making the devices work, giving little heed to how they’d be used. Terms like “user friendly” and “easy to use,” buzzwords for the UCD movement, soon became as common as “new and improved” on laundry soap.

We guarantee a journey that shouldn’t be missed.

| View | Upload your own

You can download the slides (without audio). On the Slideshare site, you can view this presentation full screen to see the details.

What do you think of this presentation?

This week, we have the latest installment of the SpoolCast crew (which we recorded back in December, and then got busy — sorry!).

Almost every company has to struggle with the balance between customer needs and internal business objectives. In this episode the crew examines the recent situation at Facebook. While trying to please both users and build a business model, the fast moving organization has stepped on many toes.

Our panel took a look at this delicate balance and how the future UX team at Facebook might help to resolve this. Facebook makes a fascinating business case from which to extract lessons, and we think you’ll enjoy it, too.

Returning to the crew this week was our foreign UX correspondent based in Hong Kong, Mr. Danial Szuc. Dan is the Principal Usability consultant with Apogee Usability Asia Ltd.

Joining the crew for the first time in this episode were special guests David Armano, VP of Experience Design for Critical Mass and Robert Hoekman, Jr., CEO of Miskeeto. You can learn more about David at DavidArmano.com and you can learn more about Robert at rhjr.net. I think you’ll find their contributions to the panel insightful!

That’s exactly the situation that our friend and second-time Web App Summit presenter, Sean Kane, now finds himself in. Sean recently left Netflix to be the founder of a new company, GetListed, where he is constructing his UX team from the ground up.

At Netflix, Sean had resources most of us could only dream of: a top-notch team, a wealth of user data, and a management team that truly understands how UX can play an important role. Under his watch, the site grew 14-fold, so he knows what he’s doing.

Yet, as many of us know, there are challenges to being in a small organization with limited resources and only a sliver of real data about who the users will be. So, we’re watching closely as Sean brings his talents, skills, and experience to his new venture.

In this issue of UIEtips, Sean shares with us his initial efforts to bootstrapping his user experience team. He talks about how he’s building the GetListed team and his initial strategy for creating a world-class design, much like he did at Netflix.

Read today’s article.

Have you assessed your team’s capabilities? What techniques have you used? Are there skills you think are important that aren’t on the list? We’d love to hear from you. Leave your thoughts below.

[Sean will be updating us on his adventure at the Web App Summit 2008, in San Diego, CA, March 26-28. We've already started to fill up, but there's a few seats left. You'll want to register soon because this event will sell out.You can see the entire program, and find out how to get your free limited-edition red iPod nano by registering by December 18th, by visiting the the Summit site.]

Jen wrote:

I enjoyed your December 10th article, on assessing UX skills, so I sent it around to my colleagues. It was favorably received, but the folks on the alias found that one core skill was missing: the creation of UI mockups, particularly interactive mockups.

The places where I saw the creation of mockups implied were: under Interaction design, “creating design deliverables such as wireframes and design priority descriptions.” and in the methods section, “Team members need to understand how to integrate their work with development approaches, such as Agile techniques.”

However, you never come right out and say it’s a skill …

It is indeed a skill. Actually, several, I think.

You need to work with the tools available, whether it be HTML, Flash, paper, or any new tools coming down the pike, like Adobe Thermo. Knowing which tools is best for the situation your in is an important skill.

You also need to know what makes a good prototype and how to get the most from it. Prototypes should be smoke and mirrors — not full running versions. Knowing what functionality to omit from the prototype is a skill.

Another critical skill is knowing how to collect usability data from a prototype. Prototypes that users can actually use (versus just look at and say, “Yah, I don’t like the fonts”) is an important technique during design.

I’d bundle all of these skills under Interaction Design.

With very little effort, I easily added the soundtrack to the slides I’d uploaded earlier:

| View | Upload your own

Kudos to Rashmi, Jon, and the folks at Slideshare.

Thanks to Andy Budd at d.Construct 2007 for letting me use the audio.

[Note: the slides don't completely match the audio, as I had to trim three slides due to time constraints when presenting.]

We don’t use personas. We use ourselves. I believe personas lead to a false sense of understanding at the deepest, most critical levels.

Every product we build is a product we build for ourselves to solve our own problems. We recognize our problems aren’t unique. In fact, our problems are probably a lot like your problems. So we bundle up the solutions to our problems in the form of web-based software and offer them for sale.

We recognize not everyone shares our problems, our point of view, or our opinions, but that verdict’s the same if you use personas. Making decisions based on real opinions trumps making decisions based on imaginary opinions.

I’ve never been a big believer in personas. They’re artificial, abstract, and fictitious. I don’t think you can build a great product for a person that doesn’t exist.

There was a lot of discussion on Jason’s blog, with many sentiments similar to this one from Mimo:

I never heard of Personas before. Now I read it on wikipedia. The idea sounds interesting. But I think at the end of the day it is crap. The product is always shaped by two things. YOUR experience (your present ego and YOUR idea (your future ego).

So, to add into the fray, here’s my thoughts on using personas:

It takes virtually no skill to build something crappy

No one is going to make you use personas. If you create a design without using personas, I’ll promise you the sun will continue to rise on schedule, without variation. The universe will remain intact.

However, how do you know you’re actually meeting the needs of your users? After all, that is why you were designing in the first place, right?

Some products, like the tools built by 37Signals, don’t need personas. Not because the folks at 37Signals have any special powers, but because they themselves are the personas they want to build for. They build tools they like to use themselves. For them, that will work great.

Not all teams have that luxury. A hospital IT team, building software systems used by critical care nurses in the hospital’s pediatric intensitve care unit, are not building tools they will use themselves. They are building tools used by others whose education, experience, goals, contexts, and tasks are extremely different.

A well-built, robust persona set can help educate the IT design team on what it’s like to be a critical care pediatric ICU nurse and the things they need to deal with. This information will inform their designs. And good personas help inform the design process.

Oh My God! They’re Made of People!

In his post, Jason says:

Personas don’t
Personas don’t talk back. Personas can’t answer questions. Personas don’t have opinions. Personas can’t tell you when something just doesn’t feel right. Personas can’t tell you when a sentence doesn’t make sense. Personas don’t get frustrated. Personas aren’t pressed for time. Personas aren’t moody. Personas can’t click things. Personas can’t make mistakes. Personas can’t make value judgements. Personas don’t use products. Personas aren’t real.

People do
People talk back. People answer questions. People have opinions. People can tell you when something just doesn’t feel right. People can tell you when a sentence doesn’t make sense. People get frustrated. People are pressed for time. People are moody. People click things. People make mistakes. People make value judgements. People use products. People are real.

It’s clear that Jason hasn’t used robust personas, because, when designed well, they do all these things. Jason hasn’t had the Soylent Green moment to realize that well-designed and researched personas are made of real people — real people who you can ask questions of, observe their frustrations, and discover their true goals.

I can see where Jason’s coming from. Recently we conducted a study of several dozen organizations who claimed to use personas. Less than 5% actually conducted field research to inform their personas. The remaining 95% just made up the descriptions from internal guesswork.

If you’re just going to guess on the personas, why bother? Just design for yourself, like the 37Signals team does.

However, when you do the field studies, you create relationships with the people in your research. You can return to those people and ask them questions. You can learn about the things they do.

The persona becomes a package for containing what you’ve learned from your field research. A package that is transportable to everyone on the team, so they can have the same benefits of knowing the users as you have.

Once you have well-designed, robust personas, you can take advantage of the benefits that come from them:

• Preventing Grounding
• Using the Oral Tradition
• Role Playing

In our research, teams that utilize robust personas find they create better designs, especially for things they wouldn’t normally use themselves.

I’m going to talk in great length today about building robust personas in our latest virtual seminar. See the description for more information. (It’s available live today and there’s still plenty of room. There will be a recording available shortly.)

Recently, Cheryl got back to me about her company’s reaction:

A few months back you kindly responded to my inquiry about facilitating a KJ Analysis session. The team did a great job and I was relieved as a couple of the team’s members could have easily hijacked the agenda. As you pointed out, by not allowing any discussion until the end of the process, the team — the entire team — was able to talk about the important stuff.

Within a week of facilitating that exercise, I was contacted by a several colleagues who were going to be leading a similar team exercise and had heard through the grapevine how well our activity went using the KJ Technique. I shared what I had learned from your presentation and my own facilitator notes (basically index cards with keywords so I would remember what to do next). I didn’t think to much about until yesterday, my Senior Manger made a comment about the KJ technique sweeping the company. I guess a lot of teams have adopted it as a means to brainstorm and prioritize without spiralling into the black hole of fruitless discussion.

So, thanks Jared! You get another (because I must assume you receive so many) pat on the back. Once again I was able to take something from one of your virtual seminars and put it to work!

Thanks, Cheryl!

Have you had good (or not-so-good) results from something you’ve learned from us? We’d love to hear about it.

In the method, teams brainstorm on potential answers to the focus question, group the answers, name each group, then vote on the group names that best answer the question. The method, in less than 45-minutes, allows teams to come to a democratic consensus on an answer, avoiding endless discussion for elements that turn out to be unimportant.

Our friend Cheryl recently decided to try the technique with her team and ran into a little confusion. Here’s what she wrote us:

After taking your “Making Sense of Usability Test and Field Study Data” webinar, I decided to try out the KJ Analysis with a team. I went t the UIE website and read the paper you published in May 2004. I ran a pilot with a group and ran into some problems.

I stumbled when it came to [the "Naming each group"] step and [the "Voting on the most important groups"] step in the technique. Folks had used different names for each of the groups of post-its. When I asked them to rank the groups, folks recorded their stars on their on group post-it — so a group may have had 9 stars, but it appeared as 3 stars on each of the three group post-its.

How do you resolve different names for groups? I’m a bit desperate — I need to figure things out by then end of the week. The “real” KJ process will occur early next week.

The problem Cheryl had is common for people trying this for the first time. The reason for these two steps is to work out the problems she encountered, so let me share some guidelines:

• When people are naming each group, they should be reading through the stickies and looking for a “theme”. The name will represent what they think the theme will be.


Naming Each Group: Group names are on the smaller orange and green stickies.

• Sometimes, groups form with multiple themes. If this is the case, you want to split the groups up. (You don’t want to discuss this — just instruct anyone who discovers this to go ahead and do it.)
• Similarly, you may discover, in the course of identifying the themes and naming the groups that more than one existing group share the same theme. In that case, you can merge them. (Again, no discussion necessary — just do it.)
• Two people, reading the same group, may see different themes and give them different names. Perfectly natural and it works out just fine. In fact, we instruct the team that they should attempt to give their own name to every group. The only reason they can skip naming a group is if someone else has “already used exactly the same words” they would’ve used to describe it. This will often encourage 2-3 names on many groups.
• When it comes time to vote for their personal “top groups” — the ones they think are most important to addressing the focus question (the focus question is the question being answered by the exercise) — it’s ok if team members put votes on different names within the same group. They should put the votes on the group name that best represents their thinking of the focus question.


Voting on Groups: Each team member chooses the group names that best address the focus question.

• When you collect up the groups to rank overall, you collect up all the group names with votes on them. Don’t worry about keeping group names from the same group together at this point. Just rank them as if they were from different groups.
• During the “Combining Like Categories” step, you’ll ask the question, “Are these two groups the same?” While they may have come from the same initial groups, they may actually mean different things. Only if you can easily substitute one for the other, do you combine their votes. So, if the group has complete consensus they mean the same thing, the fact they started with separate names will come out in the wash. If someone believes they mean something different, you’ll have an important discussion as to why they are different and then let them stand on their own in the final ranking.


Ranking Top Groups: Team combines the votes of groups names that are true synonyms.

The result of this is that group names that are true synonyms get resolved and their votes are combined. Group names that turn out to be different perspectives on the same results end up standing on their own. You’ve allowed these different perspectives to emerge with just the right amount of discussion based on their importance to the task (it doesn’t matter if they don’t get anyone’s vote) and the team is still spending the most “discussion time” talking about the most important outcomes of the exercise — not discussing the un-important edge conditions (which is where many teams get trapped).

A month ago, the New York Times ran a story about eBay, reporting how eBay’s Chief Executive, Meg Whitman, is telling shareholders their number one priority for the rest of the year is to improve the site’s user experience.

According to the Paper of Record, Ms. Whitman told shareholders, “In the next six months, you will see more changes to eBay than you have in the last two or three years, whether that is an improved search experience or fun things that make the site better, like Bid Assistant, which allows you to bid on more than one item without worrying that you will end up buying five iPods by mistake.”

eBay is the 383rd largest company, according to the Fortune 1000 list. It’s really exciting when an F1000 chief executive is declaring user experience to be the solution to their lagging market share issues.

In fact, it’s exactly what we’ve been hoping for. For years, we’ve wanted executives to realize the benefits they could reap if they focused on user experience and, at eBay, it’s exactly what they are doing.

However, is it all good? After all, we’ve lived for years being the ignored black sheep, forever searching for an “ROI” message to convince people to realize the value in investing in UX work. At eBay, it’s clear the executive get it — the ROI problem has been solved there.

I asked Christian Rohrer at eBay if this was good news or if his life just became harder. He replied:

Great question! It simultaneously makes the job both harder and easier, because focusing on user experience means that we have to do even better work. It certainly gives us a voice!

The biggest work we have to do is transforming our processes to be more user-centered. That always takes time because we’ve spent so many years doing it differently. But it’s a refreshing change.

If you want to check out the kinds of things she’s talking about, visit this site:

http://playground.ebay.com/

which is a public space where we let people take a peak at some of the different experiences we are working on.

It’s true that much will change in the next 6 months. We have so many product rollouts that, by the end of the year, it may just look like a whole new site. But you know that this is only the beginning – lots of iterations will come after that. Nobody gets it right the first time (especially on the web .

If your executives took a major interest and started promising customers and shareholders for a dramatic instant improvement in your product/services user experience, would your organization be ready for it? Do you know what you would do?

I talked about this in more detail in a recent UPA Journal of Usability Studies article called Surviving Our Success: Three Radical Recommendations [PDF]. There’s no place to comment on the UPA site, but I’d love to hear what you think of the article, so please comment here.

Flickr, the online photosharing web site, changed everything for web applications. For one of the first times, the developers of Flickr combined elements of Flash and AJAX in a seamless form, along with the HTML page.

What many people don’t know is that Flickr wasn’t originally a site for sharing photos. It was originally conceived as an online game, “The Game Neverending.” But when the design team started facing business obstacles with the game, they quickly shifted their priorities and recognized the value of the photosharing application. As a result, Flickr fundamentally changed the way we look at web applications.

At UIE, we hear all the time from clients working to build products and sites that capture the market, hoping to duplicate the success of sites such as Flickr. If you’re challenged with creating innovative designs, I think you’ll really want to read Scott Berkun’s writings on the subject. Scott is the author of the new book, “The Myths of Innovation,” and an expert when it comes to the history of innovation.

In this week’s article, UIE’s Christine Perfetti sat down with Scott to talk about his new book and his research in the area of innovation. I think you’ll really enjoy it.

Read today’s UIEtips article.

How does your design team go about developing innovative designs? Join the discussion below about this week’s topic below.

[If you find this article interesting, you'll definitely want to attend this year's UI12 Conference, where Scott Berkun present his full-day seminar: The Myths of Innovation -- How to Lead Breakthrough Projects. In this seminar, you'll gain the essential skills and core concepts needed to lead innovative projects within your organization.]

The framework was a simple four-stage progression:

• Stage I: Raw Iron — A focus on getting the technology working
• Stage II: Checklist Battles — A focus on getting the right features
• Stage III: Productivity Wars — A focus on getting the right experience
• Stage IV: Transparency — A focus on integration into bigger experiences

Once we figured this progression out, it became clear that practically every technology followed it. It explained the progression of word processors, automobiles, commercial jets, military weapons, telephones, and anything else man has developed in the last hundred years. Some technologies moved through the progression quickly, others took years.

It was really useful to refer to the framework when talking to clients because, back when we were consulting firm helping with usability research, our pitch would change depending on which stage they were in. We’d talk about identifying important features in Stage II, where we’d talk about shipping sooner (often by eliminating unnecessary features) in Stage I. In Stage III, we’d talk about traditional UCD notions of ease-of-use and ease-of-learning (which, interestingly, don’t become important to talk about until Stage III).

We stopped talking about the framework in the late ’90s because we were doing more web work and we weren’t sure if the framework applied to the web. At the time, we couldn’t see the progression, but we now know that it was because we were stuck in the middle of Stage I and it’s hard to see what’s coming from where you are.

Now, more than ten years later, we’re finding ourselves talking about the framework once again. Time has let us simplify it:

• Stage I is now Technology
• Stage II is now Features
• Stage III is now Experience
• Stage IV is now Integration

(As we get older, we realize cute names for things just obscure instead of enhance their meaning.)

We can see this clearly on the web now:

• Early sites just focused on the mechanics of getting the site working
• Then sites focused on having a plethora of features
• Now we’re seeing a push to reducing the number of features and a focus on the experience
• Some sites are beginning to get sucked into other experiences (for example, Writely.com becomes part of Google Office)

Web 2.0 is definitively a push from Stage II to Stage III. The abundance of small, simple web applications using interface technologies such as Flash, Flex, and Ajax (and soon Adobe’s AIR and Microsoft’s Silverlight) is predicted clearly by the framework: developers stop piling more features into the product, instead focusing on simpler, yet more usable, designs. Compare 37Signal’s Basecamp to Microsoft’s Office/Project/Sharepoint solution to the same problem. LessFewer functions, better experience.

(It’s not just the web where we’re seeing this now: the mobile phone world was stuck in a feature-intense Stage II until the experience-focused iPhone came along; the game console space was all about putting better hardware in the box until the Wii suggested a less-hardware-but-better-experience approach.)

Once again, our framework is gaining traction. I was sitting in a keynote by Peter Merholz at the recent Web Design World and what does he start talking about? Technology -> Features -> Experience. He also makes it a centerpiece of his great article for Core77. And others are starting to talk of it too.

It’s an important framework. We think everyone should become familiar with it, since it is the roadmap we’re following.

Improvements happen when the design truly eliminates frustration. Organizations benefit from those improvements when the eliminated frustration increases sales (due to a better user experience) or reduces expenses (due to decreased support or development costs).

One problem we often see, however, is when the user researchers get overzealous in their improvement suggestions. They start to make recommendations in cases where there may not be any clear evidence the change will eliminate frustration or improve the design in a measurable way.

The worst case scenario is when someone issues a poorly thought out recommendation, which turns out to make the design more frustrating. When this happens, it hurts the reputation of the user research effort and puts into question other recommendations.

At the recent CHI conference, our good friend Meghan Ede, who runs the user research effort at Symantec, told us she’s instructed her team of researchers to ask the following of every recommendation they write: “Would you bet your life savings on this recommendation improving the design?” They remove any recommendation which doesn’t meet this criteria from the final presentation.

Meghan reports, since she’s instituted the policy of asking this question for every recommendation, the number of recommendations has dramatically decreased, but the quality of their results have substantially improved. The researchers are now more confident when they report their results and the teams are less argumentative.

What do you think of Meghan’s approach?

Jeff Patton has a really cool article outlining what he thinks are the two aspects of human behavior that surface when encountering new products, which he calls the buyer head and the user head.

The buyer head looks at the product objectively, considering how its features will help to achieve specific goals, address certain needs, and rectify various problems.

The user head looks at how effective the product actually is in achieving those specific goals, addressing those certain needs, and rectifying those various problems. The user head also evaluates ease of use and the emotional response the product generates.

Sometimes the buyer head and the user head agree on a purchase decision. The customer is satisfied with the value, features, and experience that the product provides. But other times, the buyer head and the user head end up in conflict, especially when the product does not provide a pleasant experience, even though it provided the best value.

By learning how to appeal to these two sides of potential buyers, design teams can create products that have great value in terms of money, time and goal achievement, are easy to use, and provide a delightful experience. While these aren’t the only two “heads” to consider, designing for the buyer and the user in all of us may prove to be an effective way to drive sales and create satisfied customers. I think you’ll find Jeff’s article extremely valuable.

You can read Jeff’s full article here: Designing Software for Two-Headed People

Karl Long recently posted a short article where he discusses the effect of organizational culture on experience design through Conway’s Law.

Essentially the law states that systems (especially software) will reflect the organizational structure that created them. Going beyond the obvious aspect of organization of features, information architecture etc. it goes on to state that the software/system will reflect the disfunction of the organization that created it.

Karl also poses some interesting questions that will get you thinking about innovating your traditional approaches to product creation.

You can read Karl’s full post here: Conway’s Law – Software/Systems Reflect The Organizational Structure That Created It

Every time I give a talk, someone always asks, “That’s all good and nice that helping users learn is the key to creating passionate users… but who’s going to do all that extra work? Who’s going to make the extra tutorials and better docs?” Answer: your user community. Think about all the things a strong user community can do for you: tech support, user training, marketing (evangelism, word of mouth), third-party add-ons, even new product ideas.

You can read Kathy’s entire post here: User Community and ROI.

How are you engaging your audience?

When she arrives at the store, she initially doesn’t know where to go, as no visual clues present themselves. After a ten-minute wait at the customer service desk, she’s told she’s in the wrong place and needs to find another desk, this one labeled “Online Receiving”. Once she finds that desk, the clerk, who obviously can’t wait for his shift to end, sighs and says the camera she’s purchased is out of stock. She can buy a different camera at this point, but to receive a credit for her original online purchase, she needs to call an 800 number. She ends up leaving the store without a camera and a charge on her credit card she needs to resolve.

This scenario highlights the difference between usability and user experience — a question I get quite frequently these days.

Usability answers the question, “Can the user accomplish their goal?” In the case of our camera shopper, from the perspective of the site’s design, she did accomplish the goal, being very satisfied with the result.

User experience answers the question, “Did the user have as delightful an experience as possible?” The store portion of the experience canceled out the online portion.

If the online portion was the only thing involved, our customer would’ve been delighted with the results and likely shopped again. Because of the total user experience, she’ll likely resist shopping with the brand again.

In this organization’s case, the usability of the site involves only those people who directly influence the design of the site. However, to create a pleasurable user experience, we now have to involve people from all over the organization, including those people dictating how the store operations are designed and implemented.

User experience takes far more effort to do well, but the results have far better impact.

Are you focused on the user experience?

Present for the call were Jared Spool, DeWayne Purdy, Lyle Kantrovich, Kyle Pero, and Nate Bolt. You can meet the crew here.

You can fin the first episode and more about what’s in this episode here.

Here’s a feed that iTunes likes.

We’d love to hear what you think. Leave your comments on this page or you can write us at SpoolCast@uie.com.

Present for the call were Jared Spool, DeWayne Purdy, Lyle Kantrovich, Kyle Pero, and Nate Bolt. You can meet the crew here.

You can fin the first episode and more about what’s in this episode here.

Here’s a feed that iTunes likes.

We’d love to hear what you think. Leave your comments on this page or you can write us at SpoolCast@uie.com.

Present for the call were Jared Spool, DeWayne Purdy, Lyle Kantrovich, Kyle Pero, and Nate Bolt. You can meet the crew here.

In this episode, the SpoolCast crew convened to discuss:

• the impact of the pending Target Suit
• mixing automated and in-person testing techniques
• multi-variate testing
• designing tasks for testing
• moderated vs. unmoderated testing methods
• using Flash and AJAX on home pages
• the importance of validating inferences
• the interface paradigm of the Nintendo Wii
• the impact of new devices, such as the TiVo, Wii, and Guitar Hero on future interface design

We’ve divided the recording into three parts to make it easier to digest…
Part 2 is available here.
Part 3 is available here.

(Here’s a feed that iTunes likes.)

Sorry it’s taken so long to get this one out. It’s been crazy ’round here!

Production assistance on this SpoolCast from Brian Christiansen.

We’d love to hear what you think. Leave your comments on this page or you can write us at SpoolCast@uie.com.

His initial solution was to hire a consultant to run some usability tests, gather the essential information, write a report, and present it back to the team.

I had a different idea: I suggested we train the development team to do their own testing. In my 28 years of experience of doing this work, I’ve found there is no single experience more educational than conducting usability tests.

Sitting next to a real user while they do real work is always an enlightening experience. I have yet to sit in on a test where I don’t learn something, even if what I learn is we’ve done a good job at nailing the design to meet the user’s needs. I learn the words the user’s like to use, the way they like to approach the problem, and where the design succeeds and fails at helping them.

Watching 10 real users is always an eye opener. Seeing patterns become enlightening. Seeing what doesn’t happen is just as useful. (“Look, none of the 10 users showed any interest in that fancy widget we spent so much time on!”)

Once you have a little training, conducting tests are fairly simple and straight forward. (As I say often, usability testing is not rocket science. We know this because NASA is one of our clients and they are very specific as to what they call rocket science. This is not it.)

Plus, once testing is embedded into the team’s regular process, it becomes a great way to try out new ideas and collect some actual data, instead of the usual opinion wars. There’s nothing like having a test scheduled and closing off an endless design debate with “Let’s see what the users say on Wednesday.”

I’ve seen a lot written about usability testing over the years, but I can’t recall seeing anyone talk specifically about it’s value as a training tool, to bring the entire team on the same page about who the users are and what they are trying to accomplish. Stretch your thinking of usability testing as a design validation tool or an idea generator into a team education technique. You won’t regret it.

I guess that’s what interested me when I read this in yesterday’s New York Times article, Stirring Up the Cubicles at eBay (Registration may be required, the story may hide behind their pay-wall in a few weeks.):

[John Donahue, deputy to eBay's CEO and president of eBay Marketplaces, one of eBay's most important divisions] accompanied two members of eBay’s research group to the San Jose apartment of Kanvasi Tejasen, a 30-year-old Lockheed Martin engineer who had agreed to have her online buying habits studied by the company in exchange for $200.

With Mr. Donahoe (who makes $800,000 a year and has received around $10 million worth of eBay stock) sitting on her sofa taking notes, Ms. Tejasen shopped for a TV tuner and visited rival sites like Amazon and Google. In one crucial moment, she plugged the term “4G iPod Nano” into the eBay search engine and received 1,700 results, which she said she found confusing. That set Mr. Donahoe scribbling furiously.

“We have to do a better job getting her what she wants,” he said afterward. “If we improve search efficiency even 1 percent, it’s worth hundreds of millions of dollars.”

What would happen if your CEO went on a few site visits?

With the new year comes a redesigned Wall Street Journal newspaper. Understanding that WSJ readers might need assistance with the change, the paper produced an 8-page reader’s guide to explain:

Good newspaper design has always been a combination of utility and aesthetics. But never has getting that mix right been more important.

Today’s readers are inundated with information, 24 hours a day. Many of them come to their newspaper already knowing the main headlines, looking for interpretation and understanding of events or for “discovery” news—things they didn’t already know but are glad to learn. They want both substance and efficiency.

Download the Reader’s Guide. (PDF)

Update: I’m told the print edition of the Wall Street Journal is free today.

The original plan had been to create an online game. But they were just about out of money. And then Butterfield had this crazy vision of building a photo-sharing website, and before you knew it Flickr was a cultural phenomenon.

…

Butterfield: In February 2004, we launched Flickr.

Fake: George Oates [a Flickr employee] and I would spend 24 hours, seven days a week, greeting every single person who came to the site. We introduced them to people, we chatted with them. This is a social product. People are putting things they love–photographs of their whole lives–into it. All of these people are your potential evangelists. You need to show those people love.

We did all kinds of dumb, stupid things. But our unofficial slogan was, “F— up fast.” Make mistakes rapidly, learn from them, and move past them.

(Note: You can meet Stewart Butterfield at the upcoming UIE Web App Summit in Monterey, CA on January 21-23. He’ll be talking about Flickr’s experience with building web-based applications, along with Sean Kane from Netflix, Jim Whitney from Whiteboard Labs, Christian Rohr from eBay, and many others. If you develop web apps, you don’t want to miss this event. There are a few seats still available.)

The folks over at Manager-tools.com have published an excellent podcast on “Jump Starting Internal Customer Relationships.”

Part one of the Podcast
Part two of the Podcast

I think they are extremely useful, but not for all people in all situations. In specific, I’ve found personas to be very important under the following conditions:

1. The design team is an actual team, with more than a single individual working the entire process from ideation through implementation (and beyond).
2. The team members are different from their users (which is most of the time).
3. The team members do not have constant interaction directly with the users, particularly getting feedback on how the relevant artifacts are used.
4. Different users will interact with the artifacts differently because they have different intentions, context, knowledge, skills, or experience.

The well-executed persona description helps the team work “on the same page,” when it comes to understanding who their users are. It can eliminate the confusion and wasted efforts that come when team members are walking around with different ideas of who their users are. (See Yahoo’s Approach to Keeping Personas Alive.)

The well-executed persona description enables successful role-playing and story-telling for intra-team communication and for inter-group understanding of the design goals and objective. (See Three Important Benefits of Personas.)

The well-executed persona description helps the team members fit the design solution against the attributes which make one persona different from another, to ensure they’ve not excluded activities or impaired actions because they were ignorant (or forgot) about a subtlety of use. (See 5 Things to Know About Users.)

I see a major role for personas to be dissemination of information about users to others in the organization. When well executed, the entire organization understand who the design is for and the subsequent design rationales.

Over at the IxDA discussion board, Rob Nero from Northwestern Mutual posted a question about creating a space to help design teams collaborate:

What unique items to keep in your room to promote problem solving and creativity?

Dan Peknik, a designer for NASA Ames and San Jose State University, replied with some great ideas, including:

• People need space to express their ideas – one whiteboard is not nearly enough. Lots of colors, lots of whiteboard space is always key.
• Most creative sessions are waaay too long. Keeping people standing keeps things moving, but it’s also not a bad idea to have a large stop watch somewhere – there are several timers available that can be attached to the wall to keep people on track. When I run meetings, I’m always aware of how much floor time people are getting, and I’m scanning to see if people are starting to glaze over. I never put people in meeting where they must go on for more than an hour at a time without a break. That yields diminishing creative returns.
• A printer with a USB port and cable so people can plug in and print right there instead of walking out to do so.

What do you do to keep your team’s creative juices flowing?

Joel doesn’t think too highly of the process, saying

Software organizations tend to reward programmers who (a) write lots of code and (b) fix lots of bugs. The best way to get ahead in an organization like this is to check in lots of buggy code and fix it all, rather than taking the extra time to get it right in the first place. When you try to fix this problem by penalizing programmers for creating bugs, you create a perverse incentive for them to hide their bugs or not tell the testers about new code they wrote in hopes that fewer bugs will be found. You can’t win.

Joel’s point, a good one, is when you measure the productivity of individuals, you have to be careful of gaming. He implies that you can’t build a measurement system for programmers that can’t be gamed.

That may be true, however, I’m not sure gaming is always a bad thing.

Part of the problem with the measures Joel spoke of was they ignored any valuation on quality. They focused on function points and lines of code, two easy-to-measure quantities. Code quality is not so easy to quantify, so we tend to not try to measure them. (After all, who wants to get into arguments on whether something is quality or not.)

Someone really smart (not me and I don’t remember who) once said, “Once you remove ‘quality’ as a requirement, everything gets a lot easier to build.” Well, once you remove ‘quality’ as a measure of success, then the measures become a lot easier, but they don’t necessarily measure what you’re looking for.

In Ziya’s post, he posited the same problem would occur when designers try to measure their own productivity. After all, what do we measure our design team on?

Maybe I’m an optimist, but I believe it’s possible we can arrive at productivity measures that work (meaning, when gamed, they produce the results we were hoping for) for design teams. These measures would quantify the results the team produced and compare them to the effort it took to produce it.

From there, we could determine what practices and skills are most efficient at gaining the best results. We can also use these measures to help us make budgets and predict timelines.

Right now, we probably don’t know enough to put these measures together. But, just because we can’t effectively measure it right now doesn’t mean it’s impossible. History has shown many examples of things which took a long time to learn how to measure, but someone eventually does.

How would you measure the productivity of your designers?

The legend of how eBay got started is a quaint one: Pierre Omidyar created eBay so that his wife could buy and sell her favorite collectibles: Pez Dispensers. The story has been told thousands of times, and most people like to think that the site is a labor of love. Unfortunately, the story turns out to be a little bending of the truth: apparently Omidyar realized the site’s potential before pursuing it.

It is true, however, that Omidyar used the site to help sell his wife’s collectibles. He was one of the first users, as well as the first developer, of eBay. That may sound like an unusual combination: to be both the user and the developer. Our conceptions of both tend to be very different. Users are those people who use stuff. Developers are those who build it.

But what happens when they’re one in the same? What happens when the user is the developer, and vice versa? It turns out to be a powerful combination that leads to unseen advantages that those building for others don’t have (and might not be able to duplicate).

Scratching Your Own Itch

The web application Basecamp was created by a team of web developers at 37signals who had a project management problem.

“Basecamp originated in a problem: As a design firm we needed a simple way to communicate with our clients about projects. We started out doing this via client extranets which we would update manually. But changing the html by hand every time a project needed to be updated just wasn’t working. These project sites always seemed to go stale and eventually were abandoned. It was frustrating because it left us disorganized and left clients in the dark.”

“So we started looking at other options. Yet every tool we found either 1) didn’t do what we needed or 2) was bloated with features we didn’t need — like billing, strict access controls, charts, graphs, etc. We knew there had to be a better way so we decided to build our own.”

Other People Have the Itch, Too

What happens next is the same: after you scratch your own itch someone realizes that others have the itch, too. It might be the developer who notices, or another user. Mike McDerment, who co-founded Freshbooks, a web-based accounting application, describes this:

“(We) founded the company in January 2003. We were doing web design and development projects for various clients. We built FreshBooks for ourselves and very quickly realized that other businesses needed a painless billing solution. We put our heads down and got to work.”

Eating Your Own Dogfood

After you realize that others have the same problem, the next step isn’t to start building for all of those other people and assume you know everything. No, it’s to continue to design for yourself, and then use the product for an extended period of time. Play with it, push it, pull it, make sure that the features there are the right ones, not the nice-to-haves.

Christina Wodtke (who spoke at our User Interface 9 Conference), is working on a new web app: Public Square. She’s testing it out in a small way before releasing it as a service, using it to run one of our favorite sites, the online magazine Boxes and Arrows. She’s effectively killing two birds with one stone…using it herself as well as testing it with others to get real feedback.

Increased Passion for the Work

This users-as-developers cycle may be more virtuous than others. Dan Cederholm, who co-built a wine-sharing site called Corkd, describes how much more passionate he is when working on his own project.

“There’s a real difference between being a hired hand on a project for a specific amount of time and someone who has ownership as well as passion for what they’re working on (ownership and passion can be exclusive as well, but combined, they pack quite a punch). The short-term, part-time attention of a freelance designer or developer can often lead to clunky, duct-taped solutions after the contract is over and the site is actually being used by real people. Cork’d has been the complete opposite situation, where we’ve been able to launch a product that would be considered “done” under most circumstances and then react to member feedback using the same attention to detail that went into the initial construction.”

A New Model

At first, it can be quaint to say that building for yourself is a nice perk of your situation. Increasingly, however, starting with eBay and now with firms like these four (and countless others as well), this new model is becoming the de facto way to develop, a critical part of success. If you compare a piece of software created by its users vs. one that’s not, it’s pretty easy to tell the difference. The designers understand the problem better, they’ve worked through most of the issues, and they’re more passionate about it after all is said and done.

His premise is an interesting one:

It’s hard to describe what design is because it crosses so many boundaries: fashion, architecture, interaction, and mechanical, to name a few.

But it’s easy to talk about what all those different types of design have in common. One thing is sketching. While a clothing designer is trained very differently from an architect or an industrial designer, they all learn to use sketches as basic starting point.

Buxton asserted sketching was a fundamental activity to ideation. It is a quick way to play with an idea. And it communicates the proper stage of the idea to the viewers. Early, rough sketches just scream, “This is an idea! I’m not done!”

Buxton talked about a study of sketching for traditional design disciplines that showed all had common attributes:

• They are quick to make and timely to talk about the idea
• They are inexpensive and easy to dispose of (making designers less “wedded” to a particular idea because of investment)
• They are plentiful (designers should bring many different ideas-as-sketches to the table, not just one)
• They have a clear vocabulary (such as drawing through the endpoints to show the “unfinishedness” of the idea)
• They use no higher resolution than necessary (so they don’t waste designer’s time and effort in preparation)
• Their resolution does not suggest they are further along than they really are (to avoid giving the impression of being more done than reality)
• They suggest and explore instead of confirming (to support ideation, instead of forcing decisions)

Buxton then suggested “Since Experience Design is a type of Design, it too must have sketching. However, traditional sketching doesn’t work well to represent interactions, so what would sketching for interactions look like?”

Ideation vs. Evaluation

Buxton suggested ideation is a different process than evaluation. In ideation, the goal is to come up with many different ideas, using each idea to suggest others. In evaluation, the goal is to narrow down the choices of ideas, honing in on the best idea. He suggested today’s usability process is evaluation, while ui design is ideation, an idea I agree with.

He made it clear that both ideation and evaluation were necessary.

“It’s like saying there are both girls and boys. One isn’t necessarily better than the other, but both are required and it’s important to know the distinction.”

Ideation has to come first. You generate ideas, which you will subsequently evaluate. So, Buxton suggested that sketching has to come before prototyping.

Sketching vs. Prototyping

The attributes of each are different:

The idea is you create many sketches at first, then narrow them down, until you’re ready to build your prototype to evaluate with. Because sketches are more lightweight and cheaper than prototypes, they are easy to play with and throw away. When you’ve explored the idea space sufficiently, then you eliminate ideas to a basic few, which you then prototype out with the rigor necessary to evaluate.

“It’s about making many good mistakes. I want to have brilliant mistakes.”

This was just a subset of the great ideas in the 90-minute presentation, but I thought the idea of sketching was a brilliant take on the ideation process I hadn’t heard before. (At least, not quite this way.) If you get a chance to hear Bill speak on this subject, I highly recommend it.

Update: Nick shared this link where you can watch a recording of Bill’s presentation.

This was a really fun conversation. Some of my favorite bits are:

Kyle Pero’s idea for her dream panel at a conference

I think we need to ask ourselves if we’re growing and improving our service based on what the clients want – or what we think they want – doing a little bit of our own user research I guess. I believe that our clients, and not the industry, should definitely be setting our standards, and I don’t know if we’re doing that. A panel of clients discussing their needs would be quite interesting to me, this is just my opinion. I know every one of us works on different products – some of them offline, some of them online – but basically, the need is the same. Can the products be used easily to accomplish the task? I think if we just take a moment in one of these conferences and just stop listening to each other for a change and start listening to who we are servicing I think it would be pretty interesting and different.

Rashmi Sinha on whether usability studies are scientific or not

Rashmi: But anyone who thinks that this is science, hasn’t done science! I have done science, and this ain’t science, by any stretch of the imagination. I disagree with the whole notion of trying to make it scientific because it isn’t scientific. Second, you have a big problem…

Jared: Making what scientific? The study itself, or the field?

Rashmi: The field is not scientific, and now people have this big notion from experimental psychology, but really it’s not. Experiments have – there’s a way of doing them, and it’s very hard to do that in the field.

Lyle Kantrovich pipes in on why Rolf Molich’s CUE studies are really interesting

Jared: But this brings us back to what Kyle Pero were saying. Because, I think, what is a key element of this is that the client doesn’t realize that they have different results depending on which team comes through. We’re not pitching it that way. Let me put it another way. When Ralph ran CUE-4, he had 17 teams look at, I’m trying to remember, oh it was…

Kyle: Hotel reservations.

Jared: Hotel reservations system, the U Penn system. Not the Penn, but the Hotel Pennsylvania or whatever it was, I don’t remember what the hotel was. But he had people look at this hotel thing that was done by the iHotelier folks, and the 17 teams, approximately half of them, did heuristic evaluations, half of them just happened to work out to do usability tests. They found, across all the teams, they found 61 errors, 61 problems with the design, that the client, the iHotelier people, thought were critical designs, critical problems. Things that they said, these are things we definitely have to fix. But each one of those 61 problems was only reported by one team. So in order to have collected all 61 problems, if the iHotelier people, Jim Whitney and the folks at Webvertising, were to hire a group to do it, they’d have to hire all seventeen teams to get those results.

Lyle: Well, this is why I think those studies are pretty interesting: I think that, by doing these kinds of studies, we will learn what helps us find more problems, what helps us find more critical problems, what we mean by those things. But also, frankly, if you’re iHotelier and you hire only one team, and you find, say, ten critical problems, aren’t you still in a better place? So I don’t think it brings in a question of value or the validity of these studies; but these will help us refine our art, our craft. I don’t think it’s a science: I think what we do is craft; it’s part science and part art. I think it gets better.

Kyle: What the studies really show is that it really does matter whom you hire.

Jared: Exactly.

Rashmi and Nate Bolt discuss more about the scientific nature of our work

Nate: Well I was just thinking about the discussion we were just having and it almost sounded like there was an implicit assumption that if you were a scientist that you follow certain rules and that you should come up with the same results as everyone else. But that would also lead to the idea that all scientists are created equal and we know that that’s not true because scientists like Darwin and Kepler, Galileo, they all had something that no one else had. They had this sort of insight to translate what they were seeing and the math behind it into something new. I would just add to that, before we ultimately kill it, I would just add that all scientists aren’t created equal either and we really can’t get away from the person that’s doing the process in the discussion that we’re having.

Rashmi: Correct. When you teach courses and you do even basic scientific experiments and you have every student in the class replicate that, you do find deviations. They might be deviations around some kind of thing that might form a normal distribution that there’s this one most likely result and then there’s deviations from that. But the method and the way that people carry out the method is different every where. And also in science there’s an explicit concept of the meta kind of research where you look a bunch of the different studies on a topic and you make some logical conclusions. So that once again acknowledges that not every result done addressing the same exact question is going to come up with exactly the same answers.

Josh Porter on the Facebook Controversy

Josh: Well I think Rashmi makes a great point, that this is kind of a new sort of social design issue. The really ironic thing that I just read about this morning was that the actual implementation of the feature itself caused its own downfall. Because as you were looking on your Facebook profile, you could see that all the other people, all the other people in your network, were signing up for the protest petition. So that’s how that petition was signed by like 700,000 people in 24 hours, because the new feature itself propagated it so fast, so I found that really interesting. But one thing that I don’t think any of us have mentioned as well is that the privacy settings of everyone’s information actually stayed the same. So when, if you were seeing information in your news feed, that was information that was already available to you. The only difference is you had to work much less hard to see it. It’s kind of like moving from looking at HTML home pages to going to RSS. There’s just that much less effort in seeing information.

Jared: The MoBuzz TV people, said that this is like people who, somebody who stands naked in their window every morning, who gets upset because someone handed them a photograph of them standing naked in their window.

Read the entire transcript here.

In another aspect of social networking applications, Netflix has the capability to invite “friends” into your experience. When your friend accepts you invitation, you can see how they recommend a movie you might be interested in. This now gives users two perspectives on a film: what the general Netflix user base thinks about a given film and what your specific friends think about it. Like using tagging, looking at the differences in the recommendations tells you something about the film you didn’t know before.

While rarely talked about, the grand-daddies of social networking functionality is, of course, Amazon and eBay. Amazon, with it’s “Customers who bought this book also bought…” functionality changed the way we shop. eBay, with it’s reputation system that allows both buyers and sellers to decide if a transaction is worth the risk, changed the way we interact with what is otherwise complete strangers.

My colleague, Josh Porter, had an interesting take on all this over at his Bokardo blog:

In general, computers and software are taking an increasingly social role for us. Our behavior hasn’t become all that much more social (although it certainly has for some) but we’re learning how to effectively model our social needs in software. Three years ago the social aspects of software was email and chat messaging. Now, it’s forging online identity as profiles and embedded messaging within applications. It’s become always-on, which means that there is no distinction between “offline” and “online” anymore. We are not just modeling messaging, we’re modeling presence as well. This is a big shift…and our language reflects it. I’m “on MySpace” means that we are figuratively and literally on the site.

I quoted Wil Wright recently, and I think he’s (pardon the pun) right on. First thought of as super calculators, computers are now part of the social fabric of our lives. They are becoming integral to how we communicate with our family, friends, and colleagues. They’re still doing calculations of course, but the software that we’ve designed for them is all about human-to-human contact. Social contact. And since we’re social animals in the end, the trend of modeling this in software won’t be reversing any time soon.

I agree. It’s not going away soon. And more importantly, there will be increasing demand for designers who have experience with this. The recent Facebook controversy shows us what happens when we design social networking functionality poorly. And how we design, introduce, and maintain social network systems is unlike any of the other design problems we currently regularly face.

I think a new specialty in design will soon emerge to deal with social networking functionality. Specialists in this discipline will learn from others, develop a working body of knowledge, and apply their knowledge and experience to new problems in different contexts. I’m betting, within five years, we’ll see a conference where more than 200 such specialists gather to share and compare their experiences in this new field.

For the last 20 years, a revolution has been underway in the way organizations have developed software systems. It came about from a realization that existing processes for developing large systems were just not meeting the demands of the workplace. Before the revolution, the resulting systems were late and often didn’t come close to meeting the users’ needs.

The result was a brand new set of practices, often called Agile Development processes. Instead of long development times, software is developed in short time boxes, called iterations, which typically last one to four weeks. Each iteration is handled as its own project, with small, but solid deliverables. The goal is get something in front of users as soon as possible.

Sound familiar? In parallel, there’s been a similar revolution in the field of Experience Design over the same 20 years. We started with doing all of our usability work at the end of a project, but we’ve been pushing to get teams to conduct shorter and shorter iterations, with testing and other research techniques moving as far forward into the development process as possible.

Now it’s time for these two revolutionary approaches to merge. While the basic fundamentals are the same, their independent evolutions have made it a rough match. Care needs to be taken to get them to talk to each other.

Seeing the impending collision of these two revolutions for many of our clients, we reached out to a person who has been at the forefront of this thinking, Jeff Patton. Jeff floats (shall we say agilely?) between these two worlds and is our go-to guy when it comes to how you integrate experience design in to the agile environment.

In today’s UIEtips, Joshua Porter and I had the opportunity to interview Jeff Patton about his views. The interview turned out great and I’m very pleased to share it with you today.

Is your organization involved with a move to Agile processes? How have you worked to integrate your UX practices? We want to hear your thoughts and comments. Add to the conversation in the comments below.

Read today’s UIEtips article.

However, I think that would be a narrow interpretation of how specialties work. To explain, let me turn again to a much more mature practice area, medicine.

Specialties in medicine can be singular, such as orthopedic surgery or podiatry. However, the practice of medicine is now seeing new specialties pop up which are combinations of these singularities.

One such new one is the new discipline of Physiatry. Physiatry deals with restoring function for a person who has been disabled as a result of disease, disorder, or injury. It combines the disciplines of neurology, physical medicine, rehabilitation science, and electromyography.

Physiatry started in the 1920′s, but only came into serious play after WWII when people became concerned with the growing number of war injuries and disabilities. Even then, it’s only really started blossoming as a profession in the last 20 or so years. So, in the entire history of western medicine (going back to the Greeks), it’s a very young branch.

Physiatry is interesting to me because it takes four previously-unrelated disciplines and combines them in a holistic way. This combination allows the physiatrist to diagnose and treat issues that no one branch of medicine could work with.

A physiatrist is not a generalist. They aren’t delivering babies and dealing with rashes, per se. Like other specialties, physiatry is very specific about what it talks about. It just happens to be the intersection of other specialties.

Comparing this to the practice of user experience, I think we already see physiatry-like combos happening. As I mentioned earlier this summer, the artwork from the Mayo Clinic site demonstrates they have people who straddle multiple disciplines: illustration, anatomy, and medical science. I’ve met usability specialists who focus on telephone/interactive voice systems (which have different approaches and problems, due to the non-visual components). I’ve met information architects who specialize in news topics and others who specialize in legal topics. I’ve met visual designers experienced in designing for Eclipse environments.

I expect we’ll more of this as we integrate ourselves into teams. A team will find someone who has skills and experience related to their products domain and to their tools and environments to be very valuable.

I think it’s going to be fascinating to see how people specialize and where that will take us going forward.

Specialists are professionals who have the time, experience, and projects to allow them to go deep into a discipline, such as information architecture. Because they can concentrate on the one discipline, they become very knowledgeable and experienced at solving the problems that crop up. Having a specialist on board is often very valuable, since they’ll know how to tackle the many subtleties that can make or break a project.

Generalists are professionals whose time and projects demand they learn a broad variety of disciplines. It’s not unusual to find a generalist who daily switches between information architecture, usability research, interaction design, visual design, and even coding. Because they are constantly switching, they don’t have the advantage specialists have at gaining knowledge in a specific discipline. However, they do have the advantage that they often better understand the intersection between these disciplines. They are extremely valuable because they can see issues and details from multiple perspectives, bringing a broad view to the project.

Specialists and generalists are not new. They’ve been in other fields for years, such as medicine. For example, at the Lahey Clinic, here in Burlington, MA, there is a Dr. Margles who is an orthopedic surgeon specializing in hands and wrists. People come from all over the world to see him. Manufacturers of surgical products seek out his advice. He’s one of the best hands and wrists guys in the world. He’s definitely a specialist.

11 miles to the west is Emerson Hospital, in Concord, MA. There we find an orthopedic staff of 6 doctors, all of whom are very capable. But none of them specialize in hands or wrists. They work on whatever body parts you bring to them. They are just as good as Dr. Margles and the other specialists at the Lahey Clinic, they just have different experience.

Now, don’t make the mistake a lot of folks make and confuse specialization with compartmentalization. While the former is about having the majority of your experience in a single discipline, the latter is about only having experience in that discipline. While Dr. Margles prefers to work on hands and wrists, he could, if the need arose work on other areas. In fact, if he was the only doctor on the island, you’d want him to be the one to deliver the baby. And his medical training and experience would ensure he does it successfully.

A compartmentalist isolates themselves from the other discipline around them, not really learning what they do or how they do it. Compartmentalism is bad for teams, because it means you have to have enough work to keep that individual busy within that discipline, and if needs shift or emergencies crop up, their value is dramatically diminished.

So, that leaves generalists and specialists to staff the team. Which should you hire?

From our research into what makes successful teams, we’ve learned the answer will depend on the economics of your situation. Some organizations will have the demand necessary to support group of specialists.

That’s they way it is at the Lahey Clinic. They have enough traffic and work to support multiple surgeons who specialize in only certain parts. Dr. Margles usually has a six-week waiting list to see him. He has no trouble staying busy. And, because there are more than 20 doctors in their orthopedic department, patients with problems with shoulders or ankles can find either another specialist or a generalist to help them.

However, Emerson is more of a regional hospital, servicing the area commonly known as Boston West. The hospital isn’t busy enough to have specialists, so all of the surgeons there have to be generalists. There just aren’t enough wrist or hand cases to support a specialist in that area.

While we don’t have exact numbers yet, our early findings suggest that fewer than 15% of the organizations we’ve studied have the economic conditions that could support user experience specialists. These organizations have enough workload to keep a usability professional just doing research, day in and day out, or an information architect just working on IA issues, etc.

This means the other 85% of the organizations should be looking for people with a broader set of skills. They should look for people who understand the different disciplines and can move between them quickly.

Again, the implications of all this are interesting:

• Do we know how to modify our tools, techniques, and practices, based on whether we’re in a specialist environment or a generalist environment?
• Do we know how to guide potential employees into one area or the other? If someone is expecting to be a specialist, will they be happy in an generalist position, or vice versa?
• Do organizations have the tools to assess their own economic conditions? What happens if they hire a specialist when a generalist was really what they required? How do they know when they are ripe for a specialist? What do they have to work towards to get the demand necessary?

Like yesterday, I think the professional organizations need to play a big role in this. To date, they seem to be content only acknowledging specialization (and in many cases, encouraging compartmentalization). However, I believe they need to realize generalists are an important part of our community. (UXnet could be in a position to make this happen, but, to date, they haven’t seemed to contribute much to the conversation, as far as I can tell.)

Our research will continue to delve into these areas. And, of course, we’ll share what we learn.

Following the Defining the Problem series on Functioning Form, several designers asked how they should go about reframing problems with clients. How could they shift the conversation from an analysis of specific solutions to a broader discussion that better defined the problem they were trying to solve? Perhaps the best way to illustrate such a process is with an example.

Several years ago, I was called in to help redesign the registration process for a large European e-commerce site. The company had put together two options for a new registration flow. Both were compiled by engineering and product management teams and incorporated “best practices” from competing sites. I was tasked with determining which option would work best and to address any usability issues either of the options might have.

Read Luke’s article.

I think some of this comes from a lack of understanding as to how we fit in and what is reasonable to expect from us. After all, these professions are new (compared to doctors and farmers, for example). We don’t have established ways to work yet.

I also think some of it comes from a sense that if we don’t carefully denote our territory, someone else is going to get it in some sort of intellectual land-grab. There’s a floating lack of insecurity about whether we’re appreciated and people understand what we can (and do) contribute. Many of us remember that, when things got tough a few years back, it was these positions that were the first to go. Are we doing what we need to protect ourselves from that in the future?

However, our recent research has lead me to believe that all this professional angst is actually a red herring. We’re focusing on the wrong question. The important question turns out not to be “Who does what?” Instead it needs to be “How are we going to get this done?” (‘This’ being ‘creating the user experience’.)

As part of this research, we’ve been talking to dozens of organizations. Some of these are really excellent at producing high-quality user/customer experiences. Some really struggle to get, what everyone agrees, are mediocre-at-best experiences. A major outcome of our discussion is this realization: you have to separate the notion of discipline from the notion of a professional.

Here’s how we’ve come to think of this:

• Information Architecture is a discipline looking at how information should be organized.
• Usability Practice is a discipline looking at how design effects behavior, which designs produce desired behaviors, and how to measure both the design and the behaviors.
• Interaction Design is a discipline looking at the alternatives to design and how to apply them to different problems.

[You can have your own definitions for the above if you want, but that's not my point, so let's just go with mine, ok?]

In contrast:

• Information Architects are people who practice and study information architecture.
• Usability Professionals are people who practice and study usability practice.
• Interaction Designers are people who practice and study interaction design.

What our research shows is creating a product or service does not require information architects, usability professionals, or interaction designers. There’s plenty of examples of excellent products and services that never had the attention of any of these professionals.

However, our research also shows that successfully creating a product or service does seem to require people who understand something about information architecture, usability practice, and interaction design. We have yet to find a single example of a team who has created a great user experience who lacked a fundamental understanding of these areas.

You can create a great user experience without having the professionals on the team, but not without having the understanding of the disciplines on the team. Employing a professional is one way to bring an understanding of the discipline, but, what we’re learning is, it’s not the only way.

When I think about it, this makes sense. Most of us learned how to do this work on our own. We read books, we talked to others who came before us, we studied the work that had been done. Our passion, our drive, and the opportunity to explore and experiment made us into the professionals we are today.

The teams that aren’t employing the professionals have team members doing the same thing. Not full time and not as a main part of their job. But they are still doing it. While it’s often haphazard and they make lots of mistakes a professional would have the experience to avoid, they still manage to succeed.

What we’re learning from all this is there is not just one way to compose a team destined to produce a successful result. Like most endeavors in life, there’s more than one way to accomplish it. Some will find the employment of professionals the best way to approach the problem. Others won’t.

The implications of all this are actually quite huge and mostly undiscussed anywhere:

• When forming a team, how do you know if your team will require one or more professionals? Under what conditions can you go without? When would going without be a critical mistake? Understanding when we require on-staff professionals and when we don’t is really important.
• If we have lots of “non-professionals” (for lack of a better moniker) practicing these disciplines, how do we transfer the basic knowledge to them? If our goal is really to make the world better, even if we’re not personally involved, how do we put our knowledge and experience out there for others?
• How do we build better ways of measuring results? How does someone know when they’ve done a good job?

Personally, I think the responsibility of answering these questions really falls onto the professional support groups: the Information Architecture Institute, Usability Professionals Association, and Interaction Design Association. To do this, I feel they have to move past the if-you-don’t-hire-us-you’re-an-idiot attitude they tend to project and really start talking about the really hard questions we have before us.

In the meantime, these research findings, if they turn out to be accurate, tell us we have more flexibility to creating high-quality experiences than we first thought.
This is excellent news and I think points to the general trend that experiences are improving overall.

Changing Architectures

Some of the comments were about separating out a change in the look and feel of a site from the underlying architecture. People argued that changing the internals, such as implementing a new content management system, search capability, or advertisement management system, can be difficult to do in a piecemeal fashion, making it very tempting to do an entire overhaul of the site.

This could be true. I’ll be the first to admit that I have very little exposure to that side of the business. However, when we watch our large clients, such as Yahoo!, NetFlix, and Amazon do their work, we know that they’ve had architectural changes that didn’t require a major redesign of their entire sites, at least that any user noticed. So, it’s possible to make those changes under-the-covers, without affecting what the user experiences.

I do realize that possible does not equal inexpensive. Costs may make doing this prohibitive. However, design is all about trade-offs. What’s the trade-off of the costs to support multiple architectures in a staged-roll-out versus the costs of the user experience disruption that comes from a sudden major redesign? That’s the question that needs asking.

Reducing Risk

The main impetus behind my article is about reducing risk. Many have heard me talk about the big-box retailer who, in 2003, spent $100,000,000 on a redesign of their site to find, upon their major re-launch, a 20% reduction in sales they never quite recovered from. (Think what they could’ve accomplished if they’d only spent $50,000,000 on the redesign! And, no: I can’t tell you who they are — everyone wants to know {sigh}. I’ve been sworn to secrecy. If I tell you, I have to kill you.)

A major re-launch is risky because:

• You have a lot of stakeholders – Redesigning the entire site means you have every stakeholder involved. Not just the folks for the major content/application areas, but the folks in charge of the little details, like the investor relations and career folks. That’s a lot of coordination to make everyone happy.
• You have a lot of personas – A major redesign implies that every persona, including the odd cases (a WSJ reporter coming to get information for a story on the quarterly earnings) need to be considered.
• You have more code – A major redesign means touching every part of the code. Longer to implement. More bugs to squeak out. More instances of unspoken requirements that get dropped.
• You are less likely to have a fallback – Often, the changes involved in a major redesign are so extensive they cut off fallback options. If things go very wrong, you’re less likely to have a way go back to the old system.

With a incremental change approach, you:

• Reduce the number of stakeholders to only those players involved in the particular iteration. Less masters to serve means you’re more likely to meet all their needs.
• Reduce the number of personas to only those who are important to the iteration. Again, it’s more likely you’ll create a design that meets those personas needs and increases the chance you’ll come up with something they find delightful.
• Reduce the amount of code, which shortens development time, reduces the bugs needing fixing, and allows teams to quickly identify surprise requirements.
• Keep an easy fallback option, because, rarely, does an incremental change eliminate the option of going back to the previous version if things go horribly wrong. (Plus, when it does go wrong, fewer users feel the impact and smaller code means fixes are easier to come by.)

While a major relaunch is tempting, when you factor in the time spent dealing with all the things that will likely go wrong, the incremental approach is probably less time. And it’s less embarrassing when Murphy raises his ugly face.

Battling the Cultural Forces

Several people commented on the appeal of dumping everything and starting from scratch. Certainly, I can see where they are coming from. Sometimes, if no real thought was put into where you are today, using that as a base might be undesirable. There might be merit to Monty Python’s “Quickly, Quickly, Run Away!” approach.

But I see a flaw in that logic. Our research consistently shows usability problems are caused by developers making design decisions without all the information they need. If you have a site far from meeting its potential, chances are that’s because a lot of bad decisions were made, which implies a lot of information is missing. Where is all that missing information going to come from? How do you know you have all of it?

Designs evolve in a certain direction because of cultural forces. And cultural forces are hard to shift suddenly. As with anything, incremental approaches to cultural shifts will encounter much less resistance.

Picking an important part of the site and redesigning just that portion will more likely succeed because it will meeting less resistance. And when it does succeed, you’ll have learned a boatload about your users, the needs of your organization, and you’ll get the street cred needed to work on making other improvements.

However, the more interesting conversations came later when talking to some VC’s and investors who were looking for new investment opportunities. Things livened up when I mentioned how our research was showing that people are less and less accepting of advertising. And they got really wild when I shared how our research is convincing me that advertising’s days are numbered.

Traditionally, advertising was based on a foundation which turns out to be a house of cards. Since the first days of newspaper advertising, it’s been accepted by everyone that advertising is non-accountable. Advertising works, based on faith in the premise that if you put an ad in front of enough people enough times, they spend money. But everyone knows accepting the premise is hard. In fact, if you talk to anyone in the advertising business, they can recite the joke often attributed to Philadelphia merchant John Wannamaker: “I know half my advertising budget is wasted. The trouble is I don’t know which half.”

Except that it’s not a joke. And it’s likely it’s not half. In fact, I’d be willing to bet it’s more like 80%-90%. Trillions of dollars a year are spent on advertising and it’s been generally accepted that half of that money (and likely more) is doing no good.

What if you could actually find which dollars were going to be a waste before you spent them? That’s what’s happening in the world of advertising. New techniques for measuring the effectiveness of advertising (a movement cleverly called “accountability”) are appearing every day. On the Ad:Tech exhibit floor, dozens of companies had methods to track and measure whether every dollar spent on an ad turned into a sale. All of a sudden, we can now start to see which ads are working and which ones are waste. And, as we predicted, most of them are waste.

If you watch users interact with web sites containing advertising, you quickly notice how the users develop techniques to avoid looking at the ads. We’re not the only ones seeing this. Anybody who watches users with an eye tracker (this may be the one good use of them) on pages with advertising can see how users avoid looking at the ads. Others have seen how users even avoid looking at the innocuous Ad-sense ads that populate many sites.

This isn’t just on the Internet. People buy DVRs so they can skip ads on TV. They rent movies and TV show DVD collections to avoid sitting through ads. And now they download $1.99 shows from iTunes so they can watch a 1-hour show in 42 minutes.

So, with these new tools for accountability, we can see where the waste is happening. And, from what we’ve seen in our research, it’s happening practically everywhere.

What happens when accountability is discovered by the bean counters?

For years, those-whose-job-it-is-to-say-NO have been told to trust the premise. Since advertising was all there was, when you removed it, you saw revenues drop. So, it was easy to say, “OK, there must be something to it. I’ll trust the premise.” And they did.

But now, we have new tools. We have methods to say which ads are working and which ones aren’t doing anything. And we’ve realized advertising isn’t all there is.

So, what happens when those-whose-job-it-is-to-say-NO discover this? They’ll start saying No. “No, we won’t spend money on things that aren’t working.” And, eventually, I predict, “No, we won’t spend money on things we can’t measure.”

And that’s the day we bury advertising.

So, where will those trillions of dollars go? Into a better marketing investment, I believe. And that investment will be improving the customer experience.

If you look at any study in the last ten years about how people are influenced to make purchases, you’ll see the biggest contributor isn’t television or radio advertising. It’s not the animated ads that float across your screen when you’re trying to do something else. It’s not billboards or direct mail. It’s not celebrity endorsements or having a logo featured on a NASCAR race car.

It’s word of mouth. What other people say is the best influencer on purchases. If I’m your friend and I go on-and-on about how my TiVo has changed my life and how anyone who loves TV needs to own one of these devices, you start to take the idea of purchasing a TiVo seriously.

And what would make me go on-and-on about my TiVo? Not a great ad. Not a celebrity endorsement. But a great experience.

If I actually find the TiVo does change my life, I’m more likely to tell people about it. And the more people whose lives are changed, the more people are out there spreading the word of mouth.

Word of Mouth Marketing is huge right now. And, at the core of it, is a new premise: you have to give people something to talk about.

Netflix discovered this when they realized 93% of existing customers regularly evangelize their service. Why do Netflix customers love Netflix so much? Because of the total customer experience. A great experience is the best marketing investment they could’ve made. This is why Netflix now has twice the market cap of Blockbuster.

So, I believe advertising is going to die. (And I’m not the only one say this.) It’s only a matter of time. And with the rate of technology feeding the accountability movement, that time is getting closer fast.

Last week, we sent out the first part of our interview with Luke Wroblewski, author of Site-Seeing: A Visual Approach to Web Usability and UI11 speaker, on the topic of where usability meets visual design. (You can read the first part of the interview here. ) This week, we continued the conversation with Luke.

Are you seeing benefits when you combine visual design with usability in your designs? What challenges are you facing trying to make that happen? Join the discussion below.

Luke Wroblewski will be presenting his full-day seminar, Site Seeing: Communicating Successfully with Visual Design, at the upcoming User Interface 11 Conference in Cambridge, MA on October 11. You can read about Luke’s session, along with the other great full-day seminars, here.

Read the article here.

Enjoy your holiday weekend!

Last night, in a phone conversation between David Malouf (the interaction designer formerly known as Heller), Bill Scott and myself, David shared he took a page out of Yahoo’s book and has been using something similar to Yahoo’s new home page tour.

Yahoo! just launched their new home page and with it created a tour.

Click to see the Yahoo! Home Page Tour.

The tour shows the new home page with various new elements annotated with callout bubbles. Mousing over one of the bubbles provides a larger callout with more information.

The Page Options callout from the Yahoo! Home Page Tour

David’s idea was to use a similar mechanism to annotate new designs his team was conceiving. Creating a static page, with mouse-over callouts gives a quick and easy way for people to understand the new design.

That David guy is pretty smart, I thought.