Designers think in flows. Developers think in data. That's the real friction.
· 1 min read · Collaboration, OOUX, Product Design
There's tension during handovers. Extra meetings pop up. Sometimes a whole new role – a product owner or manager – exists just to translate between the two sides. Why? Because we're trained differently.
UX designers think in flows and stories – actions. Verbs.
Developers think in data models – structured objects. Nouns.
And that causes a real problem. Developers often have to reverse-engineer the design just to figure out what the data model should be. And the designer is usually left out of that conversation.
I realised this wasn't just a handover issue – it was a flaw in how I thought about UX and product architecture. So I changed the way I work.
I started with objects, not just flows. Now I map what actions go with what objects before any prototyping, and I create data models with actions and connections.
That small shift made a big difference:
- Speed – backend and design teams can work in parallel
- Optimisation – no more bottlenecks or endless back-and-forth
- User-centered data – built around what users actually need
- Less stress – fewer misunderstandings and meetings
- Future-proofing – a solid foundation that scales
Designers and developers don't need a translator. They just need a shared language.
More writing
Where does intelligence belong?
Most AI briefs say “add an assistant”. The better question is where AI should help, and how much. Five rules for designing AI into a complex product, with an example from KNIME.
AI UXExperience architectureProduct DesignAssistant usage is not the metric. Resolution is.
Teams measure AI features by how often people use them. That rewards the wrong design. Five behaviours that tell you whether an intelligence layer is doing its job, and how to instrument them from the first release.
AI UXMetricsProduct Design