This post was originally written for the Smart Contract Research Forum and is cross-posted there.
The user experience for most organizational governance is pretty lousy. In meatspace, it generally consists of impenetrable legal prose that, in order to be precise, loses meaning for most people who have to use it. Even fairly simple bylaws are, at best, boring.
In crypto, the problem is different but related. Interfaces like those of Snapshot and Aragon make governance seem like a deceptively simple token vote, without disclosing the layers of process occurring off-chain in chat threads, forums, and DMs.
Beginning in 2020, I and a few others have been working on CommunityRule, a Web app experimenting with what a better governance interface might look like. The goal is to explore how designing community governance might actually be fun, accessible, and transparent. As with open-source software, designers should be able to share their designs with others and fork the work of other designers, adapting it to new contexts. As a result, a design commons might emerge that allows more rapid exploration, iteration, and knowledge sharing. As more and more governance occurs through software, also, interfaces should also be capable of outputting usable code.
With the support of SCRF, and in partnership with SQGLZ, we are now developing a new chapter in this work, which we will be reporting on here at SCRF. Our goal is to develop a third iteration of CommunityRule.
The first iteration was a text-based tool that asked users a set of questions and invited answers in prose. This was simple to develop, and it attracted some interest, but it was only a modest step beyond the interface of standard textual bylaws, and the questions could be constraining. The second iteration replaced the questions with drag-and-drop modules. Users can now choose modules from menus, add them to their rule, and specify their contextual meaning in text. Modules can be inserted into other modules. This presents a more visual authoring and reading experience. But many users seem to have had difficulty understanding the modules, finding the right ones, and customizing them. User adoption remains quite slow.
The protoype works, but it has massive limitations. There are no user accounts; published rules can only be deleted by an administrator. There is no real data model (other than raw HTML!), so the rules are not very portable. We have put off such niceties until the core experience is creating the kinds of user response we’re hoping for: playful authoring, sharing, and building on others’ work.
I don’t know if we’ll get there in this third iteration, but I hope we can get closer. Here are some possible goals to work toward, now or later—and I would love to hear feedback on what seems most urgent or useful.
Reorient the design from a structure-based approach to a more subjective one based on actions and choices and agreements
Introduce gamification and interactivity to make authoring a more playful experience
Create more space for culture and other elements of governance outside of rules and structures
Rethink the layout to make it easier to find and choose modules
Replace the linear structure of the authoring space with something more 2D, enabling more relational representations
Enable diverse, custom module sets for specific applications (eg, a certain organization might present a certain limited set of modules to its chapters)
Integration with PolicyKit, enabling rules to translate into working code for governance in popular online platforms, or integration with a DAO governance platform like Boardroom or Aragon
What do you think? What else should we be exploring?
We are developing the code here, and we invite more collaborators. The app is based on Jekyll and JavaScript, with a Google Sheet for a database. If you would like to get involved, please reach out.
