Design Consequences: A fun workshop technique for brainstorming & consensus building

Design Consequences

For my recent BarCamp session I shared a design technique that a colleague and I developed quite recently that we’ve found to be quite successful in both generating great design ideas and developing consensus about the design approach for projects within a multi-disciplinary team.

We call this technique Design Consequences, due to the similarity it has with the similarly named childrens games. We tend to use it in the earlier stages of the design process, although it can be used for more detailed interface design problems.

So, how does it work? It’s pretty simple really.

What you need:

  1. a clearly articulated design problem and design goal(s) – for the BarCamp exercise our design problem was to design an electronic version of the BarCamp session wall where people could add their own session and choose which sessions they were going to attend. 
  2. some design ideas or components – when I do this in a client context, we do this by spending time beforehand looking at our specific challenges and seeing how other people have approached them, and trying to understand design techniques or principles that work (as well as those that don’t). This gives people access to a much greater repoirtore of ideas to draw in the Design Consequences exercise.
  3. a multi-disciplinary team – try to get the entire team if you can. The exercise works best with no more than 8 people involved, but it can be done with more if required. Get management to the table, bring all kinds of designers, bring the product managers and marketers, bring your developers. Bring everyone you can, as long as they’re familiar with the project and the design problem.
  4. lots of paper and markers and post its – make them as colourful and fun as possible. Make it look like a crafting session. A sense of play and enjoyment is key to this exercise.
  5. some examples of the type of output you’re expecting – anything that starts with the word ‘design’ can be very intimidating and scary. Lots of people ahve been told throughout their lives that they can’t draw, or that they aren’t creative. I have some *very* scratchy samples that have been created by people who design for a living. I show these before we get started so that people realise quickly that pretty drawings are not part of the equation.
  6. A bundle of energy – you need to be just a little bit hyper to run this exercise :)

What you do:

  1. Round One – everyone has seven minutes to design, individually, the the first page that users would see when confronting the ‘design problem’. So, a typical example would be a website homepage, but it could be any part of an application or website or even, say, an email. The faciliator(s) should participate, but keep an eye on the clock and give some warnings with a few minutes to go, and again at about 30 seconds.
  2. Round Two – here’s the consequences twist. Everyone picks up the page they’ve designed, then passes it on to the person on their right (or left, it doesn’t really matter). Everyone then has to review the page they’ve received (ask for clarification from the original designer if it’s a little sketchy in places), then decide – if you were the user, what would *you* interact with, and what would happen next. You have seven minutes to draw ‘what happens next’. (Don’t tell people about Round Two before Round One, it’s much more fun when it’s a bit of a surprise).
  3. Show and Tell – we then go around in a circle and each person describes the page they received, what aspect they chose to interact with and why, and then describes what they designed next. Discussion is encouraged.

What do you get? Lots of great data, and lots of great conversation fodder.

It’s a good idea to capture as much of this as possible as you go around the group. Of course, the best way to do this is to write up ideas onto post it notes as you go and stick them on the wall. There should be an ‘in’ section of the wall and an ‘out’ section of the wall. (‘In’ means that the idea has legs for this particular design problem). Affinity sorting on the run also helps to draw out the key themes or ideas that have emerged from the exercise. You should be leading the group discussion, helping the group to gain consesus and make decisions as to the design approach to be taken in solving the design problem, and trying to document these decisions as you go.

This process can be quite time consuming and intense, but more often than not there will be a few key ideas that the group is particularly enthusiastic about and that really propels the decision making.

By the end of the session you should be in a position where everyone is in agreement about *what* will be included in the wireframes that comprise the next phase of the design process.

Why would you use this approach?

  • It makes a great change from the talk-fest of meetings
  • It generates lots of ideas – and often some really great ones 
  • It stops people getting to attached to their design ideas and makes evaluation and critiquing more effective
  • It helps get all the team feedback and ideas into the pot (in particular, it’s great to get management and technical input at this stage)
  • It drives buy-in, involvement and consensus
  • It pulls in cross-discipline scills (for example, developers are often really great at quickly identifying great ID approaches for Rich Internet Applications)
  • You’d be amazed what you learn earlier rather than later by involving the entire team at this early stage
  • Getting lots of brains involved in the design process can uncover some really creative gems
  • It makes the design process faster
  • It’s fun!

So, there you have it. Some quick notes on a technique that’s been quite useful for me lately. I’d be interested to hear what you think of it and if you try it, to see if you too find it useful.

What is this thing you call UCD?


