K3-Labs
No-code automation for Web3. Founding designer, 0→1, 17 months.
Web3, DeFi
0→1
Role
Founding Product Designer → Design Lead
Timeline
Jan 2024 – Jun 2025
team
4 Designers, Engineering, Product
platform
Web
The Problem
Web3 operational tasks sit in a painful gap. Monitoring a wallet, publishing data on-chain, triggering a smart contract action — these are simple in logic, but locked behind custom scripts, Solidity knowledge, and ongoing engineering maintenance. For enterprise teams, this creates a permanent dependency: even small operational changes require developer time. K3 Labs set out to remove that dependency — not to "simplify blockchain," but to make it operable without engineers, without stripping away its power.
The design challenge was more subtle than it looked. Web3 isn't just technically complex — it's conceptually unfamiliar. Hiding that complexity makes the product feel safe, but not credible. Exposing it fully makes it unusable. The real problem wasn't complexity — it was deciding what to expose, and what to abstract.
I approached this from direct experience. I had spent years using DeFi protocols, trading on CEX and DEX platforms, and navigating real on-chain transactions. That gave me a clear instinct for where trust breaks — and what users actually need to see to feel in control. Not "how do we make blockchain less scary," but "how do we build something that someone who knows this space would trust, and someone who doesn't could still operate confidently."
The Mental Model
Solution: giving the system a language
Before designing any screens, I needed to answer a simpler question: how do you explain what a blockchain automation is to someone who has never built one? The answer became the product's foundation: Read → Transform → Verify → Write.
Every automation follows this sequence — pull data in, shape it, check conditions, act on the result. This wasn't just a UX pattern. It became the product's shared language: for users building workflows, for engineers creating new functions, for founders explaining the system to investors. Without this model, users faced 30+ functions with no way to reason about what belonged where. With it, every workflow was readable at a glance.
The model extended across everything: the function taxonomy, the node colour system (blue for Read, green for Transform, teal for Operational, amber for Trade), the template structure, and the onboarding sequence. It wasn't a feature. It was the architecture everything else was built on.
The Builder + Activation
The builder uses a three-column layout: function library on the left, workflow canvas in the centre, configuration panel on the right. Each column has a single responsibility. The library is for discovery. The canvas is for composition — you see the full workflow structure at a glance, follow the chain top to bottom, understand the logic without reading every label. The panel is for configuration — it opens on node selection without pulling you out of the workflow context. I chose structured vertical composition over an infinite canvas: workflows are readable, branching is visible, and a non-technical user can understand what an automation is doing just by looking at it.
But building a workflow is only half the problem. Getting a user to the point where they've deployed something and seen it run — that's where trust is actually built. Three decisions drove activation: templates instead of blank canvas, so new users land on a named real-world use case rather than an empty grid; minimal required configuration, with optional fields hidden by default and the path to Deploy as short as possible; and immediate execution feedback, with the Runs view showing status and steps the moment a workflow completes. A user with no blockchain background could go from account creation to a live running automation in under ten minutes. That same flow became the foundation for investor demos: open the product, pick a use case, deploy it live.
Function System
Solution: a system for 30+ functions
The function library grew to 30+ individual functions — each with different inputs, different validation logic, different edge cases. The risk: every new function becomes its own design artefact, slightly different from the last, creating cognitive overhead that compounds as the library grows.
The solution was a strict component pattern applied across every panel without exception: function name and category badge always at the top, description field always first, required fields before optional, Cancel and OK always in the same position. Learning one panel gave you the mental model for all of them.
The hardest function was Transform — where users compute and reshape data between nodes. I went through three versions. v1 was an expression editor that looked like code: too technical. v2 used simplified dropdowns: approachable but too limited. v3 was a hybrid — a searchable variable picker, a function library with Math, String, and Conditional operations, multi-expression stacking, and a recent expressions panel. It gave power users the depth they needed without making the default state intimidating.
The impact on the system: a consistent function pattern meant the design could scale to any new integration without custom work. Engineers could add new functions following the existing template. The library grew without the interface becoming harder to use.
Operations + Fundraising
Solution: closing the trust loop
Most automation tools stop at creation. This one couldn't — users were running financial operations autonomously. If something went wrong, they needed to understand what and why, without going back to engineering. I designed the Deploy section as a full operational environment: project overview with health signals, deployment history with version tracking, a Runs view showing execution status step by step, and build and runtime logs for diagnosis. The critical decision was treating Deploy not as a button at the end of a flow, but as a surface users return to every day. That shift moved the product from "a tool for building workflows" to "a platform I trust to run my operations" — a distinction that matters for enterprise adoption.
The founders didn't pitch with slides — they opened the product. The seed round closed in June 2024, five months after I joined, using the live React application I had designed. Not a prototype. The founders ran live walkthroughs with real workflows, real deployments, real results. My DeFi background shaped what was demonstrated: Proof of Reserves, institutional data publishing, ZK proof generation — real use cases from the space, not invented scenarios. That specificity made the product credible to investors who knew the domain. The shift from explanation to demonstration contributed directly to closing a $1.5M seed round.
Impact + Reflection
~5,000 users. 140+ B2B enterprise clients. Revenue around $1M. A $1.5M seed round. In November 2024, K3 launched on the EigenLayer Mainnet — cited in the launch announcement as "the first drag, drop, and configure UI/UX for automation and orchestration of Web3 operations." These numbers reflect the full team's output. My design decisions directly impacted the levers that drove them: activation speed through template-first UX, reduction of engineering dependency through the operational layer, and the clarity of product narrative that made the platform demonstrable in minutes. I was the only designer for the first six months. By month six I had built and led a team of four. When I left in June 2025, that team was building on the same mental model, the same design system, and the same component patterns from the start. The design scaled. That's the outcome that matters most.
The hardest part wasn't the interface — it was making consequential product decisions for six months without user data, without benchmarks, without an internal design review. Every major decision was made on first-principles reasoning and domain knowledge from my own time in DeFi. That pressure built a specific discipline: make the decision, commit to the reasoning, design for revisability rather than correctness. If I were doing this again: instrument activation metrics from day one, push for first user contact earlier, build stronger step-level observability into the Runs view, and design a more granular permissions model for integrations from the start — before enterprise clients connect production wallets.
