Ah my.
Yes, Terry and Gunnar do live on different planets. On is called
"Engineering" the other is called "Design for People." I find both of
them to be correct and compelling for life within their planet. I,
myself, am a space traveller, and have inhabited both.
Terry explains how an engineer goes about the task of design. Figure
out the requirements, use engineering tools (mathematics,
computer-assisted aids, handbooks, ...) to determine the structure and
composition of the desired outcome. Pass the plans on to the
construction or manufacturing crew. And that is that.
I used to design amplifiers and computer circuits. Yup, Terry is correct.
To Gunnar, life is never that simple. Requirements beforehand? As soon
as the system/product/artifact/system is finished, the very people who
gave you the requirements argue that the requirements are wrong.
Moreover there are no computer tools, no mathematics, no handbooks for
getting the sense and feel of the design to be right.
Terry says that typographical design is straightforward. Gunnar,
however, does typographical design. He knows that yes, if all you care
about is fitting the words to the available space, it is
straightforward. But if you want the type to communicate the correct
image to the people reading the type, convey the correct emotional
feel, have the proper aesthetic balance and feel, and also be readable
clear and distinctive, then no, it is not straightforward. It does
require trial and error.
Want to see the difference? Examine a design book on a Kindle or Nook
eReader. Then examine the same book in its printed form: dramatic
difference. There may not be a critical difference for a thriller or
pop-fiction, but when it comes to serious books, the difference is
huge. I know: my books are in both formats. I love eBooks but hate
their appearance and how they distort the message by their lack of
visual structure.
The difference between these two worlds can be explained in one word: people.
There are no people in the engineering world. No people to mess up the
design. No people to misuse the system (the word "misuse" was very
carefully selected). No people to get the requirements wrong.
Misuse: To the engineer, people who don't follow instructions are
misusing the system. RTFM goes the phrase: Read the blessed manual.*
To the people, the system doesn't do what they need. They have to
develop workarounds. As for reading the manual? That 200 page piece of
unintelligible gibberish? (200 is a misstatement: large system have
thousands of pages. The printed manuals for a modern military airplane
won't fit on the airplane.)
Of course the manual writers complain (correctly) that it is gibberish
because they were called in at the end and told to finish in one week.
They had to make believe that the engineers and designers knew what
they were doing and that those different parts of the system that work
in contradictory ways is really a wonderful feature. (As my programmer
friends like to say, if it isn't documented, it's a bug. If it is in
the documentation, it's not a bug, it's a feature.)
Once people enter the equation, all bets are off. People are fickle,
short-sighted, self-contradictory. They don't know what they want.
They don't understand how they do their tasks. Their self-descriptions
of how they do things and of their needs do not match observations of
what they actually do. And they are never satisfied, even when you
design precisely what they asked for. Actually, especially when you
design precisely what they asked for.
The difference in the professions has to do with how the problem of
people is handled. engineers either ignore them or model them as
reliable, efficient, decision makers. The product design community
empathizes with them, fondles them, caresses them. People-centered
design is their forte.
===
As for those large, perfect engineering projects. Why do they so often
fail? People.
Large projects require managing and synchronizing the activities of
hundreds or thousands of people. People change. They get promoted or
fired, they switch jobs, they switch positions. The new people have to
be trained and brought up to date. The hardest part of doing large
jobs is NOT the design: it is managing the people. And as i
explained, people are really difficult to work with. Geesh, each has
their own opinion. And they are always changing their minds. Even
engineers.
Why should designers should keep away from these projects? because
they don't have the expertise. Designers are pretty arrogant folks,
thinking that they have some mystical "design thinking" skills that
will let them solve everything. utter nonsense. Most of the large
problems are NOT wicked problems. They simply involve rigorous
scheduling, supply chain, politicking, and management skills.
Designers are especially bad at this. Designers are trained to work
alone. Large projects require synchronizing the efforts. of hundreds
or even thousands of people and organizations.
The difficulty with large projects is NOT in their design. it is in
communication, management, and organization. Change a specification
(and there is never a large project where the specs don't change), and
it is critical that all relevant parts of the organization know about
the change. And that they change their design parts to accommodate the
change. And that the rest of the organization change their designs to
accommodate the changes in designs necessary to accommodate the
changed specs. And parts that were already completed and perhaps even
installed may have to be redone. If you can only track all the things
that are relevant, all the things that have to be done.
Management of large projects is NOT a science. it is an art. And it is
difficult.
Add more people to a project and invariably the work slows up. (If 5
programmers will take a year to finish a project, how long will 10
programmers take? Answer: Two years.)
So the only way to reconcile these two different worlds is to get rid
of all those pesky people.
I'm working on it.
Don
*RTFM: Read the blessed manual. Blessed? Speaking of engineers and
design. The earlier version of this note was rejected by the
intelligent, engineer-designed list reader this mailing group
stupidly insists on using because "it used inappropriate language." I
had an F word in the spelling out of RTFM, no not the gerund of the
4-letter word but an inconspicuous common replacement. It wasn't
allowed. Geesh. We are in the 21st century. Can we get a list system
that allows HTML so we can use simple typography And why does it
reject perfectly innocuous words because of some engineers perverted
notion of decency? Terry: This is exhibit A: All engineers have to
do is build to the requirements? Not when people are involved.)
|
