Why Co-design for an R&D project?

There are many reasons why co-design is suitable for Learning Layers project. 

Listing some of the most obvious reasons are for example, co-design is flexible for parallel design activities and process, it is an iterative process as are the agile software development methods used in the Layers project, it requires that all stakeholders take part in the process – especially the end-users, the actual users who are/will/should be using what ever is designed. The not so obvious and what might not always be mentioned are: the artefacts of the iterative cycles, e.g. mock-ups, wireframes, testing results, created practices, from low level to high level prototypes are valuable outcomes and research results as such, and that the process attempts to engage the end-users for sustained activities, thus lastly it is a process that can go on long, it just changes its focus during the journey toward most enjoyable usage experiences.

Explaining the above points in more detailed and in relation to the Layers project these mean:

1. Flexible with parallel design activities: The Layers project has many streams of activities (http://learning-layers.eu/work-streams/), these are in different levels of practices. There are streams from different theories, empirical studies, on creating scalable and sustained practices and networks as well as designing and researching on the different technological solutions. These are called as work streams. These provide knowledge to the actual design that occurs in the design team. The design teams have members from each work stream and representatives from the end users (clusters from the two sectors selected for the project), entrepreneurs, policy makers and individuals from all the possible end-users of the project results. In the design teams, there are parallel threads of actual design ideas, and tools. Co-design enables to take into account the different streams and threads and create awareness practices to the partners. Some of the awareness practices are integrated into the used tools, such as wiki, which semantically lists related and similar items; some are integrated into the design activities in workshops and focus groups, and in the iteration cycles and joint face-to-face project meetings. However, these only evolve and grow during the work, so it means that patience is needed in the beginning and also tolerance to uncertainty, because the attitude of the design is experimental, partners learn while executing the design activities, and designs are tried out and also thrown away.

From the Participatory Design perspective it can be said that there is a social dimension aiming towards more democratic workplaces or communities and empowering those who are usually seen as subjects of design. Thus, the subjects have a right to participate in design decisions that will affect them, and designers have a responsibility to involve possible subjects of the designs. The role of designer is of a facilitator for the design process and a champion or leader that represents end users needs. This is the ‘Scandinavian school’ approach (Bødker, Ehn, Sjogren and Sundblad 2000).

2. An iterative process as is the agile software development methods. Basically is the process that goes in short cycles following the Agile and Lean software development methods. The length of the cycles is negotiable so it can be fitted with the development process adopted in the Layers process.

3. Taking along the end-users, is often mentioned the aim for a end-user-centred design (UCD), participatory design and similar approaches. When associated with participatory design, co-design takes an experience-driven/pragmatist approach to people. The focus is on activities, experiences, the meaning people have and create instead of information processing. It is a set of tools, events or forums where co-design activities take place (Mattelmäki & Sleewijk Visser 2011) for example in the Layers project, the design conference (in Helsinki http://learning-layers.eu/our-early-design-ideas/) and in the workshop and focus group activities within design team activities, are part of these practices and have their own set of tools. In the Layers project, the participation of end users occurs in various levels, it comes through the representatives, which are the actual end users who will use the tools but also are from clusters and policy makers that enable scaling of the tools and practices.

4. The artefacts of the iterative cycles are valuable outcomes and research results as such. This aspect has a very strong impact in the whole process of the project and in the development of the research and frameworks used. It means that research aspects are intertwined into the process. The research comes from the work streams into the design activities but also the results and outcomes, (e.g. mock-ups, wireframes, testing results, created practices, from low level to high level prototypes) provide input to the theory.  The cycle of feedback from the design to the theory and from the theory to the design is an important factor in these kind of broad and multi-layered projects. It also means that good theoretical background does not automatically provide designs of success.

5. Attempts to engage the end-users for sustained activities and in a processes that can go on for long. Presence of the users is the starting point, but participants in co-design can be selected with wider scope. From business perspective it can be seen as one method for crowdsourcing. If customers are given tools to personalize or design products and these designs are available for community, it will create value. This is often used together with co-creation. In the Layers project, it means that the scaling up practices and business models are tied to the design activity by one thread in the design teams. The engagement from early on is important, since this provides the basis to scale up. The other important issue is the long-term sustained practices with the end users that can support and enable constant feedback of new end-users, fields, usage, features, and manners of use.

Co-design activities can be created from scratch or selected freely from familiar co-design and participatory design activities. It is always good to adjust activities to better suit the purpose: these are not experiments where variables need to be controlled or that design activities need to be comparable to each other. For instance, the design conference had themes build into the days of the conference. According to the teams and goals of the design conference, different method were used. Below are some descriptions and examples of the methods and results:

  • The first day introduced the produced artefacts and ideas that the project partners had created in cooperation with the end users (for example: User Stories, Personas, Design ideas, Motivations charts, Scaffolding models, tool presentations as well as real devices that could be used, e.g. camera glasses). These were discussed in five different stands. Some of the summaries are in video: Co-constructing learning materials: https://vimeo.com/62605726, Sharing: https://vimeo.com/62602455 , Content maturing: https://vimeo.com/62604353 (These were shot with camera glasses, Pivothead provided by Alex Hayes ).
  • The second day asked partners to immerse themselves into hands on activities through, sessions of gaming (Scaffolding game reflections: https://vimeo.com/64377484, Gaming: https://vimeo.com/64379395, scaffolding model activities and tool creation design activities: https://vimeo.com/64382615 Creations of the hands on: https://vimeo.com/64384000.
  • The third day summarised the results and formed the start of the design teams. The 4 design teams are at the moment: CAPTUS, Bits and Pieces, PANDORA and Sharing Turbine [DE].

The work should go on and continue redefining, developing and further designing in cooperation with the end users and stakeholder in the local areas in the users’ own experience fields, the practices and tools that should support, scaffold and enable informal learning and scaling of these in the work places.

Even though co-design activities are methodologically free, a common flaw with co-design practices is to use them sporadically and only ‘when needed’. Often the co-design activities are not executed systematically from the start onwards. Thus, in the later stage of a project a need of co-design activities is noticed. Reason for this is that some of the co-design situations have been skipped and the design is worse than expected for the users side. The co-design activities should be flexible in content and in method, but reliably completed (Hyysalo, 2009).

Bødker, Susanne, Ehn, Pelle, Sjogren, Dan and Sundblad, Yngve (2000): Cooperative Design Perspectives on 20 years with “the Scandinavian IT Design Model. In: Proceedings of the First Nordic Conference on Human-Computer Interaction 2000. .

Hyysalo, S. (2009) A Break from Novelty: Persistence and Effects of Structural Tensions in User-Designer Relations. In A. Voss et al. (eds.), Configuring User-Designer Relations, pp. 111-131, Springer-Verlag London Limited.

Mattelmäki, T. & Sleewijk Visser, F. (2011). Lost in Co-X: Interpretations of Co-Design and Co-Creation.

2 thoughts on “Why Co-design for an R&D project?

  1. Pingback: Learning Layers and Co-design Mobile Learning (#mlearning) | Classroom Aid

  2. Pingback: Dr Debbie Holley » EU

Leave a Reply