In the summer of 2018 I was part of a team that was deeply immersed in writing the proposal for what became the ParkLife project. It was an exciting proposal to write. Nesta, a UK innovation foundation, was partnering with the Heritage Fund and Community Fund to support ‘protoyping’ projects that would test new ways that data and digital could help to create more sustainable operating models for parks. This was an excellent opportunity to develop a Living Lab project that would co-design new uses of data and technology to help improve the city for people.
Our project proposed to create a ‘data toolkit’ that would provide data to help park managers and users better understand how parks are used and valued and to better focus investments in parks.
We were thrilled when the proposal was successful. We knew exactly what we intended to do, and we had a great team with a wide range of experience, covering skills from co-design to coordination, park management to citizen science to end-to-end Internet of Things systems.
We had thought through the details, guided by questions in the application form such as:
Here's a sample from our carefully-designed plan:
My role on the project was to help guide the co-design process. That would mean working closely with park managers and park stakeholders - including Friends of Parks groups, community councils and park users - to understand their values and priorities and how the project would create benefit for them.
I began with great enthusiasm. I mean, we knew exactly what we wanted to do, so couldn't we just get on and do it?
Despite having a reasonable amount of experience working on community projects, I still somehow wasn't prepared for how different to the original plan reality turned out to be. There were plenty of things that happened that were completely outside of anyone's control, but over the following months there were also a few key lessons that would have been good to keep front and centre throughout the project.
First, co-design takes time. A lot of time. For example, in the original proposal we envisioned that we could carry out our ‘user research’ plan - effectively surveying people in parks - by employing University students and members of Friends of Parks groups to do the work. However, in practice this involved finding someone to lead the user research, designing the survey, advertising for interested students and Friends groups members to work with us, training them, and then actually doing the work. Compiled with a number of delays in other aspects of the project, what I had envisioned as a relatively straightforward piece of work to be done in the first month or two of the project wasn’t actually completed until almost eight months in.
We had also planned to host co-design workshops with the Friends of Parks groups early on in the project. However, to host a co-design workshop, we first needed to reach out to all the groups to tell them about the project. Organising that meeting took multiple months. After that we needed to find suitable date for each of the four workshops, where enough members of the core project team could attend as well as the Friends groups. By the time we had done this and hosted the workshops, even more months had gone by. It felt like the project timeline was half consumed before we'd hardly begun.
Second, co-design requires finding people who are interested in co-designing with you.
This project asked an open-ended question: ‘How might we use data to improve our parks?’ In order to answer this question, we needed to find people who were interested in data and interested in parks.
We invited Friends of Parks groups and other community members to join a number of workshops around the city. Attendance and participation varied widely by the type of people involved in the park. One workshop had 40+ people, while another had only 3, despite our best efforts at recruitment.
We got some interesting ideas out of the workshops, but when they were finished, we were still fairly far off the original ambition of having groups of people around the city actively engaged in co-designing and testing new applications of data in parks.
We’ve completed the project now, and while we certainly made valiant attempts at co-design, there’s a little nagging voice that says, surely you could have done better. What if we had had more time or tried to push things along faster? What if we had worked harder to find people to co-design with us, had hosted more events and different types of events to reach different people? Sure, it’s possible we might have come closer to achieving our wildly ambitious plan. Or maybe not.
For now, I’ll walk away with a few valuable insights and lessons for the future:
These are some of the insights...
Finally, there are many people with extensive experience in co-design and many guides to help you figure it out. But every project is different, and it will always be a process, with learning and mistakes. Take some time to reflect, make some notes, and go out and try it again.
