Archive for the ‘Usability’ Category

Trade-offs

Wednesday, June 30th, 2010

Great products require trade-off. Which features should you promote with big, glossy buttons? Which materials or technologies should you use, and at what cost? When should you release it? How heavily should you test it first? Should you fix a crash bug that affects 2% of users or a cosmetic bug that affects 90%?

These trade-offs are unavoidable. If you don’t make them explicitly, you make them implicitly. Can’t decide which feature get a big button? You can create ten buttons but you’re making another trade-off: each will be a little less prominent, and your product’s simplicity and elegance will suffer.

Trade-offs are necessary at every stage of the product lifecycle:

  • Apple is often praised for simplicity. Less is more: remove all the physical buttons and do the rest in software. But that’s not the whole truth. The iPhone has two volume buttons, a power button, a Home button, and a ringer switch. Only the power button is necessary. Someone made a trade-off, sacrificing a certain degree of simplicity for the convenience of four more buttons. The result may, in fact, feel simpler: without taking the phone out of my pocket I can adjust the volume or set it to vibrate. What we call simplicity is, in fact, a successful trade-off.
  • Facebook has repeatedly favored speed over caution, angering users by releasing features and design changes (e.g. the newsfeed) without vetting them thoroughly. Many look to the resulting uproar as a cautionary tale, but I believe this is the wrong lesson. At worst, Facebook’s tremendous growth has proceeded in spite of these choices. But I suspect Facebook has succeeded because of them: by trading speed for pre-release research and by making sure they can correct course quickly, Facebook has innovated, stayed ahead of the competition, and gotten free user research in the bargain.

Make no mistake: trade-offs are hard. They require sacrifice. They require risk. But then, it should come as no surprise that these qualities are needed for great product design as well.

Dialog Box #723: Humor Alert

Saturday, April 25th, 2009

Humor Alert

Trusting Designers

Monday, March 23rd, 2009

Some concise and worthwhile thoughts on design and designers from Kevin Fox, taken somewhat out of context:

Data-driven design is a vital tool for hill-climbing iteration of a site, but you should take great care not to use it as an appeals process whenever you and your designer reach an impasse. It sidelines the designer into being no more than a brainstormer, devoid of design ownership…Also please keep in mind that everyone has opinions on design, and that your UX professional has devoted years of their life to learning to separate their subjective opinions from their objective understanding about how the larger audience will interpret an interface. It’s not as demonstrable as code that passes unit-tests, but trust in it anyhow.

from Google Design: The Kids are Alright

Crockford on Feature-Driven Design

Sunday, January 4th, 2009

Some well-chosen, practical words from Douglas Crockford on the dangers of overly feature-driven design:

We see a lot of feature-driven product design in which the cost of features is not properly accounted. Features can have a negative value to consumers because they make the products more difficult to understand and use…It turns out that designs that just work are much harder to produce than designs that assemble long lists of features.

Features have a specification cost, a design cost, and a development cost. There is a testing cost and a reliability cost. The more features there are, the more likely one will develop problems or will interact badly with another. In software systems, there is a storage cost, which was becoming negligible, but in mobile applications is becoming significant again. There are ascending performance costs because Moore’s Law doesn’t apply to batteries.

Features have a documentation cost…Features that offer value to a minority of users impose a cost on all users. So, in designing products and programming languages, we want to get the core features – the good parts – right because that is where we create most of the value.

Crockford, Douglas. JavaScript: The Good Parts, pp. 99-100