Embedded Files
Designing with AI: Lessons From an Evolving Design Workflow
Designing with AI: Lessons From an Evolving Design Workflow
15 October 2026, by Sarah Poon
AI tools are becoming part of designers’ daily work, offering new ways to explore ideas and produce interactive prototypes. But incorporating them into an established design process involves more than generating screens. It changes how design decisions are documented, how experiences are worked through, and how the resulting work is shared with a team. In scientific software development these changes provide an opportunity to democratize user experience design work among members of a diverse team. But the changes that emerge when exploring the new best practices from AI-enabled UX design may also introduce challenges and risks that we need to better understand and account for in work.
I explored the possible impacts of these changes while working on the design of the MVP for HPDF Console. The High Performance Data Facility (HPDF) is a Department of Energy (DOE) user facility built to accelerate scientific discovery by providing massive data services at scale. The HPDF Console is a platform allowing scientists to seamlessly access and analyze diverse, complex datasets.
While reading about the latest in AI-enabled design practices and designing for HPDF Console, it became clearer where AI could accelerate my work, where it required more structure and judgment from me, and where our existing tools and practices needed to adapt. My takeaways are:
AI can shift UX work from pixel production to system architecture
AI demands clear human intent
There is a collaboration tooling gap with AI generated design products
AI in the Design Process
AI in the Design Process
Separate from the main data platform, I was tasked with quickly designing an onboarding and allocation request workflow. I decided to experiment with using AI to accelerate that process.
design.md files encode a product's UX and visual design decisions in a format that both humans and AI can read, allowing agents to generate new screens that remain consistent with the rest of the product. A common workflow for creating a design.md file is to provide an AI agent with an existing website and a design.md template, then prompt it to generate the file based on the site's design.
In my case, however, I had only a handful of early mockups rather than a live product. I uploaded these mockups as a starting point and, through a series of prompts, asked the AI to generate both a design.md file and an HTML prototype of the allocation request process.
Because the source material was limited, the AI had to make many design decisions on my behalf. Some of its initial choices weren't ones I would have made, such as how it used color and hierarchy and how it structured longer, expert workflows. Rather than correcting each screen independently, I used these differences to identify design principles that hadn't yet been explicitly documented.
I iteratively reviewed and refined those decisions with the AI, updating the design system as the prototype evolved. The process helped turn implicit design judgment into more explicit guidance that could be reused when generating subsequent parts of the Console.
Communicating Design Intent with Screen Flows
Communicating Design Intent with Screen Flows
Next, I needed to generate the onboarding experience for new users. My first experiment was to provide the AI with a journey map developed by our UX researcher, along with the design.md file.
The first attempt produced a screen with a progress stepper whose first step was labeled “See demonstrated value,” an overly literal interpretation of the journey map. More importantly, as I walked through the generated flow, I noticed screens, decisions, and transitions were missing that I intuitively knew the experience needed.
I realized that the journey map was too high level for this task. A journey map describes the user’s broader experience, their goals, emotions, and pain points, but not the individual interactions needed to build an interface. The AI treated each journey map step as a single screen, even though a step could require multiple screens, decisions, and transitions. As a result, the generated flow left out parts of the experience.
I shifted my approach and outlined the screens users would see, the actions they could take, and what would happen next. To keep the input structured and machine-readable, I encoded the flow as a Mermaid diagram and provided it to the AI along with the design.md file.
Making the experience concrete had an unexpected benefit: it made us reconsider the onboarding journey.
Our original journey included project creation as part of onboarding. But once we worked through the screens and decisions involved, we realized we were asking new users to define project roles and purposes before they had even begun using the Console. This made us question whether project creation belonged in onboarding at all.
We ultimately changed the experience. Rather than requiring users to create a project during onboarding, every user would automatically receive an onboarding project, which is a place where they could begin exploring and working immediately. Creating and organizing their own projects could happen later, once the concept had context and meaning.
The detailed screen flow therefore served two purposes. It gave the AI the level of specificity it needed to generate a much more accurate prototype, but it also gave our team a way to examine the experience itself. Translating a high-level journey into concrete interactions surfaced questions that hadn't been obvious at the journey-map level.
The resulting prototype closely matched the experience I had intended, but the process had also changed what that intended experience should be.
Tooling Gap in the Product Handoff
Tooling Gap in the Product Handoff
While generating HTML prototypes accelerated my design work, it also exposed a challenge in team collaboration. The prototypes lived as local code files, so sharing them with engineering meant passing files back and forth over Slack. My cross-functional UX partners also lacked visibility into the evolving designs.
To keep the work visible to the team, I manually took screenshots of the rendered prototypes and added them to our Figma files. This created extra work to keep the shared designs in sync with the prototypes. AI prototyping accelerated my individual workflow, but integrating it into our collaborative process required a workaround.
Lessons Learned
Lessons Learned
Shift from Pixel Production to System Architecture
Using AI to instantly render HTML prototypes allowed me to drastically cut down on time spent pushing pixels. I spent significantly less energy on execution mechanics and far more time focusing on screen flows, deep interaction logic, and system edge cases.
AI Demands Clear Human Intent
AI cannot figure out product mechanics for you. If you provide a vague input, you will get a generic output. Forcing the AI to make UX decisions actually uncovers the gaps in your own thinking. You realize exactly what you haven't figured out yet the moment the AI generates it incorrectly.
The Collaboration Tooling Gap
AI-generated prototypes accelerated my individual work, but sharing and reviewing them with the team required extra effort. Maintaining visibility meant copying screenshots into Figma and keeping them up to date as the prototypes changed. For AI prototyping to support the whole team, it needs to fit into a shared process for reviewing, discussing, and tracking design changes.
Future Research
Future Research
These explorations focused on how AI could accelerate my work as a UX designer. Our broader goal is to help scientists create effective user experiences for scientific software, including those who do not have dedicated design support. Yet much of the process described here still depended on design expertise: recognizing when a generated interface was confusing, identifying missing interactions, and deciding when to reconsider the underlying workflow.
Our next explorations will examine how AI might help make that expertise more accessible. Can it guide scientists through defining design principles, translating high-level goals into screen flows, and identifying unanswered questions about the experience? We also need to explore how the resulting designs can be shared, reviewed, and refined with a team. Understanding where AI can provide useful guidance, and where human judgment and UX expertise remain necessary, will be central to making these approaches useful beyond an individual designer’s workflow.
Author Information
Author Information
Sarah Poon is a product designer at the Lawrence Berkeley National Lab. She’s interested in designing experiences around complex workflows and emerging technologies. This post was edited with the help of humans and ChatGPT.
Designing AI for Human Agency, Not Just Automation
Designing AI for Human Agency, Not Just Automation
14 August 2026, by Hannah Cohoon
TLDR: To enable users' control of AI systems, we must help users avoid errors as they plan, execute, and evaluate AI actions. Some longstanding usability principles are available to guide us, as well as new AI design patterns.
Generative AI has popularized a new way of interacting with technology: users describe the output they want rather than giving a computer precise commands. In the name of productivity, we have given over some decision making power to these tools, allowing them to define approaches and make assumptions about goals. But humans remain ultimately accountable for outcomes. So how do we design interfaces for AI tools so that we give people the control they need to shape outcomes as they see fit?
Error prevention is key to helping humans maintain control of AI systems. But, as many of us have learned, it is very difficult to get AI to produce the right outcome with one prompt. Often, we revise or build on our requests until we are satisfied. In recent interviews I’ve conducted with researchers and technologists, I have heard how people tire of this prompt engineering. “...It takes a lot of iteration at times and it just feels like maybe I'd just rather do it myself directly rather than spend the time to iterate, review, and go back and forth,” said one interviewee. This is poor user experience; exhausting trial and error is an inefficient and frustrating way to get aligned.
Planning AI Outcomes
Planning AI Outcomes
To avoid user frustration and keep them in control, system designers need to provide users with scaffolding to craft effective prompts. Emily Campbell, creator of The Shape of AI (https://www.shapeof.ai/), refers to this scaffolding as wayfinders, tools to “help users construct their first prompt and get started.” She offers eight examples of wayfinders, like nudges to alert users to actions they can take with AI and follow ups to get more information from users. When AI is used in scientific settings, system designers should combine wayfinding patterns to shepherd users through tasks like workflow construction or literature review. Agents can apply skills and interfaces can be designed to walk users through prompt generation, rather than expecting them to share necessary details on their first try.
Established usability principles also apply to AI-specific tools for preventing errors and unwanted outcomes. Designers have long advised we help users foresee the consequences of their actions, preventing allowable but unwise choices (Molich and Nielsen, 1990). With coding agents, this form of error prevention can be seen in the diff a user sees before accepting an agent’s proposed commit. With chatbots, users may encounter error prevention when an LLM clarifies a user’s intent before proceeding, perhaps asking about the tone it should use when writing. Usable systems also prevent user errors by including guardrails and checks that disallow unproductive or unacceptable actions (Molich and Nielsen, 1990). From Campbell’s library of design patterns, we can see inline flags and parameter sliders as ways to guard against unwanted actions. These configurable tuners are “knobs on the machine that let users control” and constrain AI (https://www.shapeof.ai/patterns/parameters).
Executing and Evaluating AI Actions
Executing and Evaluating AI Actions
Applying other canonical heuristics can help humans control AI as it carries out an action. For instance, for more than 35 years, Nielsen has encouraged designers to provide users with easy ways to stop or undo an action; a system should “provide clearly marked exits,” (Molich and Nielsen, 1990, p339). For AI agents and chatbots, this usability principle explains the need for a stop button or conversation forking and emphasizes the value of version control for code. Campbell considers such stoppers to be governors, “human-in-the-loop features to maintain oversight and agency.”
Control still matters even after an AI has produced an output—this is just another phase for designers to attend to. AI outputs must be easily evaluated. Nielsen advises we don’t just show users AI outputs, but “show the user the best representation for judging what the AI produced.” This means that if an AI agent performed analyses, we might want to plot some of those results. Or, if your LLM is giving you a summary of recent research, it should also give quotes and links to impactful and relevant papers.
Like the systems themselves, AI design principles are still evolving. But it is clear that we should not just be thinking of how to offload work—we need to think of how people can easily steer AI systems and correct course when needed.
Molich, R., & Nielsen, J. (1990). Improving a Human-Computer Dialogue. Communications of the ACM, 33(3). https://dl.acm.org/doi/10.1145/77481.77486
Author Information
Author Information
Hannah Cohoon is a User Experience Researcher at LBNL, seeking to create more rewarding and impactful careers for research software engineers and more efficient and enjoyable experiences for users. She has focused on studying and facilitating open source development, open science practices, and data intensive workflows. Hannah earned her PhD from the University of Texas at Austin. She got feedback from a human and ChatGPT when revising this post. You can reach Hannah at hcohoon @ lbl.gov
Page updated
Report abuse