That might sound shocking if your perception of design involves people solving problems by having brilliant, inspired, creative ideas. But it’s absolutely true: I’m not any smarter than the next guy, and I don’t have better ideas than anyone else.

But I am a designer, and if you task a non-designer and me with solving the same problem, I’d bet my house that the  solution I present will be better than the other guy’s.

Let me tell you why that is.

Problem Solving for Regular People

Most people, when tasked with solving a problem, have one criteria for evaluating possible solutions: will it work? They might explore a couple of options initially, but when an idea looks like it could be developed to successfully solve the problem, they abandon other ideas and commit fully to the one that could work. They develop their idea fully, prove it can solve the problem, and declare the job done.

Designers Do It More

When designers are given a problem, we start out the same way. We explore ideas. When we stumble on an idea that might work, though, we don’t stop exploring. Instead, we put the possible winner aside so that we can come back to it later, and then we investigate a completely different approach to the problem.

Image by lilit via Flickr

Designers know that not all solutions are of equal quality, so we force ourselves to explore dozens and dozens of ideas. We delay evaluating how good an idea is until we’ve generated a sizable pool of possible solutions.

Designers Take More Risks

With the exception of a couple of friends who like the near-death thrill of whitewater kayaking and skydiving, every person I’ve met in my life shares a desire for ease and comfort. I’m one of them—my one whitewater experience left me convinced that I value breathing far too much to enjoy kayaking.

Human nature leads us to avoid risk. We look for the familiar path first, and if the familiar path is not available, we look for the path of least resistance. That instinct is incredibly valuable when we’re faced with choices like scaling a sheer cliff over a mountain range or walking a well worn path through it.

But when it comes to design, avoiding risk mean avoiding innovation.

Good designers recognize that the threat posed by risk—failure—isn’t really much of a threat at all. Because we force ourselves to explore so many ideas, we have a number of options that we could easily develop to solve the problem. When we decide to try a wild idea just to appease the constant voice whispering what if in our heads , we know we have that ace in our back pocket if we ever need it.

Safe in that knowledge, we make what if our rallying cry. What if a better mouse trap didn’t involve wood or wire or springs or cheese, but a cage? Or glue? Or a cat? Or Jell-O? Or disco music? The more preposterous the idea, the more critical it is that we explore it, because innovation is never found on the well worn path.

Designers Date Around

After we’ve explored enough ideas and taken enough risks, we end up with a pool of ideas of varying degrees of quality.  We’re like the college quarterback with beautiful girls begging him to take them out on dates.

(What? Humor me. I’m a designer—fantasy is my refuge from the geeky truth.)

Faced with that situation, the quarterback could do one of two things. He could date one girl to see if she’s The One, and then marry her if she is or dump her if she’s not. But what if, out of thirty girls, he thinks girl number two is his soulmate? He’d never know if girl number thirty would have made him happier.

His other option, of course, is to date all the girls simultaneously, slowly narrowing the field of candidates in a March Madness of Matrimony until one girl is left. He’d know, without a doubt, that he found The One, even though she might have been the thirtieth.

I’m not suggesting that option B is a good choice for the quarterback—it would make him a jerk, honestly—but it’s a fantastic choice for designers. We embrace our commitment issues, develop multiple ideas in functional prototypes, and then test how well each meets people’s needs—and how it affects their emotions and satisfaction—to find The One. (Or, more likely, we isolate the best qualities of each design, learn from them, focus on them, and create an entirely new design that merges them into one. It’s messy with people—cf. Frankenstein’s monster—but it usually proves a fantastic strategy for design.)

I Don’t Wear Spandex or Capes (during work hours)

I’m not a rockstar, superhero, genius or magician. I don’t perform miracles or supernatural feats. As a designer, I find success because I’ve trained and forced myself to work counter to my natural instincts to commit to the first solution I imagine. I’m trained myself not to avoid risk, but to explore it with curiosity. I understand and respect the well worn path, but I’m willing to venture beyond its safety because, more than anything, I want to find the solution that surprises and delights.

Presented October 27, 2009, at a meeting of the Atlanta chapter of the Society for Technical Communication

Referenced resources

• What is user-centered design? from Usability Professionals Association
• Tribes: We Need You to Lead Us by Seth Godin
• Conversation and Community: The Social Web for Documentation by Anne Gentle
• STC Atlanta’s Usability Workshop, which will occur on November 14, 2009 for only $25 (includes lunch)
• STC Content Strategy SIG, organized by Rahel Bailie

Still, I recognize that my perspective on usability testing is fairly limited, so I decided to tap the collected experience of the people I follow on Twitter. I posed this question:

Here are the responses from the awesome people I’ve connected with through Twitter. Each person’s contribution is linked to their Twitter profile; follow them and I guarantee you’ll learn a lot from each of them.

Follow the tracks of people who know what they’re doing.

The article both reference is Usability Testing Demystified by Dana Chisnell published in A List Apart. (Dana is also on Twitter as @danachis.)

Make sure your goals for testing are appropriate.

Take the time to prepare your test properly.

Make test participants feel comfortable–you need them to be relaxed.

Don’t taint your results.

Shut up and get out of your own way.

Embrace awkward moments–they’re often goldmines.

Caveat: Explore usability testing, but understand its limitations.

