The Missing Interface

Bamboo craftsmen of Sikkim and Echostream

I first encountered the bamboo craftsmen in Sikkim through a design collaboration with Echostream. The craftsmen produced lamps, furniture, and other objects for sale. These were successful products, but their forms had already been established, and the craftsmen’s work was largely shaped by the orders that came in.

The collaboration grew out of a conversation I had with Sonam Gyaltsen, the co-founder of Echostream, about my earlier graduation project involving bamboo. We began with a broad inquiry: how could technology enable bamboo craftsmen? I did not yet know what form that technology would take. I only knew that the answer could not be to replace the craft or the knowledge embedded in it. It had to create more room for that knowledge to participate.

When I first saw the craftsmen’s work, I was amazed. I did not immediately see a problem that technology needed to solve. The craft was skilled, the products were being made, and the collaboration was functioning. It was only after spending more time with the craftsmen and observing how the work was organized that I began to notice what was missing. They had deep knowledge of bamboo, but that knowledge was mostly used to produce established forms. They did not have a way to turn the problems they noticed, or the possibilities they saw in the material, into new forms of their own.

I began exploring whether computation could help create that room for exploration. The first version of the tool was an algorithm that could take a three-dimensional form and translate it into a physically viable bamboo weave. It combined computational geometry with an understanding of how bamboo strips behave, allowing us to imagine forms digitally and then work out how they could exist materially. At that point, I believed that if I could generate complex forms, I would have found a way to expand what the craftsmen could make.

That question led to our first prototype. The craftsmen were in the middle of producing craft items for the studio when I pulled them away from their work to show them what I had built. I wanted to demonstrate the capabilities of the algorithm and understand what they made of it.

As I guided them through the prototype, they began to see how small changes in the weave could shape the overall form. One of them told me that learning to make something like this takes years, while I had managed to demonstrate it with a computer in a few months.

That was the moment I understood that they could relate to what I had built. They recognized the value of the tool because they recognized something of their own knowledge inside it. The tool had made one part of their tacit knowledge visible, something that could be documented, processed by a computer, and shared with designers, architects, and other craftsmen.

But the tool had not yet given them agency. I was still responsible for the input. The algorithm expected a 3D model, and I was the one who had to imagine and create that model before the craftsmen could use the system. The algorithm could generate forms, but the craftsmen still could not see how to enter their own ideas into it or fit it into their workflow.

When the algorithm was not enough

In practice, I was creating the models in Rhino and Blender. The craftsmen did not yet have much say in the forms I was generating, not because they lacked ideas, but because this virtual world was unfamiliar to them. Their imagination had been shaped by years of producing simpler forms for the studio. They knew what bamboo could do, but they had not been given a way to explore everything it might do inside a digital environment.

In virtual software, almost anything is possible. In bamboo, every possibility has to negotiate with material behaviour, strip length, curvature, and the physical logic of weaving. The algorithm sat between these two worlds. It could translate an unconstrained virtual form into a physically viable weave. But because I was the one creating the virtual form, I was still the person deciding what could be explored.

The realization developed over the next few weeks. I knew something was missing, but the craftsmen could not tell me what it was. They did not yet know what a computer might make possible, so they could not point directly to the barrier.

This was not because they were opposed to technology. They used smartphones every day. WhatsApp, Facebook, and YouTube had already made parts of the internet accessible to them. The computer was alien only in relation to their work. Nobody had yet made the same kind of translation for their craft.

I began to look at the tool through an input-output lens, something I had developed during my graduation project in bionics and computation. The algorithm itself was capable enough. It could take a 3D model and translate it into a physically viable weave. The problem was the input. The craftsmen had no way to produce the 3D model that the algorithm expected.

That was when the structure of the problem became clear to me. The algorithm did not exist in isolation. Its input and output determined how it could participate in the larger system around it. I had built a capable computational element, but the connection between that element and the craftsmen was missing.

Finding the right surface

I had found the missing connection, but I still did not know what the interface should be. The problem was no longer the algorithm. It was finding an input language that made sense within the craftsmen’s way of working.

The answer came from looking more closely at how they made a weave. They always began on a flat table. The first weave was flat, and the three-dimensional form emerged gradually as they worked. Even when the final object became complex, the underlying logic of the weave was understood through its surface: how the strips overlapped, how they interwove, and how each local decision affected what came next.

The 2D surface was not a simplified version of the craft. It was closer to the craft’s actual logic.

I spent time sketching what this language could look like and what the craftsmen should be able to manipulate directly. After several iterations, I built a simple web-based interface around the 2D surface.

Try the weaving tool →

