The entire interface has become conversational, even when there’s no chat bubble in sight.

We’re designing conversations that happen across multiple surfaces, over time, with non-deterministic responses. And each kind of conversation creates its own uncertainty for users.

In fall 2025, I’m seeing AI in SaaS products do four distinct jobs, each with its own conversational pattern and uncertainty profile.

The four jobs AI does

The four jobs cover the gambit from proactive to reactive to autonomous:

Inform: Proactively surface information (daily digests, briefs, summaries)

Suggest: Offer embedded assistance (autocomplete, recommendations, next-step guidance)

Collaborate: Partner in real-time (copilot, chat, pair programming)

Execute: Take autonomous action (agents, automation, task completion)

Each job creates different kinds of uncertainty for users. And each requires different design patterns to manage that uncertainty.

Job 1: Inform (AI decides what you need to know)

This is the one that is really interesting to me: AI takes initiative to surface information without being asked.

ChatGPT Pulse delivers a personalized daily briefing every morning. It runs asynchronous research overnight, synthesizes your chat history and connected apps (if you opt in), and presents a card-based feed of what it thinks you need to know today. You didn’t ask for it. The AI decided to tell you.

Users perceive AI as a curator deciding what’s important and when to interrupt. This creates a specific kind of trust challenge: the AI is making judgment calls on your behalf before you’re even awake or logged in.

The uncertainty: What should be in the digest? When should it be delivered? What if the AI gets it wrong and surfaces noise instead of signal?

Managing this uncertainty: Build feedback loops that let users signal what’s relevant. Thumbs up/down, dismiss actions, engagement metrics—these teach the AI what each person cares about. The digest gets better over time, not perfect from the start.

Job 2: Suggest (AI offers options, you decide)

This is embedded assistance. The AI makes suggestions in the flow of your work, and you accept, reject, or ignore them.

Notion’s Database quietly fills in database fields when it can, and users can accept, reject, or ignore the suggestions. No chat interface. No “AI mode” to enter. Just helpful suggestions that appear when relevant.

Users perceive the AI as a precision assistant—offering micro-level support that’s easy to accept or ignore.

The uncertainty: Is this suggestion useful? Trustworthy? How is it influencing my own sensemaking? Is it engaging my critical thinking process or doing the work I don’t care to remember?

Managing this uncertainty: Make suggestions easy to override. The default should be ‘ignore and keep working.’ Accepting a suggestion should feel like a shortcut, not a commitment. When users can dismiss without friction, they’ll trust the AI to keep trying.”

Job 3: Collaborate (AI as thinking partner)

This is real-time partnership. You and the AI work together, iterating toward a solution.

Cursor’s chat mode (Cmd+K) is collaborative. You describe what you want, the AI proposes changes, you review and accept or refine. It’s a conversation, not a command.

The AI isn’t just executing—it’s thinking with you.

Users perceive the AI as a thinking partner—working alongside them to refine ideas and solve problems. This requires the AI to maintain context across multiple turns and show its reasoning, so users can judge whether they’re on the right track together.

The uncertainty: Is the AI understanding what I actually want? Do I understand what the AI is capable of? How do I make sense of a long-running conversation as it expands? How do I know when we’re done?

Managing this uncertainty: Make the conversation iterative—let users refine, redirect, and build on previous responses. Show the AI’s reasoning so users can judge whether they’re on the right track. Provide undo/redo so users can backtrack without starting over.

Job 4: Execute (AI takes action autonomously)

This is where AI does work on your behalf, often without real-time supervision and I’m mostly seeing it enterprise software but emerging in consumer product realms. This isn’t copilot mode (where you’re working together in real-time). This is asynchronous execution. The agent does the work, then asks: “Should I do this?”

Users perceive the AI as a coworker—capable of taking action but requiring oversight. This is why approval queues, contextual action history, and performance visibility are essential. The AI is doing real work that has consequences, so users need mechanisms to verify, approve, and learn from what it does.

The uncertainty: Did the AI do the right thing? How do I know what it did? What if it made a mistake I don’t catch? Are approving AI actions just as burdensome as doing it yourself?

Managing this uncertainty: Design approval queues with clear handoff patterns—the agent works, then surfaces its work for human review. Show contextual action history so users can see what the AI did to this specific account or object. Make the approval process teach the system what good judgment looks like.

Designing the transitions between jobs

Here’s where it gets complex. In enterprise products, AI often does all four jobs simultaneously. I’m working on agents that execute (handle tenant communications), inform (daily brief at login), suggest (next-step recommendations), and collaborate (chat with agents for complex cases).

When AI is doing all four jobs continuously across an organization, you need a different kind of interface: agent management.

Agent management isn’t a fifth job—it’s the oversight layer for AI that’s doing all four jobs at scale. The design challenge isn’t “how does one user interact with one AI” but “how does a team manage dozens of AI agents working across hundreds of business objects simultaneously.”

When you’re designing for enterprise-grade SaaS products, you will need to weave together a user’s flow through these modalities across the emerging landscape of interaction and UI patterns. A daily brief might direct you to an approval or task hand-off queue where you then might collaborate on an analysis in order to select the next action, which was, alas, AI suggested.

Are those transitions smooth? Or do users feel like they’re switching between separate products? Does the relevant context follow the user across modes? Are the UI patterns coherent and fit for purpose?

If your transitions are clunky, or your UX metaphors confusing, users will struggle to make sense of the chaos you’ve created.

What matters now for a competitive design strategy

Here’s what matters most:

• Establish and iterate on AI-UX standards, frameworks and metaphors that are fit for purpose and modality. Prioritize clarity and familiar patterns—users are learning AI interaction models across products. But don’t let existing conventions prevent you from exploring new approaches when they better serve your users’ goals.

