Hi Susan,

I'm really excited to learn from the redesign for
www.gatesfoundation.org. I would be specifically keen know what
process you follow.

I have been involved with agile teams on web applications, ergo, keen
to learn how different it it while working on an information heavy
website.

Looking forward!

Regards,
Ninad Raval


--- In agile-usability@yahoogroups.com, "Susan Campbell" <urbanga@...>
wrote:
>
> Hello,
>
> Just a quick note of introduction. I'm a user experience consultant
> and new to Agile, although iterative design has been a part of my
> practice all along.
>
> I'm currently blending Agile + UCD for the redesign of the Bill &
> Melinda Gates Foundation web site.  We're doing a lot of user research
> to inform the process and you can see some results at:
> www.gatesfoundation.org/redesign.
>
> I am excited to learn from and share with this group.
>
> Thanks,
> Susan Campbell
> Seattle
>

Have folks here implemented (or evolved in parallel) Adaptive Path's
sketchboard approach as an alternative to or a way to feed the
construction of wireframes? And if so, how do you like it?

You can see their description of it here:

http://www.adaptivepath.com/ideas/essays/archives/000863.php



Thanks,

William

This is a reminder. Please distribute this email. Data on both agile
and plan-driven projects are welcome.

To Whom It May Concern,

My name is Donald Buresh, and I am a Ph.D. student at Northcentral
University located in Prescott Valley, Arizona. The reason that I am
writing to you is because I would like you to participate in an
internet survey for my dissertation. The topic of my dissertation is
assessing agile project management and customer satisfaction. The web
site where you can find my survey is: www.assessingagilepm.com.

The questionnaire will ask you about a software development project
that was recently completed within your organization. It will take
you about 15 minutes to answer the questions. The questionnaire will
ask you a series of questions about the project, including whether
the software product was developed using agile-driven or plan-driven
methods. If you do not know the answer, the questionnaire will ask
you a series of three questions, and based on your responses, it is
smart enough to decide what software methodology was employed. The
questionnaire will then ask you other questions about the software
development project. If at any time you decide not to participate in
the survey, you need only exit the survey window, and your data will
not be collected. When you have completed the survey, please press
the appropriate button to submit your responses, and then close the
survey window.

All of your responses will be anonymous and all of your data will be
held in the strictest confidence. From your responses, it will not be
possible to identify you or your organization. Since the data
obtained from this questionnaire will be used in my doctoral
dissertation, the results may possibly appear in an academic or trade
publication. None of your responses will ever be revealed.

Thank you for considering to participate in this survey. If you do
participate in the survey, and want to obtain a copy of my
dissertation, please do not hesitate to respond to this email, and
let me know. When the degree has been granted, and the dissertation
has been accepted and published, I will be more than happy to send
you an electronic copy. Again, thank you for your time.


Donald L. Buresh
3115 Enoch Avenue
Zion, IL 60099
Home Tele: 847-872-1659

I have used what I have called story boards, and I know the guys at
yahoo have used cartoons to illustrate concepts and stories.  The key is
to make sure that the story that is being told is kept in mind, much
like a good cartoon.  I have done illustrations with stick figures, and
with cartoon type characters both with good use.  It is actually part of
the contextual inquiry process as well (or at least very similar to
something in the CI process)

daveb

I have been doing agile for about 2 years now (scrum xp). I'm primarily
a UI Interaction designers for a corporate enviornment(10 years). I've
been heavily involved in agile methodologies and trying to help coach
our other teams.

