This is a rough v0.5 version of a Collaborative Design Sessions method template. Many thanks to Arthur Attwell for working with me to improve this.
Collaborative Design Sessions are one or (more likely) a series of events as part of the Collaborative Product Development cycle, that help an organisation design a solution. In many cases, this solution is a change of behaviours (cultural change) supported by technology (an open source product).
Collaborative Product Design is a new branch on the Systems Development Life Cycle tree. SDLC methods include Spiral, Joint Application Design, Xtreme Programming, SCRUM and others (including those which conform to Agile Manifesto values). Collaborative Product Development is such a method, posited within the free software / open source sector where the cultural rules are quite different to environments where teams are employed to work within a more formal business or corporate structure.
The Sessions
These Collaborative Design Sessions are facilitated-processes and work better as physical gatherings with a facilitator and a wide range of stakeholders. These stakeholders may be from a single organisation, or from a number of organisations with similar needs. Sessions can be 2 hours (no less) or more, in some circumstances they may take several days. Commonly a session is a morning or afternoon (4 hours or so). It is sometimes necessary to break these up over an extended period of time. Each case is different and no ‘one size fits all’ strategy is possible.
The Product
It is assumed that an open source product is already in mind when going through this process and that this product can be adapted to meet the needs of the organisation. It is also assumed that the introduction of any product to an organisation is only in part a technical question, the larger issue is generally cultural.
Facilitation
Facilitation is a key ingredient for Collaborative Design Sessions, no group should attempt this process without a facilitator. Some important things to get right going into the event include:
- The facilitator is not a Benevolent Dictator
The facilitator here is not the Benevolent Dictator For Life, cat herder, or Community Manager (or other models) commonly found in open source; rather the model is closer to an unconference-style facilitator. Don’t confuse these very different approaches! - Organisational neutrality
The facilitator should not be part of the organisation that is in need of the solution – this frees the facilitator from internal politics and dynamics and enables them to read the group clearly and interact freely. - Domain Knowledge is not necessary but useful
A facilitator may be entirely neutral or, in the case where an organisation is working already with an open source product in mind, be part of the open source product development team or community. The facilitator of these sessions may or may not have domain or product knowledge. If there is no domain knowledge, it is recommended product and domain experts be present. This helps a great deal to keep the process anchored to ‘product reality’. - Tools
You may wish to have tools such as post-its etc, but generally a large whiteboard and markers (or large pieces of paper) will take care of it. Most shared objects are documentation but it may be necessary at times to use other facilitation tools and tricks to move a group process along.
Note: this document assumes some experience in facilitation. This document is not intended to train facilitators (indeed, experience is the only way to learn facilitation), rather it is intended as a suggested framework-guide for those wishing to try this process.
Here are some things to remember when facilitating Collaborative Design Sessions:
- Build trust before products
As a facilitator, your job is to build trust in you, the process, the group, and the outcomes. Each time you make a move that diminishes trust you are taking away from the process and reducing the likelihood of success. For this reason, you must put building trust, working with what people say and towards what people want, ahead of building ‘your’ product. Trust that the product and a commitment to it, will emerge from this process, and it will be better for it. - Change is cultural, not technical
Too often technology is proposed as the mechanism for change. Technology does not create change. People create change, with the assistance of technology. - Even the best solutions have problems
Own that even the best solutions, including the one you are representing, will have problems. There is no perfect solution, and if there is then time will inevitably make it imperfect. - Technology is not a magic wand
Make sure the group is not seeing technology as the magic wand. Change is not magically ‘embedded’ in the technology. Improvement, optimisation, or radical reworking of workflows requires people to do things differently. - Leave your know-it-all at the door
If you are part of a product team then you may be expected to be somewhat of a domain and / or product expert. Leaving that at the door is not possible of course, but you should be careful that you do not use this knowledge as heavy handed doctrine. Instead, it should manifest itself in signposts, salient points, and inspiring examples at the right moments. These points should add to the conversation not override it. Don’t over play your product knowledge and vision, you will lose people if you do. - Cultural drives change, technology assists
The group must be committed to changing what they do. The ‘what they do’ should not be posited as a function of technology, it is their behaviour that will always need to change regardless of whether there is a technology change. Behavioural and cultural change is a necessity, not something that ‘might happen’. The group needs to recognise this and be committed to changing how they work. - Give up your solution before you enter the room
If you are part of a product team it is a mistake to enter into a Collaborative Design Session and advocate or direct the group towards your solution. If the group chooses a technology or path you do not have a stakeholding in, then that is fine. The point is, however, that the likelihood is that they will choose ‘your’ technology, otherwise, you would not be asked to be in the same room with them. However, if you facilitate the process and drive them to your solution you will be reading the group wrong and they will feel coerced. You must free yourself from this constraint and be prepared to propose, advocate, or accept a solution that is not ‘yours’ or that you did not have in mind when you entered the room. This will not only free you up to drive people to the solution they want, but it will earn you trust. When they do they choose your solution, and chances are they will, then they will trust it because they trust you and trust the process. If they don’t choose it, they will trust you and come back another time when they are ready for what you have to offer and, additionally, they will advocate your skills to others. - Focus on problems and solutions not technology
As mentioned above, cultural change is necessary and many behavioural changes can occur that will produce positive results without the need for a technology change. It is important that you and the group can identify these issues and bring them into a focused discussion. For this reason, it is very important that the initial sessions focus on what the problems are, irrespective of whether they are born of technology or workplace process. If you can accomplish this then the group may very well propose changes that have nothing to do with technology. This is a very good outcome, as the end goal is to improve how things are done. If technology change is not always (or ever) part of the solution that is also success for the process. - Involve a broad set of stakeholders
The sessions should involve as diverse a range of stakeholders as possible. This will not only improve the product but increase stakeholder ownership of the solution and that in turn will help the organisation implement it. If people feel they own the solution, they will work towards seeing it implemented. - Move one step at a time
Move through each step slowly. The time it takes to move through a step is the time it takes to move through a step. There is no sense in hurrying the process, this will not lead to better results or faster agreements. It will in all likelihood move towards shallow agreements that don’t stick and ill-thought out solutions that don’t properly address the problem. The time it takes to move through a step will also give you a good indication of the time needed for the steps yet to come. Be prepared to re-scale your timelines at any time and to return to earlier unresolved issues if need be. - Ask many questions, get clarifying answers, ask dumb questions, the dumber the better
Ask many many questions. Try not to make them leading (note: sometimes leading questions are necessary for points of clarification or illustrating an issue). Keep asking questions until you get clear simple answers. Breakdown compound answers where necessary into fragments and drill down until you have the clarity you need. Dumb questions are often the most valuable. Asking a dumb question often unpacks important issues or reveals hidden and unchallenged assumptions. It is very surprising how fundamental some of these assumptions can be, so be brave on this point. If necessary feign humbleness and stupidity for asking an obvious question. - Own stupid problems, laugh about them!
Every workplace culture knows they do some stupid things. When you find these, call them out, and, if possible, laugh about them. Providing a context where people can bring forward and own ‘stupid’ processes in an easy way is going to help identify the problems and move towards solving them. It also sometimes gives people an opportunity to question things that they never felt made sense and this may, in turn, help others question the ways things are done – this is very valuable and is not always possible in the everyday workplace environment. Bringing these issues out can be very revealing, it gets people on the same page, and is often cathartic. - Reduce, reduce, reduce
The strongest point is a simple one. - Get agreements as you go
Double check that everyone is on the same page as you go. Get explicit agreement even on seemingly obvious agreements. Total consensus is not always necessary but general agreement is. - Document it all
Get it down in simple terms on whiteboards or whatever you have available. At the end of sessions commit this to digital, shareable, media. - Summarise your journey and where you are now
At the end of a session, it is always necessary to summarise in clear terms the journey you have taken and where you have arrived. Get consensus on this. It is also useful at various points throughout the session to do this as a way of illustrating you are all on the same journey and reminding people what this is all about. When doing this it is very useful to make points in this summary that illustrate that you understand them – bring out points that may have taken a while to get clarity on or that you may have initially misunderstood (there will be many of them if you are doing your job well!) so the group knows that you are embedded with them and not merely massaging them towards your own pre-designed end game. - State your willingness to discard your own product
Nothing builds trust more than statements to show that you are invested in helping them achieve what they need over what you want. Your investment in this, as with all your actions and statements, must be genuine. For this reason, too, you should accept conclusions that propose cultural solutions over technical, and other people’s products over yours. This also implies you need some fair understanding of products competitive in your space and you should not make denigrating comments about them, but instead recognise when they have value. The assumption is, however, that since they invited you here, and if you are doing a good job, people will choose your product anyway – but you must let them make that choice. It’s OK to highlight this dilemma and probably helps things if you do and do so in a light-hearted way. - All solutions must be implemented incrementally
Do not design and then build the final solution all at once. Solutions must be deployed incrementally and learnings folded back into the proposed solution. Build to a minimum proposition, try it, learn, redesign, repeat. - Bring in the competition
During CDS, it is sometimes a good idea to have complementary or competing technology providers at the session. You will probably find that his leads to great collaborations, each contributing what they excel at. - Facilitation is an art of invention
While this section has not been about how to facilitate, it is important to make a note about invention before the next section in the hope that no one just reads the below as an instruction manual. There are processes and methods that you can use ‘off the shelf’ as a facilitator but none of them will translate from paper to reality in a one-to-one mapping. People are too weird and contexts too variable to ever allow facilitators the luxury to do it by numbers. At the very least facilitation is an act of translating known patterns into a new context and tweaking it to fit. But the reality is that much of the what a facilitator does is to make things up. Instinct and the terror of failure force on-the-fly invention of methods, but each time a good facilitator makes it appear that the method has existed for a hundred years and has never been known to fail. When it does fail, a really good facilitator will ensure no one notices.
Phases
The following is a rough structure for a CDS implementation. Facilitation of CDS is necessarily fluid and it is not expected that there are strongly delineated phases, rather that there will be some ebb and flow between each. As a rule, however, you should be moving forward through these stages in a somewhat sequential and linear fashion.
Each of the following phases are guides, and they may all be done in one CDS or over multiple sessions:
- Introductions
No matter if everyone knows each other, always do a round of introductions. It sets a baseline expectation that even the obvious should be stated. It will also help you to understand something of the stakeholders present and the roles they play. Experienced facilitators also use this time to read the interactions in the group and start formulating strategies to get them collaborating. - Why are we here?
Ask the question – do we want change? Before starting on any Collaborative Design Session you must first confirm that the group actually wants to produce change. This should be explicit, the facilitator can actually ask this question outright. The answer is yes, but it is not the answer that it is important, it is an affirmation by the group that they are prepared to undergo a process that will instigate change. - Where are we now?
We need a good understanding of the current workflow.- Start with a description of the current workflow
- identify pain points
- quantify time periods
- identify roles & gatekeepers
Turn all of the above into easily consumable artefact’s (may need to occur after the CDS) and share them.
- Identify Scope
The problem space identified above may be huge. If this is the case then some scoping is necessary. Ask the group to define the most important problems to solve first. If possible you want one nice cohesive problem to solve. Avoid trying to solve too much. - Solution Proposition
We are now in search of the Solution Proposition. An SP is not a solution, it is a proposition. It’s very important to frame it this way. We are not under the illusion that the final design is a magic cure-all, rather it is a hypothesis that we are now prepared to test out. There are a number of ways you can develop an SP. Your choice of method is a product of observations about how the team works together, the problems they are trying to solve, and your experience as a facilitator. Here are some example methods to get there, these are some things that could work. However, facilitation is about invention. Invent processes like the below on the fly and then test them out in your sessions and learn. If you are doing your job well then you will be experimenting all the time, and if you are doing your job really well then no one will notice when one of your new inventions (possibly made up as you are saying it) fails. Those listed below work, but the first time I used each I made them up on the spot (shhh…).Blank Canvas
Start with a very open-ended session. Ask how they would like to work, let the conversation roam. Document anchor points that seem important and/or repeated themes. Essentially what you are looking for is a starting point for the new story on how things will be done. This starting point might be very concrete, or it might be highly conceptual. It could also be that you think you have the starting point but find that actually, some in the group want to take the starting point back to the fundamentals of what they are trying to achieve as an organisation. Your job is to witness this and keep the process going until you find the point where most, if not all, participants what to start the new story.At this point, you need to make sure the new story is well documented and you are getting good clear, simple, points. There is no substitute for facilitation experience at this point, but if you are struggling then the best strategy is to try and make the starting point somewhat concrete and less conceptual. For example, draw a blank box and say something like”how do we start the new process in a browser?” (assuming we are discussing web-based solutions). Get to a blank canvas that is somewhat parameterized and contained. Then draw out concrete details about what ‘could’ happen in on this new canvas. Enable people to roam and use what you have learned from the previous phases and what you know about the domain and product to ‘keep the conversation real’. This will make your work much easier.
Iterate like this and work towards building concrete steps that illustrate the new ways of doing things. It is surprising that in some situations this process will lead directly to a pretty good understanding of what user interfaces and flow you are building. Other times, you may need to keep the conversation going until something concrete will materialise. In general, the more experienced you are as a facilitator, the better this part of the process will proceed.
Pitching
Give each of the participants some large pieces of paper and ask them to each to draw a solution. Set a finite amount of time. Don’t let anyone claim they ‘don’t know enough’ about the problem space – ‘naive’ Solution Propositions often have very insightful points. At the end of the time limit, each participant is to pin their paper to the wall and speak to it in 5 minutes. These are not real pitches, just a light presentation of what they were thinking. Then have 5 minutes of questions and comments. Leave all papers on the wall (just add to them for every pitch).After everyone has presented, it is good to break for a while as this was probably a long session. It is also good to break here to take some time and consider what your next step be. From the pitches, you must derive a single Solution Proposition. It is OK at this point to propose it yourself when the group returns to the room. Make sure that when you do this you are proposing ideas that the group has had and not your own pre-designed solution. Invite comment on the Solution Proposition.
You should end this phase with a good understanding of the cultural changes necessary and what you are trying to build. It is not unusual to have whiteboard wireframes at the end of this process.
- Working Agreements
Agree on how you will work together. What channels you will use, what information goes where, when the next face to face or remote meetings will be etc. - Mocks and prototypes
If there is ‘something’ to build, don’t build anything yet. Create image mockups, get feedback, iterate to sign off. Then move to some form of interactive prototype. HTML is often a quick way to do this, you don’t need all the functionality in place and not everything needs to be working. Get feedback, iterate to sign off. - The Build
As a result of the phases above, changes may need to be done internal to the organisation – this will quite probably not involve you. However a product, most likely, also has to be built hence following from the Collaborative Design Sessions is the build period. This is possible to do within group sessions as outlined above but is more likely to be done outside of these sessions. Generally, tasks are allocated to individuals with the necessary skills. UX people, for example, will generate mockups or developers will work on code. These materials are then brought back to the group for discussion, it may be that this process is conducted remotely in part or whole.