• Understand which mode you’re working on. Conceptualize your design ideas within a user flow that helps you understand the transitions. Test the coherence of the mental models you’re asserting with real users early and often.

• Transition design work to high-data-fidelity prototypes as early as possible - ones that can simulate real world user and AI agent activity against real world data sources.

• Organize around rapid iteration using real world usage data. Transcripts, session recordings, and click-path telemetry will inform iterative enhancements while qualitative interviews can help the team shape bigger bets.

We’re in fall 2025, and I’m still figuring this out with my team. We’re building the routines to observe, iterate, and improve across all four jobs. It’s messy. The patterns are emerging, not settled.

Designing for uncertainty isn’t about eliminating it. It’s about making it visible, manageable, and transparent. And then using what you observe to get better.

Share

References

Microsoft Design. (2024). “UX Design for Agents.” Foundational principles including appropriate trust and uncertainty as a design element. https://microsoft.design/articles/ux-design-for-agents/

Notion. (2024). Database Autofill feature launch. Product updates documenting 50%+ AI attach rate and community response.

OpenAI. (2025). “Introducing ChatGPT Pulse.” Proactive daily briefing feature announcement. September 2025.

Sharma, S. (2025). “Where Should AI Sit in Your UI? Mapping Emerging AI UI Patterns and How Spatial UI Choices Shape AI Experiences.” UX Collective. Analysis of seven UI layouts and how spatial placement influences perceived AI roles. https://uxdesign.cc/where-should-ai-sit-in-your-ui-1710a258390e

Slack Design. (2025). “Prioritizing Craft in Recap, Our Newest AI-Powered Feature.” Design process for daily digest feature. https://slack.design/articles/prioritizing-craft-in-recap-our-newest-ai-powered-feature/

Skywork AI. (2025). “What is ChatGPT Pulse? OpenAI’s Proactive AI Daily Briefing.” Analysis of proactive information delivery patterns. https://skywork.ai/blog/chatgpt-pulse-openai-ai-daily-briefing/

This isn’t aesthetic preference—it’s necessity. Static mockups can’t capture AI’s dynamic, conversational nature where each response varies based on context, user history, and the inherent randomness of LLM outputs. When your product’s behavior is probabilistic, the traditional assembly line (PM writes spec, designer creates mockups, engineer implements) breaks down completely.

The teams shipping the best AI products have figured this out. They’ve stopped passing documents down the line and started improvising together. The product trio hasn’t disappeared—it’s just learned to play jazz.

When the assembly line breaks

The traditional model made sense for deterministic software. A PM could specify exactly what should happen when a user clicks a button. A designer could mock up the precise screen that would appear. An engineer could implement it pixel-perfect. The output was predictable and repeatable.

But what do you specify when the output changes every time? How do you mock up a conversation that adapts to context? How do you implement behavior that’s defined by a prompt, not code?

Anthropic’s Artifacts feature shows what happens when teams embrace this reality. Research scientist Alex Tamkin built the first prototype in March 2024 after getting frustrated with the tedious cycle of prompting Claude for HTML, copying to an editor, saving as a file, and opening a browser. His scrappy Streamlit prototype showed Claude on the right with real-time output rendering on the left. Within two weeks, product designer Michael Wang transformed this into a polished prototype using Node.js and shared it internally. The entire Anthropic company dogfooded it, providing immediate feedback.

By June 2024—just three months from initial prototype to production—Artifacts launched publicly with Claude 3.5 Sonnet.

Three months. From frustration to shipped feature.

The speed came from collapsing the handoffs. Wang describes using Claude itself throughout development: “I’m almost always using Claude in my development process. I use it to scaffold out code, have ongoing conversations about implementation details, and transform code as needed.” When Claude 3.5 Sonnet became available, the capability jump changed their ambition level entirely. “Folks were demoing entire Three.js or WebGL apps created by Sonnet in one shot. That’s when I knew we could be a lot more ambitious.”

The team adopted what Wang calls a “minimal backend approach” where “a huge chunk of Artifacts is ‘just’ presentational UI—the heavy lifting happens in the model itself.” The product specification wasn’t a PRD—it was the behavior of the model, shaped through prompts that the entire team refined together.

The new collaboration model

Microsoft’s teams underwent a parallel transformation. Yannis Paniaras, who leads design for Microsoft’s AI products, describes the evolution: “It used to be research, ideas, prototype, build, test—more linear. Now designers work concurrently with PMs and engineers to design prompts.”

Read that again: designers work concurrently with PMs and engineers to design prompts.

The prompt essentially becomes the product specification for non-deterministic systems. Content designers and UX designers jointly develop guidance for engineers to scale Copilot responses, creating consistent, reliable tone and timing. The design no longer flows through sequential handoffs. Instead, all disciplines shape the AI behavior simultaneously through collaborative prompt refinement.

Aman Khan, who writes about AI product management, describes what he calls “pair programming for prompts.” In his framework, PMs and AI engineers collaborate on evaluation criteria the same way engineers pair on code. The PM defines what “good” looks like from a user and business perspective. The engineer defines how to measure it technically. Together they own the “why”—the reasoning behind what makes the AI’s behavior acceptable.

This isn’t just about prompts. It’s about recognizing that for AI products, behavior is the interface. You can’t hand off behavior definition the way you handed off screen designs.

What actually changes

The artifacts are different. Ravi Mehta, who advises AI product teams, describes what he calls “vibe coding”—using tools like v0 to create working prototypes that serve as the new PRDs. Instead of writing a document that describes what should be built, you build a working version that demonstrates the intended behavior. The prototype becomes the specification.