I came across this group through James Shore and his recommendation to
visit Jeff Patton's blog. I currently have a article blog
(http://www.uidesignguide.com) that focuses on UI design methodologies
and how we can work along-side, or in harmony with an Agile approach.
It's goign to take me awhile to read through all these posts. I hope to
get up to speed quick.

I have many questions! I'm very happy to have found this group! I just
hope it is an active one.

I am willing to give this a try. It may be tricky to pull off, but I
think it is a good approach. I can see how adapative path would utilize
this for "web designs." This may also work for complex web application
designs. Of course, in some enviornments you have to be careful because
what goes up on the wall becomes part of an "unspoken" requirement.

The design may be flawed but "we" the business users saw it on the wall
so it must be un-changing. Of course, this could be overcome by simply
putting a big red disclaimer "Designs expected to change, will change,
are going to change..."

I think a combination of sketch, story, and cartoons (where we
required) should be used. Whatever it takes to convey your idea to the
client / business owner is what should be used!



--- In agile-usability@yahoogroups.com, david broschinsky <daveb@...>
wrote:
>
> I have used what I have called story boards, and I know the guys at
> yahoo have used cartoons to illustrate concepts and stories.  The key
is
> to make sure that the story that is being told is kept in mind, much
> like a good cartoon.  I have done illustrations with stick figures,
and
> with cartoon type characters both with good use.  It is actually part
of
> the contextual inquiry process as well (or at least very similar to
> something in the CI process)
>
> daveb
>

--- In agile-usability@yahoogroups.com, "imaginethepoet"
<imaginethepoet@...> wrote:

> Of course, in some enviornments you have to be careful because
> what goes up on the wall becomes part of an "unspoken" requirement.
>
> The design may be flawed but "we" the business users saw it on the wall
> so it must be un-changing. Of course, this could be overcome by simply
> putting a big red disclaimer "Designs expected to change, will change,
> are going to change..."

I agree that this danger exists. The effect may be reduced, though,
because iterating and designing alternatives is an integral part of
"sketchboarding" and this may prevent stakeholders from getting stuck
on one single solution too early.

As Brandon describes in his posting at Adaptive Path, the effect may
be more severe with early wireframes, especially for designers, whose
creativity can be constrained too early so that they miss the big picture.

>
> I think a combination of sketch, story, and cartoons (where we
> required) should be used. Whatever it takes to convey your idea to the
> client / business owner is what should be used!

And whatever it takes to clarify the fact that ideas may be subject to
change ;-)

As an usability manager I have been working on agile projects with user stories
for more than
a year but only at the sprint /iteration level.  I noticed that it is often too
late in the process
to start to try to get usability related acceptance criteria included into
sprint level user stories
once two weekly sprints have started especially if there is not a 'usability'
related user story
at release level or project level to stress the importance of usability and
therefore the
incorporation of  a user centred methods such as user testing for instance.
Every user story is 'a promise for a conversation' and when not included at
release level I find
that the discussion around usability start often too late.
I have been told that including 'usability' as a non-functional requirement user
story could
be a valid approach at release level  and was wondering whether someone else has
similar
experience and how best to tackle 'usability ' related user  stories at all
project levels
including acceptance criteria whilst also following  the 'invest' approach for
good user
stories.

Katharina

Not sure it makes sense to have usability as being separate from the
user story.

I think it's better if the user story is written in such a way that it
talks about what's important in that story from the point of view of
usability. Also, the Ux expert should be part of the conversation that
happens around that user story.

> -----Original Message-----
> From: agile-usability@yahoogroups.com [mailto:agile-
> usability@yahoogroups.com] On Behalf Of katharina9267
> Sent: May 7, 2008 3:29 PM
> To: agile-usability@yahoogroups.com
> Subject: [agile-usability] How to write user stories for usability at
> release and sprint level
>
> As an usability manager I have been working on agile projects with
user
> stories for more than a year but only at the sprint /iteration level.
> I noticed that it is often too late in the process to start to try to
> get usability related acceptance criteria included into sprint level
> user stories once two weekly sprints have started especially if there
> is not a 'usability' related user story at release level or project
> level to stress the importance of usability and therefore the
> incorporation of  a user centred methods such as user testing for
> instance.
> Every user story is 'a promise for a conversation' and when not
> included at release level I find that the discussion around usability
> start often too late.
> I have been told that including 'usability' as a non-functional
> requirement user story could be a valid approach at release level  and
> was wondering whether someone else has similar experience and how best
> to tackle 'usability ' related user  stories at all project levels
> including acceptance criteria whilst also following  the 'invest'
> approach for good user stories.
>
> Katharina
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Thank you Alain - are you saying then that in order to
build in usability into user stories it should be for
instance incorporated as an acceptance criteria per
user story? This makes sense to me at sprint level but
  at release level would it not make sense to have a
dedicated  user story for   'non-functional' related
areas including usability?


--- "Desilets, Alain" <alain.desilets@...>
wrote:

