K3-Labs
A no-code platform that let non-engineers build and run agentic automations. Founding designer, 0 to 1.
AI, Automation, Enterprise
0→1
Role
Founding Product Designer to Design Lead
Timeline
Jan 2024 – Jun 2025
team
4 Designers, Engineering, Product
platform
Web
The problem was not complexity. It was deciding what to expose, and what to abstract.
Operational tasks in this space sit in a painful gap. Monitoring a wallet, publishing data on-chain, triggering a contract action: simple in logic, but locked behind custom scripts, Solidity knowledge and ongoing engineering. Even small operational changes needed developer time.
The design challenge was more subtle than it looked. Hide the complexity and the product feels safe, but not credible. Expose it fully and it becomes unusable. The real problem was not complexity. It was deciding what to expose and what to abstract.
I came to this from direct experience: years using DeFi protocols and trading across CEX and DEX platforms. That gave me an instinct for where trust breaks, and what a user actually needs to see to feel in control.
The goal: operable without engineers, without stripping away the power the technical users rely on.
Read, Transform, Verify, Write. One model the whole product was built on.
Before designing any screens, I answered a simpler question: how do you explain what an automation is to someone who has never built one? The answer became the product's foundation: Read, Transform, Verify, Write.
Every automation follows that sequence: pull data in, shape it, check conditions, act on the result. It was not just a UX pattern. It became the shared language for users building workflows, engineers adding new functions, and founders explaining the system to investors. Without it, users faced 30+ functions with no way to reason about what belonged where. With it, any workflow was readable at a glance.
The model ran through everything: the function taxonomy, the node colour system (blue for Read, green for Transform, teal for Operational, amber for Trade), the templates and the onboarding sequence. This is what systems thinking meant here in practice: one model, consistent from the first node a user dropped to the pitch a founder gave.
One sentence, Read, Transform, Verify, Write, aligned users, engineers and investors on the same mental model.
Trust is not built when a workflow is created. It is built when one runs.
The builder uses three columns, each with a single job: function library for discovery on the left, workflow canvas for composition in the centre, configuration panel for setup on the right. I chose structured vertical composition over an infinite canvas so workflows stay readable and a non-technical user can understand an automation just by looking at it.
But building a workflow is only half the problem. Trust is built when a user has deployed something and watched it run. Three decisions drove that: templates instead of a blank canvas, so users land on a real use case; minimal required configuration with the shortest possible path to Deploy; and immediate execution feedback in a Runs view 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 investor demo: open the product, pick a use case, deploy it live.
Under 10 minutes from account creation to a live, running automation. No engineer required.
30+ functions, one component pattern. Learn one panel and you know them all.
The function library grew past 30 functions, each with different inputs, validation logic and edge cases. The risk: every new function becomes its own slightly different artefact, and cognitive overhead compounds as the library grows.
The fix was a strict panel pattern applied to every function without exception: name and category badge at the top, description field first, required fields before optional, Cancel and OK always in the same position. Learn one panel and you have the mental model for all of them.
The hardest function was Transform, where users compute and reshape data between nodes. It took three versions. v1 was an expression editor that read 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, and multi-expression stacking. Power for advanced users without an intimidating default state.
A consistent pattern meant engineers could add new functions to the template without custom design work. The library scaled without the interface getting harder to use.
30+ functions, one repeatable panel pattern. The library scaled without new design work per function.
Deploy was not a button. It was the surface users returned to every day.
Most automation tools stop at creation. This one could not: users were running financial operations autonomously. If something went wrong, they needed to see what and why, without going back to engineering.
I designed Deploy 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. Treating Deploy as a daily surface, not an end-of-flow button, moved the product from "a tool for building workflows" to "a platform I trust to run my operations". That distinction matters for enterprise adoption.
The founders did not pitch with slides. They opened the product and ran live walkthroughs with real workflows and real deployments: Proof of Reserves, institutional data publishing, ZK proof generation. Real use cases from the space, not invented scenarios. The seed round closed in June 2024, five months after I joined, on the live application, not a prototype.
The product was the pitch. The seed round closed on the live application, not a prototype.
In an unfamiliar domain, the most valuable design artefact was not a screen. It was a sentence.
Around 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 automation layer of its kind in the ecosystem.
Those are company outcomes, built by the whole team over 17 months. My contribution was specific and structural: the Read, Transform, Verify, Write model, the three-column builder, the activation path under ten minutes, the function-panel system that let the library scale, and the Deploy environment that closed the trust loop.
If I were doing this again, I would instrument the path to first successful deploy from day one, not retrofit it once growth made the question urgent. We could see users were activating, but we read the signal later than we should have. I would also build a permissions model sooner: the moment real money runs through automations, "who can deploy what" stops being a later concern and becomes part of the core trust surface.
The lasting lesson: in a domain this unfamiliar, the most valuable design artefact was not a screen. It was a sentence, Read, Transform, Verify, Write, that let users, engineers and investors reason about the same system in the same way. Get the language right and the interface has somewhere to stand.
Around 5,000 users, 140+ B2B clients, a $1.5M seed round. Team outcomes, built over 17 months.
