Stop, collaborate!

I just finished an amazing project. The reason it worked so well was that it was the closest I have come to truly creating a collaborative design environment with my client.

I was embedded in their organisation with a small team of people from all sections of their corporate structure and we created a concept prototype that exceeded all their (and, frankly, my own) expectations.

Collaborative design is one of those things that many people talk about but few people do. If you fancy having a go (do it!) here are 12 things I learned about turning a group of non-designers into designers:

Setting the stage
1.  Go where the action is
2.  Frame the problem meticulously
3.  Avoid abstractions at all costs

Creating designers
4.  Force them to draw and draw and draw
5.  Let them come up with the ideas
6.  Explain scary design concepts
7.  Make use of “yes, but we’re not doing that now”
8.  Don’t be afraid to over-rule (but explain why)

Making something new
9.  Design twin (or triplet) prototypes
10. Build the prototypes away from the team
11. Test at least three times
12. Force yourself to move too fast

Warning: this post has turned out to be way longer than expected! If you make it all the way through, tell me you made it on @myddelton.

1. Go where the action is

I spent two days a week for 10 weeks in their offices. We started out in a meeting room and then ended up camped out in a breakout area. I got to know how to use their coffee machines, where all the toilets were and even made some friends with passing people.

This is less comfortable than working from your own desk. It can be annoying to have to commute to a different place. But all you really need is a laptop, pens, post-its, paper and blu-tack to do this.

And being where they were meant that the people I was working with were comfortable. They had access to everything they normally use. It gave me a real sense of what it was like in their organisation.

2. Frame the problem meticulously

They say that 90% of reaching a solution is defining the right problem.

What this means for collaborative design is profound. If you spend a lot of time thinking about what the right problem is, a team of non-designers can start solving problems just as if they were interaction designers very quickly.

The project I worked on was about a system that relied on a lot of data - so we reverse engineered how all the data worked (together) and created a manual for how to interpret the data that was written in plain, simple English (rather than techno-maths). I then made a couple of fake datasets that showed some of the key challenges and interesting points in the data ecosystem. And finally created some worksheets that helped the team calculate what the data meant at different points in the customer journey.

All of this meant that we spent a couple of sessions doing actual maths homework. Looking at the datasets, calculating results and then telling stories about what had happened to these people over time. This work made everyone on the team, none of whom would profess to be that mathsy, completely internalise the structure of the data that was at the heart of the design problem.

Which meant that when it came to designing interfaces they were addressing all of the right issues from the start.

3. Avoid abstractions at all costs

Designers deal in abstractions. Pretty much everything we do is about dealing in abstraction. Normal people are far less comfortable with abstractions - this is why so many people struggle with being presented wireframes, which seem so natural to us.

The way around this is to make things concrete. Use real data. Use real photos. Use real text and real words. Create scenarios that make sense and are believable. If you spend the time doing this, the non-designers you work with will design amazing things.

Also: you should be using a graphic designer on these projects.

We are used to seeing schematics and imposing the future state on them in our mind. Normal people are not. If you work alongside a graphic designer from the start, non-designers will believe in the process much more easily. They will feel like their work has turned into magic. They will show it to colleagues, and their colleagues will get it.

Graphic designers take the logical work and make it emotionally accessible. This is invaluable. I was lucky to work with Luke Jones on this project and his work was amazing.

4. Force them to draw and draw and draw

Everyone can draw. Just like everyone can do maths. People have just been made to be scared of it by terrible teaching experiences in school (“you’re not good at art”).

Fuck that.

Make them sketch. Make it safe. Explain that they can’t get it wrong. Put them in small teams so responsibility is shared (but make sure they all draw). Give them the right tools (sharpies, coloured markers and good A3 paper will do). Introduce the idea of 6-up sketching early on and keep hammering it. Get them to present their work, even though they will hate it at first.

And then do it again. And again. And again and again and again. Trust me, by the third or fourth time they will have completely forgotten about their hangups and will be sketching interfaces like interaction designers. I am serious and I have the evidence to prove it.

5. Let them come up with the ideas

You are (probably) the design expert. But they will come up with all of the ideas you have (and more) if you frame the question right, give them time to experiment, and go through multiple open, friendly critique sessions with them.

This is a much better way to work.

Get them to sketch in small teams as above and then present back to the group. Stick the sketches on a wall. Ask questions constantly about why things are the way they are. Record things that come up on post it notes (partly for afterwards but MOSTLY to show that you are listening and taking it seriously).

