Dynamic Space Partitioning lets a single ballroom split into eight independently-lit rooms, and merge back, as operable walls open and close. I designed the system that models those moving walls, sub-areas, and devices into one configuration any installer can run.


A partitioned area carries a set of sub-areas and the walls between them. Each wall is wired to a contact-closure input, so when it physically opens or closes the lighting follows, sub-areas merge into one zone or split into many, automatically, with no one touching a control panel.
Partitioning lets large rooms be temporarily divided into smaller areas to increase the flexibility of a space. A single venue can host one 400-person gala in the morning and five simultaneous breakout sessions in the afternoon.
The dividers go by many names, operable walls, operable partitions, movable partitions. Whatever you call them, the lighting has to keep up: each room lit on its own when closed, unified when open.
Lighting platforms assume a fixed floor plan. Partitioning breaks that assumption: the walls move, so the relationship between rooms, zones, and devices is fluid. The interface had to make a physically dynamic system feel simple to configure once, and then run itself.
A wall is a relationship between two rooms, not a device. There was no object in the platform that modelled "these two sub-areas merge when this wall opens."
When a wall opens mid-event, the lighting must unify instantly, and re-separate when it closes, without staff recalling scenes by hand.
Sub-areas, walls, joins, devices and contact inputs are a lot to set up. One wrong mapping and a wall lights the wrong rooms. The flow had to be guided and hard to get wrong.
I led the partitioning experience end to end, defining the concept model, pitching it at the User Advisory Group, iterating the information architecture through three major versions, and delivering the configuration flow across mobile, tablet, and desktop.
Model the space the way the people running it think about it, rooms first, walls as relationships not the way the hardware is wired.
Get that mental model right and the contact-closure plumbing disappears behind a floor plan anyone can read.
{{ verBody }}
Step through it. The shipped desktop wizard takes a room from "Partitioned" to fully wall-aware.
The Rose Ballroom, 8 sub-areas, 7 walls. Tap any wall to open or close it; sub-areas joined by an open wall fuse into a single lighting zone.
Each sub-area carries 2 chandeliers, inner & outer cove, a wall station and a CCI. When walls open, their devices fall under one zone's control, scenes, occupancy and daylight all follow.
An installer configures partitions on a phone at the panel; a venue manager runs the room from a wall-mounted tablet or the web. The same three-step model, sub-areas → walls → devices, scales to each screen.


Partitioning was a lesson in modelling a physical, dynamic system in software. The breakthrough wasn't a screen, it was deciding that rooms, not walls, should be the primary object, and letting the wall hardware fall behind a floor plan anyone can read.
Getting there took three honest iterations and a willingness to throw out a technically-correct V1 that users couldn't reason about. The consolidated flow now reads the same on every surface, and the patterns, relationship objects, guided wizards, live state from contact inputs, carry forward into the rest of the WaveLinx platform.