Co-design

Introduction

The various collaborative finance tools that Mutual Credit Services uses have – with the exception of the Credit Commons Protocol – long histories. Multilateral obligation set-off and shared ledgers have been in routine use at the heart of the corporate and financial sectors for centuries, whilst recognisably modern mutual credit systems have come into and out of existence on the economic margins since the 19th century. In technical terms these systems are relatively simple, and there is an accessible literature on their economic benefits. Given this, the question for would-be implementers becomes: why are they not mainstream already?

Mutual credit networks have always faced a dilemma of remaining marginal or becoming centralised, and the Credit Commons Protocol is intended to overcome this limitation. In the case of multilateral obligation set-off, developing the capacity to collect and process the required data outside of an institutional context has only become feasible with the advent of ubiquitous digital tech. However, technological constraints are only part of the problem. Although we explore some other big-picture factors in our blog post ‘Complementary’ Economics Won’t Do It, the focus of this piece is on how, in practical terms, MCS is bringing collaborative finance tools to the mainstream.

This starts with a recognition that there are no one-size-fits-all approaches. Every economy, and every subset of every economy, is unique, and – as with all complex adaptive systems – the law of unintended consequences applies. This makes any approach based on universalism dangerous. What is called for is an application of technical expertise to each context on its own terms. This will necessarily involve (at least):

Careful observation and respect for what already is (and the adaptations embodied therein), as well as what could be;
Identification of the leverage point(s) that can lead to the deepest systemic change with a minimum of negative unintended consequences;
An appreciation of scale, scope, and recursion in order to draw appropriate and malleable boundaries around problems and make them tractable;
A variety of modes of operation and engagement;
Constant reassessment of conditions and processes as they unfold, paying particular attention to feedback loops.

MCS refers to this process as ‘co-design’, and it is at the core of our way of working. In our experience, it is much more effective than designing systems in a vacuum and then attempting to persuade others to use them.

However, there is a countervailing requirement – if our work is to have any substantial impact beyond a few isolated corners, then what we design must be applicable elsewhere, ideally without prior investment in deep design capacity by those who wish to use it. Each of our models and projects is an attempt to develop a pattern, embodied as a piece of collaborative finance infrastructure, that resolves the tension between customisation and replicability; specific enough to be effective in, and recognisably ‘of’ the originating context, yet general and flexible enough to be adapted for a broad range of circumstances.

Co-design in Brief

Purpose

The purpose of co-design is to produce practical, successful, and appropriate outcomes – implementations of proposals which will be viable. Such outcomes must connect with the reality of the place – and thus become part of the life of the place, supported by the daily actions of the people there (including those not formally involved in the co-design process). Note that ‘place’ can be any sort of context: a neighbourhood, an organisation, a community of interest – even something like a supply chain. To achieve this, designs should be developed:

With a strong feeling of local ownership;
Through excellent understanding and analysis of the whole context;
On the basis of good theory and sound technique;
Through processes which allow reaction to changing conditions – including the changes which the design itself will bring about.

Collaboration

Co-design is a collaboration between people/groups with different expertise. Many kinds of expertise are possible, but the two basic types are:

Local experts – the people who know the context. These people know, through lived experience, what their ‘place’ is like – the people, their cultures, the conditions, the neighbours. They provide the grounding and the understanding which sets the basis for the work. They must have consciously chosen to work with the technical experts – to positively want to join in with the process. For the local experts, the experience should be interesting and creative, they should feel heard, included, and empowered.

Technical experts – whose theoretical understanding should ensure well-founded outcomes when applying domain-specific knowledge to a new situation. These people have experience and understanding of the techniques, tools, and materials necessary to build and service what is designed. They take responsibility for facilitating the process – not power or control, but responsibility. Their technical expertise and understanding is in service of a successful outcome – creatively enabling rather than constraining. For this to be possible, technical experts must also take responsibility for good communications – so that all are heard and can participate.

