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.