The document outlines the UX research and design process for the EOSIO Authenticator app developed by Block.one. It details the project's objectives, actions taken, user research findings, and competitive analysis. Key insights include the importance of understanding user needs, simplifying user flows, and ensuring security in the application. The app aims to improve developers' workflows by providing a seamless signing experience within a dApp browser.
UX Research, Prototyping and Information Architecture Design for The Only EOS Authenticator Released by Block.one
Project Overview
Block.one launched one of the world's most valuable new blockchains in June of 2028. Product development companies encountered the challenge of providing a trusted, user-friendly signing device. Due to security concerns, creating a browser plugin was not a preferred solution. The objective was to develop an application where keys could be securely stored in the iPhone's secure enclave. This would allow dApps to be viewed and securely signed in a browser within the application.
Project duration: 3 Months
Situation
In this rapidly evolving blockchain technology environment, the design and development team needed a way to visualize the application. As the UX Researcher, I was assigned to assist with this task.
Task
Investigate the integration of a signing application with a dApp browser to create a secure and seamless application experience within the browser as a hybrid app.
Action
I engaged in active listening, participated in whiteboard sessions, and led documentation discussions with the CTO. I then created research briefs on feasibility and competitive landscape, including both blockchain and non-blockchain solutions. With this understanding, I began developing UX keyframe views for content and created rapid, low-fidelity, then high-fidelity prototypes to test usability assumptions. I developed usability prototypes that demonstrated high usability and viability to the blockchain technology and development teams.
Result
The app front-end, security, and blockchain engineering teams utilized my app concept and user flow, leading to the creation of a new product: the EOSIO Authenticator app for iOS. This app was initially released to the EOSIO blockchain developer community as an open-source project in early 2019 and later launched on the Apple AppStore by the community.
My role
Lead UX Designer
My Responsibilities
Research, wire framing, design, prototyping
Understanding the user
• User research
• Personas
• Problem statements
User research
User Research: Summary
In order to better understand user needs, I interviewed individuals who use blockchain applications. This was done to identify their preferences and to uncover any issues they encounter.
User research pain points
1 | Cumbersome | “Saving a long passwords or passphrase makes if feel cumbersome.” |
2 | New and unsure | "Every new blockchain makes me worried that I’m going to make a major mistake and lose my account and tokens." |
3 | Insecure | “Offering too much leads to less security.” “Let’s just provide the key.” |
4 | Slow | “Blockchain apps are slow” |
Personas
Persona 1 | A blockchain game player wants to play EOS dice and sign transactions more quickly. |
Age: 21, Eduction: bachelors, Home town: Roanoke, VA, Family: single, Occupation: Designer | |
Problem statement | William, a busy construction worker, receives medication from his doctor. However, after a coworker shares a negative experience with the same medication, he becomes uncertain. Now, he wants to get a second opinion to put his mind at ease. |
"One of the guys I work with said the medication I take caused problems. I want to get a second opinion after work." |
A journalist and blockchain investor needs to interact quickly and securely with EOS applications to evaluate and document. | ||
Age: 36, Eduction: Bachelor, Home town: Charlotte, NC, Family: Married, Occupation: Journalist & Investor | ||
Problem statement | Susan is a journalist and blockchain investor. She needs to interact with EOS applications quickly and securely to evaluate them for her readers. However, each time she begins using a new application, she feels overwhelmed. It's as if she has to learn a new language each time. The unfamiliarity and complexity leave her worried about the security of her account and the risk of losing her tokens. | |
"Every new blockchain makes me worried that I’m going to make a major mistake and lose my account and tokens." |
Persona 2 | Quick and secure signing application to speed up testing. |
Age: 32, Eduction: Masters Computer Scicnce, Home town: Dallas, TX, Family: Married w/ 2 young children, Occupation: EOS Blockchain Developer | |
Problem statement | Mark, busy iOS developer, is developing blockchain applications and needs to test often. He needs something to open and test quickly on iOS. He uses 3rd party applications that seem to work fine, but he needs something that is more efficient and direct. |
"I need a fast, simple signing app I can trust.” |
Discovery
Usability Problems
Our customers and their patients appreciate our simple "See a Doctor Now" feature. However, it currently feels like an ER visit, offering no choice of doctor. To make the experience more patient-friendly and to honor our commitment to our clinic customers, we've decided to add a scheduling component. The challenge lies in determining which calendaring system to use, and how to ensure it is as user-friendly and straightforward as our "See a Doctor Now" feature.
User flows are known and comparatively simple.
The user process from application download to the final report involves only 10 steps, which is considered excellent.
- Open a browser application
- Choose to sign into the application
- Agree to sign with the EOSIO Signing application
- Display the EOS Signing sign-in page
- Confirm your account on the application
- Sign in
- Return to the application in the browser
- Confirm you're signed in
Paper Prototypes
We built and tested Paper prototype in coffee shops with developers who helped us to better understand their priorities.
We built and tested a paper prototype in coffee shops with developers. Their insights helped us better understand their priorities.
“I need to test with about 30 different accounts. How can I load all the accounts quickly?”
“I don’t need a friendly application, just something that gets the job done.”
“I want this to be for developers, not consumers. Consumers have other apps, and those apps don’t work for me at all.”
Conclusion
→ From the feedback we received, we concluded that the primary goal of the first version of the application is to improve developers' workflow.
Competitive Review
Competition (Aligned): Doctor on Demand
Recurring visits: My evaluation of Doctor on Demand showed that locating and scheduling a doctor can be a tedious process. The service provides numerous options, including an extensive 8-step onboarding process.
Metamask | Discoveries - Pros | Discoveries - Cons |
Signup | Standard word phrase | Users don’t feel comfortable downloading app to own computer to transact. Risks. |
Use | Has industry standard features and works well for developers working in Solidity. | Has maybe too many features that consumers don’t want. More oriented for developers. |
Openness | ETH Foundation. Fully open source. Community preference. Aligns with Solidity and Truffle apps. | Open source associated risks |
Platforms | Desktop Mac and PC | Electron |
Security | Industry standard for browser plugin. Password is secured in app by cryptography. | Electron app, which carries risks and has many connections which present risks. |
Metamask | Discoveries - Pros | Discoveries - Cons |
Signup | Standard word phrase | Easy to set up, and easy to lose wordphrase. |
Use | Readily available signing app in browser. | Because always on, results in higher risk of signing bad contract “Drunk signing” risk. |
Openness | Fully open source - preferred by community | Open source associated risks |
Platforms | Desktop Browser Plugin and mobile app. | |
Security | Industry standard for browser plugin. Password is secured in app by cryptography. | All browser plugins carry risks - man in middle attack. Less secure than stand alone app, or hardware wallet. No secure enclave support. |
Trezor | Discoveries - Pros | Discoveries - Cons |
Signup | Good software tutorials | Hardware keys scare consumers |
Use | Functionality high on device | Lots of clicking little buttons |
Openness | No open source associated risk | NOT open source |
Platforms | Mobile & Desktop | Newer models work with bluetooth. |
Security | Industry standard personal cold wallet | Private company, NOT open source |
Trezor | Discoveries - Pros | Discoveries - Cons |
Signup | Easier to use than Ledger | Hardware keys scare consumers |
Use | Easier to use than Ledger | Functionality in related software. |
Openness | Open source | Open source associated risks |
Platforms | Mobile & Desktop | No bluetooth at this time |
Security | SECURE Open source standard | Has associated open source risks |
Exodus | Discoveries - Pros | Discoveries - Cons |
Signup | Easy to use | All tokens reside in same wallet address |
Use | Easy to Swap | Ethereum focused token list. Additional tokens grows slowly. |
Openness | Highly regarded / works with HW keys | Not open source |
Platforms | Mobile & Desktop | |
Security | Uses device and passwords |
Competition (Unaligned):
Not researched
Because security and secure user processes take precedence in the thought process of this application, I focused more on user flows and took the lead form engineering for flow requirements.
Keeping flows simple. Because the application could only be used for signing the user would not be able to purchase tokens to create an account. So a user would need to have an account already to use the app.
iOS Native app user flows with UAL - Universal Authentication Library
User Add account:
- User opens application
- User choses acc using a key for either the owner or active account.
- Owner Key
- Active Key
- User adds Owner or Active Private key
- Application confirms key by finding public associated address(es)
- Chose account user wants to add
- Or multiple accounts to add more than one
- Or add all if user wants to add all accounts associated with the key as owner or active.
- Keys added
- Errors: failed to add (with reason)
- Success message, return to home screen with added keys
User signs into UAL enabled native or web application:
- User opens native or browser application
- User activates action that calls UAL
- Receives dialog asking to open signing application
- User says yes: opens signing applicaiton
- User says no: dialog closes (end)
- UAL signing app opens automatically
- User presented with signing contract
- Reviews contract to be sure it is correct
- User chooses account with which to sign with
- User signs
- Signing takes place
- Error: reason for failure
- Success: Success dialog
- User is automatically returned to home
Technical explanation
Final User Flow Diagrams
Add account to UAL app
Sign contract with UAL app
Learnings:
- Understanding the user's needs and pain points is crucial in designing a user-friendly application and keeping it simple.
- Competitive analysis can provide insights into what works and what doesn't in similar products.
- Paper prototypes are an effective way to get early feedback from users.
- A signing application combined with a dApp browser can create a seamless application and signing experience.
- The primary goal of the first version of the application is to improve developers' workflow.
- User flows should be kept simple for better usability.
- Security and secure user processes are crucial in the design of the application.
- Testing with multiple users can help uncover potential issues and areas for improvement.
- Feedback from users can provide valuable insights and lead to product improvements.
- Incorporating user feedback into design iterations can enhance the final product.
Final Delivery Designs
Thanks!
©2024 Thomas Hallgren