(Apologies for multiple postings in various groups you may be
reading.  We want to get this notice out widely!)

On June 26, we're holding an unconference about Games - Innovation
Games®, design games, and serious games:
http://www.enthiosys.com/news-events/idsge

This one day event focuses on the use of playful techniques for
gathering customer (and user) requirements, as part of the design
research process, and for other serious purposes, such as citizen
participation in democracy and social movements.  Games are also a
terrific method in team building within an organization and for
professional development within a particular occupational group.

I was introduced to Innovation Games a couple years ago   Of course,
I'd been using techniques like these for many years - but mostly
within a team rather than with customers and users.  Meeting Luke
Hohmann (of Enthiosys, and author of a book about the set of a dozen
games) opened my eyes to new possibilities for adapting methods to the
user experience and user research tasks.  And the more I tell people
about these methods, the more I realize how aligned they are with
other participatory design activities.

You're probably familiar with the "unconference" format:  we prepare a
schedule in advance (number of parallel meeting spaces and time
assignments), but leave the setting of topics in slots to the start of
the event, when people introduce themselves and declare their
questions and expertise.  Everyone has the opportunity to lead a
session whether by presenting or facilitating a discussion on a
question they're interested in.  Often we find synergies in unexpected
places, so that two people who didn't know each other before might
combine their topics into a single session.  All very fun and
energizing.  We're committed to good documentation of what goes on,
and hope this will be the first of many such meetings, locally and in
other places as well.

We're keeping costs low by splitting the expenses, roughly half from
sponsors and half from participant fees.  Sponsorships start at a
nominal $500.

Advance registration is required.  We won't be able to accommodate
walk-ins.

Please share this announcement with others who may be interested.
We're looking into hotels for folks from out of town.

   -- Nancy

Nancy Frishberg +1 650 804 5800 mobile
nancyf@...

Hi,

I am a developer working in an agile team for more than two years. There are
five developers, one usability engineer, and one on-site customer in our team.
We have integrated few HCI techniques in our XP process, e.g., low-fidelity
prototyping, personas, laboratory usability tests, expert usability evaluations,
etc.

I am also a student at Technical University Graz, Austria. My research interest
is in agile usability/user-centered design. Besides working in our team, I have
also access to two more agile teams as case studies.
For further doing research in this direction, currently I am in the process of
conducting interviews from the professionals who work in agile development
methods and integrate HCI techniques / usability into their processes.
I am also conducting an online questionnaire. The goal of this questionnaire is
to analyze the integration of agile development methods – particularly XP and
user-centered design (UCD) methodologies. Our hope is to gain a better
understanding of what is actually happening on real-world agile projects and the
benefits and limitations of the integrated process.

I, therefore, request you that kindly fill out this questionnaire. It only takes
5-10 minutes to complete.
The URL is:   http://129.27.202.49:9000/~survey/index.php?sid=51655
The summary of the results will be published on this group. The detailed results
will be published in a journal or in an agile/usability conference.

In the end, I would like to thank Scott W. Ambler and William Pietri for their
valuable feedback in preparing this questionnaire.

Thanks & Regards,
Zahid

--
Zahid Hussain
Institut für Softwaretechnologie
Technische Universität Graz
8010 Graz, Austria
TEL: (+43|0)316-873-5743
FAX: (+43|0)316-873-5706
http://www.ist.tugraz.at

A basic pass / fail test was developed at Nokia to understand if the
    many teams were implementing Scrum correctly. You can take this test
    by clicking on the link below.

    I will aggregate the results and email them to you if you are
    interested. I will present the results back to the Agile/Scrum
    community for discussion once we have 1000 responses. We have 430 so far.

    Please forward this email to other teams so we can get as many
    responses as possible.

    The test:
    http://spreadsheets.google.com/viewform?key=p_DGqV8jkE4Wmpir24Xt8Zg

    cheers,
    Robin Dymond.

John, thanks for this.  I am raptly interested in your real-world experience; as
you say, I've heard a lot from people who know what "well-researched" and who
can speak academically.  I don't identify so much as I do with real-world horror
stories.  I've just signed on with a large freight shipping company as one of
only two UX types in the business unit responsible for developing all the
software support for the pickup to delivery lifecycle.  Just as I have joined,
the development teams are switching to Agile.  Everything is new and exciting
here!  I look forward to reading more.

Peace,

jb

