.cross.wired.mind.

As you may know from a pervious post I am a big fan of Robert Hoekman Jr.’s first book Designing the Obvious. Well I finally got around to picking up his new book Designing the Moment. Just like his first I was absolutely floored by the time I hit page xiii. Yep, not even into the real numbers.

This passage in particular had me picking my jaw up off the floor because it captured a core belief I have always held about user experience design but have never been able to say it quite this concisely …

Each moment has the potential to increase a user’s confidence or destroy his trust in a product or a company, and each one is an important piece of the whole experience.

Why? Because the task a person is attempting to complete at any given moment is the most important task to that person, at that moment.

It is our job to make sure nothing goes wrong.  To make sure that moment is enjoyable and productive, and helps our user feel smart.

- Robert Hoekman Jr. from Designing the Moment page xiii

This book is a fantastic follow on to Designing the Obvious.  His first book gave us the expression of the qualities of great web apps and the framework to create them.  Designing the Moment gives us an approach to creating great solutions for our users so that they will be truly and deeply satisfied with their experience.

I said this after reading Designing the Obvious and it is also true for Designing the Moment - if you have anything to do with the conceptualization and design of web applications, sites, or even traditional software then you should immediately buy this book.  This book presents some fantastic tools you can add to your user experience design tool box.

Today a coworker of mine asked me to put aside my years of experience in UX design, and everything I have learned from years of conferences, reading and research and look at a design problem logically.  Sounds odd doesn’t it.  Set aside everything I know so I can become one with some Vulcanesque ideal of pure engineering logic.

That is when it hit me.  If design were about pure logic then mathematicians would make the perfect designers.  Engineers could do it all.  Why have these pesky user experience designers when the answer is so clear and logical.  That got me to thinking of the internal debate we have had in the IA community - is IA a science, art, or craft.

The one thing I have learned from 11 years of experience web craft is that the folks that use the systems we design often act in ways we did not expect or predict.  That is what makes user experience design such a challenge - we deal with people and all of their idiosyncratic behaviors.  In other words - the first victim of the user experience design process is logic.

However, user experience design is not purely an art.  Intuition, emotion, and perception are all key components to user experience design but they do not operate unbridled.  User experience design also requires a bit of cognitive science, a dash of ethnographic methodology, and a solid dose of objective experimentation.

I believe our main tool of trade is intuitive design coupled with validation testing.  User experience design requires us to use both lobes, or to work with people that can compliment our own left or right lobe bias.  Over time we begin to build a strong sense of what will and will not work.  But we must always test our work.  Our intuition must be a measured intuition because, ultimately, the designs we create will be used by the least logical of operators - the human being.

Women who knit sweaters for men often find a less than enthusiastic recipient once they complete their work. (note - men knit too but this usually happens when women knit for men) For the knitter the work was a time consuming challenge. It took skill. It took time. It took many hours of hard work. Why is it that the men who get these sweaters simply do not appreciate what was done for them?

Because knitting is so time consuming the creation of the knitted object must hold the knitters interest. The yarn must feel good on the fingers. The stitches cannot be too repetitive or too simple. The color must not be a bland monotone lest the knitter become bored like a long distance driver watching the white lines of the road wiz by in endless procession.

The trouble is that most men want plain sweaters. One need look no farther than a local men’s shop to see the kinds of fashions that men like to wear. When men see sweater that is a many colored, intricately cabled, mash up of styles they see a sweater that they do not want to wear. Yes it was fun for the knitter to make but it is not what the guy want to wear in public.

The knitter is trapped in a cruel paradox - in order to make a sweater that a man will wear, she will need to use monotone yarn that might be thicker than she wants to use. She may have to use a simple pattern with row after row of uniform stitches. Producing it will be dull and will lack real challenge. Her choice is to enjoy knitting or make a sweater that a man will wear.

So what does this have to do with digital design? User experience designers want interesting projects. They get bored building plain old digital information systems. Information architects constantly look for new ways to build intricate structures, complex organizational systems, and sites with perfect browsing systems. Interaction designers want to build sites with sophisticated interfaces that solve challenging problems. Information designers want everything to be visually interesting and designed with a deeply artistic aesthetic.

We do this because the alternative is often dull and it isn’t always challenging. We want the work we do to be personally gratifying. We want to feel as if we have accomplished something great. Above all else we do not want to get bored. Creativity needs to be expressed. We must stay challenged. We must push the edges of the envelope. We strive for exquisite sophistication that takes complexity and makes it useable for the masses. We all want to build a better, cooler mousetrap.

That is not what the user wants. The user wants a tool that makes sense to them. The do not want to think about how it works - they just want it to work.

User centered design is not just about making products that people can use. People can use products that don’t work very well. User centered design is about making products for the people that will use them and not to make products that can be used but were primarily designed so that we could have a fun time designing them.

