When you say "design"... what do you mean?

by Nick de Voil 6. February 2009 15:39

George Bernard Shaw (I think) said "England and America are two nations divided by a common language".

He was referring, I suppose, to the jarring experience when you think you're speaking the same language as someone else, only to find them using an unfamiliar word, pronunciation or construction. Or, worse still, when they use familiar words with the "wrong" meanings. As we all know, if you send an Englishman and an American to a clothing shop (apparel store?) to buy pants and vests, they'll come back with quite different things.

There's a similar linguistic problem with some of the communities of practice to which I belong - software engineering, web development and HCI. Take the word "design", for example.

Many people in the digital world are familiar with the distinction between a (graphic) designer, meaning someone who creates visual designs, and a (software) designer, meaning someone who takes system requirements and turns them into program specifications and database schemas. But it's recently dawned on me that in the HCI community "design" has a third distinct meaning. It apparently refers to the entire system creation process, including problem definition, requirements specification and analysis. That comes as quite a surprise to someone from the software engineering community, where the word specifically identifies one step in the process. You can see this in the Rational Unified Process (RUP), for example, where there's an "analysis and design" workflow separate from the "business modelling" workflow and the "requirements" workflow; or in SSADM, whose name itself - Systems Analysis and Design Method - accurately indicates a similar interpretation of the word.

I don't think this is just linguistic nitpicking. It seems to me to be symptomatic of a lack of communication between the two sets of people. Unfortunately this is self-reinforcing, because the two communities won't even notice that they have something to say to each other if they're using the same words to mean different things. For example, I'm currently reading two of the most interesting books I've ever come across about identifying requirements - an activity which I've always referred to under the heading of "analysis" or something similar. They're respectively entitled "Contextual Design" (Beyer & Holtzblatt) and "Interactive System Design" by William Newman and Mik Lamming. Before opening them I never would have guessed that they talked about requirements analysis at all, let alone offered the level of valuable original insight that they do, and which is sadly lacking from most "systems analysis" texts.


Add comment


  Country flag

  • Comment
  • Preview