Process

Co-design starts with the local experts, and operates through three basic modes – these do follow a sequence, but in practice there is much looping back as new ideas, perspectives, proposals, and realities are arrived at in the course of the work. When the process is well-embedded, distinctions between the modes will begin to blur. As long as documentation and other recording is maintained to an effective standard, this blurring is to be welcomed.

Growing Shared Understanding – so that all can contribute

To begin with, the participants need to learn from each other – often this learning is between members of groups, as well as from one group to another – local experts will have different experiences and understandings of their context and needs, and technical experts may likewise have different knowledge and approaches.

Work is needed to develop shared language about the work in hand – so that increasingly sophisticated and specific ideas can be effectively communicated.

In co-design the technical experts act as facilitators and learners first, working with the local experts to build a shared understanding of the ‘design space’.
This means producing one or more types of ‘map’ of what already exists, what is wanted, what the constraints are, what impacts need to be considered – everything which needs to be taken into account in making a positive change.
These ‘maps’ will:
- - Mostly not be actual maps! All sorts of methods might be used, of which the most important will always be what is inside the participants’ heads – their own mental maps. But documents will always be necessary, too – firstly, for checking that there is common understanding, but also for communication to others.
  - At first be ‘factual’ in character – recording and relating information about what ‘is’ (and what ‘is not’). Empirical research and data sources may be required.
  - Then become more ‘characterising’ – developing views about the qualities, associations, and possibilities of aspects of the context – what things are ‘like’, and what they ‘could be like’. All participants will need to engage more personally for this to work well – the technical experts developing a feeling for the context, and the local experts developing their ability to imagine changes to things they know well.
  - Then become more ‘analytical’ – looking at reasons ‘why’ these characteristics are evident – as well as ‘why not’, and what it might take for them to ‘become so’.

Developing Proposals – the work of design

Creative work should start on the basis of even a small amount of understanding. Complete understanding is never possible. Creative thinking on the basis of some understanding will raise new questions and produce new understanding. Be prepared to ‘loop back’ to the ‘Shared Understanding’ mode often throughout the process.

In co-design, every participant is a creative contributor. The character and style of creative input may vary between participants coming from different starting points – for instance, open questions are as valid a part of the process as practical proposals.
It is important that experts (whether local or technical) do not find themselves acting as ‘gatekeepers’ – shutting down ideas before they have had a chance, or become isolated – expected to deliver large parts of the project without general engagement.
In practice, this means that design work begins with open-ended conversation.
Early design work, in particular, should indeed be seen as mostly a way to identify gaps in the shared understanding of the participants, suggesting a loop-back to that mode, rather than about making firm decisions.
It is likely that many desired outcomes and early proposals will appear to be in direct conflict – things like the list of needs breaking the available budget, or a desired feature clashing with regulation. This is a Good Thing – the work of design is largely about finding creative ways to solve several apparently conflicting requirements in one ‘move’. Solving each sub-problem separately and then bolting all the ‘solutions’ together in a row rarely works. It is best to find these conflicts early, as they will indicate where effort should be concentrated.
- - At the outset of the work, apparently impossible problems are normal – and important to bring up, and be clear about. This is to be expected, and resolutions to such conflicts should not be immediately attempted. There will be many other aspects of the work that have not even been considered yet – it is fine to leave the mess as it is, and look at some other issue. Early on, what matters is to flush out as many of these conflicts, particularly the major ones, and seek to understand them. Not discovering them until later on may be expensive!
  - Such conflicts will crop up all the way through. If the process is going well, then the scope of such conflicts should get smaller as it proceeds. If conflicts of wide scope keep cropping up, then more (and often more detailed) work is needed in the building shared understanding mode.
