Hello, Brian.  On Thursday, January 10, 2008, at 5:06:17 PM, you
wrote:

> Yes Ron...that must be it.
> Point was that no methodology is implemented in a pure form. The client is
always right and
> even when they're not, they're paying the bills. If it's an internal client,
you still gotta
> work with them.

Yes, but that doesn't mean that I have to code with my finger up my
nose just because they say to.

But my point, perhaps not as respectfully phrased as it might have
been, was that maybe all methods look alike to you because, rather
than doing what the methods say, you're consciously or unconsciously
reverting to something close to your standard way of doing things.

I've done a number of different methodologies too, since 19mumble,
and I have found them to be rather different in some important ways.

> Perhaps there's some magic land where perfect
> Agile/RUP/XP/Waterfall (or whatever one uses)
> occurs, but I've yet to see it over 11+ years of doing
> development with lots of clients.

Well, it is not given to us to be perfect, but I've seen places that
were really trying to do it, and others where they would say they
were but visibly weren't.

Ron Jeffries
www.XProgramming.com
It is better to attempt something great and fail that attempt,
than to attempt to do nothing and succeed.
--Cookie, Garden Court Chinese Restaurant, Hamburg, MI

Hello, Brian. On Thursday, January 10, 2008, at 1:37:36 PM, you
wrote:

> In the end, I've worked with damn near every software dev
> methodolgy there is, and they all are
> the same.

Maybe you've just done one methodology and called it different
names.

Ron Jeffries
www.XProgramming.com
This is how I develop software.
Take the parts that make sense to you.
Ignore the rest.

--

Susan Meszaros managing director p +61 2 6773 3004 m +61 407 958 306 e susan.meszaros@... w www.xprime.com.au

Wow, talk about an overwhelming response! I appreciate everyone that
took the time to put in their 2 cents, for some - 25 cents. There is
some great input, both pro and con. I would admit that I am hestitant
to use formal prototyping tools. I am part of a fairly good sized
consulting organization and in the spirit of being innovative, there
are always new internal tool campaigns that you have to work through.
Thanks again for the great input. Now, since my mind does not work in a
threaded manner - I usually mind map these kind of things out so I can
see the big picture at one glance. There is an idea, a discussion topic
done via mind mapping and not threads....

Open Text is looking for a Product Designer to perform UCD tasks with
an agile development team. Interested? See the job posting at
http://www2.recruitingcenter.net/clients/ceridiancanada/publicjobs/canada100/con\
troller.cfm?jbaction=JobProfile&Job_Id=15946&esid=az

Send your creative application for this job to Amanda Eddington,
aeddingt@... or apply online on our corporate website.

--- In agile-usability@yahoogroups.com, "Bob Sarni" <agilepm@...>
wrote:
>
> Do any of you have experience or thoughts on the use of web based
> prototyping tools (Simunication, iRise, other) to create hi-fi
> prototypes as input to product backlog items, product owner,
> development team?
>
> Good thing? Bad thing? Will the tool constrain the team too much
and
> limit their creativity?
>
> I have not used these tools before but have certainly used post
> it/whiteboard type prototypes in the process.
>
> Thanks for your input
>

My company (220 employees, <> 30 engrs) is on agile and we
incorporated prototyping into our work over a year ago. We went with
Axure because of the feature2pricepoint ratio.

Prototyping has led to incredible collaboration and I think both the
product folks and our engineers feel better able to work iteratively
than ever before.

I (or a counterpart) will take the really loose thoughts of the
product folks and develop a rough prototype and then the product
folks use it in estimation with engineering and our engineers seem
to love it. I get 10x the feedback on a prototype (from all parties)
than I do on any sort of documentation (albeit it lean or a
throwback to waterfall days). I am able to quickly throw in things
based on input and shoot it back and have them feel it.

Also, we send our prototypes through user experience testing. SO
MUCH BETTER THAN PAPER PROTOTYPES and so so so far ahead of (several
sprints usually) of when engr would have work ready (user testing is
expensive). We are able to get alot more user feedback into our
products today because of this. Also, our projects start so broadly
that we used to WASTE a ton of engineering on narrowing that down
and now inexpensive Axure and a designer's afternoon gets everyone
to a happy place and then gets tested, incorporates feedback into
the prototype and hits the backlog (large project). Also, the work
that is done in terms of visual design is greatly improved because
our visual designer looks at something visual, understands the
motion of it...good stuff.

