Everyone says they want to work on a blank slate. Build something from scratch. No legacy code, no inherited decisions, no one to blame for the constraints. It sounds like freedom. It isn’t. It’s accountability with nowhere to hide.
When there’s no existing system to reference, every decision you make is the system. Every pattern you introduce becomes the convention. Every call you defer becomes someone else’s problem to fix later — usually at three times the cost. Greenfield work feels open until you realize the openness is the challenge. There’s no floor. There’s no ceiling. There’s just you, a blank Figma file, and the question of where to even start.
Most designers approach greenfield work like they approach any other project: define the problem, sketch solutions, iterate. The issue is that approach assumes a stable problem to iterate on. In greenfield contexts, the problem itself is often contested. Stakeholders have different versions of what’s being built in their heads. There’s no existing product to point to when someone’s interpretation conflicts with another. You can’t resolve a disagreement about direction by looking at what already exists — nothing does yet.
Research on design teams confirms what this feels like from the inside: successful design teams harness interpersonal conflicts to reduce uncertainty, while in unsuccessful teams, uncertainty rises after conflict [4]. The difference isn’t whether disagreement happens — it always does — but whether the team has a shared model visible enough to make disagreements resolvable. Without that shared model, every stakeholder meeting risks generating more uncertainty than it resolves.
This is why the first design deliverable in a greenfield project is almost never a screen. It’s a shared question. A model. A framework that gives everyone something concrete enough to disagree with specifically. The goal isn’t to have the answer — it’s to convert vague disagreement into precise disagreement. Precise disagreements are solvable. Vague ones compound.
There’s a cognitive dimension to this worth naming. Kahneman’s work on decision-making under uncertainty shows that when people lack clear reference points, they anchor on whatever comes first — the first wireframe, the first framing of the problem, the first stakeholder who speaks with confidence [1]. In greenfield work, the designer who defines the frame first has disproportionate influence over everything that follows. That’s not a warning. It’s a reason to invest in the framing before anything else is visible.
On the Pax8 monetization project, I spent the first weeks not designing — but establishing a single question that forced alignment across five stakeholders who each had a different product in their head: what does success look like for a partner who uses this in their first week?That question became the design spine for everything that followed. It didn’t answer what to build. It made every subsequent disagreement about building answerable.
Greenfield work also means you’re setting standards in real time with no organisational memory to draw from. There’s no existing interaction pattern to inherit. No one to ask how edge cases were handled before. You’re building the product and the conventions and the shared understanding simultaneously — and the decisions you make in the first phase don’t just affect the first release. They compound into every surface that comes after.
Designers working in this mode need to move away from the view of design as problem-solving with clear, fixed goals toward a more flexible, adaptive approach that embraces ambiguity — while still producing something stable enough for a team to build from [3]. In greenfield work, the goal isn’t certainty. It’s a model that’s clear enough to move forward and honest enough to revise when you learn something new.
The transferable lesson isn’t a technique. It’s an orientation. Greenfield work rewards the designers who treat the absence of constraints not as freedom to go anywhere, but as responsibility to establish the right constraints early — because the constraints you set will outlast the first version of the product by years.
References