Intercom learned this lesson building their Fin AI chatbot. The team discovered that colorful mockups with placeholder text couldn’t validate whether AI-generated answers met quality standards. Early prototypes required real customer questions paired with actual help center articles to evaluate answer quality. “Lorem ipsum is your enemy” became the operating principle.

This led to extensive backtesting—running the algorithm against historical support data at scale before building the full product envelope. Sometimes the MVP was simply “a spreadsheet of outputs” to validate the AI behavior worked before investing in interface development.

The responsibilities haven’t disappeared—they’ve just shifted. Marty Cagan and Bob Baxley from Silicon Valley Product Group provide the clearest framework: product discovery is fundamentally about judgment, not documentation. PMs still own value and viability. Designers still own usability. Engineers still own feasibility.

But for AI products, these dimensions interweave more tightly than ever because the AI’s behavior is the product experience itself.

Here’s what that could look like in practice:

Product managers ensure features create customer value for both users and buyers, assess business viability across legal/compliance/sales/marketing stakeholders, understand data implications and constraints, know the competitive landscape, and make tradeoffs between AI capabilities and business limits.

Product designers design how AI communicates with users including tone, personality, and conversation flow; are crafting interaction choreography that make AI capabilities discoverable and integrated into existing flows while introducing new AI-related mental models to users. Designers should be partnering with engineers to iterate on behavior quality: understandable, learnable, and usable across an infinite universe of edge cases and AI limitations.

Engineers (and increasingly, AI engineers specifically) own the technical implementation of prompts, build evaluation frameworks to measure behavior, integrate AI capabilities into production systems, optimize for performance and reliability, and stay current on techniques and model capabilities.

The difference is that these roles now work concurrently on the same artifacts—prompts, evaluation criteria, behavioral specifications—rather than sequentially on separate deliverables.

New roles emerging

This concurrent model has spawned new specializations. Conversation designers have become distinct practitioners who design dialogue flows, define conversational personality, write scripts or prompt LLMs appropriately, ensure linguistic correctness, create consistent voice across interactions, and test conversational experiences. They typically report to or work closely with product designers, specializing in the conversational interface layer.

Prompt engineers occupy the engineering-focused counterpart. They craft and optimize system prompts, build prompt templates and libraries, test and iterate on prompt effectiveness, integrate prompts into production systems, optimize performance, and stay current on techniques. The relationship flows logically: conversation designers define what the AI should say and do, prompt engineers implement the technical how of making AI behave that way.

But here’s what matters: these aren’t replacements for traditional roles. They’re expansions. Microsoft’s job posting for “Principal Product Designer” in AI emphasizes “shipping world-class AI applications with emphasis on craft, quality, trust, and positive user and societal impact” and requires “understanding user needs and behaviors, defining product requirements” for “zero-to-one consumer products” with AI capabilities.

This isn’t a new role—it’s product design with additional knowledge requirements: understanding AI capabilities and limitations, designing for non-deterministic outputs, managing user expectations about AI, understanding training data implications, and addressing ethical AI considerations.

The jazz metaphor is real

Here’s what I mean by “jazz band”: In traditional software development, each role plays their part in sequence, like an orchestra following a score. The conductor (PM) sets the tempo, each section (design, engineering) comes in at the right time, and the output is predictable.

In AI product development, you’re improvising together. The PM sets the key and the general direction. The designer suggests a melody. The engineer riffs on it. Someone tries a variation. You listen to how it sounds, adjust, and keep playing. The output emerges from the collaboration, not from following a predetermined score.

This doesn’t mean chaos. Jazz musicians practice scales, learn theory, and develop deep expertise in their instruments. The product trio still needs specialized skills—product sense, design judgment, technical expertise. But the way those skills combine has changed.

The teams that master this new rhythm will ship better products faster. The teams that keep trying to play from a score will keep discovering their sheet music doesn’t match the music their product is making.

References

Khan, A. (2024). “How AI PMs and AI Engineers Collaborate on Evaluations.” Aman Khan’s Newsletter.

AI Product Playbook

How AI PMs and AI Engineers Collaborate on Evals

👋 I’ve been posting less lately as I worked on shaping more of a structured list of topics to cover. I’m covering these topics in more depth during an upcoming cohort - you can learn more about that here…

Read more

10 months ago · 39 likes · 1 comment · Aman Khan

Mehta, R. (2024). “How to Work Like an AI-First PM.” Ravi Mehta on AI Product Management.

Ravi on Product

How to work like an AI-first PM

The death of Product Management is greatly exaggerated. Last year, Danny Martinez and I discussed why Product Management is likely to become more essential not less essential in the age of AI…

Read more

a year ago · 61 likes · 13 comments · Ravi Mehta and Danny Martinez

Modisett, H. (2024). Perplexity design process. Referenced in multiple industry discussions of code-first design approaches.

Paniaras, Y. (2024). Microsoft AI design process evolution. Microsoft Design team interviews and presentations.

Silicon Valley Product Group. (2024). Cagan, M. & Baxley, B. Framework on product discovery and AI product roles.

Wang, M. (2024). “Building Artifacts: From Prototype to Production.” Anthropic product development case study.

Sometime in the late 90s or early 2000s, my Aunt Ruth Ann presciently gathered all of our family’s recipes that she could and compiled them into a true family heirloom: an ms.doc file.

Now, let’s say, one of my cousins wants to make that doc easier to use. As an early adopter of AI-tools, she drops it into Claude and now she can chat with it. Later, she even creates a Custom GPT and shares it so that other family members can chat up some dinner ideas.

But sometimes you just want to browse the recipe book.

