Re: [agile-usability] Agile vs. Creativity
- personally, i find that if one discipline on the project team gets too
far ahead of any of the others, it can be a less efficient process than
if you do a more proper balance.
i have seen projects where the UX design is taken too far along with the
end users in a simulated "storyboard" environment. Such that, when the
team is implementing the system iteratively and getting frequent
feedback, it is common to not need to go as far as the "grandiose" UX
Ron Jeffries said the following on 12/5/09 3:45 PM:
> Hello, mark. On Saturday, December 5, 2009, at 12:42:39 PM, you
> > 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
> I'm not bad, I'm just drawn that way. -- Jessica Rabbit
- 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: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