Get everyone else to ask questions too, but enforce design critique rules. No design suggestions, only questions. No criticisms, only questions. Questions, questions, questions. (You will have to play the part of ‘translator’ initially - listening to a criticism or a design solution and reframing it as a question - but they will quickly learn). Make this critique really safe for people. Find elements in everyone’s work that are great ideas (they are always there) and talk about them.

You may have a vision in your head for how the designs should look. That’s fine. But if you do it right, they will come up with 90% of your vision, one way or another, themselves. It’s so much more powerful if they reach the conclusions themselves without being told what to do.

6. Explain scary design concepts

During the critique you will constantly come up with things that you have internalised as a designer but they have never seen before. Things like the problems of too much choice on one page. Or putting a feature on a page or in the navigation when it can be achieved in a different way.

Don’t be afraid to explain your understanding of what is going on. Take the time to go through the issues of choice and complexity. Outline how the same thing could be achieved in a different way.

They are all intelligent humans. If you take the time to talk it through with them, it might take multiple attempts (old ideas are hard to shake) but they’ll end up thinking like designers.

7. Make use of “yes, but we’re not doing that now”

People are amazing at finding edge cases. Seriously. If you’re in a team of people from your client’s organisation you will find they generate edge case after edge case after edge case.

And however good your non-designers become at design, they are not going to address all the edge cases. That is the kind of detailed work that really is better to leave to a designer on their own later on.

But you need to address the edge cases as they come up.

The way I did this is to clearly isolate the problem we are working on (this type of person, with this goal, with this information) and then put everything else in the “yes, but we’re not doing that now” bucket. This can be a large bucket. It’s a bucket that will get visited and revisited again and again throughout the process. But it’s critical to helping people forget the millions of details and focus on the core problem. We do this naturally as designers, others find it really hard, so make the contents of this bucket highly visible and highly talked about.

There are some edge cases that become so important that you need to address them by talking about how they can be dealt with. Try to keep this to a conversation rather than actual design work. Outline how that case might fit into the design (you might need to do some thinking about this away from the group) and then put the expanded edge case back in the bucket.

This is all assuming you have meticulously framed the problem you are working on. If you haven’t, you’re in real trouble.

8. Don’t be afraid to over-rule (but explain why)

Collaborative design is not about just letting your non-designers do all of the design themselves. You need to end up with something that works, and sometimes this will mean you need to step in and over-rule.

