Category: Design

MIT’s John Maeda on design and simplicity

The Laws of Simplicity (Simplicity: Design, Technology, Business, Life)

Rating: 4 out of 5

Author: John Maeda

Year: 2006

Publisher: The MIT Press

ISBN: 0262134721

Here is an example of a short, little, book that benefits from the author’s decision to keep it focused. Maeda is a designer/computer scientist at MIT’s Media Lab and he consciously limits this book to just 100 pages of reflection on why and how you might seek simplicity in a technology-centric world.

While I easily read this book in an evening (while waiting for my 13-year old to finish hockey practice), it is a book and set of ideas I can expect to revisit multiple times. Although Maeda’s own background is primarily in product design, his insights are equally applicable to other design realms.

For a long time, I’ve maintained that if you are serious about improving knowledge work for yourself or others, then design has to become one of your core skills. This book should be on your shelf. Maeda also provides a website specifically for the book, laws of simplicity, and has a blog, Simplicity, he has been writing for the past two years. Both look to be excellent resources that I’ve added to my reading lists.

Tags:

More on email and project management

Lars Plougmann started a discussion last August of the role of email in project management that triggered a post on my part back in October. Lars has posted a nice summary of the discussion that flowed from his original post with links to many interesting posts on the topic. His conclusion:

Email is about messages and messages have proven useful for thousands of years. (Part of the reason that RSS is successful is that a feed can be presented as messages). Email software takes the strong conventions pertaining to messages and integrates them with the centuries old inbox paradigm – which itself was a way to transition from an industrial society to the information processing organisation by mimicking a conveyor belt. Altogether a very powerful concept which is the reason that email is how work gets done in today’s businesses.

It is only for a decade or so that we have achieved the ability to work together in the new ways that we have started to call collaboration. Our challenge is to explore what we can do with collaboration while weaving into it the message style of communication. Messages and inboxes (a.k.a. email) are an undeniable part of the future, but as concepts they will be fused with transparent, discoverable, content-persistent, workflow-enhancing, buddy-list-integrated, taggable and action-supporting collaboration tools.

mind this.

Worth your time to explore, both for the discussion and some other voices examining the changing nature of work.

Why email continues to be a poor project management tool

There’s no doubt that anyone who devotes a minute’s thought to it will conclude that email is a nearly useless tool for project management. Why then does email continue to be the default tool for most project management activity?

My first thought is that few people, in fact, devote any thought to the systemic role of communications in project management settings. If they consider communications at all, they assume that sending messages implies that they will be effectively received. That is not a symmetry that can be safely assumed.

For those experienced and wise enough to get past that barrier, they still need to become aware of the spectrum of potential choices for technologies to support relevant project communications and to invest design effort to use those technologies to create an effective communications environment. Ploughmann’s 10-to-1 rule is a good starting point to keep in mind as you start that design effort.

Lars Plougmann’s 10-to-1 rule of Email

My pal, Lars Plougmann provides us the fundmental law of the universe that demonstrates the stupidity of email-based collaboration:

#9 people read the email
# 8 people file the email (in their private folders, thereby duplicating effort)
# 7 people are interrupted in their work or thoughts when the email arrives
# 6 people will never be able to find the email again
# 5 people didn’t actually need to know about the change
# 4 people joining the project in the next phase wouldn’t have received the email
# 3 people will be able to find the email again, should they need to
# 2 people will check back to the email at a later date when they need the information
# 1 of them will understand the email in context, be able to find it at a later date and act on it

It’s like a vampire, sucking our plasma.

tags: , ,

Diligence vs laziness – Complexifiers vs simplifiers

Scott Berkun offers an alternative characterization of innovation than the diligence/laziness issue that I dicussed last month. Life is complicated enough; we don’t need more folks adding complexity just of the sake of complexity (or job security).

There are two kinds of people: complexifiers and simplifers

There are several thousand ways to complete the sentence “There are two kinds of people, those that…” And in case the universe wouldn’t be complete without another, here’s one more.

There are two kinds of people: people that make things complex and people that simplify.

…

[Berkun Blog]

Can't we please try to solve real technology problems for real users?

Why does Scoble choose to deliberately misunderstand Tim Bray’s thought experiment about Microsoft using ODF as the underlying core document format for Office? Robert isn’t dumb, so I have to assume his response is a deliberate misreading of what Bray is suggesting. It’s reflective of all too many technical arguments.

As a user of technology, my devout wish is for technologists to make a real effort to make my life simpler. Fortunately, or unfortunately, I have enough gray hair that I no longer have any expectation that the real world resembles the one I wish existed. Microsoft’s approach to making my life simpler, of course, is to persuade the entire world to use the same version of Office. In the world I live in (where 90% of my documents are simple paragraphs of text with a bit of bold and italics thrown in, as Bray suggests), I can’t even count on compatibility between different versions of Microsoft’s own differing versions of Office.

