A couple of weeks ago Kat and I spent some time working out how best to spend the remaining time on our latest major project: helping people impact local planning by making it easy for them to write to their local councillors through PlanningAlerts. I thought it would be useful for our team, and anyone following from home, to document the decisions we made and how we got there.
When we started the project last year, we worked to deploy a functional system into PlanningAlerts as early as possible. This means that we’ve been able to see people, from all around Australia, writing to their councillors using PlanningAlerts for months. Many of them have even gotten a reply.
This year we’ve been making our system work more smoothly and with as little intervention from us as possible (remember we’ve got 5 other projects to develop and maintain). Our remaining core tasks are to load in more councillors for people in more areas to write to, and to announce the project. After we complete work on this we probably won’t come back to it for some time–we’ll be working on our other projects. We’ve currently got a little extra time to spend, so we want to make the most of it for the people who use PlanningAlerts.
To work out what we should focus on Kat and I did a mini, adapted Design Sprint. We were both happy with the result, and would like to experiment with the process more.
Design Sprints
A Design Sprints is a 5 day process for asking and answering important design questions, developing ideas and questioning assumptions. It was developed and formalised by Google Ventures. We drew on Google Ventures helpful resources and also Thoughtbot’s writing about the way they use Design Sprints.
Google Ventures describe a Design Sprint as:
a “greatest hits” of business strategy, innovation, behavior science, design thinking, and more—packaged into a battle-tested process that any team can use … On Monday, you’ll map out the problem and pick an important place to focus. On Tuesday, you’ll sketch competing solutions on paper. On Wednesday, you’ll make difficult decisions and turn your ideas into a testable hypothesis. On Thursday, you’ll hammer out a high-fidelity prototype. And on Friday, you’ll test it with real live humans.
We’re always keen to experiment with new approaches, and Kat and I both like the traditional Design Thinking approach of expanding with ideas then contract towards a solution. We both also have a capacity to go on tangents so were also attracted to the aggressive scheduling and blunt questions in the Design Sprint process.
However, working out what’s the most important thing to do with the remaining hours of a project isn’t a great fit for a Design Sprint. As I understand, they’re more commonly used to kick projects off. We weren’t looking to prototype a new solution, but refine the existing one in the ways that will be most helpful to people. We also didn’t have a facilitator. Usually a 5-10 person group goes through the process; we had just the two of us. Blocking out 5 days didn’t fit our availability either.
Working within our context, we did a rough two and a half day sprint that went through the first two formal Design Sprint days. These first days involve focusing on the deeper problem and generating new ideas. We didn’t need the final three stages to diverge on a single solution, prototype and test it. We wanted to be pointed to a bunch of small iterations on our existing solution. The major question we wanted to answer was, ‘how might help people make a bigger impact on local planning through the process of writing to their local councillors in PlanningAlerts’.
We worked through the Design Sprint checklists for the two days (Monday and Tuesday), sometimes sticking to the times, sometimes discussing more if we thought it was worth it. Some of the most useful bits we found were:
- mapping the user story we wanted to focus on;
- generating and sorting “How might we” questions which emphases the range of possible solutions and keeps the focus on their potential impact; and,
- the structured sketching from Tuesday (we came up with some pretty wild ideas).
Choosing a focus
There are so many good ideas or things to fix in any project. Deciding what to work on with the time available is the hard part. We firstly revisited the goals of the project and thought about the different futures that PlanningAlerts could help push us towards.
We came back to the simple idea of people working together to lead planning in their area, and that PlanningAlerts could help push us, “from a antagonistic planning process to a cooperative and collaborative one”.
We also noted down the simple phrase “public interest planning”, and the ordinary idea that local councillors should be accountable for their decisions to the people who elect them. We thought that “public interest planning” would only come when the people who experience the impacts of planning decisions work together to improve their local areas. This is because to fix some of the big things pushing us away from this future, current planning legislation for example, will be very hard for individuals to change alone.
“How might we …”
We reviewed observations from interviews we’d done with both PlanningAlerts users and local councillors. We used this as our ‘ask the experts’ Design Sprint session. One of the interesting things we pulled out was that when people successfully impact a local planning decision, they often have some kind of direct relationship with their councillors. We thought that one of the most important things this new feature of PlanningAlerts could do is seed and help develop these relationships with many more people.
During all this we noted down “How might we ..” questions. These are open ended ideas for what we want to focus our design efforts on. Some of the questions were:
- “How might we help councillors better represent people’s interests?”
- “How might we help people organise around a DA or specific issue?”
- “How might we help councillors better understand community concern?”
- “How might we hear from more diverse voices through PlanningAlerts?”
- “How might we help people continue their discussions with councillors?”
- “How might we help people communicate their community’s values?”
- “How might we help people help each other? (Right To Know style)?”
- “How might we get concerned locals to a council meeting?”
- “How might help people see if their actions made an impact?”
- “How might we change the planning rules to match people’s expectations?”
- “How might we make PlanningAlerts a safe space?”
- “How might we reduce abusive comments?”
- “How might we help people see what is influencing local planning?”
We decided that our focus should be to find ways to answer this question:
How might we build a sense of responsibility for local planning decisions in people and their councillors
We think that if more people gain a sense of responsibility for their local environment, then they’re more likely to take the steps to organise and build the relationships to really impact it. Without this sense of responsibility, it’s hard to imagine how they might do this–and how many of the other questions we thought of might be approached.
With this focus in mind we did the sketching session to explore some ideas for solutions. We also went through our existing user flow in PlanningAlerts and created new issues where we thought there could be an opportunity to build that sense of responsibility. We also went through existing GitHub issues and assigned them to our WriteToCouncillors Beyond MVP Milestone.
Using the results
Some of the changes we thought could make the biggest impact are to the text in the PlanningAlerts interface that frames the whole process of learning about DAs and commenting. These short bits of text, like the way we suggest people make a comment on an application in the alert emails and on a DA page, are seen and read by thousands of people every day. If we can seed a sense of responsibility through the text, we can make a big impact over time.
After all this time talking, we wanted to just get in and start making these improvements and really define what “fostering a sense of responsibility” looked like. We’ve started by iterating on the design on the comment form where people select a councillor to write to.
We thought it was currently looking bureaucratic and uninviting. If the councillors seem approachable, people will be more likely to comment and feel good about building that relationship. We made a big first step last week by redesigning the way councillors appear.
The next steps are working through the remaining issues and identifying more opportunities to build a sense of responsibility as we wrap up work on this project. Overall we found our heavily adapted, mini-Design Sprint process useful. It was great to work through the whole idea of this major project with Kat and really think about the impact we want and how to get there. I’m excited about seeding and building up a sense of responsibility for local planning through the experience of using PlanningAlerts.
If you’re using the Design Sprint idea in a civic hacking context we’d love to hear how it went for you.
Facebook
Instagram
Twitter