Improving Polkadot's User Experience: Introducing Braille

Hey Polkadot fam!
We are starting an initiative to help improve the user experience of Polkadot’s Ecosystem.
We would love your thoughts and feedback!


:thinking: The Issue: The Need for Intuitive User Interfaces

“I will never fully understand it, but give me a user interface that I can use and tell me everyone is using it.”

“As developers, we have to remember that there is a user who doesn’t know about the development.”

These quotes, extracted from the active brand research, highlight the critical need for simplicity and intuitiveness in UX/UI.

While we see continuous expansion on development initiatives within the Polkadot ecosystem, a significant challenge remains: the lack of intuitive user interfaces.

We have an opportunity here to attract more developers and everyday users by simplifying the experiences we are offering.


:technologist: Who Are We?

Braille is a team of UX/UI experts on a mission to make Polkadot’s Ecosystem more approachable and intuitive.

Core Team

Our core team is composed of 3 Parity people:

  • Michel - Product Design Lead
  • Benoit - Program Manager
  • Alex - End Users Campaign Manager

Together, we bring over 10 years of diverse experience in Product Design and Management, spanning various industries from banking to Web3, passing by retail.

Ecosystem Agents Pool

Alongside our core team, we collaborate with ecosystem agents to cover every aspect of the user experience.

They are experts in their fields: UX Designers, UX Engineers, Front-End Developers, Brand Designers, Data Analysts, Product Managers and UX Copy Writers.


:bulb: Braille’s Comprehensive Solutions

We’ve crafted two packages, each tailored to effectively address the current needs and future growth of the Polkadot ecosystem.

Package 1: End-To-End Solution

This package focuses on immediate, actionable improvements for projects:

  • :male_detective: Usability Audits: In-depth evaluations to identify UX challenges, complete with actionable recommendations and wireframes.
  • :hammer_and_wrench: Implementations: Rapid deployment of our recommendations to enhance user experience without disrupting projects’ roadmap.
  • :arrows_counterclockwise: Continuous Follow-Ups: Iterative improvements to keep dApps user-friendly and up-to-date.

Package 2: Common Good Design Standards

Designed to nurture and solidify the Polkadot ecosystem:

  • :books: Design Library: A collaborative, comprehensive and evolving library of UI components, best practices, and standards to establish Polkadot’s UX Mental Model.
  • :speaking_head: Community Coordination: Facilitating ecosystem-wide discussions to unify and elevate UX/UI standards.
  • :brain: Thought Leadership: Pioneering insights through publications, events, and educational initiatives, focusing on user-centric design in Web3.


:world_map: Our Roadmap

Key points:

Funding:

  • We are applying to the W3F Decentralized Futures grant to support our first year and focus on the DeFi vertical.
  • In the future, we want to leverage decentralized mechanisms to keep pushing our vision on other verticals (NFTs, Gaming, etc.).
  • The goal of our approach is to redistribute the value of the grant/treasury proposals by offering solutions free of charge for the project.

Package 1:

  • What the heck is Unification of ecosystem experiences?
    Polkadot’s dapps and protocols should offer an unified experience to the users. That doesn’t mean they can’t offer different features, but fragmented experiences is a lose-lose situation for everyone.
  • We are not DeFi-centric. We’ll expand to other verticals later. However, we have to start somewhere, and DeFi is a low hanging fruit that fits perfectly our approach.

Package 2:

  • We are confident that our work and the Common Good Design Library will benefit the projects and the ecosystem. Hence why, we are aiming for 70-100% of the current dapps in the ecosystem to be onboarded with UX/UI Standards after year 3.
  • Finally, we foresee great engagement with the community. The natural evolution will be to create a DAO to keep pushing this initiative.


:handshake: Partners

We are not naive — UX & UI on its own won’t solve all the problems to gain mass adoption.

It’s only with a mix of good tech, nice experience and great marketing that we’ll achieve amazing results.

This is the reason why we plan to bridge efforts with other ecosystem initiatives to offer a full range of expertises for the community.


:raised_hands: How You Can Help

We welcome your thoughts on this initiative! Some questions for the community:

Helping us:

  • Who wants to answer a survey? 4 min of your time to get your sentiment on Polkadot and its experience. Fill it our here → Help Us Improve Polkadot User Experience
  • Focus Verticals: Which areas should we prioritize after DeFi? NFTs, Gaming, others? Let us know!

Helping your project:

  • Most Valuable Resources: What would help you most in UX improvements - detailed documentation, design libraries, or something else?
  • Interest in Usability Audits: Would you consider a usability audit for your project, especially if supported by grants? Reach out on telegram

Helping the ecosystem:

General:

  • Feedback on Our Approach: Any concerns or suggestions to make this initiative better? Let us know your perspectives below!




Thanks for your time. :pray:

Braille team

21 Likes

Polkadot’s dapps and protocols should offer an unified experience to the users.

Are you referring to the few applications users can interact with on relay chain/system chains, such as staking, crowd loans and voting? I feel like creating a unifying UI for 3 apps is slight overkill. Are you referring to the apps on parachains themselves? Those probably want their own UX/UI.

