Design

I’m putting an article together for UXmatters on the topic of usability testing and validating one’s own designs. My goal is to develop some guidelines for self-testing.

I’d love to get your feedback on some questions I have:

  • Testing your own designs: all-around bad idea? Or is it possible to do it well?
  • If so, what should you do / not do when testing designs you’ve created?
  • What should you look out for?
  • Got a good story or anecdote to share? Please do. Either success stories or cautionary tales are welcomed.

Thanks in advance. -Paul

{ 12 comments }

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 }

Found this on Digg.com today, and promptly added it to my “Questionable_Designs” set on Flickr.

What a great example of after-the-fact design modification.

It makes me wonder what the context was. Did someone set this up for a young child or an older relative? Or did they do it for themselves?

In any case, it’s a great reminder of why us user experience professionals do what we do.

For those of us in design: remember, you shouldn’t design for *all* the edge cases. You shouldn’t even design for most of them.

Why? Because you clutter the user interface when you try to account for all possible user needs.

A reasonable question to ask at this point is this: if you have a set of rich capabilities that *some* small subset of people might want to access, what do you do?

That answer is actually easy. There’s two things you can do in this very specific case of a TV remote.

Both of them are examples of what I think of as “beyond here be dragons” design. Without going into the etiology of that (in retrospect kinda obtuse) metaphor, let’s just say that it’s often a VERY good idea to surface the UI for your minimal main user stories while burying the controls and interactions for the complex edge case capabilities behind an access point that clearly indicates that the functionality is not intended for most people.

So how do you do this for a TV remote?

  • Method 1: Put the advanced functions underneath a sliding cover. This was all the rage 8-10 years ago. Not seen as much today.

Advantages: The cover makes it clear that, well, beyond here be dragons. Effective.

Disadvantages: Presence of physical parts probably means higher cost to manufacture. Physical parts (i.e., cover and slide) also wear out.

  • Method 2: Put the advanced functions in the onscreen portion of the UI. The simple controls on the remote can then be used to step through the advanced dialogs and tasks.

Advantages: No additional hardware requirements. Provided the unit can receive updates, the software interactions can be improved if the initial UI design support for the complex stuff isn’t, shall we say, usable.

Disadvantages: Slowwww. Error-prone, especially for interactions requiring alphanumeric input via “point and pick”.

{ 3 comments }

For some reason this slipped my mind for the last two weeks. On August 15th I delivered two talks at ProductCamp Austin 2009. Before I link you to the talks I wanted to give hat tips to the crew who put together this ProductCamp. It was a fantastic, energetic, and crowd-driven “un”conference, and I highly recommend attending one if you get the chance. They’re springing up in many major metro areas, so finding one shouldn’t be hard. You can learn more about BarCamps at this site.

The first talk I gave was “How To Achieve A Great User Experience For Enterprise Software” and the second was “From Personas To Production: The Role of Personas, Design Briefs, Stories, Storyboards, and Wireframes in the Ideation – Design – Build Process.” The second one had more people than the enterprise talk; which I guess shouldn’t really surprise me as the enterprise talk is more specialized. But the enterprise attendees were full of good questions and there was lots of good within-audience discussion. The feedback I’ve gotten on these two has ranged from slightly to strongly positive. So I’ll put them in the “win” column.

Oh and my past presentations are also available on Slideshare.net here.

{ 1 comment }

I know that as a professional user experience practitioner I should avoid angry rants, as they’re (mostly) unproductive.

But here’s the thing: I am PISSED OFF right now, I feel cheated and abused by this printer’s designers, and I have no real recourse except to call out the manufacturer and tell them just how thoroughly they have failed me… and in all probability, many other customers.

I’ve owned this printer – a Canon MX860 – for about a month. So far so good, I’ve been able to connect it to my network and print plain paper documents with no problems.

So this morning I tried to print a half-dozen photos so I could send pics of the kids to my 99-year old grandmother. Sending attachments or a link to my Flickr account is not a viable option. She wants pictures, big pictures. Pictures she can hold in her hands.

No can do. I’ve spent more than 45 minutes crawling around the backside of this stupid time vampire of a machine, trying to figure out why it insists on printing from the rear tray, and realizing I don’t know how to load this until-now-unknown-to-me rear tray.

I’m angry. This stupid piece of crap printer just stole almost an hour of my time. And I still don’t have the damn pictures to send to my grandmother.

So you fail, Canon. You fail hard. It’s a pity actually. I really like and enjoy my Canon cameras. But you’ve just stolen – yes, stolen, as in consumed without my agreeing to it – an hour of my time. Think that’s a trivial amount? It’s not. Not when you multiply it by x number of people who’ve also struggled to print photos. And I’m sure “x” is not a small number.

{ 5 comments }

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 }


(Click picture to see full-sized)

I don’t know if this happens to all y’all, but I always have a hell of a time figuring out which button *opens* the elevator doors and which button *closes* them.

