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.

</rant>

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 mmoorcraft@arkgroupasia.com or call him on +61 1300 550 662.

I hope to see you there.

UX Australia 2009

I 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.

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…

A bad project manager can spoil even the best user centred intentions

All those that espouse user centred design as the elixir to all ills aren’t seeing the full picture. The reality is that organisational and other factors often outside of your direct control are highly influential in determining the successful execution of your work.

Even with a solid user centred design approach, the success of a project can be scuppered by factors such as a technology team rooted in “old school” development approaches. The benefits of user centred design can’t be fully realised until there is buy in from the full project team.

The influence of a bad egg

A project I recently worked on was completely stymied by an unreceptive old school project manager. He was of the “the less we promise to deliver, the more chance we have of success” school. He felt that the prototype we’d spent months and months iterating was purely illustrative of the kind of thing we wanted despite repeated attempts to convince him otherwise.

Another favourite quote of his was “you’ll know what the users will get when we give it to them”. It seemed like it was a power trip for him. “You will get what I give you”. The concept of user experience was alien to him.

He, and the entire IT department behind him, were used to delivering whatever they could in whatever time they had, lobbing it over the fence and never giving it another seconds thought. He was used to sitting in his ivory tower and delivering things without any care of whether they met user needs, or as is more likely completely frustrated users. He was primarily driven by deadlines rather than having any focus on the quality of what was being delivered. Thus throughout a project in which it was increasingly evident to everyone that we would fail to deliver on the intended delivery date, he continue to offer nothing but positive messages around the likelihood of meeting the launch date.

He was convinced he could meet the launch date because he paid no attention to the quality, or user experience of what he was proposing to launch.

Incentivising people by anything other than the ultimate success of the project is wrong

The problem was that our bad egg was incentivised to deliver the project by a certain date. He had no care for the quality of what was delivered. He didn’t give a moments thought to “fancy new notions” such as user experience. Having such an influential figure in the project having no long term incentive in the success of the project was ultimately leading the project to almost certain failure.

In a warped way I can kind of understand his position. He was doing what he was being asked to do by the people that hired him. The real problem is that the organisation not only accepted it, but actually encouraged his approach. But then again many organisations do just that.

If we hadn’t had such a supportive business owner and gone through such an extensive user centred process, and had been able to cry long and loud about every proposed compromise required to meet the project deadline, the entire project would have ultimately failed.

Thankfully our cries were eventually listened to, the voice of the user prevailed, and our bad egg was escorted from the building (literally!).

The result is that the project was much delayed, but the user experience ultimately prevailed. It is good to see that it isn’t only in the movies that the good guys win.

This experience has highlighted to me the importance of getting the whole project team on board. For the user experience practitioner it becomes essential to be able to share and convey the importance and impact of each compromise that is suggested as the project proceeds. It also highlights the importance of continued involvement throughout the entire project lifecycle.

10 tips to help foster innovation

The need to be right all the time is the biggest bar there is to new ideas. It is better to have enough ideas for some of them to be wrong than to be always right by having no ideas at all.

Normally one is only taught to think about things until one gets an adequate answer. One goes on exploring while things are unsatisfactory but as soon as they become satisfactory one stops. And yet there may be an answer or an arrangement of information that is far better than an adequate one.

Both quotes from Edward De Bono‘s Lateral Thinking which I have been re-reading for the first time in many years.

The book, originally published in 1970, echoes the kinds of issues and concerns I still hear from clients today. For example, over the last few weeks I’ve heard many organisations lament the difficulty of creating green field, genuinely innovative products and services. They have talked about “being trapped within existing paradigms” and “unable to escape the way things are currently done”.

What is worse is that they express difficulty in finding people capable of helping them think differently about their particular situation. Is it because so many UX practitioners spend so much time using convergent thinking approaches to help optimise solutions? Is it because of a dearth of UX practitioners with a background steeped in design theory? Is it because organisations aren’t willing to create the time to explore alternate approaches or commit the resources to do so? Or is it some other reason entirely?

