Design for the User Nobody Asks, and the Whole Space Gets Better

There's a wave of public design work right now that all starts from the same odd premise: build for the user with the least power in the room. Kids. Not the commuters, not the tourists, not the office towers. The people who never fill out the survey and never sit in the review.

It sounds like a charity move. It isn't. When these teams design for the weakest user, the space gets better for everyone who uses it. That's a lesson that travels straight into your roadmap. Let me catch you up.

The user who never files a ticket

Start with the frame, because it changes everything downstream. Since 1989, a UN convention has listed play alongside food, shelter, and healthcare as a child's right, not a reward. Designboom makes the point plainly: play shows up as "an amenity added after the 'real' infrastructure has been delivered," tucked into a corner once the serious needs are met.

You know this move. Every product has the user whose needs get pushed to "phase two." The one who can't escalate. The frame here says stop treating that person as optional. If a need is real, it belongs in the core spec, not the backlog you never reach.

Constraints beat features

The research the piece leans on has a sharper edge than "kids need swings." Stuart Lester and Wendy Russell argue play depends on "time, freedom, safety, social interaction, and environments rich in possibility" far more than on "prescribed activities or elaborate equipment." Aldo van Eyck's postwar Amsterdam playgrounds proved it: simple domes and sandpits with "no prescribed route or intended game."

Read that as a product note. You don't serve your hardest user by shipping more features at them. You serve them by removing friction and leaving room for uses you didn't plan. The best designs here define the constraints, then get out of the way.

Make the expert start over

The Rockaway Beach ping-pong tables push this the furthest. Six artist-designed tables rise from the sand, and each one breaks the game it looks ready to host. A tentacle blocks the serve. Holes swallow the ball. The show, called Between Tides, "makes skill temporarily useless."

That's the move worth stealing. By making expertise worthless, the tables put a first-timer and a champion on the same footing. Both are beginners. Both experiment. Your power users have muscle memory that hides how confusing your product is for a new person. Sometimes the fix is designing a moment where the expert has to figure it out fresh, same as everyone else.

Building for one user reshapes the whole site

The city-scale projects show the payoff. Snøhetta's unbuilt Banpo playscape in Seoul spanned 38,000 square meters and treated "infrastructure, flood management and recreation as parts of the same urban system." A playscape that also filters water and buffers a flood. One user's need pulled three others along with it.

Kinzo's Berlin proposal does the same. They dropped a 100-meter pool into an overlooked strip beside Potsdamer Platz, a park that was "highly visible from surrounding towers yet sparsely used at ground level." Co-founder Karim El-Ishmawi calls it "the living room of Potsdamer Platz." One bold amenity for casual use turned a pass-through into a place people return to.

The deep cut

The +Pool story in New York is the warning label. The floating pool cleared 17 approvals across city, state, and federal agencies and still slipped its public demo to 2027, because it can't discharge waste until a separate flood-resilience project finishes. And one of the four founders, Dong-Ping Wong, says he was frozen out after raising concerns about diversity to the board.

Here's what that means for you. Deciding to serve an underserved user is the easy part. Delivering it means dependencies you don't control and hard calls about who's actually in the room when decisions get made. The reframe is cheap. The follow-through is where teams either mean it or quietly drop the user back into phase two. Budget for the plumbing, not just the vision render.

Three questions for your team

• Who is our version of the kid in the room, the user with a real need and no way to escalate it? Name them, then check if they're in the core spec or the backlog.
• Where are we shipping more features when we should be removing friction and leaving room for uses we didn't plan?
• If we commit to serving that user, what dependencies and internal decisions could quietly gut it later, and who owns them now?