The before

Pokydo's users are planners building space programs for corporate clients. Pokydo was built around assumption presets: a starting space library, seating assumptions, design assumptions. You picked a preset and the tool calculated quantities from it. You could always change things afterward, turning spaces on and off, but the shape of the work was top-down and subtractive: start from the preset, then prune. The flow was also split across several pages, so editing meant leaving the thing you were looking at.

What I observed

Working with Vocon, a national design firm and an existing customer, it became clear that the preset-then-prune model fit only half of how people program. Some planners build as they go: adding spaces, creating space types no preset contains, setting quantities by hand. The tool treated all of that as a correction to make afterward, when for those users it was the main event. Two mental models of the same task, and the product was fluent in one.

What I designed

• One modular page instead of a segmented flow
• A space table editable in place
• Inline overrides of allocation assumptions and quantities, so the preset became a starting point rather than a constraint
• AI moved to the foreground, with two placements: floating bottom-center, or a sidebar with more room that does not cover the table

SHOT 2: full modular page, wide

What happened

Vocon went from 10 to 16 offices programmed, and 6 of those came in the two months after launch. That is one customer over a short window with other things in motion, so it is not proof of causation. What I can say is that adoption accelerated after the change they asked for.

What I would change

Shipping two chat placements was right for these users, and it is still the decision I would most want to revisit. Configurability is sometimes an answer and sometimes a way to avoid making one.

The problem

A space program usually starts from seat demand: how many people, in which groups. It sounds like one input, but it arrives in different shapes. Sometimes the planner has a real headcount file from HR. Sometimes they know the org but have nothing exportable. Sometimes it is early enough that group-level precision would be false precision. A single input method only serves whichever of those situations it was designed for, and everyone else goes back to Excel.

What I designed

Three paths, chosen by what the user actually has:

• Drag in a spreadsheet, AI parses it
• Set department seating manually
• Apply blanket assumptions across groups

SHOT 5: manual department seating

SHOT 6: blanket assumptions across groups

Why this one

The instinct is to pick the best input method, usually the most automated one, and push everyone toward it. That optimizes for a demo and fails the user whose data does not cooperate. Treating the three as equally valid, rather than as a happy path plus two fallbacks, changed what the interface had to communicate: none of them is a downgrade. The goal was a page that absorbs a lot of complexity and variation from one user to the next, without sacrificing detail for the people who want it or speed and simplicity for the people who value that.