A Good Nielsen Quote...

From: http://www.useit.com/alertbox/mobile-ux-guidelines.html
"People want me to give hard and fast rules: don't show more than X menu items; don't write more than Y words per page; nothing should be more than Z clicks from the homepage. Sadly, UI design doesn't work that way. Usability questions seldom have a single answer. Rather, they are qualitative issues that specify the direction and nature of inevitable design tradeoffs."

Huh.

Seen on a semi-private women's restroom door.

I felt like going to the front and asking if there was a key for the restroom.

One More Steve Jobs Post...but not what you expect.

Steve Jobs was a genius. No question. I enjoy many of the products he enabled to be brought to market. He was a huge influence on my technology life.

But if one more person tells me that 'we don't need to talk to users, because Steve Jobs didn't talk to users to inform his designs', I'll barf on their shoes.

My contrary assertions:

He was a user of what he designed, so he had intimate domain knowledge. If you are designing something for someone else, and you don't have intimate domain knowledge, you need to get it. How? Engage the users.*

He had people who talked to users. If you don't have people to talk to users, you need to do it yourself.

Not everyone likes the iPhone or has one. Don't say that they do. And there are very poorly-designed apps for iOS devices, just like other platforms.

He was a marketing genius. He told us what we wanted, and we bought it. He could have sold us the iTurd. He couldn't know--and didn't design--everything we would do with his creations. He just gave us the platform in which to do it.

Consider this, from Apple's own Human Interface Design Guidelines:

"A great user interface follows human interface design principles that are based on the way people—users—think and work, not on the capabilities of the device. "

Last I looked, "human interface design principles" include the principle of talking to users.

By gosh, I wish I had a fraction of the visionary, arrogant, creative genius of Steve Jobs. But until I do, I'm gonna spend some time trying to understand my users.



_________________
*An example: While designing a system for healthcare professionals, I learned, from talking with healthcare professionals, that a "doc" is a physician. In my context of information technology, a "doc" is a document, or a file. In your design, you must remove ambiguity for your audience. Labeling is contextual, and you can't rely solely on your own frame of reference unless you are a domain expert. (And even then, you're only one domain expert.)

Huh.

Not sure if I'm more awed or baffled by the creative cheapness. (Note: the bottom part was broken, so they...yeah.)

Curious signage

I wonder what happened that made them be so specific?

Seems like you could simply say, "NO MOTORIZED VEHICLES BEYOND THIS POINT." What's not to understand?

Let me guess: this experience was designed by someone in IT?

Scenario: filling out a "form" online to request a medical appointment. Click "Confirm Request", and receive this message:

Surprisingly, I don't have a big problem with the fact that the "form" is simply a pre-filled input area that I edited. I found it simple to understand and use, except for the intent of the "Voicemail" question: are they asking "Does your phone have voicemail capabilities?", or "May we leave a voicemail with your patient information in it?"

But the error condition AND its helpful messaging are atrocious for your average healthcare consumer.

Gmail Menu (or, "If Only They Had Asked Me")

If you use Gmail, and if you have multiple Gmail accounts, you may have noticed you can sign in to two at a time, and quickly switch between them. Well...sort of quickly. The menu looks like this:

Even if you are signed into another account, you must select Switch account. Then you get this:

Why not display the two accounts I'm signed into right away, and allow me to make my selection with one click? Here's a suggestion, in which I can do everything I did before, but without two menus. 

Practicality (yes, another 'Tools' post)

There is a recent discussion on a LinkedIn group for information architects regarding requirements tools. The original poster asked for requirements analysis tool recommendations, and the responses have varied widely.

As the thread has gone on, it began to amuse me that here we are--business analysts and information architects--doing exactly what we shouldn't: recommending tools without knowing the requirements.

It's not a "one-size-fits-all" practice in which we work. Just like we as BA/IA/UXD folks wouldn't recommend a single technology solution or single user interface model for every business problem.

Many people swear by Axure, which is a great tool for developing high-fidelity prototypes. Rational is a great tool set for those who are using Rational Unified Process. For those using Agile, Rally can be a very effective tool. For us, a set of custom-designed Sharepoint web parts (in effect, spreadsheets on steroids) does the trick.

(A note on prototyping: I cannot recommend it enough as a technique for refining, as long as you identify the appropriate level of fidelity required to do the job. When we do high-fidelity prototypes, it can become challenging to manage customer expectations around delivery ("It looks like you're done, so why does detailed design and development take so much longer?"). Regarding the archaic tool set "Paper and Pen" (or "Pencil and Eraser", which are infinitely more efficient for people like me ), it may not be effective to rely on those for every situation. But the ubiquity of the digital camera makes taking a photo of a sketch--pencil or whiteboard--much more efficient for our internal processes than taking an extra hour or two creating a Visio wireframe or Axure mockup. And when you're charging your customer, an hour or two per use case can make a difference.) 

So, just like the work we do, I'd want to know more about the requirements of the organization or project before recommending a solution. So, as I try to boil it down, here are some key inquiry points:

- What processes do the tools need to support?

- How mature / flexible are those processes?

- What is the scope and scale of the projects you need to define?

- What are the types of requirements and level of detailed analysis you need to perform?

- Who is your audience for the outputs? Do you have capable, experienced developers and customers, or do they need a bit more hand-holding?

- How well-developed are your BA/IA skills? What techniques do you use for gathering requirements?

- What is your budget? We have none, so specialized tools aren't cost-effective for us. We are trying to be innovative by finding new uses for the enterprise tools we already have in place.

- Are there any regulatory or legal constraints that require a particular level of analysis or documentation rigor? That might prompt you to use a different toolset.

I'm sure there are several more....

So, the answer, as usual, is "It depends."

From the "Ah, the Irony" Department

We bought this can opener yesterday. It's the kind that doesn't leave sharp edges on the can or lid. We were amused to find it packaged in one of those rigid clamshell packages--you know: the kind with the really dangerous, sharp edges.

Do you know the recommended method for opening rigid clamshell packages to avoid injury? With a can opener.

If only we had one.

Design for Disability

"In the context of an environment or society that takes little or no account of impairment, people's activities can be limited and their social participation restricted. People are therefore disabled by the society they live in, not directly by their impairment." --Graham Pullin, "Design Meets Disability"

I am not a tool

Or am I?

This year's theme: TOOLS.

I've been in several meetings where IT people have asked what tool we use for usability, or Agile, or design. I am surprised that people assume that having a tool gives you the ability to implement these practices effectively.

• For Agile, we don't use Rally: we use spreadsheets (SharePoint lists, to be precise).
• For Design, we use everything from Dreamweaver to Notepad to paper and digital cameras. 
• For Usability, we use everything from Morae to paper. Yup, paper.

Get it? It's not the tool. It's the process, skills, and oversight of both. In other words:

• Having Project doesn't make you a skilled project manager.
• Having Word doesn't make you a best-selling author.
• Having a toolbox doesn't mean you can build a home that would meet code.

Learn what it's about first. You are the tool.

No caption needed.

I don't believe this warrants any discourse about WHY it's a poor form design choice, does it?