Designing Simpler Lightning Payments

Lightning envisioned as an overly-complicated mouse

Bitcoin and the Lightning Network offer features that make them incredibly unique and valuable. Decentralization, security and transparency are a few important features of Bitcoin, while the Lightning Network offers instant transactions, low fees, scalability, decentralization, and privacy.

These two powerful technologies are packed with benefits, but they remain complicated to understand and continue to require deep technical knowledge to use.

The complicated nature of these technologies is one of the things that holds them back from being truly mainstream. Today, Lightning requires you to create and run a node—often with hardware. The learning curve is necessary and steep to get going. Aside from general knowledge of how the network works, you’ll also need to know how to find peers, open channels, add liquidity, balance channels manually, and more. This all takes a lot of knowledge and a lot of care and feeding to continually make it work. Simply put, there is nothing simple about running a Lightning node.

For about a year, we pushed ourselves to simplify Lightning. The process of taking something as complex as Lightning and making it feel simple is a challenging endeavor. It’s not just about designing a good interface, it’s about designing a good system—and that’s as much (or more) about engineering than it is about interface design.

A baseline to learn from

To help us better understand the current pain points of running a node on Lightning, we set one up and ran it ourselves. Setting up a node was complicated, finding the right peers was primarily trial/error and guess work, rebalancing channels was painful and something that required constant attention. Through our set up and usage it became clear that there was a lot of room for improvement.

Our first iteration of Lightspark was a closed beta. It was still going to be aimed squarely at crypto literate people. It would not attempt to remove all the complexities of Lightning, but instead focus on simplifying node creation and providing better interfaces to find peers and balance channels with them.

After a few cycles of design and engineering work, we had managed to take much of the complexity out of node creation (essentially becoming one-click creation). However, the overall system was far from simple. Peers could be explored, but it was still difficult to understand which ones to connect to. Channels could be rebalanced with a simple slider, but this deeply felt like something that should be automated. 

Below are some screens from the closed beta that illustrate how intense and complicated it is to manage—even with a purpose-designed system.

Early versions of node creation made it simple to spin up a node

Our first dashboard needed to communicate all of the complexity of running a node because we hadn’t yet simplified and obfuscated the notions of nodes and channels. This helps illustrate how foreign Lightning is.

We initially created interfaces to help find peers, but these still required a lot of knowledge, trial and error in order to find the right peers to establish reach and efficiency on the network.

Channel rebalancing is complicated. We originally created ways to let you rebalance in a more visual way, but it was still too much manual work that needed to be automated.

That first version taught us a lot in a short period of time. We learned how important being properly connected in the network was for successful payments. We learned that manually managing channel liquidity at scale is very inefficient. It taught us how to find the best peers—something that would inform the next version and allow us to figure out how to dynamically open channels and keep them balanced. We learned that while it was easy to create a node, the remainder of experience was still rife with language and concepts completely foreign to people. 

In short, we learned that we needed to push more on designing a simpler experience more akin to the way people expect payment systems to work. 

Abstract and automate

We knew that the complexity we were dealing with wasn’t something that a pretty front-end design and some education was going to solve. We needed to find ways to abstract and obfuscate the more complicated aspects like nodes and channels away from the experience. 

These were hardcore design problems that required a lot of complicated engineering to make things simpler for the customer. We needed to engineer the complexity away and leverage familiar user experience patterns in order to make this a simpler, better product. We hypothesized that incorporating more familiar language, design elements and patterns, would not only help people recognize and understand what the product is, but also make onboarding a less painful process since there wouldn't be a ton of new things to learn.

A first step towards true simplicity

The Lightspark Platform today is a step forward in terms of simplicity for Lightning. Nodes and channels are indeed abstracted away. They still exist behind the scenes, but they’re created and managed automatically. This automation not only removes complexity for the user, but vastly increases the performance (speed and cost-efficiency) over a manually operated node. Additionally, the removal of all aspects of channels from the front-end helps everything feel more familiar, allowing customers to focus on their balances and payments.

Below are some screenshots of our first major release.

No more dealing with channels and nodes, our new release focuses primarily on the balances and transactions, not the tech that enables them.

When you want to receive payments from someone, you can generate a Lightning invoice (we call it a ‘payment request’). It’s a unique code that includes the amount of Bitcoin you want to receive and the destination address where the funds should be sent, alongside an optional memo.

To send money, just paste in the address of the receiver, add an amount and hit send.

If you want to pull your funds back into a bitcoin wallet simply withdraw them out. No need to manually close channels as those don’t exist in the experience anymore.

We continue to refine a lot of the experience to be more familiar including the ability to filter and search past transitions and requests

Many of the design patterns and terminology in our interface are borrowed from proven systems that have worked well for a long time. Simple transaction lists with sorts and filters; basic charting and reporting; step-by-step flows for sending and requesting payments — these flows and experiences are all made up of elements and language that are more familiar. This familiarity gives customers a head start because they intuitively know what things mean and how to use them purely based on using past experiences. Of course, we don’t want to retrench into days gone by and just copy the legacy systems we left behind for the sake of being familiar, but we do want to leverage what has proven to work, while removing complexity and friction that holds it back.

Work in Progress

Bitcoin and Lightning are powerful technologies that offer numerous benefits, but despite the fact that they’ve endured for a while in more than challenging times, they remain difficult to put into practical use. To make them more mainstream, we need to continue to push for design systems that feel familiar and continue to abstract the complexity away, whilst maintaining the benefits the technology inherently holds. We believe by doing so, that these technologies will become more accessible to everyone and bring them closer to mainstream adoption. 

Our next iterations will push on making things even easier and more familiar. We are still dealing exclusively with crypto, so there is still a lot to be done to make this feel native in a world that runs on fiat.