Domain Driven Design conflicts with CoopersInteraction Design...

26 Jun 2007 - 5:58pm
7 years ago
1 reply
504 reads
Dave Cronin
2005

Michael,

Good questions. I must admit that I'm new to the concepts of
Domain-Driven Design, but here's my initial reaction.

Bruce's response is pretty consistent with my experience: The way most
people think about the world (their mental model) is very different than
a well-designed data structure. The unfortunate reprocussion of this is
that (especially on products designed by engineers) data structures are
are often designed first, and then user interfaces are built so that
they reflect the underlying database architecture. The end result of all
this is usually that the resulting product/Web site/service is horrid to
use.

That said, your comments towards at the end (excerpted below) are
certainly intruiging. As an interaction designer, I certainly have no
objection to your suggestion to "implement the mental model", assuming
that it can be done in such a way that the performance is good enough to
deliver a fluid user experience.

Unfortunately, my experience suggests that most engineers that I've
worked with would have some objections to the idea. Given that my
understanding of database design is largely academic, I think I'll leave
it at that.

As far as the persona question goes, let me put it this way: different
personas commonly have different mental models. If two personas' mental
models are in conflict with each other, we usually think that they will
require different interfaces or even different products. We often use a
number of personas to drive and test the design for a single product.

Ultimately, I'm not sure that it seems like there is much of a conflict
between DDD and GDD (Goal-Directed Design, what those of us at Cooper
call our design method). It does sound a bit like DDD is mostly about
software construction, whereas GDD is about interaction design.

Hope this helps.

Best,
Dave

__________

Cooper | Product Design for a Digital World

David Cronin
Director of Interaction Design

office (415) 267 3504
mobile (415) 699 3036
dave at cooper.com | www.cooper.com

All information in this message is proprietary & confidential.

> My personal conclusion is to combine the two approaches: use
> interaction designs and goal directed design to model
> Personas and the mental model of the Personas of the domain,
> but use domain driven design to come up with a ubiquitous
> language to represents the domain and the interaction model.
> In one sentence: "implement the mental model"
>
> What makes me struggle is the different Personas:
> is it possible to come up with one model for all Personas or
> would there be different models for different Personas?
>

Comments

26 Jun 2007 - 11:37pm
Michael Scharf
2007

Dave,

> Unfortunately, my experience suggests that most engineers that I've
> worked with would have some objections to the idea. Given that my
> understanding of database design is largely academic, I think I'll leave
> it at that.

Ok, maybe I am working is a atypical domain: I am working on tools for
software engineers. When I stared working in this domain, 13 years ago,
I was happy that I finally could write software for a domain where I
was an "expert". But now I came to the conclusion that being a domain
expert makes things harder, because it's hard to get into the mindset
of "normal users". (See also my blog entry on DDD:
http://blogs.windriver.com/scharf/2006/10/domain_driven_d.html)

Then I got "About Face 3", I actually bought it because someone mentioned
some of the recommendations in the second part are very useful. But
it turns out that GDD is the real nugget in the book. Now I realize that
there is not only "one user" but there are different personas with
different mental models. It is not "the user". It is not the tasks or
work-flow o start with, it's the different personas with unique goals and
mental models that should drive the interaction design.

> As far as the persona question goes, let me put it this way: different
> personas commonly have different mental models. If two personas' mental
> models are in conflict with each other, we usually think that they will
> require different interfaces or even different products. We often use a
> number of personas to drive and test the design for a single product.

But what do you do with the mental models of the different personas?
Do you formalize them? How do you communicate them to the developers?
Have you ever tried to let the developers create some software that
represents the mental model(s)?

I think mental models can be used in two ways in interaction design.
On one hand we have to understand the mental model of the user, but
on the other hand, we can help the users to refine their mental model
by using the software. If we have a clean language in which we can
describe, the artifacts, their state and the operations, then a user
can learn the story. But the story needs to be consistent. The
perpetual intermediate can act most efficiently if the implementation
is consistent and the software model reflects the mental model.
Then the user can reason and explore new functionality of the system.
If the developers have a totally different model in their mind, then
some parts of the application might be polished by interaction designers,
but when the user leave the "polished path" they are faced with an
implementation that does not match their mental model.

In his book, Eric Evans gives a very simple example of mismatch
between the presentation model and the implementation model:
The "Favorites" in microsofts internet explorer. Most user think
that is a list of names of Web sites that persist from session to
session. But the implementation treats a Favorites as a file
containing a URL, and whose filename is put into the favorites
list. Suppose a user types the following name for a Favorite:
"GDD: Goal Directed Design". He will get the following error message:
"A filename cannot contain the following characters:
\ / : * ? " < > |"
What filename???? If a user would know that Favorites are files then
we could use all the tools (e.g. the file explorer) and knowledge a
user has about the files. But this model mismatch is just confusing.

Eric concludes: "Trying to create in the UI an illusion of a model
other than the domain model will cause confusion unless the illusion
is perfect"

> Ultimately, I'm not sure that it seems like there is much of a conflict
> between DDD and GDD (Goal-Directed Design, what those of us at Cooper
> call our design method). It does sound a bit like DDD is mostly about
> software construction, whereas GDD is about interaction design.

I agree, I think DDD and GDD can work very well together! GDD is
a way to learn about the model and the personas and DDD helps to
implement it in a consistent way. DDD also adds some agile aspects
to the development process. Although the creation of personas has
to start early in the process, DDD helps to refine the models and to
communicate between users, analysts, marketing, interaction designers
and developers (and who else is involved)....

I deliberately choose a flashy title for my post, in the hope to
get some attention of the authors of my new favorite book ;-)

Michael
--
http://MichaelScharf.blogspot.com/

Syndicate content Get the feed