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

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

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

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

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

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

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

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

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

How to get the free recordings?

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

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

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

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

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

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

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

See the other UI16 Spotlights:

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

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

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

That was it. Beans up the nose. Really.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

See you there!

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

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

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

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

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

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

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

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

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

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

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

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

Thanks to Pam and Luke for taking such great notes.

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

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

The Most Valuable UX Person In The World

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

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

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

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

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

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

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

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

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

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

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

Julie Zhuo

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

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

Christian Crumlish

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

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

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

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

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

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

Find out more about Dana’s seminar and register?

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

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

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

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

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

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

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

Read today’s article.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tim tells us that Design Thinking is:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Here’s the description of the talk:

Journey to the Center of Design

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

We guarantee a journey that shouldn’t be missed.

| View | Upload your own

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

What do you think of this presentation?

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

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

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

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

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

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

| View | Upload your own

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

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

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

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

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

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

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

Thanks, Cheryl!

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

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

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

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

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

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

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

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

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

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

http://playground.ebay.com/

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

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

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

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

The framework was a simple four-stage progression:

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

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

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

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

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

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

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

We can see this clearly on the web now:

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

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

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

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

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

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

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

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

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

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

What do you think of Meghan’s approach?

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

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

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

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

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

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

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

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

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

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

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

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

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

Are you focused on the user experience?

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

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

Here’s a feed that iTunes likes.

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

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

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

Here’s a feed that iTunes likes.

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

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

In this episode, the SpoolCast crew convened to discuss:

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

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

(Here’s a feed that iTunes likes.)

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

Production assistance on this SpoolCast from Brian Christiansen.

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

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

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

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

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

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

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

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

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

Download the Reader’s Guide. (PDF)

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

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

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

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

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

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

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

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

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

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

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

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

His premise is an interesting one:

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

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

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

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

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

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

Ideation vs. Evaluation

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

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

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

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

Sketching vs. Prototyping

The attributes of each are different:

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

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

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

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

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

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

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

Rashmi Sinha on whether usability studies are scientific or not

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

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

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

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

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

Kyle: Hotel reservations.

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

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

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

Jared: Exactly.

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

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

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

Josh Porter on the Facebook Controversy

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

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

Read the entire transcript here.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Read today’s UIEtips article.

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

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

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

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

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

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

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

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

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

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

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

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

Again, the implications of all this are interesting:

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

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

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

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

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

Read Luke’s article.

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

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

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

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

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

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

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

In contrast:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

What happens when accountability is discovered by the bean counters?

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

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

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

And that’s the day we bury advertising.

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

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

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

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

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

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

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

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

Here’s the details Gene Smith from nForm sent:

Jared Spool
We Are Not Alone: IA’s Role in the Optimal Design Team
June 23, 12 pm ET (9 am PT)

The Basics

• Presenters will deliver their presentations using screen sharing software and a conference call line.
• Anyone can join
• We can have up to 20 “participants” (computers) per session
• Seats are available on a first-come, first-served basis
• There’s no sign-up cost, but you’ll have to dial long-distance for the conference call

Signing Up

• Email *redux@nform.ca* to sign up for a session
• Be sure to include the presenter’s name (Spool) and/or date (6/23/06)
• If you’re one of the first 20, we’ll send you details about joining the session
• If you’re not one of the first 20, we’ll keep your name and let you know if someone cancels

If you miss it or can’t get in, Livia Labate recorded the original presentation.

The handouts are available here.

Sam divides the business rationale for good design into three pieces:

• Designing to Simplify
• Designing to Differentiate
• Designing to Innovate

I thought this was a nice, straightforward way to talk about why design pays off.

He also mentions HP’s use of deep ethnography and interviews to collect unmet customer needs. In addition, he talked about how they use internal newsletters from HP’s worldwide network of designers to keep everybody up to date on trends and design ideas.

Very interesting stuff.

The spring conference season is upon us and, by coincidence, I’ve recently found myself at several conferences where many of the participants were executives from organizations such as GE, The World Bank, Bloomberg, Intuit, Microsoft, and Best Buy. Hanging out with these folks has given me a chance to hear the challenges they are currently facing.

Executives, for the most part, now face the same challenges as they always have: the need to increase revenue and customers, decrease costs, and enhance shareholder value. However, I’ve noticed a real shift in their strategies. Many are now turning to innovation as the mantra for tackling the hurdles they see.

This shift to innovation is a good thing for us, the design practitioners. We thrive on being innovative and love the opportunity to show what we can do. Now we can get attention for our talents all the way to the corner office.

The more we understand what executives are seeking, the more support we can generate for those things we love doing. This can only be a good thing, since innovation thrives in both growing and shrinking economies. This thrust will serve to cement our value to the organization as time goes forward.

This week’s featured article, Innovation is the New Black, talks about this new executive attention on innovation. In the article, I explain how the designers at Apple and Netflix have made a profound impression on executives everywhere giving experience design a new focus.

Have you noticed an increased focus on innovation in your organization? What are you doing to respond to it? Share your thoughts below.

Read the article here.

[Since experience design is an essential skill set for innovative companies, we've made the theme for this year's User Interface Conference be "Enriching the Experience." If you haven't registered yet, you'll want to look at the conference program, as we've packed it full of valuable expertise on all aspects of creating innovative designs. Details about the conference are here.]

Update: Apparently, the @issue conference isn’t the first place Bruce Nussbaum talked about innovation being the new black, as Michael Bierut points out.

Recently, I was coaching a client through the process of establishing a experience design process for their organization. We got on the subject about their vision for their product, a suite of tools for application developers. The lead developer piped in and announced they had just written a vision statement for a recent customer presentation. He promptly opened up a PowerPoint presentation with a slide that read something like this:

“[the Product] will make it easy
to design and build applications
that use competitive [proprietary framework],
conform to best practices,
and are built in a highly productive manner.”

My first thought was, “This doesn’t say anything!” How is this different from what any competitor would have? Is there a competitor who wouldn’t want to “make it easy,” would advocate not using “best practices,” or consider promoting how their product prevents developers from working in “a highly productive manner?”

The problem with a vision statement like this is that it’s too generic and it doesn’t talk about the users’ experience. An experience vision describes both the current experience (what users do today) and the experience the team would like to aspire to (what users could do with the right products).

Turns out the team doesn’t really know how their customers develop applications today. They haven’t spent much time talking or watching their users use the suite of tools they already produce, or how they work with the competitors’ tools. They don’t really know the work environment or the constraints their customers are under, as they create new applications or maintain and update existing ones.

Without knowing what customers are doing today, the team really can’t start to put together their experience vision. So, the next step for these guys is to go out and do the research. Visit customers and find out how they utilize the tools they have now. That will give the team a solid understanding of the current experience.

When we’ve done this before, we’ve found that once teams have a solid current experience, the insights into how to improve it happen quickly. If you have a bright team, (and these guys are amongst the brightest I’ve ever had the opportunity to work with,) their minds will kick into gear on the first visit. They’ll have all sorts of ideas on what the design could aspire to be.

The problem with innovating isn’t coming up with ideas. It’s knowing which ideas add value. Without the solid understanding of what the current experience is, you can’t possibly know that.

A vision statement put together as part of the marketing/product management effort is not the same as having a solid experience vision. Don’t let your team fall into that trap.