The first step in making any decision is determining what exactly needs to be decided. That sounds simple on its face, but can be surprisingly complex once you dive into it.
Ethelo’s algorithm can’t function unless it knows what issues and options to reference and what constraints prevent certain scenarios from being feasible. That foundation is built during the ideation phase and is essential to achieving quality results in the end.
An overview of the entire Ethelo process is available in this video. Here, we’ll specifically focus on ideation and how it sets the stage for voting and aggregation later in the process.
Issues reflect all of the subtopics within a decision. There is no limit to the number of issues Ethelo can process at one time, so your decision can be as complex as it needs to be. The only constraint is that each issue must be unique so that there’s no duplication in the final output.
For example, if a school board or organizing committee was using Ethelo to gather input from residents about a proposed new high school, they might break that decision down into issues like location, classroom size, amenities, and cost.
The content of each issue, or even the total number of issues, probably can’t be decided in a vacuum. It takes a certain level of consensus among key players to even reach this part of the process. Generally a balance must be struck between simplicity and inclusion.
If you find that your list of issues is too long, Ethelo can support higher levels of organization to put those issues into even broader categories.
Issues can be understood as buckets containing “options” which address that facet of the decision. An option is a specific action that would be part of an overall course of action. It’s not a decision in and of itself, but it plays a role in making one.
Returning to the school example, options within the “amenities” issue might be athletic fields, art studios, and computer labs. “Locations” might refer to specific places up for consideration.
To ensure that all of your voters are on the same page about these options, you can add a description in Ethelo and link out to supporting documentation if needed. Options can also have “details” which refer to pieces of key information about the option that is critical to the decision. For example, the details of an “athletic field” might include its construction cost, size, overhead costs, if those details will affect the overall cost of a school.
In configuring an Ethelo decision, you may find it’s easier to start with a list of options and then group them into higher-level issues from there. Either way, you’ll achieve the same result within Ethelo.
Again, the options and supporting information will need to be vetted by the proper stakeholders before Ethelo is deployed. In many Ethelo projects, participants can make “proposals” but those proposals must be approved in order to become “options.”
In the Ethelo paradigm, every possible decision outcome can be expressed as a combination of options, called a “scenario.” Not every combination of options is a valid scenario – there are often many combinations of options that are not internally consistent. Some combinations may not workable for other reasons – for example, a certain scenario may exceed a constraint such as total cost.
The number of potential scenarios in a given Ethelo project grows exponentially with the number of options (2^N to be exact, where N is the number of options). However, many of these potential scenarios are usually eliminated by the application of constraints.
Constraints are rules which make sure all the scenarios Ethelo generates are workable from a practical perspective. There are several types of constraints to consider:
- Logical constraints: Sometimes options are naturally mutually exclusive and can’t appear together in a final proposal. In the new school example, you might include options for an outdoor courtyard and an expanded auditorium, even though the space is only large enough to accommodate one of those things. By identifying an “XOR” relationship between the courtyard and the expanded auditorium, participants can express support for both options but no scenario will contain both.
- Set-based constraints: Sometimes we need rules that apply to groups of options. For example, we may have six options for sports fields, but only space for two. In this case, we are setting a constraint on the set of possible field options: “choose 2 of 6”
- Calculated constraints: These constraints apply to details (mentioned above) of a scenario that must fall within thresholds in order for the scenario to be valid. For example, if cost and budget are part of the decision-making process, then total cost cannot exceed total budget. These constraints can change relative to one another, such as adding additional revenue to the school project by raising taxes or launching a fundraising campaign.
Details and constraints are generally identified by the decision-maker as part of the ideation process. However, depending on how Ethelo is configured they can also be modified by participants.
In Ethelo’s framework, a “decision” is the selection of the best scenario, from all the potentially workable scenarios. How to know what scenario is “best” and more than merely workable is the hardest part of any decision process – and where Ethelo relies on collective intelligence.
Next Up: Voting
Once the issues, options, constraints, and criteria have been defined, it’s time to vote! The next post in this series will dive into how each individual contributes their feedback to Ethelo.