> Not sure it makes sense to have usability as being
> separate from the
> user story.
>
> I think it's better if the user story is written in
> such a way that it
> talks about what's important in that story from the
> point of view of
> usability. Also, the Ux expert should be part of the
> conversation that
> happens around that user story.
>
> > -----Original Message-----
> > From: agile-usability@yahoogroups.com
> [mailto:agile-
> > usability@yahoogroups.com] On Behalf Of
> katharina9267
> > Sent: May 7, 2008 3:29 PM
> > To: agile-usability@yahoogroups.com
> > Subject: [agile-usability] How to write user
> stories for usability at
> > release and sprint level
> >
> > As an usability manager I have been working on
> agile projects with
> user
> > stories for more than a year but only at the
> sprint /iteration level.
> > I noticed that it is often too late in the process
> to start to try to
> > get usability related acceptance criteria included
> into sprint level
> > user stories once two weekly sprints have started
> especially if there
> > is not a 'usability' related user story at release
> level or project
> > level to stress the importance of usability and
> therefore the
> > incorporation of  a user centred methods such as
> user testing for
> > instance.
> > Every user story is 'a promise for a conversation'
> and when not
> > included at release level I find that the
> discussion around usability
> > start often too late.
> > I have been told that including 'usability' as a
> non-functional
> > requirement user story could be a valid approach
> at release level  and
> > was wondering whether someone else has similar
> experience and how best
> > to tackle 'usability ' related user  stories at
> all project levels
> > including acceptance criteria whilst also
> following  the 'invest'
> > approach for good user stories.
> >
> > Katharina
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>



       ___________________________________________________________
Yahoo! For Good. Give and get cool things for free, reduce waste and help our
planet. Plus find hidden Yahoo! treasure

http://green.yahoo.com/uk/earth-day/

> Thank you Alain - are you saying then that in order to build in
> usability into user stories it should be for instance incorporated as
> an acceptance criteria per user story?

I'm thinking more about specific usability gotchas that might bight you
in a particular user story. I don't think saying something like "users
must be able to complete this task in 10 secs or less" is very helpful.
It's better to talk about things that might cause the implementation to
be inefficient and tell the dev how to avoid them. The kind of important
details that developers are likely to overlook.

But maybe a generic acceptance criteria can be useful, as long as they
are accompanied by a promise by the Ux specialist to have a conversation
about how to achieve this.

> This makes sense to me at sprint
> level but  at release level would it not make sense to have a
> dedicated  user story for   'non-functional' related
> areas including usability?

Can you give me an example of what such a story might look like?

Alain

Desilets, Alain wrote:
> Not sure it makes sense to have usability as being separate from the
> user story.
>

I strongly agree with this.

Each story is supposed to be a complete, releasable unit of work. That
doesn't mean it has every feature under the sun; often early stories are
very minimal. But it does mean that it should be 100% done. Not "done
except for testing." Not "done except for bug fixing." Not "done except
for polish." When a story is declared done by the team, it should be
100% done.

If you are working in a context where usability matters, then that 100%
done should include making it well designed and meeting or exceeding
your usability goals. And for stories where usability is important,
people who understand usability should be part of the conversation from
the beginning and all the way through.

That doesn't mean that you can't schedule future stories whose primary
goal is improving the user experience. Sometimes you figure out better
ways only after a story has been in production a while. Sometimes you
intentionally defer usability improvements so that you can release early
and get feedback. Sometimes you want to ship out a relatively bare-bones
product for early adopters before you come back and make it more
approachable for other target audiences.

Even then, though, it is important that be a conscious decision, with
usability experts participating fully.

William

I think you have look at the "done done" definition or acceptance
criteria and make sure your usability is included in the definition
of a stories aditional doneness. Of course,  users / customers are
using the software throughout the sprint and examining the problems
with the interactions at that point.

I would not separate out the usability aspect, but sometimes it is
extremely difficulty to get usability as part of the acceptance
criterai. It depends on customer, company, etc... The end user has to
be shown the business value to including the usability as part of the
done criteria. Sometimes this means getting buy-in from the BA /
Executive team. That makes this a very challenging process.

I have found that when usability is "addressed" as a separate story
it tends to go ignored and is seen as unimportant to the overall
feature implementation. If you expereince this, the best advice I can
recommend is: Be loud and state the obvious.

"Great our application has a ton of features can anyone use it? No?
Ok great than what was the point of putting this massive set of
features into the application?

