Category Archives: UCD

You need to take a step before I can tell you if you’re going in the right direction

In itself the involvement of users in the design process is no guarantee of a successful product or service. Reliance on users alone to guide you to the “right answer”, means you could be in for a long and winding design journey.

Designers must be prepared to develop and test paradigms. Failure to do this means you’ll yo-yo for an elongated period of time, and have little of any substance with which to get any meaningful user feedback.

I have been in a number of infuriating situations recently (generally design committee situations) where the team has shrunk from taking any responsibility for making a decision and instead asked to get the users help in making the decision.

Now don’t get me wrong, I am not saying don’t involve users. Nor am I saying make firm decisions before you involve users. But I am saying that if you are singularly incapable of making a step in any direction until you get confirmation from a user that you’re going in the right direction, you might consider a new profession!

You need to take a step before I can tell you if you’re going in the right direction!

Users guide and inform decisions, but it is the responsibility of the designer and/or business to actually make the decisions. Yes they can be tough, but with user involvement you’ll get their pretty quickly provided you are prepared to ask the tough questions and create materials that enable users to inform the decision. After all you are getting paid for it, the user isn’t.



Those nice guy Eddie moments

The dynamic between a traditional design agency (i.e. one that has “fantastic” designers that win design awards, but have no clue about UCD) and a UX agency or consultant can be a tense one. It can reach boiling point when you throw a client into the mix.

Over the years I’ve been in a number of complex situations where my diplomacy and UCD ethics have been tested to the full.

Consider this scenario, you are running a debrief workshop off the back of some usability testing. The usability testing clearly showed that the product had significant issues in a number of areas to do with the interface design. The design agency who called you in to the project, and who only did so because their client insisted on it, is giving you daggers as with each new issue you challenge the quality of their design work. Meanwhile their client is smiling at you and giving them daggers wondering why they produced such rubbish.

It can become a stand-off of almost Pulp Fiction like proportions.

Who blinks first?

What do you remain loyal to “the truth” (i.e. what you observed during the research) or the business dynamic (i.e. I get paid by “them” so I have to make sure they don’t look stupid)?

When presented with these options I’ll always go with the truth and suffer the financial repercussions. But here are some other things you can consider.

1. Do unto others as you want to be done to

Remember what it felt like before you discovered UCD, or worked in an enlightened company. Would you really want someone rubbing your nose it in? They are likely to become defensive, which isn’t a good, collaborative dynamic from which to design from.

Choose your words carefully. Expressing the problem and recognising the fact that without user insight it was an understandable solution to come to, will go a long way towards getting everyone thinking in the right way.

2. Craft your message

Tell them how enlightened they are to have embraced usability testing and user-centred design (even if it wasn’t actually their idea, but their clients).  Tell them that by recognising that they needed to get user involvement, they will quickly get to a much better solution.

3. Focus forward

Surely it would be worse to be oblivious about these things than to know about them now and do something about it. Set the emphasis on moving forward and refining the designs based upon what we’ve learnt.

4. Acknowledge the constraints

If things are still uncomfortable in the room, a brief discussion about the timescales, business requirements and technical constraints can often help deflect attention from the poor designer who is either shrinking in his chair, or become red-faced in defence of his work.

“It wasn’t Hank’s fault we asked him to pull a rabbit out of a hat while sky-diving to earth on a ironing board.”

Alternate approach – avoid the discussion

An alternate approach is to avoid the three way dynamic entirely. Instead arrange two separate one-on-one meetings. This enables you to give the message as honestly as you need to without fearing the sensibilities of others.

In reality this means your work can be pushed under the carpet by the design firm – “the research didn’t really tell us anything we didn’t already know”.

The purest in me strongly recommends against this approach. The uncomfortable tension that comes from getting “the truth” out in the open often leads to a successful working dynamic. The freshness after the storm. If you avoid it, as this alternate approach suggests, you run the very real risk that history will simply repeat itself.

Workshop: IA and collaborative design

I will be running a 2-day workshop on information architecture and collaborative design on the 24th and 25th March 2010 at Rydges World Square, Sydney.

The workshop is titled ‘Information Architecture and Collaborative Design:The design behind the design of successful interactive products’. More details can be found over at the Ark Group website who are hosting the event.

The workshop will cover all sorts of good IA and collaborative design topics, such as:

  • Card sorting and other methods of user and stakeholder engagement
  • Prototyping, usability testing and iterative design
  • Designing and documenting a robust and flexible information architecture

