A software book's best design lesson: a model is shared understanding

Over the holiday break, I started reading Domain-Driven Design by Eric Evans. It's a software engineering book, not a design book, but the first chapter changed how I think about my own work.

Evans describes a "domain model": the team's picture of the problem they're solving. Three ideas stuck with me:

• A strong model takes engineering, product and domain experts working together. No single role gets there alone.
• The model changes as you learn more. That's expected, not a failure.
• A domain model is shared understanding. The diagram is just a record of it.

That last one landed hardest. As a designer, I'm often the one drawing the boxes and arrows, and it's easy to treat the diagram as the deliverable. But if engineering and product don't see the same thing when they look at it, the diagram hasn't done its job.

So when I make a flow or a map now, I ask a different question. Not "is this accurate?" but "would everyone in the room describe it the same way?"

In practice, that means asking for definitions of words we all think we know, like "case" or "referral." Their meaning can change from one customer to the next, so I'd rather define them out loud than find out halfway through a project that we meant different things.

Then I write them down where the team already looks. At my current company that's Confluence, but the route there is a little unusual: I write definitions in Writerside from inside Cursor, and Writerside syncs them to Confluence. I lead implementation engineering and also work as a UX designer, so keeping definitions where both sides look is how I contribute to our shared understanding.