Don't be suprised if even that fails at some point. Next you should
desmonstrate in your (sprint review) or preferably thruogh the course
of the development of each story (especially as it's related to
Usability)the problems and pain points you see as a Interaction
Designer and get those things high on the priorty story back log!

I actually talk a little bit about this in my blog.


--- In agile-usability@yahoogroups.com, William Pietri <william@...>
wrote:
>
> Desilets, Alain wrote:
> > Not sure it makes sense to have usability as being separate from
the
> > user story.
> >
>
> I strongly agree with this.
>
> Each story is supposed to be a complete, releasable unit of work.
That
> doesn't mean it has every feature under the sun; often early
stories are
> very minimal. But it does mean that it should be 100% done.
Not "done
> except for testing." Not "done except for bug fixing." Not "done
except
> for polish." When a story is declared done by the team, it should
be
> 100% done.
>
> If you are working in a context where usability matters, then that
100%
> done should include making it well designed and meeting or
exceeding
> your usability goals. And for stories where usability is important,
> people who understand usability should be part of the conversation
from
> the beginning and all the way through.
>
> That doesn't mean that you can't schedule future stories whose
primary
> goal is improving the user experience. Sometimes you figure out
better
> ways only after a story has been in production a while. Sometimes
you
> intentionally defer usability improvements so that you can release
early
> and get feedback. Sometimes you want to ship out a relatively bare-
bones
> product for early adopters before you come back and make it more
> approachable for other target audiences.
>
> Even then, though, it is important that be a conscious decision,
with
> usability experts participating fully.
>
> William
>

If the usability people are going to build in usability acceptance
criteria into the user stories it will no doubt add extra work.

Do they need to estimate that work, work out their own velocity and
build it into the user story?

Leina wrote:
> If the usability people are going to build in usability acceptance
> criteria into the user stories it will no doubt add extra work.
>
> Do they need to estimate that work, work out their own velocity and
> build it into the user story?
>

One of the things I see teams struggle with during agile adoption is
going from a team with formal roles to a more collaborative team.

In the beginning, when people are role oriented, database work is done
by the database guys, back-end development is done by the server-side
specialists, front-end development is done by the web people, and
usability is done by the human factors expert. I think this is a natural
place to start, but should be looked at as something to move away from
over time.

I think each estimated story should have a single estimate that
represents the whole team's estimate, including everything it takes to
get to 100% done. However, when scheduling stories within iterations,
the team should be sensitive to individual overload and burnout.

During iterations, teams should be working together in ways that provide
some cross-training. If not enough of that is happening, explicitly
schedule it in the course of working on stories. E.g., get together with
the front-end people, and work out the UI together. It will take a
while, but eventually your team will pick up some usability skills,
allowing the basic stuff to be done by a broad range of people. Then the
team can adjust organically to stories with different workloads, making
the concept of a team velocity much more real.

William

Hello, all;

Well, I am very new to writing user stories, and my project team is
not only new to agile methods in general but especially new to
incorporating usability.  However, I found that when I tried to
include usability criteria in the definition of Done (with a plan
in place for getting rapid user input to validate those criteria),
I got pushback from our resident agile expert because we can't
estimate in the sprint planning meeting how long it will take us
to reach the Done criterion.  If the results of having users bang
on the first prototype are, "It's great!", then we're good - but if
the results are that it needs some significant reworking, then our
initial estimates for how long it will take to complete the story
are blown out of the water.

So, with regard to the features that really need some usability
work*, my response was to have one of the Done criteria be that user
evaluation has been performed, but not that specific usability
criteria had to be met for that iteration to be Done.  If we find
issues in user evaluation that require significant reworking, we can
craft a user story around the specific problem that we found in
testing for the next iteration.

Do you see a major issue with that, and if so, how do your teams
estimate the story points for a user story that specifies usability
criteria that will be determined by user testing?

*Note: Our project is a little unique in that we are upgrading an
existing product that is OK usability-wise except for a few problem
areas.  So we are not doing a wholesale rethinking of the UI.

-Beth


