UX Design for Blockchain and DLT

A simple handbook to help you design better Blockchain and DLT apps for the enterprise.

A cover image for the article "UX Design for Blockchain and DLT"

It’s been a while since my last story but at INDUSTRIA we’ve been quite busy developing a few awesome apps for the financial industry built on Corda. During these journeys, we’ve learned a lot. One of the main lessons is that Blockchain and DLT apps desperately need better UX design.

Test page for an Apache installation on a website

Most of the Blockchain entrepreneurs are ultra intelligent. From a technical perspective they create exceptional solutions, but their UI often looks to me like the default Apache screen from 1998: “It worked!”.

Petko Karamotchev, CEO of INDUSTRIA

At INDUSTRIA we covered what Blockchain and DLT are several times in our articles. Our clients are genuinely fascinated by the capabilities of the technology, but something appears to be missing. They all want to “touch the Blockchain”.

So, I’ll get straight to the point: What’s important for the UX of Blockchain and DLT apps and how to do things the right way? You can read a lot about creating better crypto wallets, but there is almost nothing on designing complex enterprise solutions.


  1. Transparency

  2. Security

  3. Trust

  4. Аwareness

Those goals apply to most apps, but when developing Blockchain and DLT apps, we need to be extra careful. Many of those solutions are built for the finance, insurance, and supply chain industries where often transactions are of hundreds of thousands and millions. The potential cost for a simple mistake could be tremendous and to prevent such, you have to pay special attention to several fundamental aspects of your design.

Key Factors

  1. User types

  2. Roles and user management

  3. Statuses and system feedback

  4. States

  5. Event records and audit

  6. Verification and validation

User Types

Having the end user in mind when building a new product is a general rule that applies when designing all kinds of software. Unfortunately, when it comes to Blockchain and DLT, UX specialists are invited almost at the end of the party. Usually, this happens because stakeholders are very tech-oriented. They are focused on solving the new technological challenges. Sooner or later, the UX pro comes and starts asking questions, and the first one would always be “Who is the user?”. And that’s where things get interesting.

Let’s say, John is a high-level bank manager. He has a different mindset than Olivia — a forex trader. John prefers information to be presented in a clean, simple, and understandable way. He has to take crucial decisions and pay close attention while performing tasks. Olivia, however, wants to see the whole picture straight away. She needs to complete important but repetitive tasks very fast. The two would expect completely different behaviour from a software. And, on some occasions, they will have to use the same app but for different purposes.

A diagram comparing two different users, explaining that having the end-user in mind when building a new product is a general rule that applies when designing all kinds of software

So at the beginning of a project, the first thing to do is to create your personas. Alan Cooper’s blog provides the best insight on the do’s and don’ts of user personas, simply because he invented them. Thinking about your user first could save you hundreds of hours spent on code change and adjustments. And it will definitely help you build a better app.

Roles and User Management

User Roles

In most of the enterprise Blockchain apps, you would find similar user roles. The vast majority of use cases include separate nodes for a superuser, a regulatory user, a basic user. A typical node for a superuser embodies several different roles: issuer, notary, and oracle. We will get back to those later. Usually, you have at least 3 users with completely different goals, tasks, and mindsets, thus your app should have a separate design for each one of them.

The main purpose of DLT apps is the secure, frictionless transfer of value. Let’s take the roles in a simple Corda payment app for example:

  1. A basic user can transfer assets and review the details and transactions history of his account.

  2. The superuser can create and edit user accounts, issue tokens, settle these assets with other parties, make transfers, and exit assets from the system. Besides these actions, they have access to the accounts list, assets list, event records, audit information, and so on. - The app uses a service called notary — the role of the notary is to verify the transactions. This service is performed by the system automatically but it could have a separate interface for human supervision.

  3. The regulatory could be a supervising government institution, for example. This user should be able to access ledger history, but their interface would be in a read-only mode.

  4. The system could use an oracle. The oracle is the window of the system to the outside world and verifies the information going in and out. This could be done manually or automatically, depending on the business needs.

A simple example of how layouts in a single app may vary depending on the user’s role.

