Notes on Collaborative Product Development

So, during the Shuttleworth Gathering this week I facilitated a session about CPD and asked for feedback. I got some great information, most of which is targeted at what people would need to know in order to understand the process better. I am currently writing a ‘book’ about the methodology so this feedback will help shape that. Starting with:

  • challenges on the name and if there is something better
  • timescales need to be illustrated and discussed
  • implementation phase needs to be unpacked and described
  • testing cycles
  • bring out the fact that the product must be adaptable
  • explain how this will change ‘your’ organisation
  • importance of institutional buy-in
  • case studies and stories
  • maybe a hardware case study?
  • with this method some change is cultural
  • how would you measure cultural change?
  • how do you better ensure cultural change?
  • case studies would be very useful
  • simple illustrations of why this method is better
  • front load the political critique of Open Source
  • with the front loading highlight that most ‘client centered’ solutions are actually developer-centric solutions hidden behind a paywall

Also an interesting idea to make a current workflow image into a poster ‘this is what we are trying to avoid’

Arthur Attwell came up with this lovely way to describe the advantages of collaborative design:

footpath-oraSolution designed by the city council

footpath2-oraActual traffic

Here  you can see the dissonance pretty clearly.

I think I will structure the book something like this:

  • what is Collaborative Product Design
  • What does a hosting organisation need to think about
  • the basics
  • the setup
  • the design session
  • facilitation
  • the build
  • implementation

Where am I? How did I get here?

I recently did a presentation at the Open Fields conference in Latvia. It was about how art shaped how I think about publishing. It was a very personal pondering. I’m not sure how interesting it was to the audience but it gave me some moments to contemplate this for myself and, as a result, I produced these two mappings. The first shows my journey from art to publishing:

The next is the same journey but with the themes of Tech, Community, and Process threading through the mix.


I was trying to articulate how I am still the same person now, working in publishing, as I was when I was an artist. I think what I do hasn’t changed (it has, a little, utility has its own laws after all, but for the most part is the same) but the operational context has changed. I live (literally) in/on the publishing world, whereas previously it was the art world. In between was an interesting half-way house for my artist self – FLOSS Manuals which I founded when I ‘gave up’ the art world after I came back from Antarctica. This half-way house gave me the skills to transition from the art world to the ‘real’ world. In that period I developed the basics of the Book Sprint method, learned how to build community, and started building publishing tools.

Interestingly I never thought I was ‘entering the real-world’ (my apologies for the use of the term ‘real-world,’ it’s not to imply an invalidation of the art world, but it feels like a better term than ‘non-art world’ or any other term I tried to use instead). When I started FLOSS Manuals I thought I was doing what I did as an artist – making the interestingly ridiculous possible. I sought to establish the largest community in the world producing free manuals about free software. It didn’t have much reality attached to it and I never really thought through the sustainability options for this path. I just did it and trusted I’d work it out (a skill artists need all the time). So FLOSS Manuals is, in retrospect, a handy transitional moment and very important to all I do now, but at the time I just did it purely as a challenge and I didn’t want to get “a real job.” 😉

