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.

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

However, where I think Mr. Gruber gets it wrong is the value to the internal design team. The Apple Knowledge Navigator created a ton of discussion internally and set the company off on a 23-year journey that now brings us some amazing technology, which was impossible to imagine back in 1987 when the video first came out.

When an experience vision, like the Knowledge Navigator video, works, it gives the teams a chance to ask the question, “Am I getting closer to that design?” with every decision they make. It helps the team, as a whole, understand where it’s trying to go.

When teams don’t have a vision like that, each person is walking around with a different understanding of what the end of the journey should look like. When there’s no common understanding on what that end point looks like, each decisions is evaluated on a different criteria and the resulting products end up looking like crap.

I think the Microsoft and RIM videos are interesting. However, there’s too much in there. Apple’s Knowledge Navigator was simple in its delivery, covering only a few concepts. There are so many concepts in each of these new videos that I find it hard to believe the design teams can talk about what they are really trying to say.

I’m also betting that Microsoft and RIM have made classic mistakes: the visions represented in these videos are not put together by the teams that will be working towards them. They were likely created by marketing folks (and, even more likely, by outside agencies with no connection to the internal product development and design teams). It’s possible that the developers and designers at these companies saw the videos at the same time we did.

Unless the design and development teams have a voice in what their future is, they are unlikely to buy into it and will probably take their designs in a different direction. Team collaboration on the vision is critical for success.

I don’t think these visions need to be publicized to be useful. And, as Mr. Gruber asserts, it’s brings into focus the failings of the current products when they do.

However, there is real gold in having a solid vision and these videos can be a great way to represent that vision within the organization.

This is a sample of Lou Rosenfeld’s, Beyond User Research, from the 2011 IA Summit.

UX professionals have made a lot of progress in large organizations. Companies realize the importance of connecting with their users more and more. User research is becoming firmly rooted as companies strive to produce better products and services for their users. But user research itself can be narrow in focus and full of biases. Lou Rosenfeld of Rosenfeld Media, suggests that by breaking down the silos that exist between other research practices, we can create a complementary research experience. This will produce even better analysis and therefore, better products as a whole.

In an attempt to map out organizational structure, Lou offers a set of dichotomies. In terms of research, web analytics folks and UX professionals both bring important insights to the table. But they focus on different things. It’s this separation of insights that lead to the silo effect. Even though these insights would be completely complementary, the cross-pollination that would require this enhancement to the research often is not occurring.

It boils down to the differences in how people think. User experience people tend to shy away from quantitative data and take a more qualitative approach. Neither is a bad approach to take, but the differences between empathetical and analytical thinking, for instance, provide vastly different results.

By combining the efforts of these different practices we can arrive at tremendously useful insights. For example, Lou explains that by adding data to typical personas you can enrich them and enhance the design process. The personas may then align closer to the analytics data simply by adding what they would search for, resulting in a deeper understanding of your users.

Lou is presenting a UIE Virtual Seminar, 8 Better Practices for Great Information Architecture: Closing the Findability Gap on November 3. There are new opportunities for Information Architects to add significant value to projects. There exist new metrics for measuring engagement with your site visitors. These measures will guide you towards design decisions that let your users find what they’re after. Learn more about Lou’s seminar.

This podcast was recorded at the 2011 IA Summit. For details about next year’s summit, visit IAsummit.org.

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

Full Transcript.

Lou Rosenfeld: We have this fragmentation problem which I’ve already said things live in silos not just content but now insights that ought to help us figure out what to do with content and other design issues.

We’ve got differentiation. We don’t really understand what that CRM stuff is about. I’ve never seen one of those things before. Yet, I sense it might be good to look at if I’m doing any kind of design work.

And then most importantly this combinatorial issue, the synthesis of all those insights into something that approaches an organizational brain, an organizational or institutional way to make smart design decisions.

So that’s kind of what we’re facing. In my limited experience with this, I’ve tried to map it and I think a lot of us are pretty good at doing this sort of mapping of an organization and how it works. It’s almost like the same sort of urge that we use, that got us into doing things like site maps and wire frames.

I came up with a bunch of dichotomies. I couldn’t map it so let me run through some of these dichotomies. What I’m finding is, there’s a lot of people who are really good at figuring out what is going on and there’s a lot of other people often not the same that are really good at figuring out why those things are going on.

So for example, people draw on information that comes from analytics research, the quantitative data. They may learn something really interesting. But it’s all behavioral stuff. They don’t really know what was going on in a user’s head.

They can draw up and infer interesting hypothesis but they can’t test those hypothesis. That’s something that people who are really good at doing user studies for example like a lot of us, are really good at.

We, on the other hand, aren’t always so good at knowing the right questions to ask. And I’m kind of going to start focusing a bit on two areas of practice, web analytics and user research but these are the ones I know best.

This is really even more complex when you introduce all the other perspectives but let me just focus on these two. A lot of web analytics people can tell you what is going on. They can’t tell you why. A lot of us can tell you why things are the way they are but we don’t know what to test necessarily.

We don’t have the right questions to explore without the data to help us figure that out. There’s a whole kind of a breakdown between qualitative and quantitative people. I love this diagram with the two brains in there. I wish I had come up with it.

I’m not sure how well you can read it but numbers versus emotion, analysis versus empathy, the brain versus binky? Is that what it is? So you know, we have different ways of looking at problems, different ways we try to solve problems and we often are comfortable with different types of data or evidence to help us solve those problems or at least to help us understand what the problems might be.

So that’s a big breakdown. A lot of what I’m saying right now, I’m trying to make a point and by making that point, I’m going to over generalize quite a bit but I think a lot of us kind of would fall into one of these categories.

I don’t know that anyone is equally comfortable with qualitative and quantitative data. I’ve met very few people that seemed to be able to do that. In many cases, I think some of us make for qualitative studies because we’re really uncomfortable with quantitative data or vice versa. It’s just the nature of how our minds work and what we’re comfortable with.

A lot of us are in the business of making sure our organizations reached their goals. Web analytics people as an example, they express goals as KPI, things that are measurable, key performance indicators.