Overall your approach seems a bit generic to me as you didn’t really take into account how Polkadot works: users mostly interact with parachains. Polkadot has no business telling parachhains what UI to use. E.g. MeWe.com

Hi @cpiccard ! Thank you for your feedback :slightly_smiling_face:

When referring to Polkadot’s dapps and protocols, we mean dapps built on top of parachains, and to start with particularly DeFi offerings — sorry for the confusion!

I didn’t go in detail in the post as I didn’t want to flood the other information with this point.

Let me give you an example of what I mean by unifying the experience.

The experience of liquid staking derivatives (LSD)

The DOT LSD landscape today is very fragmented. What does it mean?
You can do liquid staking on Bifrost, Acala, Taiga, StellaSwap, Equilibrium, and more.

All those platforms are proposing almost the same product to the end user: to liquify your staked DOT. Yet, they are all explaining it differently with different jargon and a different UX.

You can see in this example, none of the protocols are using the same interface. The experience is also different.

That means the user need to relearn every time he’s using a new protocol.
This is not a user friendly experience we are proposing as an ecosystem.

Of course every parachain or dapp is free to choose their UX/UI. We simply offer a set of components informed by best practices which can be easily modified or customized.

Finally, as you mention MeWe, it’s a great example to prove our point. They are using a standardized social media UI: a right and left side bar, with a middle field where you have all the informations.

They are innovating in the approach and with new functionalities, but their UI is generic to any other social media.

Hope this give you more detail about our approach :slight_smile:

Happy to chat about it!
Alex

5 Likes

Thank you for the clarification. I agree users and the ecosystem overall would benefit from a homogeneous look and UX. However, there is no way to force parachains/dApps to use a your Design Library.

Have you considered talking to them? Is the assumption / expectation that parachains / dapps will just use the Design Library provided?

One issue is, that several parachains and dApps operate on more than one chain. For instance moonwell is deployed on Moonbeam and Base. And Moonwell should look the same no matter on which chain customers are.

We are already talking with some teams in the ecosystem. Our goal is not to deliver another library in the sea that nobody uses.

We’ll onboard projects on this initiative by creating working groups. Hence why we are calling it a collaborative and evolving library — engaging the projects is the priority because this library is for them.

Finally, your last point is totally legit. We need to be aware of what’s happening beyond Polkadot’s ecosystem.

Working on Polkadot experiences doesn’t have to be too far from an EVM experience.
At the end, this is how a multichain experience should look like.

I do like this initiative on the surface, but I to be realistic and echo @cpiccard 's concerns. Really starting from the ground up thinking who actually needs this etc. seems like something that is not yet fully grounded. If polkadot is to be a chain of chains, an initiative like this needs a way broader scope.

Maybe a suggestion here could here could be to take a more concentrated approach:
Suggestion A - Only focus on system parachains and dApps on them. This is the Cosmos style approach.
Suggestion B - Do a pull instead of push model. Offer discounted services to polkadot builders, based on requests. Like how Arbitrum is contracting service providers on retainer.

Thanks for the feedback @JoakimEQ!

Our initiative is to first provide real use case for the ecosystem and prove our statement that an optimized UX/UI not only retain users & create value for the dapps, but also, improve the sentiment about Polkadot in general.

Having a broader scope is good for the long term, however in practice, we all know that it refrains from acting.

What we propose is to have an agile approach to test our assumptions and validate them with projects before rolling it wider.

About your suggestions — we are confident we can do both, with A evolving into B.

”Suggestion A - Only focus on system parachains and dApps on them. This is the Cosmos style approach.”

That’s our approach but more “vertical centric”. For the first year, we will focus on the DeFi vertical.

“Suggestion B - Do a pull instead of push model. Offer discounted services to polkadot builders, based on requests. Like how Arbitrum is contracting service providers on retainer.”

That’s also our goal, we just need to start somewhere, so we “pushed” it in the first place to start building use cases.
Later, the idea is to offer our services (pull) to other projects in other vertical (still free of charge for them) and using decentralized funding mechanism like treasury proposal.

1 Like

Hi everyone,

@Alex_Houdz - I could not agree more with “The Issue” statement. In my opinion real adoption does not happen without clean and intuitive UI. This problem plagues all ecosystems and blockchain space in general. It is important to resolve if Web3 space wants to take meaningful steps forward.

Although I do not see one-size-fits-all approach working when it comes to UI, I do think that there could be “unified” approach to auditing, testing and best practices.

All in all, UI is definitely a topic worth considering. Keep it going :muscle:

P.S. For anyone interested in having a read on the topic, I’d like to recommend a few great reads:

  • “Don’t Make Me Think” by Steve Krug : This book is a classic in the field of UX design, emphasizing the importance of simplicity and usability in web design.

  • “Hooked: How to Build Habit-Forming Products” by Nir Eyal : This book delves into the psychology behind building products that users engage with repeatedly, emphasizing the importance of creating products that form habits.

  • “Lean UX: Designing Great Products with Agile Teams” by Jeff Gothelf and Josh Seiden : It discusses integrating UX design principles within agile development processes, emphasizing collaboration and iteration.

  • “Design for Hackers: Reverse Engineering Beauty” by David Kadavy : Geared towards developers and engineers entering design, this book explains design principles and techniques in a way that’s accessible and practical.