That seems like a LOT of miles out of the prototype even through
Axure's work is "throw away" in terms of code base.

For smaller stuff, UX starts the prototype just one sprint (2 wks)
ahead of engring usually and has something ready for the next
iteration. We continue to evolve the prototype in parallel ***IF***
it's a huge project, otherwise we switch over to dev sites as soon
as reasonable and iterate from there.

So for us, it's been good and only helped creativity and timelines
and meeting reduction. And oh, our products look so much better.

In 2005, Jeff Patton had the idea that the output from UX design could
be the input to automated testing. We played around with that idea:
<http://www.testing.com/cgi-bin/blog/2005/03/17#presenter1>
I've continued to play around with wireframes as expected output from
tests:
<http://www.testing.com/cgi-bin/blog/2007/01/18#wireframe4>
And recently I've been using OmniGraffle workflows to drive Rails
"integration" tests:
<http://www.exampler.com/blog/2007/07/13/graphical-workflow-tests-for-rails/
  >

If this sort of thing pans out, it will be one advantage of
prototyping tools over paper.

-----
Brian Marick, independent consultant
Mostly on agile methods with a testing slant
www.exampler.com, www.exampler.com/blog, www.twitter.com/marick

Capgemini Finland Oy, Registered office: Espoo, Reg.No 1628142-5

> And without _enough_ documentation with some sort of traceability you'd be
lost in projects where you are working for
> a client, no matter whether you use agile, waterfall or RUP. Less formal
methods of documentation are needed on
> internal development or in situations where it is the same organization that
creates requirements and does the
> implementation.

You seem to be implying that you need more formal methods of documentation,
unless the development team and customer are part of a same organisation.

I disagree and many Agile teams have been able to collaborate with external
customers without having to resort to heavily formal documentation. The secret
is to involve the external customer in a very close collaboration relationship.

Alain

Hiya,

On 11 Jan 2008, at 18:21, machappy553 wrote:
[snip]
> Also, we send our prototypes through user experience testing. SO
> MUCH BETTER THAN PAPER PROTOTYPES

Could you talk a bit more about where/why you've found Axure better
than paper prototyping?

> and so so so far ahead of (several
> sprints usually) of when engr would have work ready (user testing is
> expensive).
[snip]

Could you talk a little bit about why being several sprints ahead of
engineering is useful?

Adrian

Hi Fred/Scott,

On 10 Jan 2008, at 17:06, Fred Beecher wrote:

> On 1/10/08, Scott Preece <sepreece@...> wrote:
>>
>>  I believe the point is that the prototypes are done with tools
>> that the
>> designers can use themselves. This doesn't mean that they wouldn't
>> talk to
>> the developers or other stakeholders. This is to distinguish from
>> situations
>> where the designers need to have the developers build the
>> prototypes for
>> them, typically because the tools used are more programming-like than
>> designing-like.
>>
>
> That's exactly the point. Thanks, Scott!

I'm all for designers doing development! I hope we'll soon give
developer-ux / ux-developer roles the same respect that tester-
developer / developer-tester roles are getting now.

My issue (dunno about Ron's :-) was the "all by themselves". That
seemed to imply that the designer "owned" the prototype code (however
it was implemented). The problem I was seeing was that the rest of
the team seemed cut off from participating in the development process.

It tend to see a team where any single person has control over a key
artefact as a bit of a red flag. Better to have more folk involved so
the knowledge spreads around.

Cheers,

Adrian

On Jan 14, 2008 11:16 AM, Adrian Howard <adrianh@...> wrote:

>  > and so so so far ahead of (several
>  > sprints usually) of when engr would have work ready (user testing is
>  > expensive).
>  [snip]
>
>  Could you talk a little bit about why being several sprints ahead of
>  engineering is useful?
>
>  Adrian

In my experience, getting design ahead of actual development is
crucial in that it allows time for user centered design - usability
testing, interviews, ethnography, etc - results from these activities
can be delivered to the entire team prior to the sprint in which
they'll work on a certain feature. It also allows for use cases for
features to be somewhat fleshed out before sprint planning.

Also, providing the team with a more holistic vision of what the
entire product *may* end up being provides a lot of value. Having an
eye towards the big picture allows current work to be built in a more
reusable, scalable fashion and prevents some re-work. It's easy to
loose sight of this when strictly focusing on a single sprint.

Jeff

On 10 Jan 2008, at 18:37, Brian Weiss wrote:

> We're not an Agile shop, we're RUP blended with UCD. And our
> developers and BAs and Stakeholders all read and edit and reread
> and reedit the documentation. It also helps new developers get up
> to speed quickly on a specific part of a code they aren't familiar
> with. I would push back on your sentiment and say if you think
> documentation is useless, then you aren't using it right.
[snip]

True. There are certainly contexts where documentation is necessary
to get the job done.

Over the last few years, my approach to these environments has
changed. I've found it more effective (in anything but the very short
term) to try and change the context so that less documentation is
needed - rather than just push out the needed docs.

