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 the design on screen and the information used to build it change together.

I lead product and technology for Blocks, working with our product, engineering and design teams. My focus is the system behind the interaction: what a designer can change, which dependencies must update, and what the next team needs to receive.

Follow one cabinet change

Say a cabinet needs to be narrower to fit a room. This walkthrough is illustrative and uses no customer project or internal configuration.

1. Start with the room. The available space constrains the cabinet width. The visual change needs to refer to a dimension the system can use.
2. Resolve the configuration. A new width can affect the cabinet’s components, materials and hardware. Those choices need to remain valid together.
3. Carry the decision forward. Pricing and production information need to describe the revised configuration, so the next team can work from the same decision the designer sees.

So I treat a change like this as one connected update to the project’s information, and the design carries its dimensions and specification into the handoff. The public Blocks launch introduces that design-to-production scope; this walkthrough is the reasoning behind it.

Why browser-native design mattered

Interior design work happens across conversations, room layouts and product decisions. Keeping the working design in a browser puts interactive 3D where that work already happens, so a designer can explore a space alongside the product information that makes each option meaningful.

Running in a browser doesn’t make the hard parts optional. A responsive viewport still needs a structured project underneath it. The line I care most about is the one between what the designer sees and the dimensions, configurations and specifications the system has to preserve.

Rooms and catalogues need a common language

A room’s dimensions decide what fits. A catalogue item’s configuration decides its materials, hardware and cost. Connect the two and the design becomes a project that downstream teams can act on, which is why I treat catalogue structure and real-time interaction as one product problem.

Pricing, validation and handoffs

Blocks supports interactive design, pricing and the connection to manufacturing, so the teams after design receive the design information itself instead of reconstructing 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 are better at a different job: helping a designer explore what a space could become. Once a direction is chosen, Blocks carries the measurable decisions into pricing, validation and production.

Relationship to Designesto

An earlier InCo AI integration created a path between visual exploration and Blocks. Designesto has its own case study because it covers the exploration side (concept, revision and visual communication), while Blocks resolves the structured design and production decisions that follow.

What it builds on

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.