4 Likes

Hi Braille!

I’ve been a UI/UX Software Engineer for most of my career and while I agree with the problem I don’t understand most of your solution specially regarding package 2.

Is there a place I could learn more about it? I fail to see how your proposed solutions benefit the ecosystem or are even feasible to implement in some cases.

Thank you,
Mia

Hi @Miami, thank you for your question!
Here is our Deck if you want more details :blush:

To respond specifically to your points above, our package 1 is a normal process in any product team: you audit, you implement and you iterate by doing follow ups.

Our 2 package is a way for us to share it with the ecosystem and ensure UX/UI topics are in the discussions. It’s composed of 3 deliverables:

  • The design library that will be populated with our learnings from working with different teams in the ecosystem (protocols & wallets). Standards components would be added there like tx notifications, wallet connection or fees presentation. The list is long, but the idea is to establish a mental model for the ecosystem with good practices and simple components to avoid reinventing the wheel every time. It will also help the offering a seamless experience for all users using dapps on Polkadot’s Ecosystem.

  • Community coordination is self explanatory. If we want to raise the bar of UX/UI, we need to ensure discussions are happening. By facilitating those talks, we believe teams will be more engaged. It’s always easier to come in a group and give your opinion, rather than starting from scratch. The “community” as we see it would be a UX/UI forum category (better than the current existing), a TG group and a newsletter. By being present in the ecosystem and identified as coordinators, we’re facilitating the adoption of the design library too — a way to avoid having another unused library in the sea.

  • Thought leadership is finally what pushes the two points above in front of everyone’s eyes. We are aware that great things need some communication to be seen inside and outside Polkadot. This is what we propose here. We’ll attend Polkadot events (Decoded, sub0, PBA and more) to push the vision and engage discussion for a better experience in the ecosystem, and we’ll also participate to non-Polkadot centric events to share and defend the voice of Polkadot.

Hope it clarifies your concerns :slightly_smiling_face:

Don’t hesitate if you have more questions!

Thanks for the pitch deck! It helped at understanding your post further. Specifically about the library being Web3 focused components instead of just yet another React component library (inputs, buttons, etc etc).

I see the value now with the extra detail. Thanks again.

1 Like

Is anyone on your team actually building these things out? If not, you’re effectively going to design stuff in Figma and just say “Okay, now you figure it out, parachain frontend developer!” What is the point of standardization if it doesn’t create less work? Then you’re sacrificing freedom for no reason.

Hi @Noah! Thanks for your question :slight_smile:

We agree that an audit alone can be another documentation and might be never implemented by the project due to a full backlog or no time/resources to implement them — we saw it happening several time in our previous experiences.

It’s exactly why we are providing implementations in our offer, in case the teams need an extra help.

Our goal is not to work in our corner, share it to the teams and never come back.

We are building a relationship.

We’ll never do an audit without ensuring the implementations are made just after with the team’s resources, or ours directly.

Regarding standardization, we also agree that this is important on the developer side — that’s why we want to engage multiple projects in the loop before creating anything.
But again, we’re talking about the user experience here, and we want to make sure users don’t discover an all new experience each time they land on a Polkadot dapps (experience =/= feature here, we’re talking about key actions that are harmonized like swaping, bridging, minting, etc.)

Happy to talk more about it :slight_smile:

It’s exactly why we are providing implementations in our offer, in case the teams need an extra help.

Yes, what does an implementation look like?

Re Noah, here’s a breakdown of how an implementation would like :slight_smile:

  1. One of our front-end devs will already be looped in (during the audit phase) while we start designing recommendations to make sure whatever we suggest is feasible to build.

  2. We align with the project whether they want to go ahead with the recommendations and then enter the implementation phase.

  3. Together with our dev we break down our recommendations in prioritised issues and then begin implementing.

Happy to jump on a call to discuss in depth our approach & processes if you want :slight_smile:

No, that’s exactly what I was hoping to hear. Sounds like a valuable addition to the ecosystem.

2 Likes

Great post and very nice slides! I think it would be a great value add to have a much leaner team working to align and bring a standard to UI across the eco - good to see this initiative!

2 Likes

Thanks for posting this proposal. There appears to be some crossovers between Braille and Polkadot Cloud (Decentralized Futures Proposal: Polkadot Cloud).

It might be beneficial to explore how the 2 projects can collaborate as to not duplicate efforts.

3 Likes

Hey all! Quick update from Braille’s team :slight_smile:

We hosted a workshop at sub0 Bangkok on UX Standards for the ecosystem where we had many great discussion on how to tackle this challenge.

You can find the details, restitution and next steps here.

We are super excited to see our vision shared by other great minds.
Stay tuned, it’s only the start!

PS: if you want to participate in the discussion :point_right: join us in this TG group.

2 Likes

gm all!

We just announced the formation of the Polkadot UX Collective :partying_face:

1 Like