Whatever the real reason, experienced UX practitioners need to know when to use divergent thinking tactics and when to use a convergent approach.

The following are ten tips how to encourage divergent thinking within a workshop environment.

1o tips to help run a successful innovation workshop

1. Set rules and roles. Providing a constructive environment for creativity requires a few rules and roles. There is only really one rule; 1. no critiquing of ideas until a follow-up evaluation session. There are only three roles; 1. a facilitator to guide the session and pre-prepare topics and stimulus materials, 2. a note-taker to capture the ideas that are generated during the meeting, and 3. a number of participants.
2. Don’t make creative sessions too long. Around 30 minutes, and certainly no more than an hour, is enough to generate a range of ideas that can then be analysed, evaluated and turned into concepts.
3. Don’t fall into the trap of thinking you can do it on your own. Although genius design does happen, a collaborate process involving a small group is far more likely to consistently produce fresh ideas in a timely manner. Anywhere between 5 and 15 people is a good number. Less experienced facilitators may prefer to start with smaller groups.
4. Don’t expect magic to happen quickly. Many teams, especially those within usually traditional, formal, “always right” organsations, require time to warm up to divergent thinking. Quick warm up exercises may be required to get the group out of the business-as-usual convergent thinking mentally and into a useful headspace.
5. Don’t stop when you encounter the first acceptable idea. Although it may end up being the best idea. Continue thinking, exploring and sketching alternate solutions. At the very least these will validate that the acceptable idea is in fact the best idea, and by continuing you may actually identify a better idea that would otherwise have gone unnoticed.
6. Don’t critique or criticise ideas before others are given the chance to consider them. By focusing on the interesting aspects of an idea can spark other more practical thoughts, but if you focus on the impracticalities you may kill an idea before it has chance to breath.
   
7. Don’t fear failure. To have one great idea you’ll have to have many not so great ideas. The trick, as Scott Jenson puts it in The Simplicity Shift, is to “fail fast”.
8. Trust the process even when all around you are in doubt. Chances are you’ll have people who think what you’re doing is “fluffy”. You might even have people who storm out of a workshop because they don’t see the value in what you’re doing (I certainly have!), but even in the darkest hours you need to believe that good will come by encouraging people to think different about their products and services. The very worst that can happen is that a company realises that there is no better way than the way they currently do things. Validation of the status quo is a valid output from the activity provided the group has spend time exploring truly divergent alternatives.
9. Focus on quantity of ideas not quality. You have forever to evaluate which ideas are good and bad. Don’t run the risk of stymieing radically different approaches by focussing on refining a single idea even if it does initially appear to be the most viable.
10. When all else fails… consider the existing patterns, models and processes within your product or service. Focussing on and remodelling sub-components can help break down the existing norms and enable free-er thinking about the bigger picture.\

The secret to Xero’s success

Interesting to read Xero, who Jakob Neilsen decorated as having one of the 10 best application user interfaces, talking about one of the secrets to their success on their blog, One secret to our success. To quote:

In our methodology, the prototype is the specification. It speaks for itself. Our developers use the prototype as their blueprint throughout the development process, all the way through to final QA testing.

It’s important to clarify what I mean by prototypes. We don’t create working prototypes. We create design prototypes called screenflows: click-by-click simulations of the user experience, showing every interaction necessary to complete a given task. A screenflow is based on a scenario of a person completing a common task. We simulate all the screens, all the clicks and all the data entry necessary to start and complete the task. The result is a slideshow that simulates somebody using the software.

Screenflows are an ideal blueprint for developers. They make it obvious what needs to happen, when, where, how and why.

If you haven’t tried out Xero’s accounting application, you can sign up for a free trial and have a look for yourself. Certainly a very impressive experience, even more so for anyone who has ever used MYOB or one of countless other pieces of hard to use accounting software.