It’s important to me to drill down into this a little because I think art, like philosophy, enables you to choose ways of thinking. I think I’m still an artist, and its important to me to identify as that. I don’t go around saying “I’m an artist,” because the world reads artist with a capital A. Artist. Most would laugh if I said I was an Artist because in this world that sounds self-aggrandising. “Oh. he thinks he’s an artist of systems design”… sounds a little ridiculous. Like I’m claiming the mantle of Steve Jobs. But.. .a good friend of mine (Jaromil) once invited me to join an Italian hacker collective ( I was flattered but I said I wasn’t a hacker (or Italian) and his reply was ‘hacking is an attitude’ (I think being Italian might be an attitude too. 😉 I appreciated that and I think the same is true for artists. It’s a way of thinking, an approach. For me, it means being critical of what you do and not listening to the legacy ways. Of dreaming and allowing ideas to bubble through from of a cacophony of interesting ponders and hooks. Of allowing you to invest in the ridiculous as part of the journey to the succinct. At least that’s some of it.

Open Fields was an interesting event, perhaps more from a personal point of view too as this community was once my world (the art world). It was great to see some old buddies… particularly Tim and Tina from TimesUp. Still doing great work:latvia_3And of course…Marko Peljhan…never there even when he is there. haha 🙂


Collaborative Product Design v0.9 Ch5 The Build Process

The build is when the code and UI specialists start building. It is good to have this period immediately after a design session.

You can choose your own build methodology. Some organisations are set up to follow what they call ‘agile’ methods: [(I use inverted commas here for good reason – please see the following critique of the Agile Manifesto by one of the developers, Pragmatic Dave here or ], or some follow a requirements up-front process… whatever you choose that’s fine. I list the following proposed process as we have designed it and used it. It has some advantages. First, it gives the opportunity for the UI and code specialists to have creative input, second – this process is extremely fast and efficient, third – it delivers great results, and lastly – it actually works.

This build process, I’ll call it the Collaborative Build Process, for now, revolves around the creation of a single source of truth – the design brief. This document must be maintained with accurate and up-to-date information on the build teams approach to the solution.

From the design session, an initial version of a high-level brief should emerge that day or the next and then is sent to the UI and code people. This brief doesn’t need to be more than one page, 2 pages max and it should articulate a clear goal, breakdown of terminology (if necessary) to avoid confusion, and outline the design goal and parameters. The goal will be carried over as close to verbatim as possible from the design phase of the design session. The document should also state what the ‘space’ is for a second design session with the build team and what design choices have already been made. This document should be easy-to-read and contain no mocks. It is largely a narrative document, not a requirements document.

The build team then reads the doc and should be given a few days to consider approaches. Then the team meets (remotely works well if you can work out a good online whiteboarding system – we use Bigbluebutton). In this period the team go through a shorter collaborative design session. The goal is to make the simplest realisation of the previous sessions solution proposition. This sometimes means there is a lot to design, sometimes less so.


The build workflow of the Collaborative Knowledge Foundation (Coko)

The team can mock up roughly on a whiteboard and make UI and code decisions. The most important thing here is that everyone is in agreement at every step with the selected approach. When all parts of the design are discussed and decisions have been made,  then the team works out an order for these issues to be addressed. Once these decisions are made then four things must occur:

  1. Update Brief
    The design brief circulated must be updated with the decisions made in this session. This brief is the ‘single source of truth’.
  2. Code
    Code specialists can begin work.
  3. UX
    The UI specialists develop mocks. The code people can usually already begin on other tasks while waiting for the mocks.
  4. Update the Brief
    The brief must be updated with the finished mocks.

The build team then continues until done! It is good for the code specialists to check in with the UI people whenever necessary to get specs etc. Once completed then other Collaborative Design Sessions must occur for review and designing the next part of the solution.

Collaborative Product Design v0.9 Ch4 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’.

However…there are some gotchas. If the facilitator is part of the org with ‘the solution’ (eg an open source product) then make sure someone else from your team is present. Facilitation is about trust and you can’t be both a facilitator and a product advocate. You need someone else present to advocate for the product. The second gotcha is that it is generally better for the facilitator to be neutral to all parties, however, in this case, I believe there is value in the facilitator knowing the proposed product-solution intimately (with some knowledge of how it could apply to the use case being confronted), but you will need to work extra hard to maintain your trusted neutrality (you might have to work out in advance how to manage your feelings if the group starts advocating that they don’t use your product, for example).

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.


Facilitation Tips
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. 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. 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.

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.


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.

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 overplay your product knowledge and vision, you will lose people if you do.

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 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.

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. Stakeholders in this context can apply to the organisation you are working with (to solve their problem) or other projects that might play a part in solving the problem. Inviting the later to the events will greatly enhance the final product and produce valuable collaborations.

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.

Use their semantics
Use terminology to describe the problem and solution that come from the group. Don’t impose your own semantics.

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 fear 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 never been known to fail. When it does fail, a really good facilitator will ensure no one notices and that the outcomes were the typical, expected, ones you were after.

Collaborative Product Design v0.9 Ch3 The Design Session

The initial CPD design session starts with an initial current status review, followed by a development of a solution proposition, and finally a plan to produce part of that solution.

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 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.

cpd3-1Each of the following phases are guides and they may all be done in one CDS or over multiple sessions. The very first session has a special structure and we will get to that after describing the general approach:

Phase One – Why are we here?

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.

Phase Two – Where are we now?

Where are we now?
If the design session has materials to review from a previous session then this should occur now. If it is the initial session then 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 these into easily consumable artefacts (may need to occur after the CDS) and share them.

cpd3-2Example of an easily consumable current workflow description

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.

Phase Three – Where are we going?

This is when the group articulates what the future solution will look like. This can be a free ranging dreamy discussion but should be shaped slowly (like whittling wood) into something reasonable and achievable. This period might take some hours especially if it is the first session as there is much more to dream about earlier on.

Phase Four – Design

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…).

  1. 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 this concrete will materialise. In general, the more experienced you are as a facilitator the better this part of the process will proceed.
  2. 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 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 what cultural changes are necessary and what you are trying to build. It is not unusual to have whiteboard wireframes at the end of this process.
  3. Give Them the Pen
    Sometimes it is very useful to give someone with a strong vision for the solution a pen and ask them to draw it on a whiteboard and explain it. This turns the idea into something tangible that can then be discussed.


Phase Five – Summarise and Capture

This phase involves wrapping up the session, summarising what has happened and most importantly what is going to happen next. Capture all this ‘on paper’. The following is an example output of a whiteboard drawing of a component from one of these sessions:


In some instances, you need to clean up the outputs so others can better understand them. In this is a drawing that I made of it to make the idea clearer for the build team (see next chapter):


And, just an example, the following is an image of what the build team actually built:


Phase Sixth – 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.

The initial Design Session

The initial Collaborative Design Session is a little different. It requires the first phase to be a very deep dive into the way things are currently done and identifying the problem to be addressed and the scope. This will take a lot longer. Generally, a full day is required. Prepare to take the group through a longer and more involved ride and you should expect, and facilitate, a lot more discussion and spend a lot more time identifying shared semantics and understanding the exact details of what is now and where they want to go. It will be a long, but interesting, day.

Collaborative Product Design v0.9 Ch2 Set Up

You need: a problem that needs to be fixed, an experienced facilitator, a commitment from the people needing it to participate, a venue for the in-person sessions, a goal, and UI and code specialists.


The problem
Unfortunately, it needs to be said that you need a problem to work on. This problem should come from the mouths of the persons with the problem. We don’t imagine problems for people. If you have imagined someone else’s problem, you possibly should solve it via the performance arts or writing. Product design, as it is discussed here, is for people with actual problems, as told by them.

There are many models for facilitation and still more that are called facilitation. 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!

However it is also important to understand that the CPD facilitator is not an unconference facilitator, rather they are someone that can use unconference tools to manage dynamics but they must also be able to drive people to specific clear end points. These two things do not always come together and do not assume an unconference facilitator can perform this role.

Stakeholder Commitment
You need the commitment from the people that will be affected by the system. The software is going to be a direct result of their participation since they will design it. It stands to reason then that if an important stakeholder is missing, then you cannot design for them. So make sure you have everyone affected by the system present and that they are committed to this process.


A Venue
A good venue, at its minimum, is really a space with just enough room to house a table and enough chairs to seat everyone. An extended whiteboard wall is good to have, but can be substituted with large pieces of paper if necessary. The ideal venue would have breakout spaces and fresh air. It is good to have the sessions in rooms connected to or a part of the hosting organisation’s workspace so in-house legacy tools or current workflow can be demonstrated if necessary. Coffee and food arealways welcomed.


A Goal
The hosting organisation needs to articulate a clear goal. This could be in the form of “we need to replace our existing system for X”. It does not need to be much more detailed than that however sometimes the scope of ‘X’ will need to be determined. This can be done in the first Collaborative Design Session. However the very first session will need this first statement of the goal from the hosting org.

UI and Code Specialists
While you could try developing software without UI and code specialists (I have done it many times when I had no money to hire anyone) you will quite probably not end up with a good product. UI and code specialists add a lot of value when it comes to the build cycle of CPD. It should be noted that these people are not to be placed at the end of the line and passed hard and fast specifications to build. Instead, they are also part of the collaborative process and will be involved in a design session as part of the build process. Sometimes it is also possible, depending on resources, to also have them involved in the design sessions with the hosting organisation and this should be done if possible.

Collaborative Product Design v0.9 Ch1 INTRO

First chapter in a series describing Collaborative Product Design.

Collaborative Production Design (CPD) is a facilitated methodology for producing software products. I would call it a strongly facilitated method that generates and requires immersive collaboration.


In some sense, CPD is a new branch of the Systems Development Life Cycle tree. SDLC methods include Spiral, Joint Application Design, Xtreme Programming, SCRUM and others (some of which conform to Agile Manifesto values). CPD is specifically positioned 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. However, CPD also differs from open source models/default processes that have embraced developer-centric solution models. CPD requires the end people needing the software to design the system and places the facilitator as the enabling agent.

CPD also differs in that there is no backlog, no roadmap, no personas, no validations, no user stories, no standups, no user testing (since the ‘users’ design the system). This process is not about typical development procedures, it is about communication and collaboration. It is not a question of profiling a ‘user,’ rather it is a necessity to have all people affected by the system involved in the design process. The question is not ‘do we have a roadmap?’ the question is ‘do we understand each other?’ Followed closely by ‘do we clearly understand the problem and what we need to do?’ if the answer to this question is ‘no’ then the facilitator’s job is to find the right mechanisms (not necessarily the default software dev tools) that will help each member of the team get to this point of understanding.

CPD is iterative and has clear cycles each of which consists of a Collaborative Design Session followed immediately by a build period. Sometimes (but not always) UI and code specialists are involved in these design sessions. The specialists most in demand for the design sessions are the users. The design sessions are always in person and do not function well with remote participation. These sessions can be as short as 2 hours, as long as 1 day. The build cycles can occur remotely and may take 2-8 weeks, perhaps longer.

The general principle is that all stakeholders (end users) that touch the software must be present (in total or a representative group) in the design sessions. Building is the job of the UI and code specialists. All users affected by the software must be present (at the appropriate moment – more on this later) during the design sessions. Without their presence, you cannot develop a solution for them. A fundamental rule is that no one speaks for the user but the user themselves. Each build cycle also has a parameterized collaborative design session which involves the UI and code specialists.


In addition, a very important prerequisite is that the software must be able to be adapted to the final design. That does not mean the group must be ‘facilitated’ towards a pre-determined narrow solution which the software can cope with… rather, the software architecture at its root must be adaptable. The software must be able to be adapted to the user in the broadest sense possible, not the other way round. We adapt software to people. We don’t adapt people to software.

Finally, it must be remembered that new software changes behaviour, and it follows that we want software to produce a positive behavioural change – a change that benefits us. It is worth remembering that if this is the case, then if we can change behaviour without the need to change technology, that is the easier path and this is success. A solution designed by the people needing it might not require a change in technology at all, or the change may be to a smaller scale than you had imagined when starting the project, or the solution might not require your product at all. Unless you can accept this from the start, you are doing nothing more than producing technology for technology’s sake and CPD is not for you.

On the other hand, if the people design a technology that will assist them, then you also have a success and probably, perhaps luckily, there is more work for you to do.


You will note that we avoid the term ‘users’ as this suggests people are ‘hanging in there’ and conforming to the requirements of a technology. They ‘use’ the technology that is given to them. If the rat learns enough to get to the end of the maze relatively unhindered then this is the best case scenario with this approach. CPD believes technology should conform to the way people want to work and help the user get to where they need to go in a mode that is most suitable for them. That can only be determined by the actual people that need actual technological assistance.