Before the diagram, ask a better question.

Two people can look at a diagram, nod along and leave with completely different ideas about how the system works.

One reads an arrow as “send this and wait for an answer”. The other reads it as “send this and get on with the next thing”. Both think they’ve agreed. They haven’t.

Before we get too attached to the boxes, I want to know what we’re trying to decide. Where does a responsibility belong? What happens when something is unavailable? What should the person using it expect?

Let people explain what they see

A quiet room doesn’t tell us much. Give people a chance to explain how they think it works, especially the bits they’re unsure about.

If the explanations don’t match, that’s useful. We’ve found something to work through while it’s still a drawing. I’d rather have that conversation now than discover the difference after we’ve built it.

Try one awkward situation

Here’s an invented example. An application saves an order and sends a message to a warehouse. Now the warehouse is unavailable.

Do we ask the customer to wait? Accept the order and deal with it later? Who knows there’s still work to do?

We need to agree on that behaviour before choosing how the connection works. Drawing a more detailed arrow won’t settle a disagreement about what we’re promising the customer.

Keep the unanswered questions

We don’t have to settle everything in one discussion. If something is an assumption, mark it as one. If we don’t know yet, leave the question where the next person can see it.

By the end, I want us to know what we’ve decided, why we’ve decided it and what’s still open. Then we have something we can build from, question and change when we learn more.