UCD and Agile Programming - models of involvement

21 Jun 2006 - 1:42pm
7 years ago
12 replies
1067 reads
Mimi Knowles
2006

I have reviewed the previous postings regarding how Usability fits in with
Agile Programming and I have a slightly different question.

I am an Interaction Designer and have worked with Agile Programming teams in
two different ways. I was hoping people could comment on the methods and
provide any insight on preferred methods, etc.

1. On one project, the usability team would always be an iteration
ahead of the development team, creating storyboards and fleshing out
interaction details to hand off to the development team when they were
ready. During the development iteration, the usability team would continue
supporting the actual development of the application while doing the
storyboarding for the upcoming iteration.

2. On the other project, the usability team worked in tandem with the
development team (same iteration at the same time), fleshing out design
concepts at the same time as the developers were figuring out the technical
details and coding.

I found the first method to be much more effective. Has anyone found a
particular method of involvement that works particularly well?

Thanks,

Mimi

~~~~~~~~~~~~~

Mimi Knowles

Partner / Principal Consultant

Limina Application Office, LLC

P: 808.987.9487

E: <mailto:mknowles at limina-ao.com> mknowles at limina-ao.com

http:// <http://www.limina-ao.com> www.limina-ao.com

Comments

21 Jun 2006 - 2:15pm
Paul de Curnou
2006

Mimi

We have customers who have run into these issues as well. The short answer
that I can provide is to use what is generically called the model based
development for interfaces. The key is to minimize the work products that
are thrown away from step to step. For example, if the usability folks need
to change something in the interface design, it takes too long and costs too
much to move components within the design and many people on the team are
unhappy about the compromises and the time (and money) lost.

This third way honors the original vision for a product, incorporates the
testing and simulation, and what gets deployed is something without
compromise.

Several of our customers were able to change their development process in
this manner. One in particular was very skeptical and tried both models in
parallel. The model based development process was used and the customer was
able to design, test, develop and deploy in 5% of the time that it
traditionally took. They were happy, their customer was happy, and they got
their product to market (and made money off of it) in less time as well.

Paul

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Mimi
Knowles
Sent: Wednesday, June 21, 2006 12:43 PM
To: discuss at ixda.org
Subject: [IxDA Discuss] UCD and Agile Programming - models of involvement

[Please voluntarily trim replies to include only relevant quoted material.]

I have reviewed the previous postings regarding how Usability fits in with
Agile Programming and I have a slightly different question.

I am an Interaction Designer and have worked with Agile Programming teams in
two different ways. I was hoping people could comment on the methods and
provide any insight on preferred methods, etc.

1. On one project, the usability team would always be an iteration
ahead of the development team, creating storyboards and fleshing out
interaction details to hand off to the development team when they were
ready. During the development iteration, the usability team would continue
supporting the actual development of the application while doing the
storyboarding for the upcoming iteration.

2. On the other project, the usability team worked in tandem with the
development team (same iteration at the same time), fleshing out design
concepts at the same time as the developers were figuring out the technical
details and coding.

I found the first method to be much more effective. Has anyone found a
particular method of involvement that works particularly well?

Thanks,

Mimi

~~~~~~~~~~~~~

Mimi Knowles

Partner / Principal Consultant

Limina Application Office, LLC

P: 808.987.9487

E: <mailto:mknowles at limina-ao.com> mknowles at limina-ao.com

http:// <http://www.limina-ao.com> www.limina-ao.com

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org List Guidelines ............
http://listguide.ixda.org/ List Help ..................
http://listhelp.ixda.org/ (Un)Subscription Options ...
http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org Home .......................
http://ixda.org/ Resource Library ........... http://resources.ixda.org

21 Jun 2006 - 3:24pm
Robert Hoekman, Jr.
2005

Interesting question.

I used to work in an eXtreme Programming environment, and out of sheer
necessity, I started doing what I call Just In Time Design. Much like Just
In Time in manufacturing terms, it was about getting together whatever was
needed right when it was needed. The company simply couldn't manage to
oranize itself into a process that began with design and ended with
development and testing. But they did manage to find a way to have quick
design meetings before a feature was built or changed in some way.

Basically, we'd get together and try to talk ourselves out of building the
new feature, in an effort to keep the app light. If we couldn't talk
ourselves out of it, we went into brainstorm mode and kicked off a quick
whiteboard session. One programmer, one designer (usually both of which were
me), one staff member to play "user", and one whiteboard. And we'd balze
through a few ideas, whiteboard them, map out what it would cost to
implement it, talk out the use cases, and so on.

This worked really, really well most of the time. It coordinated well with
the XP methodologies, fit with the timelines, allowed the resident UX guy
(again, me) to ensure design work was done and things were thought out
before implementing anything new, and everybody generally dug it.

We didn't have a name for it then. We just did it. Since then, I've started
calling it JIT Design.