A lot of us in this room have been trained to think more on behalf of the user and what their goals are and how to identify them and make sure they’re using them. Sometimes those things are very easy to mesh together especially in commerce sites for example. Often, they’re not.

We have to resolve these things but we’re not always so good at it because usually, whoever is making the decision has a bias in one direction or the other. In effect they’re thinking with half a brain.

I think a lot of us are really good at measuring the world that we know. Certainly, again, on the analytics side, you start with your KPI based on metrics and you say, “I’m going to look at all that data and figure out whether we’re performing against the goals that we’ve set out for ourselves as an organization.

Are we doing well? Are we not doing well? Contrast that with looking at data for patterns, looking at data for things to emerge that were unexpected. That kind of emergent data analysis is really looking to learn about the world we don’t know and therefore we don’t know how to measure.

And then yet another, I’m sure there are more dichotomies. There’s a breakdown between the comfort level and understanding of statistical data versus descriptive data and you could have people who make very strong arguments, garbage in, garbage out in both cases and they’d both be right probably in both cases.

But that’s not how they see it. Usually, we have a bias toward one direction or another. We like one, we like the other, usually not both but they tell us very interesting, but different things that often fit together nicely, as we’ll see.

I’ve tried to, like I say here, reduce this to a very over generalized, over simplified set of dichotomies that I’ve just gone through. This is just a summary of what those are. And this is just for two areas. This is just for web analytics and user experience.

But if you look at these, I hope what you’re starting to see is not just the differences but the fact that they come together quite nicely, that they’re very complimentary. That’s where that’s where combinatorial effect that’s coming in where the insights that one has fit quite nicely with the insights of the other.

Now, I can’t map this. It’s just not in my wheelhouse but I bet some of you could. What I’m really hopeful for is that someone like Alex Osterwalder who wrote the Business Model Generation book. Is anyone familiar with it? Fantastic.

He actually created and published it with a bunch of people, created a whole new business model around publishing just to do one book. Amazing. But he did a whole bunch of mapping of essentially business models. It’s over simplified but damn it, it’s useful.

We need something like that to take all these types of insights and put them together in a way that would be really useful for us especially making design decisions. So without a map, why bother even trying?

You know, if we can’t map, this is really a hard problem, what’s the value of jumping in? Well, for one, we can really, really learn quite a bit from each other’s data, right? So let me give you an example.

This is one of my favorite things in the world. It’s a little bit of site search analytics code little snippet of stuff. All you really need to know is that if you look at it, the orange stuff like “vincense plate” is what was searched.

There are a few other things that you can maybe figure out, an IP address so you know who it is, the time-date stamps, you know when it happened. The zero next to the last bit of information is how many search results there were.

Now, look at another line. Same time, roughly two seconds later, same IP address. Now they’re searching license plate and I got, I think it’s 146 results. Interesting, what’s going on here? Maybe they spelled it right but well what happens next?

Oh, it’s a different user and they’re searching on a real mouthful. This is a state government site and this user was searching that site for Regional Transportation Governance Commission. People search things that long? They know what those things are even called? Do you know what government agencies are called?

As you’re looking through this, I bet you each one of you are already putting on your analysis hats and saying, “You know, obviously typos are an issue. How would I fix that problem? Maybe I would turn on the spell check on the search engine.”

Now did they get what they wanted when they were searching on the license plate or not? You don’t know. Is that a common thing that people search and what about this mouthful in the last line?

Basically, each one of us should probably have a whole bunch of different ways of looking at this data and we would start ferrying very different hypothesis, just a couple of examples.

I think a lot of people from, to over generalized analytics community, would be wondering things like are we converting on license plate renewals. A lot of other people like me would be saying, “What are people searching for the most? Is it license plate coming up a lot?”

If so, are we giving that information very easily, are we presenting it on the main page so they can renew their license plate easily and so forth. So we look at the same data, tiny little snippet of data and we probably are all starting to come up with different conclusions or at least different hypothesis and thinking about what we do next differently.

What the next action would be could be very different if you’re looking at this as an interaction designer versus an analytics person versus a content strategist. Another way we can really benefit each other is by helping improve each other’s design tools.

So I grabbed an Adaptive Path persona and you know again, I love site search analytics but there are lots of other types of analytics out there that you can do this with but I threw some site search analytics data in there.

So you got your typical persona stuff, right? And then, why don’t we add some data? Wouldn’t that enrich in a new way “what does Steven search?” Now I can actually go to my analytics people and say I could use some of that data.

In fact, maybe my personas might match up well with your audience segments. Maybe you can start putting these things together in some new and far more powerful ways. We can really help tell each other’s stories.

I love this example. Adaptive Path again, Jeff Veen and a team were working on a product to make analytics data more easy to understand. I think it’s called Measure Map. Is that right anyone? Measure Map.

Google liked it. In fact, Google basically bought Measure Map but they really bought the team. And they’d already purchased the analytics application that they were going to make into Google Analytics but they wanted that team to work on it, to help tell the story of the data in a way that maybe someone from the web analytics world wouldn’t have thought.

Back in 1987, Apple (under the direction of John Sculley, not Steve Jobs), released a video of what Apple products could be like in the future. Called the Knowledge Navigator, it showed a sci-fi mythical tablet computer from 23 years in the future (yup, 2010) that the user talks with to get things done.

Fast forward 24 years and Apple releases Siri with the new iPhone 4S. Siri is an assistant that takes voice commands and acts on them. If you haven’t seen Siri, here’s a demo.

Now, as far as I know, Siri is only available on the iPhone 4S. However, that’s likely temporary, as I don’t believe there’s anything that prevents it from showing up on other platforms, like the iPad.

And once it shows up on the iPad, Apple will have fulfilled it’s 1987 quest. All the components of the original Knowledge Navigator are now available and for less than $500.

In ’87 — when we all used big, boxy CRTs on bulky, loud, slow desktop processors without any notion of communications beyond 9,600 baud (14.4 came in 1991) — there was no way you could have a small, tablet computer to do all the things in that video. Knowledge Navigator was complete science fiction to everyone at that point. Computers couldn’t speak. You couldn’t imagine face-to-face video conferencing across the planet, let alone collaborative workspaces. None of that had been invented yet, except as sci fi.

