Second round of research
This is going to be a short weeknote, so that we’ve got more time for analysing the evidence that came out of the research, turning them into robust insights.
Design rationale
Earlier in the week, Fabia added more notes on the design of our first two prototypes to our design history. It explains why we stripped away features we figured we’d need, talks about the Frankenstein phase of combining two frontends using collaborative ‘mix-and-match’ prototyping, and talks about how what we learned from users fed into later iterations of the design.
Rapid pre-release testing
Before we get into the research that happened this week, it’s worth calling out the excellent effort the team put in for testing the second prototype internally, before we released it to production for testing with users.
After deploying the second prototype to staging, everyone started running through the prototype, looking out for inconsistencies, bugs and broken things.
A couple of show-stoppers popped up. Instead of sorting these out in isolation, Hannah and Kev treated it like an incident and hopped on a call, debugging the problems and figuring out a way forward. Gavin joined later to help out too, and incredibly we got it all sorted in a couple of hours.
The prototype needed to be ready on production by 3pm. It was online and sparkling clean by 2.45pm. Top work from all involved!
Second round of research
Rob ran the second round of research, speaking with five people from four local planning authorities. Most of the users were GIS officers, although one person worked in planning policy, which surfaced lots of interesting points.
We’re not making any conclusions just yet nor sharing any early insights. We’ve got another session on Monday, meaning we’ll have tested with six people from five local planning authorities come lunchtime next Monday.
After that, we’ll be analysing the evidence, forming insights, and ready to end the year on a high. We’ll come back in the new year to continue the alpha.
Adapting for the unexpected
Researching, designing and developing products and services is not a linear process. Even though we describe it as a linear process with a start and an end, it’s actually more like a loop.
Right now, we’re exploring solutions to a problem. Problems are seldom well-defined, coherent, and tractable. So when we’re testing a prototype, what we hear from users often tells us things about the problem we didn’t previously understand or know about. We’re continually discovering new insights we didn’t expect, testing and learning and testing and learning.
Test and learn relies on a culture of learning, expecting the unexpected, and a willingness to accept new information and change the plan in response. And new information is coming up suggesting we’ll need to adapt the plan a little bit.
Early next year we’ll need to do some discovery-type research to better understand users’ needs, tasks, motivations and goals. There’s high variation in how they produce and maintain planning data (which doesn’t always include working with documents), and mapping this landscape a little more will teach us about where we need to focus.
It may even suggest some other forms of prototype we hadn’t considered before, and it’ll definitely help with planning a private beta too.