So, for our story, we’ll imagine my cousin has been fiddling with Notion awhile. She’s used it to organize a few trips, but isn’t an expert. She gets the idea of how filtering and sorting works in Excel - not a database expert, for sure, but familiar enough to wish the cookbook doc were a Notion database. Maybe for meal planning or maybe for appending additional tips and tricks.

My cousin is not going to create a Notion database schema and then copy and paste the recipes one by one. Instead, she might say,

• Claude, take this word document with all our family recipes and make a Notion database that is a recipe box.

You now have a recipe box webpage you can share with family via URL. In one instruction.

My cousin could continue on to chat her way to a dinner calendar, a shopping list, or methods guide for training young cooks, all stored in Notion where it’s easy to share, leverage, and evolve as needed on the fly to fit your needs (to a point, I’m sure).

But really regardless of your use case, instead of all your work being trapped in the Claude conversation thread, you can now easily post to an external persistence layer with a simple instruction (albeit after authorizing a connector).

A Poor Man’s Workflow Automation

My research interests include both design methods and tool use. In particular, I’m curious about how designers are combining tools in their workflows and how these workflows are evolving.

One of my research pipelines starts with a step using GummySearch:

• Ask the question of Reddit.

• The above input is analyzed for tools and workflow patterns (e.g. in this Claude Project with instructions).

  

• So that a formatted report is produced and stored in Notion.

• And specific Tools are updated to include additional workflow insights

The beauty of this approach for me:

• The persistence layer integration is entirely plain language in the project instructions.

  • I didn’t have to build an integration - I asked Claude to look for the couple of databases I already have - as context for building the project instructions.

• Easy to make, easier to use.

  • I drop in a report in a new chat within the Claude project and about a minute later it is a new entry in a database and has appended any existing Tool records.

• Easy to update.

  • Discuss and deploy minor Notion db schema updates, select values, and then update the project instructions. (I did eventually move over to Claude Code to manage the project instructions after I broke them out into different knowledge documents.)

  • It was also quite easy to debug/improve performance - Besides the MCP server failures, Claude recovered from 100% of errors from Notion when processing a report. A few turns of reflective improvement to instructions went a long way - except for when Notion’s MCP server returned an ever-changing but always ambiguous error code on any number of seemingly random operations.

How did Notion MCP break my heart?

It’s frustratingly unreliable. At least it was on Friday. And I’m not interested in debugging.

An aside on how good Claude Code is:

Excited by the rapid progress, but frustrated by the MCP unreliability - I used Claude Code to write and test an API-based fallback - leveraging Claude’s new code execution sandbox with network access. It worked, amazingly, but because the API instructions were in the prompt (project instructions), Claude would write the actually executed persistence-layer python code during inference time, which was prone to an occasional error (besides seeming extraordinarily silly as an approach). I did try to “imagine” though, to use Anthropic’s own term for it. Instead of optimizing this approach any more, I’m sticking to my more stable research automations for now and hopeful the Notion MCP service quality improves with time.

The CEO's words hit like a slap from across his desk. I was a UX team of one at the company and had reached the limits of his patience with my pontification on why context scenarios matter as a part of UX design work.

I was still energized at the time by a recent discovery of a technique that felt revolutionary to me in terms of effective software requirements definition.

I was no stranger to writing use cases and requirements documents when I read (devoured, actually) Alan Cooper's About Face 2 and one thing really clicked in the Goal-directed methodology: the efficiency of character-driven stories as the foundation for both design decisions and scope management. Those context scenarios with triggering events and user goals weren't just nice storytelling, they were a different way of thinking about UI design. Instead of design scope being screen-centric, I could shape scope into an evolving set of flows. Instead of guessing what users might do, I built realistic stories about specific people. If a new feature didn’t make sense for an existing character - then we needed a new character, which could then cause the appropriate reflection on our go-to-market strategy and release plan. For me, stories had become an incredibly rich way to figure out (and communicate) what we should actually build and why.

That CEO was wrong about stories not mattering, but he was right about my communication problem. I had much to learn about operationalizing the power of storytelling—using narratives to help teams develop shared understanding and make faster, more grounded decisions. Most design leaders have struggled with this same challenge—how exactly to calibrate their methods and practice to bring the right kind of design thinking at the right time. Stories help groups explore big strategic ideas and opportunity zones and they are just as useful in distilled form at the delivery level to help the trio rapidly translate grounded ideas into high-resolution experiments.

In this first article on how to use AI to amplify the benefits of narrative-driven design, I’ll introduce a framework (and example implementation) for an enduring, shared fictional world that sets the stage for AI-enabled scenario exploration. Read on to learn how you can get started now transforming your own context discovery from a designer's private sensemaking process into an exercise of shared foundation building.

1| Building the Foundation for AI-Enhanced Design

In the enterprise, the real challenge facing product designers is rarely a blank screen nor a lack of good ideas. It’s figuring out how to have a coherent conversation with people about the functional behavior of a complex systems (e.g. our product UX). Nevermind that our system behaves according to an endless sea of configurations and contexts, across a matrix of customer types and user roles. Still, product folks are admirably doing all of this mental gymnastics across current and future versions: backflipping and cartwheeling through what’s “now, next, and later” on the roadmap.

Designers are responsible for helping product teams make sense of present reality and possible futures. Doing whatever it takes to enable the team to make decisions faster, test assumptions earlier, and ship value more often. Lots of service design tools have become common practice: persona modeling, customer and user journey mapping, timelines, storyboards, canvases, continuous discovery routines and the like.