Obviously, this doesn't lend itself well to GDD (Goal-Directed Design) or
UCD, because there was never time to do thorough research and ethnography,
and we never wrote up a single persona or spec (beyond the proposal we used
to land the project). But I've never been one to dot hese things anyway. I
believe that as long as you have a strong basic understanding of users and
how they interact with the Web, you can go the Donald Norman route and focus
design efforts on the *activity* instead of the users.

ACD is definitely my weapon of choice. It still uses a lot of what's great
about GDD and UCD, but it's a lot more functional in the real world, where
projects are completed on extremely tight deadlines with almost no
resources.

-r-

On 6/21/06, Mimi Knowles <mknowles at limina-ao.com> wrote:
>
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> I have reviewed the previous postings regarding how Usability fits in with
> Agile Programming and I have a slightly different question.
>
>
>
> I am an Interaction Designer and have worked with Agile Programming teams
> in
> two different ways. I was hoping people could comment on the methods and
> provide any insight on preferred methods, etc.
>
>
>
> 1. On one project, the usability team would always be an iteration
> ahead of the development team, creating storyboards and fleshing out
> interaction details to hand off to the development team when they were
> ready. During the development iteration, the usability team would continue
> supporting the actual development of the application while doing the
> storyboarding for the upcoming iteration.
>
>
>
> 2. On the other project, the usability team worked in tandem with the
> development team (same iteration at the same time), fleshing out design
> concepts at the same time as the developers were figuring out the
> technical
> details and coding.
>
>
>
> I found the first method to be much more effective. Has anyone found a
> particular method of involvement that works particularly well?
>
>
>
> Thanks,
>
> Mimi
>
>
>
> ~~~~~~~~~~~~~
>
> Mimi Knowles
>
> Partner / Principal Consultant
>
> Limina Application Office, LLC
>
> P: 808.987.9487
>
> E: <mailto:mknowles at limina-ao.com> mknowles at limina-ao.com
>
> http:// <http://www.limina-ao.com> www.limina-ao.com
>
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

21 Jun 2006 - 3:42pm
cfmdesigns
2004

>From: Mimi Knowles <mknowles at limina-ao.com>
>
>1. On one project, the usability team would always be an iteration
>ahead of the development team, creating storyboards and fleshing out
>interaction details to hand off to the development team when they were
>ready. During the development iteration, the usability team would continue
>supporting the actual development of the application while doing the
>storyboarding for the upcoming iteration.
>
>2. On the other project, the usability team worked in tandem with the
>development team (same iteration at the same time), fleshing out design
>concepts at the same time as the developers were figuring out the technical
>details and coding.
>
>I found the first method to be much more effective. Has anyone found a
>particular method of involvement that works particularly well?

As a software tester focusing on UI, I've worked on both sorts of projects, and I was miserable on the "agile" one. Things never felt "solid": the Dev team would push things through from the UI team as fast as they could, but with no time able to be spent on revision cyclesfrom QA because the next stuff was being handed off to them. The big fallout result was that bugs (both UI and lesser functionality) which would normally have had a "bake time" and get dealt with were being deferred or discarded midway through the Alpha phase (with nearly a year left in the project) because there was no time to fix them. Which indicates that scheduling and scoping was way out of whack by the time we got the first versions of the software to test.

The two things most missing on that project from the QA side were:

* While UI and Dev had an "agile" plan in place, QA did not. (I don't know if that'sm ineptitude by the QA managers, not realizing what they needed to do, or QA being left ot of the loop in the decision making and not knowing that the need for such plan would come.) QA had to struggle with trying to bridge traditional test methods and scheduling into the "agile" scheme; running as fast as we could just to stay in place.

* What spec review was being done prior to hand-off to develeopment was being done purely by the management team (include QA managers), not by the test engineers who would actually be working with the software. And thus the mid and low level interaction details were never questioned and never specified, leaving the answer to QA's "what should it do when?" questions being "try it and find out". (And the response to "it doesn't work right" being "too bad, that's what's in the spec".)

In the end, "agile" development and other mechanisms meant to cut through process slowdown(*) only work if you have buy-in and understanding from everyone involved. Not just the managers but all the people who will be working day in and day out on the process.

(*) We also used a spec driving process which identified approval roles, usually narrowing things down to an initiator, and couple other people who got to "vote", and two larger groups of people who would be informed and should be (but generally were not) informed. Intended to reduce the need for consensus from a groups of 6-12 people, it also allowed for shutting down of discussion and debate. QA was never in a voting position, and individual QA engineers were never in the "must be informed" set. Ergo, features and designs were approved without input from the people who needed the info.

-- Jim Drew
Seattle, WA

21 Jun 2006 - 3:53pm
Lynn Miller
2005

>
> 1. On one project, the usability team would always be an iteration
> ahead of the development team, creating storyboards and fleshing out