As you can see, this app will need at least three different interfaces for its users. The design has to ensure safe, fast and easy interaction for each of the users.

User Management

In addition, you’ll probably need to design a user management interface for the superuser. This means, screens for:

  • Inviting users

  • Setting and reviewing accounts

  • Grouping users and setting permissions and roles

  • Editing and deleting accounts

  • If there is an audit functionality, you could provide a history of users’ actions

For basic users you’ll probably have to provide:

  • Means of communicating within the system — chat or messaging functionality

  • Interface for editing and deleting the account

  • Requesting permissions from superusers

A fragment from the TrueDataShare’s user management system.

The above is a basic example of what could go into a simple role management system. Depending on the application, you may need to develop a different set of screens or features, or you may not have to create those interfaces at all, especially when building an MVP. You can find more details on user management in hackernoon’s article: How to design roles and access controls in your product.

Permissions management tool in TrueDataShare

At first glance, this looks very complicated and time-consuming. That’s where design systems using atomic design come in handy. They ensure a rapid process for design and development.

From my experience, the most awesome thing about a design system is that, if done correctly, it could be reused over and over for totally different projects. We’ve been developing our own design system for a few months now and already see the results. I know, you are wondering if apps look the same. They don’t. If you create a simple enough design system, changing colours, font faces and paddings can make an enormous difference in style.

A screenshot from INDUSTRIA’s Design System.

Statuses and System Feedback

Appropriate feedback for a user action is perhaps the most basic guideline of user-interface design. It serves to keep users informed of the current status and to allow them to steer the interaction in the right direction, without wasting effort.

Aurora Harley in Visibility of System Status

As we all know, validating transactions in Blockchain may take some time. Users have to know the status of a transaction at all times. The basic statuses for most apps usually are: pending, successful, failed. Of course, there could be more. But let’s focus on those three. It’s always good to distinguish them by using colour. If there’s not enough space, you can present statuses using icons and show tooltips with the name on hover.

  1. The success status is easy — there’s not much more you can say about it.

  2. The pending status is a bit more tricky. Besides the name of the status, you can provide information about what’s going on, what are users waiting for, and approximately how long it would take to verify (if possible). And if you want to go even further — give the users a progress tracker. Here is an example of the steps in a Corda flow: - Identifying other nodes on the network - Sending data between parties - Extracting states from the vault (ie. the node’s database) - Gathering a transaction’s other components - Building a transaction - Signing a transaction - Verifying a transaction - Gathering a transaction’s signatures

  3. The failed status needs the most care. Except the reason for failure, you should provide guidance about what to do next. “Oops! Something went wrong” is never enough.

Visualisations for a software displaying different statuses

Besides statuses, you should inform the user about other major events happening at the moment, or issues that have occurred while the user was away:

  1. For uncommon terms — provide tooltips with detailed information.

  2. For feedback that doesn’t require instant reaction, you can use toasts.

  3. For events that require the user to interact immediately, use dialog boxes.

  4. To inform the user about events that happened while he was offline, you can build a simple notification centre. And if you want to make it even better, you can group notifications by topics and purpose.

Example of a confirmation dialogue box

UI States

This is a common concept in the UI and I won’t get into too much detail (do not mistake it for Corda States). We all know:

  1. Active elements should have: normal, hover, focus, pressed and disabled states.

  2. Empty states should be useful. They should provide information on what’s supposed to be there and how to create it.

  3. Too much or too little information should look good too.

  4. Loading states should provide information on what’s to be expected while waiting.

  5. Form validation should be helpful and meaningful.

Empty state with instructions

What is special about states in Blockchain apps? You can make the users’ life a lot easier with some better design decisions. Let’s take a look at some examples:

  • To receive assets, the user needs to provide the sender with their address. Usually, those addresses are long strings of letters and numbers and don’t make much sense to humans. There is no need to show the whole string at all times. You can show a part of it. On click — display and copy it to the clipboard.

  • If it is a busy screen with lots of details, help the user by focusing his attention on the part he is working on. If it is a form, dim the rest of the screen while filling it out.

  • If it is a table or a chart, provide an option to expand it.

  • Before completing important actions, always ask for confirmation, making it clear what is going to happen.