--- In agile-usability@yahoogroups.com, "imaginethepoet"
<imaginethepoet@...> wrote:
>
> I think you have look at the "done done" definition or acceptance
> criteria and make sure your usability is included in the
definition
> of a stories aditional doneness. Of course,  users / customers are
> using the software throughout the sprint and examining the
problems
> with the interactions at that point.
>
> I would not separate out the usability aspect, but sometimes it is
> extremely difficulty to get usability as part of the acceptance
> criterai. It depends on customer, company, etc... The end user has
to
> be shown the business value to including the usability as part of
the
> done criteria. Sometimes this means getting buy-in from the BA /
> Executive team. That makes this a very challenging process.
>
> I have found that when usability is "addressed" as a separate
story
> it tends to go ignored and is seen as unimportant to the overall
> feature implementation. If you expereince this, the best advice I
can
> recommend is: Be loud and state the obvious.
>
> "Great our application has a ton of features can anyone use it?
No?
> Ok great than what was the point of putting this massive set of
> features into the application?
>
> Don't be suprised if even that fails at some point. Next you
should
> desmonstrate in your (sprint review) or preferably thruogh the
course
> of the development of each story (especially as it's related to
> Usability)the problems and pain points you see as a Interaction
> Designer and get those things high on the priorty story back log!
>
> I actually talk a little bit about this in my blog.
>
>
> --- In agile-usability@yahoogroups.com, William Pietri <william@>
> wrote:
> >
> > Desilets, Alain wrote:
> > > Not sure it makes sense to have usability as being separate
from
> the
> > > user story.
> > >
> >
> > I strongly agree with this.
> >
> > Each story is supposed to be a complete, releasable unit of
work.
> That
> > doesn't mean it has every feature under the sun; often early
> stories are
> > very minimal. But it does mean that it should be 100% done.
> Not "done
> > except for testing." Not "done except for bug fixing." Not "done
> except
> > for polish." When a story is declared done by the team, it
should
> be
> > 100% done.
> >
> > If you are working in a context where usability matters, then
that
> 100%
> > done should include making it well designed and meeting or
> exceeding
> > your usability goals. And for stories where usability is
important,
> > people who understand usability should be part of the
conversation
> from
> > the beginning and all the way through.
> >
> > That doesn't mean that you can't schedule future stories whose
> primary
> > goal is improving the user experience. Sometimes you figure out
> better
> > ways only after a story has been in production a while.
Sometimes
> you
> > intentionally defer usability improvements so that you can
release
> early
> > and get feedback. Sometimes you want to ship out a relatively
bare-
> bones
> > product for early adopters before you come back and make it more
> > approachable for other target audiences.
> >
> > Even then, though, it is important that be a conscious decision,
> with
> > usability experts participating fully.
> >
> > William
> >
>

Hi, Beth! Thanks for posting; you've raise an important point.

Beth Meyer wrote:
> I got pushback from our resident agile expert because we can't
> estimate in the sprint planning meeting how long it will take us
> to reach the Done criterion.  If the results of having users bang
> on the first prototype are, "It's great!", then we're good - but if
> the results are that it needs some significant reworking, then our
> initial estimates for how long it will take to complete the story
> are blown out of the water.
>
> So, with regard to the features that really need some usability
> work*, my response was to have one of the Done criteria be that user
> evaluation has been performed, but not that specific usability
> criteria had to be met for that iteration to be Done.  If we find
> issues in user evaluation that require significant reworking, we can
> craft a user story around the specific problem that we found in
> testing for the next iteration.
>

I think that's a great solution. Your agile expert is right that stories
should be things you can estimate and declare done. Each story must also
provide some clear business value, and that value is usually a unit of
functionality that you can ship. To understand why your solution fits,
it's worth stepping back and asking why agile people are so adamant
about the "done is done" mantra.

We like this for a lot of reasons, but the main one is clarity. If we
know what the units of work are, and how long they take, we can make
clear plans. We can avoid that baffling hell where most of the project
goals are supposedly 90% done, but we can't say when we'll finish. When
we are running behind, we can cut scope rather than slipping dates or
working 90-hour weeks. And we can look at individual units of work, see
how they went, and learn lessons from doing them that would get lost if
we had more balls in the air.

  From what I've seen, doing user testing in the middle of a story is
generally too painful, so teams will do it either before a story or,
like yours, after.

Doing it before gives you hard data that lets you specify a clear,
easy-to-estimate UI that you have high confidence will be very usable.
But how do you fit that into the agile cycle? Some teams do that with
low-fidelity testing, like with paper prototypes. In that case, the
testing never enters into the stream of stories; like other planning
work, people do it as needed to keep the story queue full.

Other teams do it by putting in stories where the team produces
prototypes specifically for user testing. Some will object that this is
wrong, in that the stories are not shippable features, but I disagree.
Most stories should ship, but you can also use your development team to
buy knowledge that is used in product planning. Knowledge about what UI
is the most usable definitely has business value.

More commonly, though, I think people do their usability testing after
stories are complete, and then they schedule follow-up cards to tweak
things. An advantage of this approach is that you can batch your testing
and do completed, in-context flows. For web shops, an even bigger
advantage is that you can release and do A/B testing or just make things
live. Either way, that gives you statistical data that can complement,
support, or drive your user testing.


To make the usability-test-after approach work, I think you need three
things. First, you have to be confident enough in your UI designs that
the cost of building and tweaking later is lower than the cost of
prototyping and then building. Second, your agile process cycles have to
be short enough that improvements and corrections can follow quickly on
the original work. And third, there has to be enough rapport on the
planning side that usability gets properly valued.

Happily, agile methods like Scrum and Extreme Programming usually make
all of those more true over time, so I see plenty of people using that
approach successfully.


William

--- In agile-usability@yahoogroups.com, "katharina9267"
<katharina.brunagel@...> wrote:
>
> As an usability manager I have been working on agile projects
> with user stories for more than  a year but only at
> the sprint /iteration level.  I noticed that it is often
> too late in the process to start to try to get usability
> related acceptance criteria included into sprint level
> user stories once two weekly sprints have started especially
> if there is not a 'usability' related user story
> at release level or project level to stress the importance
> of usability and therefore the incorporation of  a user centred
> methods such as user testing for instance.
> Every user story is 'a promise for a conversation' and when
> not included at release level I find that the discussion
> around usability start often too late.
> I have been told that including 'usability' as a non-
> functional requirement user story could
> be a valid approach at release level  and was wondering
> whether someone else has similar experience and how best
> to tackle 'usability ' related user  stories at all project
> levels including acceptance criteria whilst also following
> the 'invest' approach for good user stories.
>
> Katharina

I concur with your observations. Jeff Patton in particular, and also
I have been writing and talking lately to try to counteract this
tendency. I think more people should work to make it come alive for
teams.

http://alistair.cockburn.us/index.php/Three_cards_for_user_rights
has one antidote.
http://www.stsc.hill.af.mil/crosstalk/2008/05/0805Cockburn.html
has the more general discussion with the 3-pass recommendation at the
end.

Perhaps one of these could help motivate your team to allocate time
for usability work and usability rework in particular.

(I know those two don't talk about the need to perform usability work
early - but at least they may help get the usability topic a
legitimate topic to schedule.)

Alistair

I'm been following this question about usage and usability design
VERSUS incremental development for quite a while - since Jeff started
up this group, and talking with him, and comparing how he describes
visual designers' work v programmers work, and how I also do and see
them.

I confess that I can't yet see a way out of the conundrum.

Visual designers really do benefit from wide-band ideation, exploring
lots of ideas early and concurrently and leaving ideas on the table for
cross-pollination. The sketchboard and cartooning discussions show this
well.

Software designers/programmers these days tend to get the base idea
pretty quickly and program incrementally, changing the architecture as
they go.

I don't know what the resolution can be. Certainly, faster more sketchy
ideation period for the visual designers, learn to adjust to surprises
that show up later and learn to work incrementally ... but until and
unless someone shows up with a way to revise UIs inexpensively half-way
through a project, I can't see advocating "do visual design as you go"
as some companies are forcing their visual designers to work.

I will counter with a particular proposal that may buy visual designers
some time ... it's an idea from the old Smalltalk community back in the
early 90s. Namely - have the software designer/programmers design and
code up the system entirely to an API, not a visual interface.

The API defines the services the system needs to support and the
information structures it needs to be able to produce (and absorb).

This is fairly much independent of the visual design, the sequence of
screens, the placement of visual elements. That design can be going to
in parallel, or even a bit behind, since it will simply call upon the
interfaces.

