As AI made the platform more powerful, my role was helping keep it understandable.
July 2025 – present | Freelance UX and Product Designer, remote
1. From traditional UX to AI-native workflows
2. Bridging design, product, and implementation
3. Keeping complex systems understandable
From traditional UX to AI-native workflows
Myop is a builder platform that helps teams transform ideas, components, workflows, and business logic into production-ready digital experiences, with AI assistance throughout the process.
I joined the team in July 2025 as an embedded UX and Product Designer. The first phase of the work looked familiar: FTUE, onboarding, folder workflows, AI chat interactions, product improvements. Standard UX/Product work inside an existing platform.
Then the platform’s direction shifted. AI changed how the team thought about the product itself. What had been a builder with some AI features became something closer to an AI-native development environment. The questions changed. The work changed.
What started as hands-on screen-level work gradually became something broader. I found myself operating at the intersection of UX, product thinking, implementation, and workflows that had no established patterns yet.
My role was not simply to design interfaces. It was to help turn powerful new capabilities into experiences users could understand, trust, and successfully use.
The Challenge
When I joined Myop, the platform already supported a range of builder capabilities. Soon after, the rise of AI began changing how the team thought about the product itself.
Questions that previously had straightforward answers suddenly became open design problems: What is the role of the builder when AI can generate parts of the experience? How should AI assistance appear inside the product? Which decisions belong to the user and which can be delegated? How do users understand what the system generated and why?
The challenge was no longer designing individual screens. The challenge was helping define workflows for a product category that was still emerging.
The Process
One of the first challenges was helping define what concepts actually existed in the platform and how they related to each other. What is a Component? What is a Flow? What is an Experience? How does AI-generated content relate to content the user created manually? Who controls what, and how does the user know?
These questions were not abstract. They shaped the entire pipeline: how a designer works in the builder, how that becomes a production artifact, how AI participates along the way, and how users understand what has been generated versus what they authored themselves. The path from Designer → Builder → Production is not linear when AI is involved. Every step raises questions about ownership, visibility, and recoverability.
Much of this work happened before any screen was designed, in discussions about structure, ownership, and mental models. That is where the real leverage was.
The Solution
I helped establish patterns for how AI assistance should appear inside the product: when to surface it, when to stay out of the way, and how to make the system’s actions visible and recoverable. The goal was not to limit what AI could do. It was to ensure users always understood what had happened and what they could do next. Many of these patterns did not exist before. They had to be defined as the platform evolved.
The Result
Rather than adding AI as a separate feature, the team gradually evolved the platform toward AI-native workflows. My contribution was helping ensure those workflows remained understandable from the user’s perspective while the product continued to evolve.
Myop, AI builder platform
• Embedded UX and Product Designer during a major product transition toward AI-native workflows
• Quick to adopt, experiment, and turn new tools into practical advantages
• Bridging design, product thinking, and AI-powered workflows
• Helping turn emerging capabilities into experiences users could understand, trust, and successfully use
Bridging design, product, and implementation
As the platform expanded, design decisions became increasingly tied to implementation realities. The gap between a good idea, a usable experience, and a working implementation became smaller. To move quickly, the team needed people who could operate across those boundaries.
The Challenge
As AI-assisted implementation increased, a new kind of problem appeared: inconsistencies between design intent and the coded product. Buttons implemented at different heights. Spacing that drifted. Component variations that diverged from the original system.
This was not a design problem. The design files were correct. It was a design-to-code problem: the gap between a Figma component and how it was interpreted and implemented, especially when AI tools were generating parts of the code.
The Process
I began exploring how design systems could be made more implementation-ready. Not just as visual references, but as structured documentation that AI tools and developers could follow more consistently. This meant writing design-system-oriented markdown: explicit guidance about spacing rules, component behavior, state logic, and edge cases, documented in a format that reduced ambiguity between what was designed and what was built.
In parallel I started working directly with Claude Code, Figma MCP, and Myop MCP/Agent workflows, moving closer to the implementation layer than I had in any previous project. The goal was not to become a developer. It was to understand the full path from design decision to coded output well enough to catch problems earlier and communicate more precisely.
The Solution
When design documentation is structured for implementation, not just for handoff, the gap between design intent and coded experience narrows. Fewer decisions get made by default at the implementation stage. Fewer inconsistencies accumulate across the product over time.
The Result
This work shifted how I think about design deliverables. A Figma file is necessary but not sufficient in an AI-assisted development context. The most valuable output is often the structured logic around the design: the rules, the relationships, the edge cases, documented in a way that leaves less room for interpretation.
Keeping complex systems understandable
As capabilities grow, complexity grows with them. Every new workflow introduces new states. Every new feature introduces new concepts. Every new capability creates new opportunities for confusion. The risk is rarely a single broken interaction. The risk is that users gradually lose their understanding of how the system works.
Publishing and release management was one recurring example. As workflows became more sophisticated, users needed to understand what had changed since the last publish, what was currently live, what remained in progress, and what would happen if they pressed publish now. These are not simple states. Each one carries different implications for different user types. Designers, developers, QA, and release managers each have different things they need to know at the same moment.
My work focused on making those states legible: what the system shows, when it shows it, how it distinguishes between states that feel similar but mean different things. The goal was not to enable the action. It was to make users confident in the action before they took it.
Workspace structure, onboarding, empty states, search, and design system consistency followed the same principle: every area where users could lose their footing, I looked for ways to give them something to hold onto.
Clarity at this level is a product decision, not a visual one. It lives in what concepts are named, how they are separated, what information is shown at which moment, and what the system communicates about itself without being asked. That is the work.
The product became more coherent as a system. The improvements are difficult to point to in isolation. Their value appears in the overall experience: fewer moments of hesitation, stronger mental models, and greater confidence when interacting with workflows that have real consequences.
Final Takeaways
Myop was one of the first projects where I experienced the transition from traditional product design toward AI-native product development in real time. Not as an observer. As someone who had to keep up, adapt, and find ways to contribute value inside a process that was changing faster than any playbook could describe.
Before this engagement, my primary deliverables were research, wireframes, workflows, prototypes, and design systems. I handed those over to developers and trusted that the implementation would follow the intent. That worked well enough when humans were doing all the implementation.
During this project, that assumption stopped holding. AI tools were generating parts of the coded product. The gap between a Figma file and a working experience was no longer bridged by a developer reading a spec. It was bridged by an AI interpreting documentation, and then a developer reviewing the output.
That changed what I needed to do. I started working directly with Claude Code, Figma MCP, and Myop MCP/Agent workflows. I started writing design documentation structured for AI interpretation, not just human handoff. I started treating the path from design decision to coded output as something I could and should participate in throughout, not just at the beginning.
That shift changed what I think a senior UX designer needs to be able to do in 2025 and beyond.
The project also directly influenced decisions outside of work: it contributed to creating an AI learning community, to developing design-system-to-markdown practices, and to consulting work where I began delivering implementation-ready guidance alongside Figma files.
Understanding how users think, how concepts relate to one another, and where confusion is likely to emerge remains one of the highest-leverage contributions UX can make. Especially when the technology is evolving faster than the patterns around it. That did not change. What changed is how I deliver it.
Credits: Keren Fanan and the Myop team.