The Data Model That Wasn't There
For a long time I measured my output in screens. Then I designed a clean solution that assumed a data model that didn't exist. That failure changed how I start every project.
For a long time I measured my output in screens. A good week meant a polished Figma file with every state accounted for, pixel-perfect and ready for handoff. It took a failure to show me that the best design work often doesn't look like design at all.
The Failure That Changed My Thinking
It happened early on at Keela, on a first pass at the transaction workflow. I'd designed what I thought was an elegant solution: cleaner UI, better hierarchy, smarter defaults. Then engineering started building, and we hit a wall: the design assumed a data model that didn't exist.
The screen was "right." The system it lived in made it impossible to build.
That failure taught me something I now consider fundamental: zoom out before you zoom in. Before I open Figma, I ask:
- What data flows into and out of this feature?
- What other features share the same data?
- What happens at ten times the current usage?
- What organizational constraints shape what's actually shippable?
Maps Over Mockups
Since then, I've started every major project with a system map: how data, users, and features relate. These maps are ugly. Whiteboard sketches and FigJam files full of arrows and question marks. But they surface hard questions early, when changing direction is cheap.
On Automation at Keela, the map showed in week one that our notification system couldn't handle the volume of events automations would create. We caught it before a single screen depended on it, instead of months later in QA.
And when I came back to transactions after the acquisition, the first thing I drew was the map. It became the most important artifact of that project, more than any Figma file.
What I Look For Now
The designers I've mentored who made the biggest leaps weren't the ones who sharpened their Figma craft. They were the ones who started seeing the system around the pixels: how the data is stored, who else shares it, and which team's roadmap a change quietly breaks.
If you want to practice it, start small. Read your product's data model; you don't need SQL, just the nouns and how they connect. Sit in an engineering standup to listen, not to manage. And before your next project, draw the arrows first.
The best design work I've done didn't look like design. It looked like asking the right question at the right time, in the right room, to the right people.