Instead of asking the craftsmen to create a three-dimensional model, the interface allowed them to place valences at individual nodes using numbers.

Valence made visible and manipulable something the craftsmen already understood through practice. It was not entirely new knowledge to them. They had encountered its effects through years of working with bamboo, but nobody had explicitly described it to them as valence or represented it as a value that could be changed.

The default valence was six, so a node with a valence of six appeared simply as a dot. When the valence changed, the number itself appeared on the surface. A local change directly determined how many bamboo strips were available at that point and further along the weave. It also produced a larger effect on the form.

As soon as the valence at one node changed, the weave updated on the two-dimensional surface. A local decision immediately revealed its larger consequence. A valence greater than six produced a surface with negative Gaussian curvature, while a valence lower than six produced positive Gaussian curvature. The craftsmen did not need to know the mathematical term to recognize what was happening. They could see when a surface bent inward or outward and relate those changes to the material behaviour they already understood.

The interface also allowed them to create symmetric or freeform patterns. In the symmetric mode, the tool reflected changes across the surface. This matched the way the craftsmen often worked from top to bottom, as the constraints of the weave became apparent. However, reflection was not intuitive from the interface alone. I had to explain the idea to them. The tool could enforce symmetry, but it did not yet communicate clearly why that symmetry was being created or how the reflection worked.

The interface was still connected to the rest of the system through some mundane steps. Users had to manually export the weave as JSON and import it into Grasshopper, where the algorithm generated the corresponding form in Rhino. I did not yet have the tools to make that connection continuous. It was a bottleneck, but a relatively simple one to teach. I accepted it for the time being so I could test the more important question: could the craftsmen use this language to make decisions about form themselves?

From execution to exploration

The system was not correcting an invalid weave after it had been designed. The validity had to exist in the two-dimensional structure first. Entering a valence changed the structure of the weave, which constrained how many bamboo strips were available at that point and further along the surface.

The two-dimensional and three-dimensional versions had a direct correspondence. The interface defined a flat mesh, and the dual of that mesh, with its structural constraints, was rendered in three dimensions. Each point in the 2D mesh mapped to a corresponding point in the 3D form. The 3D view was not a separate interpretation of the weave. It was the same structure expressed spatially, with the physical behaviour of the bamboo strips taken into account.

With my guidance, the craftsmen first built forms generated by the computer, including a hat and a freeform structure. At this stage, they were still executing forms that I had created. But that execution was important. By building the forms, they learned how to read the three-dimensional output and translate it back into bamboo.

Once they understood that relationship, they became comfortable exploring the interface without waiting for my approval. They began producing forms of their own.

Part of the pleasure came from how little was required to begin. They could enter random valence values and see the form change. Something was always generated, and the system ensured that the result remained physically viable. They could experiment without worrying that a small mistake would make the weave impossible or waste material.

Over time, this play became more deliberate. As they understood the relationship between valence and curvature, the numbers became design decisions. A valence greater than six could create a concave surface, while a valence lower than six could create a convex one. They did not need to use the mathematical language of Gaussian curvature to work with these effects. They could see and feel the difference between a surface bending inward and one bending outward.

At first, the forms were not especially surprising. As I experimented with the system, I was also arriving at similar forms. But as the craftsmen introduced more random valences and increased the complexity of the weave, unexpected results began to emerge. The system started producing forms that neither of us had directly planned.

This was the shift I had been looking for. The tool was no longer only translating a form that I had imagined into something physically possible. It was creating a space where the craftsmen could explore the consequences of their own decisions. They could begin with randomness, discover a possibility, and then make deliberate choices to develop it further.

The first prototypes tested the entire system. They showed that the algorithm could produce physically viable forms, that the 2D and 3D representations corresponded, that the craftsmen could translate the digital form into bamboo, and that the interface could support both independent exploration and deliberate design.

The tool did not make the complexity disappear. It gave the craftsmen a way to enter that complexity, experiment without fear, and develop an understanding through use.

A shared language

The hat and the freeform structure were small prototypes, but they gave me confidence that the complete loop worked. I could move from a decision in the interface, to a valid 2D weave, to a 3D form, and finally to something the craftsmen could build with bamboo.

The next stage was a large bamboo pavilion, developed through a collaboration between Echostream and Studio Interweave. The pavilion was not simply a larger version of the earlier prototypes. At this scale, the exact dimensions and number of bamboo strips mattered. Planning had to begin roughly two weeks before construction, and the craftsmen had to prepare the material in advance.

I needed to coordinate a group of people around one form. We were no longer testing only whether the algorithm could generate a viable weave. Studio owners, architects, designers, students, and craftsmen all had to understand what was being proposed, how it could be built, and what each person would need to contribute.

