robert hoekman, jr. / blog
Note: This is the old blog for rhjr.net. The new one is here.
Complexity causes 50% of product returns
This is an older article - it came out in March - but I still love it. ComputerWorld reports that complexity causes 50% of product returns.
The last sentence in the article really illustrates the need for designers to get involved in the very beginning.
"[...] most of the flaws found their origin in the first phase of the design process -- product definition."
Product definition is where usability starts. That's where we should start, too.
The last sentence in the article really illustrates the need for designers to get involved in the very beginning.
"[...] most of the flaws found their origin in the first phase of the design process -- product definition."
Product definition is where usability starts. That's where we should start, too.
Microsoft's version of simplicity
Microsoft has a "Design Principles" article up in the MSDN Library about their new "Simple and Powerful" approach to Windows Vista application design. In it, they define the word "simplicity". It goes like this:
"Simplicity is the reduction or elimination of an attribute of a design that target users are aware of and consider unessential."
So let me get this straight. First, you somehow make users aware of the feature. Then you get them to tell you whether or not it's essential. If it's not, you remove it.
Poor, pathetic Microsoft.
Removing unessential elements from an application or interface can certainly make it better by default, but it's much smarter to design for simplicity and clarity in the first place. And "simplicity" is not a word meant to reflect process. It's meant to reflect the nature of an application.
"Simplicity" means justifying everything in the application by proving it's essential. It means making task flows and interations clear and concise so that a user's mental model can be maintained and users can be confident and productive.
Simplicity is realized when we design simplicity on purpose, not arrive at it by accident when our users tell us how to get there.
Be authoritative. Be unafraid to say "This is how it must be done."
"Simplicity is the reduction or elimination of an attribute of a design that target users are aware of and consider unessential."
So let me get this straight. First, you somehow make users aware of the feature. Then you get them to tell you whether or not it's essential. If it's not, you remove it.
Poor, pathetic Microsoft.
Removing unessential elements from an application or interface can certainly make it better by default, but it's much smarter to design for simplicity and clarity in the first place. And "simplicity" is not a word meant to reflect process. It's meant to reflect the nature of an application.
"Simplicity" means justifying everything in the application by proving it's essential. It means making task flows and interations clear and concise so that a user's mental model can be maintained and users can be confident and productive.
Simplicity is realized when we design simplicity on purpose, not arrive at it by accident when our users tell us how to get there.
Be authoritative. Be unafraid to say "This is how it must be done."
Book update
I'm somewhere in the middle of writing Chapter 8 of my 9-chapter book, Designing the Obvious, and a few flattering compliments have come my way. At risk of sounding arrogant, I thought I'd share them.
First, my editor, Wendy Sharp, says that she thinks the book is good enough that she could probably just pass it off to the copy editor with a quick proofread. But she also thinks it has the potential to be one of the greats, so she wants to spend the time and energy it takes to make that happen.
Second, the copy editor, who is the first person to read any of the book besides my editor, says she thinks every software developer should read this book.
That's exactly the response I was looking for. That's a very good sign.
Designing the Obvious should be out sometime in September or October. We're aiming to have it available for FlashForward 2006, where I'll be giving a presentation by the same name, but it may be a bit later than that.
First, my editor, Wendy Sharp, says that she thinks the book is good enough that she could probably just pass it off to the copy editor with a quick proofread. But she also thinks it has the potential to be one of the greats, so she wants to spend the time and energy it takes to make that happen.
Second, the copy editor, who is the first person to read any of the book besides my editor, says she thinks every software developer should read this book.
That's exactly the response I was looking for. That's a very good sign.
Designing the Obvious should be out sometime in September or October. We're aiming to have it available for FlashForward 2006, where I'll be giving a presentation by the same name, but it may be a bit later than that.