Yet, if we look close, it’s the path Apple has been on for 24 years. We’ve seen the baby steps. With the introduction of the Mac Book, then the iPhone, followed by the iPad, we got our table. The interwebs provided the connectivity, where Apple focused on its Airport wireless products to get the components tiny. Innovations like built-in cameras and Facetime made the video conferencing a reality.

And now Siri completes the journey. Siri isn’t quite the bow-tied dude who can order a cake for your mother’s birthday party, but it’s damn close. (And I’m not convinced we need avatars to believe the computer is speaking. I think Second-Life ruined avatars for everyone, except those who enjoy online virtual sex.)

In 1987, when Apple first released the video, they received a fax (!) with a purchase order for the Knowledge Navigator. Now they can finally fill the order.

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

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

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

Here’s an excerpt from the podcast.

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

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

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

Tune into the podcast to hear Kevin address these questions:

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

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

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

Full Transcript.

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

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

Kevin, how are you doing?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Jared: I think that’s really neat.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kevin: Yeah. Exactly.

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

Kevin: It was my pleasure.

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

More and more, we’re finding ourselves in situations where the design just “has to be right.” No longer, can we just have incremental feature enhancements or small improvements in the design. Our users need to be wow’d and delighted. And adding large fonts in bright colors with rounded corners will only take us so far.

To truly delight our users, we need to dig deep into what is meaningful and valuable to them. Give them something that resonates and they will jump for our design.

We can discover those resonance points by taking our research into the field. We meet the users in their own environments, observing them as they live their lives and do their work. We bring back oodles of data, which, once we analyze and synthesize, we can reveal the delightful essence of new designs.

Steve Portigal has traveled all over the world to do just that. He’s spent thousands of hours in people’s homes, offices, and the other places of their lives, just to learn more about what will delight them. His work with design teams has taught them to mine their rich data sources and uncover a wealth of value and meaning to design for.

Steve’s full-day workshop at UI16 will take you through the entire process. Prepare for a hard day of work, which starts with a real field visit. You’ll bring back observations that you’ll work with for the rest of the day. Under Steve’s expert guidance, you’ll learn the best methods for interviewing users, analyzing the data, and synthesizing the key meaning.

You’ll be ready to head right into the field the moment you get back to your office.

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

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.

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

And it may surprise you to learn that I refuse the offer every time. As a policy here at UIE, we only take on work we can guarantee results from. I know from experience that I have no chance in hell to convince any executives of anything, so I politely decline the gig.

“But surely, because of all your success, you must know what it takes to convince an executive to invest in UX?” they always ask.

Actually, I don’t. I’ve been pitching our services for 23 years and I’ve never once successfully convinced an executive of anything.

Our success has always come from projects where the client team, including the senior management, already understood the value of great user experiences. I haven’t convinced them because they didn’t need convincing.

Have you ever met a smoker? Of course you have. Have you ever met a smoker who didn’t know the harmful effects of smoking? I bet not. Every smoker I know is well aware of what smoking does to their bodies, yet they continue to smoke. There are physical, cultural, and behavioral forces that make it hard to quit.

You can’t convince a smoker to quit smoking. They need to just decide they’ll do it. On their own. When they are ready.

It’s the same with executives. Neither I, you, nor anybody else can convince an executive to invest in user experience.

Sure, there may be a few execs that are somehow still unaware of how a delightful, useful, easy-to-use product is better than a frustrating, useless, difficult-to-work product. I haven’t met one in all my years, but they could exist. Even so, I don’t believe a presentation will change their views.

What can you do instead of a presentation?

You can find out what your executives are already convinced of. If they are any good at what they do, they likely have something they want to improve. It’s likely to be related to improving revenues, reducing costs, increasing the number of new customers, increasing the sales from existing customers, or increasing shareholder value.

Good UX can help with each of those things. The problem is that there is no generic, always-saves-the-world process or solution for any of these improvements. If you wanted me to help, I’d have to study your business in-depth to learn how to make improvements in these areas through solid UX investment.

(That’s a project we’ll accept AND guarantee by the way. We’ve done it before, many times. It’s expensive, but it produces great results.)

Once you start talking about what the executives are already convinced of, it becomes easier to get them to make investments. You’re no longer trying to get them to change their focus. You’re playing directly into their main field of attention.

A generic presentation about how Apple or some other company has a great user experience program (or worse, a presentation showing all the bad user experiences in the world), won’t convince anyone of doing anything different.

You’ll need to do something custom. Something specific to their current focus.

And if that doesn’t work, maybe it’s time for you to find someplace else to work. Someplace where the executives are already convinced and want to make the investment. Right now, there are plenty of these opportunities on the market. Why bang your head against a wall when you can be doing those things you love?

Mike Lee has to face this challenge. Mike is the Senior Digital Strategy Advisor at AARP. With much of the organization’s 53-year heritage being within “traditional” media realms, shifting its publishing and broadcast businesses into the online world is no small task. In this podcast, Mike joins Jared Spool to discuss some of their design challenges. They also discuss the ways AARP has transitioned to the web, and how they have been exploring and taking advantage of mobile and tablet technologies.

Here’s an excerpt from the podcast.

“…obviously we know and we look very carefully at what the ROI is on the paper side, and I think the inertia that is behind this machine is at least two faceted. One is a good piece, it’s to say, well, it’s working and we’re pretty sure that this mode of doing the paper piece is going to be useful and engaging and accepted for a five to 10 year time frame.

But, for example, our numbers tell us there are about five million members with smart phones. And that number is only going to grow. Our mobile traffic, which is still in the single digit percentages, is showing its 70 percent IOS devices and 20 percent Android devices.

So that number, if it’s five million now out of nearly 40 million members, as it grows, will start to be really interesting and impactful when you start to get into the teens and the 20 percent share. Here’s this group that prefers digital and they want the green, sort of, membership, they want to opt out of paper. We’re not seeing a big rush to that yet, but, I think it’s only inevitable. And we’re seeing that that’s an opportunity.

So, as great as a paper magazine is, and it doesn’t need a battery and it doesn’t crash, and (it’s) ultra high resolution, and you can bookmark it really easily. (It) has page numbers, which the Kindle just only recently added, right?

