Summary: The goal of this project was for Status.im to take the first steps towards becoming a Decentralised Autonomous Organisation (DAO) by designing the first version of a decentralised voting app (dapp), and to learn through experimentation what’s required to see organic community participation.

My role: I led the design process, from research to implementation, working together with a researcher, a product manager, and an engineer.

The problem

We needed to design a decentralised decision tool flexible enough to allow people to vote on a variety of topics, from naming a new product, to the team’s OKRs for next quarter.

A first proof of concept to test the technology had been built earlier, but we needed to take it to the next level by increasing voter participation and designing the entire experience.

Challenges

While drafting the idea, we discovered that our users were going to face a series of challenges, most of them related to the initial state of the technology we were using.

The biggest challenge was related to the ‘cost’ of voting—a person needs to have tokens available in their wallet to get voting credits, and they also need to have some extra tokens in order to pay for transaction fees, since a vote is considered a transaction.

The next challenge is that a person needs tokens available in their wallet at the time the poll is created in order to vote. Not at the time they find out about the poll or decide to vote. The reason for this is to stop people moving tokens around so they can have multiple votes.

The third challenge was to explain all of this to our users in a transparent and direct way. In a nutshell, if we wanted to increase voters’ participation, we needed to create a system with minimal friction.

Last but not least, the team’s availability and the time for implementation were very limited.

The solution

With all these constraints in mind, we created a first version of the voting dapp, accessible from the decentralised, secure internet (web3); on mobile and desktop devices; and ready to connect with our users’ wallets.

The process to solve the problem

As the lead designer for this project, I was in charge of not only the design outcomes but also the process needed to create them, while involving the right stakeholders in the right stages.

Understanding the problem and defining success

Designing for blockchain applications can be different from what we designers are used to. But since this is still a very development-centric ecosystem, I needed to stick to the best tools we designers have to make a great product, that is implementing a human-centered design approach.

As a first step, we needed to understand the problem we wanted to solve, define who we are building this for and what their needs are. Research was done to define this, including interviews with users and stakeholders. The PM had started the interview process by the time I joined (I generally run interviews together with a PM), but I was able to help him set up a survey that would allow us to define part of the scope for this first version. I also ran a competitive analysis to see what others were doing and to identify opportunities.

From this, we knew our users were going to be Status Contributors (people from the blockchain community), with different profiles (mainly developers and tech enthusiasts).

This app would debut at the Status Hackathon, so we had around 4 weeks to design and execute. We also decided on a number of contributor’s votes to consider this project a success.

Ideation

I started drafting some high-level concepts and flows, presented them to the team so we could discuss the direction, give feedback and evaluate options. Since we were a remote team, we did this using a collaborative board (Miro).

While drawing the different flows, we also started identifying all the potential pain points in the experience.

By now, we knew the scope of the first version, and we decided to prioritise the voting experience (submitting a vote). After asking our users which wallets they kept most of their tokens in, we focused on allowing people to vote using Status Wallet (the mobile app), Ledger (a physical wallet device), and MetaMask (web). Everything else, like creating a poll, see other polls, etc. should be done later.

Low fidelity design

After this initial round of ideas, I needed to visualise them in a more concrete way. For that, I created mockups in low fidelity, without worrying much about the details, making it less scary for the team to participate and give their feedback. At this point, the engineer and the researcher were already involved in the process and aware of the goals and direction we wanted to go.

This type of fidelity is very useful when you need your team to focus on the concepts and the experience more than on the details. It is great for collecting and analysing feedback in the early stages. It is also less scary to everyone involved since anyone can create or modify them.

Another important advantage of this kind of artefact is that it allowed me to produce more options faster and to throw them away easily in case they didn't work.

For me, the preferred tool for creating low-fi mockups was Balsamiq. Although this tool is not collaborative, I stuck the mockups into the canvas for comments and feedback from the team.

After collecting enough internal feedback, I went ahead and started prototyping in high fidelity.

Why not test with users before jumping to hi-fi? I know that it’s ideal, but in this case we had a really tight deadline and resources, so I decided to take a risk and apply users' feedback directly on the prototype. I recommend to (and usually do) test with users and iterate–if needed–before going hi-fi.

Prototype & high fidelity design

For this phase, I used Figma, since it gave me the possibility to design, quickly prototype, receive feedback, and iterate collaboratively.

Test with users & iteration

It was time to get feedback from users. I generally run the usability tests, allocating some time for discovery questions. But since we had the opportunity to test it in-person at a conference full of potential users in Europe, our user researcher helped us by testing the prototype guerrilla-style.  

First I created a quick test plan: what we wanted to learn, the assumptions we wanted to challenge, and other tactical details. I shared it with the team for feedback and from there we started recruiting users for the sessions (using social media and in-person recruiting), running the tests and documenting the findings. After every session (6 sessions in 2 days), we had quick alignment meetings with the researcher and the PM. All the design recommendations were also annotated on Figma.

What did we learn? That we needed to divide the voting process into more digestible steps (good advice for designing any complex process), guiding the user and giving only relevant information during each step.

After a quick iteration on the designs and content, we ended up with a solid version, ready to be built.

Shipping together

The engineer had already started implementing the backbones of the solution based on the initial concepts & feedback while I was designing. During the implementation, I reviewed the progress in different devices and reported any UI bugs or flaws in the experience, prioritising them together with the PM. This back and forth between the PM, the engineer, and myself was done up to the day of the hackathon. It was intense!

The moment of truth!

The day has come, and the voting dapp was live and ready for the Status community to use. The first experiment was to vote on the company’s OKRs. Although we had some bugs that were quickly fixed, the community was able to vote using our application.

Outcomes

• We built the first version of a decentralised tool for democracy. Using this tool, the community decided what they wanted to work on the next quarter.
• Success metrics: We hit the targeted amount of votes and voters.
• Tons of insights and feedback for a second version.

‍