--- In agile-usability@yahoogroups.com, John Schrag <john@...> wrote:
>
>
> There is more to it --- specifically, there's a particular horror
> story or two for each item on the list, which will be talked about in
> future blog posts by members of my team.  I think those articles will
> be more fun to read, once they're written.
>
> I can't really disagree with the accuracy of your simplification, but
> I don't know how useful it is.   People who know what "well-
> researched" means don't need to be told, and people who don't often
> think that they do.
>
> -john
>
>
> On 11-Jul-09, at 9:50 AM, Jared Spool wrote:
> > Hi John,
> >
> > This is interesting, but seems to me to be a bit more complex than
> > it needs to be.
> >
> > Sounds to me that what you're saying in the blog post (http://is.gd/1uMjH
> > ) is "Well-researched user experiences over group-think-produced
> > feature requirements."
> >
> > Is there more to it?
> >
> > Jared
> >
> >
> >
> > On Jul 11, 2009, at 8:39 AM, John Schrag wrote:
> >
> >>
> >>
> >> I've written a post for my company's external design blog, that
> >> might be of interest to this list.
> >>
> >>
> >> "...my co-workers and I spent several hours considering the
> >> question of UX design practice.  We weren't considering the
> >> question of what makes good design;  there are innumerable books on
> >> that topic.  We were considering the question of what separates a
> >> healthy, effective design practice from the horror stories we hear
> >> about when talking to others in the industry...."
> >>
> >> The full post is here:  http://dux.typepad.com.   Feel free to
> >> comment.
> >>
> >> -john schrag
> >> interaction designer
> >> autodesk
> >>
> >
> >
> >
>

dina salah wrote:
> What i am asking about is:
> Among all the suggestions to achieve agile usability, how can u prove
> that your suggested method is better than any other suggested
> method?Is it through user/ customer satisfaction? Better Developement
> team productivity? More Agility? ....
> And again how do u backup your opinion?

Could you say more about your goal in asking those questions?

I have seen a lot of teams, and I don't think I've ever seen one where a
team has been helped by focusing on proving the absolute superiority of
one method or another.

If you are working as a team, releasing at least weekly, and doing
regular retrospectives, you will find that most weeks are better than
the one that came before. Each team seems to find their own particular
definition of "better", and that definition changes over time.

In that context, the way that teams decide what methods are best for
their circumstances is generally through trying them out and seeing what
works. Is that an option for you?


William


--
William Pietri - william@... - +1-415-643-1024
Agile consulting, coaching, and development: http://www.scissor.com/
We'd love feedback on our new blog: http://agilefocus.com/

Jared introduced into this thread the simplification:

"Well-researched user experiences over group-think-produced feature requirements.

Later the list was expanded with other dichotomous distinctions

  ...

As a licensed troublemaker and certified outlier, I am bothered by the continued virulence of this sort of “versus virus” that infects us so frequently. Even valid or useful dichotomies are constraining, limiting the purview to a single dimension or distinction when the world is, thankfully, ever so much messier and interesting than that. And false dichotomies, such as most of those listed, are for more insidious in the way they can poison thought and practice.

I did indeed write:

> I would never presume to suggest that user experience research is bad
(although it is over-rated and even over-used, but I would never say that
because anyone who does is clearly deranged or evil or both) <

And Todd Warfel responded:

> This clearly shows you have a misconception of what user experience
research is. <

