Navel Gazing

UXmatters Article: Testing Your Own Designs Redux

by Andreas Bossard on January 4, 2010 · 2 comments

in Design

This is just a quick pointer to my latest UXmatters column, which is a follow-on to my article from September about the perils and pitfalls of testing your own designs.

In this follow-on, I revisited some of my more bombastic points about testing one’s own designs. Thanks to some excellent comments by several colleagues (and colleague-slash-wife), I modified and built upon my original recommendations and provide some modified guidelines. Here’s the summary guidelines. To understand the reasoning behind them, go read the whole article.

Guideline 1—When testing your own designs, don’t think of it as a test to pass or fail, think of it as part of your design process.

Guideline 1a—Test early, test as often as possible, and test lo-fi prototypes rather than making usability testing a make-or-break event in your design lifecycle.

Guideline 2—When testing your own designs, you should seek disconfirming evidence, but be alert for joys and delighters, too.

Guideline 3—When you’re trying to solve a design problem, usability testing serves design. It’s a tool. Use it to improve your design, not to justify your actions.

Comments about these guidelines? Email me via UsabilityBlog, or comment at UXmatters.

Testing Your Own Designs Redux ::? Paul Sherman via UXmatters

{ 2 comments }

My Usability Marathon Preso

by Paul Sherman on October 14, 2009 · 0 comments

in Experience Strategy

I just posted my Usability Marathon presentation to Slideshare. (I love Slideshare btw…no surprise; Rashmi Sinha started out as a UX person.)

I’m getting good feedback and nice retweets on Twitter; which is a good sign.

Normally, I’d pull some choice quotes to whet your appetite. But I’ve got a pile of storyboarding and wireframing to do this week, so it’s back to the UX grind (but what a satisfying fun grind!).

Enjoy.

Usability…Or Strategic User Experience? ::? Usability Marathon 2

{ 0 comments }

The End of “Just Google It”? Twitter-Based Search Behavior

by Paul Sherman on September 8, 2009 · 14 comments

in Design

Let me be up-front about this from the beginning: this is a half-formed thought. But its implications are very, very interesting.

So here’s what just happened: I had a desire to take in some emerging thoughts in the user experience field. I wanted some fresh thinking, some exposure to new presentations.

For about 8 years, my first instinct has been a) browse to Google, b) type in “user experience”, and c) browse the list of returned search results to see if anything new strikes my fancy.

This morning, I didn’t do that.

Without even realizing I was changing an ingrained habit, I went to Twitter.com, typed “#ux” in the search box, and browsed the list of returned tweets. I clicked a few, starred a few, and made a mental note to come back and check out some of the links to preso’s.

Then I sat bolt upright when I realized what had just happened.

This, colleagues and readers, is an early warning. An indication that one of my consumer habits is open to change, and could very well tip into a new and different routine.

And if it happened to me, it can happen to any of us.

I don’t know if you’re grokking the import of what happened, so I’ll restate it: something in my sub- or semi-conscious mind decided that the resource I’ve been relying on for years might not be cutting it any more, and it directed me to try a more real-time and dynamic resource.

I will certainly follow up on this in future posts. But right now, I think this incident opens up several interesting research and design questions, such as:

  • How much of customer behavior is consciously directed, and how much is directed by the sub-, un-, or semi-conscious?
  • What factors influence customers’ willingness to change behavior?
  • What are the leverage points for changing customers’/users’ habits?

{ 14 comments }

My UPA09 “UX Kit” Presentation & Bonus Audience Comments

by Paul Sherman on June 15, 2009 · 9 comments

in Design, Experience Strategy

Today I’m posting the presentation and source document from my UPA2009 presentation “A Kit For Building User Experience Teams in R&D Organizations.” The talk went very well; nearly everyone in the (somewhat small but whatever) audience spoke up and contributed.

Happily, when I posted links to this content on Twitter I got about a half-dozen retweets, which for a second-stringer like me is not too shabby. So I think you’ll like this preso and the kit doc, which I’ve released under a Creative Commons Attribution-Share Alike 3.0 United States License. BTW you can learn more about this license and what it means at http://creativecommons.org/licenses/by-sa/3.0/us/. Basically, it means you are welcome to make use of the content as long as you attribute it to me and you share any derivative works under the same license. Which I think is more than fair, and leads to boatloads of good UX karma besides.

