https://thomashallgren.com/edenoneos-dac-voting-app-fractally

EdenOnEOS is a blockchain-based community voting application inspired by Dan Larimer's book "More Equal Animals." The project aims to enhance democratic processes through user-friendly design, focusing on user research, pain points, and personas. Key features include playoff-style voting, a consensus-o-meter, and real-time feedback mechanisms. Despite challenges in technology and user experience, the application successfully facilitated community voting, achieving high completion rates and positive user feedback, while also identifying areas for improvement in future iterations.

Description

Building a community voting solution based on Dan Larimer’s book, “More Equal Animals”

Project background

EdenOnEOS is a pioneering project aimed at revolutionizing democratic processes through the use of blockchain technology. As the lead UX Designer, I significantly contributed to the UX/UI research and design of the product. This tool harnesses the power of the EOS blockchain to foster a new generation of Digital Autonomous Communities (DACs), community builders, and influencers.

Project details

The objective is to develop a community application that incorporates the solution proposed in Dan Larimer's book, "More Equal Animals".

Deliverables

• User Research
• User flows
• Wireframes
• Lo-fi Prototype
• User Testing
• Mockup Prototypes
• Style Guide
• Hi-fidelity designs

My roles & responsibilities

As the Product Design Lead for this project, I was responsible for:

• Conducting research
• Performing user testing
• Wireframes, Mockups, Prototypes
• Designing UX / UI
• Developing brand design

The technology team

The technology team served as the core leadership for the project. My role was to create a user interface for the application that delighted users while adhering to the technology leadership's intentions. All members of the team were well versed in the underlying technology and the intent of the proeuct.

Understanding the user

• User research
• Personas
• Problem statements

User research

Meeting with the community was important to the process. We were contemplating user flows outlined in Dan Larimer's DAC plan. Preparing the community early to participate in the process was headed by other members of our team. Being in the meetings and being able to hear the cancers helped identify pain points.

Community meetings →

Five-six-member meetings

User research: Summary

To gain a deeper understanding of user needs, I interviewed members who participated previously in DAOs or on community associations, or boards.

User research pain points

Personas

Product Problem Statement

Our users, varying from software engineers to community activists to retired civil servants and professional networkers, are seeking a blockchain-based solution that enables efficient community mobilization, fosters government transparency, and provides innovative solutions to current technological limitations. They are passionate about utilizing technology to revolutionize democratic processes and community building and are in search of an intuitive, user-friendly application that can help them achieve these goals.

Challenges

The design of the EdenOS app presented unique challenges. These included enabling member onboarding and voting via Zoom video meetings, and incorporating playoff-style election processes. This is all very new so the the complexity of these features was amplified by the absence of similar models. This was compounded by the inherent usability challenges of the EOSIO blockchain technology. Despite these immense technology hurdles, the goal was to develop an effective, user-friendly application. This was achieved through collaboration with the most skilled front-end and EOS blockchain team on the planet - literally (no other development team could have delivered this project, or in anywhere near our timeframe).

User Flows

The user flows were designed in accordance with Dan Larimer's plan for the Digital Autonomous Community (DAC), incorporating extensive input from the entire technology team. These flows identified a significant number of potential issues at the early stages.

Development of the application information architecture

I crated the following user information architecture diagrams with the development team to confirm our understanding of how our users would navigate to key features in the application. These included:

1. Membership
2. Community
3. Treasury
4. Elections for voting

2. Voting

The voting user flow also contained several significant "pain points" related to voting percentages, time allotment, blockchain signing, and video capture and upload. Our technology team was aware of these challenges and collaborated with me through numerous iterations to simplify this essential process for the user.

Key Feature Designs

The following designs present the final product outcome. These results provide insight into the complexity encountered during the design and early development stages of the app, as shown below.

Playoff-Style Small Group Voting

The playoff-style elections allowed any member to advance to the next level in the community through persuasion. In a group of five or six, a member had to persuade at least 2/3+1 members of the group (including voting for oneself) to vote for one member to progress. This required notable leadership, purpose, and persuasion skills from each member. If a member didn't receive the required votes, they wouldn't advance, and that group would not have a representative to communicate with upper levels.

Rapid prototyping rank-order vote test

The following is an example of a quick rank order voting process where users could be moved up or down using the arrow buttons.

Rank order vote Lo-Fi Prototype tesging

We conducted internal testing to understand user experiences, identify issues, and confirm design decisions. This helped us ensure the final product was functional for users.

Distilling early testing feedback

In an effort to get a handle on the user testing and to discover the pain points in the process I put together an Empathy map of the results.

Empathy Map: Feedback Example

Conclusion: No rank order voting

After completing this interim rank-order vote test, it was determined that rank-order-voting does not align with this version of the application. The reason being that there is no reward system for ALL users. It only rewards the users who advance and receive a budget.

Rank order voting would be considered in a future version we developed called “Psinq” the following year.

Minimal styles guide

