Every wallet includes a list of transactions that allow the users to see who they sent bitcoin to and who they received bitcoin from. This sounds straightforward, but there are many detailed design decisions to consider.
What is a transaction? #
On a technical level, a transaction is a transfer of a specific amount between two addresses at a given time. But as human beings, we think of a transaction as a grocery store purchase, a mortgage payment, or paying back a friend for lunch. We should strive to let users capture these additional layers of meaning so they can more intuitively navigate and work with their transaction history.
Design considerations #
Activity is a utility screen where a user wants to quickly browse a data set to see what’s new, find something specific, identify patterns, etc. Be deliberate with every detail and avoid adding anything that adds visual interest without signal, unless you have good reason to.
Following are some of the design decisions in the screens above:
- Received amounts are green, which is typically a positive connotation. Highlighting sent amounts red seems like a logical follow-on decisions, but this is not necessary as there is enough contrast already. Red can remain the color associated with errors.
- Adding a plus or minus next to amounts is helpful for the color-blind, as well as general readability & usability.
- Fallback icons are designed to be subtle and useful by indicating whether bitcoin was sent or received, and the status of the transaction. When they are not shown, because there’s a contact image displayed instead, no information is lost. Showing a bitcoin symbol instead, for example, would be visually distracting without providing any useful information.
- The formatting guidelines in Units & Symbols are applied.
Not carefully weighing these decisions can easily result in a cluttered appearance.
Beyond transactions #
Since we already offer users a chronological list of events, it is a small step to go beyond transactions and also include other relevant wallet activity.
User activity #
Events can include user activity related to unique wallet features. For example:
- Blixt allows for manual control over Lightning channels. The list can show when channels were opened and closed.
- Breez includes a podcast player. New subscriptions and episodes could be listed.
- Hexa allows users to have multiple wallets. The list can show when new wallets were created.
Software notifications #
Wallets can also independently keep an eye on user funds, data traffic, and other aspects, and highlight activity that the user should be aware of right away, or be able to reference in the future. Especially with security and privacy, users rely on the software to keep an eye out for them.
Smart organization #
The Lightning network makes micropayments economically and technically viable. For example, as a user listens to a podcast, they may stream 10 sats per minute to the host as a thank you. This can easily result in a cluttered activity list, which can be remedied via automatic grouping.
Search & export #
Search is helpful for anyone using a wallet somewhat regularly, especially if micropayments become more common. Since this functionality relies strongly on quality data, it should be very simple for users to add relevant metadata to transactions.
Closely linked to search is export, which can serve several purposes. For one, a user may want to migrate to a new wallet and take their transaction history with them. Second, it is useful for accounting and tax purposes, especially for merchants.
Different views #
Alternative approaches to the basic list view can give users different perspectives on their finances and activity.
The example shown here uses traditional categories borrowed from personal household finance. As users tag transactions, the categories update.
It’s recommended to approach this type of view based on the unique use case and feature set of the application. For example, a wallet that is focused on interaction with Lightning applications may instead group payments by the services they were made with.
Transaction details #
The activity list focuses on summarizing the top-level information, so users can quickly scan the screen to get an overview. If they identify a transaction they want to take a closer look at or interact with, the following screens become relevant.
A payment made on Lightning #
As with the activity list, transaction details screens should also only highlight relevant information and options, and make secondary details easily accessible.
A payment received on-chain #
While the details for Lightning and on-chain payments look very similary, there are subtle differences. Most noticeable for the user is the difference in fees and processing time.
Status display #
Status indicators are important for on-chain transactions since they take longer to confirm, as well as when things go wrong. While a completed transaction generally doesn’t need a status indicator, it should be shown if the transaction completes while the user is watching. Error messages should be clear and provide access to details and options to remedy the problem.
The recipient field #
Most intuitive for users is likely when a transaction is directly linked to a person or business. As this requires the user to tag transactions accordingly, there need to be fallback approaches that try to communicate the available technical information in ways that users can relate to.
This can be in the form of text labels, or even uniquely generated icons like Jazzicons. When using visual fallbacks, be deliberate about their impact. If they draw visual attention, but don’t communicate any useful information, you may want to avoid them.
Wrapping up #
As mentioned at the top of the page, there is a lot of nuance in the display of user activity. While this allows for many different small design decisions, users overall benefit if wallets take similar approaches. Particularly when it comes to the addition of metadata that is not stored on-chain or by Lightning nodes, it would be helpful if wallets can converge on standardized data formats to allow for interoperability and data portability.
Closely related to activity is the next page about contacts.