Doesn't always work of course. Sometimes folk are stubborn :-)
Sometimes the environment can't be fixed to make it more efficient
(not much you can do if you have a client in a different timezone).
Most of the time though I find that there's an awful lot of stuff
that's being produced as a sort of comfort blanket to the client, or
because the team is put together in a particular way that makes
documentation a necessity.

As ever, YMMV :-)

Cheers,

Adrian

After you've all finished sending in your proposals for the Agile 08
User Experience Stage

	 http://submissions.agile2008.org/node/58

<hint>

you might be interested in this :-)

Begin forwarded message:
[snip]
> Call for Papers
> Cooperative and Human Aspects of Software Engineering
> - Workshop at ICSE 08
> - Tuesday, May 13th, 2008
>
> http://softwareresearch.ca/seg/CHASE/
> _____________________________________________________
>
> Theme
> =====
>
> Software is created by people - software engineers working in varied
> environments, under various conditions. Thus understanding the
> cooperative and human aspects of software development is crucial to
> understanding how methods and tools are used, and thereby improving
> both
> the creation and maintenance of software. Recently, a renaissance is
> occurring in this research area, with a large amount of research being
> published in software engineering venues as well as other research
> discourses. Thus the time is ripe to bring together researchers to
> share
> knowledge, and further build the research area.
>
> The goal of this workshop is therefore to provide a forum for
> discussing
> high quality research on the cooperative and human aspects of software
> engineering, as well as a meeting place for the nascent community that
> is currently distributed over several research domains (e.g. HCI, SE,
> CSCW, and IS).
>
> Topics of Interest
> ==================
>
> include but are not limited to:
>
> * Software engineering as cooperative work,
> * Social and cultural aspects of software engineering,
> * Psychological and cognitive aspects of software engineering,
> * Managerial and organizational aspects of software engineering
> * Coordination of large scale software development,
> * Cooperation between software developers and other professionals over
> the lifetime of a system.
> * Knowledge management in software engineering.
>
>
> Submission
> ==========
>
> Prospective participants are invited to submit position papers (up
> to 4
> pages) on a topic of relevance using the same format required for the
> ICSE technical papers (posted at
> http://icse08.upb.de//calls/fsguidelines.html). Please see CHASE
> website
> for additional submission instructions.
>
>
> Important Dates
> ===============
>
>     * 24 January - deadline for workshop paper submission
>     * 7 February - notification of acceptance by workshop chairs
>     * 21 February - camera-ready deadline for workshop papers
>
> Workshop Organisers and Program Committee
> =========================================
>
> * Li-Te Cheng, IBM, li-te_cheng at us.ibm.com
> * Cleidson de Souza, UFPA, cdesouza at ufpa.br
> * Yvonne Dittrich, IT University of Copenhagen, ydi at itu.dk
> * Michael John, Fraunhofer, Michael.John at first.fraunhofer.de
> * Orit Hazzan, Technion, oritha at techunix.technion.ac.il
> * Frank Maurer, University of Calgary, frank.maurer at ucalgary.ca
> * Helen Sharp, Open University, H.C.Sharp at open.ac.uk
> * Janice Singer, NRC, janice.singer at nrc-cnrc.gc.ca
> * Susan Elliot Sim, University of California Irvine, ses at
> ics.uci.edu
> * Jonathan Sillito, University of Calgary, sillito at ucalgary.ca
> * Margaret-Anne Storey, University of Victoria, mastorey at uvic.ca
> * Bjornar Tessem, University of Bergen, Bjornar.Tessem at
> infomedia.uib.no
> * Gina Venolia, Microsoft Research,Gina.Venolia at microsoft.com
[snip]

Cheers,

Adrian

On 14 Jan 2008, at 17:39, Jeff White wrote:
[snip]
> In my experience, getting design ahead of actual development is
> crucial in that it allows time for user centered design - usability
> testing, interviews, ethnography, etc - results from these activities
> can be delivered to the entire team prior to the sprint in which
> they'll work on a certain feature. It also allows for use cases for
> features to be somewhat fleshed out before sprint planning.
>
> Also, providing the team with a more holistic vision of what the
> entire product *may* end up being provides a lot of value. Having an
> eye towards the big picture allows current work to be built in a more
> reusable, scalable fashion and prevents some re-work. It's easy to
> loose sight of this when strictly focusing on a single sprint.

There are certainly larger "scale" (for want of a better term) issues
that fall outside that of an individual sprint. I'm more than fine
with that :-)

