DAO Voting App Design
This week, we focus on the second stage of the DAO selection and voting process. (Here is part one)
Last week, we dealt with the selection of the proposals that will go forward for a vote from the DAO community. The thinking is that we need to present the information contained in the proposal to the prospective voter in a way that will enable them to make an informed decision with their vote.
The challenge is how we present this text-heavy information in a way that works on mobile devices and maintains the user's engagement through the act of voting.
The image below was the first draft of the list of proposals as cards. The bottom of each card is a link to more text and information and a link to the comments with a total of the comments on this proposal. The thinking is, that the user will easily see is there has been much discussion around this proposal.
The next image is the card that the user will see if they click the “more” link in the selection of cards above.
I added some fields for estimates of effort, duration and area of impact.
On the voting influence, I was offering the user the option to apply some, or all, of their influence score. This was an error; I had forgotten that we had agreed to make it binary. The user can only apply all of their score or “weight” to the vote, or none.
In this version, I was thinking of a proposal for a new insertion into the rules. The main body shows the title and description along with the actual new text for insertion.
The thinking on the horizontal bar is, it is easy to see the engagement from the community. The icon on the left is the creator's profile thumbnail and the date the proposal was created. Next is the time elapsed since the last reply or comment, followed by the number of replies and the number of people that have viewed the proposal. Finally, we have the number of likes the proposal received during the selection phase.
This is the same information as the one above; the only difference is that the two fields show replacement text where the proposer is trying to change something. It is a side-by-side comparison of the old and the new or existing text and the proposed replacement.
This is the actual voting page. It shows a few things:
More information on the actual TIP being voted on
Whether the current number of voters has reached a quorum, or not
In a pie chart, the ratio and percentage of users voting, companies voting and if TIKI voted, or not
Your influence score as a number
Two buttons to vote on this TIP, or not
I have started to look at the information in sections and the sequencing of said information. Logically, my thinking is that the information must be present to enable an informed decision.
The basic information at the top gives you the reason the proposer is seeking the change.
Below that is the engagement within the community.
Next is the actual change or addition.
Then you see the status of the proposal in terms of the votes and voting.
Next is the actual voting button. You can see your influence score at the time of your vote for this proposal.
The logic is that you are more informed as you move down the app and are fully informed about the community engagement and the proposal details before you vote.
This is a continuation of the page above where the comments are listed in chronological order down the page.
In line with the thinking in a more modular way, I have started to think about the specific modules rather than the whole flow, as it is probably too much.
I was researching ways to display information, and I found this method called “lollipop” sticks. I have 3 different groups that will carry an unequal weighting, but they are needed to achieve a “pass” or weighted goal. This is a nice and elegant way to display the actual number and its relativity to other numbers.
We have made a decision to move from using my Picasso-like sketches and sharing them as DMs on Discord to GitHub, where the progressions can be shared for the world to see. It should be easier to track the progressions in a more dev-type way. (Here is a link to the GitHub issues)
This is the updated status section to provide a snapshot of the proposal and its status in terms of passing or not, and the voting engagement of the other groups.
You can easily see if it will pass or not and whether a quorum has been achieved.
This will prompt the user to vote or not.
This was my thinking on the flow of the app:
A. It’s a list of the rules and regs at that time.
B. The icon allows the user to change the existing rules or insert a new section.
C. Presents the rules as links when the user can amend them.
D. Is a pre-populated proposal where the user needs to add the new wording and the reasoning for the change.
E. Is the current rules
F. Is a pre-populated proposal where the user needs to add where they want to insert the new section and the reasoning for the change.
This is the comparison of the existing form of words in the rules. We figured there is not enough room on a mobile device to read them side by side but rather above and below.
In conclusion, this week the focus was on the second stage of the DAO selection and voting process. The challenge was to present text-heavy information in a way that works on mobile and maintains user engagement. A draft of the list of proposals was created as cards with links to more text and information, as well as comments and the total number of comments on the proposal. Effort, duration, and area of impact fields were added, but the user's voting influence was changed to be binary, with the option to apply all or none of their score. The voting page displays more information on the TIP being voted on, the quorum status, the ratio and percentage of users and companies voting, and the user's influence score. The information is presented in sections and the sequencing of that information was designed to be logical and informative, with the user becoming more informed as the progress in the workflow of the app. The app's flow and design was shared on Github, and the team decided to use a "lollipop" sticks method to display information and to track progressions in a more dev-type way. This is a key section in the DAO app and needs more work to ensure that we get this right.