> interaction details to hand off to the development team when they
> were ready. During the development iteration, the usability team
> would continue supporting the actual development of the application
> while doing the storyboarding for the upcoming iteration.
>

This is the method we use and it works for us quite well. We create
prototypes (low or high fidelity) instead of storyboards, but the
concept is the same - it is something to hand off to the developers.
Working very closely with the developers as they are implementing the
design is the key to making this handoff work. (And having agile
implemented correctly in the company is the key to making anything
work.)

I wrote a paper on our method if you want more details:

http://abstractics.com/reference/LynnMillersAliasReport.pdf

Lynn Miller
Manager, User Experience Team
Autodesk

22 Jun 2006 - 12:42pm
ldebett
2004

Interestingly, I just had a discussion about this topic with my colleague
the other day. There is a big tension in system UI design between designing
for consistency and predictability within a system and the expectations of
Agile Development. Just in time design can wreak havoc on overall product
usability. In our case, all the design needs to be complete far in advance,
and supporting agile development becomes just in time documentation
delivery. It's a far better position to be in to have big picture system
design complete as well as detailed design flushed out when it comes time to
provide design documentation on specific parts.

Our discussion boiled down to this:

1. UI/IxD designers have to be way ahead of the game and have the system UI
architecture, vision, and philosophy nailed down early. We also have to have
our Interaction paradigms flushed out with patterns and rules for use
created. Specific instances of use must be thought-through via storyboards
or other design tools. Most of the problems these instances uncover (how
they break paradigms and rules, specifically) must be dealt with and solved.
All the heavy lifting must be complete and documented.

2. Graphic design languages and art direction must be (mostly) complete.

3. During the sprints, software gets fed the (mostly) completed design in
bite-sized chunks according to their development schedule. First, they get
high-level rules, overall layout/look and feel and guidelines for general
product behavior and the user interaction/system response times we expect.
When it comes time for detail implementation, they then get art assets and
documentation plus any exceptions or additions to the high-level rules for
the area they're working on. Iteration happens here as limitations are
revealed.

So, my opinion is that the bottom line for system/product/application design
(and possibly web as well) in the Agile environment is that we still must
behave like architects. We must create the blueprints up front with full
client/management/etc. approval, and when the builders come we get hand off
specifics as they need them, focusing our attention first on the whole and
then on the individual parts; making sure the implementation follows both
the high-level rules and the detailed design (and of course, making tweaks
as we learn of limitations or issues). I can't imagine designing a house
room by room with the builders in tow, without a *master plan*. Well, maybe
I can imagine it. I just wouldn't want to live in it. ;-)

~Lisa
-------------------------------------------
Lisa deBettencourt
Principal Interaction Designer
Bose Corporation

22 Jun 2006 - 1:54pm
Robert Hoekman, Jr.
2005

> Just in time design can wreak havoc on overall product
> usability.

Yes, it can. But this certainly isn't true for every app. Simple ones with
just a few screens can be done Just In Time with much success. More
complicated stuff, though, I agree should come from a big-picture
perspective.

1. UI/IxD designers have to be way ahead of the game and have the system UI
> architecture, vision, and philosophy nailed down early. We also have to
> have
> our Interaction paradigms flushed out with patterns and rules for use
> created. Specific instances of use must be thought-through via storyboards
> or other design tools. Most of the problems these instances uncover (how
> they break paradigms and rules, specifically) must be dealt with and
> solved.
> All the heavy lifting must be complete and documented.

Hey, I'm all for it, but most projects simply do not have this kind of
timeline and most companies do not have a process this organized. It just a
fact. IxDers seems to want to rely on academic processes a lot, and the fact
is, it just doesn't work 80% of the time. Sure, if you work for a UX design
firm, and that's all you do, then heck yeah, go for it. But I work for a
web-based software company that is in a constant state of "get it out now,
and be the best". Not conducive to IxD processes.

The fact is, most of us are capable of telling someone how to make a screen
better. How to make an interaction or task flow better. How to strip it
down, focus it, refine the design, etc. We all know how to do this. And when
UCD doesn't work, this is often all you can do. If that's true, who are we
to say it's a bad method. If it's the ONLY method, it's a million times
better than nothing.

-r-

22 Jun 2006 - 3:00pm
ldebett
2004

>It just a fact. IxDers seems to want to rely on academic processes a lot,
and the fact is, it just >doesn't work 80% of the time. Sure, if you work
for a UX design firm, and that's all you do, then >heck yeah, go for it. But
I work for a web-based software company that is in a constant state of >"get
it out now, and be the best". Not conducive to IxD processes.