I know that a bunch of people run their UX group an iteration ahead
of engineering. They act in the customer role and work to develop the
stories for iteration N+1 while the developers are working on
iteration N. I can understand how that can work well. Although my
preference is to try and do as much work as possible during iteration
N, which blurs the customer/developer divide a bit.

What machappy553(?) seemed to be saying when s/he said:

"Also, we send our prototypes through user experience testing. SO
MUCH BETTER THAN PAPER PROTOTYPES and so so so far ahead of (several
sprints usually) of when engr would have work ready"

was that they were developing functional prototypes _many_ iterations
ahead of the development group. I'm interested in why they found this
necessary, since I've not found prototyping features this far of
development to be a useful way of spending money.

Cheers,

Adrian

On Jan 15, 2008 6:03 AM, Adrian Howard <adrianh@...> wrote:

>
>  I know that a bunch of people run their UX group an iteration ahead
>  of engineering. They act in the customer role and work to develop the
>  stories for iteration N+1 while the developers are working on
>  iteration N. I can understand how that can work well. Although my
>  preference is to try and do as much work as possible during iteration
>  N, which blurs the customer/developer divide a bit.
>

I'm hoping you can elaborate on this a bit. A problem I've been
running into recently is that if functionality for a certain feature
isn't pretty much fleshed out before the planning session for the
sprint in which it will be worked on, it really complicates things and
results in less efficient planning sessions and less productive
sprints.

The first thing engineers ask me when estimating the work needed to
build a feature is "how does this work" - if we have to figure that
out at the same time as we develop it, it's often deemed an unhealthy
backlog item and pushed out for further discovery. Or, the actual time
needed to build is way more than the original estimates, meaning we
have to take a break mid-sprint and re-plan.

For me, this all boils down to the difference between UCD and design
by democracy. I prefer the former for lots of different reasons, but
I'm curios to hear what others think.

Jeff

--- In agile-usability@yahoogroups.com, Adrian Howard <adrianh@...>
wrote:
> Could you talk a bit more about where/why you've found Axure better
> than paper prototyping?

Oh yes. Couple fronts. For roughly the same amount of designer time
(really), you can have something the moves and feels alot like your
application (or parts of it) to send up to product owners and to put
in testing.

We have found prototypes show us interaction problems and poor button
placements and missed expectations alot better. Users can actually try
out an Axure prototype vs. staring and speaking about a paper one.
This moves testing up WEEKS and WEEKS sometimes...so we have a chance
of getting big problems into future iterations or even sometimes
dismissing them ahead of development.

When our UX group gets directives from product owners, it's pretty
vague. The Axure prototypes allow us to spend an hour or two
translating whiteboard conversations with them into a prototype and
sending back up so the product owner can feel what they are requesting
or what you are suggesting...it completely removes the churning ball
of fish that was previously sent into engineering for development (and
then sent back up much later in the game when product owners flinch
over making big changes).

Then, we've had very positive response from engrs on them. Big nasty
spec (or trickles of documentation within sprints) vs. moving, mostly
working prototype? They actually ask for a prototype now over
documentation and you get smurfy questions like "I know you want it
work move like this, but our controls permit...what do you think
about..." over "*flips pages*...so how did you want this to work
again?"

I still do documentation (Axure has a "getting better" mechanism for
this) - but it's alot less and more in response to
iterations/revisions.

The bottomline is that we get ALOT more feedback from working
prototypes than paper ones and we have alot more visibility into the
major issues in design. We also cut alot of the waffling and revisions-
in-engring off.

I am sure there are other tools (product owners were looking into 5
digit documentation systems when we were pushing for Axure), but we
found the price point something we could move through and the tool
quick enough to use in an iterative manner with a very small UX team
(there's <> 3 of us and > 30 engrs, so we cannot be decided to a
single project in an iteration).



