Speak First, Then What? - Collaborative Technologies and Applications for Interactive Information Design - page 154

Figure 2.

ment of a small description. That is what the
user sees when they are looking for something.
Opening attachments is a bore, since the browser
will ask for permission to open or save, then the
application handling the document starts, and then
the document might not be what the description
promised. After a few experiences like that, users
quickly learn that leaving through the content is
extremely tedious and to be avoided.
So what happens to all those documents pub-
lished? They turn into gravestones, only read by
the determined. They turn into trees falling in
the forest: does anybody hear them? The im-
mediate effect is disillusionment, frustration
and a deep distrust in the process forcing the
tool upon the user.

Mel advises her to make the content more dynamic,
more relevant to her current work. Mary now starts
to be serious about her own documents. She com-
mits a large number of her “work-in-progress” to
the repository, to make it more relevant and lively.
And then she waits. Waits for comments, emails,
anything. But nothing happens.

The “Functional Fallacy”

Mel is starting to wonder whether the corporate
content structure is such a good thing. The func-
tional content tree seemed to be such a good idea
in the beginning, making it easy for everybody to
find a place for their work products.

How much impact will adding a single docu-
ment have when the repository is rather substan-
tial? Any collaborator will inadvertently ponder
this question. He or she reflects on her own
behavior to judge others. Most folks do not use
repositories extensively. They will go when they
are told (mostly through an email notification), or
when the process they execute demands it from
them. Rarely do we see people “just browsing”
the information.
Network effects play a role, too. Consider
Figure 2 (MacMillan 2001): the number of com-
munication channels grows exponentially with
the team members. The more people work in a
repository, the more overwhelming the commu-
nication task.
The structure of single posts is causing some
of the behavior. Most repositories allow for the
upload of documents, usually products out of
Microsoft Office applications. They then ask for
a description of the contents of the document, a
bit on the author, maybe some keywords or tags,
and that's it. The document ends up as an attach-

Now, that seems to be not such a good idea any
more. The tree structure makes it hard to find
something, unless you have a good idea what
you are looking for. The functional top level does
not help here, but makes people collaborate less
cross-functionally. In addition, there is little tie to
the process of the project itself, the stage gates.
Content is somewhat unattached to the heartbeat
of the project.

In a hierarchical repository, the author needs
to make exclusive decisions on where to place the
content. If the hierarchy is also functional, the flow
of information through the project itself is very
hard to follow. One would have to hop between
different branches of the content tree to connect
the individual content pieces to the whole.
The belief that functional considerations are
more important than process flow drives many