This month, a lot of my time has been spent planning, organising or teaching the Archaeology Department’s Heritage Field School. Like last year, Meghan Dennis (@GingeryGamer aka @ArchaeoEthics) and I were working on the module with Sara Perry (@ArchaeologistSP). Unlike last year, Meghan and I are now primarily responsible for organising and delivering the module. Part of the deal was that we would be allowed to shape the module to align more closely with our research interests. Sara likes to always do something new, so having worked on an audio guide and leaflet last year and a mobile app the year before (and given Meghan’s research interests), we decided to make a game this year. How does this align with my research interests? Well, we are working with Malton Museum, which is run by volunteers, so it is an opportunity for me to teach the user-centred and co-design approaches I have been using in my own work, and see them put to use in a different context. It also gives me another experience of participating in a project that includes volunteer and “professional” (read full-time) contributors. When we were planning the module, Meghan suggested that because we were only going to spend a couple of days at the museum, I should consider our students as my co-designers, rather than the volunteers at the museum. I wasn’t quite happy with this idea at the time – but she was right, of course. I thought I’d share some reflections on teaching the module (which is almost finished), and how this project has changed the way I view my other co-design work.
In my research, I often talk about two different design approaches: user-centred design and co-design. I’m an expert in neither, but I think both are relevant (and underutilised) in professional heritage practice. User-centred design is all about designing for users. In order to create a product users will want to use, you need to understand what they want and what their restrictions are – don’t design a phone app for users who don’t use smartphones. This may seem obvious, but it’s incredible how easy it is to start designing for yourself – or an ideal user that doesn’t exist – rather than the users who actually are likely to interact with your design. Co-design is about designing together. I had been introduced to it as an approach where the boundaries between users and designers are blurred and users are more involved in the design process. Recently, a computer scientist told me that it is perhaps most often used to refer to integrated design projects, where different kinds of designers design together. He said the most obvious example is the difference between Android and iPhone. Software and hardware designers design iPhones and iPhone apps together, while Android phones and apps are designed separately. This means that new iPhones and iPhone apps are designed specifically for each other; they are co-designed by software and hardware engineers. The reason why I found this so interesting is that it resonates with my reflections around #hexpertise. Collaborative heritage projects where professionals work with volunteers shouldn’t be framed as non-experts participating in professional practice, but as individuals with different kinds of expertise working together for the benefit of everyone involved.
I came into the module I’m teaching wanting to co-design a game with the volunteers at Malton Museum. It quickly became clear that this wouldn’t really be possible, because we would only be spending a couple of days together. As a result, I decided to tone down the talk of co-design, and tell my students that we would be adopting a user-centred design approach, where it was our responsibility to find out what our client (the museum) wanted and who our users would be (museum visitors). Then, of course, I realised that the involvement of the volunteers at Malton Museum wouldn’t be that different from the involvement of my partners in my own co-design project. The projects are different, of course, in that my students are building a game, while my own co-design work is about designing a web-resource, but it made me question whether my own co-design work is truly co-design. As I have written previously, my co-design project changed a few months in when I was convinced that we should take the design process further, before handing it over to a web-developer. I accepted this change, but I didn’t discuss it with my partners until after I had already taken on the extended design responsibility, which fundamentally changed the skills and time-commitment required. It was only after this shift that I began feeling that maybe we were no longer co-designing, but reverting to more traditional roles of a professional consulting focus groups. This feeling is what has caused me to think that maybe I began my co-design work too soon, before I knew what I was getting myself into, and that my co-design partners have had to pay the price for my inexperience. Increasingly though, I’m being persuaded that this isn’t the case. Like Sara, who likes to do something new every year for the Heritage Field School, starting my co-design work as early as I did was risky, but maybe this wasn’t the real problem. I think the problem was a lack of communication. I was uncertain, and instead of communicating that uncertainty and the ways I was navigating it, I let it keep me from communicating with my partners on a regular basis.
This problem is ongoing. I want to write another post about communication and trust and how important they are in collaborative work. But first I’m going to email my co-design partners – even if I don’t know exactly what to say.
In the meantime, you can check out my students’ blog. The game they’ve made will be online soon!