Now it’s much much better to not have to do this. Framing the problem meticulously gets you a long way to good solutions. Well-facilitated critique sessions and iterations with clear instructions ('think this time about restricting the number of choices on this page’) get you most of the rest of the way.

But sometimes you need to intervene and change things.

When you do this, flag it up and acknowledge that this is what you are doing (do NOT try and do it by stealth, or behind their backs). And most importantly, explain really clearly WHY you are doing the things you are doing (hint: if you can’t explain it clearly, maybe you shouldn’t be doing it). It might be that there’s not enough time to build the interaction before the test. It might be that it introduces a logical inconsistency that you know will compromise other aspects of the design. It might be that it’s against decades of good practice in human-computer interaction.

Whatever it is, explain why you are making the decision.

9. Design twin (or triplet) prototypes

There are always too many design ideas for a single prototype. In fact, like Leisa says, if you haven’t got multiple solutions to the problem in your pocket as a designer, you’re not really doing your job right.

So build at least two, preferably three, prototypes for the first round of user testing. Let people put their pet features in. Go deliberately wild with different approaches. Don’t be afraid to test things that bomb - people learn loads from seeing an idea they have held onto throughout the process come into contact with the user. In fact I would say you should preserve some of the most strongly held ideas until they see the light of day in testing (not least because often we are dead wrong about what will work and what won’t).

Make sure you explain that it’s not prototype A versus prototype B - but that the different prototypes are simply vehicles for testing different hypotheses. Like is it better to show all items, or just the most important items? Or does it work better to give the user control over setting goals or to set the goals for them?

But make sure that each prototype is internally consistent. Each concept needs to work in its own skin. This is tricky. And where your expertise really counts.

10. Build the prototypes away from the team

Make sure the whole team knows what is going into the prototype. Post-it out all the pages and flows you will be testing. Show them which of their design ideas from the sketching sessions are going into which areas of the prototypes (and which aren’t - but explain why).

But then go away and build the prototype yourself.

This work is not collaborative in the same way that generating ideas and critiquing approaches is. You need the time to push pixels around. And it’s also a chance to impose some of your expertise on the ideas from the sketching sessions, to iron out some of the kinks.

Then come back and show the prototypes to the team, pointing out where all their ideas are incorporated and how they have been implemented. Suddenly seeing their sketched ideas stitched up into a beautiful, working mini-version of a website will be one of the best moments of the whole process. Savour it.

11. Test at least three times

I would go so far as to say that this whole process won’t work if you don’t have at least three rounds of testing. You may JUST be able to get away with two, but you won’t have the freedom to let your team experiment with their own ideas in the first round of testing and you’ll end up doing so much over-ruling that you destroy the whole thing.

It’s also really really really really important that the whole team comes along to all of the tests. It’s the feedback loop of designing things and seeing how people react to them that turns non-designers into designers quicker than almost anything else (except maybe sketching).

On this project there was one non-designer in particular who seemed really interested in the testing work. So, in the spirit of collaboration, she stepped in and moderated some of the testing sessions in the final round herself. And she was amazing. Treat your team like designers and they end up acting like designers.

And don’t document the testing sessions formally. Get all of your team to watch, take notes and give them the opportunity to ask their own questions at the end of each session. Then the next day run a full debrief (multiple hours) where you put printouts of the prototype screens up on the wall and work through all the insights and observations. Make sure you discuss the reasons and possible solutions and bring your designer insight into these conversations too. This is a supercharged environment for learning to be a designer - seeing your own work interact with real users, and then talking about what you all saw together as a group.

End these debrief sessions with a high level plan of what you are going to do in the next session.

12. Force yourself to move too fast

The thing that always comes out of this process is that iteration is what makes the difference. Iteration in sketching sessions - do one, present, critique, do another, present, critique, do yet another, present, critique. And iteration in testing - design two protoypes, test, debrief, design a single prototype, test, debrief, redesign the prototype, test, debrief.

You need a tool to force yourself to iterate. That tool is the calendar. If you don’t force yourself, your time will slip and you’ll lose iterations.

Set user testing sessions at the start of the project at two week intervals. Any longer and you will be navel gazing. You WANT it to feel rushed, because when it feels rushed you only ever concentrate on the most important stuff. It might not FEEL right, but it definitely IS right. Too much time between iterations is a killer.

The same applies to sketching - cut people off when they are still asking for more time - they’ll get better and quicker as time goes on.

Establish a routine around these testing sessions, including:

• time to plan yourself (away from team)
• sketching sessions to design and critique things (collaborative)
• planning the prototype structure and flows  (collaborative)
• building prototype and discussion guide (away from team)
• testing session (collaborative)
• prototype debrief session (collaborative)

We did two week sprints and we had the non-designers for 2 days each week. That’s two days of sketching and planning week one, and two days of reviewing and testing and debriefing in week two. 

Final word of warning: don’t dive straight into sprints. You need time up front for discovery and bonding as a team and framing the questions. A couple of weeks at least. But make sure you set the dates for the testing at the start of the project as this will hold you to them.

A better way?

I thought this was going to be a quick post. I didn’t realise how much I had to say about it.

The thing is, working like this is talked about a lot, but rarely done in practice. Having actually done it myself, in the flesh, with all the glory and all the pain, I can safely say that it was an amazing experience. It’s how I want to do design as a consultant - at least for those early stages of helping an organisation completely rethink the future of its product.

We built a prototype that no one thought was remotely possible at the start. It tested well to start with, then better and better as we went on. It addressed some hideously complex problems but we found answers.

And while the users loved it, that’s nothing compared to the organisation. It’s been going viral - partly because it’s a clickable believable prototype, partly because it’s high fidelity and looks like the real thing, but mostly because the people that worked on it are pushing it on everyone they know or come across in their own organisation.

I’ve written before (a lot!) about how the biggest problem with user experience consultancy is that so much of the time our work doesn’t get built, mostly because the organisation doesn’t 'own’ it or 'know’ what to do with it.

This is the opposite. It ended with something good and tangible. I’ve left a team of people who have internalised all sorts of critical design concepts. The organisation is excited. I had a great time doing it.

But I think the thing that I learned most was - if you trust people and take the time to give them the tools they need to design, the output will be miles better than if you had done it alone. I started thinking this was about buy in, but I ended thinking this is simply about good design.

Go, collaborate…