search

codeforamerica / civic-tech-patterns

common patterns and anti-patterns for civic tech and civic apps
http://codeforamerica.github.io/civic-tech-patterns
BSD 3-Clause "New" or "Revised" License
192 stars 25 forks source link

Split "process improvement" from "behavior change/increase usage" #6

Open bensheldon opened 11 years ago

bensheldon commented 11 years ago

From #2:

Also, these days I think of the tier app as a MVP. It demonstrates that there is a lot of demand for help in navigating the enrollment process, and I think an effort that did that would be really popular and make the process much more equitable.

That's a really cool statement: splitting the "process improvement" from the "behavior change". I think a challenge of a lot of civic apps is that they try to change behavior and fix a broken process at the same time. You're demonstrating "this is a problem that can be addressed with technology" (which I don't think we can take as a given for so much in the civic space) before you try to optimize/generalize the actual technological intervention.

Not sure if this should be a pattern or anti-pattern (though pretty much everything could be written positively or negatively). There are a few projects that have tried to involve new people in a new process without validating that the new process works for the people who were involved in or completing the old process.

So maybe this is just pushback to the shallow exuberance of putting things online in the name of accessibility/convenience OR recognizing that there are a lot of existing online processes that frustrate or inconvenience potential users..

A related potential pattern could be to seek out people who actually made it through a process and build something that helps them in continuation/maintenance (e.g. First make it easy to renew your business license before trying to tackle new biz licenses). This is trying to avoid the danger of Intentions Over Practice

kmcurry commented 11 years ago

Re:

There are a few projects that have tried to involve new people in a new process without validating that the new process works for the people who were involved in or completing the old process.

Whether this is good or bad has a lot to do with whether or not it is intentional or accidental. Many times it is a detriment to proceed thusly but occasionally positive disruption happens when redux-ers proceed and damn the consequences to the status quo. I think the key is to not do it by accident. Then again, deliberately disregarding the old guard doesn't make friends easily.

bensheldon commented 11 years ago

Whether this is good or bad has a lot to do with whether or not it is intentional or accidental

Yes! That's actually one of the main reasons for trying to collect/define these patterns: being intentional in what you do and having a vocabulary to describe that intentionality. Pattern or anti-pattern, everything isn't a green light or a red light, but rather a flashing yellow light: "here's an intersection, slow down, look for cross-traffic and check the road sign because you might want to make a turn."

On Saturday, January 12, 2013, Kevin Curry wrote:

Re:

There are a few projects that have tried to involve new people in a new process without validating that the new process works for the people who were involved in or completing the old process.

Whether this is good or bad has a lot to do with whether or not it is intentional or accidental. Many times it is a detriment to proceed thusly but occasionally positive disruption happens when redux-ers proceed and damn the consequences to the status quo. I think the key is to not do it by accident. Then again, deliberately disregarding the old guard doesn't make friends easily.

— Reply to this email directly or view it on GitHubhttps://github.com/codeforamerica/civic-tech-patterns/issues/6#issuecomment-12189600.

Ben Sheldon 2012 Fellow @ Code for America ben@codeforamerica.org 415.275.1776