Posts tagged collaboration

Design is the shared language for collaboration

In my ongoing search for contemporary definitions of what design is, i am currently reading Making Meaning by Steve Diller, Nathan Shedroff, and Darrel Rhea. Making Meaning is about Experience Design – an approach to the conscious creation of meaning in products and services, according to the authors. I bought the book because i have great respect for Nathan Shedroff’s work and got a lot of inspiration from him in the past.

Although i don’t like the book in particular – too much self-praise for their consulting firm – i think it’s worth a read. In chapter 5 the authors share their understanding of design. Quotes:

When we speak of design, we are talking about a mechanism for consciously creating value based on truly understanding customers as people and, ideally, caring about, having empathy for, and being compassionate towards them […]

This broader definition of design should not be confused with invention, which does not require the production of value to customers […] Inventions are often demonstrations of capability […]

(p.58)

This is the interesting thought that design can be distinguished from other creative roles by the goal of understanding the customer. Consequently, design is – amongst others – an internal communication task:

Design [is] the shared language for collaboration

(p.64)

I like this! It’s true, i can tell.

3 reasons why i hate wikis, too
March 17, 2007 blogs collaboration wiki

Stowe Boyd picked up a point from Ian Ketcheson who wrote: „Wikis: Am I the only one who gets frustrated?” No! Of course not! We poor enterprise wiki victims, we are all frustrated! And i can tell why, it’s no rocket science:

Wikis do not incorporate the time dimension.

Any enterprise wiki user knows the problem: there is a lot of outdated contents you have to deal with. Knowledge often has a short half-life period and is useless afterwards. But nobody cleans up your knowledge base, because its all self organized and nobody is responsible. In effect, the ratio between useless and useful information gets worse and worse every day. There is no functionality that makes fresher information more relevant. Sometimes you might wish for an autodelete feature after some time…

Wikis are focused on documents, not people.

Wikis dissolve authorship”, Stepanie Booth makes this point in the discussion thread on Stowe’s post. Perfectly right. In a wiki, you don’t have the view on a specific person’s work. That’s a threat because of two reasons: first, people can’t be proud of their own work and show it to others, that will lead to decreasing motivation earlier or later. Second, other people can’t judge relevance of a piece of information because they don’t know who was the originator (this information is hidden in the version history).

Wikis require structured information force you to structure information upfront, which is a roadblock to information flow

A wiki is an approach to structured information – despite the loose linking of pages. You have to choose the place to leave your information first, and there are conventions that authors have to respect, e.g. summary and introduction at the top, references at the bottom etc. This makes a lot of work for you when you just have an idea or a thought that is worth to share with others. In the end people keep their information or – thats the case in the company where i work – they spam the staff mailing list.

What will work better than wikis for enterprise collaboration? Probably blogs do. I like Stowe’s idea of aggregating posts and comments via RSS to something like a discussion thread. I will think about it.