Digital engagement is extremely compelling, because the person can engage with the organization from wherever they are. And if we do our job correctly, it’s offering the tools that they need, wherever they may be standing…”

Tune into the podcast to hear Mike address theses additional points:

• How do you get an organization as old as AARP to begin to think about new technologies?
• Do you find that you have to argue for good user experience?
• Do you have a dedicated user experience team?
• Are people talking about user experience closer to the beginning of projects now?
• Has there been a change in energy level amongst management teams when it comes to the idea of user experience?

Mike is also one of the Masters joining us for the 2011 Web App Masters Tour. We’re coming to Seattle in May and Minneapolis in June. For more details such as dates, pricing, and agenda, visit UIEtour.com.

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

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

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.

Subscribe to our podcast via

Effective communication is the basis for keeping your team organized. But how can you be certain that everyone in your organization is on the same page when it comes to business goals, objectives, and the user experience perspective? Using personas can set you in that direction and Tamara Adlin specializes in just that.

Tamara is the founder of adlin, inc., a customer experience consulting firm. She is an expert in developing personas and has written two books on the subject, The Persona Lifecycle and The Essential Persona Lifecycle. In her Virtual Seminar, The Power of Ad Hoc Personas: Truly Practical Methods to Get Your Organization on the Same Page, she ran short of time to answer all the questions. Today we bring you the follow up podcast with Jared Spool and Tamara answering those remaining questions.

Here’s an excerpt from the podcast.

“…I just don’t think that it works to have personas thrown over the fence. You can certainly go hire somebody to do a bunch of market research and a bunch of behavioral research and come back with shiny documents and big posters and whatever.

But I just don’t think that works. You have people still thinking the words “enterprise” and “small business,” and if you don’t get that stuff out it will never disappear. And the only way to get that stuff out is to have people convince themselves that it’s not so great, it’s not as useful as they thought.

However, if you’re using them to try to mirror back to execs what you think you hear them saying – the trick that I use is, “Well, let’s imagine this person,” like you said, Ahmed, “(he) is a program manager and has to manage this incredibly remote team all over the world and somehow has to have our product to do that. Isn’t it true that if we don’t satisfy him, we failed? I mean, isn’t he right smack-dab in the middle of the people that we’re trying to help?”

And people will say, “Yeah.” So, it’s not a matter of saying, “He’s the most important.” It’s more like saying, “If we don’t satisfy this dude, what are we doing?” Isn’t that true?…”

The real value of using personas comes from the ability to mirror back what you think is being communicated and arrive at that common understanding. This can be difficult. You need to show the issues that need addressing in the first place. As Tamara states in the podcast: “You all can’t be on the same page if there isn’t a page”.

Tune in to the podcast and hear Tamara address these questions as well.

• Don’t the stakeholders in the meeting need to know the consumers before they can make assumptions about building personas?
• How do you get the stakeholders in the room? How do you get the boss and the grand-boss and the great-grand-boss to participate?
• Does this technique make sense in a remote environment? Can you actually create personas remotely?
• Does the ad hoc persona technique lend itself well for creating a customer experience in services oriented organization?
• Can personas align with marketing segments, or is it something completely different?
• How do you sell ad hoc personas into a project where they’ve been down that road and it was a complete failure?

Please feel free to share with us any of your own experiences with personas and any other thoughts or questions in our comments section.

Subscribe to our podcast via

Design has made a lot of progress in the corporate landscape over the past decade, but many designers still find themselves justifying their existence on a fairly regular basis. Most companies, even those who claim to value design, aren’t taking full advantage of what design can offer them.

In Kim Goodwin’s talk, “Getting Design Into the Corporate DNA” from the 2010 User Interface Conference, she explains that it’s a matter of changing the culture of your organization. Kim understands that this is one of the most complex design problems you will ever have to face, but she can also tell you how to set it in motion.

One of the issues, as Kim points out, is that most businesses have a unit efficiency focus. This causes people to look inward and not share responsibility. It ends up promoting a lack of cooperation as turf wars develop and people begin competing for resources to ensure that their unit, department, or team is doing well rather than the company as a whole. This creates silos within the organization.

The alternative is a user-centered focus, but getting to that point isn’t easy. Kim concedes, shifting the way the entire company thinks is a daunting prospect. But she offers that organizational change is actually, in fact, individual change. She says to think of organizational change like moving a series of pebbles and boulders instead of the entire mountain. The organization is made up of individuals and shifting the organization is a matter of moving those individuals.

But it could be even more attainable than that. As Kim says, “Think about starting an avalanche. If you roll the right rock down the hill, it’s going to start taking others with it. You don’t personally have to touch every rock.” She encourages you to seek out the most influential “rocks” in your organization.

In order to bring change about, you need to be persuasive. Kim mentions that one of the greatest tools of persuasion is the users. She says that getting executives in front of users more often is one of the best ways to get them to begin to think differently about design. The more user exposure that you can get the more they will see the benefit of the design process.

You can also look for teachable moments. By that she means, look for a way to convey any unhappiness or dissatisfaction that your users may have. Then show how design can help improve the problem and give a clear way from Point A to Point B. In the end, it’s human nature to view change as loss. Exhibiting how design can improve things will help alleviate that sense of loss.

The audio to Kim’s full talk is available for purchase with all seven other Featured Talks from the conference as part of UI15 OnDemand. Also included are the handouts and presentation slides from the talks as well as the slides from the each presenters’ full day workshop. Get more information or place your order for UI15 OnDemand.

Have you experienced difficulty illustrating design’s value in your organization? Feel free to share your experiences in the comments section.

The article quickly became one of the most popular articles we’ve ever published. People love the fact that a small design change could be linked to a huge increase in revenues. It’s the ultimate ROI story.

Yet in our research at User Interface Engineering, we see these kinds of increases all the time. And $300 million isn’t anywhere close to the biggest.

In today’s UIEtips article, we look back at another article from 2009. Here, I talk about a design element whose income contribution is possibly 10 times larger. It’s a simple question on the Amazon site—one you’ve probably seen a thousand times—yet it is critical to the success of the business.

