SnapLogic
SnapLogic recruited me to modernize a dated user interface for their low-code/no-code platform. That was the stated problem. The actual problem was larger and more systemic.
Engineering had always owned the product and design was an afterthought. They had a single visual designer whose background did not include interaction design. Engineering assumed they were the target user, which meant customer frustration was systematically misread as an education problem rather than a design problem. When customers ran pilots, they discovered quickly that aside from the initial drag-and-drop pipeline assembly model, the platform was not low-code/no-code in any meaningful sense. It required deep technical expertise to operate. The promise of the product and the reality of using it were not the same thing, and customers knew it.
The UI was a symptom. The organization was the problem.
Navigating resistance
I built the design team from scratch: designers, user researchers, and design engineers. In parallel I established the organizational conditions that would make design consequential rather than cosmetic. Driving the adoption of a Product Operating Model that aligned engineering, design, and product management before any roadmap commitment or product brief, and a co-innovation practice that brought customers into the design process as active participants rather than passive reviewers.
De-risking development before the roadmap was set changed the conversation between design, product, and engineering from reactive to generative. The four types of risk we addressed were:
Usability: is the product usable, useful, and learnable;
Feasibility: can it be built without compounding technical debt;
Viability: does it serve the company's strategy
Value: will customers pay for it.
AI product suite
Design contributed to every AI product from inception: initial concept definition, early prototypes, and front-end prototypes that took projects from academic research to market-viable products. The generative AI suite represented the most significant design challenge: translating genuinely novel technical capabilities into interfaces that users without deep technical expertise could operate effectively.
SnapGPT introduced in 2023, enabled users to generate integration pipelines through natural language. Unlike competitors focused on chatbot interfaces, SnapGPT embedded generative capability directly into the integration workflow allowing the user and SnapGPT to work side by side. It was the first of its kind in the market
AgentCreator enabled non-technical users to build, deploy, and manage AI agents without writing code, extending SnapLogic's low-code/no-code promise into the agentic layer of the platform.
PromptComposer solved the context-switching bottleneck in LLM app development by collapsing prompting tools, input data, and model outputs into a single visual environment allowing users to edit a prompt and see the LLM response instantly. AgentCreator and PromptComposer together generated $5M in bookings in their first year, the fastest product growth in company history.
SnapLogic Intelligent Modernizer (SLIM), is on the cutting of MCP capabilities. SLIM is an AI-powered tool that enables users to migrate integrations from legacy platforms and regenerates them natively inside SnapLogic, eliminating the manual effort that has historically made platform migrations a barrier to adoption. SLIM generated $3M in revenue in its first two quarters.
API Manager
API Manager was the first product built through a fully design-led process and it established a template for everything that followed. Running structured co-innovation workshops with customers, the design team acted as the bridge between customer insight, product management, and engineering: surfacing root causes that customer feedback alone had never reached and translating them into technically feasible, commercially viable solutions.
The results were immediate. Siemens moved off their existing legacy API management vendor onto SnapLogic's solution based directly on their engagement in the design thinking workshops.
As the agentic AI market matured, APIM was set to pivot to solve a problem no competitor had addressed: governance at scale. Organizations deploying agents across their technology stack had no single place to monitor, control, and secure them. APIM became that place: guardrails and policies, API security management, robust access controls, and human-in-the-loop validation across both SnapLogic and third-party agents. Observability and accountability in a category where neither had previously existed.
The co-innovation model that produced APIM became standard practice across the full generative AI product suite.
Platform transformation
Beyond the AI product suite, the design team led a comprehensive transformation of the core platform:
Information architecture: first-try findability improved from 22% to 78%, meaning users could locate what they needed on the first attempt more than three times as often as before.
Design system: an internal design system was established that reduced the cost of front-end development by 22%, creating consistency across the platform and accelerating the production of new features and products.
Co-innovation at scale
The co-innovation practice that began with APIM became a defining capability of the design organization. Structured around design thinking methodology, it engaged a cross-section of customers across industries and markets on focused problem areas including observability, AI and machine learning integration, and platform scalability. A Strategic Advisory Council — senior leaders from across industries — provided a 3-5 year strategic horizon to complement the near-term product work.
User research operated continuously across the product lifecycle: usability assessments of new products and features, benchmarking of integration lifecycles to prioritize improvements, and ongoing research into the evolving range of end users to ensure the platform served the full spectrum from data engineers to business analysts.
Learning and Enablement
In 2025 I took over SnapLogic's Learning and Enablement function, inheriting a course catalog that had not been updated since 2017. The content no longer reflected the product, the certifications no longer reflected how customers actually used the platform, and there was no coherent structure to guide learners through the material.
Within a year the catalog was completely overhauled. Courses had been restructured around role-based learning paths, ensuring that a business analyst, a data engineer, and an IT administrator each had a clear and relevant route through the material. All course content and certification exams were refreshed to reflect the current product. Micro-learnings were introduced to surface specific enhancements, new products, and best practices in digestible formats that customers could act on immediately.
The more significant transformation was financial. I built a business plan to monetize SnapLogic's training offerings directly and syndicate them through the partner network, converting what had been a cost center into a revenue-generating function. With a projected $2.8M in revenue in the first year, $2.3M of which was profit.
My role
I joined SnapLogic as the founding design executive, building the design organization from scratch and establishing design as a strategic function within the company. I reported directly to the CTO and served on the Product Leadership Team.
The scope of the role was broad: team building, product design, AI product development, platform transformation, and the creation of the co-innovation and customer advisory practices. But the defining challenge was organizational: shifting design from an afterthought in an engineering-led culture to a function with structural authority over the experience it was accountable for.
The outcomes reflect that shift. SnapLogic surpassed $100M in ARR in early 2026, establishing itself as the recognized leader in agentic integrations. UI improvements were cited by sales as the single most impactful product change from a revenue perspective, contributing to a 14% increase in top-of-funnel deals and improved close rates. The design system and front-end ownership model reduced annual spend by $1.34M and compressed time to ship from months to weeks, delivering customer value faster and giving the business a meaningful competitive advantage in a market moving quickly toward agentic integration.
The decision to have design own the presentation layer, using Claude Code and Figma MCP to generate and ship front-end code directly, was the structural move that made the efficiency gains possible and resolved a design authority problem that no artifact, regardless of fidelity, could have solved on its own.
D E E P D I V E
Owning the Front of the Front-End
Design has always been accountable for the user experience at SnapLogic. What it lacked was control.
The ratio was 1 designer to every 24 engineers. In that environment, design operated as a service function: producing research, synthesizing that into artifacts, models and workflows, attending reviews when invited, and expected to absorb feedback from engineers even if that ran counter to customer needs and requests. Engineers had 100% control over what shipped but the UX designers were held 100% accountable for its success.
We initially approached this as an education problem. SnapLogic had never had a design team before, and we assumed engineering's exclusion of design from critical planning meetings reflected unfamiliarity rather than indifference or worse. We responded by producing increasingly higher-fidelity artifacts: detailed Figma specifications, interactive prototypes, and working code generated either by hand or with AI assistance. The quality of the work was not in question. The dynamic was.
Every high-fidelity artifact we produced to compensate for exclusion was doing two things simultaneously. First, it was absorbing engineering's work without giving design any authority over the outcome — engineering retained a free option to take what was useful and ignore what was inconvenient; design had no leverage either way. Second, it was raising the bar for our own inclusion. If a working prototype wasn't sufficient to get designers into the room, the implicit message was that the next artifact needed to be even more complete. We were on a rock hunt. No artifact, regardless of its fidelity, substitutes for structural standing.
The solution was not a better artifact. It was a different organizational model.
I drafted a proposal for the design team to take ownership of the front-end presentation layer. Using Claude Code and Figma MCP, design engineers could generate, review, and own the front-end code directly, wiring it to the backend through defined component contracts with engineering rather than through informal influence. Once work was approved by Design its clarity, branding, usability, accessibility, etc. Engineering would review and approve the actual pull requests following a documented protocol that included things like performance, security, architectural integrity. Vague objections are not sufficient. The escalation path and decision timeline were also well defined.
Making this work required getting four things right before a single line of code was generated.
The first was a shared component contract. Legacy SaaS platforms accumulate inconsistent component libraries over years of development by different teams. Before Claude Code generates anything useful, there must be a defined boundary between what design can safely generate and what engineering owns and exposes via props. Without that contract, generated code works in isolation and breaks in integration.
The second was a disciplined CLAUDE.md. Claude Code reads this file as its operating context — acceptable component patterns, CSS frameworks and token systems in scope, what it should never generate, naming conventions that match the actual codebase. A vague or missing CLAUDE.md produces reasonable but wrong assumptions based on general best practices rather than the platform's actual constraints. This is the single biggest failure mode in AI-assisted front-end development.
The third was the distinction between design engineers and designers who code. A UX designer running Claude Code prompts and shipping the output is not the same as a design engineer reviewing, testing, and owning that output. The design team includes engineers who can read generated code critically — catching output that renders correctly but is semantically broken, inaccessible, or violates the platform's state management patterns. Without that capability, the workflow produces design-suggested front-end code that engineering quietly vets anyway. The structural problem is not solved.
The fourth was a canonical Figma discipline. Figma MCP feeds component specifications directly into Claude Code's context. In a legacy SaaS platform, Figma gets out of sync with production constantly. Claude Code is pointed only at components designated as canonical — not exploratory work — to ensure generated code reflects the actual component state rather than a design that no longer matches what is in production.
The result is a design organization that does not need to earn its way into the conversation through increasingly complete artifacts. It is structurally entitled to the conversation because it owns the layer where design decisions become user reality.
At a 1:24 ratio, that structural entitlement is not a luxury. It is the only model that scales.
