Neal Humphrey | November 15, 2017
Cross posted on Medium
This post is part of a series documenting lessons learned while I was the project manager of Housing Insights, a website that provides data about subsidized affordable housing for policy makers in DC. I was hired to work on the project for 20-30 hours per week, primarily managing the group of 40+ volunteers that contributed to the project. Read part 2 and part 3.
It’s easy to build a website that no one uses. First, you hear about a problem - either something you see in the world, or something someone working in the world tells you about. You say to yourself - “Tech can solve this!” You sit down, draw up a plan, and then start coding. Several short months later, you release your software/tool/website/tech solution to the world, eager for accolades. Then, nothing happens.
It turns out you didn’t understand the problem, or the users, or what information or assistance they needed to solve the problem. Or maybe all these potential users do desperately want a better method to solve this problem - but they don’t understand how your tool works…
When we launched the Housing Insights project with Code for DC, I was wary of this. Our partners in the non-profit advocacy community and in the DC government wanted to bring better data to the process of developing affordable housing policy in the city. Code for DC brought the technical expertise, in the form of a volunteer software developers and technologists who want to give back to their community. We had the general direction provided by our partners, but needed to come up with the specifics of what we would build.
In Housing Insights, the most valuable sessions for getting our volunteers to understand affordable housing and feel confident enough to begin working on design were when we had volunteers interview potential users directly. We started this off by doing a ‘Design Sprint Month’, based loosely on the Google Ventures Design Sprint process (see the next post in the resources below). I also did about a dozen 1 hour user interviews (by phone and in person) to validate the need for a tool that our project partners had proposed, drawing from other people that worked in affordable housing policy.
Even though I started the process knowing user input was critical to our design process, the biggest lesson learned was that you can always use more user input. I thought the design sprint and user interviews would be enough to get us an initial design to test with users - but we ended up doing a dozen more interviews before we could even have something testable. The two biggest lessons were:
Keep up an interview schedule throughout the process. I found I plateaued in my learning until we started trying to design the website, which unearthed a whole new round of questions. Quite simply, you should always budget more time talking to users than you think you’ll need.
Everyone needs to talk directly to users. I thought the design sprint process, plus my summary notes from interviews, would be enough to fill this need. But it quickly became apparent that while this jump started the process, many volunteers also came up with more questions that they didn’t know they needed to ask during their first interactions with users at the design sprint sessions. Having each volunteer sit in or lead at least one in depth user interview at least 1 month into working on the project made a huge difference. Even when people only had one interview, if each volunteer had interviewed different people they could bring real concrete examples back to the planning discussions and share these concrete examples with each other. Being a little ways into the project also made sure they had enough context to have some questions of their own.
After we had a testable first version of our tool, our focus shifted to user testing - an equally important part of the process. We ended up doing 3 rounds of user testing, one using a fake tool (a clickable mockup) and two using real drafts of the actual website. But here again, do as many as you can and more than you expect to.
“Design with, not for” is such an important principle to civic tech that Code for DC even has it included in their code of conduct. But it’s often hard to do that - what is with? How often do you involve users? When are you ready to start building? Hopefully this post shares some lessons that you can use in your next civic tech project.
The next post in this series talks about adapting the design sprint process to a volunteer group.
The final post in this series talks about getting volunteers up and working quickly by reducing the time to hello world.
The Civic Tech and Data Collaborative is a partnership of Code for America, Living Cities, and the National Neighborhood Indicators Partnership and is supported by the John D. and Catherine T. MacArthur Foundation. The national organizations are working with seven communities around the country to understand how to harness the power of data and technology to increase efficiency, equity, and effectiveness in order to benefit the most vulnerable residents in our urban communities.