The following is created by Thomas Hallgren and pasted from his website:
https://thomashallgren.com/psinq-dac-meeting-rank-order-voting-app-fractally
Summary
The Psinq DAC "Meeting Rank Order Voting" app focuses on improving community engagement through user research, testing, and design. Weekly experimental meetings confirmed that rank ordering contributions was more effective than traditional voting. The target community for the application is Home Owner Associations (HOAs), addressing their unique challenges. The design process involved creating user personas, mapping user journeys, and developing a simplified user flow without blockchain complexities. The final design emphasizes a user-friendly experience, allowing members to rank contributions easily, fostering community unity and participation.
Description
Improving the EdenOnEOS voting solution by including video, removing voting, and creating "Rank order voting."
Project Overview
At Fractally, we developed Decentralized Autonomous Communities (DACs) to assist communities in self-management through contribution sharing and recognition. Psinq adapts the core concepts of Dan Larimer's book, "More Equal Animals, The Subtle Art of True Democracy".
The Eden application, which preceded the Psinq app, was built directly onto the EOS blockchain. Its community voted in groups of 5-6 members (randomly chosen) for one to advance to a leadership role.
Psinq no longer advances only one member in each group. Instead, groups are required to rank-order themselves. Then, over time, productive members are naturally elevated to roles of leadership.
The design process for this project included prototyping and testing weekly with real communities in order to see firsthand how the rank-order system impacted user participation.
For the purposes of this case study, I am reviewing the transition from voting for a single member to the final rank-order design.
The technology team
The technology team led this project, and my role as the UX/UI designer was to make sure the user experience was as natural and intuitive to all users as possible while adhering to principles of integrity and transparency. In other words, we wanted members to understand their contribution counted, in as frictionless an experience as possible. All team members possessed a deep understanding of the underlying technology.
Challenge
This case study investigates the substantial challenge of transitioning from a voting system to a rank-ordering and rewards system for determining leadership within a community. The implementation of rank-ordering in a completely transparent group can encounter several issues. These challenges include both the logistics of the mechanism and its impact on the members.
Project Duration
- 3 months
My roles & responsibilities
As the Product Design Lead for this project, I was responsible for:
- User Research
- User flows
- Wireframes
- Lo-fi Prototype
- User Testing
- Mockup Prototypes
- Design System
- Hi-fidelity designs
Understanding the user
- User research
- Personas
- Problem statements
- Journey maps
Rank order community test sessions
Our team ran weekly experimental meetings with the Eden community members to test rank ordering member-contributions manually (outside the Eden app) instead of using Eden voting. These meetings took place over several months.
👉
In each test session, from a user base of approximately 90 members, around half participated weekly. The members were manually rank-ordered in groups of 5. All members generously gave their time and feedback, displaying remarkable trust and providing invaluable input to the project. We cannot thank them enough.
Summary of rank-order manual test meetings
Members who joined and participated regularly ended up getting ranked accurately - according to their contributions - over time by their by randomly chosen peers over 8 to 16 weeks of participation. High contributing members rose up and lower contributing members settled down gradually over these periods.
👉
This left us with confirmation that rank ordering, over voting, was the correct next path.
Creating a mainstream application
We began a search for a mainstream community that would be ideal to model a new non-blockchain based application. This became a hot topic inside the company. We looked at towns, school boards, and eventually landed on HOAs (Home Owner Associations).
Target community: HOAs (for their collaborative pain points)
The HOA USP:
- HOAs have bad reputations.
- We willing participants - who wanted to make them better.
- Personal assets stake - including home values and neighbor relations.
- Members often felt trapped and were looking for ways out.
Settling on HOAs as a model reference made sense to move forward. Solving the problem for this type of community would be a model for other communities should we succeed.
HOAs were an ideal target community because they are existing autonomous organizations with much at stake for all the participants.
For a better understanding of how home owners related to HOAs, we I compiled a set of user Goals, Needs, Motivations, Frustrations, Tasks, and Opportunities.
Removing obstacles: Focus on meetings
For our of this case study we would drop complex onboarding and associated blockchain security, and focus on the actual meeting experience of rank ordering.
User research
To better understand user needs, I conducted interviews with community members who have had problematic experiences with community organizations in the past year. (The results below are anonymized)
User research: pain points
Loss of control | “A group of cronies took control of our local dog park and might sell it to developers.” |
Rogue leadership | "Nepotism is ruining our HOA. We need transparency and fairness." |
Out of touch with the community | “Our condo association is our of touch and has lots of anti-child oriented rules and regulations that result in unnecessary fines.” |
Not time to fight | "I spent a year showing up to get on the board of our condo, but leadership is locked in, so I gave up. It was a time-suck." |
Personas
PERSONA 1 | Adult male wants to have more say over the local dog park. |
Age: 37, Eduction: MBA, Home town: Irvine, CA, Family: Married w/ 2 children, Occupation: Business Owner | |
Problem statement | Jaques, a busy business owner worker, wants to save the dog park in his town. However, a group who runs the dog park seems to be more interested in selling the land to a local developer friend to develop condos. Jaques wants to get on the board to save the park. |
Loss of Control | “A group of cronies took control of our local dog park and might sell it to developers.” |
Jaques Problem Statement
Jaques, a committed local business owner, cherishes his town's public spaces, especially the local dog park. Recently, he's noticed the park's managing group prioritizing profit over community, considering selling the park for condo development. Troubled by this, Jaques recognizes the park's importance to the community. He's can’t get on the board to help direct the park's future towards community needs over profit, and needs a better governance solution.
PERSONA 2 | Mother lives in a town where nepotism is rampant in the government. |
Age: 33, Eduction: Bachelor, Home town: Austin, TX, Family: Married w/ 4 children, Occupation: Home maker | |
Problem statement | Susan, a busy mom, is frustrated by nepotism in her town's government. She wants a platform to voice concerns, improve transparency, and ensure fair policy implementation. |
Rogue Leaders | "Nepotism is ruining our HOA. We need transparency and fairness." |
Susan Problem Statement
Susan, a mother who recently moved into her neighborhood, is troubled by the prevalent nepotism in her HOA. She believes this favoritism impedes fair resource distribution and policy implementation. Susan is seeking more transparency and community input, she wants for a system that ensures official accountability and fosters open dialogue. Susan wants a platform that empowers members like her to actively engage in their HOA process.
PERSONA 3 | Out of touch with the community |
Age: 42, Eduction: Bachelor's in Social Work, Home town: Oakland, CA, Family: Married with 3 kids, Occupation: Elementary School Teacher | |
Problem statement | Karen, a mother and teacher, is upset with her condo association's neglect of the local park, which is crucial for the community's children. She seeks a prompt solution for its upgrade. |
“Our condo association is our of touch and has lots of anti-child oriented rules and regulations that result in unnecessary fines.” |
Karen Problem Statement
Karen, a dedicated mother and teacher, is frustrated with her condo association's insensitivity towards the needs of the many children in their community. Rules around kids' toys being left in yards result in silly fines if not picked up. She needs a voice for her children so they can have fun in her community without having to fear being pushed out by heavy fines or liens on her property.
PERSONA 4 | Not time to fight |
Age: 45, Eduction: Bachelor's Degree in Business Administration, Home town: San Diego, CA, Family: Single, Occupation: Disability Rights Advocate. | |
Problem statement | John, an active community member using a wheelchair, tried joining his condo's board. Despite constant resistance and time waste, he seeks a solution for fair participation and accessibility in community decisions. |
"I spent a year showing up to get on the board of our condo, but leadership is locked in, so I gave up. It was a time-suck." |
John Problem Statement
John, an active community member using a wheelchair gets along with almost everyone, tried getting on his community board. However, he encountered resistance from those in power. This discouraging and time-consuming made him realize he needed fairer solution where he didn’t have to attend ever meeting in person. John desires equal participation in community decisions and emphasizes accessibility.
The user journey
User journey map
ACTION | Join meeting | Listening | Sharing | Proposing | Voting |
Task list | •Schedule. • Showing up. •Listen. •Share. •Repeat. | •Sign up to share. •Wait in line. •Stand at podium. •Deal with distractions. •Answer questions. | •Mind timer. •Speak introduction, core speech. •Request support of board or other members. | •Preset issue to vote on. •Voicing support/opposition to items. | •Propose projects. •Propose budgets for projects. •Follow up on budgeted projects. |
Feeling (Adjectives) | •OK. •Wondering. •Scared | •Excited. •Unfamiliar and Familiar. •Bored. | •Combative. •Ignored. •Alone. •Unsupported. •Disliked | •Confused. •Unsure of support. •Alone. | •Ignored. •Hated. •Nuisance. •Angry. •Hopeless. |
Improvement Opportunities | •Create welcome committee. •Train up front for what to expect. | •Clarify structure in advance. •Put structure on screen with progress. | •Smaller committees to detailed ideas to engaged members. | •Get feedback early and up front rather than wait until too late. | •Transparent online process of voting and logging rather than roll call. |
Takeaway
- New members come into communities with a large range of emotions including excitement, fear, dread, confusion, and disappointment.
- Making the process easy would increase participation and improve the community overall.
- Existing members can set the tone for those who come on board.
The User Journey
All the persona pain points we discovered were problems we were committed to solving through participation in Psinq. By removing the blockchain security, eliminating onboarding hurdles, and focusing on the actual meeting experience itself with the added benefit of rank ordering, We hoped to address the pain points, if users felt comfortable using it.
Simplified user flow WITHOUT a blockchain:
User Task: Open the application.
User Task: Log in.
User Task: Navigate to the meeting schedule.
User Task: Join a meeting.
User Task: Share contributions.
User Task: Rank participants in the meeting.
User Task: Complete the meeting.
User Task: Return to the home screen.
User Task: View ranking from the meeting.
Meeting user flow diagram
The user flow diagram is relatively simple, which is beneficial. The rank ordering feature might be a significant issue for users due to the human components involved.
Starting the design
- Paper wireframes
- Digital wireframes
- Low-fidelity mockup & prototype
- Usability studies
Paper Wireframes
- Given our team's previous experience with the EdenOnEOS service, paper wireframes were considered unnecessary for this project.
Digital Wireframes
- Similarly, our prior team experience with Eden moved us beyond digital wireframes.
Early Low-Fi mockups and prototypes
In collaboration with the engineering team, I built the structure for rapid iteration in Low-Fidelity responsive mockups.
Lo-Fi meeting & ranking views mockups
We began with a Mobile first approach because it focused our attention on the key feature-Ranking.
- Icons and ranking details were mocked up and at times blank green squares (on the right).
- Early designs incorporated Fractally's branding elements, such as the hexagonal profile images (To the left of each user name).
- Early designs incorporated layouts with ranking numbering levels systems (on the left)
Ranking component
This component was the most challenging to make user friendly. Each member displayed lots of key data in the member card, including:
- Rank
- Name
- Group
- Consensus
- Grab-icon
1) Mobile frames
2) Desktop frames
3) Responsive frame sequence we could play with in Figma
Challenge: Displaying Consensus
Achieving and displaying rank-order consensus of two-thirds +1 members led to discontent in earlier tests.
Replacing Human Consensus with Mathematical Consensus!
Experiencing the discontent in meetings personally led James Mart, one of our brilliant blockchain developers, to author a white paper solution addressing this problem. He eliminated the human consensus agreement requirement while allowing member intent to be captured, providing a consensus result. No more fighting in meetings.
Designing the rank-order sequence
This allowed me to employ a reductive design approach to rank ordering.
- All users begin without rank.
- All users rank all the other users.
- All users submit their ranks anonymously in the meeting.
- Results are averaged over time.
Conclusion
Lo-Fi mockups and prototypes revealed the discontent issue of 2/3 +1 agreement.
- Making voting real-time and public distorted outcomes.
- Forced consensus created unnecessary friction.
Final Design
Hi-Fi Rank-Order Mockup
The following marketing images show how simple the final process looks:
- Meet on video.
- Rank the members in your group and submit.
- Talk and form relationships before departing.
Final Mobile and Desktop Meeting Views
The ranking process still involved starting with nobody in a ranked position. Each member had to be dragged into the rank area, then arranged in order of preference.
Chat was provided as a tab item so that all members could share information without interrupting the speech of others or in the event of loss of audio or loud background noise.
Responsive Mobile and Desktop Views
With designs tested, I created responsive layouts for different breakpoints. Mobile views could only show rank ordering or chat. Simultaneously viewing chat and rank ordering was possible on desktop and tablet views, leading to discussions about enlarging video windows and allowing chat with rank ordering.
Interaction Design Details
Every user starts in an "unranked" state. To assist newcomers in understanding the rank-ordering process, I designed interaction highlights. This feature quickly teaches users how to execute the action. To rank members, users simply select a member. This action causes both the selected item and its potential placement to highlight and pulse in a matching color.
Detailed Hi-Fi Prototypes
- Responsive web application
- Simplify for development
- Ensure high legibility
- Accessibility:
- Make it compatible with screen readers.
- Consider speech-to-text over video in the future.
- Use of icons support future localization.
Whole application design
Using the design system I designed responsive community views and more.
Linking the whole app for testing
Having a broader view of the application helped us better understand the flow asynchronously, improve user empathy, and identify anything that could distract from meetings.
Whole app prototype Usability Notes - abbreviated summary discovery
A summary of general findings from user testing.
Task | Click Path | Observations | Quotes | Task Completion |
Task Directions | Record what path the participant took to complete the task. | Note down behaviors, opinions, and attitudes along with any errors, issues, or areas of confusion. | Note any significant quotes (positive and negative). | Choose if the task was: 1. easy to complete, 2. completed but with difficulty. 3. not completed |
Prompt 1: If I said "Lets Psinq up our community organization," what do you think you might use to get this done? | Participant opened the Psinq app and navigated to the Psinq up weekly meeting. | Participant found the feature quickly and without guidance. | "I found it." | 2 - User didn’t understand what “Psinq up” meant, but then found the menu and wen there. But was unsure of the action to be taken. |
Prompt 2: Lets say you wanted to rank the other members in the meeting. What would you do? | Participant moved participants from the un-ranked area to the ranked area. | Participant hesitated and then moved the members successfully | "So how do I rank?” “I see, there is a ranked area.” “That’s easy.” | 1 - A bit hesitant because was unsure how ranking worked, then tried dragging and it worked easily. |
Prompt 3: Lets say you ranked the members, how do you complete it? | Participant clicked the Submit button and remained on the page. Changed the order and submitted again. | User was surprised that he/she could submit the rank again. User submitted more than once. | "Why can I submit multiple times?." | 1 - user completed with ease and submitted multiple times before the end of the meeting. |
Prompt 5: How do you think you'd improve psinq rank order feature? | N/A | Participant wanted to know why they could submit multiple times. | "I did not want anyone voting more than once. Then I realized it meant I could change my vote, which is good." | N/A |
Discovery:Add a dialog explaining to use that a rank had been submitted. Add that the rank can be updated at any time up until the end of the meeting, and that only one final rank will be submitted by each member for the meting.
Whole app design system
During the design process I created a comprehensive design system in Figma
The design system included eight core elements and thirty-five complex components, ensuring consistency and efficiency. The project's success was confirmed through user testing, which showed that users could easily navigate the voting system and participate in meetings. The project highlights the value of UX design in simplifying complex processes and enhancing user participation.
Color and Typography
The Psinq color system works for branding, alerts, grays, and neutral colors, with a complementary palette for Psinq's marketing design and illustrations.
Font sizes and weights for the application, website, and related components provide balanced readability and impact for display text, headings, paragraph text, and a monospace font for stacked data.
Icons and “Avacons”
My "Avacon" designs served as avatar-icon hybrids adaptable across all platforms and contexts, including social media profiles, gaming characters, or user interfaces.
Buttons, badges, and dropdown styles
These parts of the design system came in many colors and sizes for different design needs. They could switch between dark and light modes, making them easier to use and see.
Creating Unity On All Devices
♾️
After dozens of meetings with hundreds of community members, we discovered that 1) rank-ordering was the that brought communities together, and 2) sharing contributions and and meeting together on video united the community.
The final Responsive UI
Final Desktop views
The desktop views are displayed in various breakpoints for wider views, tablet views, and phone views.
Final Mobile views
Conclusion
Listening to user concerns about discontent led to a better rank-ordering system.
Including design, management, and developers in test sessions created opportunities for user empathy among all stakeholders, resulting in significant usability enhancements. The final solution aligned with Dan Larimer's book, "More Equal Animals," simplifying a complex set of processes into a very user-friendly experience, highlighting the value of genuine cross-functional teamwork.
©2024 Thomas Hallgren