But even with significant progress in customer and user journey management methods and tools, our research, modeling and design processes still scatter valuable user knowledge and product details across projects and teams. We interview users, create personas, craft stories, map journeys, write specs and then watch that insight disappear into Miro files and Notion docs as it ages, seldom to be systematically reused. Whether you're a design team of one or 100, whether you're exploring problems in discovery or refining solutions in delivery, the core challenge remains the same: teams lack institutionalized memory to rationalize features, functions, and scope decisions while staying rooted in real customer problems.

This is where world-building becomes the foundation for AI-enhanced design practice. For more than a decade, across both small teams and large product families, I’ve managed complexity in product/UX design programs by building rich, persistent contexts that serve as ongoing, foundational rationale for design decisions. In the many years since my meeting with the CEO, flow-based thinking has largely replaced screen-designing as the norm. I’ve extended this flow mindset by framing flows always within character-driven stories. This approach has consistently enabled my teams to make coherent feature scope and sequencing decisions by ensuring everyone shares the same grounded understanding of what they are building and why.

I’ve tried to formalize my world building approach lately since the availability of LLMs. These new tools have inspired me to consider the possibilities of infinite exploration and how to constrain, scope, and manage such infinity at a program level. So far, the infrastructure for this practice centers on what I've dubbed the Story Bible—borrowing from fiction writing traditions like the Star Trek: The Next Generation Technical Manual.

The Technical Manual helped writers on the show maintain consistency across complex fictional universes. Similarly, this approach of canonizing a fictional world for use in your design practice can help transform scattered user research into a curated, persistent foundation that your team can use to rationalize design decisions across multiple features and projects.

This matters because AI makes comprehensive narrative practice much more scalable for organizations. AI-amplified world-building enables any team to build and maintain foundational rationale at scale while accelerating decision-making through shared context.

For individual designers, this approach empowers you to help your team succeed by providing the structured foundation that makes both discovery exploration and delivery refinement more productive. Rather than starting each feature conversation from scratch, you can reference established contexts that accelerate understanding and focus discussion on the specific design decisions at hand.

In the coming sections, I'll share my recent explorations building this foundation and establishing the cognitive framework that makes effective AI-enhanced narrative design possible.

World-building with a Story Bible Framework

The Story Bible I’m piloting consists of three core components that work together to create your team's persistent fictional universe: Characters (people with established backgrounds), Places (specific settings with known constraints), and Settings (environmental and organizational factors that shape experiences).

1 | Characters: People with Persistent Backgrounds

Characters in your Story Bible aren't situation-specific personas—they're people with established backgrounds that remain consistent across different scenarios and timeframes. Maya Chen serves as an example of this approach. In our Story Bible, Maya has: educational background in business administration from UT Austin, three years as leasing agent before promoting to property manager, strong relationship-building skills and detailed communication style, prefers phone calls for urgent issues, comfortable with technology but not an early adopter.

Notice that nothing here situates Maya at a specific time or property. These persistent facts enable us to explore Maya in different contexts—her first week as a property manager, handling a crisis after two years of experience, or transitioning to manage a luxury high-rise. The character foundation remains constant while the situational context changes through our Stories Collection.

2 | Places: Locations with Known Operational Realities

Places capture the persistent characteristics of specific locations that affect how anyone would operate there. Willowbrook Apartments exemplifies this approach: 180 units, garden-style layout, built in 1995, recent roof renovations; self-managed by Alliance Residential with on-site maintenance team; young professionals and small families, 18-month average tenure; aging HVAC systems, limited parking during peak hours; pool and fitness center, package concierge service.

These characteristics persist regardless of who manages Willowbrook. Whether Maya, a seasoned veteran, or a new manager runs the property, these operational realities shape what's possible and what challenges they'll face.

3 | Settings: Environmental and Organizational Factors

Settings encompass the broader context that shapes how characters behave and what's possible in specific places. For our multifamily context: Alliance Residential's corporate standards and communication protocols, Austin rental market dynamics and seasonal leasing patterns, Texas tenant laws and fair housing requirements, property management software and maintenance scheduling systems.

Settings provide the "rules of the world" that make character and place interactions feel authentic and explain why certain solutions would work in this universe while others wouldn't.

How These Components Enable Better Design Decisions

The structured foundation of characters, places, and settings transforms how teams collaborate and make design decisions. Instead of starting each feature conversation with lengthy context explanations, you can reference established Story Bible elements and immediately focus on the specific design challenge at hand.

For AI collaboration specifically, this structure enables precise prompting that generates useful insights. Rather than asking:

"Generate scenarios for a property manager dealing with maintenance requests,"

you can prompt:

"Explore how Maya Chen would handle a complex maintenance situation at Willowbrook Apartments during peak leasing season, considering Alliance Residential's response protocols."

The AI has rich, persistent context to work with—Maya's professional background and work style, Willowbrook's specific operational challenges, and Alliance Residential's organizational constraints. This produces grounded, realistic scenario generation that accelerates team decision-making because the outputs feel authentic and actionable from the start.

The three components work together to create a cohesive fictional universe:

Characters are people with persistent backgrounds, career trajectories, skills, and personalities. Maya Chen has a specific educational background, work history, and approach to problem-solving that remains consistent across different scenarios and timeframes.

Places are specific locations with known operational realities and constraints. Willowbrook Apartments is a 180-unit garden-style community in suburban Austin owned by Alliance Residential, with specific amenities, challenges, and operational rhythms. Maya is the current property manager, but the Story Bible tracks the property's persistent characteristics that would affect any manager.

