Despite the growing appreciation for iterative design, it’s still not common practice for companies to bring design to the table at the inception of product development. Alethio, however, is an organization with broad views and an ambitious goal and has embraced the design thinking process from the earliest stages of development.

Starting in 2019, we’ve been building products with input from data gathered during robust user testing and surveying. Our approach started with getting to know our target audiences. As we interviewed, surveyed, gathered data on, and listened to real users, we realized we did not know them nor their needs quite as well as we had assumed. After that realization, we’ve conducted ourselves and our development at Alethio as user-centric as possible.

We’re following an iterative design process based on the principles of the double diamond — Discover, Define, Develop, and Deliver.

The Double Diamond Design Process

1. Discover

We started with some gut feelings about what we observed from the market analysis. Our general conclusion was that other products in the market lacked capabilities, but users wouldn’t or couldn’t specify what they needed. Typically, users don’t even realize they need something until you show it to them. With this in mind, we started to work on our lean UX canvas and populate it with the users’ needs. At first, we worked off pure assumptions. After a short time, we began gathering data inside our network and conducting real robust user research and 1-on-1 interviews with real users.

We conducted both quantitative studies (~70 survey responses) and qualitative studies (8 in-depth user interviews).

Dan The dApp developer — our main persona

2. Definition

After gathering the data from our research, we compiled all the information and started to define the problems our users were confronting. We built User Personas and Empathy Maps in order for us to develop empathy for our users and get inside their minds. This helped us critique our product from our users’ perspective instead of continuing to rely on our bias assumptions as the developers.

The Empathy Map we built

3. Develop

After compiling our research data, a robust MVP for our Monitoring product was built. Having a strong infrastructure has allowed us to build on top of our data pipeline and enable alerting, monitoring, and reporting capabilities in a blockchain environment.

The MVP was built on the following premises:

• Our target users, dApp developers, need to monitor their smart contracts for their day to day work.
• There is no such capability developed yet.
• They need to customize the alerts they set for their smart contracts and accounts.
• The need for different channels for real-time alerts other than just email.

4. Deliver

Based on our research and our business canvas, we concluded that our main persona representing our target audience was Dan the dApp developer. Based on this, we defined some profile characteristics that future user testers should have in order to bring value to our research:

• Have an experience of more than 6 months as dApp developer.
• Has been working on a dApp or, preferably, has launched a livedApp.
• Builds on the Ethereum network. This was a mandatory characteristic.

We reached over 200 individuals, of which 70 were eligible for User Testing. We used private database and user testing platforms like respondent.io and The Bounties Network to make sure we were interviewing people who we didn’t know, and who were not already familiar with our products.

Of the 70 selected participants, we interviewed 8 people who were outside of our network and had never heard of Alethio before. They were dApp developers from the US, UK, Romania, Portugal, Turkey, and India, and ranged from 23 and 45 years old.

What we wanted to know for our Monitoring Product:

What is needed from a blockchain monitoring tool in order for users to get the most value?

What are the daily monitoring needs?

What would stop them to use the Alethio Monitoring?

What user context is important for shaping our products?

What we learned

All our findings after the User Test Interviews gathered in a Mural

Here are a few key takeaways from our research:

• Developers who write Smart Contracts are more sensitive to tools which would allow them to be more productive, write less code, create code with fewer bugs, help them debug easier, and have automated processes.
• Because testing on local testnets is tiring manual labour, they would be interested in something that would save them from toiling, lift the burden of constantly thinking outside the box, and allow them to be super creative.
• The software on the market which was usually used by the testers does not allow users to extract the output into something more usable and none of them generates analytics, charts, or graphics. A reporting feature right on the dashboard seems to be a thing which all of the users agree they would definitely need and love. They wouldn’t pay right now only for an alerting feature, which most of them feel like they could build it themselves.
• The need to be alerted in real-time is quite stringent amongst dApp developers. The possibility of being alerted via webhooks made people very excited.
• All of the users wanted to be able to monitor Ether and ERC20 tokens at the same time. When adding an address, some validation is expected whether the hash is actually a wallet address or a smart contract.
• When contemplating the possibility of a dashboard with multiple alerts, some of the users stated that overcomplicating the management alerts could be a potential dealbreaker. Some of them would like an option to re-order or re-organize their alerts. Mostly, they think it looks good, but testing lots of contracts might mean needing to have sort of a folder management (e.g. if working across different dApps).

“I struggled a bit with a “threshold” [an input field in the interface]. But after I read the tool tips, it was clear what happens there. “ (a user quote)

Following our research, we have implemented updates in order to meet the needs and requests our users have stated:

• We have created a better UI for our product.
• We have signalised better differences between assets — holdings and on-chain activity.
• We have created a better flow for the setup forms, making them easier and more intuitive.
• We’ve built a mobile version for our site since a lot of users come from mobile devices.
• We’ve created a more organized dashboard so information is presented neatly and bucketed.

“ This is absolutely a higher level, it will help a lot if you are managing lots of contracts.“ (a user quote)

Empty State for our Monitoring Product

Some tips for your own user testing:

• Gather your team’s assumptions and research needs beforehand, to help shape your research plan.
• Use a platform like respondent.io to find unbiased, external people to talk to. Five to six is a good starting number.
• Don’t ask people what they want, find out what their needs and problems are and build to solve those.
• Get every member of your team to observe at least one research session, to build a closer understanding of the problems for real users
• Map your recommendations against development effort and user impact, to determine what changes should be prioritized first.
• Make those changes, and test again.

At Alethio, we are committed to continual product updates and user testing, because we know how powerful this process is for getting us from A to B in the fastest time. Doing user research has saved us a lot of headaches and we’re proud of what we have built, but we always want more feedback — so contact us and tell us your opinion.

Check the Monitoring product here: https://company.aleth.io/blockchain-monitoring