Unlike the previous story, where we worked on the project, this story comes from our research of Amazon, independent of any projects we’ve done for them. Therefore, our revenue projections are estimates this time. But even if we’re off by an order of magnitude, it’s still an impressive number that tells us how a well thought-out design can make a big difference.

Read today’s article, The Magic Behind Amazon’s 2.7 Billion Dollar Question.

Increasing the effectiveness of a design is exactly what we’re talking about at the UIE Web App Masters Tour. We still have stops in Philadelphia and Seattle. Learn more about the 9 Masters presenting in each city at www.UIETour.com.

Have you had any design changes that had a big impact on your organization’s bottom line? We’d love to hear your stories. Share your thoughts below.

Until May 21, register for Philadelphia or Seattle and get $100 off when you use the promotion code TOURBLOG. Learn more about the tour at www.UIETour.com

Subscribe to our podcast via

Ken Kellogg

There’s plenty of pressure on web designers to groom the corporate website. You have the politics of keeping stakeholders happy and the responsibility of rolling out improvements that don’t decrease revenues. But what if your website was responsible for $6.5 Billion of revenue last year?

Such is the life of Ken Kellogg, the Director of User Research at Marriott International. Ken leads the user research team that is responsible for the experience 12 million people a month have at Marriott.com. The first day on the job, Ken received the first directive: Do No Harm.

In this podcast, Ken discusses with Jared Spool how he:

• Navigates the design process from within a large corporate world
• Partners with his executives to gain access to the most useful tools
• Keeps the site moving forward with a lot of customer research.

Ken starts by telling us the genesis of the current redesign project at Marriott:

Our research kept telling us that we might be missing out on a key segment—and those are folks that are a personal traveler, a leisure traveler. Of course, a business traveler can be a leisure traveler anytime. But, we’re really thinking about folks that don’t normally travel for business, or a spouse of a frequent business traveler who wants to plan a vacation.

What we were seeing over and over was these folks would come to Marriott.com and they’d get lost. One of the old rules about usability is you never get two chances to make the first impression. If someone gets lost, they will go some place else, that is still the truth. Everything kind of started from those two facts.

The needs of their main customer, the business traveler, are somewhat different from the leisure traveler. They had to find a way to cater to this group without alienating their bread-and-butter demographic.

…one of the first things that you’re indoctrinated with when you start working in e-commerce at Marriott is that you do no harm. It’s the Hippocratic Oath. You do not hurt the frequent business traveler. So, we have painstakingly done our best to make sure that we don’t put any stumbling blocks or any delays in the paths of our frequent business traveler.

Ken has a lot more to share in this podcast on the research and decision process that went into the redesign. And Ken’s presentation at the Web App Masters Tour in San Diego, Care and Feeding of a Corporate Cash Cow, received rave reviews. You can still catch him at our Minneapolis, Philadelphia or Seattle tour stops.

Want to learn more from Ken? See his session – Care and Feeding of the Corporate Cash Cow at the Web App Masters Tour

Are you designing within constraints of a large corporate environments? How are you bringing innovation to your site, while coloring within the lines? Let’s hear about it in the comments.

One of Brian’s comments jumped out at me:

We took our knowledge and created, in a warehouse in San Francisco, an entire lobby made out of white foam core. We built it to scale. Then we brought in consumers to get feedback on the overall experience of the space. We didn’t want feedback on color choices, like blue versus red. Instead we wanted feedback on using welcome pedestals, rather than a clunky front desk. Our associates circle around the space rather than standing in one place, and we wanted customer feedback on that. And the foam core allowed for rapid prototyping. After we got user feedback, we could rip it apart and build it again to get the concept right.

It’s one thing to talk about the abstract notion of protoyping a web page or a dialog box. But to prototype an entire lobby experience? That’s pretty cool.

Not too different than what Apple did with the Apple Store. Who said an old-tyme business like Marriott can’t play the same game as the cool kids. See? There’s hope for us all!

Read the entire interview.

(Hat tip: Dana Chisnell)

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.

Interaction with a product is more than how it’s used or how it behaves. It’s about a connection between two sides. One side is the customer, but the other side is much more than a product or service. To many people, the character and essence of a product and its company are identical. So, what is the essence of your product?

When your product behaves like a machine, your company is perceived to be a machine. It’s just another company – rigid, mechanical, and cold. Yet when your product displays a bit of humanity, your company gains a face and becomes another human.

In this webinar, you’ll see examples of how humanity exists in the design of products and services through humor, personality, and emotion. You’ll explore how just a little extra design effort and thought beyond functional needs can enrich the experience, reveal the company behind the product, and forge enduring connections with customers.

This presentation generated quite a buzz at Web App 2009. It’s a talk that’s sure to get you thinking
about your products, and how you foster the connection between your products and your customers.

In advance of the presentation, we’d love to hear from you. How do you gain an edge with your products? How does your organization show its humanity? Share your thoughts, questions, and concerns below.

Take that two-way communication out of your process, and the design that emerges from the development process doesn’t work the way we thought it would.  You increase your development costs, and deliver a product that’s lost all of it’s interactive goodness.

Unless you’re doing your own implementation, practically impossible for a serious production application, you need to find a way to succinctly communicate what’s important and how it should all work. In this week’s issue of UIEtips, I bring back an article, Getting the Most from Design Deliverables, that discusses how the best design teams go about successfully communicating their ideas to the development team. I think you’ll really enjoy it.

Also, we think this article ties in nicely with our upcoming UIE Virtual Seminar: Comps vs. Code: Case Studies on Collaboration Between Site Designers & Developers with Ethan Marcotte.  On July 30, Ethan will use four case studies to teach some insightful lessons about the collaboration between designer and developer. See a preview.

How do you hand off projects at the transition phases in your organization? What types of reviews do you build into the transitions?  Join the discussion below.

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. 

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.

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.

In this presentation, Jeff Patton will discuss the essentials of Agile Development, the distinct culture and value system that Agile brings, and the common Agile process you’re likely to see. You’ll hear about the myths of Agile and common pitfalls organizations tend to encounter. Armed with the foundations, you’ll explore some emerging UX practices and how to thrive within an agile process.

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!