Another person I follow on Twitter, Robert Hoekman, Jr., wrote another article about usability test on A List Apart recently. His article, The Myth of Usability Testing, clearly makes the point that usability testing is not a silver bullet. Usability testing can tell you a lot about where your designs do and don’t work, but it’s not a perfect, scientific, empirical tool. If you use usability testing as your only method of validating and prioritizing design work, you won’t produce the type of work you really want to. To be most successful, you need to employ a plurality of methods for evaluating designs, then blend all that data with a healthy dose of design intuition. Robert makes the point much better than me, though, so go read his article. And, of course, follow him on Twitter–he’s @rhjr.

So, what’s your tip for usability testing newbies?

Share it in the comments!

As a user experience designer in the agile world, I recognized a while ago that my job is as much about influencing my team’s DNA to include best practices for UX design as it is about actually designing. I’ve supported anywhere from three teams (with a total of sixteen developers) to a single team (with with six developers). No matter what the ratio, though, there’s always been more user interface to design than I can execute (even when I worked ungodly hours). With more work to do than I could cover, some UI design had to be done by other team members.

And yes, even now, that terrifies me. But that’s reality, so I’ve had to go to greater lengths to make sure that the entire development team shares a concrete understanding of the user’s motivations and fears.

User stories have helped me get there. I like to pair user stories with personas derived from user research, so that the “As a x” portion of the story becomes “As Michael.” By marrying the two together, I gain two things:

• The personas, which historically were read through once before being forgotten, gained greater prominence through repetition–actually achieving that mythical goal of becoming part of the team vocabulary.
• The user stories became even richer, as each story written from Michael’s perspective drew on the combined history of the user research, the persona itself, and all of the other Michael stories. What was an isolated and generic user story becomes one part of a rich narrative about a specific archetypal user.

Because the user story is present every day during the sprint, tying the user stories to the user research creates a powerful reminder to keep the user at the center of every decision.

Photograph by drewgstephens

Eventually, I decided to step back from the details of an iteration and focus instead on the patterns of how we worked. I watched in planning as we did everything technically right. We lined up the user stories we wanted to execute, decomposed them into tasks, and then triple checked that our estimates on the task cards fit into our actual available time. We even factored in some time for the unknowns that would crop up. By all measures, we were primed for success.

The next morning’s scrum revealed the problem clearly. One by one, we all stepped up to the board and pointed to a task card that we planned to work on that day. And each team member pointed to a task card related to a different user story. One person even pointed to two small tasks on two separate user stories.

On the first day of our iteration, our team of seven started eight different user stories. At the end of that iteration, all eight of those user stories were incomplete.

Our problem? We were approaching our scrum board like it was one of those carnival games where you shoot water canons at targets to make your horse/hot air balloon/clown/whatever charge toward the finish line. As soon as the starting flag waved, we each grabbed a cannon and plugged away in isolation, hoping that our horse/hot air balloon/clown/whatever would cross the finish line before time ran out.

We had a couple of mental model problems with how we approached our process:

• We assumed 100% success at all of the user stories we planned to execute, so we made no effort to maximize the amount of success for the what-if scenarios.
• We saw a single finish line at the end of the sprint, so we did nothing to try to fully complete stories before that deadline.

Like most process problems, understanding the issue was ten times harder than fixing it. The solution was obvious: make every effort to limit the number of user stories in play at any given point in the iteration. Focus on pushing a story through the process completely—all the way to acceptance from the product owner—before starting a new story.

If we focused three or four water cannons at one target, we’d push our horse/hot air balloon/clown/whatever past the finish line quickly, and then we could tag team another target.

So what about your team? Are you aiming at as many targets as you have team members, or are you controlling risk by keeping the number of stories in play to a minimum?

If you work in communication (technical or otherwise),  you’ll find great information that will help you engage your customers more effectively.

Anne made a sample chapter available, which I’ve included for you. Read the chapter, then buy the book.

Free Chapter Conversation and Community

Seriously. Go buy the book now.

RefreshAugusta: User Centered Design from Chris Harrison on Vimeo.

This presentation was delivered at RefreshAugusta on July 22, 2009.

Here’s the write-up from the RefreshAugusta site:

Nobody ever set out to build a Web site that’s difficult to use. Even so, many sites prove to be frustrating for the very people they’re built to serve. When we design without a clear and proven understanding of the site’s audience–or with our own preferences and biases unchecked–we put the overall usability and effectiveness of the site at jeopardy.

In this presentation, Will Sansbury overviews user-centered design, a process that infuses concern for the audience into every step of creating a site or software product. He shares practical tools for learning about your audience initially, checking your decisions against your understanding of the audience throughout the design process, and gauging the effectiveness of your final design using qualitative usability testing.

As an information architect on the WhatsUp Gold team at Ipswitch, Will has experimented with integrating user experience design into the Scrum software development process. Because he’s a practitioner first, he has a pragmatic, from-the-trenches view that makes user experience and user-centered design approachable to designers and developers of all skill levels.

Note: In the video, I talk about the cost of running usability testing at SPSU. The numbers I tossed out were completely speculative; I don’t have any idea what it costs to run tests in their lab. But if you’re looking for a safe way to explore usability testing for your projects, the Usability Center at SPSU is a fantastic resource.

This site features before-and-after photo galleries of homes Graybeal has restored.