I am sure I’ll post quite a bit more on the topics I’ll cover over the next few weeks and months as I collate the materials I’ll be using for the workshop.

If you’re interested in attending please contact Michael Moorcraft at or call him on +61 1300 550 662.

I hope to see you there.

UX Australia 2009

Idealism increases in direct proportion to one's distance from the problemI presented some thoughts around design pragmatism and idealism at UX Australia. I’ve uploaded the presentation to Slideshare, Pragmatism or Idealism: a user experience conundrum.

The presentation focussed on some of the interesting philosophical challenges I’ve found myself facing as I’ve taken user experience leadership roles on projects involving high degrees of complexity – and thus compromise.

I will extract the key themes from the presentation into a post over the next few days, but for the time being these images capture the essence of what I was attempting to convey.

Sometimes good has to be good enough

Design is compromise

I believe audio files and slides from the conference will be published soon. I am sure I’ll post links some of the talks I particularly enjoyed once I track them down.

Prototypes don’t need to be “finished”

Catching up on some old copies of the Harvard Business Review I was struck by this quote about prototyping in an article by IDEO’s Tim Brown, Design Thinking.

“Prototypes should command only as much time, effort, and investment as are needed to generate useful feedback and evolve an idea. The more “finished” a prototype seems, the less likely its creator will be to pay attention to and profit from feedback. The goal of prototyping isn’t to finish. It is to learn about the strengths and weaknesses of the idea and to identify new directions that further prototypes might take.”

I couldn’t agree with Tim more. As a user experience practitioner, prototyping is just about the most important technique I have up my sleeve. I am amazed when I hear people come up with excuses not to prototype:

  • It will take too much time
  • I need more time to finish the prototype
  • We can’t learn anything from anything that isn’t finished or more representative of the actual product.

What rubbish. All of these are excuses of people stuck in their old ways of doing things. The truth is that you can obtain valuable insights from very low-fidelity prototypes, and also that even when dealing with higher-fidelity prototypes you can get away with a lot of smoke and mirrors to minimise the amount of effort that goes into the creation of something that appears finished.

Tim’s point about “finished” prototypes being of less value is particularly insightful. The amount of time we invest in creating a prototype should be directly proportional to the amount of confidence we have in what we are designing. The less clarity we have about the direction the design will take, the less time we should invest in prototyping.

If we invest too much time in a prototype too early in the process we run the risk of investing too much in its success that we won’t be prepared to listen to, or have time to respond to, the constructive feedback we receive.

This is particularly troublesome if you are working on a project with fixed timescales. The more time invested in “finishing” each design, the less time there is to explore alternate designs, and the less time there is to respond to any insights obtained from user research.

When prototyping we should resist the temptation to cement our thinking around one particular design paradigm for as long as possible. Short prototyping sprints (to use the Agile vernacular) are far more preferable to the prototyping marathon many engage in. By remaining open to radically different concepts deep into the design activity, we remain nimble enough to realign our thinking as insights are revealed from user research.

Research suggests that using personas leads to superior products

A research study conducted by Frontend, Real or Imaginary: The effectiveness of using personas in product design, suggests that using personas lead to designs with superior usability characteristics.

The debate about whether personas work or not has been one of faith versus scepticism; claim versus counter-claim. This study demonstrates the effectiveness of using personas in the product design process and while more research is needed, this is now some objective evidence that using personas does work.

The study is far from the definite work that puts this debate to bed once and for all, but it is good enjoyable fuel for the fire and certainly confirms my own belief that, if nothing else, personas provide teams with a way of remembering key audience needs. Well worth a read.

When conducting analysis, don’t jump to conclusions too quickly

The following diagrams, copied from De Bono’s Lateral Thinking, provides a great example of why we should avoid jumping to decisions too early when analysing research findings. If we jump to conclusions too early, we run the serious risk of not getting to the most elegant solution.

De Bono’s puzzle involves adding together a number of objects. With each new object the challenge is to create a regular shaped object.

Step 1 is to put the following objects together…


Having successfully turned these into a square, we then have another object to add…


Turning this into a rectangle is fairly straightforward for anyone, but then it gets a bit trickier…


Having scratched out heads a bit, you’ll end at the final challenge…


Now this is a bit tricky and for most people there will be no obvious way of turning this collection of objects into a regular shape.

How often have you brushed a research finding under the carpet because it didn’t fit with the mental model of the findings you were developing?

The trick is to deconstruct the objects each time a new object is added.

The solution is as follows…