Protosynthetic

This was the design task I received during an interview process. It described an object and a scale, but left the actual problem open. Who would use the elevator? What kind of building would it serve? What would accessibility, traffic and operating constraints require?

My background reporting on architecture made the missing context particularly apparent. An elevator interface sits inside a larger physical and human system. A residential tower, a hospital and a freight facility would lead to very different decisions.

I read how other people approached the question and saved the discussions below. They helped me focus on the assumptions behind a proposed solution. The useful work was identifying which questions needed to be answered before committing to an interface.

I considered two ways to organize the interview. Parallel sequences could explore different directions independently, including different levels of creative variation. The drawback was that a series could stay narrow, and the relationships between separate threads would be difficult to see.

A branching tree offered a clearer structure. A follow-up belongs to the answer that prompted it, while neighboring branches explore other aspects of the same problem. This supports both a broad survey and a deeper investigation without detaching either from the original objective.

The tree's structure also gave the interface something tangible to show: where a question came from, what had been answered, and which direction the exploration was taking.

From drawing to a usable interface

The complete drawing brought together setup, a tree, an answer panel and generation. The prototype evolved that drawing into readable question-and-answer cards beside the current question. Compare the layout and the two central areas below.

I developed a specification covering the flow, data structures and agent responsibilities, then refined it through sketches and conversations with an LLM. This made the connections between the interview, the knowledge material and the generated outputs explicit before building them.

The system had four roles: organize supplied knowledge, generate questions, synthesize requirements and generate a wireframe. Separating those responsibilities let each stage use the previous stage's output for a defined purpose.

The question tree carries parent-and-child relationships. The requirements document captures the interview's interpretation, and the generated interface gives that interpretation a concrete form to inspect. Keeping these artifacts visible makes it easier to understand where an output came from.

The interview can lead to generation at different points. A researcher role synthesizes the accumulated answers into requirements; a designer role uses those requirements to produce the interface and supporting specifications.

That creates a loop: explore, generate, inspect, and keep asking questions. An output can expose something missing from the brief as clearly as a question can.

Sixteen original variations

The output collection returns to the original elevator assignment. The designs vary in their arrangement of floor entry, operational status, voice controls and accessibility options. Seeing them individually makes those differences inspectable.

These are generated design artifacts from the original work, not evaluated elevator systems. The collection shows the range of directions available for a designer to examine and refine.

What I would explore next

I want to make the decision tree revisable: change an earlier answer, see which requirements it affects, and inspect the implications for later designs. I also want to improve the quality and usefulness of the generated interfaces, rather than simply produce more variations. These are directions for further exploration, not shipped capabilities.