> Could you talk a little bit about why being several sprints ahead of
> engineering is useful?
>
> Adrian
>

I think someone already responded to this in the same way I would
(Jeff - could posts down). Depending on the size of the product, we
try to work ahead on the *major* stuff. (we did try to start desing
and engr in the same sprint several times and UX felt they had to make
hasty decisions and engr just generally hated it and got through alot
less).

Working ahead (if only slightly) allows product owners, UX, engineers,
and assorted stakeholders to be on the same page about the big picture
before it goes into engr. The "move this here and try this there" has
been lifesucking to engrs in my experience and so if we have the
general idea (and it has been tested) prior to engineering, we get
alot more traction on the iterations we do need and get alot more
features in vs. waffling on interface (and interation) opinions. Then
in interactions, we can do smaller bits of testing on single features
and actually get traction on those vs. still testing for proof of
concept.

> "Also, we send our prototypes through user experience testing. SO
> MUCH BETTER THAN PAPER PROTOTYPES and so so so far ahead of (several
> sprints usually) of when engr would have work ready"
Ok you need some time for that (though several iterations
might hint at some overpolishing), I'm also interested in
getting to know what value you get from producing prototypes
iterations ahead ?...

I think we're getting back to what Brian Weiss mentioned at
the beginning of this thread : having hi-fi prototypes too often
leads to stakeholders pointing to differences and details in
production work.

So this leads me to some other question ?
What does prevent user experience testing to be conducted with
paper prototypes (+ trend boards + visual identity sketches) ?

My own opinion : not much.

Thomas

Hiya - thanks for your comments. Yet more annoying questions follow :-)

On 15 Jan 2008, at 17:42, machappy553 wrote:

> --- In agile-usability@yahoogroups.com, Adrian Howard <adrianh@...>
> wrote:
>> Could you talk a bit more about where/why you've found Axure better
>> than paper prototyping?
>
> Oh yes. Couple fronts. For roughly the same amount of designer time
> (really), you can have something the moves and feels alot like your
> application (or parts of it) to send up to product owners and to put
> in testing.

I have to admit I find the "roughly the same amount of designer time"
hard to believe :-) Sketching stuff out on paper is pretty darn fast.
The demos on their web site don't look like they'll give me that sort
of development speed. Guess I'll have to download and play a bit.

> We have found prototypes show us interaction problems and poor button
> placements and missed expectations alot better. Users can actually try
> out an Axure prototype vs. staring and speaking about a paper one.

Perhaps we're talking about different things when we say "paper
prototype"? Folk don't just look at and talk about paper prototypes -
they interact with them too. Carolyn Snyder's book "Paper
Prototyping" is a nice introduction.

> This moves testing up WEEKS and WEEKS sometimes...so we have a chance
> of getting big problems into future iterations or even sometimes
> dismissing them ahead of development.

It's the whole "WEEKS and WEEKS" thing that I'm finding confusing. I
can understand user research, ethnographic work, etc. taking time.
But trying out design options? I'm not understanding why you need to
be so far ahead of development.

Figuring out the details of the user experience seem to be the
constraint in your software development process, which is pretty
unique in my experience. I'm interested in figuring out why if you
can spare the time to explain a bit further? :-)

> When our UX group gets directives from product owners, it's pretty
> vague. The Axure prototypes allow us to spend an hour or two
> translating whiteboard conversations with them into a prototype and
> sending back up so the product owner can feel what they are requesting
> or what you are suggesting...it completely removes the churning ball
> of fish that was previously sent into engineering for development (and
> then sent back up much later in the game when product owners flinch
> over making big changes).

Ah... Beginning to make sense here. The other agile development
practices are doing an excellent job of keeping clients / product
owner in the loop - solving that whole churning ball of fish issue
for me.

This was one of the places I used to use software prototypes for - to
reassure the product owners and stake holders that we're on the right
track. Now I have the regular delivery of vertical slices of working
functionality to do that job.

> Then, we've had very positive response from engrs on them. Big nasty
> spec (or trickles of documentation within sprints) vs. moving, mostly
> working prototype? They actually ask for a prototype now over
> documentation and you get smurfy questions like "I know you want it
> work move like this, but our controls permit...what do you think
> about..." over "*flips pages*...so how did you want this to work
> again?"

God yes - they're certainly better than many other kinds of more
formal documentation.

Paper prototypes seem to work well for me though. Along with things
like video snippets of them in operation with a user. And, of course,
being in the team room to answer questions. And having developers
involved in the testing process so they get a deeper understanding of
the issues involved.

