Domain-driven UI design

We have all read and are actively using some sound DDD principles (I hope :-) ).

For some clients I found the approach of discussing the domain model using an ubiquitous language and various diagrams and (perhaps) written documentation just does not work very well. We can have days of workshops with the domain experts, and still, when presenting some iteration of work, the questions and confusion come pouring in.
But that is part of DDD, getting feedback, refining the language and the model, etc.

Now step back a moment, and look a bit differently at solving this communication gap.

We can use UI mockups and prototypes.

There is always the danger of going into too much irrelevant detail too soon, or being side-tracked into application infrastructure, or more work involved in presenting a domain concept on a UI mockup or prototype than with a diagram and descriptive paragraph of text.

However, once again DDD comes to save the day, from there what I call "Domain-driven UI design". What do I mean with this?

We use DDD to design the model, but we use UI mockups, perhaps prototypes as well, as a way of presenting the model we are building to the domain experts, in stead of diagrams or other forms of presenting the model.

These UI mockups still need to strictly adhere to the domain language!

In a project I'm busy with currently, we base all the workshops we have with the domain experts around the UI screens, while still coming back to discussing the domain objects and model while busy with screens depicting those objects.
We still use an ubiquitous language, we still build up a rich domain model, but we use primarily UI designs to present it to the domain experts, because for this specific group of experts that is what they understand best. It is more concrete for them, thus allowing them to give better feedback.

However, it does place a big responsibility on the facilator: he/she must be able to keep the domain discussion from being side-tracked by non-domain concerns that are typically also part of a UI mockup or prototype. At such workshops we do not want to discuss the exact border width to use for checkboxes... (there is a place for such discussions, but not when using the UI as a way to facilitate domain design discussions)

And behind the scenes?

When we go back to our development work, we first update our domain model (wherever that is depicted), then our tests, then our domain objects, and lastly the next round of UI prototype screens and/or mockups. We find that taking the domain model through to the UI level actually help enrich our understanding of it, and ultimately enrich the communication process with the clients, leading to more valuable feedback.

Ultimately good design and good code is mostly about good communication, and using this domain-driven UI design approach has greatly enhanced the communication in a number of projects I've been involved with.

References:
I can really recommend Erik Evan's book on DDD:
Domain-Driven Design: Tackling Complexity in the Heart of Software