Epistemic Function Diagnosis in AI-Aided Design: Connecting Established Frameworks and Rapidly Evolving Practice
This paper proposes Epistemic Function Diagnosis (EFD) as a unifying reference layer to analyze and intervene in the complex, co-occurring hazards of AI-aided design by integrating established frameworks through a 2×2 diagnostic-intervention architecture and a Belief-Means-Method-Justification (BMMJ) grammar, while acknowledging the need for future empirical validation.
Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
In the world of making things, from designing a new chair to engineering a spacecraft, there is a long-standing understanding that the process of thinking and building is not a straight line. It is a messy, looping journey where designers generate ideas, test them, and often get stuck on a single solution too early, a phenomenon known as fixation. For decades, researchers have studied these stumbling blocks, creating maps and checklists to help teams avoid dead ends. At the same time, artificial intelligence has arrived with the ability to generate thousands of design options, explanations, and recommendations in the blink of an eye. This speed creates a new kind of trouble: the old problems of getting stuck or trusting the wrong information are now happening all at once, compressed into a single interaction with a machine. The challenge for researchers is not to discard the old maps, but to figure out how to use them when the terrain is moving faster than ever before.
A researcher named Masahiko Matsuhashi has proposed a new way to navigate this fast-changing landscape, not by inventing a new map to replace the old ones, but by creating a common language to describe what is actually happening. He calls this approach "Epistemic Function Diagnosis." The core idea is simple but powerful: instead of asking whether a specific AI tool or design method is good or bad, we should ask what specific job that tool or method is actually performing in the mind of the designer. Is it acting as a source of raw ideas? Is it acting as a final judge of quality? Or is it acting as a strategic guide for the whole project? By sorting these roles clearly, the method helps teams see when an AI is overstepping its bounds or when a team is mistakenly treating a temporary suggestion as a permanent rule.
The paper argues that the danger in modern design is not that AI is doing something entirely new, but that it is combining several known risks into one moment. Imagine a designer asking an AI for help with a cup. In a matter of seconds, the AI might suggest a shape, explain why it works, rank it against other options, and recommend it as the best choice. In that single burst of information, the designer might accidentally lock onto that one shape (fixation), treat a rough sketch as a finished product (premature commitment), and trust the machine's ranking without checking the math (overreliance). These are all separate problems that researchers have studied for years, but when they happen together, it becomes hard to know which part of the process needs fixing. Matsuhashi's work suggests that we need a way to untangle these threads without throwing away the decades of research we already have on how people think and design.
To solve this, the author introduces a framework that acts like a diagnostic layer sitting on top of existing design methods. It does not replace the specific tools designers use, such as process models that break a project into stages or studies that measure how much a team gets stuck on one idea. Instead, it asks a series of questions about what those tools are actually doing in a specific situation. The framework distinguishes between two levels of analysis. The first level looks at the method itself: what was this process model or AI tool designed to do? The second level looks at the specific moment of use: what job is the information actually performing right now? A prototype, for instance, might be intended as a learning tool to test usability, but in a specific meeting, it might be treated as proof that the product is ready to sell. The diagnosis helps spot when that shift happens and whether it is supported by enough evidence.
The paper offers a specific set of categories to help teams sort out these roles, described as a "grammar" for design thinking. It separates the vision of what the product should be from the strategy of how to get there, the tactics used to build it, and the execution that proves it works. This separation is crucial because it prevents a team from confusing a specific technique with the overall goal. For example, a team might decide that using a particular design thinking workshop is their strategy for success, when in reality, the workshop is just one tactic that could be replaced if it stops working. By keeping these layers distinct, the method ensures that if a tactic fails, the team does not abandon the entire project strategy. It also helps identify when an AI output is being used as a final decision-maker when it should only be offering a suggestion.
The author demonstrates this approach using two common scenarios in design research. The first involves the many different ways designers map out their processes. Some maps break a project into five stages, while others focus on feedback loops. The paper shows that these maps are not wrong; they just have different boundaries. The diagnosis helps users understand what a map can and cannot tell them. If a map shows that AI is being used in the "evaluation" stage, the diagnosis reminds the team that this does not automatically mean the evaluation is good or that human judgment is preserved. It signals that the team needs to look deeper at how the information is being used. The second demonstration looks at design fixation, where a team gets stuck on one idea. The paper shows how an AI can cause fixation not just by showing one example, but by bundling that example with a recommendation and a ranking. The diagnosis helps the team see that they are not just stuck on a shape, but are also treating a rough idea as a requirement and trusting a machine's ranking as a fact.
Crucially, the paper does not claim to have solved these problems with a perfect tool. The author is careful to state that this is a conceptual proposal, a way of thinking that needs to be tested in the real world. The work presented here is an analytical demonstration, showing how the method could work in theory, rather than a study with data from hundreds of teams. The author suggests that the next step is to see if different experts can agree on what diagnosis to apply and whether using this method actually helps teams make better decisions. The paper outlines specific questions for future research, such as whether separating an AI's suggestions from its recommendations reduces confusion, or whether teams can learn to spot when they are letting a tool take over a role it was not meant to fill.
The ultimate goal of this research is to help rigorous design research keep up with the rapid pace of artificial intelligence without losing its foundation. By providing a common language to describe what is happening, the method allows researchers to connect their findings across different tools and technologies. It suggests that the hazards of AI-aided design are not entirely new monsters to be feared, but familiar challenges that have been compressed into a faster, more intense interaction. The solution is not to stop using AI or to invent a new theory of design, but to become more precise about what we are asking these tools to do and how we are using their answers. If this approach holds up in future testing, it could allow the field of design to remain cumulative and grounded, even as the tools it uses change every day.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.