How quickly it becomes ad hominem. :-(

> Unfortunately, there's a lot of bad research going on in the UX field by
people who are misinformed and untrained. <

Of course. It's Sturgeon's Law.

> The fact of the matter is quite the opposite of what you propose-user
experience, which I prefer to refer to as design research, is not only not
over-rated, but in fact typically under-used. <

Well, I made no proposal, so I am not sure what is the opposite or how to
argue against "the fact of the matter" or what is true "in fact." Nor can
either of us tell whether what you refer to as design research is what I or
anyone else refers to as user experience research. So whether anyone has
misconception will have to remain undetermined.

Your reaction to my indirect reference and tongue-in-cheek parenthetical
disclaimer is precisely why I "would never presume" and "would never say"
those things. The reactions to any challenging of the shibboleths or
questioning of the received truths is met with immediate and even sometimes
violent reaction.

User experience research (or design research, if you prefer), is an absolute
and unmitigated good (if done well by good people), so no one should ever
suggest there might be disadvantages. So I won't do that.

Todd Warfel continued:

> I am curious why you think it is over-used (not to be an instigator, but
really am curious). In my experience working w/user experience
practitioners, business people, and software developers I frequently hear
"we don't have time for user research." This is bullocks. There's always
time. You just have to know what method to use given your constraints. <

I also hear this all the time. And, I agree, often it is just an excuse.
However, it is not true that there is always time and only a matter of
choosing the right method. The real issue in situations of extreme time
constraints is always how best to use your time, and sometimes the answer is
not to do any user research, but to use your extremely limited time for
something else that, given that limitation, will yield better return on
investment. (But I am not proposing that or arguing it or even saying it,
because it would be dismissed out of hand as wrong and would brand me as a
heretic.)

Todd went on:

> In the example of Don Norman, yes, some people like Don Norman, Jonathan
Ives, Jared Spool and others have been doing this so long that their expert
input is quite valid and can serve as A data point. But I'm sure if you
speak to Jared (I use him as I know him personally) he'll tell you that he's
continually learning things as times are changing. And frankly, if Don
Norman and Jonathan Ives don't think they're continually learning, then I
wouldn't trust their "expert opinion." SMEs are only one data point. Relying
solely on them is dangerous and rarely produces innovation. <

I'm an expert, too, and learning all the time, too. Both Jared and Don are
friends and lifelong learners and strong advocates of user research, so I
would not want them to be tarred with the same brush as used on me. But, I
think it is a misdirection to try equating design research with learning.
They are unrelated. You can do scads of design research and learn nothing
from it, and you can learn from many different sources by many different
means. SMEs and design experts are not "only one data point"; a single user
or single diary or single factoid or single contextual interview is one data
point. If you don't give more credence to what your expert tells you, then
you are not using your expert well (or you might have the wrong expert or
just be someone who does not give credence to expertise, which can't be
helped). In fact, an hour with good SMEs and design experts could save you
days of field inquiry, depending on how you spend that hour and how you use
what you learn. The interesting cases are where the data and the experts are
at odds, but even there, it is not as clear cut as the evangelists would
make it out to be. In general, I would say trust the data, but I don't work
in general; I always work in specifics, and I have known a number of cases
in which the data and/or its interpretation and/or the drawn conclusions
were wrong and the expert was right.

What I see far more often than most people are prepared to admit or even
talk about is groups spending far more time on user research than they
actually needed to (for varied reasons: sometimes out of insecurity,
sometimes because it is seductive, and in a few cases because they just had
more time and money than was good for them) and then becoming hostage to
"the data," allowing it to override their own intuition, experience, and
even common sense or allowing it to dictate designs that are less than they
are capable of. I am not saying this is the norm or the majority of cases,
but it is a real phenomenon. What I find intriguing is that the so many
people will not even consider that user research could be over done or that
it might have a downside as well as an upside. Which is one reason that I
would never dare say anything about these issues in a public forum, least of
all here.

And Todd added:

> BTW, Apple's innovation comes from design exploration and not listening to
"the experts." So, I would consider Ives an expert who doesn't listen to
"expert opinion." <

I don't know Ives, so I have no idea to what extent he does or does not
listen to expert opinion and I would guess neither do you. As to Apple's
successful design innovation, it is rooted in many contributing factors and
I would not reduce it to such a simple notion.

And Todd finished by quoting me and then parrying:

> Finally, you state that "I have worked in spaces in which the
organization, political, practical, and fiscal constraints have made field
research essentially impossible and validated data has been unavailable.
This has not prevented us from going forward and designing good products,
even outstanding successes."

First, how do you determine good products and success? If you don't have
some type of base research to determine what it is suppose to be (based on
user need, not some bogus marketing requirements document), what do you
measure against to determine you've met your goal? Further, if it was
outstandingly successful, imagine how astronomically successful it would
have been if it had been informed by some good design research. <

There are many measures of success, many of which depend not an iota on
baseline research. Microsoft software is widely criticized, not the least by
Apple advocates, but it is clearly a gigantic market success. Apple's
computers are worshipped by a community of true believers, yet it is in one
sense a market failure at a paltry 4%. (For the record, I think both
companies do good things and stupid things and I have used them both, so
please don't turn this into another Mac versus Windows sideshow.)

I was going to not rise to the bait, because the structure of your inquiry
suggests to me that no matter what criteria I offer as measures of success,
they will only be dismissed. But, I'll naively proceed anyway. In one case I
have in mind, with extremely limited user research (many would not even
consider what we did as user research), we produced an award-winning product
that was dramatically easier to use than previous versions, that beat the
competitors hands down, that was a commercial success and became a paradigm
for future software from the company. In another case, with limited up front
user research and way too modest on-going input, we produced a product that
cut training time by a factor 15 and increased productivity by 50 some
percent. Users absolutely loved it and it went on to become the most
successful and profitable software product in the company's history. Both of
these examples have at least one thing in common: ongoing access to in-depth
subject-matter expertise that was viewed through the lens of a systematic
model-driven approach to interaction design.

As to your last sentence, I have no reason to believe that so much as ten
minutes or ten weeks more of user research would have resulted in a
dramatically better product in the cases I know within the constraints of
time. It is always about tradeoffs: every minute you focus on one thing is a
minute you are not focusing on something else. All I am saying is that
sometimes it is a better use of time to do less user research and more of
something else. I have my own views based on experience of what I might do
instead, but I would not expect you to agree with me or maybe even believe
me. Most projects I have ever worked on as a designer have had too little
time and too little money, and I am not saying a little too little, I am
saying whopping too little. In every case, if we had had more time or more
money, we probably would have done more field work, but we also would have
done more of other things, and the split would not necessarily be down the
middle.

--Larry Constantine, IDSA, ACM Fellow
   Director, Lab:USE Laboratory for Usage-centered Software Engineering
(www.labuse.org)
   Professor, Department of Mathematics & Engineering
   University of Madeira | Funchal, Portugal
   Chief Scientist, Constantine & Lockwood Ltd

On Jul 9, 2009, at 10:54 AM, dina salah wrote:
> Among all the suggestions to achieve agile usability, how can u
> prove that your suggested method is better than any other suggested
> method?Is it through user/ customer satisfaction? Better
> Developement team productivity? More Agility? ....

Dina,

The effectiveness of any given method for any project is largely
driven by the organization's design literacy. And then it's also
largely driven by the organization's culture. And then it's also
driven by the practitioner's political savvy and ability to evangelize.

There is no best method, and I don't think you could actually measure
one. There are only better methods for different circumstances which
is why anecdotes and sharing our experiences is so important. Proper
case studies might be better, but sharing experiences may be the only
way to teach these skills.





--
Austin Govella
User Experience

Work: http://www.grafofini.com
Blog: http://www.thinkingandmaking.com
Book: http://www.blueprintsfortheweb.com

austin@...
215-240-1265

Upcoming speaking engagements:

1. JUL 1: Agile+UX - collaboration in the wild
Panel and presentation at UX Austin on strategies for agile UX -
Austin, TX

2. JUL 21: Liquid user experience
Presentation at Dallas UPA on designing content, navigation, and
interactions for highly dynamic sites - Dallas, TX

John Shrag wrote:

> Larry, I'm sorry that you didn't read the original article that started
this discussion.  It would have saved you some time. <

I'm sorry, too, but then I don't always have the time, opportunity, or
bandwidth to read everything I should or could or would like to.

And John continued:

> The list of "dichotomies" came first, from the article, and Jared later
offered his simplification as a way of encapsulating everything on the
existing list.

Plus, they article makes it very clear that these are not dichotomies (true
or false).  Everything on the list is of value;  the list reflects how our
team resolves differences in cases of conflict.  For example, I value expert
opinion very highly --- but at times when the facts on the ground contradict
it, I'm going with the facts. <

They are, in both cases, dichotomies, not "dichotomies" or for that matter
"true or false," but this is getting into semantic quibbles that are not
terribly important or interesting to me. The punch-line is in your closing
sentence. In another post I said "In general, I would say trust the data,
but..." The big "but" is that user research is NOT in practice always right
or valid, even when validated, any more than expert opinion is always right
or valid, even when based on extensive experience. In truth, when so-called
facts and so-called opinion contradict, sometimes the opinion is right. What
I try to teach my students and counsel my clients is that user research
should never become a substitute for thinking, that it CAN be misleading or
misunderstood, and that scads of user research can become a cover behind
which to hide a lack of conviction or confidence. I have seen people do
things that they know in their heart of hearts is wrong but they are afraid
to contradict "the data." Basing work--or at least maintaining the
appearance of basing work--on validated user research data is the safe and
secure route to take. Whatever is delivered can be justified and defended on
the basis of the extensive data that was carefully gathered and extensively
analyzed and thoroughly checked. So clearly, extensive user experience
research, thoroughly validated, is THE way and the ONLY way to do good
design, and anyone who suggests otherwise is demented.

In abject and fully acknowledged cowardice I have glossed over the
unpleasant possibility that most user experience research might be only
remotely related to anything deserving of the term "facts on the ground,"
but that is material for another post that I may or may not ever dare to
make.

--Larry Constantine, IDSA, ACM Fellow
   Director, Lab:USE Laboratory for Usage-centered Software Engineering
(www.labuse.org)
   Professor, Department of Mathematics & Engineering
   University of Madeira | Funchal, Portugal
   Chief Scientist, Constantine & Lockwood Ltd

Hello, Todd.  On Sunday, July 12, 2009, at 7:32:41 AM, you wrote:

> On Jul 12, 2009, at 7:37 AM, Larry Constantine wrote:

>> I would never presume to suggest that user experience research is
>> bad (although it is over-rated and even over-used, but I would never
>> say that because anyone who does is clearly deranged or evil or both)
>> [...]

> This clearly shows you have a misconception of what user experience
> research is.

It seems to me very unlikely that Larry Constantine is under a
misconception about what user experience research is. I'm submitting
a defect report on you for this one.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
To be on the wire is life. The rest is waiting.  --Karl Wallenda