Laws of UX
Rooted in psychological principles, these laws are pertinent to accessibility. We have highlighted the most pertinent currently below, however more exist. Additionally, it is very likely that more connections to dapp designs will be made. This document, as with any document in this reference guide, should be considered dynamic and ever changing.
This is largely based on the work of Jon Yablonski, in his book Laws of UX. His website is also a fantastic resource.
Jakob's Law
Users form existing mental models for technology and interfaces. They will refer to these mental models and if the experience differs it will add cognitive friction to adjust to the new design.
We form patterns, if the pattern is broken there is confusion.
For Web3 this entails leveraging similar web2 flows with added enhancements.
A prime example of this that we recommend is leveraging a standard login button with "connect wallet" embedded as an option in the modal.
Unfortunately the original "connect wallet" button is a not standard flow for newcomers to the space, and breaks jakob's law.
View Our login modal from our staking dapp, the connect wallet button is to the left of the twitter button.
Hick's Law
One aspect is the idea of labelling all icons. In our previous example it would have been better had we labeled the icons instead of relying on iconography alone. For example, often you may see:
Not all icon symbols are universally understood. It is usually better to accompany icons alongside labels. For instance, the heart icon serves sometimes as a Like action or other times as a Favorite selection action. Labeling it per its function removes ambiguity.
A major focus of hick's law is to simplify tasks to reduce complexity. Confirmation screens or step by step guides can be helpful for different transaction types.
Postel's Design
Always leave room for potentially unexpected actions on the user's part.
Accept various inputs
For instance in searching a list of tokens, be willing to accept both the ticker symbol and the full token name.
Mobile/Cross Device Type Driven Design is applicable.
Don't assume users will access your dapp through desktop only, it is actually more likely they will use mobile/tablet based devices as we consider a global view.
A more advanced dapp could consider left-to-right (LTR) and right-to-left (RTL) language scripts formats as languages differ.
See material design documentation for a great reference on this: https://m2.material.io/design/usability/bidirectionality.html#mirroring-layout
Consider supporting as many languages as possible.
Last updated