Re: [agile-usability] Thanks for showing up!
- Adam Carter wrote:
> Phlip wrote:Me!
> > I always just relied on the "doesn't suck"
> > principle myself...
> Who says it 'doesn't suck'?
This might be considered a gap in the process.
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
- Phlip wrote:
> > Who says it 'doesn't suck'?:)
> /a beat/
> This might be considered a gap in the process.
Not surprisingly I think that is the answer for most application
- What is the role of the Interaction Designer (ID) in agile teams? To
build on the many insightful observations that have come before, I'll
unload the following opinions:
THE INTERACTION DESIGNER SHOULD REPRESENT THE USERS
As several have noted previously [16, 56], there are major differences
between the XP Customer and an application's Users. Keeping this in
mind, one can examine the XP system of Developers and Customers and
see that there is a productive tension between the two; this can be
multiplied by introducing Users as a third party. Since the full
continuum of Users rarely enjoy direct representation in a project
team (even by proxy), someone must advocate for their needs, as does
the Customer for the business's needs (or their own), and the
Developers for the system's quality and their own bandwidth. This
responsibility should lay with the Interaction Designer.
IDs SHOULD BE GENERALIZING SPECIALISTS
Jeff earlier divided usability folks into three groups:
up-front/requirements people, design/implementation people and testing
people. I would contend that, especially in an agile team, these are
skills that are applied at various stages of a project, but ones that
should all be held to some degree by a single person. (A partial
exception is testing, which is multifaceted and deserves attention
from several parties, and a separate discussion.) Agile teams need
the eponymous "generalizing specialist" [Ambler], with core
proficiencies in interaction and UI design, and strong capabilities in:
- Business analysis
- GUI development
- User observation & analysis
- Usability testing
- Graphic design
I have seen few agile projects that would readily fund more than a
single individual in this general line of practice, so this is to some
degree a matter of practicality. However, it is more about the single
point of responsibility noted above; in order to have a consistent
shared vision and quality execution throughout an incremental process,
someone must be singularly focused on the none-too-simple task of
smoothly integrating all of those changing requirements into the
broader navigation structure, as well as into the individual screens.
The mental context switch between interaction/UI design and OO
development is significant, and asking Developers to manage both will
inevitably lead to sacrifices on one side or the other.
THE CUSTOMER NEEDS HELP UNDERSTANDING BUSINESS VALUE
I believe that the ID provides a vital service to the Customer by
providing a more objective picture of their User's needs than they
might otherwise enjoy. This perspective is both an addendum and a
counterbalance to internal business objectives, as Brian noted
eloquently in message 16. For example, a Customer might feel that
they need certain features, but have little true idea of the relative
value of each; this information can be provided by the application of
Usage-Centered Design, by ethnographic observation and other means.
The Customer still has the final word on what they want to do, but now
they're getting strong opinions from both Developers and Users (via
the ID) to inform their decisions.
Some other quickies addressing previous posts:
* Usability should be cultural, but not solely distributed. Its value
should be clear to the entire team, and they should collaboratively
practice and learn it as much as possible. However, diluting the
responsibility among the team (even with a pinch-hitting UI/usability
expert) is risky, because the practices are different and complex
enough that a single owner is generally warranted (IMO). I really
like Kent's approach in message 30.
* ID practices generally move to a very different beat than the rest
of development. This means that they can be done in parallel, yet
another argument for a dedicated resource (see Mark's message 18).
* The ID's skills can be useful even in projects with little or no UI,
as noted in the thread regarding API development. I have been
involved in several business process redesign efforts, for instance;
the principles and practices are much the same, and similar to those
of business analysts.
OK, I think that's long-winded enough. 'Til next time... ;)
Interaction Design Manager | CC Pace | www.ccpace.com
another "blast from the past" post that evidently took the scenic route
(and still is).
I agree with Jeff's breakdown with 2 slight twists. From what I've seen
companies break the work down into the 3 chunks.
In large organizations Usability usually starts out with testing, then
gets into some design, followed by front-end work, and finally more
design and a life-cycle process.
Second, most people seem to specialize in one phase or another. In fact
they typically specialize in using a few of the tools available in that
So what are the credentials? That is a different question. I've known
folks who have had 1 year of experience 10 or more years and a few who
have crammed 2 years of experience into a year. Additionally there
isn't a certification program that is universally accepted. So for
credentials we typically look at tools used, portfolio of work, input
from collegues, and gut feel.
> Jeff Patton wrote:
>> --- In email@example.com, Phlip <phlipcpp@y...> wrote:
>> > What kind of credentials do usability experts need?
>> As always, the answer is "it depends."
>> I lump usability people into three groups:
>> 1. up-front people: those who work at pre-development/pre-product
>> stage to determine what software is appropriate to build 2. design
>> people: knowing what the software should do, how exactly
>> does it do it? Both appearance and user interaction
>> 3. design validation or test people: given a piece of software
>> functionality, exactly how usable is it? What adjustments could be
>> made to make it more usable?
>> Like developers, there are usability generalists who do all those
>> things well, and specialists who focus hard on doing a particular
>> thing well. Among usability people there are many different points
>> of view on how any of those activities are done.
>> What best credentials are depends on where you perceive risk to be
>> in your project. Are customers unsure what to do? Are they sure
>> what it should do, but hazy on exactly how? Do you have a product
>> that does what it should, but does it poorly?
>> > I always just relied on the "doesn't suck" principle
>> > myself...
>> Me too - sort of. If the piece of functionality is used by one
>> proficient person infrequently, I let it suck. If it's used by
>> hundreds of inexperienced people very frequently, sucking might get
>> expensive. Especially if you have to pay to frequently train this
>> people, and provide help desk support for them. Since sucking can
>> get very expensive in that situation, an expert in making it not
>> suck can pay big dividends to a customer concerned with ROI.
>> I think others on the list could better say what proficiencies a
>> usability person should have.
>> Also, usability people, if you have other points of view than mine
>> on the 3 classes - I'd like to hear them.
>> > =====
>> > Phlip
>> > http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfac