Comments on: It’s rarely just about design http://www.technotheory.com/2007/08/its-rarely-just-about-design/ Time-saving reflections on lifehacking, social media, and technology. Mon, 30 Dec 2013 18:20:21 +0000 hourly 1 http://wordpress.org/?v=3.4 By: Doug LeMoine http://www.technotheory.com/2007/08/its-rarely-just-about-design/comment-page-1/#comment-6798 Doug LeMoine Wed, 05 Sep 2007 19:09:24 +0000 http://www.technotheory.com/2007/08/its-rarely-just-about-design/#comment-6798 Oftentimes, the role of the designer is similar to that of a doctor. When a patient visits the doctor with stomach pain, the patient is not expected to know what the root of the problem is, i.e. "I think it's because my gall bladder needs to be removed.". That's for the doctor to figure out. Design projects usually begin at the clients' hypotheses for their problems, their own interpretations of symptoms that they've identified. As we do research, we test these hypotheses and attempt to determine whether they're sound and complete. If they aren't, we have to break the news to them: The problem isn't actually what you think it is, i.e. "It's not your gall bladder; it's the junk food you've been eating." The best results in delivering this (sometimes bad, sometimes hard-to-swallow) news are achieved by notifying clients up front when you notice a hypothesis in place of a symptom. "You're telling me that you think the registration process is too complicated; where is this coming from? Describe what you've seen that makes you think this." By representing to them that your ultimate goal is to determine the root of the problem, you're positioning them to absorb and act on your analysis. Of course, some clients just want you to remove their gall bladders anyway, and you always need to be prepared to do what's right in those cases. Oftentimes, the role of the designer is similar to that of a doctor. When a patient visits the doctor with stomach pain, the patient is not expected to know what the root of the problem is, i.e. “I think it’s because my gall bladder needs to be removed.”. That’s for the doctor to figure out.

Design projects usually begin at the clients’ hypotheses for their problems, their own interpretations of symptoms that they’ve identified. As we do research, we test these hypotheses and attempt to determine whether they’re sound and complete. If they aren’t, we have to break the news to them: The problem isn’t actually what you think it is, i.e. “It’s not your gall bladder; it’s the junk food you’ve been eating.”

The best results in delivering this (sometimes bad, sometimes hard-to-swallow) news are achieved by notifying clients up front when you notice a hypothesis in place of a symptom. “You’re telling me that you think the registration process is too complicated; where is this coming from? Describe what you’ve seen that makes you think this.” By representing to them that your ultimate goal is to determine the root of the problem, you’re positioning them to absorb and act on your analysis.

Of course, some clients just want you to remove their gall bladders anyway, and you always need to be prepared to do what’s right in those cases.

]]>