> I still do documentation (Axure has a "getting better" mechanism for
> this) - but it's alot less and more in response to
> iterations/revisions.

Less pointless documentation is always good :-)

> The bottomline is that we get ALOT more feedback from working
> prototypes than paper ones and we have alot more visibility into the
> major issues in design. We also cut alot of the waffling and
> revisions-
> in-engring off.

I think I'm getting that feedback from working software rather than
working prototypes now. The  lo-fi prototypes are giving me just
enough information to make the working software good enough.

> I am sure there are other tools (product owners were looking into 5
> digit documentation systems when we were pushing for Axure), but we
> found the price point something we could move through and the tool
> quick enough to use in an iterative manner with a very small UX team
> (there's <> 3 of us and > 30 engrs, so we cannot be decided to a
> single project in an iteration).

I've mostly been working with much lower ratios than that - which
probably helps me. About 1 UX dude to 4-6 Engineers. UX dudes also
have development skills which also helps spread the knowledge around.

>> Could you talk a little bit about why being several sprints ahead of
>> engineering is useful?
>
> I think someone already responded to this in the same way I would
> (Jeff - could posts down). Depending on the size of the product, we
> try to work ahead on the *major* stuff. (we did try to start desing
> and engr in the same sprint several times and UX felt they had to make
> hasty decisions and engr just generally hated it and got through alot
> less).

For longer term ethnographic type work I completely understand
needing to spend more time there. I misunderstood and thought you
were talking about the nitty-gritty of product design.

> Working ahead (if only slightly) allows product owners, UX, engineers,
> and assorted stakeholders to be on the same page about the big picture
> before it goes into engr.

The problem I find with this is that the engineers then aren't on the
same page - because they've been off doing other things. Which means
more time has to be spent bringing them up to speed, and more
communication errors result in more misinterpretations of the design.

> The "move this here and try this there" has
> been lifesucking to engrs in my experience and so if we have the
> general idea (and it has been tested) prior to engineering, we get
> alot more traction on the iterations we do need and get alot more
> features in vs. waffling on interface (and interation) opinions. Then
> in interactions, we can do smaller bits of testing on single features
> and actually get traction on those vs. still testing for proof of
> concept.

Of course, whatever works is good ;-) For me the lo-fi work is giving
us enough feedback so that we're not pointlessly churning. We then do
more user testing on the software that comes out of each iteration
and feed that info into the next release. Seems to work okay :-)

Cheers,

Adrian

On 15 Jan 2008, at 20:27, thomas lissajoux wrote:

[snip]
> So this leads me to some other question ?
> What does prevent user experience testing to be conducted with
> paper prototypes (+ trend boards + visual identity sketches) ?
[snip]

For me the time I move to a software prototype are when both of these
are true:

a) I can't do it with paper (e.g. the "pinch" gestural interface you
use on things like MS Surface and the iPhone to resize/zoom stuff.)

b) The cost of "really" building it in the production environment is
significantly (say at least twice) as expensive as prototyping it

A quick copy'n'paste from a similar ramble on the IxDA list earlier
this week :-)

<snip>
I used to work at three levels

a) Low-fi work (paper prototypes, whiteboard sketches, etc.)
b) Prototypes (functional prototypes, hi-fi visuals, etc.)
c) Production ("real" code)

These days I find that (b) has been mostly squeezed out between (a)
and (c).

* I do more testing / communication work with (a) which is even cheaper.
* Development is throwing out new demoable releases on a regular
basis, which reassures everybody that real progress is being made in
the right direction - getting rid of another reason why I used to
build more functional prototypes.
* I'm working with developers that have adopted some really neat
technologies and development practices (mostly from the agile world)
that means they can produce quality code quickly and easily without a
lot (if any) of wasted work.
* Working with the developers, rather than producing prototypes off
by myself, means that the developers naturally pick up more of the
"whys" behind the design - making the whole development process easier.
</snip>

It's not so much that I don't think you can get valuable things from
functional prototypes. It's just that, over time, I'm finding that I
get that value quicker and cheaper from other places.

Cheers,

Adrian

On 15 Jan 2008, at 15:31, Scott Preece wrote:

> I tend to think that you have to do the UCD work before the
> iteration where the design is going to be implemented, because UCD
> itself takes time - multiple iterations with users - that doesn't
> directly involve the developers (unless you're in a situation where
> developers are also qualified and performing UCD roles), so the
> developers presumably should be doing something else during that
> time. A lot of agilists, on the other hand, want to do the UCD
> iterations on the actual product code, rather than on prototype/
> wireframe code, so that when the design is complete, the
> implementation is, too. In that case, everyone is working on the
> same things, at the same time.
>
> YMMV, depending on how fast you can iterate the artifacts you're
> using for the UCD...

Yup. I'm definitely tending towards the latter camp over time. I'm
mostly doing web dev work though which means I have a bunch of useful
development tools available that let me iterate "real" code darn
quickly. I'm less certain how well I could do this in the desktop
application world.

Although the newer Apple/MS tools make it look a lot easier than it
used to be back in the day :-)

Cheers,

Adrian

Hi Jeff,

On 15 Jan 2008, at 15:06, Jeff White wrote:
[snip]
> I'm hoping you can elaborate on this a bit. A problem I've been
> running into recently is that if functionality for a certain feature
> isn't pretty much fleshed out before the planning session for the
> sprint in which it will be worked on, it really complicates things and
> results in less efficient planning sessions and less productive
> sprints.

Hopefully my recent ramblings answered some of your questions :-)
Basically:
* Longer term understanding-the-user / ethnographic type stuff is
ongoing
* Just enough lo-fi prototyping to figure out that we're in the ballpark
* Development of other features in real environment for testing

> The first thing engineers ask me when estimating the work needed to
> build a feature is "how does this work" - if we have to figure that
> out at the same time as we develop it, it's often deemed an unhealthy
> backlog item and pushed out for further discovery. Or, the actual time
> needed to build is way more than the original estimates, meaning we
> have to take a break mid-sprint and re-plan.

I think we worry less about getting something right first time, since
we're more confident that we have processes in place for getting from
a not-so-good solution to a fairly-good to a rather-nice solution
without stupid amounts of waste.

Building something, going "that sucks", and then throwing it away
takes less effort and teaches everybody more than getting the design
right with more functional prototype phases first.

> For me, this all boils down to the difference between UCD and design
> by democracy. I prefer the former for lots of different reasons, but
> I'm curios to hear what others think.

I wouldn't characterise what we do as design by democracy. I'd
characterise it as design by consensus. People are more than willing
to let the folk who know most about a particular domain have the most
input, but everybody is involved in the process. Which means
everybody has more knowledge and can build better solutions. I don't
see a conflict between that and UCD :-)

Cheers,

Adrian

> Paper prototypes seem to work well for me though. Along with things
> like video snippets of them in operation with a user. And, of course,
> being in the team room to answer questions. And having developers
> involved in the testing process so they get a deeper understanding of
> the issues involved.

There is a great series of examples called "X in plain English". These
are low tech paper-based tutorials on technologies like Wiki, RSS,
Social Networking, etc...

For example, this is the one on wikis:

http://www.commoncraft.com/video-wikis-plain-english

Alain

Hello, (with our apologies for any duplicates)

We are looking for speakers for our panel on Agile Web Design.

If you are interested in exchanging on collaborative and agile
development, UCD and web design, and sharing your thoughts
on the subject let us know before January 25.

Thomas Lissajoux

---
Call for Proposals
WIF 2008 Panel : Agile Web Design
17-19 April 2008, Limoges, France

Submissions deadline: 25-Jan-08
Notification date: 30-Jan-08

Event website:
http://www.webdesign-festival.com/2008/spip.php?lang=en

WebDesign International Festival
--------------------------------
   From April 17th 2008 to April 19th in Limoges, France, the WIF
   is both a competition and a conference.
   Learn more about the WIF :
   http://www.webdesign-festival.com/2008/spip.php?lang=en

   In the Competition, contending teams from all over the world
   will compete on one subject at the same time. Learn more about
   the Competition :
   http://www.webdesign-festival.com/2008/-About-

   There will also be a conference on webdesign, with 4 tracks :
   * Mobilities at the time of Web2.0,
   * Designing for the senses,
   * New uses : rich interfaces and augmented reality,
   * New design practices : professional communities and
    methodological tools.
   Learn more about the Conference :
   http://www.webdesign-festival.com/2008/-Conferences,28-