And here’s a little bonus: I asked my friend and session chair Lyle Kantrovich (@lkantrov for the Twitterati in the crowd) to take notes on the audience comments and contributions; which he peevishly (kidding! I meant happily) did. I’ve posted his notes below.

Before I link you out to the content you might be interested in the “story behind the story” of this presentation. About 7 or 8 months ago I decided to submit to UPA2009, and scoured my hard drive for something appropriate. I realized that I had created a comprehensive resource while at Sage that detailed how to staff, budget and run a user experience team at a medium-to-large software organization. I figured that this was as good a submission as any. Plus, it really fit my whole “get the organizational structure and processes right” theme. If you’ve been reading me for any length of time you know I have a passion for this area of our field, having trained in social/organizational psychology and built several teams over the past 12 years.

So I submitted a proposal, which went something like this:

This submission provides an overview of a “User Experience Kit” that one user-centered design team developed as an implementation guide for other product teams within their global organization. This kit was first released in mid-2007 within the organization, and has been used in the organization to guide the creation of four additional teams since then. The primary audience for this presentation is people who are able to drive change in their organizations and have the authority to support those changes with allocation of resources.

And it got accepted. Yay.

Of course I put off writing the presentation for months, but not for the usual reason (i.e., pure procrastination). As the day of the talk drew nearer, it became clear to me that the kit itself was a really boring story. And I don’t do boring. I HATE boring. I have high standards for presenting, I do it well, and I was stressing out about how boring this talk was shaping up to be.

That is, until I realized that the more interesting story was *why* I had to create a UX implementation guide/kit, what it said about my then-organization (and other organizations), and what we as a field should be doing about it.

And then everything was alright, I wrote some entertaining slides (keep on the lookout for “Captain Obvious”) and I gave a kick-@ss talk.

So, without further ado, here’s what I covered in my talk:

  • The sad truth about the need for a “UX kit”
  • A bit about the kit itself
  • An extended discussion about launching UX teams and spreading UX in medium to large orgs

As I mentioned above, Lyle was kind enough to capture discussion notes, which I’m including immediately below. However, I recommend looking at the preso first (either in .pdf format or on SlideShare) and getting the kit source doc before reading the discussion notes.

Thanks again Lyle for capturing the audience comments. Here they are:

  • Come back with data to show the value of what happened during UX processes.
  • Be more of a teacher – share UX? techniques (aka “UX freeze-tag”).
  • Be flexible.
  • Triage projects early on – to discuss how UX can help.
  • Focus on convincing people who can be convinced.
  • Have an open-door policy on usability lab.
  • Create an internal blog with test highlight clips.
  • Conduct a quarterly UI workshop.
  • Stay relevant – you know if you’re relevant by # of people coming to you.
  • Focus on money/budget & key influencers in the organization.
  • UX has to manage a lot of different things at the same time.
  • “Customer Experience Bar Raiser Review Board”? – executives that help set UX direction.
  • Selfishly share the glory – co-present success stories with clients/partners.
  • Find a mentor/peer outside your organization to learn from, commiserate with and share with.
  • Find an aspirational (design/product) example – something that reflects what you’d like the UX to look like.

A Kit For Building UX Teams [preso pdf]? [kit doc]? ::? Paul Sherman

{ 9 comments }

We Don’t Have Enough Time To Make It Usable

by Paul Sherman on January 28, 2009 · 4 comments

A meme has been following me around the last few weeks. Several times I’ve heard UX practitioners bemoan the fact that their project or corporate leaders have as much as said “we just don’t have the time to do the usability work right now, we’ll come back to that.”

As we all know this isn’t as effective as doing the iteration and design validation up-front. Taking the “we’ll add in the usability later” approach just yields nasty surprises down the line. But my question isn’t “why do people still think like this?” It’s part of human nature. Or project management nature, at any rate.

The real question is why our field doesn’t have better defenses against this. I mean, we know that in certain crunch times we’re going to get pushed on to shorten our processes and either go light on or skip our design iteration and validation. Yet it almost always leads to rework, lower user satisfaction, etc etc.

Are we just slaves to the “fast-good-cheap” iron triangle? How do others in the field push back on engineering and management in these situations?

{ 4 comments }