When to bring in technology?

17 Dec 2004 - 10:00am
10 years ago
5 replies
523 reads
Marc Robichaud
2004

What about the data model or database design? Should we be considering that
separate from the technology?

Sometimes I think the data model should be made before the interface because
an interface that strongly reflects the data model is easier to use. That
is, users can more easily create a mental model of the data. Even a
task-based interface should account for that.

However, I've also run across many projects where the data gets modeled
based on how the user wants to approach the problem. This seems to be more
of a case in search and taxonomy however. Also, I've seen many projects
where the data model was so business centric that it was a major limitation
on the usability of the application.

Solutions? My thought is design data related to search functions after the
interface. Data the model for other data before the inteface while taking
into consideration users' mental models. Any one see holes in that?

Marc Robichaud
Information Architect
Critical Mass

marcr[at]criticalmass.com

Comments

17 Dec 2004 - 11:01am
david gee
2004

Marc Robichaud wrote:

>[Please voluntarily trim replies to include only relevant quoted material.]
>
>What about the data model or database design? Should we be considering that
>separate from the technology?
>
>Sometimes I think the data model should be made before the interface because
>an interface that strongly reflects the data model is easier to use. That
>is, users can more easily create a mental model of the data. Even a
>task-based interface should account for that.
>
My view on this is pretty much the complete opposite. The optimal data
model rarely, if ever, reflects the user's mental model. In any
moderately complex application, the user's goals for any given task will
span across multiple data structures. I've always considered the
interaction designer's chief task to be transforming the underlying data
structure into an interface that conforms to the users mental model.
It's also usually the biggest obstacle :)

On the other side of the coin, designing your data structure around the
user's mental model would be hopelessly inefficient. The whole process
of data normalization pretty much mandates this.

david g

17 Dec 2004 - 11:04am
Dave Malouf
2005

> Sometimes I think the data model should be made before the
> interface because an interface that strongly reflects the
> data model is easier to use. That is, users can more easily
> create a mental model of the data. Even a task-based
> interface should account for that.

Hmmm?

Marc,

I'm pretty strongly in favor of having a data model map to a mental model
and not the other way around. Why? Well, I've noticed that when a data model
doesn't map against the object model that it actually makes communicating w/
engineering more difficult.

So to answer the broader question here is where I think we are:

1. Design as Peter stated should be as technology agnostic as possible,
except when the design problem itself centers around legacy issues of
technology, or the problem is stated where the technology is included in
some way. I think what "ignorant of technology" really means is at the
implementation level. Do I really care if they use an array in the
javaScript or if they actually make a call back to the server? No. What I
care about is the performance and performance should be specified in the
requirement.

2. The design process should begin actually being "interface agnostic". The
beginning of the process should be about defining the problem itself using
as little of technology and interface as possible. It should concentrate on
the goals and motivation of those who are effected by the problem and the
overall task analysis that comes out of that.

3. prototyping should then begin and still be technology agnostic, so that
mental model & task model validation can begin.

4. Finally as the next iterations of prototyping move forward, technical
constraints need to be added to the puzzle so that prototypes move closer
towards reality.

Anyway, that's my take at it. ;)

- dave

17 Dec 2004 - 11:13am
Listera
2004

Marc,

> interface that strongly reflects the data model...

...is the source of my livelihood wherein I charge of a lot of money to do
surgery on failed apps.

Ziya
Nullius in Verba

17 Dec 2004 - 11:27am
Marc Robichaud
2004

Dave G wrote:

> My view on this is pretty much the complete opposite. The optimal data
model rarely,
> if ever, reflects the user's mental model. In any moderately complex
application,
> the user's goals for any given task will span across multiple data
structures.

I didn't mean to say that the Data Model should be the same as Mental Model.
Obviously it's much more complex. However, I've also seen how data models
could have been improved by user research rather than purely focusing on
business rules.

Marc R (that's me) wrote something about:

> ...an interface that strongly reflects the data model is easier to use.

That was to say, when the conceptual model of the interface conflicts with
the data model, there tend to be negative impacts. Rarely the data model
can be completely abstracted in the interface layer, which inhibits the
users ability to form a mental model.

David Heller wrote:

> [A bunch of stuff Marc liked]

Oh yeah. The problem I see with so many design processes is that they are
either too business, technology or user focused. They use documentation
practices that make too many assumptions about the other sides of that
triangle.

Since the work requriement can mean so many different things, my favorite
question is...
Can you describe your entire process without using the word requirement?

Marc Robichaud
Information Architect
Critical Mass

marcr[at]criticalmass.com

17 Dec 2004 - 11:49am
kjnarey
2004

Dave:

>3. prototyping should then begin and still be technology agnostic, so that
>mental model & task model validation can begin.

Perhaps this is semantics, but are you (conceptual) modelling here or
prototyping? I perceive the suggestion of prototyping as being broadly
technology specific, as you are using form elements (html/vb etc.) or a
wheel to navigate etc. Even if it's paper-based you are implying a
technology. This could, and often is, misleading to key stakeholders. In
traditional product design, an object shape would be modelled and tested
(papier mache model?), then perhaps the ideal materials would be tested on
the previously tested shape (steel prototype?). So did the designer have
steel in mind before designing the shape or was the steel chosen as a result
of testing the shape?

Kevin

Syndicate content Get the feed