One issue I have been thinking about is applying user centered design in situations where target users do not have the problem that is trying to be solved. For example if your goal is to build a software program to encourage people to reduce their energy usage, but the users do not need or want to do that, then does user-centered design make sense as the approach to solving this problem?
My guess is the answer to this is no, or rather it turns out that the project is focusing on the wrong user. If users do not need or want to reduce their energy usage, then we do not need to solve this problem for them. Instead the rationale thing to do is reframe it as “how do we help advocates persuade people to reduce their energy usage”. From there we can open up a world of possible solutions.
I encounter a similar issue with my vote.ctnewsjunkie.com platform. Candidates get tons of surveys so we sometimes have a challenging time getting them to answer our questions. However we can think about and try and fix other problems through our project. For example we provide an online presence and social media exposure that they do have, and then they are more likely to answer the survey if we solve these problems.
I spent the weekend at Code for America’s Brigade Congress event where we enjoyed programming related to running the volunteer program that Code for America administers. We covered a large swath of topics from fundraising to diversity. After helping run a brigade for over a year I have come to realize that brigades face two types of problems: figuring out how to do something, and then executing on doing it.
For the most part the biggest barrier to more success we face at Code for Boston is not on the how side, but on the execution side. This problem can be divided into two parts: lack of desire and lack of time. The first problem is difficult to solve. Either you need to modify the activity to make it fun, or make not doing it so painful for a person that they choose to do so it despite not wanting to. The second part is easy to solve because you just have to choose to not do something else. Unfortunately it is also hard to solve if you cannot or do not want to stop doing those other things. The only other solution is to make it take less time.
On Saturday I attended the Public Interest Technology Summit at Harvard Kennedy School. About eighty people gathered to learn about and discuss issues related to public interest technology. Public interest technology is the term the Ford Foundation is using to describe the field that many of us currently call civic tech. It was a worthwhile summit where I networked and learned a lot.
One session I attended was facilitated by Nick Sinai and focused on how to get students into the field. Students involved in the group Coding it Forward were there to share their experiences and how their program worked. It was helpful to get the experience of college students but I was disappointed to learn one of the founders of the group chose a job with Google instead of government, as rational as that decision was.
Another session was focused on David Eaves maturity model for digital services groups. The session emphasized that the product of digital services groups is culture change and there was a focus on user centered design. User centered design is the design and management side of what software developers might know as agile. Working together these two methodologies allow teams to deliver products that do a better job of fixing problems more quickly.
Almost a year ago my friend Mandie asked me to do the BAA Distance Medley with her. I roped in another friend and as a result signed up for my first half-marathon. I had never run a half-marathon before and was not sure how well it would go. After a year of training including a month of getting up at 5:30 a.m. to run before work on Tuesdays, I made it to a place where I was ready for this challenge.
Training was not without its challenges and sacrifices. The blistering hot summer made running more brutal. Some days I only made it half way before giving up. Longer runs and more sweat required extra tools. I got a new water bottle and gained a new appreciation of Gatorade. I found a sweatband to keep the burning mix of sunscreen out of my eyes. My sweat and the rain destroyed three pairs of bluetooth earbuds. When the distance is far, minor discomfort can derail major progress.
Running this race has taught me much about grit, dedication, and following a plan. Not every run was my best. Sometimes there was rain and headwinds. I had to eat and drink based on how food made me feel instead of how it tasted. When it felt like I could not go any farther, I persisted because I knew that doing so would make it easier next time. I kept my eye on the North Star and followed the plan to get to it.
Yesterday I ran some numbers about the impact of my group at MAPC and posted them on the wall:
If you want to put your own number on this wall, you can apply to join us!