Using Collaborative design with clients

How do you understand what users want? Simple. Work with them.

Collaborative design sessions with users are great. They require quite a bit of planning and facilitation – and of course like any research activity only really work if you’ve got the right participants in the room – but as a user research method they get immediate results. No intensive analysis or lengthy report writing required – just easily sharable and visible user outputs that can provide great design input early. A well-designed session can elicit user language, goals, task flows, information priorities and even great ideas and concepts that have been applied from other domains or applications.

All in all, collaborative design is quite a difficult user research method to beat in terms of understanding how users expect and want a system to work.

But recently I’ve have found that collaborative design can also be used earlier in the process as a way to really understand what clients actually want from a system. Yes, they may have handed over business processes, requirements documents and even use cases – but aside from all of the formal documentation, I have found that they often have very strong ideas (and opinions) for how the system could, and even should, work.

I hear every designer throwing their hands up in horror at the idea of clients creating designs. Isn’t this why we have user-centered design to get away from this kind of madness? Our goal is to design with users, not clients, and use our user research insights to create great experiences.

This is all true but it doesn’t mean that we should ignore client ideas. The danger of not providing a forum for clients to express and visualize their concepts early on is that these ideas have a habit of lying dormant until the first design review and then springing into life to de-rail the whole process. As the designer carefully explains the initial designs based on the user research findings, the first indication that a sleeping preconceived idea exists is when the client’s brow starts to furrow, their pen starts to move, and after the designer pauses for feedback, the client sits back, holding up a piece of paper and says “Yes I understand, but I was thinking it should be more like this”.

The ideal situation of course is to adopt the Design Thinking process where business people come together with researchers, designers and the technical team, and before anyone gets bogged down with requirements or user stories, they work together to rapidly ideate and develop different concepts to solve a user problem. However, sadly, most projects are not run this way. The first time a designer gets to even think about what the problem is that needs to be solved is when they are handed the requirements documentation and asked how long it will take to create the wireframes and visual designs that will meet the requirements.

This is where a collaborative design approach with clients can help.

With a requirements-led project, running collaborative design sessions with clients early on can solve 2 problems; it can uncover hidden or assumed requirements and it can engage them with the design process. It can also help team working and communications.

For some clients, a collaborative design exercise might be the first time they have ever worked with designers and the first time they have been proactively asked how they think the interface should work.  This is why the design of the workshop is so important.

To head off the inevitable question, “Why are you asking us to create the designs, surely that’s your job”, it is always a good idea to start the session with a very brief overview of the design process and why understanding mental models is so important to the process. After this, we can apply collaborative design best practice to the session.

  1. Put the participants at ease with drawing – its about their ideas, not their drawing skills
  2. Emphasize the importance of stepping into the users shoes. Put people in teams that map to a user profile, and make it clear who the profile is.
  3. Plan the workshop to cover all the key areas and keep participants busy with timed activities
  4. Allow plenty of time for individuals to explain their ideas and for other team members to provide feedback
  5. If you see a team member who is creating some alternative designs to the rest of the team, ensure they have the materials to develop their ideas and time to speak about them
  6. Always try and introduce some competition between the teams to maintain the momentum and increase the enjoyment

Lastly the session needs to be interactive and enjoyable. This is perhaps the most important workshop requirement.

And how does this help the designer?

First, all of the main pre-conceived ideas and concepts will be out in the open. This will mean they can be developed, tested, accepted or dismissed and there won’t be any nasty surprises later on.

Secondly, watching and listening to the conversations while the designs are being created can tell you a lot about why a requirement exists and what the real problems are that the business is trying to solve. How the client chooses to solve the problem in their designs can also reveal what they believe is the priority of tasks and information and why.  These insights can help designers develop a better experience and help researcher to develop plans to test client assumptions.

Lastly, engaging the client in the design process will help make the eventual design sign-off go more smoothly. By including clients in the design of the solution and developing and testing their ideas with users will help them understand why some of the ideas were accepted and why some were rejected. It is also important to openly acknowledge the client contribution to the eventual designs. Designers should always be ‘ego-less’ when it comes to creating designs, and good ideas can come from anywhere, including clients.

Actively including clients in the design process using collaborative design techniques can really make the whole design process go more smoothly.

Some cynical people might call this careful stakeholder management, but I actually think that it is just good design practice.