In advance of the presentation, we’d love to hear from you.  What are the scary stories you’ve heard about Agile?  Do you have success stories to tell about iterative development?  What hurdles would you face bringing such a discipline into the culture of your organization? Share your thoughts below.

Determine if this seminar is right for you and your team by reviewing Ginny’s ’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!

In advance of the presentation, we’d love to hear from you. Have you ever struggled with writing something for your site? How do you know you got it right? What rules do you follow for creating effective copy? And what are your thought on how to handle those “marketing moments”? Share your thoughts below.

In design, it’s no different. Inevitably, great design is about producing both long and short term value for the organization. Something that is well designed not only delights the users but shows up positively on the income statement.

We’ve been looking closely at the practices of some great organizations and one of the common threads we see is how well they match their design goals to the priorities of the business. This is especially important in tight economic times, when the organizations are looking to cut anything that doesn’t show immediate value. The best teams have put this practice into place.

I talk about these priorities in this week’s UIEtips article, A Recession Strategy For Web Apps, and how understanding them becomes important for any designer. While the article focuses on web-based applications, it can be applied to almost any design project.

Part of succeeding in a hard economy is to ensure your team has the necessary skills to make you best of class. That’s why we’ve put together an awesome program for our upcoming UIE Web App Summit, April 19-22 in Newport Beach, CA. Register by Wednesday, January 7, 2009 to get both the lowest price available and your own Limited-Edition iPod nano.

We love to talk to Steve Mulder (from Molecular) and Riccardo La Rosa (from Isobar) about building out a Web 2.0 strategy and incorporating elements, such as social features and highly-interactive elements to the design.

Steve and Riccardo work with mainstream organizations, which may not be as familiar as, say, a Silicon Valley startup with what the state-of-the-art is for these types of features. In this interview, they told me about the solutions they worked on with Reebok (a sports apparel company) and HumanaOne (a direct-to-consumer health insurance company). We talked about the challenges they faced on these projects and what they needed to do to overcome them.

During the podcast, we discussed how to determine what features to build, how to tell if the features are working as expected, and how results changed over time. We talked about how starting small and iterating is most successful, but not an easy sell in many situations. You’ll want to listen to hear how they overcame this challenge and other Web 2.0 adventures they had.

Enjoy the podcast? Well, you can join Steve and Riccardo for their UIE Web App Summit full-day workshop, Web 2.0 Strategy and Design, and learn how to apply the elements of social media, openness, rich interfaces, and emerging digital interactions to your designs.

Interestingly, the theme of how to learn from failure was pervasive throughout the conference. Dana Chisnell talked about how to extract takeaways from usability tests. Jeff Patton discussed techniques for learning during the iterations of an Agile development process. Peter Merholz presented his challenges for organizations. And I discussed how teams need to celebrate failures, so teams have a chance to savor the rich insights that come from them.

It turns out that it’s no accident people are talking about failure these days. Over the last few years, our research has shown that the organizations that embrace the mistakes they make are more likely to show growth and improvement in their designs. That’s the great paradox: failure is strategically important to success.

In this week’s UIEtips, I describe how one nameless client got themselves into big trouble, how Amazon.com minimizes the risk from major design changes, and eight common mistakes preventing organizations from getting the most from their failures. I think you’ll enjoy it.

Read the article – Failure Is Not an Option — It’s a Requirement.

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

All one has to do is look to Apple to see how this works. When iTunes 6.0 came out in January of 2006, they introduced a feature called the mini-store, which, for all practical purposes, bombed.

This past month, in iTunes 8, they reintroduced the same business model, this time with a different interaction design called the Genius. It looks like this new design of the old mini-store is going to be a big contributor to Apple’s next year of revenues. (How much? Well, they are now selling more than 1 billion songs each year. The Genius functionality could easily add another 20%-30% on top of that.)

Some model, different design, huge increase in revenues.

When the business model doesn’t match the user experience or (as was “discussed” in the IxDA.org insane-people’s-death-match thread) when nobody seems to understand what the business model is, the designer can’t know if they are helping or hurting the company by creating a better experience for the user.

Creating a great experience can be an expensive investment. Unless the designer can clearly show the value of that investment, they’ll be constantly fighting the forces of reducing costs to increase profitability. It’s always cheaper to produce crap, so if you don’t understand how quality factors into long term profitability, crap is what will win.

Designers that can’t talk to value in the business model also can’t explain why they themselves should be on the payroll.

This is why understanding the business model is essential to good interaction design.

[Thanks to Robert Hoekman for encouraging me to make this into a blog post.]

Yet, it would be impossible to see radical, major innovations come from that approach. Instead, every so often, we need to remove ourselves from the tactical refinements and immerse ourselves into a world of strategic thinking. It’s in this world that we’ll see new approaches, find major innovations, and radically change the way we’ve done things, all to move us forward in a new way.

In this week’s issue of our email newsletter, UIEtips, we’ve asked Adaptive Path’s Brandon Schauer to share his thinking about what he calls the Long Wow, where he talks about techniques for ensuring long-term customer loyalty through systematically impressing customers again and again. We found this article really inspiring to our thinking about great design and thought you would to.

Read Brandon’s article, The Long Wow.

The Long Wow will be just one topic that Adaptive Path’s Peter Merholz and Andrew Crow will be sharing at this year’s User Interface 13 Conference, October 13-16 in Cambridge, MA. They’ll be teaching their full-day seminar, Subject to Change: Product Strategy and Planning Tools for Great User Experiences. This workshop was highly-rated at previous conferences and we know you’re going to love it.

What have you done in your design process to enhance customer loyalty? We’d love to hear your thoughts and questions.

This week, our good friend, Peter Merholz, joins us for the show. Peter is the President of Adaptive Path, a leading experience strategy and design consultancy. Peter is the co-author of the recently published book, Subject to Change, which discusses new strategies of thinking and working to adapt into innovative and commercially successful organizations.