It happens every time I get in an elevator. Invariably, after I’ve already boarded someone runs to make the elevator before the doors close completely. As soon as I see them, I try to be helpful. I go to hit the “door open” button, hesitate, shift my gaze from one to the other in a semi-panic, and then jab the WRONG button.

I think I’ve figured out why I have such trouble discriminating between the two icons: the “door open” button (on the left in this picture) looks to me like the image of a *closed* door, and for some reason the action implied by the outward-facing arrows just doesn’t register with me.

Similarly, the “door close” button on the right, with its two strong vertical lines defining the outer edge of the icon, just seems to me to look like two open doors. And like the other image, I just don’t grok the arrows in the picture.

Is it just me that has this particular problem, or is does this design confuse others as well?

{ 9 comments }

Just noticed a tweet pointing out this designer’s Flash homepage.

Creative? Undoubtedly yes. Also annoying and a bit nauseating.

I’m not going to get on a usability soapbox about this. It speaks for itself. And it? speaks a mixed message.

{ 3 comments }

Hey, what can I say. Sometimes I’m on a tear and I write lofty big-picture conceptual pieces on the state of the user experience industry. Other times I can crank out an incisive, perceptive screed that absolutely devastates a design.

And still other times, you get this: a post about a garden variety, seen-it-before bad design. In this case, you’ve got your classic chromostereopsis issue, where the red-text-on-blue-background renders the text shimmery and hard to read.

And dare I say it…this isn’t exactly the most attractive landing page on the Interwebs. All told, it just reeks of “we’re too cheap to hire a designer, and we’re doing well enough that we don’t care.”

{ 0 comments }

Hat tip to Ghost in the Pixel’s Uday Gajender for putting together this well organized resource page. Nicely done.

And Whitney Quesenbery of WQUsability tweeted this UX toolkit-slash-process map, which I’m dutifully blogging here. Credit where it’s due: the page indicates that the toolkit was created by Bas Leurs, Peter Conradie, Joel Laumans, and Rosalieke Verboom of Rotterdam University.

{ 0 comments }

“Open Here”

by Paul Sherman on February 12, 2009 · 2 comments

in Design

Another example of how even tiny bits of bad design have real-world effects. I picked this one deliberately because it seems so small, yet affects the work satisfaction of about a half-dozen people and causes momentary consternation to countless hundreds every day.

Here’s the situation: this is a countertop drink fridge at a restaurant in the Portland Oregon airport. It sits to the (customers’) right of the register, roughly perpendicular to the leading edge of the counter. Customers are supposed to self-service and grab their own drinks while being rung up.

The frame of the door is uniform on all four sides; there is no flange, handle, or pull attached to the outward facing part of the frame. To open the cooler door, the customer is supposed to wrap her fingers around the side of the door frame, fit her fingers into the cut-out section of the door, and pull the door outward. However, this door is hinged to the right, i.e., at the edge CLOSEST to the customer. It opens from the LEFT.

The assistant to the regional manager of this store told me that they added the “Open Here” sticker because people were constantly struggling with the cooler, knocking over the drinks inside, and in some cases almost pulling the cooler off the counter.

Why?

With no distinguishing features (read: affordance) on the face of the door to indicate how it opens, what invariably happens is that the customer attempts to wrap their fingers around the edge of the frame on the right side and open the door from the hinged side. The cooler is light, and because most people are used to using a bit of force when opening a cooler with a magnetic latch, the cooler gets tugged around the top of the counter as people struggle to open it.

The staff became so tired of dealing with this, they decided to add an after-the-fact design modification. Hence the sticker.

Does it work? The person I talked to offered a qualified “most of the time.”

Again, a tiny example. But how many times do we see this type of thing in our daily lives? More often than we remember, I would venture to guess.

{ 2 comments }

No, that’s not a typo or PHP code run amok. That’s the hashtag I’m fixin’ to use on Twitter to denote “Good Design of the Day” and “Bad Design of the Day” tweets that I, uh, tweet.

Y’know how I was using the “Questionable_Design” tag on Flickr so people could tag pictures of good/bad design? Yeah, it didn’t exactly catch fire and go viral. (Although it has been useful for me to classify design pics that I upload.)

So I’m giving Twitter hashtags a try. Feel free to join in the fun. Got an example of good design? Tweet it and add “#gdotd”. Bad design? Tweet it and add “#bdotd.”

{ 0 comments }

So I went looking for a better content inventory template than the one I use currently, and was reminded how great the IA Institute’s tools and downloads page is.

You should check it out if you haven’t seen it yet.

{ 0 comments }

An article on Digg caught my eye this morning. Seems some non-profit foundation has given the Wikimedia Foundation, the non-profit organization responsible for Wikipedia, almost 900K USD to make Wikipedia “easier to use”.

OK. No problem so far. (Well, I’m a bit shocked that they think it’ll take 900K to fix the entry edit interaction…I could design AND validate a better interaction for less than 1/10th of that amount…)

I’ve edited Wikipedia entries and it’s no picnic. What I take exception to is C|NET columnist Caroline McCarthy referring to folks who have trouble with Wikipedia’s editing tools as “Luddites”.

