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

Re: [agile-usability] Agile vs. Creativity

Expand Messages
  • Ron Jeffries
    Hello, mark. On Saturday, December 5, 2009, at 12:42:39 PM, you ... Actually, I wouldn t think that. Respect is not provided because one has gone to a good
    Message 1 of 118 , Dec 5, 2009
    • 0 Attachment
      Hello, mark. On Saturday, December 5, 2009, at 12:42:39 PM, you
      wrote:

      > If you are lucky enough to have an interaction design or information
      > architect on your staff... (statistically, there is one to every
      > hundred or two code writers) they are likely educated from one of a
      > dozen of so schools that specialize in that place between humans and
      > computers. The masters programs these days are pretty damn sgood. They
      > have three things going for them... a closeness to how user behave and
      > expect things to work, an intimacy with the product that few can claim
      > - at least on the product side(or as I think you call them
      > "customers'), and a passion for doing great work. You would think this
      > would provide some respect and regard.

      Actually, I wouldn't think that. Respect is not provided because one
      has gone to a good school and is full of passion. Respect comes when
      one becomes a member of the team and plays well with the team. If a
      designer--or anyone else--comes in expecting respect because of
      where they come from, they've got a surprise coming.

      > In the 30 years that I have been working and consulting with designers
      > in corporate environment and code shops, I have found it
      > extraordinarily rare to find designers working in an environment of
      > respect. They are seen as purely tactical when in fact design is an
      > incredibly effective tool at the strategic level (need I really trot
      > out the list of companies that succeed using design as a tactical
      > advantage?).... but I digress.

      Actually I have asked before for an example of a really successful
      software project that has gotten that way because of its really
      fantastic design. My followup question will be whether that design
      was done in the ivory tower, or by designers working in the mud with
      the rest of the team. Your words below make me think you will make
      the same prediction I would: //IF// design has ever really made a
      difference in software, it made that difference with designers being
      part of the team not placing themselves above it.

      > Unlike a strategy and tactical
      > implementation of C++, everyone has an opinion about design and the
      > interactions of software because we all have a singular experience
      > perspective to draw from. If your domain of expertise was similarly
      > exposed to pedestrian expertise and institutional disregard, I dare
      > say you might work in isolation and expose your supreme solution in a
      > magic show ah ah sort of fashion as well.

      On the contrary. Every damn fool thinks he knows what he wants the
      software to do. The whole POINT of Agile is: he's right! Agile is
      about exposing everything we do to scrutiny and discussion. Agile's
      not about magic shows or ivory towers ... except, all too often,
      when it comes to the design folks, who insist that they are special,
      and can't expose their thoughts until they are done, and that their
      skills are so high that feedback is insulting.

      > Or maybe you'd wonder off to some remote spot and reinvent the entire
      > process and terminology.

      Well I suppose one could be saying that the Agilistas have done
      that. But what we have really done is observed what actually works
      and recommended it.

      > This is simple human nature... which surely at some point in your
      > career you can identify with.

      If you mean surely at some point I've been a stupid jerk, you are
      all too correct. I probably even tried to justify it. Despite all my
      rationalizing and reasoning, I was less successful than I wanted to
      be. Finally, based on a statistical argument, I concluded that I
      must be the one who needed to change. :)

      > Is it appropriate of designers to hide
      > the process and act like spoiled babies when there ideas are
      > scrutinized and disregarded? Absolutely not. Designers need to
      > consider the misunderstandings and pseudo expertise that surrounds
      > them as part of the design constraints. They need to spend much more
      > time laying the ground work for their premise, providing evidence for
      > their conclusions and selling the best solution against the provided
      > criteria.

      Yes, yes, oh god yes.

      > There are lots of designers working on this level, but they
      > likely have reached a point in their careers where they no longer feel
      > compelled to tolerate the hostile environments of those who have yet
      > to embrace their practice and the benefits forthcoming. Or, maybe they
      > are off somewhere conspiring to drive the entire process.

      Most of them, I suggest, have learned to build trust (perhaps by
      clever techniques like not writing cartoons that make their
      customers look like jerks), and thought building trust, built their
      ability to guide and enhance what is done.

      Ron Jeffries
      www.XProgramming.com
      www.xprogramming.com/blog
      I'm not bad, I'm just drawn that way. -- Jessica Rabbit
    • 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.