CASE STUDY 4: Working with AI
I don't just use AI. I think critically about what it changes, what it breaks, and what it makes possible.
The context
Most conversations about AI in design focus on making things better, better prototypes, better documentation, better output. I've spent the past two years asking a different question: what does AI actually break, and is that always a problem worth solving?
One experiment I ran produced an unexpected finding. Making AI prototypes more consistent with our design system made stakeholders assume the designs were final. The polished output was undermining the design process. The right answer turned out to be keeping the prototypes deliberately rough. Sometimes inconsistency is a feature.
That kind of counterintuitive finding is what I'm interested in. Here are three pieces of work that shaped how I think about AI as both a design material and a design tool.
Designing the AI experience for Morpheus
OutSystems built an AI-powered app generator called Mentor, running on a platform called Morpheus. The product took a natural language prompt and generated a working low-code application. My role was designing the content for the onboarding experience and the prompt writing guidance.
The core design challenge was expectation setting. AI app generators are genuinely powerful but they have real limits. Users who don't understand those limits write bad prompts, get bad output, and blame the product. Users who understand them write focused, high-level prompts and get remarkable results.
I designed a three-screen onboarding flow that walked users through what Mentor could do, what it couldn't, and how to write prompts that worked. The "Prompt best practices" modal had three sections: be concise and focus on concepts, outline your data model, and set your expectations. The last one was the most important. Explicitly telling users what the AI couldn't do, mobile apps, complex logic, edge cases, made the experience more trustworthy, not less.
I also designed the example prompt chips on the Create app screen. Short, concrete, industry-specific. Ticket Management. Employee Onboarding. Order Management. The goal was to show users the right level of abstraction for a prompt before they'd written a single word.
Can design system guidelines make AI prototyping more consistent?
OutSystems designers were using Cursor to generate high-fidelity prototypes using AI. I wanted to answer a specific question: if we embedded our content guidelines and design system rules directly into Cursor as prompt context, would the output be more consistent with our design system?
The answer was yes, but with an unexpected consequence.
Better documentation did produce more consistent, guideline-aligned prototypes. But the more polished the AI output looked, the more stakeholders assumed it was a final design. We were creating a perception problem. Designs that were meant to be exploratory and proof-of-concept were being treated as commitments.
That led to a harder question: why were we trying to make AI prototypes better in the first place? The value of a prototype is that it looks unfinished. Deliberate inconsistency was actually protecting the design process, keeping stakeholders from locking in on something before the real design work had started.
The experiment ended not with a solution but with a reframe: the goal isn't AI prototypes that look more like final designs. It's AI prototypes that are clearly and intentionally rough, so everyone in the room understands what they're looking at.
That reframe led to a different question: if the goal wasn't better-looking prototypes, could we at least give every designer the same starting point? I began working with a small group of designers to build an AI-tool-agnostic starter kit. A cloneable markdown file connected to our design system styles, tokens, and content guidelines that any designer could pull into their AI tool of choice. The idea was that consistency didn't need to come from polished output. It could come from a shared foundation everyone started from. The project was early when my role was terminated, but the thinking behind it remains: design system consistency in an AI-first workflow is an infrastructure problem, not a quality problem.
Content Desk: an AI content review agent
The hardest content design problem on a large product isn't writing the content. It's maintaining consistency as the product grows and teams multiply. Every new designer makes micro-decisions about copy. Over time those decisions compound into inconsistency.
I co-designed and led the model training for Content Desk, a proof-of-concept AI agent trained on OutSystems' design system documentation and content guidelines. The idea was to make design system guidance conversational. Instead of searching through docs, a designer could ask a question and get a specific, guidelines-grounded answer.
The interface was a chat UI with a project sidebar, usage dashboard, and configurable assistant settings. We ran real queries through it during development. One example from the session logs: a designer asking about a toast message error for duplicate entity names during import. Content Desk responded with a specific answer about the constraint and asked clarifying questions to give better guidance.
The dashboard tracked questions asked, questions per day, trending topics, and content areas. We were building toward a tool that would surface where designers were confused most often, making the content layer of the design system self-improving over time.
The project was paused when my role was terminated. But the thinking behind it, that design systems need a conversational interface to be truly usable at scale, is something I'd continue in any role.
The through-line
Each piece of work pushed against a simple assumption about AI.
Morpheus pushed against the idea that AI will figure it out. Users need to understand the model to work with it well.
The Cursor work pushed against the idea that better AI output is always better. Sometimes roughness is a feature.
Content Desk pushed against the idea that documentation is enough. At scale, guidance needs to be findable in the moment, not filed away somewhere.
The pattern across all three: AI changes what's possible, but it doesn't remove the need for clear thinking about what you're actually trying to do.
Suggested visuals:
Morpheus onboarding flow, the three screens showing the progression from welcome to prompt best practices
The "Prompt best practices" modal with the three sections visible
The Figma to Cursor to Prod comparison showing the prototyping experiment
Content Desk chat UI showing a real conversation from the session logs
Content Desk dashboard showing the usage metrics structure