EdenOnEOS DAC Voting App (Fractally)

EdenOnEOS DAC Voting App (Fractally)

Description

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

image
image

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

image
image

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

Pain Points
Technology
"I'm concerned about the limitations of current technology and want to explore innovative solutions."
Effectiveness
"I need to find ways to efficiently mobilize my community."
Being Ready
"I see a problem that most people don’t want to talk about in Sweden, and I’m looking for a technology solution to be ready when things fall apart."
Integrity
"Community technology is run by corporations that hinder honesty and integrity.”

Personas

image
Persona 1
Adult male looking to unite his community
Age: 34, Education: Masters in Computer Science, Home town: Rapid, MI, Family: Married with 2 children, Occupation: Software Engineer
Problem statement
James, a software engineer specializing in blockchain, is eager to contribute to the development of cutting-edge technology inspired by Dan Larimer's book, More Equal Animals.
Pain Point
"I'm concerned about the limitations of current technology and want to explore innovative solutions."
image
Persona 1
Adult female community activist
Age: 29, Education: Masters in Community Development, Home town: Berkley, CA, Family: Married, Occupation: Community Activist
Problem statement
Jane, a community activist and mother, is eager to unite her community to promote sustainable living, especially among mothers in rural areas. Inspired by Dan Larimer's book, 'More Equal Animals', she believes in harnessing technology to achieve this.
Pain Point
"I need to find ways to efficiently mobilize my community."
image
Persona
Retired Swedish Man Interested in Government Reform
Age: 70, Education: Masters in Political Science, Home town: Stockholm, Sweden, Family: Widower with 3 grown children, Occupation: Retired Civil Servant
Problem statement
Lars, a retired civil servant and political activist, is passionate about reforming the democratic process in Sweden. He sees potential in utilizing blockchain technology to build a transparent and accountable coalition government. Inspired by Dan Larimer's book, 'More Equal Animals', he is eager to adapt these principles to Swedish society.
Pain Point
"I see a problem that most people don’t want to talk about in Sweden, and I’m looking for a technology solution to be ready when things fall apart."
image
Persona
Russian Male, Passionate about Government Transparency
Age: 24, Education: Bachelor's in Social Sciences, Home town: Moscow, Russia, Family: Single, Occupation: Professional Networker
Problem statement
Nikolai, a professional networker and social activist, is passionate about promoting transparency in the Russian government. He sees potential in using blockchain technology to facilitate a more transparent and accountable governance system. Inspired by Dan Larimer's book, 'More Equal Animals', he is eager to adapt these principles to Russian society.
Pain Point
"Community technology is run by corporations that hinder honesty and integrity.”

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.

image

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
image

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.

image

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.

image
image

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.

image
image

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.

image

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

Think/Feel
See
Hear
Say/Do
Pain Points
• Curiosity about how rank order voting works • Excitement about participating in a new type of voting process • Uncertainty about the impact of their vote
• Frustrated • Not sure why they are ranking everyone • Not sure what to do
“These buttons are kind of small.” “I think it would be easier to drag someone all the way to the top or bottom.” “This is hard”
“Will they hate me for ranking them down?” ”Can I make two people the top person?” ”Do other people see my rank and How I’m voting?” ”Tap Tap Tap to make one move is hard.”
• Lack of clarity about the voting process • Uncertainty about the effectiveness of their vote • Difficulty understanding the ranking system

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.

image

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

image

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.

image

Hi-fi mockup and prototype of single-choice voting

image

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.

image

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.

image

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.

image

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.

image

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.

image

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.

image

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

Think/Feel
See
Hear
Say/Do
Pain Points
• Excited and nervous about voting process • Excitement about participating in a new type of voting process • Uncertainty about the impact of their vote
• Frustrated • Not sure why they are ranking everyone • Not sure what to do
“These buttons are kind of small.” “I think it would be easier to drag someone all the way to the top or bottom.” “This is hard”
“Will they hate me for ranking them down?” ”Can I make two people the top person?” ”Do other people see my vote while I’m voting?” ”Tap Tap Tap to make one move is hard.”
• Lack of clarity about the voting process • Uncertainty about the effectiveness of their vote • Difficulty understanding the ranking system

Application release

image
image

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