Blocks

The operational problem

A cabinet that looks right in a render may be the wrong size for the room. Changing it can affect its materials, hardware, price and production details. Blocks connects those decisions so that the visual design and the information used to build it can develop together.

I lead product and technology work with our product, engineering and design teams. My focus is on the system behind the interaction: what a designer can change, which dependencies must update, and what the next team needs to receive. This is shared work, not a claim of individual ownership over the platform.

Why browser-native design mattered

Interior design moves between conversations, room layouts and product decisions. Keeping the working design in a browser brings interactive 3D closer to that process. A designer can explore a space while working with the product information that makes an option meaningful.

The browser is a delivery choice, not a reason to simplify away the hard parts. A responsive viewport still needs a structured project underneath it. The important product boundary is between what the designer sees and the dimensions, configurations and specifications the system must preserve.

Rooms and catalogues need a common language

A room is more than a background for furniture. Its dimensions constrain what fits. A catalogue item is more than a thumbnail. Its configuration determines materials, hardware and cost. Connecting the two lets the design become a project that downstream teams can act on.

That is why I treat catalogue structure and real-time interaction as the same product problem. A change that looks small on screen can have a long chain of consequences outside the viewport.

Pricing, validation and handoffs

Blocks supports interactive design, pricing and the connection to manufacturing. The goal is to carry design information forward rather than ask every team to reconstruct the intent from an image.

Validation is most useful when a finding points to a specific decision. A missing dimension or a collision is a different kind of problem from a client disliking a finish. The first can have an explicit rule. The second needs a conversation. The interface should help people distinguish them.

Where rules beat generation

When a question has a definite answer, I prefer a rule that can be inspected. Dimensions, allowed configurations and pricing dependencies need repeatability. An attractive generated result does not make a cabinet fit or turn a concept into a manufacturing specification.

Generative tools have a different job: help a designer explore what a space could become. Once a direction is selected, Blocks carries the measurable decisions into pricing, validation, and production.

An earlier InCo AI integration created a path between visual exploration and Blocks. Designesto is presented separately here because its current public case covers exploration, revision, and communication rather than every structured capability inside Blocks.

Relationship to Designesto

Designesto develops the concept and revision side of this work. Blocks serves the structured design and operational side. The useful connection is the boundary between them: explore a direction, then resolve the measurable decisions needed to carry it forward.

Square Yards had an immersive-technology foundation through PropVR before I joined. This work builds on that foundation and on the experience of the teams delivering interiors.