Re: [agile-usability] Re: Today's article on UseIt.com
- aacockburn wrote:
> I thought Nielsen's article was notable enough to comment on pointOK, I'm just catching up with this thread. I just got around to reading
> by point. Not much to disagree with, but I hope a few things of
> note for both programmers and UX/UI specialists.
http://www.useit.com/alertbox/agile-methods.html and the statement "For
a project to take interaction design and usability seriously, it must
assign them 'story points' (i.e., resources) on an equal footing with
the coding" jumped out at me. I see that Alistair has also touched on
this. I like Alistair's response, but I'd like to approach this from a
First of all, story points do not represent resources applied. They're
an estimate of the work required to accomplish a small but measurable
increment of functionality. This work has never been just "coding." At
the very least it includes testing and acceptance by the Customer. If
the functionality includes a change to the UI, then figuring out what
that UI change should be is also part of it.
Many shops don't have UI experts, so figuring out that UI change falls
to the developer and the Customer having a discussion and making a
decision. Yes, this sometimes results in a terrible UI from a usability
point of view. The good news is that, if you're working in small
increments in an iterative fashion, you can always revisit this and
change it. If it's bad enough, this usually happens.
When there is a UX/UI designer, their work is too-often treated as an
up-front requirements definition phase, handed to the development
process as a /fait accompli/ to be developed without any further
discussion. The problem with this is not that it's not "Agile," it's
that it sabotages the benefits that people seek when they adopt Agile.
The Customer might have made some subtle adjustments to the
functionality of the story, and the pre-designed UI might no longer be
so appropriate. The precisely-defined UI might be really expensive to
develop, and a much cheaper approach might be approximately as good.
And, if the story is never scheduled for development, this up-front
design is completely wasted.
It appears to me that the only way to get the Agile benefits of
balancing needs and costs to get the best bang for the buck, is to move
this UX/UI design work into the incremental, iterative development
cycle. That doesn't mean to create a separate story card for UI design,
and then another for implementation. The completion of the story
includes the UI design, the implementation, the testing, and the
acceptance by the Customer.
"But," some designers protest, "we need to do usability testing with
mockups to know which is the best design." Well, perhaps. On the one
hand, with enough experience you might be able to design a "good enough"
UI without this step, particularly if you know it can be changed in the
future. Doing the usability testing with live code, rather than a
mockup, might provide better feedback because it tests the concept
as-implemented, rather than as-conceived.
Sometimes, of course, we just won't know enough to jump right to code.
This happens with coders, too, and we have a tool to deal with this
situation. That tool is a "spike." This is a time-boxed exploration to
learn what we know we don't know. For a coder, it may be coding up an
alternative implementation to see if it will work, or if it will provide
advantages. For a UI/UX designer, it may be creating and testing a
low-fidelity prototype. It's time-boxed because it's not directly
producing value--it's producing knowledge that we must then leverage to
produce value. Our goal is to answer some questions, not produce the
best possible prototype.
Hmmm... This is getting a bit long for an email. I'll finish it on my
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
> > There are other studies (I don't have the exact quote) that showthat
> > the difference between a top-notch developer and a run-of-the-millone
> > is a factor of 10 or so.http://forums.construx.com/blogs/stevemcc/archive/2008/03/27/productivit
> The back up for that is here :-
Thx James. I always assumed that this was indeed supported by actual
studies, but still had a small nagging doubt that it might be one of
those urban legends that start with "studies show that ...." ;-). This
is a good reference which eliminates that doubt.