Reflections on some experiences that might be sorta like community-centered design
Here are some first-draft-quality ramblings about tensions between dimensions of design, from my experience, that might be related to doing community-centered design using value flows. This will be a little long. Sorry. As somebody said, I wasn't smart enough to make it shorter. But I promised to write something, and thought I better get a starting point out there, good or bad.
I say "might be related", because that phrase was not in my vocabulary when I started out. I knew I wanted to work with real communities, not make stuff up from my own wonderful ideas (which are often not so wonderful in practice...) At the same time, I had a focus, which you can read about here: https://sites.google.com/site/economicgroups/. That was posted around 2009 when me and Lynn and some other friends were thinking about economic networks. We had started working on software for them in 2007.
I also had a lot of experience in manufacturing supply chains, which are a form of economic network. And in 1996, I decided the requirements for transitioning to a better economic system required economic network software. So I spent a year searching for the best model for such software. Everything I found was limited and inadequate until I ran into REA (the model I am still using). Bill McCarthy, who first defined it around 1980, presented it as an internal company accounting model. But it was obvious to me that the model did not care about companies at all, and was instead a general-purpose economic network model. I contacted McCarthy, and told him what I saw, and he immediately got it and agreed. From there, we started to work together, until a version of REA was adopted as the ISO Economic and Accounting Model.
So when I meet a group that might want to work with us, I have some biases upfront. Are they an economic network? Are they doing something that might be transformational? And would the REA model more-or-less fit? (It's flexible, and I'm somewhat flexible about it, but probably not flexible enough. Or something. More on that below.)
But regardless, to the extent I am doing community-centered design at all, it's not from an open mind or for all aspects of a community.
You might ask, since I have so many biases, why do I want to learn community-oriented design? It came from the experience of working with some really good software developers who do what they call "user-centered design". And I thought to myself, I don't really do that or even want to do that. I think first of what this community I am working with needs (in the economic sphere), not what each individual user needs. It's not that I am against users. But I have seen situations where some individual users want stuff that is damaging to the community as a whole.
And I am just now engaged in an email discussion with the author of one of the articles on this page which references both community and user centered design about if and when tensions arise between those two centers. I think they often do. http://platform.coop/stories
But I don't think I am a very good designer, nor that I have done a really good job of community-centered design. Here are some examples where I think in retrospect I have gone astray, and wonder what I could have done better or differently. We are also in a similar situation on a new project
Every time we start to work with a community, we are mostly working with and through one strong leader who was among the founders and keeps everything going. These are usually not "natural" but "intentional" communities and usually mostly virtual, although they often have a geographic center as well. And usually they see our software as an aid to attracting and organizing members to their community.
Often we have mostly worked remotely, although we try to meet community members face-to-face as much as we can. That remoteness means we are not really members of the community we are working with. We don't feel their pulse or all their pain.
When I read the stories from @unalee and her associates in design for justice, it's clear that they tend to work with more "natural" communities, and also to immerse themselves more, and have more participation, than I have been able to make happen. Or even know how to make happen. Software development has some roadblocks to broad participation. Which is one of the reasons we like Value Flows: might make it easier.
The combination of interaction through a single leader or small group of leaders, and working remotely, causes problems. One community we worked with had a leader who described everything in terms of the future he wanted, not the reality that existed now. It wasn't until we visited ourselves that we understood what was really happening.
Another problem, which I want to focus on here, is connected to coming in with a model upfront: this has its good and bad sides, which affects Value Flows now, and will affect Value Flows implementations in different communities going forward.
In one community, the leader wanted to design his own ontology. I wouldn't work from his ontology, partly because I didn't think it would work, and partly because I already had an ontology and a lot of code based on it and he wanted something up and running fast. So I would either have backed out of the project, or he would need to go along with my ontology. I don't think I handled it well, though, because it was always a sticking point in the back of his mind and came up implicitly and explicitly in arguments.
When we met more community members, they didn't care about that, they were happy to see some tools being developed to solve some of their problems. And even the leader was happy because the software did embody most of his ideas, just not his ontology.
Many members of the community were unhappy with another aspect of design, though: the user interface of our software does not meet the Applelish fit and finish standards and user-friendliness they have become accustomed to from their smart phones. So that's one of the tensions between community-centered and user-centered design: both take a lot of time, and different sorts of work. We were working with another group at the same time that focused on user-centered design, and it took them a month to do what we could do in a day, but the results were beautiful. We needed features and functions to cover a broad range of needs of an economic network, while they could focus on a single feature, the visualization of a network.
Another version of the ontology clash is happening in a new project. This time, it is a community member who has developed an ontology he wants to use. Also this time, his ontology is a lot better-designed than the first time. It may be mergeable with our ontology. In other words, the system could work, and he could use it from the viewpoint he wants.
Ontology as I am using it here means the set of concepts and relationships in the underlying model and logic of a system. For an economic system, it means, how the economic relationships work in the software. It is a critical aspect, and what we focus on when we develop economic network software.
In this new project, we are also lucky that the person who has his own ontology also can code, and can take over a lot of the user interface work. So we are trying to let him run with his ideas and see what happens. We're hoping it leads to more participation, rather than less.
But the tension I see there is between experience and expertise and community participation. I am describing some experiences in my pre-valueflows software projects, but they do now and will in future affect both the development of the value flows vocabulary and protocols, and also the use of them in community projects.
In my previous projects, we were working with monolithic software which made it really difficult for other people to fully participate in the design and construction of the system.
They needed to either trust us or learn to code in a complex suite of software. We are now working with a couple of new projects where people are doing that, and are also therefore able to participate a lot more fully in the design of the software for their community. Using their own programmers, with some help from us, they can start taking over the development of their own system.
But there is still a tension between expertise in the economic model and logic, expertise in coding in general and in this particular software suite, and the larger number of people who cannot participate in those ways.
And expertise in the logic of an economic network. It's not freeform. It needs to work, and work over time, and also be adaptable.
As I have explained before, we work in spirals between the general and the particular, spiraling into a particular network with all its quirks, and then spiraling back out to summarize what we learned from that experiment to prepare for the next one.
Value Flows has been our form of summarization for the past few years. One of the lessons we are trying to learn from those monolithic software experiments is to break up the model into smaller components which can be mixed and matched as required for a particular community, and also to be developed independently by different people.
So I envision going forward with Value Flows as a set of components, the mythical software lego blocks. And wondering if those lego blocks will enable actually participatory community-centered design. And also have enough built-on logic so the lego block constructions don't fall apart.
As for Value Flows as its own little community, I am personally delighted that Lynn and Pavlik are taking the lead and I can step back, although I do sometimes feel the urge to argue about things.
What do you think? Was this too confused? Did you understand the main ideas? What do you think were the ideas that are useful?