Settings encompass the broader environmental factors—organizational culture (Alliance Residential's corporate standards), technology infrastructure, regulatory requirements, and market conditions that create the backdrop for any scenario in this universe.

Together, these components create the structured foundation that makes AI collaboration feel achievable rather than overwhelming. Instead of asking AI to generate scenarios from scratch, you're asking it to explore specific situations within established contexts, creating more relevant and useful design insights.

Story Bible Framework
├── Characters (Maya Chen, Property Manager at Willowbrook)
│   ├── Background & Journey
│   ├── Current Context
│   └── Relationships
├── Places (Willowbrook Apartments, Austin TX)
│   ├── Physical Environment
│   ├── Operational Constraints
│   └── Community Dynamics
└── Settings (Suburban Market, Alliance Residential Culture)
    ├── Organizational Context
    ├── Technology Infrastructure
    └── External Factors

2 | Ideas to Get Started

Here's what Story Bible documentation actually looks like in practice:

Maya Chen - Property Manager Based on interview with Maria Rodriguez, Sunset Gardens (Austin, TX) - March 2024

Professional Background:

• Business Administration, UT Austin (2019)

• Leasing Agent, Alliance Residential (2020-2023)

• Property Manager, Willowbrook Apartments (Sept 2023-present)

Work Style & Constraints:

• Thorough documentation, prefers phone calls for urgent issues

• Paper-based work order system creates information gaps

• Alliance Residential requires all interactions documented within 24 hours

Key Relationships:

• Lindsey Martinez (Leasing Agent) - lease history and resident explanations

• David Chen (Maintenance Coordinator) - utility consumption patterns and maintenance records

Current Context Notes:

• Managing 180-unit garden-style community in suburban Austin

• Six months into property manager role, still building confidence

• Peak leasing season creates time pressure for resident issue resolution

Notice the difference between this and a typical persona. Maya isn't "Property Manager, 3-5 years experience, manages 100-200 units." She's a specific person with established relationships, known constraints, and authentic work realities that shape how she approaches problems like confusing utility bills.

When your team references Maya in design discussions, everyone immediately understands her context: her communication style, her relationships with Lindsey and David, her documentation requirements, her time pressures. This shared foundation accelerates design decisions because you're solving for specific constraints rather than debating abstract user needs.

Try This - Pick Your Character

Choose one real person you've encountered in your design domain. This might be someone you interviewed last month, a colleague from a different department, or even yourself in a previous role. The essential ingredient is that you've actually observed this person grappling with real constraints.

Document their background, work style, key relationships, and known constraints using the Maya format as a template. Don't worry about creating comprehensive Story Bible infrastructure—just capture what makes this person specific rather than generic.

Now, the next time you're in a design review discussing a feature or workflow, try saying "[Your character's name] would..." instead of "users would..." Notice how this changes the conversation. Instead of debating abstract needs, you'll find yourself discussing specific constraints, relationships, and realistic scenarios.

For example: "Maya would need to access David's maintenance notes while she's on the phone with the resident, because she can't put them on hold to check paper records" reveals specific information architecture requirements that "property managers need maintenance data" never could.

This is the cognitive shift that transforms design discussions. You're not designing for imaginary users—you're solving authentic problems for specific people whose constraints you understand. The more specific your character foundation, the more grounded your design decisions become.

Experience this benefit first. Feel how Maya-specific framing prevents feature creep and reveals authentic requirements. Once you've felt the value of character-grounded design thinking, you'll be ready for the systematic exploration capabilities that build on this foundation.

Be a Design Storyteller

What I've learned since that CEO encounter is that the real breakthrough wasn't convincing him that stories matter—it was discovering how specific character context transforms design conversations from debates about abstract needs into collaborative problem-solving for authentic constraints.

Imagine your next design review where you present story-based rationale: "Maya would struggle with this interface because her paper-based work order system means she can't verify maintenance history digitally." Then imagine showing the team multiple design options your Maya exploration revealed: solutions that leverage her phone communication preference, others that help her coordinate with David more effectively, approaches that work within Alliance Residential's documentation requirements.

That's the horizon we're building toward. Character-grounded design thinking that enables systematic scenario exploration, AI-enhanced context variation, and solution refinement processes that maintain authentic user constraints throughout implementation. Teams that can present design rationale through established character contexts while showing the multiple approaches that character's reality suggests.

The foundation we've established here—thinking through specific people like Maya Chen rather than abstract user categories—is immediately valuable for improving your design decisions. But it also opens the door to sophisticated exploration capabilities: partnering with AI tools to systematically vary Maya's scenarios, synthesizing existing research data through character lenses, developing collaborative studio methods that leverage shared fictional universes.

Start building your Story Bible now. Choose your character, document their constraints, experience how specific context transforms design discussions. By the time we explore advanced scenario generation and systematic solution refinement, you'll have the character foundation that makes those techniques feel natural rather than overwhelming.

The story and the wireframes were never in competition. They're partners in creating solutions that feel purposeful, grounded, and genuinely helpful to the people who will use them. Begin with one real person whose challenges genuinely interest you, and let authentic curiosity about their reality guide your design thinking.

Choose your Maya. Start today.

APPENDIX

Implementation Appendix - Story Bible in Practice

The Story Bible framework translates naturally into AI project structure using markdown files as persistent character context. This approach enables designers to maintain character knowledge across multiple design conversations while systematically exploring scenarios within established constraints. In my experiments below, you’ll find a companion to the Story Bible called, “Stories Collection.” The Stories Collection is the temporal aspect of the framework where Characters are situated at a place in time. Such maintenance of speculative and canonical scenarios in a repository then enables their future use as context.

Project Instructions

markdown
# Character-Driven Design Discovery

You are a narrative curator helping designers explore features through
established character contexts rather than generic user assumptions.

## Core Approach
- Always reference existing Story Bible characters rather than creating new ones
- Maintain character authenticity across all scenario exploration
- Ground design decisions in specific character constraints and relationships

