On Jan 28, 2009, at 11:38 PM, Jim Leftwich wrote:
I doubt that all of those teams, including the unsuccessful ones you
mentioned, approached things from very diverse and experienced
backgrounds, with expertise in designing a wide range of development
factors successfully. I also doubt that those efforts have involved
teams producing pixel-perfect and behavioral-rule-perfect
specification blueprints, as we've done.
Actually, pixel-perfect and behavioral-rule-perfect specifications of
crappy designs are created every day.
So, from what I read in what you've written, what separates the teams
that succeed from the teams that fail are the people, their diversity,
and their experience.
In fact, you could probably take the same group of intelligent,
diverse, experienced people, have them stand in a corner, wear pink
hats, chant 17th Century Romanian Love Poems, while typing on keyboard
with their toes, and still get better designs than many organizations
out there.
Good design starts with good designers. There's no getting around that.
I believe what you're alluding to is actually a lack of adequate
architectural design. The typical effort has been a cobbled-together
mash of engineering with a big of marketing icing smeared over the
top. Almost nothing could be further from the RED practice I'm
describing.
Ok. But your description of the RED practice doesn't mandate adequate
architectural design. As far as I've determined, there's nothing in
your Philosophy/Approach/Method that ensures that's done, except the
expertise of the team doing it.
So, what is the contribution of the RED practice to ensuring this is
done?
And it's not as though there's no research. It's just that the
research is conducted very quickly, and also involves extensively
pulling from any already-known body of knowledge at the client or in
the organization.
Which is based on the assumption that that research information is (a)
readily available and (b) accurate. What does the RED practice do to
ensure there aren't holes, the information is easy to attain, and,
once collected, validates that it is in fact an accurate
representation of user needs, goals, and contexts?
What I believe, from what I've experienced first hand and what I've
observed, is that experienced and broad-based RED practitioners and
small teams are capable, designer-for-designer/team-for-tem, of
producing more and superior products, in more conditions, in tighter
timeframes, for less cost, than any other method. But that assumes
that the designers are both broadly talented and extensively
experienced.
EXACTLY MY POINT! Woo hoo!
Take away the talented and extensively experienced part, and the
entire practice, as I understand it, falls apart.
Give those same talented and extensively experienced people another
way to work, and they'll still produce good stuff.
In Stone Soup (obligatory Wikipedia citation: http://is.gd/hH3C), the
stone isn't magic and doesn't really make soup. It justs gives the
villagers the perception that it does. The important lesson from that
fable is that the traveller doesn't actually believe in the stone's
magical abilities.
RED to me sounds like Stone Soup. I'm sure your clients really believe
you've created soup from a stone. And I believe you've created great
soup. But I'm not seeing what the stone's contribution is.
Looking forward to seeing the magic revealed in Vancouver. :)
Jared
Jared M. Spool
User Interface Engineering
510 Turnpike St., Suite 102, North Andover, MA 01845
e: jsp...@uie.com p: +1 978 327 5561
http://uie.com Blog: http://uie.com/brainsparks Twitter: jmspool
UIE Web App Summit, 4/19-4/22: http://webappsummit.com
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... disc...@ixda.org
Unsubscribe ................ http://www.ixda.org/unsubscribe
List Guidelines ............ http://www.ixda.org/guidelines
List Help .................. http://www.ixda.org/help