As I wrote, this is what we recommended and occasionally did in the
early 1990s on Smalltalk projects (using the transcript window for all
I/O to start with), and I have found myself doing this with my current
project to replace my website. We have the entire website working with
absolutely no visual design in place. There is (hopefully) nothing the
visual component will ask for that we haven't already tested that the
system can produce. We are, however, a bit more experienced in talking
about what the meaning of certain requests mean in terms of
computational implication. We've recently started on the visual design
and not found any conflicts.

what this means is that the software designer/programmers can code and
test every part of their work independently of the visual design.

I don't know how this would look on a larger project with multiple
teams.

The hard part really is finding programmers who are willing to build a
headless system to an API. Most of them insist on a UI for no
particular good reason (and thereafter couple the system too closely to
the UI and get stuck after that).

If anyone else is / has played with this approach, please comment on
your experiences.

cheers - Alistair

Hi, Alistair. Good to hear from you.

aacockburn wrote:
> I confess that I can't yet see a way out of the conundrum.
>
> Visual designers really do benefit from wide-band ideation, exploring
> lots of ideas early and concurrently and leaving ideas on the table for
> cross-pollination. The sketchboard and cartooning discussions show this
> well.
>
> Software designers/programmers these days tend to get the base idea
> pretty quickly and program incrementally, changing the architecture as
> they go.
>

As somebody who has much more experience in under-the-hood design than
as visual designer, I may be wildly off base here. But this is also an
area that I've been researching, and here's my take.

My pre-agile approach as a software designer was to take the same path
as a lot of people on the user experience side are comfortable with:
lots of research, lots of planning, lots of sketching out alternatives,
and wanting to settle on one before starting to code.

The number one factor for me in getting comfortable with working
differently was learning how to safely change my designs later. That let
me do my designs when I had the most information available. There were a
variety of technical practices that made this possible, including
test-driven development, refactoring, once-and-only-once orientation,
and frequent, easy releases.

Now, I still do plenty of sketching of architectural possibilities, but
I do them on a ongoing basis, considering possible paths and
destinations. It reminds me of the way a big-city taxi driver doesn't
plan a single route, but keeps the options alive in his head, so that
when he hits traffic, he'll instantly change plans.

I think on the design side, things have lagged behind. Not because of
any fault of designers, mind you. I think it's partly because
plan-driven methods caused a lot more pain for developers than
designers, so they had more incentive to switch. And partly because one
of the big agile methods, Extreme Programming, was mainly programmer
created. But I think a big driver is that developers can make their own
software tools, and so there are more and better software tools for
solving developer problems than designer problems.

Still, at least in the web world, I think things have improved a fair bit.

The rise of CSS has been a huge help. The good agile designers I know
are just as fanatical about organizing and refactoring their CSS as
developers are about continuously improving technical architecture. And
they do it for the same reason: reducing the cost of change. Early web
frameworks were very page-focused, which pushed against the kind of
reuse that eases agility. Now there are better options for componentized
UIs, so that the same visual component may appear in may places but is
only coded once.

And coming back to your other point, headless systems that provide API
for UI, Ajax-ish approaches and better in-browser tools have made that
easier. It's not that one builds a whole back-end system first and then
puts on a UI, naturally. But people do tend to end up with a more slowly
evolving back-end system and a more quickly evolving front-end
interface. In the projects I keep an eye on, this has drastically
reduced the cost of design change, and led to a lot more lightweight
prototyping and design exploration than I saw at the beginning of the
decade.

So the way I see out of this is more of the same: new practices,
improved tools, better collaboration, and more experience making agile
design work.

William

On May 8, 2008, at 12:30 PM, Jared M. Spool wrote:
>
> I guess I'm wondering what the role of a 'vision' for the project
> is in the Agile world.
>
> As we study the differences between those organizations that
> produced great user experiences from the ones that are struggling
> to do so, we see that one key differentiator between the two groups
> is whether they have a clear vision.
>
> Members of successful teams can quickly elaborate what the
> experience of using the design will be like years in the future.
> And everyone on the team gives basically the same story. So, it's
> clear they know what the ideal is. (Keep in mind, this is a vision
> of the experience, not of the technical solution that will drive
> that experience.)....
>
> So, where in an Agile world, does vision come in to play?

At CIM, we're using an agile process to develop Fancast. UX work fell
into two camps:

1. Discrete, tactical, reactive sprint support helped design and dev
push out the next feature.

2. Strategic, visioning support communicated the *existing* product
vision to everyone on the team.

