Malmö Civic Lab: Felanmälan prototype pt. 2
This post is a continuation of the post: My first weeks with Malmö Civic Lab: Felanmälan pt 1
Four weeks ago, I joined Malmö Civic lab. Malmö Civic Lab is an experiment by the city of Malmö to reveal ways of improving life for the city by prototyping using tech and design. It has only been around for a couple of months and is run by Måns Adler and Timo Engelhardt.
Felanmälan
In the previous post, I described what Felanmälan is solving and why we decided to look at that particular service as my first project.
How might we?
Based on the insights we gathered from user research, we defined a couple of problems we’d like to solve, phrased as “how might we” questions which helped us set a brief for the coming sketching sessions.
Sketching
In the next step, we tuned these insights and questions into some testable solutions. We invited people unfamiliar to the project and presented to them the insights we found during the research. Then we did 2x2 rounds of 7-minute sketching, each on a different topic. This short timeframe forces participants to create lots of sketches rather than quality sketches.
Sketching is a fun and efficient way of bringing people together, and getting new input on how to solve problems. After sketching, I usually take the high-level sketches away and turn them into detailed sketches. We ended up with 4 smaller flows that we wanted to test.
Picking a prototyping tool
There are endless tools and ways to test ideas. We could have used pen and paper or one of the many high fidelity prototyping tools that are on the market. We gained an interesting insight from our research, which helped us pick our prototyping tool.
Many of our users, the citizens reporting errors, are very active in local Facebook community groups and are using Facebook Messenger to communicate with friends, family and businesses. A couple of them had even been reporting an error in the city using the Malmo city Facebook Messenger. We wanted to quickly test if Facebook Messenger could work for error reporting, so why not use it for prototyping!
“Not with the aim to build a final product, but with the goal to build a product to figure out what to build” — From the book Lean Analytics
Prototyping
From the sketching session, I condensed the sketches down to 4 small flows or tests, that we’d needed to learn more about. The first one being if Facebook Messenger could be a suitable platform, the flows were to validate if:
- If people will understand how to use the map to locate their error with the standard Facebook Messenger map integration?
- If we can make people feel like their error report is in good hands?
- If we can help people understand why to leave their phone number?
- If we can help people upload useful photos and understand what they’re being used for?
Friends
From the 9 citizens we interviewed, we created a group of 6 extra dedicated users. These were the ones we’d be testing the above list with and get continuous feedback — So we met up with each one and handed them the prototype with the four different flows to validate the questions above.
What did we learn?
After testing with the users, we mapped out their feedback to identify patterns, which made it much clearer where to put our energy and effort next.
After this first round of testing, we quickly realized that Facebook Messenger is as a good place for us to start. It’s accessible and, for users, it feels familiar and natural. We also learned that users:
- Want to continue the communication in Messenger about their error
- Need context to the error report numbers
- Want to know who is responsible and what is happening
- Want to be able to skip the photo example
- Want to be able to search for the address for their error
- Want to be notified when something is happening with their report
All of these learnings will help us develop the product going forward. Some of them were easy solvable and could be implemented in our next version, others will need more thinking and technical depth.
From prototype to MVP
A minimum viable product (MVP) is a product with just enough features to satisfy early customers and to provide feedback for future product development— Wikipedia
We now felt somewhat comfortable about our Facebook Messenger concept and wanted to let something out in the wild, to test if it would work without us holding users hands.
Based on the feedback, we glued together what we had and turned it into a working flow. This flow does the basics; collects photos of an error, the description, location and contact details. The nice-to-have features will have to wait.
Fake it
Behind the scenes, we’d collect the data in a spreadsheet and use the current online form to do the reports for them. This not scalable at all, but it’s a fast and cheap way to get a product in the hands of users. It cost us nothing to build and has given us tremendous insight and learnings on how to move forward.
TBC
This was how we went from research to insights and testable prototypes, to the hands of users.
In the next post, we’ll cover what happened when we let the Messenger bot into the wild, what went well, what didn’t go so well, including numbers. Stay tuned!
