From Design and Break to Design and Make

In Autodesk Research we often turn to physical artifacts to drive innovation. Our mission is to de-risk emerging technologies for both the company and our customers, and one of the most powerful ways we do this is by building and testing real-world prototypes.

The Industry Futures team in Autodesk Research focuses on applying early-stage technologies, like generative AI, not just in theory, but in practice. That means engaging directly with the messy, constraint-laden, and often surprising realities of making things. Through physical design and fabrication, we aren’t just building a part, we test how AI can genuinely support design and expose our tools to real-world friction.

This kind of alpha testing reveals hidden design constraints, sharpens our empathy for customers, and forces critical thinking about workflows, usability, and what it really takes to “design and make anything.” Designing something digitally and exploring its use entirely in the mind—without ever building it—is like writing a novel and never publishing it.

In this first part of a two-part blog series, we share how we collaborated with the Science and Research Engineering team to create a physical prototype that accelerated the technology readiness of our AI tools and brought meaningful insights back into the Science team.

Closing the gap between research and reality

There’s a difference between doing science to publish papers and doing research to build something real. In Industry Futures we care about both, but we lean into the latter. Our goal is to turn promising ideas into tools that can actually help Autodesk customers design and make things.

Thomas J. Allen wrote in Managing the Flow of Technology (1977) how science, technology, and practical application have traditionally evolved along separate, loosely connected paths. Allen argues that the contribution to technology from basic science is rare, except for what he calls ‘gap-filling science’, an activity where technology defines a problem for science.  Allen also argues that the science and technology paths are becoming more closely coupled over time. Today, this convergence is especially visible in fields like AI, where massive investments in technology are making the boundary between experimentation and deployment increasingly blurry.

AI is closing the gap between early research and usable products faster than ever before. But that speed comes with risk, especially in design, where complexity is high and mistakes have real consequences. That’s why our team doesn’t stop at building digital experiments and aims to build physical prototypes to mitigate this risk.

Making hardware forces us to test whether our AI tools are truly robust enough for the real world. It reveals design constraints that aren’t visible on a screen, and it pushes us to trust (and question) the outputs in a way that digital-only workflows don’t. In short, physical prototyping helps us de-risk both the technology and the assumptions behind it.

Challenges with using research prototypes for real design problems

Narrowing the scope of the problem and determining which part of the research to leverage for a physical prototype is one of the hardest parts of our job. The TRL framework developed by NASA can help.

What are TRLs?

In the 70’s, NASA mapped out the journey from a groundbreaking idea to a market-ready product over nine distinct stages. These stages, known as Technology Readiness Levels (TRLs), assess the development stage of new technology, ranging from 1 to 9. At TRL 1, the idea is in its early phase, potentially as a concept or laboratory experiment. As development advances, it progresses through the TRL scale. The technology is tested in controlled laboratory environments, then in more realistic settings, and ultimately in real-world environments. By TRL 9, the technology is deemed reliable and ready for use in actual products or systems. The TRL system assists teams in determining when technology is suitable to move from research to practical application.

Design challenges using research prototypes for real-world problems.

Early-stage prototypes (TRL 2-4) sit in a space where things might just work, but haven’t been validated beyond a controlled lab environment. Bringing them into real design problems comes with a constant mix of challenges to juggle, from uncertainty to shifting needs:

• Technical readiness – How reliable is the current prototype today?
• Complexity of the problem – Is the use case simple enough for the technology to handle in its immaturity?
• Customer interest – Will customers care about the system?

At TRL 2 to 4, several challenges commonly arise due to the early maturity of the technology. At TRL 2, where the technology concept is only just formulated, there is typically no functioning hardware or software, and the risk of fundamental flaws remains high. Progressing to TRL 3, experimental proof of concept is introduced, but prototypes are often fragile, difficult to replicate, and hindered by complex or underdeveloped interfaces. By TRL 4, although validation occurs in a controlled environment, the technology has yet to encounter real-world integration challenges, with minimal user interface and potential installation issues.

Across these levels, key pain points include poor reliability (since controlled tests don’t reflect the noise and constraints of real-world usage) and undefined requirements, which can lead to misaligned problem-solving or building unused features.

Finding the Correct Problem

Identifying a use case that is simple enough to prototype yet valuable enough to build is challenging, and it must align with real customer pain points. Because early prototypes have constraints, we gauge potential with lightweight tests and a small, targeted user group. Low usage at this stage is expected; their feedback tells us what to change next: tighten scope, smooth the workflow, and add the integrations they rely on.

So, how to pinpoint the right problem? One effective method is to implement small pilot projects that align with the challenges in the TRL. By focusing on the smallest component of a larger issue, such as a subtask, researchers can comprehensively demonstrate the technology’s capabilities and target TRL progression. Spending time with customers and observing their workflows can often lead to identifying small but high-impact areas where the technology could provide a quick win.

Trade-offs: Complexity vs. Technical fit & Customer Value

The most productive early prototypes usually focus on a narrow scope, tackling smaller sub-steps within a larger workflow. These prototypes are directly relevant to a specific user problem and help address genuine pain points. Think of them as low-hanging fruit that can demonstrate quick wins. If they aren’t contributing to overcoming challenges of TRL progression, then they are not worth focusing on. While validating the technology, these small successes build confidence with stakeholders and pave the way for broader improvements.

The point of v1 is to choose v2 wisely.

To further illustrate the ideas shared in this post, we will dive into a case study in part two. This case study will explore the design of a robotic gripper showcasing the benefits of physical prototyping in research and how it can accelerate technological advancements. Stay tuned!