My solution over the last several years is twofold. First, when I do work on documents that are developed, reviewed, and edited by a group that frequently crosses several organizational boundaries, I end up working with lowest common denominator features and functions of Word, Excel, or Powerpoint. If I’m lucky I get to use maybe 5-10% of the features available. Don’t even get me started on Word’s notion of version control, Track Changes. If this part of my strategy is as common as I suspect it is, I might be trying to muddy the waters too. If Office did put ODF at the core of its file formats, I doubt that I would ever bother to use any feature that depended on a Microsoft specific extension.

The second element of my personal strategy has been to treat Office products and file formats as my final output formats only. I do somewhere between 75-90% of my knowledge work today using tools that help me create and manage ideas and substance first and foremost. I wait until the last possible moment to transfer this work into Office formats and tools and, when possible, bypass Office entirely. Frankly, I don’t really expect Microsoft to be terribly interested in helping solve my knowledge work problems. Making it easier to share my work among colleagues and clients would be a good step in the right direction. But, I expect that looks like a threat to the installed base that Microsoft will go to great lengths to avoid.

Tim Bray wants Microsoft to make Office support ODF.

Tim Bray just told me (and my fellow Microsofties) to do more work. He wants us to convert Office to support the open document format from OASIS.

Tim, I think you are GREATLY overstating the point when you say

Design as a signature skill for knowledge workers – ESJ Column

(cross-posted at Future Tense)

Over the summer I wrote a column for the Enterprise Systems Journal that I neglected to point to at the time. The broad point I was trying to work out was that for all the recent attention to issues of innovation and design, the focus has been on addressing the needs of the organization.

Design thinking and design skill are equally, if not more, pertinent to individual knowledge workers. My wrap up there was:

Design is a talent, but it is also a skill, and whatever talent we were graced with, the skill can be developed. Few of us will rival MacGyver (few of us have a scriptwriter and props department handy either), but we can learn to start looking at the world around us as potential resources with more possible uses than intended. We can start to see opportunities to make small changes that will lead to a better fit between our resources and our problems. [ESJ: Design as a Signature Skill]

This is part of a more general trend of organizations needing to deal with how to strike a new balance between execution and design. In the last century, that balance was one person thinking design for every hundred to thousand doing execution. Today, that ratio needs to be much closer to one to one. Moreover, that balance will often have to be managed within each of us as knowledge workers. Perhaps that is one factor that accounts for the relative strength of small organizations versus large ones.

What is an information system?

A nice little reminder from Espen on the value of keep design simple and local.

As much as many of us like shiny toys, it can be too easy to lose sight of the real objective of an information system.

Some years ago (December 1998, according
to my email archive) I participated in an online discussion on the
ISWORLD mailing list, about what an information system really is. I
posted this story, which I had heard told somewhere but never found a
source for:

A
CEO with hotel chain A found himself having to spend a night in a hotel
from hotel chain B. Naturally, he was very curious as to what kind of
information systems they had, and resolved to keep an open eye for
competitive use of IT. As he approached the reception for first time,
the woman behind it smiled at him and said “Welcome back, Sir!”

Flabbergasted,
he said “But…it is 12 years since I was here last! How could you know
that I have stayed here before, what kind of advanced information
systems do you have that can store and find the fact that I was here 12
years ago?”

“Well, it is really very simple”, she said. “When
the doorman opened the door to your cab, he asked if this was your
first stay with us. You answered no, and as you walked through the
door, the doorman looked at me through the window and touched his nose.
That told me that you should be welcomed back….”

Moral of the story: Information systems don't have to mean information technology….

I
was going to use this story in a paper I am writing, did a Desktop
Google search for it – and found it not only in my email file, but also
on a number of web pages (here and here, in addition to a previous story here).

It is kind of fascinating to see how these things move, but I still don't know the real source of that story – does anyone?

(And incidentally, this story is an excellent teaching device…)

[Applied Abstractions]

Designing for Experience – Rettig and Goel

Marc has always done superb work and this is no exception. Full of
ideas you can adapt to all kinds of design problems. It is also an
excellent example of what you can do with presentation materials if you
are willing and able to take the time (and are as talented as Marc).

This presentation
made by Marc Rettig and Aradhana Goel is one of the finest examples of
using down-to-earth methods and practices to create engaging user
experiences. [PDF file: 7.5MB]]

How low can you go?

Some interesting point-counterpoint on the relative merits of
organizational scale, but I can’t help but smile at the notion the 80+
employees constitutes “big.” To me the more interesting question here
is how low we’ve been able to drive the scale of micro-businesses such
as 37Signals who are able to have impact and presence far beyond their
size because they are able to operate within the largely open ecosystem
that is the internet.

Clearly annoyed by all the attention on small teams, Mena Trott goes on the record to defend big
(relatively speaking). I especially enjoyed her comments because she