## Three-Phase Process
1. Character Selection & Context Setting
2. Scenario Exploration & Evaluation
3. Implementation-Focused Refinement

Story Bible (Project Knowledge)

markdown
# Cast of Characters

## Maya Chen - Property Manager
*Based on interview with Maria Rodriguez, Sunset Gardens (Austin, TX)*

**Professional Background:** 
Business Administration UT Austin (2019),
Leasing Agent Alliance Residential (2020-2023), 
Property Manager Willowbrook Apartments (Sept 2023-present)

**Work Style:** Thorough documentation, phone calls for urgent issues,
builds personal relationships with residents and vendors

**Key Relationships:** Lindsey Martinez (Leasing Agent), David Chen
(Maintenance Coordinator)

**Constraints:** Paper-based work orders, Alliance Residential
documentation requirements, peak leasing season time pressure

# Places & Settings

## Willowbrook Apartments
180-unit garden-style community, suburban Austin, built 1995,
aging HVAC systems, Alliance Residential managed

## Alliance Residential Context
Corporate documentation standards, resident satisfaction focus,
cautious technology adoption, Texas regulatory requirements

Stories Collection (Project Knowledge)

markdown
# Previous Scenarios

## Maya's Utility Bill Confusion (March 2024)
Maya receives call from confused resident about utility charges...
[Canonical story with date/time stamps]

## Maya's Peak Season Coordination (February 2024)
During peak leasing, Maya juggles prospect tours while handling...[Exploratory scenario for workflow optimization]

Example Prompts

I think these prompts evolve along with the context - but I’ve provided some examples of how you might immediately start exploring narratives with an LLM. Practicing with prompts will help you identify context gaps in the Story Bible and refine your context model (e.g. creating a new property or character).

CHARACTER SELECTION

I'm exploring a utility bill confusion feature for Maya Chen. Based on her established background and current context at Willowbrook Apartments, suggest 2-3 specific scenarios where this feature might naturally fit into her property management workflow.

SCENARIO EXPLORATION

For Maya Chen handling a complex utility billing question from Meg at Willowbrook Apartments, generate a scenario that includes her communication style, her relationship with Lindsey regarding lease explanations, and Alliance Residential's documentation requirements.

CROSS-CHARACTER INTEGRATION:

This utility bill feature affects Maya (property manager) but also involves Lindsey (leasing agent) who handled original explanations. Based on their established relationship at Willowbrook, how would they realistically coordinate around confused residents?

STRATEGIC OPPORTUNITY ANALYSIS // MARKET EXPANSION OPPORTUNITY:

I'm exploring expansion opportunities for our resident portal features. Using Maya Chen's context at Willowbrook (garden-style, Alliance Residential) as a baseline, help me understand how property management needs might differ across:

1. High-rise luxury properties (downtown urban)

2. Student housing communities (university adjacent)

3. Senior living communities (specialized services)

For each context, consider how Maya's core challenges (documentation, resident communication, vendor coordination) would manifest differently and what new requirements might emerge.

FLOW VALIDATION ACROSS CONTEXTS

I need to validate our maintenance request flow works across different property types. Take Maya's established workflow at Willowbrook (garden-style, paper-based work orders, coordination with David) and help me explore how this same flow would need to adapt for:

1. Maya managing a mixed-use property with retail tenants

2. Maya at a conventional apartment complex with corporate maintenance staff

3. Maya at a luxury property with concierge services

What constraints change? What relationships become more complex? Where does our current flow break down?

FEATURE PRIORITIZATION THROUGH CHARACTER LENS

Our team is debating whether to prioritize automated utility billing explanations or enhanced maintenance coordination tools. Using Maya's specific context - her communication style, her relationships with Lindsey and David, her Alliance Residential documentation requirements - help me evaluate:

1. Which feature would have higher impact on Maya's daily workflow?

2. How would each feature integrate with her existing relationships?

3. What implementation challenges would Maya face with each approach?

4. Which aligns better with Alliance Residential's operational priorities?

Implementation Benefits

This markdown-based approach enables:

Persistent Character Knowledge: AI maintains Maya's context across multiple design conversations without re-explanation

Systematic Exploration: Character constraints guide scenario generation toward authentic rather than generic solutions

Cross-Feature Consistency: Design decisions for different features remain grounded in same character reality

Collaborative Development: Multiple designers can explore same characters from different feature perspectives

Institutional Memory: Story Bible grows richer through accumulated scenario exploration

The technical implementation supports the cognitive framework: specific character contexts enable grounded design exploration that accelerates decision-making while preventing the feature creep that emerges from abstract user assumptions.

Any thoughts?

I’m really thirsty for some feedback on this one. What do you think? Can you envision how fictional world building can help you model complexity?

Leave a comment

AI-powered design tools are transforming the landscape of digital product creation. From prompt-driven development platforms like v0.dev to AI-enhanced collaboration environments like Miro and FigJam, these tools expand what’s possible in early-stage ideation, prototyping, and cross-functional communication.. On one hand, they empower solopreneurs and non-designers to visualize and simulate product ideas with high fidelity and interactivity—without needing deep design or technical expertise.

But for experienced product designers, these tools open up entirely new dimensions of practice. They enable us to think beyond screens and flows, and start shaping the next generation of user experiences—ones that are more adaptive, more responsive, and more deeply human. To keep pace, we need to evolve not just our tools, but our approach—bringing our craft into conversation with the new mediums of LLMs, real-time systems, and intelligent interfaces.