I set up and facilitated a workshop at Echostream’s space in which everyone could use the interface to explore possible forms, including the craftsmen. Each person was asked to develop proposals individually. We then reviewed the designs together and voted on the one we would build.

The interface gave everyone a shared object to work with. People did not need to understand every part of the algorithm to participate in the design. They could change the form, see what happened, and discuss whether the result was worth pursuing. The craftsmen were not only evaluating forms created by others. They were making proposals of their own.

We also built a small model before beginning the final construction. This helped us understand the form and plan the logistics. By the time we started working at full scale, the craftsmen knew what bamboo strips had to be prepared and in what quantities. The designers, architects, students, and studio owners had a clearer understanding of the structure they were contributing to.

For a while, the usual hierarchy between roles disappeared. The craftsmen brought their understanding of bamboo. The architects and designers brought their spatial and formal concerns. The students brought their own experiments. The studio owners brought the practical context of the project. The interface gave all of us a common language through which those different forms of knowledge could meet.

The tool was not only generating a shape. It was helping me create a process in which a group could coordinate around a shared object. It made the design process more participatory, not by erasing differences in expertise, but by making those differences available to one another.

The pavilion showed me that the limits of craft may not lie in the material or in the knowledge of the craftspeople. They may lie in the absence of a shared language through which different kinds of knowledge can meet. Once that language existed, the craft could be discussed, explored, planned, and extended beyond the forms it was usually asked to produce.

What documentation can do

The pavilion made me think differently about what it means to document craft. Before this project, I might have understood documentation mainly as a way to preserve knowledge, to record a practice so that it could be passed on or not forgotten. But the workshop showed me another possibility.

The documentation did not simply preserve the logic of the weave. It allowed that logic to become active. Because the weave could be represented in a language that both people and computers could work with, it became possible for craftsmen, architects, designers, students, and studio owners to participate in the same process.

That gives documentation another layer. It can preserve knowledge, but it can also connect knowledge to a larger system.

The craftsmen understood the behaviour of bamboo. The architects and designers understood space and form. The students brought their own experiments and questions. None of these kinds of knowledge needed to replace the others. Once they could meet through a shared language, they could combine into something larger than any one person, discipline, or role could have produced alone.

This made me think about the role of computers in documentation. In the twenty-first century, it may not be enough to document craft only for human understanding. We also need to consider how that knowledge can be expressed in forms that computers can interpret and work with.

That does not mean turning craft into data or reducing it to an algorithm. It means giving the knowledge within craft more ways to participate. Once it can be interpreted by both people and machines, it can be explored, translated, shared, and recombined with other forms of expertise.

AI may make this kind of translation easier today. It can help make tacit knowledge visible, connect different vocabularies, and create interfaces between people and systems that previously could not communicate. But the underlying challenge remains the same: the technology has to enter the world of the people it is meant to serve.

The designer as enabler

The project changed how I think about the role of a designer. A designer cannot only be a producer of design. They also need to be an enabler for other people.

That requires a systemic understanding of the situation. The designer has to see how different stakeholders, tools, materials, and machines are connected, and then help those parts work together. In that sense, the designer becomes a translator between different kinds of human knowledge, and increasingly, between people and machines.

For an overlooked stakeholder, a tool is useful only when it meets them where they are. It has to be grounded in their context, their existing knowledge, and the way they already work. The stakeholder should not always be forced to enter the context of the tool, especially when that tool has been designed far away from them, often by people making decisions inside the glass buildings of Silicon Valley.

The weaving tool still has a long way to go. At a technical level, the algorithm needs to account for the thickness of bamboo, especially when the structure is built at a larger scale. It also needs to become a complete product rather than remain a working prototype. Creating the final artifact involves many steps, and the software could eventually guide the maker through the physical construction of the weave, step by step. That would make it more useful, especially for people who are new to the craft.

This feels particularly relevant in the current development of agentic tools. Much of the agentic ecosystem is still designed for developers: people who already understand computers deeply, and who are often the same people building the tools. It is natural that these systems reflect the needs of their creators. But making tools for other stakeholders requires a different kind of sensitivity. It requires people who understand technology deeply, while also understanding people, design, and systems.

That is the kind of role I want to move toward. Not simply building more capable systems, but asking who those systems are built for, who is affected by them, who gets to participate, and who remains outside the process.

The next time you use a tool, a product, or a service, it may be worth asking the same questions: Who made it? Who was it made for? Who does it affect? Who gets to shape it, and who does not?

Those questions are often where better tools begin.