It does not matter who does it. It does not matter how much (or how little) skill they have as a designer. It does not matter if it was planned or not, tested or not, researched or not. Anyone can do it.

design happens

That is the problem with design - if you think it up and make it then you are a designer.

I have seen so many projects fail because unskilled designers tried to create. I am talking about web apps and other digital information systems created by the companies I have worked for over the past 10 years. I am talking about projects conceived by executives and then designed by them without any consultation with the folks inside their organization who have the skills to make their ideas reality.

Here is how a project typically runs - “the business” has an idea that will generate money, solve a problem, or meet a need (all just ways to make money really). The folks in “the business” look at what their competitors are doing, they think about what they would want, they talk to other “business people” and then they decide what they want to build.

They start a project to build their vision into reality. They want people to just do it. They do not want anyone to conduct the kind of research that would lead to a real understanding of how this product will be used. They do not want anyone to question their vision, even if that means refining it and honing it into an effective solution, product, design, etc. They do not want users to test the design to see if it can be used. They just want it done.

That is when projects fail.

So how do they succeed? Look at how the Palm Pilot came to be. Its creator, Jeff Hawkins used a block of wood that he carried with him for months to see how he would use mini computer. He actually tested his high tech vision with wood and some paper. He did the kind of research that takes a good idea and makes it a great idea.

Look at the iPod … Here is a device that is not the first digital music player on the market and yet it is now the dominant player out there. If the iPod designers had simply done what their competitors were doing would the final solution been as elegant and useable as the iPod we have today? No. Instead they tested, investigated, researched, and then designed the product for use.

For a product to truly succeed it must be intentionally designed to be used by real people. That type of design requires research, testing, and willingness to acknowledge that a good product is not always the one with the largest feature set. Why most product managers do not understand this simple truth is beyond my comprehension.

The iPod proved that rushing to market is not a justifiable motivator to cut corners on design. The success of the Palm Pilot shows that when you think about how people will actually use your product then people will actually use your product.

Design is more than ideas made real. Solid design happens when the designer stands to the side, turns down the ego, watches people do things, and then uses that as inspiration to create solutions that will work.

That is how design should happen. Not by the edict from an executive but from the needs of real people - observed, understood, and then used to make great things.

If you are an IA, UX’er, code monkey, software or web product manager, or an exec that makes big decisions about web base applications or software then you NEED to buy designing the obvious … you just may not realize it yet.

Why should you listen to me? Well first of all I am not earning a dime from this. I am just a oft frustrated IA/UX professional who has spent the last 10 years banging my head against the walls of corporate America to get them to learn exactly what Robert Hoekman Jr. wrote. Like all great books he has taken an obvious truth that has been hidden in plain sight and captured it so we can all see it clearly and learn from it. We now have a common language and framework to bring this subject into the enterprise, into our garage web app projects, into the community of practice, and help folks understand just how critical this is.

By next week I will post my full review. Don’t wait untill then - just go buy it. Now. I mean it. Go to wherever you buy books and order it up. I don’t care if you just bought Gears of War and your a little short on cash. Go sell some blood plasma or something.

If you have ANYTHING to do with the creation, design, or development of web application than go here right now and get the damn book.

Don’t make me get the flying monkeys after you.

The IA Summit was truly excellent - again.  This was my fifth year running and the quality never dips.  If you are an information architect or you do anything that involves organizing information in electronic media then you should go.  The IA Summit has been the single greatest source of professional development in my career.  Over the next few weeks I will post comments on the things I learned this year so stay tuned.

Andrew Hinton has given us a brilliant cognitive model to frame the discussion of of the definition of information architecture.

Here are two posts made on the IAI mailing list:

02/28/06 

I have often said that the practice of IA is like anthropology in that at the core of our discipline is a set of common concerns - organization, categorization, and navigation.  To me its all about the semantic relationships expressed in the information spaces we design.  Each area of practice (web 1.0, web 2.0, apps, physical spaces, virtual worlds, hypertext, etc.) has its own special approach to organization, categorization and navigation.  To me they are the core.

03/01/06

I think that organization, categorization, and navigation (maybe that should be wayfinding) are fairly distinct, as long as it is clear that we are talking about the evaluation of semantic distance and relationships in an infospace.  I have not encountered another discipline places semantics at the center like IA does.  Navigation is the only aspect of our core concerns that I see as being “shared” with other design disciplines, but when it comes right down to it the heart of navigation is the crystallization of semantic relationships into a means of wayfinding.  Interaction design and visual design also claim a stake in the design navigation systems, but their role tends towards the more mechanical and experiential aspects of navigation and not the structure created by a navigation system.

As to the question - should we care if other discipline lay claim to our core concerns?  No, not really.  Look at sociology and anthropology.  Here are two disciplines that share many core facets.  They are both concerned with the study of macro relations formed by humanity yet each discipline uses a slightly different approach and has slightly different methods.