Tools like v0.dev are powerful examples of this shift—they amplify user-centered design practices by helping designers push boundaries, bring complex ideas to life faster, and build interactive, data-rich prototypes that once required weeks of engineering support. They also help bridge the gap between speculative design and functional systems, allowing us to prototype design fictions—linking 'what if' product narratives to working simulations that model behavior and flow. This connection between imagined futures and tangible simulations helps us think through new interaction modalities, from AI-augmented collaboration to adaptive, context-aware interfaces.

This shift moves design practice from static screens and flat flows toward immersive, dynamic simulations. It enhances the designer’s role as a strategic partner in product development—one who prototypes not only the visual experience but the underlying behavior and context of use.

To begin, we’ll look at how different design modes—working inside an enterprise organization versus experimenting with startups or solo projects—shape the way these tools show up in practice. Each mode presents its own constraints and freedoms, and AI tools like v0.dev are starting to collapse the boundaries between them.

Designers often find themselves shifting between different contexts—each with distinct rhythms, constraints, and opportunities for AI-enhanced tools. Understanding these contexts helps determine when and how to integrate tools like v0.dev into your workflow.

Mode 1: Startup or Solo Design Exploration

In startup settings or personal projects, the pace is faster, the constraints are fewer, and the feedback loops are shorter. Tools like v0.dev shine here because they collapse the gap between ideation and implementation. Designers can sketch out an idea, write a structured narrative of the product vision and use that narrative as a living spec for prototyping and development.

We experienced this firsthand while building Castle, a creator support platform currently in private alpha. We began with a narrative describing what we might build, then mapped out the interaction flows to arrive at a working framework. From there, conceptualizing became straightforward. Our backend developer Mark could use the v0.dev-generated UI almost as-is, while our creative director Ryan focused on visual and motion graphics design for individual components which I can then integrate into v0.dev prototypes. We have a tight cadence of breaking down releases into smaller technical sequences that each introduce incremental change.

This approach eliminated traditional handoffs—we are co-evolving the product in real-time. Now, as we look toward the next version, we're in discovery mode again. New concepts take shape through narrative elaboration, Mural flows, Notion user stories, and team conversations, with v0.dev ready to help us prototype and test once ideas crystallize.

This mode rewards improvisation, storytelling, and tight loops between design and development. It also invites speculative thinking: what could this be? What’s the fastest way to test that vision with a few real users?

Mode 2: Enterprise Design Systems & Coordination

In an enterprise setting, the scale increases—so does the importance of consistency, coordination, and systems thinking. Design teams are often distributed across multiple products, and prototypes are used not just to test ideas, but to communicate them across functions. Here, narratives become essential tools for bringing order to complexity, helping teams align on user scenarios across distributed product families.

AI-powered tools take on a different role in this context. They promise to help componentize large systems, enforce design language, and simulate how new workflows might affect other parts of a product family. Tools like v0.dev can ingest structured component libraries and reuse design tokens, while collaborative environments like FigJam, Notion, and Miro become planning surfaces that integrate directly with downstream tools.

At RealPage, product designers on my team work across more than a dozen platform and product teams. Each designer navigates shared systems, updates others on in-flight changes, and prototypes in ways that reflect production realities. A speculative redesign might begin with a narrative sketch of scenarios across time, but it quickly needs to conform to our shared visual language, grid systems, accessibility constraints, and architectural dependencies.

We're still in the early stages of exploring how tools like v0.dev fit into this environment, experimenting with two distinct approaches: component-level prototypes and layout frameworks for implementation-focused work, and broader discovery concepting for exploring ideas without immediate implementation intent. We're also exploring how LLMs can help us scale our design fiction practice—using AI to generate scenario variations across different user contexts and business models, then testing these narratives through rapid prototyping.

This creates an interesting tension: in the enterprise, mature tools like Figma support established delivery operations and flexible design thinking, while tools like v0.dev promise to generate more production-ready UI—if teams can tune the machine to work for them. Some designers will always prefer the freedom and fluidity of Figma for early exploration, while others may introduce ideas through v0.dev at the orchestration layer (entire views or flows) or for components demanding specific, novel interactivity.

We're exploring how to bridge these approaches—balancing structured design system rhythms with the expressive possibilities that prompt-driven prototyping enables. Fundamentally, this is about storytelling through simulation: the faster we can create, test, and explore new interactions across multiple contexts, the more human-centered our outcomes become.

AI tools are already helping us speed up some of the negotiation—reducing time spent mocking up variants, clarifying edge cases through realistic simulations, and supporting design/dev conversations with working examples rather than redlines.

Exploring Together

By understanding the shape of your design context, you can better tune how and when to bring in AI tools. Some contexts call for quick tests and expressive leaps; others call for structured modeling and cross-team fluency. In both, the designer’s imagination remains at the center—now with more powerful tools to support it.

This newsletter explores how AI is fundamentally transforming product design—not by replacing human creativity, but by elevating discovery work over delivery, reshaping how design teams create value, and opening new opportunities for designers who cultivate strong design sense within collaborative product teams. Thank you for exploring these changes with me. The future of design is being written through our collective experiments, discoveries, and willingness to explore what's possible when human creativity meets intelligent tools.

What’s Next

In the coming issues, we'll dive deeper into specific design practices and prototyping workflows that are emerging in this new AI-assisted landscape. Expect explorations on:

• How to write design narratives as product requirement documents

• Bridging Figma, Notion, and v0.dev for dynamic prototyping

• Using interactive prototypes to communicate intent—not just visuals

• Evolving design systems to support real-time UI generation

• Experimenting with new interaction patterns made possible by LLMs

This is a space for experimentation, reflection, and sharing what we're learning as we build. I'd love to hear how these modes show up in your work—and what tools, methods, or questions you're exploring.