Participatory Design for Cryptoeconomic Systems

Or “How to include stakeholders of cryptoeconomic systems in the design process, from concept to delivery.”

I currently have two pillars in my craft as a design strategist at ConsenSys:

  1. Employing game design theory and practice in cryptoeconomic systems.
  2. Fomenting participatory design as one of our team’s core practices.

You can read more about the first pillar in my article about our experiments in levels and flow (as part of an ongoing series I just started). However, in this particular article I’m going to introduce my forays into participatory design at ConsenSys.

What is participatory design?

Participatory design is characterized by an opening of the design process to non-designers. It is an active creation of spaces, moments, and methods that fosters and empowers users during the design process. In other words, the users get a say in what is being created by and for them.

This is by no means a new idea, and in fact started during the 1960s in Scandinavia, under the name of “cooperative design.”

In an article I love on the history of design thinking (a concept that I might write about in another article), Jo Szczepanska describes the rise of cooperative design quite nicely:

Instead of being closed off and selective, here designers played the role of facilitators or guides, with everyone from experts to workers and inhabitants co-designing products and services they would want to use.
Many highly innovative projects […] were developed to help workers, unions, workplaces and even government departments tackle the changing workplace environment as a reaction to the introduction of new technologies.

Years later, cooperative design came to America, and for some obscure reasons, got a new name: participatory design.

But how does participatory design have anything to do with cryptoeconomics?

What does participatory design look like in cryptoeconomic system design?

I’ve been introducing participatory design in all the different concentric circles of the production of cryptoeconomic systems. My objective is to break down the circumferences of each circle as much as possible.

I’ve so far deployed participatory design in cryptoeconomic systems in four ways: developer workshops, facilitation tools and frameworks, in-person simulations with final users, and stakeholder workshops. You can expect an article with the specifics of each one very, very, soon, but for now, let’s look at a summary of each one.

Developer workshops

These are multi-day sessions where whole development teams work on cryptoeconomic system design, including developers, designers, product owners, and whomever else you think is important in the strategic development of your system.

A dev workshop in action. No, that is not my arm.

I’m sure this doesn’t sound like anything new to you if you’re a designer in regular apps (as opposed to dApps — decentralized apps), but this is actually quite novel in the crypto world. The design of these vast systems of token incentives has usually been owned by developers and economists, who sit down together for days, write white papers, and have long verbal discussions colored with algebraic formulas transforming the words written into math.

As a designer, I’ve approached workshops differently, inviting whole teams to the table, creating visual architectures that anyone can speak to, and live-roleplaying incentive scenarios.

A visual architecture of a cryptosystem that a team built together during a dev workshop.

Of course, I’ve already stumbled upon some limitations of believing participatory design is just a matter of being at the table: it’s also necessary to give everyone ways to understand what’s happening in a straightforward way. This has lead me to the creation of new facilitation tools and frameworks.

Facilitation tools and frameworks

In order to get all these different areas of expertise working together on a topic that is usually relegated to text and math, I’ve had to come up with variations on design tools that I already know (like systems maps and customer journey maps) and completely new tools altogether.

For the systems maps, I’ve been using a mixture of systems maps that are broken down by the functional stage a system would be developed in. For example, for Delphi, a product we are developing, we created systems maps with the Bounties team for each of the stages the code would need to account for. I’ve since used this approach in many other team sessions.

A systems map of a particular stage in Delphi.

I then adapted this into a huge flow chart divided by each of the stages, and showed it like you would show stages of interaction in a customer journey map. This has proved INCREDIBLY helpful for later translating cryptoeconomic system requirements into wireframes.

A flow chart/customer journey hybrid tool.

Finally, I’ve devised a Cryptoeconomic Divination Deck, a card game for creating cryptoeconomic systems from scratch. This one can be used for ideating, or for challenging yourself as a designer of systems. Both are very enjoyable, and the deck is right now on its third version.

Some of the “categories” of the deck, illustrated by Dámhín McKeown.
Detail of one of the cards on the other side. There are several cards per category. Each category has a place in a “spread”, just like in the tarot.

In-person simulations with final users

A third approach to participatory design in cryptosystems has been the creation of “games” or simulations to be played by actual final users WHILE the design process is at its beginning stages. I’m really excited about this one and we had our first (and successful!) test this last August 4th.

Players (testers) paying attention to me at the beginning of the session.
Some silent reading at the beginning. Things got way more intense later, when the game actually commenced. I’m working on a bigger post about this with more content.

The simulation sessions rethink a cryptoeconomic system as an analogue game that can be played by up to 10 players. Development teams learn, in person, what strategies humans take to “win” the game, what is hard for them to understand, and how communities and politics play a part in the system. They even get excited for next iterations and inspired to embrace constant change as part of the development process.

Stakeholder workshops

I’m really interested in stakeholders who are important to the success of a cryptosystem participating in the design process. As you can see, I’m separating “users” from “stakeholders.” These stakeholders can be, for example, government regulators of crypto assets that could make-or-break your system, or even potential competitors of it. These are the people that could make your system’s token go up or down at the drop of a hat.

I am now working on the creation of one such test for an upcoming project, so I haven’t got much to show, but I believe this is another part of production in which participatory design can be employed as a way to gain evangelists for systems and reducing friction in deployment.

In summary: why does participatory design matter in cryptoeconomic systems?

Firstly, because it makes sense to apply decentralizing design (a.k.a. participatory design) in a decentralized organization that has the objective to bringing about a decentralized society, like ConsenSys does.

The second big reason for using this type of design is that past experience at the Cryptosystem Productization Lab, the spoke (venture) I’m a part of inside ConsenSys, has convinced us of the importance of involving stakeholders of a cryptosystem quickly and purposefully in its design.

Ultimately, when you DON’T include stakeholders early in the design process of your cryptosystem, you…

  • Determine the “health” of your system based on assumptions and expertise that may not actually apply to your stakeholders reality.
  • Don’t gain an understanding of their purposes and behaviors until you’ve finished shipping a large amount of code that already took you months of development.
  • Even if you have talked in passing to stakeholders during your development process, it might turn out that their behavior in the system is quite different than your initial theoretical research.
  • You have a higher resistance from your team and your stakeholders to changes in your design.

In contrast, if you DO include stakeholders early, you…

  • Go beyond talking to users and stakeholders, and instead actively involve them in your design sessions.
  • Test your assumptions more quickly and cheaply every time a stakeholder is designing side-by-side with you.
  • Convince important stakeholders of the value of your cryptoeconomic system, since they’ve been designing it too.
  • Get your team used to uncertainty and changing development requirements.
  • Become more user-centered.
  • Notice the differences between your theory and assumptions and their real-life applications.

So go ahead, and start opening your design process to others! The crypto world (and your team) will thank you for it.