As the level of understanding, and the level of detail of the proposals, increases, then it will become clear:
- - Which conflicts cannot be resolved – and will thus require new Shared Understanding effort to revise the aims of the work. Unresolved conflicts are a marker for low quality outcomes and should not be accepted. It is better to be clear that some identified issues cannot be resolved through the work (and thus need to be set outside the scope of the project – often a major undertaking) than to attempt to smooth the problems over.
  - Which conflicts can be resolved by design proposals – these resolutions, even if they seem unusual, are the real purpose of design – for it is the degree to which conflicts are effectively resolved which governs the viability and appropriateness of the outcome.
Design work is much, much cheaper than building a project that is not viable:
- - If this is not true in the context under consideration, then design work shouldn’t be done at the current level – if building is cheaper, then go for ‘trial and error’ by implementing the best available idea, seeing how to improve it, and then rebuilding, repeating until it works.
  - Generally, being prepared to ‘rip it up and start again’ many times throughout the course of the work is necessary. Don’t actually rip it up! Rather, each attempt should be carefully preserved and documented, sharing the reasons for it not working. There will be learning there for the future.
Instead of getting too detailed, too soon, it is better to look for aspects of the proposals which can be implemented early – often in mocked-up form, so that they can be tested cheaply. Again, the results from tests may well be negative. This is not failure, but avoidance of wasted resources. Loop back and incorporate the learning.

Building Responsively – refining as we go

Implementation should start on the basis of the first proposal that seems reliable; ‘safe to try, good enough for now’. In MCS’ work, this usually takes the form of trials with the intended users of one of our platforms. In keeping with the rest of this piece, the outline below is somewhat philosophical, whilst our page on grassroots trials gives a more concrete sense of the process.

In co-design, the building process is integrated with the design process.
This is to allow for the design to respond to reality – which is always different (messier and more complicated) than any design space map. If the process doesn’t allow for such responses, the end result may be complete, but non-viable in some respects.
If the building process allows for refinement to be made – particularly in the matter of smaller-scope elements – then there is a chance to resolve newly discovered conflicts as it proceeds.
In particular, it is import to avoid the situation where the local experts’ involvement in development is considered to be finished once the implementation starts, with this group expected to step back and watch it get built, before being presented with the end-result. If this happens, it is easy for pragmatic responses to issues arising during implementation to damage the viability of the project, wasting much of the effort of design, and undermining the willingness of the local experts to engage with further design work.
The act – and the fact – of building, changes reality. Of course it does – that’s why we do it! But whilst it’s still just a design, the work doesn’t change anything much, and so it doesn’t provoke any real change – the best that can be done is try to imagine a response. Unfortunately, the designers are bound to imagine the response that they intended (otherwise they’d have designed it differently!).
Once the work becomes real in the world, people outside the design team will look at it and interact with it. People – both locals and outsiders with no interest in the aims of the team – may respond to it, often surprising everyone. These interactions matter. They are real. These are the people who are engaging with the outcome of the work. How they respond will determine its degree of success.
At the outset, it was noted that understanding can never be complete. These reactions add to the team’s understanding – and will quite likely drive further loop-back work.
All of which makes it well worth the slight extra effort to design an implementation process which proceeds stepwise – each stage making a change that is worth assessing the response to.
Where possible, detailed design work or decisions can even be left ‘sketchy’ until the point is reached where they can be developed in the context of the reality which has already been built. This gives a chance to design a way out of things that look like mistakes in light of how people respond to them for real.
Key to this ‘refining as you go’ process is a particular approach to resource management. Instead of costing everything in detail, what is needed is budget allocations for each stage of the work, and a significant ‘contingency’ amount to allow for change. Ideally, some of this contingency is not even spent during the build process, but is retained for responses to the work which come up once it has been in use for a while. The world is littered with projects that, once ‘finished’, have no access to resources to fix small problems when they arise; often, these problems-in-use can undermine otherwise high quality work.
Enabling this process requires attention from the outset – the implementation process, budget, and often contract arrangements are part of the design space from the outset – and subject to all the same processes of shared understanding, design development, and implementation.