Whenever arguments about User Centred Design (UCD) get started, in my experience, it’s due to a lack of definition. What is UCD? What do you actually need to *do* to be able to claim that you’ve used a UCD process or philosophy or methodology?

Good question.

I borrowed the diagram about from the Flow website. It’s not very pretty, but it does outline the general process that a UCD flavoured project will take.

Now… you don’t need to do every one of the activities listed here in order to be ‘UCD Compliant’, but you will need to take user input at each one of the points shown in this diagram – Research, Concept, Design, Implementation and Launch.

That is pretty much what defines a UCD project – it involves *real* people who are actual or potential users of your product, and it involves people at each of these points, allowing you to check and iterate your design at each stage of the project.

Let’s examine a few scenarios:

I do user centred design, I think about users all the time when I design.

This is not UCD. Thinking about users is very different to actually meeting them, talking to them, watching them interact with your product, or exist in the space for which your product is designed. UCD is more than just thinking about users.

I am a talented designer, and I know this domain. I don’t need to use a UCD process. I can make a good guess about what the right design is and then test that design, rather than doing all that research at the beginning.

This is frequently UCD in disguise. You see, you *can* re-use your research from project to project. If you are are designer who knows all about a particular client, or design problem, or subject area, or type of product this is very often because you’ve been through the UCD process to acquire that knowledge in the first place.

I don’t have time for all this UCD malarchy. It takes too long.

One of the great things about the UCD methodology is that it can ‘squeeze to fit’. You don’t need to do all the exercises for each step. You can improvise each activity to fit the resources, time, budget that you have available for the project. UCD gurus including Jakob Nielsen and Deborah Mayhew both advocate getting as much as you can from each step, using the methods and means most appropriate to the project.

But, don’t throw out any of the steps. That way trouble lies.

All lifecycle tasks will always apply, but they can be expanded and contracted depending on the requirements, characteristics, and resources of a particular project.

Deborah Mayhew, The Usability Engineering Lifecycle.

So, when I’m talking about User Centred Design (and, in particular, asking for reasons why people might not choose to use it) … that’s what I’m talking about.

How’s that fit with your idea of UCD? About right? Any objections?

why bother calling if you call so late?

Don’t get me wrong… it’s not that I don’t want to work with you. I’d love nothing more to help make sure that your design is great and people love to use your product.

It’s just…  by the time you get to the part in your project plan that says ‘Usability Testing’, there’s not much I can do. You’ve left things too late.

Sure, I know. That’s when you do the usability testing, isn’t it? In that mad rush when you’re trying to get everything coded up and launched. I know, because it usually means that we don’t get much time to do the testing, and it’s usually not with the finished product.

And, you know… that probably would be ok, if we’d have done some testing earlier on in the piece.

OK, so you might not call it testing. You might call it research. Or you might just call it putting some ideas in front of people who might be using your product in the future and seeing what they think.

No, we don’t need your finished product before we can test. Not at all. We’ve tested with scraps of paper in the past and discovered we were heading down the wrong path altogether. We’ve learned a LOT about how our design should work even with some ugly wireframes.

And the great thing is that scraps of paper and wireframes cost nothing… compared to the amount you’ve invested in getting to the ‘Usability Testing’ line item on the project plan.

Compared to the amount you’ll probably have to spend if you want to implement any of the things we’ll probably learn if we do that testing now.

Of course… between you and I…. we know that’s probably not going to happen anyway, is it. There’s no time for changes. There’s a launch date fast approaching, and hardly enough time to finish the work you have already.

We’re just ticking a box here, aren’t we. With the best of intentions.

It’s a shame tho’. We could have been a good team.

We could have got to a kick butt design, one that we *knew* would work. We could have stopped all this coding and re-coding. We could have had good strong answers to questions that the business was asking. We could have taken so much of the guesswork out of it.

We could have been launching this thing with out the sneaking suspicion we’d be back at the drawing board (literally) in the very near future.

But I’ll tell you what I’ve found, and you tell me that you don’t have time to do anything about it.

And hopefully, next time, we can work together from the beginning.

I think that would be a much better idea.


Give me one good reason you can’t use User Centred Design in your project… Submissions Open!

I’m collecting reasons that you’ve heard or used as to why you can’t use a proper UCD (User Centred Design) methodology in your project.

Not just ‘yeah, I think about users when I’m doing the design’, but actually involving *real* users in your design process. Doing a proper UCD methodology.

How do you rationalise using UCD in your projects?

How have you heard other people rationalise it?

If you’re a UCD consultant, what reasons do you come up against and have to refute regularly?

Let me have ’em.