A Toolkit by Any Other Name

What is in a name? Would a toolkit by any other name seem as useful? In this post, I delve into what comprises innovation “toolkits”—and make a stab at classifying them. What is the difference between a playbook and a manual? This taxonomy development is a step in building our resource to help public sector innovators navigate, sequence, and tweak tools and methods to facilitate their innovation journeys.

In one of my previous blog posts I declared that we have reached “peak toolkit” and wrote about the many ways that innovation toolkits can be both helpful as well as dangerous in the public sector. So now what? Well, as a first step, let us play with a common language.

Let’s be clear: a common toolkit vocabulary

The first step is being clear about the common vocabulary we use to describe the “things” we use when we innovate. Building a language around the contexts is much trickier and will come later.  Public sector innovation work is by nature emergent and evolving, so being overly granular and specific in our language means being overly prescriptive—an innovation killer. So, our common vocabulary needs flexibility, enabling some “play,” and needs to emerge in part from the innovation community. What minimum consensus on language do we need in order to enable the proliferation and adaptation of methods and tools?

We will not pretend to know all of the elements of every context or situation facing public sector innovators and their journeys; our goal is transferability not replicability of tools and methods. We are curious and interested in uncovering patterns that link methods and tools with contexts. We think we can build a meta-tool that helps us learn these insights.

The Toolkit Taxonomy

First, we will clarify what we mean by “toolkit” and attempt to classify what exists already. This is an initial stab at the language so please do add your thoughts.  Here at the OECD, toolkits typically serve a specific purpose: implementation guidance for a set of official policy recommendations. This differs from what many in the public and private innovation community consider a toolkit, so the language clarification and translation effort will happen in my own backyard too.

Some toolkits can consist of “guidance” or an explanation of a methodology or types of methods to consider deploying, such as a particular way of doing digital service design (i.e. UK Government Service Design Manual) while another toolkit can contain a set of standalone “tools,” such as printable templates intended for some kind of interaction (i.e. journey map templates, the Business Model Canvas, etc). The first explains why one might consider using a particular methodology. The second is a suggestion of how to do something. All tools have an explicit or implicit method baked in. The “guidance” does not suggest any actions whereas the “tool” does not provide reasoning for the suggested action. While there is nothing wrong with either, calling them both “toolkit” can be confusing and inaccessible. Adding to the confusion, some toolkits in the compendium contain both guidance, tools, and everything in between.

The following language is a draft taxonomy of toolkits. At a minimum, it gives us a place to start for discussion.

What is inside each of the toolkits?

The toolkits in the growing compendium include different bits and pieces of the table above—as well as having different “features” like an associated curriculum, social network, or case studies. For example, the United Nations Development Programme Project Cycle Hacker’s Kit contains everything from an overarching methodology to a facilitator’s guide, whereas MASS LBP’s Reference Panel Toolkit is a standalone playbook. There is nothing better or worse about each of these. Being all-inclusive of toolkit pieces facilitates reuse by another person (assuming the context is similar).  Standalone pieces are easier for another person to piece together in a sequence and deploy quickly as a missing piece of an ongoing process. There are pitfalls for each approach, of course, and these have a lot to do with contextual factors, like the process knowledge of the user, the types of problems being tackled, and the existing organisational practices and culture.

Further, some toolkits are more or less abstract or granular. For instance, the Innovation Growth Lab’s Experimentation Toolkit contains guidance—mostly why it is important and ways to approach it—but not much in the way of tactical resources for deployment. On the other hand, the Danish Design Centre’s Inclusion Toolkit contains templates, step-by-step instructions, and research synthesis worksheets, but not much reference to the overarching methodology. Again, neither of these is better or worse than the other, but they both serve very different roles yet are both called toolkits.

Why does this matter?

This all might seem a bit picky, but language really does matter. This is a foundational element in developing our future resource. In addition to some upcoming testing with users, we want to hear your thoughts about this post. We will use the final toolkit taxonomy to inform the organisation of our toolkit compendium. It will also inform the data model of our meta-toolkit resource, so we want to make sure we get this right. What would you add, remove, or tweak? Add a comment below or make edits or comments in this Google doc.

We are developing a resource for public sector innovators

This work around building a common language will feed into the development of the meta-toolkit resource, which includes several components:

• The toolkit compendium: growing body of toolkit content. If we are missing one, feel free to add it.
• The toolkit taxonomy: the vocabulary we will use to classify the innovation toolkits
• The context typology: the loosely characterised contextual factors
• The meta-toolkit: patterns of interaction between content (the toolkits) and contextual factors

A passionate and brilliant team of informal advisors—interaction designers, innovation methodology gurus, academics exploring innovation and design, practitioners, and consultants—is helping me think through the development of this meta-toolkit resource. If you would like to be more involved with this team, please reach out.

Some other ways to connect with OPSI

Interested in public sector innovation? Feel free to get in touch with us at opsi@oecd.org or @OPSIgov. We also encourage you to join our OPSI LinkedIn community to exchange ideas with fellow innovators and our newsletter to receive innovation updates.