Loading ...
Sorry, an error occurred while loading the content.

Re: [agile-usability] Agile vs. Creativity

Expand Messages
  • Jeff Patton
    ... When I see the word design written down, I hear the word decision in my head. Good decisions are made based on understanding the problem or goal and
    Message 1 of 118 , Dec 5, 2009
    • 0 Attachment
      On Dec 5, 2009, at 10:57 PM, Glen B. Alleman wrote:

      Ron,

       

      Maybe  expanding  your horizons will reveal some examples. ALL the software for embedded flight controls, battle space management, space craft ground  and on orbit control, general and commercial aviation avionics, guidance navigation and controls (GN&C), command and data handling (C&DH) boxes and their user interfaces, the 777 avionics suite for example spring from the design process. As a success example, these represent billions of dollars in recurring revenue for their firms (Honeywell, Raytheon, Northrop, Lockheed Martian) and employee 10’s of 1,000’s of software engineers, V&V, UI designers,  and a myriad of other “software intensive” staff, from simulator development, embed testing, logistics systems and our little niche of program planning and controls.

      When I see the word "design" written down, I hear the word "decision" in my head.  Good decisions are made based on understanding the problem or goal and the context the decision is made in.  Good decision making processes consider alternatives.  Good decision making processes test the effectiveness of their decisions and make changes if they were wrong.  You can go back through my sentence and replace the word "decision" with "design" and it'll still parse correctly, and say what I meant.  [I play this design/decision MadLib game a lot.]

      My point is that there's lots of design decisions in deciding what to build, who it will serve, and how exactly how it should serve them,.  And there's lots of design decisions in exactly how to build it, how verify and validate it, and all the rest of the how-to stuff.  I suspect what interaction designers [including me] get in a bunch about is decisions about what to build being made using a bad design/decision process masquerading as "business requirements gathering."  Then those decisions being communicated without any context to help me carry the decision making process forward - which I and everyone needs to do to effectively "design" the details of the product.  

      Now, before someone think that I believe the interaction designers should be making all the decisions about what to build... well, just don't think that.  Lots of smart business people and requirements people have been making good decisions for a long time.  In Mark's post a ways up the thread he used the phrase "wander off to a remote spot and reinvent the entire process and terminology."  Forgive me Mark for taking it out of context, but it's important to note that interactions designers have invented lots of process and terminology for stuff that smart business people have been doing for a long time.  Often for those intelligent people it looks like the designers have wandered back in from their remote spot and started telling business people "the process you should be following is based on 'design thinking'" - which to them runs the risk of sounding like invented process and terminology for something they can prove they've often done well in the past.

      Not saying its wrong, just a stinkin' mess to make sense of.

      Thanks,

      -Jeff


    • mark schraad
      I ve been called pedantic on occasion. I m ok with that ; )
      Message 118 of 118 , Dec 10, 2009
      • 0 Attachment
        I've been called pedantic on occasion. I'm ok with that ; )

        On Sat, Dec 5, 2009 at 6:56 PM, Jeff Patton <jpatton@...> wrote:
         

        On Dec 6, 2009, at 12:22 AM, mark schraad wrote:

        Jeff,


        I run with a few definitions of design. When Alan Cooper (I can hear the cackles rise) came to talk with us a while back he spoke of differentiating the design of code (structure), from the design of the application, which is of course much different that designing labels and graphics for functionality.

        For me separating different kinds of design starts to get a bit tedious.  When you think about it, it's like night and day - which although you can tell me to the second when sunrise or sunset is, it's a pretty academic discussion when it's still light outside.  OK, bad metaphor - my point is that all design decision run together.  They just do.  Giving precise definitions for one type or another doesn't seem to help people make better decisions in practice. 

        Reading "the oatmeal" has put me in a strange mood.  Yes I am the mother-f**ing pterodactyl: http://theoatmeal.com/comics/ptero



      Your message has been successfully submitted and would be delivered to recipients shortly.