1.00Problem
1.00Problem
Lots of smart contract developers hate building frontends. Instead, many use “frontend generators” to get a free, working UI in minutes. Etherscan is the most popular one, powering tons of Ethereum projects. The problem? Etherscan’s UI sucks. 1) It’s a list of technically-worded forms, 2) It’s hard to navigate and 3) It shares little feedback about transactions. It’s bad enough that begginers need a Youtube tutorial.
Etherscan worked best with one-way actions (like voting or sending ETH), which trigger changes without returning data. Two-way actions, which return more complex data (like checking balances or viewing NFTs), often needed custom UIs to handle the extra complexity. The straightforward layout made navigating one-way actions easy, while two-ways required more tailored solutions.
Etherscan worked best with one-way actions (like voting or sending ETH), which trigger changes without returning data. Two-way actions, which return more complex data (like checking balances or viewing NFTs), often needed custom UIs to handle the extra complexity. The straightforward layout made navigating one-way actions easy, while two-ways required more tailored solutions.
2.00Form UI
2.00Form UI
Realizing smart contracts worked like mini forms made us wonder: What if we applied form builder patterns to smart contracts? You could solve most of the UX issues by 1) giving every action a dedicated page, 2) letting people write their own copy and 3) sharing clear, thoughtful feedback about transactions.
2.19Landing page
3.00One-way actions
3.00One-way actions
Formie had to integrate with any contract, meaning its copy, error handling, and layout needed to adapt to thousands of actions. It also had to be flexible enough to work seamlessly across different brands. To make Formie a universal solution, we focused on one-way actions. This narrowed the scope, avoided potential edge cases, and targeted the core functionality used by the majority of projects.
3.01One-way actions UI
4.00Confirming trust
4.00Confirming trust
We knew scammers could exploit forms to misrepresent contracts from the start. While stopping them entirely wasn’t feasible, we needed a way to protect users without overcomplicating the product. Requiring users to confirm trust became our solution. Many scams succeed because people act too quickly, especially in crypto. By forcing users to actively confirm trust, we slowed things down, giving them more time to make informed decisions.
5.00Open text fields
5.00Open text fields
Smart contracts have quirks like transaction costs, delays, and public access to frontends. These technical details confuse users. To simplify, we replaced jargon with plain English (“method” became “action”). Still, users needed more control, so we let people write custom titles and descriptions, keeping forms flexible without adding complexity.
6.00Tradeoffs
6.00Tradeoffs
Editing after form creation required a week-long backend rewrite. Instead, we made forms permanent but easy to duplicate, letting users “edit” by creating new forms in ~30 seconds. This saved development time and allowed faster shipping. Full customization was overwhelming without edits, so we limited form customizations to title and description. This kept forms simple while providing essential context.