There's tension. Agilistas claim you don't need vision: you'll figure
it out when you get there. And, sure, you can, but without a vision
you have no consistent benchmark, so your day-to-day decisions are
measured with whatever current meme or trend sweeps your organization.

In reality, the agilistas don't care if you communicate the vision.
They're fighting to win more of your time for tactical work.



Two points need more focus:

First, every project has a vision, regardless of whether it's been
communicated or shared by everyone on the team. But, as Jared said,
teams with a shared vision create better products. (This should be no
surprise. Shared vision is a key factor to any organization's success.)

In my view, helping teams articulate and share their vision is one of
design's (IA, UX) chief responsibilities.

Second, agile processes manage *workflow*. They are not a way to
*design*. The two have *nothing* to do with one another. The friction
we feel comes from people (designers and developers) not
communicating priorities and status. It's a communication problem.
It's not a process problem.



Just this week, I posted six strategies for working better with agile
teams. I'd appreciate any feedback, changes, recommendations, or
comments any of you might have:
* http://www.thinkingandmaking.com/view/agile-ux-six



Thanks,
--
Austin Govella
Thinking & Making - http://www.thinkingandmaking.com
Thinking Links - http://thinkingandmaking.com/links

So, where in an Agile world, does vision come in to play?

Agilistas claim you don't need vision: you'll figure it out when you get there.[...]
In reality, the agilistas don't care if you communicate the vision. 

As would I.

Four

At 11:50 AM -0700 5/8/08, William Pietri wrote:
They do? I'd love it if you could point me at your sources for that.

At 1:22 PM -0500 5/8/08, Austin Govella wrote:
Austin Govella wrote:
So, where in an Agile world, does vision come in to play?

Agilistas claim you don't need vision: you'll figure  it out when you
get there.[...]
In reality, the agilistas don't care if you communicate the vision.
--
--
Four Hewes, Principal
Caspian Design | A Hybrid Consultancy for changing marketplace,
technology and business
Strategic Guidance | New Product Development | Product + Interaction Design

On May 8, 2008, at 1:50 PM, William Pietri wrote:
> Austin Govella wrote:
>>
>>> So, where in an Agile world, does vision come in to play?
>> Agilistas claim you don't need vision: you'll figure it out when
>> you get there.[...] In reality, the agilistas don't care if you
>> communicate the vision.
>
> They do? I'd love it if you could point me at your sources for that.

I wasn't sure if you were asking about my sources for them claiming
you don't the *need* vision, or sources that they don't care if you
*communicate* the vision.

This is based largely on my experience with agile teams, discussions
with others with experience on agile teams.

However, I've been researching this problem, and it's informed by
writing from the agile community:

Why You Won't Fix It Later:
* http://on-agile.blogspot.com/2007/04/why-you-wont-fix-it-later.html

Are we there yet:
* http://www.scrumalliance.org/articles/37-are-we-there-yet

Focus on value:
* http://www.scrumalliance.org/articles/89-focus-on-value

Kicking off the slow software movement (intro):
* http://agileproductdesign.com/blog/slow_software.html

Kicking off the slow software movement:
* http://agileproductdesign.com/writing/slow_software.pdf

Valuing outcomes over features:
* http://www.artima.com/weblogs/viewpost.jsp?thread=183405

Don't become an agile zombie:
* http://outside-in-thinking.com/?p=93

Don't know what I want, but I know how to get it:
* http://agileproductdesign.com/blog/dont_know_what_i_want.html



Is that what you were looking for? I think the clarification is that
bad agilistas poo-poo vision. They also confuse the vision with the
product.



--
Austin Govella
Thinking & Making - http://www.thinkingandmaking.com
Thinking Links - http://thinkingandmaking.com/links

On May 8, 2008, at 1:50 PM, William Pietri wrote:

Austin Govella wrote:

Agilistas claim you don't need vision: you'll figure it out when you get there.[...] In reality, the agilistas don't care if you communicate the vision.

They do? I'd love it if you could point me at your sources for that.

[...]
This is based largely on my experience with agile teams, discussions with others with experience on agile teams.
However, I've been researching this problem, and it's informed by writing from the agile community:
[long list of links removed]
Is that what you were looking for? I think the clarification is that bad agilistas poo-poo vision. They also confuse the vision with the product.