Month: October 2016

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?

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.

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.

cpd3-3

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.

cpd3-4

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:

cpd3-5

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):

cpd3-6

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

cpd3-7

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.

cpd2_first

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.

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

cpd2_middle

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.

cpd2_last

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.

cpd_1

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.

cpd-2

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.

cpd-3

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.