And if you want to be even more helpful, design good micro-interactions. Not only do they provide great feedback about what’s going on and why, but they direct users’ attention and teach them how to interact with the app.

Interactive account address

Event Records and Audit

Once again, the main purpose of DLT apps is the transfer of value. This means you’ll have to display historical records of transactions, events, actions, etc. To present this information, you’ll need to design efficient tables. At first, the task seems simple, but when you start designing with real data and functionalities, it could become quite a challenge. There is a lot that can be done to improve table usability:

Fixed Headers

Fixed headers show column names at all time.

An example of fixed headers displaying column names at all times


Filtering option grants quick access to any desired information.

An example of a filtering option granting quick access to any desired information


Column sorting enables prioritising the information.

An example of column sorting enabling the prioritisation of information

Bulk Edit

Provide an option for bulk editing.

An example of bulk editing options


For indexed items, be sure to update the index when reordering rows.

An example of the index being updated when reordering rows

Horizontal Scroll

For large datasets, horizontal scroll is inevitable. Usually, the first column holds the identifier — lock it to help orientation.

An example of horizontal scrolling for large datasets, which is inevitable


Audit modules for supervising user actions and performance need tables too. It is crucial to design these modules right — people’s jobs depend on it. You can provide filtering by user, action, date or period, object, and so on. Summarise the data using a visual interpretation of the statistics. Charts and graphs help the user to spot patterns and issues in aggregate.

Further Reading on Tables:

Verification and Validation

Just like any other application, a basis component of enterprise DLT apps is forms. They help users communicate with the system and other users. I would like to outline just a few key aspects, as much has been written on the subject.

First, help the user to understand what is required. Some of the concepts in Blockchain apps are entirely new and users will need help to understand them. Explain what the concept means and how to retrieve this kind of information.

Split forms into steps even if they are short. This is a good practice when designing decisive forms. Let the user focus only on one thing at a step. For example, in the first step, enter the address and in the second select currency and amount.

An example of a transfer's first step, where you first have to enter the address and then select currency and amount

Help the user to fill out the form by showing the correct format for numeric and text fields. For example, each currency may have a different number of decimal places: EUR has 2, BTC has 8, and ETH has 16 — the field should automatically adjust the dps to the currency.

A UI example of a transfer's second step, where a form should be filled out by showing the correct format for numeric and text fields

Show a read-only preview of the filled information before sending the form. Changing the looks of the data helps users to see if there are any errors and be confident when sending. How many times have you seen your typo only after you’ve sent the email?

A UI example of showing a read-only preview of the filled information before sending the form

Provide feedback on what happened after sending the form. Add details about what was sent and to whom.

Further Reading on Forms

Final Thoughts

In terms of UX, Blockchain and DLT apps are very similar to other enterprise solutions. If you have experience designing for the fintech and insurtech, this transition shouldn’t be too hard. If you care for your users and help the stakeholders make the right decisions, you have nothing to worry about. Of course, the best thing to do is to test your design at least 3 times with real users.

  1. Once in the beginning, using a simple paper prototype to confirm flows and architecture.

  2. Second, test your UX and UI, using an interactive prototype to validate the design decisions.

  3. Finally, test the final product to confirm the usability of the whole app.

And last but not least, consider the aesthetics of your app. Using a beautiful interface is pleasing for all users. “Form follows function” has been my mantra since the beginning of my design career, but the style of an app is what makes people connect with it on an emotional level. Beauty is the trigger that brings users back and makes them enjoy working with your app. A neat design will help increase sales and improve user satisfaction.


INDUSTRIA is a global technology consulting, development and ventures firm with extensive expertise in the field of enterprise blockchain, confidential computing, process automation and digital experience. Official partner of R3.

Let’s talk about making your idea a reality — contact uscontact us at hello@industria.tech!

Follow us on TwitterLinkedIn and Facebook.

We use cookies in order to personalize your experience.