The problem with this cavalier putdown is that it perpetuates the attitude, held by many technophiles, that anyone who can’t easily use a complex system is stupid, lazy, or both, and that they small-mindedly shun new technology.

C’mon now. People who can’t slog their way through the entry edit flow are *not* Luddites. They’re just regular people. The idea that they’re Ludditical (I just coined that, props to me…) devalues the admirable goal of fixing a poorly designed interaction on an Internet resource that is regularly used by millions of people.

Wikipedia gets $890,000 for the Luddites  ::  The Social  ::  CNET News

Blogged with the Flock Browser

Tags: , , , ,

{ 1 comment }

Say what you will about Wil Wright’s Spore. One thing he and the team got right: the creator interaction. Ever since I downloaded Creature Creator, my 5- and 9-year old have been building ships, buildings, and creatures endlessly. And more importantly, they’ve discovered how to do this with minimal intervention from me.

Video of Hattie’s creature is here. His name is “Spino Jerry.” Not sure where she got that, exactly.

{ 2 comments }

This week I went to Washington DC to attend the U.S. National Design Policy Summit, a gathering of academics, government employees and representatives of professional associations who were focused on raising the profile of design in the United States. The gathering was organized by Dr. Elizabeth Tunstall of the University of Illinois – Chicago, a design anthropologist who wants to “create an actionable agenda of U.S. design policy for economic competitiveness and democratic governance among professional design associations, design educational bodies, and the design-related Federal government agencies.”

I’m still processing and internalizing my reactions to the meeting and what it all meant. I’m glad I went though. I met interesting people and learned about the trials, travails and tribulations of other professional associations like the DMI, AIGA, and the IDSA.

{ 1 comment }

Ouch, My Eyes

by Paul Sherman on March 6, 2008 · 0 comments

in Design, Web


(Click picture to see full-sized)

I know, it’s not nice to point at somebody’s work and say snarky things. And once you look at this site, it becomes clear that it provides a ton of functionality. But the design seriously detracts from the overall perceived quality of the site. The visual design just doesn’t scan, if you know what I mean. And that hurts discoverability.

If I was ready to put my money where my mouth is, I’d mock up a redesign. It’s easy to point out problems, harder to provide solutions.

Man, it’s a busy week. But I’ll try to put something together this weekend.

Blogged with Flock

{ 0 comments }

Ars Technica is reporting that several patent reform advocacy groups have banded together to collaborate on the effort to abolish software patents.

Says Ars:

Supported by the Free Software Foundation, the Public Patent Foundation, and the Software Freedom Law Center, the End Software Patents (ESP) project aims to challenge the legal validity of patents that do not specify a physically innovative step. In addition to helping companies challenge software patents in the courts and in the patent office, the ESP project will also work to educate the public and encourage grass-roots patent reform activism in order to promote effective legislative solutions to the software patent problem.

This is an important effort, and one that UX professionals should support. As I described in my article a few months back in UXmatters, software patents do more harm than good. They stifle innovation rather than protect and nurture it. As I wrote in UXmatters:

The sad fact is that companies often file for and the US government actually grants patents for user interface and interaction design “innovations” that are either strikingly obvious or have appeared before in other systems—that is, when prior art exists, as someone in the field of intellectual property would say. This means, as user experience practitioners, we are at risk of litigation every time we design an application. Each time we fire up Visio or Photoshop, create a new design, then put it out into the world, there’s a good chance we’re infringing on someone’s patent.

I hope that those of you who are active in the user experience field will learn more about this issue and choose to stand with the ESP project. Even if you don’t agree with me (and them), it behooves you to learn more about the issue. It’s quite easy to ignore – until you find yourself staring down the barrel of an injunction or subpoena.

Patent Reform Coalition Aims to Abolish Software Patents

Blogged with Flock

Tags: , ,

{ 0 comments }

TomTom Scolds In Advance

by Paul Sherman on February 19, 2008 · 0 comments

in Design, Web


(Click picture to see full-sized)

I bought a TomTom GPS device. The application that comes with it seems pretty usable overall, but there’s a funny interaction design on the “create an account” page. It displays the scolds in advance, before the user enters anything in those fields. I’m not sure what I think of it; I found it jarring when I first saw it. It does make the requirement obvious, but it’s kinda scoldy.

{ 0 comments }

Just thought I’d point to my latest UXmatters article. My idea for this article is that people get stuck at a certain point of understanding a system, and fail to progress beyond a few areas of a rich application.

? After initially becoming somewhat familiar with a system, people often continue using the same inefficient, time-consuming styles of interaction they first learned. For example, they fail to discover shortcuts and accelerators in the applications they use. Other people learn only a small portion of a product’s capabilities and, as a result, don’t realize the full benefits the product offers. Why? What can operating systems, applications, Web sites, and devices do to better facilitate a person’s progression from novice to expert usage?

It’s an idea I’ve been kicking around for a while. Since I owed UXmatters a column, I thought I’d explore it a bit. I’m still working it out.

{ 2 comments }