I guess I'm a lucky part of the 20% where it can work. And I work for a
multi-billion dollar consumer electronics company that produces products
from conception to shrink-wrap. My division is signed up to the "academic
process" where design time is built into the schedule at the beginning of a
project - often far before even one software engineer gets assigned to the
project. We're also in a constant state of "get it out now and be the best"
only the whole world doesn't see our churn as it happens - it's hidden in
these walls until the product hits the shelves. And then we're on to the
next design.

~Lisa

22 Jun 2006 - 3:37pm
Adrian Howard
2005

On 21 Jun 2006, at 19:42, Mimi Knowles wrote:
[snip]
> I am an Interaction Designer and have worked with Agile Programming
> teams in
> two different ways. I was hoping people could comment on the
> methods and
> provide any insight on preferred methods, etc.
>
> 1. On one project, the usability team would always be an iteration
> ahead of the development team
[snip]
> 2. On the other project, the usability team worked in tandem with the
> development team (same iteration at the same time),
[snip]

Personally I don't think that it's an either-or situation. I try and
do both.

Some aspects of IxD belong (to use the XP term) in the Customer role.
It's requirement definition. This kind of work very naturally sits
ahead of the development work the team is doing.

Other elements of IxD, the detail work, sits quite happily along with
the development cycle itself. At a bare minimum there is the role of
an educator - getting the IxD related design concepts across to
everybody involved so mistakes don't happen through ignorance.

Cheers,

Adrian

22 Jun 2006 - 3:45pm
Adrian Howard
2005

On 21 Jun 2006, at 21:24, Robert Hoekman, Jr. wrote:
[snip]
> Obviously, this doesn't lend itself well to GDD (Goal-Directed
> Design) or
> UCD, because there was never time to do thorough research and
> ethnography,
> and we never wrote up a single persona or spec (beyond the proposal
> we used
> to land the project).
[snip]

I find these sort of activities fit nicely into the pre-development
activities. Persona, especially, I've found an /excellent/ tool to
use with agile development environments. The persona summaries sit
right up there next to the story cards as a continual reminder about
who we're building the application for.

Of course that may mean that after a few iterations and releases you
discover that the persona's you were targeting might not be quite as
important as you first thought...

Adrian

22 Jun 2006 - 3:48pm
Adrian Howard
2005

On 21 Jun 2006, at 21:42, Jim Drew wrote:
[snip]
> As a software tester focusing on UI, I've worked on both sorts of
> projects, and I was miserable on the "agile" one. Things never
> felt "solid": the Dev team would push things through from the UI
> team as fast as they could, but with no time able to be spent on
> revision cyclesfrom QA because the next stuff was being handed off
> to them.
[snip]

As you correctly note later - this really doesn't sound like a very
agile environment at all.

[snip]
> In the end, "agile" development and other mechanisms meant to cut
> through process slowdown(*) only work if you have buy-in and
> understanding from everyone involved. Not just the managers but
> all the people who will be working day in and day out on the process.
[snip]

Is there any process that will work without buy-in and understanding
from everyone involved :-)

[snip]
> (*) We also used a spec driving process which identified approval
> roles, usually narrowing things down to an initiator, and couple
> other people who got to "vote", and two larger groups of people who
> would be informed and should be (but generally were not) informed.
> Intended to reduce the need for consensus from a groups of 6-12
> people, it also allowed for shutting down of discussion and
> debate. QA was never in a voting position, and individual QA
> engineers were never in the "must be informed" set. Ergo, features
> and designs were approved without input from the people who needed
> the info.
[snip]

That sounds about as far from an agile "whole team" environment as
you can get. My sympathies.

Adrian

22 Jun 2006 - 6:13pm
Jared M. Spool
2003

At 04:48 PM 6/22/2006, Adrian Howard wrote:
>Is there any process that will work without buy-in and understanding
>from everyone involved :-)

The US Congress?

24 Jun 2006 - 2:57pm
cfmdesigns
2004

Adrian Howard <adrianh at quietstars.com> writes:

> > (*) We also used a spec driving process which identified approval
>> roles, usually narrowing things down to an initiator, and couple
>> other people who got to "vote", and two larger groups of people who
>> would be informed and should be (but generally were not) informed.
>> Intended to reduce the need for consensus from a groups of 6-12
>> people, it also allowed for shutting down of discussion and
>> debate. QA was never in a voting position, and individual QA
>> engineers were never in the "must be informed" set. Ergo, features
>> and designs were approved without input from the people who needed
>> the info.
>[snip]
>
>That sounds about as far from an agile "whole team" environment as
>you can get. My sympathies.

Well, that was a different process, adopted company wide rather than
just on our team. And while too much push for consensus can be a bad
thing, this seemed to go in the opposite direction. What was one
"And what do you think" became "We don't need input from you.'
--

----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
Jim Drew Seattle, WA cfmdesigns at earthlink.net
http://home.earthlink.net/~rubberize/Weblog/index.html (Update: 5/2)
(Subject: Movie Commentary: I, Robot)

Syndicate content Get the feed