Monthly Archives: January 2009

How many alternatives, concepts, or sketches are enough?

Harry Brignull’s post, Why you shouldn’t rush into a solution too quickly, about some of the slides from my presentation at OZIA has sparked off an interesting thread on the IxDA discussion list, How many alternatives, concepts, or sketches are enough?

The key point I was trying to make with the slides is that reaction to initial design sketches often sets the design direction and constrains the design space within which we explore potential solutions.

My intention with the slides was to warn practitioners of this, and encourage that they actively try to keep the design space unconstrained for as long as possible. It is difficult to do this, especially if you get positive feedback from the first sketches you share with colleagues/stakeholders/users.

As soon as we stop exploring different concepts and start iterating, we are optimising an idea rather than looking for different (innovative?) solutions. As another of my slides suggests, not every idea has the same potential:


So to give an answer to the question (How many alternatives, concepts, or sketches are enough?), I advise exploring as many different ideas as possible within the constraints (budget, time, etc) that are imposed upon you.

Ultimately how long you spend exploring different concepts depends upon the business objectives. If the business is trying to quickly squeeze another 5% revenue from the product in the quickest amount of time, fewer sketches and more iterations will probably get them there more quickly.

If the business has loftier ambitions, I would advise exploring more concepts and obtaining more early stage input from users before getting into an iterative process.

There isn’t a single set of user centred design activities, user centred design scales to fit. The activities and time you spend at each phase of the project must to be tailored to the specific objectives, aspirations and constraints of the project.


Context is everything

Harry Brignull’s post (Why you shouldn’t rush into a solution too quickly) about my OZIA presentation reminds me that I promised to extract a few of the key messages from the presentation and blog about them myself.

The key message of the presentation was Iterative design alone can’t save us.

Iterative design alone can't save us

As you can probably guess from the main theme, my argument was that we must ground our work in a rich understanding of the context of use, or else we run the risk of creating well meaning rubbish.

I argued that although an essential ingredient in good user centred design, iterative design alone can’t stop us from creating bad products.

To make my point, I cited the highly iterative, but decidedly non-contextual development of the UK Government’s SA80 rifle. The rifle was developed over a number of years and involved much testing at firing ranges.

The problem was that the testing was conducted under far too controlled conditions. The rifles were carefully caried out to the firing range, rather than being dragged around in the real conditions in which they would need to operate. The result being that when the product was ‘launched’ it still had major (**major**) issues. Such as:

  • Couldn’t be fired from the left shoulder
  • It went off when dropped
  • Safety catch would break if the trigger was pulled hard
  • Plastic would swell in rain and jam the safety switch on/off
  • When running a heavy ammunition magazine would fall out

My argument being if we only conduct iterative design in controlled usability testing labs, using pre-defined tasks then what is to stop our projects going the same way as the SA80?

My full presentation is fairly visual rather than textual, so it may not make sense out of context (chortle).

The information about the SA80 project comes from James Meek’s excellent article, Off target, from a few years back in the Guardian.

Prototyping rich internet applications (RIAs)

Commenting on a thread on the IxDA discussion list, Jared Spool points us in the direction of this fantastic low-fi example for communicating about a rich internet application.

I certainly like the power of the stop-motion video, but as with any form of interactive prototype if it means going away from your core skills it means unnecessary time learning the tool you’re using to create the prototype.

Intuitive design replaces dozens of keys with a wheel!

Apple introduce the Wheel:

I am equal parts amazed and skeptical. I can’t see it catching on in the typing pool!

Are Apple guilty of going the same way as the people that designed my washing machine (Universal buttons: Now my washing machine thinks its a DVD player)?

User centred design doesn’t mean sacrificying business control

I have been out and about pitching for work quite a bit recently (which explains why my blog has been quiet!). It has been around two years since I last did this, so as well as scratching off the rust, I’ve also had fairly fresh eyes (and ears!) to the kind of things that clients are looking for and common misunderstandings about user centred design.

I have been particularly struck by two different clients thinking that user centred design means doing just what customers say that want at the expense of the business’s objectives. I appreciate this may be a literal translation of user centred design, but it is too simplistic and does a disservice to the pragmatism that goes into the design process.

Obviously I quickly put them right on this.

It is important to understand that user centred design not only means designing a solution to meet the needs, comprehension and desires of real users, it also means thinking pragmatically and creating a solution that works both for the business and users.

There are four key concepts behind user centred design. These are:

  1. Structured user involvement
  2. Prototyping
  3. Iteration
  4. Multidisciplinary teams (including key stakeholders such as the business and technology)

Forget any one of these and you are in trouble!

It is wrong to practice UCD in an idealistic vacuum without structured collaboration with multidisciplinary teams.

It all of which puts me in mind of my previous posting about my frustrations with misunderstandings of the term usability testing (Usability testing is really design research).