In our discussion, I ask Peter about mapping out a product’s evolution. Launching a product is no simple task. Every new product falls on the spectrum somewhere between feature-complete, perfect execution and actually shipping with a pile of features on the cutting room floor. Realistically, most sway towards the latter. But that doesn’t mean your products needs to feel unfinished. Peter and I discussed how the best products never offer their users an incomplete feeling experience. And with proper planning, future features won’t feel simply tacked on. Listen in to our conversation for some real-life advice from Peter on how to actually accomplish this feat.

[Peter Merholz and Andrew Crow will show you how to map out your product's evolution, plus several other techniques for creating great experiences, in their full-day seminar, Subject to Change: Product Strategy and Planning Tools for Great User Experiences, at our User Interface 13 conference that will take place this October 13-16, 2008 in historic Cambridge, Massachusetts.]

We look forward to your questions and thoughts on this podcast. How is your organization staging its product rollouts? Are those rollouts working? Let us know what you think in the comments!

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.

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

Larry is co-founder of Constantine & Lockwood, the pioneer of usage-centered design, and author of the landmark book, Software for Use.

September 27th UIE Virtual Seminar: Don’t Panic — Design and Usability Under Impossible Pressure ($129—includes handout)

[Larry is also going to present the full-day seminar, Interaction Design in an Agile World, at this year's UI12 Conference. You'll learn how to use the agile development process to implement a shorter lifecycle and encourage team collaboration.]

A few weeks back, I had the chance to talk with Gerry McGovern, author of Killer Web Content and UI12 Speaker Extraordinaire. We talked about a variety of aspects of designing web sites, but one theme we kept coming back to was about how prepared the team was for the long haul.

During the talk, I realized people who have experience building brochures and marketing materials might come to the web design process with a misleading perspective. With a brochure, you carefully construct the design and messaging, put it into production, and then never see it again. Rarely do you get to see anyone interact with the brochure. That information never informs the design of future brochures.

Gerry made the great point that web design is very different. It’s an iterative process where you’re receiving constant information after the design. This information allows you to tweak and enhance the design, often in small ways, to make continual improvements. Most of the work happens after the initial production, not before, as in a brochure.

In this week’s UIEtips, I’ve described the findings from recent research on web site redesigns. In this article, I talk about seven strategies we see employed by the organizations best at redesigns.

Read today’s UIEtips article.

Have you employed these strategies? Are you finding hurdles from thinking too much in the short term? We’d love to hear your thoughts on the challenges when redesigning web sites. Join the discussion below about this week’s topic.

Want to learn more? At this year’s User Interface 12 Conference, Gerry McGovern will present How to Design a Task-Based Information Architecture, to give you a solid grounding in IA that will enable you to create designs that help your users find what they want.

Each week in our Usability Tools Podcast, I will be sitting down with UIE’s Managing Director, Christine Perfetti to discuss tips and tools for improving your site’s user experience. The goal of our weekly podcast is to share some of the most important findings from UIE’s research on web design and usability.

In last week’s podcast, we talked about Gallery Pages, which are pages with links to the site’s content pages. This week, Christine asked me about two other types of pages: Department pages and Store pages. These pages become crucial when an information-rich site has thousands (and sometimes millions) of pages.
In this podcast, we discuss:

» How Department and Store Pages help narrow down the content choices for users
» How Department pages help users make confident choices between galleries
» What sites successfully take advantage of Department Pages, including the Bureau of Labor Statistics
» What common mistakes designers make when implementing Department and Store pages

As always, we’re very interested in hearing from you. Do you have questions or comments about this episode? Do you have suggestions for future episodes? We want to know. Please leave a comment below or email us directly at mailbag@uie.com.

UIE’s Latest Research: If you’re interested in the topics Christine and I discuss in the podcasts, I highly suggest you sign up for our free newsletter, UIEtips, to read our latest usability and design research as soon as we publish it. We’ll also notify you in UIEtips when we publish new podcasts.

New: Survey and listener drawing!
We would like to give you and your co-workers free admission to our next Virtual Seminar program, with full, lifetime access to the archived program as well! All you need to do to be eligible is give us your feedback on your podcast listening experience. Fill out the following survey and each week we’ll randomly send one survey participant a free admission to the next UIE Virtual Seminar and Archive, a $169.00 value! We appreciate your input!

Participate in our survey to win!

This week, we have the latest installment of the SpoolCast crew.

In this episode, we discussed Adaptive Path’s Todd Wilkens recent blog posting, Usability is a path to failure. Not surprisingly, we had some interesting thoughts on Todd’s controversial post.

We talked about the role of usability research on product development, including the reasons why successful design teams launch both huge hits and products that fail to excite users. Next, we discussed the impact of outside influences on the design process, such as team and company culture. Finally, we explored whether we can apply the bold visions that we see in the consumer space, like 1987′s Apple Knowledge Navigator, within the enterprise realm.

This is one of the best discussions I’ve had with the group and and I think you’ll enjoy it.

New: Survey and listener drawing!
You and your co-workers have the opportunity to get a free pass to our next scheduled Virtual Seminar and lifetime access to the archived program! To be eligible for the drawing, please give us your feedback on your podcast listening experience. Fill out the following survey and each week we’ll randomly send one survey participant a free admission to the next UIE Virtual Seminar and Archive, a $169.00 value! We appreciate your input!

Participate in our survey to win!

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

All the time, I hear from clients working to build products and sites that reshape the market, hoping to duplicate Flickr’s success. But how can these design teams best go about developing innovative designs? Is it just luck when sites such as Flickr become successful?

If you’re challenged with creating innovative designs, I highly suggest you check out 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.

UIE’s Ashley McKee recently posted about a great interview Guy Kawasaki conducted with Scott Berkun, author of the new book, The Myths of Innovation, where Scott discusses how innovations happen and some of the biggest challenges designers face when trying to build innovative products. You’ll also want to check out Digital Web’s interview with Scott.

When teams make critical feature changes in their designs, there’s always a risk of backlash from loyal users. That’s what happened to Facebook, the social networking site, a few months ago. Facebook’s designers created the mini feed, an exciting new feature that promised to offer users a vastly improved experience. Instead, the feature resulted in loyal users getting angry and frustrated with the change.

How could Facebook’s designers have prevented this backlash from users? How can you ensure that you don’t experience a similar fallout when launching a new feature? In this week’s UIEtips article, I discuss what led to the Facebook disaster and how design teams can avoid similar results with their own sites.

Read today’s UIEtips article.

How does your organization handle the launch of new features or products? Has your team experienced any backlash when launching new design features? 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 I'll present my full-day seminar: New Perspectives in User Experience Design. In this seminar, I'll be sharing my outlook on the state of our field and discuss UIE's latest research.]

A few weeks ago I wrote an article discussing the 3 steps design teams take when creating an experience vision to guide the direction of design towards their users’ ideal experience. Once a design team creates that experience vision, they need to share it with everyone involved in the project to make sure everyone is on the same page as the design process progresses.

While the process of conveying the vision to key decision makers on the project and within the organization is very important, the methods used to share the vision can vary greatly depending on budget, available resources, and the pool of creative talent. Teams can use any technique, from expensive video-shoots with actors to low-fidelity stop-motion animation, as long as the vision helps the design team and stakeholders progress in the same direction and inspires team members to produce an improved experience.

In this week’s UIEtips article, I discuss how a successful envisionment that focuses on the users’ ideal experiences can lead design team’s direction for years to come, and I also explore the many creative techniques for making that vision clear to everyone involved on the project.

Read today’s UIEtips article.

Does your organization have an experience vision? How are you guiding your design direction towards your users’ ideal experiences? What methods to share this vision have you used? As always, I’d love to hear what you’re doing. Join the discussion below.

[If you find this article interesting, you'll definitely want to attend the User Interface 12 Conference this November 5-8, where Kevin Cheng will present: Communicating Concepts with Comics. This seminar is an in-depth look at using comics as a technique for communicating the core concepts behind a design's intended user experience.]

It didn’t look like much at first, but then I noticed the blue and white hand sensor on the top. I waved my hand over the sensor, and the toilet seat started rotating under the blue arm that extended out a few inches. The arm let out a stream of cleaner and also “squeegeed” the seat as it rotated. The same thing also happened when you flushed. How cool is that? Functional, sanitary, and unordinary. I also wasn’t so annoyed about having to pay 50 Euro cents to use it.

The rest of the folks on my tour talked about these toilets for the rest of the day. Normally you wouldn’t give toilets a second thought, or care much about them. Let’s face it, using an ordinary toilet isn’t very thrilling. They all work the same and accomplish the same goals. But, this extra feature gave the experience a touch of excitement.

Customer/User expectations and homogenous products are two things marketers, designers, and development teams can use to their advantage when creating new goods, services, and experiences…or revamping old ones. By gauging customers’ expectations and transforming homogenous products to include new features, marketers and designers and can take a step beyond the ordinary and offer a pleasant surprise.

So, what is your self-cleaning toilet? How are you satisfying your customers’ needs for delight?

What’s interesting is that you could say there’s nothing new here. Panic’s new application uses an enormous amount of code that comes from other places:

The text editor is SubEthaEdit.
The FTP is essentially their product Transmit.
The web preview is Apple’s WebKit engine from the Safari web browser.
The code documentation (currently HTML, CSS and PHP) is from a series of published books from O’Reilly.

What’s great is that the Panic guys clearly did not intend to reinvent the wheel, but simply refashion it, while standing on the shoulders of giants. By taking great code that was already written, they could concentrate on the part of web development they thought was lacking: the experience.

Steven Frank, co-founder of Panic, wrote an introductory post about Coda on his weblog,

If you hand-code web sites like we do, you know the drill: You have your editor in one window, a browser or two open for previews, a shell for doing MySQL work, a book open on your desk (or perhaps php.net in yet another browser window), your favorite file transfer client (Transmit, of course!) and maybe even another program still, specifically for editing CSS.

It works. But, man, that is a lot of clutter and visual overload.

When we write Cocoa software, we don’t do it in ten different applications. We do it in Xcode, because it brings all the tools we need together in one place.

We saw a clear need, and we set out to fill it.

He adds later,

You can’t even see Coda’s best feature.

We asked our beta testers what they felt Coda’s best feature was, and the most popular answer was: the integration. The way it all fits together.

This shows small teams can accomplish great things by spending their cycles on innovating the experience, instead of reinventing the internals. They’ve tread similar paths before, addressing the experience in other areas considered boring, like FTP (Transmit) and even Usenet (Unison). Now they’ve launched a new product that approaches the experience of building and publishing web pages from a different angle and have created a serious amount of buzz.

Could an improved-experience-spin on an old problem be the key to success on your next project?

This is just one of the ways the employees at this particular Dunkin’ Donuts make me feel special as a customer. Because I stop by often, the employees also automatically know what I’m going to order.

Noticing your customers’ little details and remembering their personal preferences are two great ways to create loyalty with them. In a recent post, marketing expert Seth Godin discusses how flattering one’s ego is a sure way to make clientele feel important. A little recognition can go a long way. You can read Seth’s full article here: Ego.

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

You can market by telling or you can market by showing. There’s no doubt that interactive marketing, marketing where you actually deliver something of value, is far far more powerful than telling. Telling is just bragging. Telling is ignored. Showing, on the other hand, is about me. Me, me, me! It’s about providing an interactive experience that touches me.

There is definitely great value in offering people an unforgettable interactive experience with your product or brand. Demos, free trials, and free samples all provide a way for people to try out what you’re offering with no strings attached.

You can read Seth’s full article here.

Business as usual is almost always lousy marketing, because there isn’t a lot of room for growth. The opportunities kick in when an external force requires a brand new story, when consumers are choosing to pay attention because they’ve got no other choice.

It’s easy to argue against change. It disheartens shareholders and even employees. But external change is the most likely lever of growth, because it puts you back on the agenda of attention.

Why can change be so scary? Why do we often hold steadfast to old ideas and values? In many cases, organizations find that certain ways of doing things just work. But what happens when the old way of doing things doesn’t work anymore? Is it better to stagnate and disappear in the face of adaptive competition than to try something different? Success isn’t always guaranteed from change, but neither is failure. To be complacent, or not to be complacent? That is the question.

You can read Seth’s entire article here: Do you have to be anti-change to be pro-business?