DynEx: Dynamic Code Synthesis with Structured Design Exploration for Accelerated Exploratory Programming

TL;DR

DynEx addresses the challenge of converting abstract design ideas into functional UI prototypes during exploratory programming. It combines a Design Matrix for structured design space exploration with Modular Stepwise Implementation for sequential, testable code generation, including self-invoked multimodal LLMs. The study with 10 experts shows DynEx yields greater design divergence, better convergence, and more feature-rich prototypes than a Claude Artifact baseline. This approach suggests structured design exploration can significantly accelerate MVP creation and strengthen the alignment between design reasoning and engineering in UI prototyping.

Abstract

Recent advancements in large language models have significantly expedited the process of generating front-end code. This allows users to rapidly prototype user interfaces and ideate through code, a process known as exploratory programming. However, existing LLM code generation tools focus more on technical implementation details rather than finding the right design given a particular problem. We present DynEx, an LLM-based method for design exploration in accelerated exploratory programming. DynEx introduces a technique to explore the design space through a structured Design Matrix before creating the prototype with a modular, stepwise approach to LLM code generation. Code is generated sequentially, and users can test and approve each step before moving onto the next. A user study of 10 experts found that DynEx increased design exploration and enabled the creation of more complex and varied prototypes compared to a Claude Artifact baseline. We conclude with a discussion of the implications of design exploration for exploratory programming.

Figures (8)

• Figure 1: The Design Matrix: There are three columns for the Person, Approach, and Interaction dimensions. There are two rows for the levels of specificity: Idea and Grounding. The matrix can be traversed in any order as long as the Idea comes before the Grounding for each dimension. Each entry will take all already-submitted entries as context to generate a response. For example, the Interaction:Grounding will take in all previous entries as context in this diagram.
• Figure 2: DynEx Code Generation: The system first decomposes the project into steps that are modifiable by the user. The user iteratively implements each step. The user can add, remove, or update steps at any point. The backend LLM then generates the UI code -- the user can also interact with the UI . The user can directly modify the code output, debug, and revert to previous versions. The user iterates through steps until the final prototype is complete.
• Figure 3: DynEx's Design Matrix User Interface: Users traverse through the matrix, which guides them through exploring the Person, Approach, and Interaction dimensions relevant to the problem space. For each dimension, users begin on the Idea level by inputting their problem (A). They then brainstorm ideas (B), and can iterate on the ideas (C). They can select an idea ( D) and submit it in the input box (E). They then move on to the Grounding level, brainstorm a response (F), and submit that as well. They have the option to save versions (G), in case they want to move back to the Idea level and explore a new idea. Previous entries used to curate the current entry response are highlighted in yellow (I). Finally, users can can explore the prototype (H).
• Figure 4: DynEx's Implementation User Interface: Users can navigate between existing prototypes (A) and create new prototypes (B). Users are suggested and can select from a list of potential project requirements (C). Users are able to edit the project specification (D) and view/modify placeholder data if it is required (E). DynEx breaks down the project specification into implementation steps (F) which can be edited, added, and removed by users (G). Users generate code (H) step-by-step. Users can iterate via natural language (I), toggle between versions (J), and view generated code (K) and interact with UIs (L).
• Figure 5: Step Outputs: UI outputs created at each step in the usage scenario.