Panel on Agile Web Design
-------------------------
   With the growth of the web2.0, websites go beyond what standard
   technologies and organizations previously achieved. In an ever
   faster market, their capacity and flexibility is always
   increasing. New websites and webapps appear every day.

   Today, designing for the web is a continuous challenge.
   Designers must innovate and provide a great experience to
   demanding users.

   Just as the social web is based upon collective intelligence,
   agile web develoment and interaction design thrive on
   exploiting collaboration and engaging the user.

   Specialists in the fields of User Experience and Web
   Development will describe how they take advantage of
   collaboration. They will reflect on their experiences with new
   strategies, practices and techniques that are being used to
   allow for this fast-paced innovation. They will tell us about
   how webdesign is changing.

Submitting a proposal
---------------------
   If you are interested in participating to this panel, just
   reply to this mail and let us know ! Should you have any
   questions related to the WIF, the conference or the panel
   itself, I will be happy to answer you the best I can.

   You are invited to position yourself on 2 or 3 issues among
   which to choose from, so that the discussion can be articulated
   among the speakers.

   Submissions should be sent before Jan 26th and the final
   approval will be announced shortly on Jan 30th.

   In case we have too many speakers for the panel on Agile Web
   Design, submissions are also open for presentations on the 4
   tracks, so do not wait and submit your proposal now.

Travel and Accomodation
-----------------------
   Selected speakers will be invited in Limoges for the WIF in
   April 2008. Your travelling costs, bookings, accommodation and
   meals will be catered for by the WIF organization.

   Air France will be the official carrier for the WIF and the
   hotel hosting the speakers will be the Mercure Limoges Royal
   Limousin. Have a look at the accomodation here :
   http://snurl.com/royallimousin

Where and when ?
-----------------------
   April 17-19 2008, Limoges, France

As the facilitator of the panel, I am looking forward to your
participation !

Thomas Lissajoux

Systèmes Agiles - Agile Coaching
   email// thomas at systemesagiles dot com
   web//   www.SystemesAgiles.com
   tel//   +33.675.607.671

DoubleClick is a cool place to work, and getting cooler.

As we expand our revenue, we're also expanding our product line and
updating our existing UIs. And that means we need more great UX
professionals to ensure that our clients have the best possible user
experience.

Currently, we're looking for two User Experience Architects with
advanced skills in usability testing along with experience in B2B
web apps. We're an agile development shop where our usablity
professionals work side-by-side with Web Developers to design
screens in real time. No voluminous documents and a minimum of throw-
away artifacts. We develop personas drawn from onsite studies,
envision revised workflows, and perform a range of in-house, onsite
and remote usability tests to continually improve our products.

To qualify, you should have an academic background in Information
Design, HCI, Cognition, or a related field. You should also have at
least five years work experience in  UI design/usability testing,
including at least two years of work with  web-based B2B
applications. You should be facile with tools like Visio and
Photoshop, know basic HTML and javascript, and understand how ajax,
asp.net, and other emerging technologies can best be leveraged  to
increase user productivity.

We provide a high-energy, creative environment in which you can
thrive. If you can multitask efficiently, communicate effectively,
and collaborate successfully, please email
ymuncherji@.... Reference the User Experience positions.

Our reputation as estimators, even when we use Agile methods, is bad.
Agile methods provide useful techniques and practices for teams and
their customers to improve accuracy without creating illusions of
precision. Many of our estimation problems come from misunderstanding
and miscommuncation about what estimates are and from confusion with
other related concepts, such as, planning and targets. Where do errors
come from? What can we promise and how do we best serve the primary
purpose of the software estimation process?

Join Martine Devos for this Skills Matter In-the-Brain Session in
London on Thursday, 24th January, where she will guide you through the
best techniques and perception management for estimators and their
customers.

For more information & registration:
http://skillsmatter.com/agile-estimation-planning/pcd/5000

Hi Daniel,

OmniPlan works for multiple projects - I have an enterprise programme
in it for my current client...5 projects over 3+years with many
shared resources...within a single file I have 5 independent (no
dependencies) top level tasks, each containing the WBS for the
relevant project...I just collapse the ones we are not looking at and
publish PDFs when needed...

FastTrack Schedule from AECSoftware is also pretty good (I prefer
OmniPlan) and cross platform (I used it heavily when it still had a
Palm module)...

HTH

Elias.

On Jan 19, 2008, at 08:44, Daniel Castro wrote:

> Hi everyone,
> I manage multiple projects for a group of designers and client
> developers for our UX dept. I was wondering what you would
> recommend for a good project management tool that exists for Mac. I
> tried OmniPlan but it only does one project at a time ;(. Excel is
> just not cutting it anymore.
> -Daniel