The first version of EdenOnEOS was intended to be an iterative process. I built a preliminary style guide and components. For the color palette we adhered to web standards.

New Voting Process UX/UI

Voting was only possible during election periods, which is why it's located at the bottom of the navigation menu.

Desktop Voting UI

Mobile Voting UI

We initially assumed that all users would vote using their desktop devices.

Mobile usage results: Unexpectedly, about 30% of users chose to vote on mobile devices. Many even used Zoom and voted on the app simultaneously.

Understanding: The convenience of joining a meeting from anywhere at any time attracted more users. This flexibility allowed users to vote who otherwise wouldn’t have been able to.

Hi-fi mockup and prototype of single-choice voting

Prototyping the mockups to test the flows

I had almost daily reviews of the hi-fi mockups with the development team. They mostly led the project and I translated much of the functionality through discuss with them into the final designs. The Hi-Fi mockups and prototypes helped them to better understand the human factor issues I was dealing with.

3 Key voting components

In the voting design process, three key components went through extensive iterations on their way to final designs.

1. Choice Box

The voting component interface was designed based on user testing. Users favored a checkbox, where only one box could be selected at a time, over a traditional radio button. This preference was due to two reasons: firstly, checking a box felt more like voting to users; secondly, this format complies with UX standards as no initial selection is required.

Additionally, to enhance communication among participants, voting results were shared in real time. Participants could vote and modify their votes until the meeting concluded. Real-time feedback on who was voting for whom and how many votes each member received was also displayed.

2. Consensus-o-meter

The component we fondly refer to as the “consensus-o-meter” required significant iteration due to its complexity. The final design was influenced by several factors, including space constraints and the requirement for a member to vote for themselves to achieve consensus. With the use of iconic and written active feedback, users found it easy to vote. They were always aware of the current active state, thus successfully casting their votes.

3. Voting “pi-mer”

In tests without a timer, users did not complete their voting on time and required a prompt. As meeting durations and stages can vary, a color-coded time system was devised.

A new component we fondly named the "pi-mer" served as a timer to inform users of the remaining discussion and voting time. Initially, the timer is green with 40 minutes left. It turns yellow at the halfway point to signal that half the time has elapsed. When time is running out, it turns red to urge users to finish their voting.

Hi-Fidelity Invitation prototype recordings

User Testing

We recorded test meetings so I could capture responses. We looked for positive and negative feedback and to measure the overall sentiment of the community. Here is an examaple of the video upload service we tested.

EdenHi-Fi Mobile Invitation Flow

The Eden invitation flow required several steps which we required displaying all the steps to the user, and added educational information along the way. Our members later helped us to simplify this flow.

EdenHi-Fi Mobile Consensus-o-meter

The consensus-o-meter measured the consensus and when you did not vote for yourself, there was an open space that took the group out of consensus.

Hi-Fidelity Invitation prototype Link

Experience it yourself using the prototype link provided below.

🔗

Prototype user testing

We were able to provide very simple instructions to users during testing.

1. “Vote for one member.”
2. “Use the consensus-o-meter to align your consensus with the other participants.”
3. “Be aware of the timer.”
4. “Note, you can change your vote.”

Testing results:

The results were very positive. The feature worked well and users were completing voting with positive feedback overall.

“Being able to change my vote helped us complete the meeting early.”

“I suddenly notice the timer turned red, so we hurried up and got the our votes done.”

“We all voted for one who had not voted for themself, the consens-o-meter helped there.”

“Using the check box was not a problem. It made sense.”

Learnings

• Simplified designs
• Prototypes in motion: The ‘temporal’ experience of prototype helped reduce clutter and improve user focus on key tasks.
• Focus user attention: Any piece of information that does NOT provide SIGNIFICANT REAL value to the user at that time should be removed.

Empathy ,ap of feedback

Application release

Positive results

• 94% of the groups completed voting in the time allotted.
• 88% of all groups achieved consensus.
• 1 group did not achieve consensus because the group could not agree.
• 1 group did not not achieve consensus because failed to vote.
• 2 members had technical blockers.

Positive user testimonials

"This solution works for our community."

"This a refreshing take on what a DAC should be."

"Everyone was able to talk and share."

"This is amazing, I got to know so many awesome people."

"I fell like I’m part of a community that cares about it’s members."

"Experiencing this kind of democratic process in such an innovative way was truly remarkable."

Negative feedback

There was

friction

between members over voting.

Combining video within the voting application would help.

Outcome and conclusion

The application worked, but it was not a smooth experience.

The community found the app intuitive and successfully cast their votes. Our primary success determinant was a user interface that displayed only the most critical information for decision-making at any point.

We needed to find ways to make the process easier, possibly off blockchain.

Collaboration and active prototyping

Had we not been actively prototyping, we would not have been able to launch on time. Many important issues were caught early in the process.

Community Notion Page:

🌳Eden 🍏

©2024 Thomas Hallgren