Originally published on Matters by Designit.
In the first article of this series, we saw how your design team, no matter how talented, won’t ever be big enough on its own to tackle everything needed by the organization, from a human-centered design perspective.
Time for another movie reference. I’m sure you’ll be familiar with the classic Hollywood trope whereby the hero and their lieutenants train the people they are bravely defending, in effect creating an instant army. Think of Robin Hood: Prince of Thieves, The Last Samurai and The Three Amigos. The small band of highly skilled experts are equipping a larger group of novices with tools and techniques, to help them take on the looming threat of a superior enemy.
Not only does this make for great on-screen action, but it teaches us a valuable lesson about scaling our design capability.
In the case of human-centered design (HCD), the enemy is the problem we are trying to solve for customers/users/employees, the skilled hero is the design team (I’m not at all biased!) and the large group being trained are your colleagues from across your organization. These people can be formed into a community of human-centered designers, a much larger force than the design team could ever be on their own. Not as highly skilled, yet able to take the tools and methods you teach them and take on a much wider scope than you ever could.
The key to solving these problems is to build an HCD community, which extends the reach and capacity of the design team and provides an effective mechanism for collaboration and capability evolution.
This community will allow people across the organization to:
- See the tools and practices that have been created, to be educated on them and discuss how to use them. Without this they are unlikely to adopt them.
- Share and discuss, which leads to more teams contributing to the collective knowledge base and practice. This will start to breakdown silos and the redundant/duplicate work being done in each.
- Provide feedback based on real-world use and diverse input, which allows you to iterate. The artifacts we have created are not the end of the journey, but the start. Iteration leads to improvement, better meeting the needs of teams, which leads to them better meeting the needs of customers.
- Meet their local needs. Through this collaboration, you will be able to accommodate the needs of different teams working at different levels of granularity, which may require different tools or views of the customer. The community will work together to figure out how these things fit together, to build an ecosystem of tools rather than competing or contradicting.
The community should be the mechanism for communication but also governance and decision making (working collaboratively, but with leadership).
There is no silver bullet solution to most of the pain points described earlier. The way to solve them is to get together and talk effectively, and work them out as a community.
A new way of working
This concept may come as a bit of a shock to some designers; give up control of design to non-designers? Well, kind of. Depends on how you define ‘design’!
What we’re really talking about here is not design but problem solving. The tangible craft of design and ‘designing’ will still be the remit of designers. You may play a key role in the community, but the point of building the community is to multiply the reach and scale of how design is applied; to firstly identify unmet needs, and then to meet them.
To others, this won’t be a new concept. If your organization has adopted agile ways of working, for example, this collaboration across disciplines and branches of the org chart is pretty standard. The idea might go by other names, such as Community of Practice (CoP), guild, chapter, etc., however the core principles remain the same.
In the third and final part of this series, we’ll discuss how to create such a community, including practical tips and rules of thumb.