January 2010

The First Thing We Do, Let’s Keep The Lawyers Out Of The UI

by Paul Sherman on January 31, 2010 · 1 comment

in Design, Hardware, Usability

Old-school readers of UsabilityBlog may remember my (ranty but well-reasoned) diatribe against EULA’s and how they’re presented in software user interfaces. (Also check out my follow-up posts here and here.)

This picture I took the other day  reminded me how easy it is to corrupt and degrade the user experience with obtuse and unfriendly language.

In this case, I was at the bank setting up an account. The rep handed me the account agreement, and then told me that the bank didn’t require me to sign the actual forms anymore; they’d recently begun collecting signatures electronically. I have to admit that bothered me a bit, because my “electronic” signature looks nothing like my pen and ink signature.

Putting that aside, the experience of providing my signature on the device was not good.

The face of the device I needed to “write” on was raised about 4-5 inches, and there was no way to comfortably position my hand while signing. The bezel was not flush with the screen, which caused the edge of my hand to bend in an unnatural way,  further deforming my signature.

And then there was the lawyerly language. We’ve all had the intimidating and negative experience of viewing a legal document in paper form. I don’t think a single person will dispute the fact that legalese is intimidating and obtuse. Not surprisingly, that experience is intensified when rendered digitally. And then there’s the ridiculous aspect of referring to something “herein”, which applies to a document, but certainly not to anything “in” the UI of the device I was interacting with.

And no, the full agreement was not presented onscreen for me to page through. The rep simply handed me the written agreement, then slid this device across the desk for me to “sign.”

The various user experience disciplines – usability, information architecture, interaction design, etc. – have been laboring for the 20-odd years of the tech boom to create great user experiences. Let’s not let the lawyers screw it up.

{ 1 comment }

So Bad It’s Good

by Paul Sherman on January 15, 2010 · 8 comments

in Design

Check it out now. Today. Go on, you know you want to. And here’s the scary thing: IT’S STILL BEING UPDATED REGULARLY. How scary/awesome is that?

Here’s the URL: http://www.Havenworks.com.

I should also post Ling’s Cars. I’ll get around to that this week. In the meantime, enjoy HavenWorks, and try not to have a seizure. (And if you do, it’s not my fault.)

{ 8 comments }

Guidelines For Design Guidelines

by Paul Sherman on January 8, 2010 · 1 comment

in Everything Else

This post grew out of my response to a question on the IxDA discussion board. Russ Wilson, fellow Austinite, UX VP at a large software co., and all-around good guy, posed this question:

I’d like to get people’s opinions on the value of “company-wide” design guidelines (for software applications/websites)?In theory, design guidelines could help to remove design bottlenecks by empowering others to create and apply the guidelines… but in reality they can also be hard to implement, confusing,restrictive, etc.

My response was:

…I can share some lessons I’ve learned while building guidelines and leading teams that produced and consumed guidelines.

1. Treat design guidelines as a design problem in and of itself. Make the guidelines findable, learnable, usable (and memorable) for the intended consumers. This means you need to understand your users’ needs. Some questions to ask yourself and your team are:

* Do they need to know the why behind the guidelines, or do they just need to know how to be compliant?

* Consider whether they (and therefore you) are constrained by the UI toolkit and available controls. That is, do they need implementation-specific guidelines? This is more typical for platform-specific software and certain web-delivered apps. Or do you have degrees of freedom more typical of web-based apps?

2. Make sure people can quickly and easily access the digital assets they’ll need to successfully implement the guidelines. Provide links to the assets (i.e., images, controls, CSS, code snippets, etc.) that will help designers and devs to implement the guidelines. Put the relevant links as close as possible to the guideline. Basically, put on your Tufte hat. (What can I say, I’m almost done with “Beautiful Evidence” so I’m looking at everything through Tuftian lenses right now.)

3. Make it so people can discuss and annotate the guidelines. Also, it’s constructive when the community can submit examples of how they’ve implemented or adapted guidelines. At some point you may find it useful to convert a community submission into a full guideline.

4. Examples examples examples. (And more examples.) It’s often helpful to mock up one of your organization’s existing applications to illustrate one or more guidelines. If nothing else, the team can then practice “cargo cult design” and just emulate your example.

5. Socialize the guidelines…but also socialize a release plan for future guideline changes. Design and dev teams absolutely hate to find out that they’ve complied with R1.0 of the guidelines, but you’ve rev’ed them to R1.1 or 2.0. If you’re making changes to the guidelines, make sure people know when the changes will be rolled out. And of course provide as many sneak peaks as you can.

6. Make sure that you coordinate with the folks who own the visual aspects of your organization’s brand. A little synergy here goes a long way. And they’re usually a great source of brand digital assets.

I thought this was blog-worthy, so I decided to post it. I’d love to hear about others’ experiences in this area of design and user experience management.

{ 1 comment }

You Can’t Make This Stuff Up…

by Paul Sherman on January 6, 2010 · 0 comments

in Everything Else

Y’know that last post of mine where I pointed out that I didn’t know what to do with the “Yes” button?

I discovered what that button does. It’s probably the second-worst case scenario. (First worst-case scenario is that it makes you lose data or a setting you’ve selected.)

It CLOSES THE WINDOW.

Classic. You just can’t make up stuff like that.

{ 0 comments }

What Am I Saying Yes To?

by Paul Sherman on January 6, 2010 · 8 comments

in Everything Else

I just took this screenshot this morning. Here’s the situation: I’d just installed new trackpad drivers on one of my Windows laptops. This laptop’s trackpad is a bit hinky, so I knew I wanted to get into the trackpad’s control panel and make some settings changes.

So I clicked the trackpad’s system tray icon to open up the control panel. And was presented with this screen.

Of course my first question was “What does clicking Yes do?” Look at that screen for a moment and put yourself in my shoes. I’ve just fired up software I’ve never seen before, I haven’t selected anything from the icon navigation at left, but it’s offering me an enabled Yes button.

I’ve been conducting usability tests for almost 14 years. During that time I’ve noticed that people are usually afraid to press a button or perform an action when they’re uncertain what will happen. I took to calling this phenomenon being “click shy.”

This is a great example of what causes a user to be click shy. It’s a shame, really. Sloppy programming – that is, failing to set the button’s state to disabled when no relevant selection is made – can have a raft of unintended consequences.

{ 8 comments }

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 }