By way of background, I'm a Certified Scrum Master (for about 6 months now)
with about 10 years experience doing user experience work for the Web. My
company adopted Scrum as an Agile practice early this year.

<wave>Hi all</wave>.

It sounds like most people on the list are addressing this quandry -- and it
is a real consideration -- in pretty much the same way we are -- we try to
model the basic navigational structure as far out in front as we can and
then we plug in more-specific process design and testing incrementally as we
actually develop functionalities.

Beyond that, we typically have someone with user experience expertise
involved in every development team, which means that person is involved in
planning every 30-day development sprint. So that person is able to bring an
informed perspective about when we need to budget time for rethinking
overall UI design as development proceeds and the product requirements
change.

That heuristic approach is bolstered (when clients are willing to cover the
budget) by user experience testing that complements our basic Sprint review
, UAT and internal QA practices. We use a methodology that combines
open-ended and defined-task listening lab approaches and the open-ended
testing especially allows users to alert us to UE problems that we haven't
caught on our own. And just basic the Sprint review process, to -- come to
think of it -- will sometimes trigger a re-think of the UI. Sometimes
product owners will add UI enhancements to the product requirements as
development proceeds.

So, yeah, our two main inputs that can trigger an overall UI re-think are:

- Heuristic analysis, through incorporating UE design with everything we do
- Regular interaction with clients and end users via UAT, Sprint reviews and
UE testing using listening labs

We do still grapple with exactly how far out front to model overall
navigation, balancing those design resources against the other resource
requirements of the project and fitting those allocations into Scrum's
30-day dev sprint framework -- especially for big projects with very
ambitious product requirements right off the hop. And I'm still trying to
figure out how much of that is related to deficiencies in our processes and
how much is just part of the normal intellectual input that has to go into
any project.

Any thoughts?

Thanks.

- kent


[Get ideas, tools and insight to help your organization grow online.
Subscribe to Xaccute Ideas@Work Quarterly. Sign up now at
http://www.xaccute.com/newsletter and earn a chance to win $100 from
Amazon.ca.]

_________________________________
kent wakely
xaccute interactive :: solutions that connect
kent@...
647.722.0059 :: toronto vox/fax
1.866.576.4688 :: toll free
m.kent@... :: mobile msg
http://www.xaccute.com



> -----Original Message-----
>    Date: Wed, 14 Jul 2004 00:48:03 -0000
>    From: "Jeff Grigg" <jeffgrigg@...>
> Subject: incremental design -vs- overall user experience
>
> I can't claim to be an expert on user interface design or agile
> methods, but here's a thought that's been bothering me for a while:
>
> It's been my experience that systems that "grow organically" over
> time often have bad user interfaces.  New features are often buried
> deep within the existing user interface structure, making it hard to
> find.  New reports, for example, are added as buttons or menu
> options deep in the work flow, where they're first needed, but *not*
> made available from higher level menus.
>
> I've found that drawing screen flow diagrams of the overall system
> illustrates these problems and guides redesign of the GUI to make
> the system more usable.
>
> But...
> How can one avoid this problem in "organically growing" systems?
>
> Does the "overall user experience" need to be planned up-front, even
> when functionality is implemented incrementally?
>
> As project direction changes during implementation, what triggers
> you to recognize that the user interface flow needs to be redesigned
> to most effectively support the new business requirements you've
> discovered?

Jeff Patton wrote:
>...build that picture big, as a
>poster, and hang it in a visible place where the development team
>and customer team can see it.  As the product evolves, I'd keep that
>picture updated.  So it's not too tough to update, I might do it on
>poster paper with 3x5 cards and tape - or sticky post-it notes.
>...and so that others on the team "ingested" the information in the picture faster than
>they would by just looking at it.

I agree that exposure to these models is a great communication and education tool.
We were working on our task model and a our lead developer stopped by, he thought
the model was "cool". In fact, he was wondering what type of deliverable
we could produce that was going to capture the differences between current state
admin features, our pilot release features of the product, and what was coming out in release one...turns out our task model is the deliverable they were asking for.

>An earlier post asked where usability/interaction design stuff goes
>in agile process.  /My/ opinion is that it's a cross-cutting-
>concern - it goes everywhere.  It's a layer of what we're doing.
>certainly there are places in the process where more emphasis and
>expertise is more valuable.

Our intent is to have the user experience/usability "threaded"
throughout the project lifecycle - interaction design threaded as needed. I am planning on having our user experience/usability analysts (what's in a title is another topic of discussion) and our systems analysts to pair on writing the stories, pair w/ developers on build out issues as they relate to interaction design, and pair w/ quality
assurance analysts on the testing.

>Lastly, I don't think a usability person is a necessary role on an
>agile team.  I think the _work they do_ is necessary.  And,
>depending on it's criticality to the project, there could be an
>expert on the team, or the work could be understood and shared among
>members of the team.

The critical issue here is...ensuring that the *work* is getting done.
Whether it is done by a dedicated resource or not is secondary. More often than
not, I am the solo resource on projects to ensure the broad scope of user experience related activities are being done.

--mfs

Hello, everyone. Thanks for setting this up, Jeff!

On Wed, 2004-07-14 at 09:23, Brian O'Byrne wrote:
> I don't agree that the interaction design concern has to go
> _everywhere_. On the second of the two projects I mentioned there was
> a real n-tiered architecture and were very definitely two teams, one
> for the problem domain and one for the UI.
> The PD team followed a very traditional methodology and wrote service
> code that could be used by many different UIs. They concerned
> themselves with the business model, persistence and most of the
> technology, exposing APIs for the UI team to use.

Your point is well taken, but I think you're selling APIs a little
short. APIs, after all, are interfaces for programmers. When I'm
building an API, I ask myself a lot of the same questions that I do when
building a more traditional UI. Who will be using it? What are they
trying to accomplish? How can I make common things easy? How can I make
dangerous things hard?

This is most important when you're building APIs for broad use, of
course. EBay and Amazon have APIs used by thousands; Microsoft and Sun
sell APIs used by millions. For these, it's obvious that investment in
usability pays off. But even intra-company, inter-team APIs are worth
effort to make them usable. I've seen companies where internal APIs with
no thought of programmer usability cost tens or hundreds of thousands of
dollars in wasted effort on other teams.

So I'd agree that a team building internal code need not be particularly
skilled in building GUIs. But I do think they should be relentless in
focusing on the usability of their creations, always keeping in mind
their users and, by proxy, the real users that the system is being built
for.

William

Our organization recently adopted Agile methodologies (Scrum, Test-
driven design) in order to implement a large, multi-year, J2EE
project. We just started our fourth iteration.

One of the process questions that recently emerged is how do we
ensure that the UI Guidelines that the UI team has put together get
implemented?

Here's our process in a nutshell:
1. We have a set of UI Guidelines that all screens are supposed to
follow.
2. At the beginning of each iteration, if the goal involves UI work,
a UI designer creates a screenshot and a UI behavioral description
that details all of the expected interactions (i.e. tab order,
cursor focus, button states). These are presented to the product
owners for approval along with the test plan.
3. During the iteration, the UI designers create the Java panels and
then turn those over to the developers to "hook-up" the UI.

The problem:
The acceptance tests (JUnit) up to this point have been very simple
functionality based tests so the finished product at the end of the
iteration can pass all tests, yet not resemble the interaction that
we (the UI team) had originally intended or the Product owners
expected.

Product Owners are understandably upset, and the dev. teams respond
that since the UI behaviors weren't part of the acceptance tests,
they weren't responsible for completing them.

Any ideas on how to help resolve this issue and end the finger
pointing? Do the product owners have to detail out every UI behavior
as part of the suite of acceptance tests (even if something is
covered in the UI Guidelines)? Can/should this be done in automated
testing? Do product backlogs need to include such detailed items
like tab order?

Any input greatly appreciated! And thanks again to Jeff for getting
this group started!
-Ann

--- Jeff Patton <jpatton@...> wrote:
> Lastly, I don't think a usability person is a necessary role on an
> agile team.  I think the _work they do_ is necessary.  And,
> depending on it's criticality to the project, there could be an
> expert on the team, or the work could be understood and shared among
> members of the team.

What this says to me is that usability expertise is necessar on a
development team (whether or not agile).  As a practical matter,
because so few software engineers and programmers have that experience,
it's often necessary to bring in an expert, either as a team member or
a trainer and coach.

Gary



__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail

--- Dale Emery <dale@...> wrote:

> XP puts a gives a lot of explicit attention to simplicity from
> the developer's point of view, refactoring often to maintain
> simplicity.  What if the team had an analogous practice that
> attended strongly and explicitly to simplicity from the user's
> point of view (refactoring often to maintain simplicity)?

The problem with focusing on simplicity is that there are often
multiple usability goals, and simplicity (often characterized as ease
of learning) and productivity are often at odds, because the latter can
imply being feature rich.

Gary



__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

--- In agile-usability@yahoogroups.com, Adam Carter <a.carter@i...>
wrote:
> Jeff Patton wrote:
>
> > Lastly, I don't think a usability person is a necessary role on
an
> > agile team.  I think the _work they do_ is necessary.  >

> Funnily enough I think they are as needed as anybody else on a
well
> balanced crew.

Yeah - I think I overstated myself a little.  I was trying to place
emphasis on the activities done by the person - and not necessarily
a role or job title.  Secretly I believe there should be a usability
person on most teams.  Hopefully they're productively engaged in
those activities.

-Jeff

Jeff Patton wrote:

> Lastly, I don't think a usability person is a necessary role on an
> agile team.  I think the _work they do_ is necessary.  And,
> depending on it's criticality to the project, there could be an
> expert on the team, or the work could be understood and shared among
> members of the team.
>
> thanks,
>
> -Jeff (P)

Funnily enough I think they are as needed as anybody else on a well
balanced crew. Just like you have some software engineer ninja (or more)
to ask very apt questions to customers, and then using those questions
use their expertise to generate fantastic hardcore bits of programming
as quickly and cheaply as possible, you need Human Computer Design
ninjas who can ask the right questions, and design awesome customer
interaction paths as quickly and as easily as possible.

Heck at the end of the day it is all about business value. Usability
gurus are all about getting the customer get the most out of the product
... that sounds like business value to me.

Adam

--- In agile-usability@yahoogroups.com, Brian O'Byrne <bobyrne@s...>
wrote:
> Certainly for the first of the two projects I mentioned the chart
was
> drawn big and stuck on the wall. Everyone got used to referring to
> it, and anyone could annotate it as they worked.

The visible posting and hand notation is an ideal agile adaptation
for a technique.  If you were overly formal you might have modified
the diagram through change requests and meetings.  For better or
worse the agile community is laying claim to behavior which used to
be called "common sense."  ;-)

The fact that was done in UML and printed doesn't bug me at all -
since it was fast to do, and since using UML for that team didn't
exclude anyone.  If a business leader or someone from a traditional
XP customer role was expected to understand it, UML may have been a
barrier.

> I don't agree that the interaction design concern has to go
> _everywhere_. On the second of the two projects I mentioned there
was
> a real n-tiered architecture and were very definitely two teams,
one
> for the problem domain and one for the UI.
> The PD team followed a very traditional methodology and wrote
service
> code that could be used by many different UIs.

I'd suspect even that service code was driven at some level by the
interactions users had with the software.  If not, they'd have
implemented unused services, or failed to implement necessary
services.  The user interactions may have had a lighter day-to-day
touch on the work this team did - but I'd still assert that they
affected it.  I wouldn't have a usability guy wandering through
their team very often....

Thanks for posting Brian!

-Jeff

On Wednesday 14 July 2004 15:49, Jeff Patton wrote:
> --- In agile-usability@yahoogroups.com, "helen johnstone"
>
> <hjohnstone@b...> wrote:
> > > An effective way around this problem is to draft a navigation
> > > architecture (screen flow) in advance based on provisional
> > > understanding of user roles and tasks in the application.
> >
> > This is what I've been using for a while.
>
> I'm seeing a pattern in this post, and Brian O'Byrne's subsequent
> post: that is a big picture showing the system navigation is pretty
> valuable for detecting and helping to solve these sorts of
> problems.
>
> If I recognize that, I'm tempted to build that picture big, as a
> poster, and hang it in a visible place where the development team
> and customer team can see it.  As the product evolves, I'd keep
> that picture updated.  So it's not too tough to update, I might do
> it on poster paper with 3x5 cards and tape - or sticky post-it
> notes.  I could see building this model as a collaborative group
> activity - so it wasn't a burden to one interaction designer, and
> so that others on the team "ingested" the information in the
> picture faster than they would by just looking at it.

Certainly for the first of the two projects I mentioned the chart was
drawn big and stuck on the wall. Everyone got used to referring to
it, and anyone could annotate it as they worked.
We did use a UML modelling tool to draw that chart, and it was updated
and reprinted regularly from that tool. In that team no-one saw it as
a burden because we had suffered so long without the information
available on the chart its upkeep was seen as a very small price to
pay.

> An earlier post asked where usability/interaction design stuff goes
> in agile process.  /My/ opinion is that it's a cross-cutting-
> concern - it goes everywhere.  It's a layer of what we're doing.
> certainly there are places in the process where more emphasis and
> expertise is more valuable.  But if a big picture of the navigation
> architecture is a usability technique, I see that technique as
> being valuable most of the time through the life of the product.

I don't agree that the interaction design concern has to go
_everywhere_. On the second of the two projects I mentioned there was
a real n-tiered architecture and were very definitely two teams, one
for the problem domain and one for the UI.
The PD team followed a very traditional methodology and wrote service
code that could be used by many different UIs. They concerned
themselves with the business model, persistence and most of the
technology, exposing APIs for the UI team to use.
The UI team (where I worked) prepared the interaction design and the
UI code, calling the APIs provided by the PD team.

Thus on that project only the people on the UI team and dealing with
the user representatives needed to be aware of the interaction
design. The PD team worked with the domain experts and business
analysts to produce their bit while we prepared and implemented the
interaction design.

> I'd consider the role of a usability person on an agile project as
> a teaching/coaching role.  In regards to this technique, I'd see
> the usability person leading the work-session to build this
> navigation model.  I'd see them coaching people on a day to day
> basis on using the model and seeing how the work they're doing
> today fits into the model.  This integrates the usability person
> into the team rather them leaving them in their own silo of
> expertise.  This gives everyone working on the software a
> foundational understanding of what the usability person does and
> can give guidance in doing.
>
> Lastly, I don't think a usability person is a necessary role on an
> agile team.  I think the _work they do_ is necessary.  And,
> depending on it's criticality to the project, there could be an
> expert on the team, or the work could be understood and shared
> among members of the team.
>
> thanks,
>
> -Jeff (P)

Brian.
--
Brian O'Byrne, Statesoft Ltd.
Tel: +353 1 4498 151, +353 86 240 4719
http://www.statesoft.ie/

--- In agile-usability@yahoogroups.com, Phlip <phlipcpp@y...> wrote:
> Would it help if your Integration Tests took pictures
> of every screen (regardless of its platform) in every
> data state, and uploaded all of these to a Web site
> for you and your minions to flick thru?
>
> > I find it is a great communications tool as well for
> > the rest of the team
> > (development, sales, support etc) so they can
> > understand what we've got and
> > where it is going for those aspects.
>
> Yeah. I want to automate that. (It turns out to be
> absurdly easy.) Specifically, I want tests that drive
> a GUI view thru a sequence of states, then upload an
> animated GIF of the faked interaction.
>
> GUI changes would produce new GIFs with their
> variations.

I start to squirm when folks start to automate too much.  You want
to automate tedious tasks - but want to avoid automating tasks that
are information discovery or learning tasks.  I've had people walk
up behind me when I'm doing a CRC card activity and tell me about
how a plug-in in my IDE would produce better UML than my silly 3x5
cards.  I'm not doing the activity because I need a chart - I'm
doing the activity to learn about my software.  I'm doing it
collaboratively with others so we both learn and can discuss it
while we're doing it.

Sometimes building and maintaining design artifacts are hidden
opportunities to learn.

- But don't get me wrong - I hate hate hate doing repetetive busy-
work tasks.  Do automate those.

thanks,

-Jeff






>
>
> =====
> Phlip
>
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfac
es
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - 50x more storage than other providers!
> http://promotions.yahoo.com/new_mail

--- In agile-usability@yahoogroups.com, "helen johnstone"
<hjohnstone@b...> wrote:
>
> > An effective way around this problem is to draft a navigation
> > architecture (screen flow) in advance based on provisional
> > understanding of user roles and tasks in the application.
>
> This is what I've been using for a while.

I'm seeing a pattern in this post, and Brian O'Byrne's subsequent
post: that is a big picture showing the system navigation is pretty
valuable for detecting and helping to solve these sorts of
problems.

If I recognize that, I'm tempted to build that picture big, as a
poster, and hang it in a visible place where the development team
and customer team can see it.  As the product evolves, I'd keep that
picture updated.  So it's not too tough to update, I might do it on
poster paper with 3x5 cards and tape - or sticky post-it notes.  I
could see building this model as a collaborative group activity - so
it wasn't a burden to one interaction designer, and so that others
on the team "ingested" the information in the picture faster than
they would by just looking at it.

An earlier post asked where usability/interaction design stuff goes
in agile process.  /My/ opinion is that it's a cross-cutting-
concern - it goes everywhere.  It's a layer of what we're doing.
certainly there are places in the process where more emphasis and
expertise is more valuable.  But if a big picture of the navigation
architecture is a usability technique, I see that technique as being
valuable most of the time through the life of the product.

I'd consider the role of a usability person on an agile project as a
teaching/coaching role.  In regards to this technique, I'd see the
usability person leading the work-session to build this navigation
model.  I'd see them coaching people on a day to day basis on using
the model and seeing how the work they're doing today fits into the
model.  This integrates the usability person into the team rather
them leaving them in their own silo of expertise.  This gives
everyone working on the software a foundational understanding of
what the usability person does and can give guidance in doing.

Lastly, I don't think a usability person is a necessary role on an
agile team.  I think the _work they do_ is necessary.  And,
depending on it's criticality to the project, there could be an
expert on the team, or the work could be understood and shared among
members of the team.

thanks,

-Jeff (P)

Jeff Grigg wrote:
>Does the "overall user experience" need to be planned up-front, even
>when functionality is implemented incrementally?

My approach to this has been to integrate Constantine and Lockwood's usage-centered design, as well as Jeff Patton's agile-interaction design techniques.

I've been a practitioner of user-centered design techniques for many years and now am involved in a large-scale, multiple-release agile project to define and perform the user research, experience planning, usability, and interaction design activities. I recently had the opportunity to meet both Jeff Patton and Larry Constantine - through their presentations I was further exposed to usage-centered design (primary focus on usage rather than user). I was thinking hard about how my experience w/ user-centered design would fit in to the agile project. I was thinking along the lines of agile-usability and iterative design. My concern was that my typical upfront design activities were not desirable on this project, and in fact would not be accommodated into the timeline.

I've spent the bulk of our initial iteration on user research; on-site user observations/interviews, role and task modeling, and building out the navigational architecture. We have a dozen iterations slated before our first live production release, so I know it'll be a while before we get to some of these features and functionality, but my confidence that the UI, usability, behavior, and users experience will be consistent throughout this app is strong because we've integrated the right resources and activities to account for these areas of focus within each iteration.

I had to step away from big-upfront design, and be more focused on what to when. I'm enthusiastic about this approach, as I feel I don't have the stress of getting it right the first time - so to say. I can rely on the exposure to users throughout development, and also the fact that we've got a focus on iterative usability in our plan as well.


-----Original Message-----
From: Larry Constantine [mailto:lconstantine@...]
Sent: Wednesday, July 14, 2004 8:13 AM
To: agile-usability@yahoogroups.com
Subject: RE: [agile-usability] incremental design -vs- overall user experience


Jeff,

An effective way around this problem is to draft a navigation architecture
(screen flow) in advance based on provisional understanding of user roles
and tasks in the application. This architecture gives a reasonably well
thought out framework on which to hang the features and functions as they
arise "organically." The navigation architecture is itself reviewed and
refactored as needed as the details of the application emerge. This approach
is what I describe as "architecture-first development" in the new Cutter
Report on agility and usability. It's proven to be a good compromise that
yields maximal payoff in maintaining a sound UI organization with bare
minimal upfront investment.

--Larry Constantine
  Chief Scientist | Constantine & Lockwood, Ltd.

helen johnstone wrote:

> In order to get my head around how this all hangs
> together, and how to move
> it forward, I use screen-shots of existing screens
> and mock-ups of future
> screens. I put these in powerpoint and add workflows
> for the various
> user/business scenarios that we support. I also show
> groupings of technology
> - which obviously have a significant impact on the
> UI style and behaviour,
> as well functional groupings.

Would it help if your Integration Tests took pictures
of every screen (regardless of its platform) in every
data state, and uploaded all of these to a Web site
for you and your minions to flick thru?

> I find it is a great communications tool as well for
> the rest of the team
> (development, sales, support etc) so they can
> understand what we've got and
> where it is going for those aspects.

Yeah. I want to automate that. (It turns out to be
absurdly easy.) Specifically, I want tests that drive
a GUI view thru a sequence of states, then upload an
animated GIF of the faked interaction.

GUI changes would produce new GIFs with their
variations.


=====
Phlip
   http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces



__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Jeff,

On Wednesday 14 July 2004 01:48, Jeff Grigg wrote:
> I can't claim to be an expert on user interface design or agile
> methods, but here's a thought that's been bothering me for a while:
>
> It's been my experience that systems that "grow organically" over
> time often have bad user interfaces.  New features are often buried
> deep within the existing user interface structure, making it hard
> to find.  New reports, for example, are added as buttons or menu
> options deep in the work flow, where they're first needed, but
> *not* made available from higher level menus.
>
> I've found that drawing screen flow diagrams of the overall system
> illustrates these problems and guides redesign of the GUI to make
> the system more usable.
>
> But...
> How can one avoid this problem in "organically growing" systems?
>
> Does the "overall user experience" need to be planned up-front,
> even when functionality is implemented incrementally?

Certainly in my experience there is a value in planning the flows and
interaction up-front and capturing that in some formal or semi-formal
manner.

To take two examples from a recent employer:
One project involved an application system for financial services.
There was no interaction design produced up-front. The requirements
included being flexible enough to take applications for new financial
products as they were introduced.
The UI on that project quickly became very brittle in the face of
change. As new products came on line or the application process
changed more than half the development time was spent working around
this brittle user interface instead of dealing with the business
model.
After some time dealing with this mess the PM invested some time in
drawing a chart describing the user interaction. This chart showed
the unwanted dependencies and useless paths through the system and
allowed him to plan future changes with this information in hand. He
was then able to show a business case for refactoring the UI to
simplify future changes.

Another project was a pilot for a large desktop application to be
deployed to help customer-facing staff in a retail network. The pilot
was spec'd to include about 20% of the anticipated feature set.
An interaction design for the pilot was prepared as a UML statechart.
The pilot was deployed successfully and work is now underway to build
the bulk of the feature set. The UI components of the new features
are being added to the chart and as far as I know it is going well.
(I was involved in the pilot on that project, but am not involved in
the current work.)

> As project direction changes during implementation, what triggers
> you to recognize that the user interface flow needs to be
> redesigned to most effectively support the new business
> requirements you've discovered?

I think there is a bias in your question you need to be aware of: the
idea that the UI flow supports the business requirements. Maybe I am
just nit-picking here, but I think it important to see the UI as
serving the users rather than the business. You can have business
requirements that are met by the model or persistence while being
entirely independent of the UI, while you can have UI improvements
that are completely irrelevant to the business (except that they make
the users happier).

So if I can take the liberty of changing the question to: What
triggers you to recognise that the UI flow needs to be redesigned to
most effectively support the users? The answer is some combination of
listening to the users' questions and comments and testing (role
playing, prototyping and UAT).

Brian.
--
Brian O'Byrne, Statesoft Ltd.
Tel: +353 1 4498 151, +353 86 240 4719
http://www.statesoft.ie/

--- Dale Emery <dale@...> wrote:

> XP puts a gives a lot of explicit attention to
> simplicity from
> the developer's point of view, refactoring often to
> maintain
> simplicity.  What if the team had an analogous
> practice that
> attended strongly and explicitly to simplicity from
> the user's
> point of view (refactoring often to maintain
> simplicity)?

Who said, "Refactoring users is hard"? I have heard it
was Martha Lindeman. Maybe her words are only
available in molecular format.

The problem with refactoing a GUI mercilessly is Agile
processes also like to deliver early and often. The
best feedback comes from boosting end-user
productivity.

But users boost their productivity by bonding with
aspects of a GUI that even usability experts simply
cannot predict. (It would be nice if they bonded with
keystrokes, but today's users abuse the mouse to do
everything, even switch from one edit field to the
next.)

So a GUI feature becomes "stable" (in the Robert C
Martin sense of "highly depended on") as more and more
end-users use it. Like it or not, refactoring a GUI
can decrease productivity.

For example, Visual Studio 7 absolutely sucks. My
favorite VS6 keystrokes, such as <Shift+Ctrl+G> to
open text as a file name, no longer work. The
equivalent operation on the Context Menu doesn't work
the same.

This is an example of a re-write, not of refactoring.
But MS really slacked off here. I use VS6 without a
technical reason to open VS7.

=====
Phlip
   http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces



__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

> An effective way around this problem is to draft a navigation
> architecture (screen flow) in advance based on provisional
> understanding of user roles and tasks in the application.

This is what I've been using for a while. I'm now responsible for the user
experience of a 10+ year old large-scale software system. Every 2-3 years,
it is revolutionised by adopting new, better technology, and in between, it
evolves as needed. However, we don't get the time to move all functionality
forward so currently have 4 major UI technologies; (some of) the original
green screens, tcl/tk, java and now .NET.

In order to get my head around how this all hangs together, and how to move
it forward, I use screen-shots of existing screens and mock-ups of future
screens. I put these in powerpoint and add workflows for the various
user/business scenarios that we support. I also show groupings of technology
- which obviously have a significant impact on the UI style and behaviour,
as well functional groupings.

I find it is a great communications tool as well for the rest of the team
(development, sales, support etc) so they can understand what we've got and
where it is going for those aspects.

Best,
- h

Agile-Usability:

Sometimes two or more different user interfaces must
cover the same Logic Layer. One common industry reason
is versioning. Version 5, for example, will have many
new features, and these deserve a re-designed user
interface. Version 4, however, is still available for
release, and V4 shares the older features in V5's
Logic Layer. Customers suffering with V4 bugs should
not be told, "Wait for V5. It will fix your bug, and
it also has a new and improved user interface that
looks completely different!"

The least brave, and least wise, solution to this
problem is to fork the entire code base, then mirror
every bug fix between V4 and V5. Forking a code-base
is duplication, like any other, and should be fixed
while it's simple, before it drags down a team's
productivity.

As soon as the V4.1 user interface no longer "looks
like" V4, duplicate only the GUI elements that are
different. The program's "skin" will be a
configuration setting. Methodologies that prevent GUI
code from turning into spaghetti will support this
"user view fork" very easily. Configure the test rig
to exercise both versions simultaneously. Look up
"Abstract Tests".

Similarly, many projects release more than one
application built out of a single core. The
differences between each "flavor" of application could
be as simple as tiered price/feature points-Personal,
Standard, Premium, Enterprise Editions - or as complex
as different user interfaces tuned to match different
hardware assemblies. The Software Engineering
Institute calls this topic "Software Product Lines";
the GUI must also address it with skins. Tests must
cover all skins and flavors when any of them change.

While we know that we must always find ways to improve
external appearances and responses, we must also
appease our stakeholders that our applications, in all
their aspects, have appearances and responses that
closely match requirements and expectations. If your
integration tests capture screen shots of all your
windows with all their skins, you can upload these to
a Web site for easy cross-reference.



=====
Phlip
   http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces



__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

Phlip wrote:

> I always just relied on the "doesn't suck" principle
> myself...

Who says it 'doesn't suck'?

Adam

Jeff,

An effective way around this problem is to draft a navigation architecture
(screen flow) in advance based on provisional understanding of user roles
and tasks in the application. This architecture gives a reasonably well
thought out framework on which to hang the features and functions as they
arise "organically." The navigation architecture is itself reviewed and
refactored as needed as the details of the application emerge. This approach
is what I describe as "architecture-first development" in the new Cutter
Report on agility and usability. It's proven to be a good compromise that
yields maximal payoff in maintaining a sound UI organization with bare
minimal upfront investment.

--Larry Constantine
   Chief Scientist | Constantine & Lockwood, Ltd.


-----Original Message-----
From: Jeff Grigg [mailto:jeffgrigg@...]
Sent: Tuesday, 13 July 2004 7:48 PM
To: agile-usability@yahoogroups.com
Subject: [agile-usability] incremental design -vs- overall user experience

I can't claim to be an expert on user interface design or agile
methods, but here's a thought that's been bothering me for a while:

It's been my experience that systems that "grow organically" over
time often have bad user interfaces.  New features are often buried
deep within the existing user interface structure, making it hard to
find.  New reports, for example, are added as buttons or menu
options deep in the work flow, where they're first needed, but *not*
made available from higher level menus.

I've found that drawing screen flow diagrams of the overall system
illustrates these problems and guides redesign of the GUI to make
the system more usable.

But...
How can one avoid this problem in "organically growing" systems?

Does the "overall user experience" need to be planned up-front, even
when functionality is implemented incrementally?

As project direction changes during implementation, what triggers
you to recognize that the user interface flow needs to be redesigned
to most effectively support the new business requirements you've
discovered?






Yahoo! Groups Links

On Tuesday, July 13, 2004, at 8:48:03 PM, Jeff Grigg wrote:

> How can one avoid this problem in "organically growing" systems?

> Does the "overall user experience" need to be planned up-front, even
> when functionality is implemented incrementally?

I know some HI people who want to say so ... but if it can be done quickly
enough, maybe we don't care.

> As project direction changes during implementation, what triggers
> you to recognize that the user interface flow needs to be redesigned
> to most effectively support the new business requirements you've
> discovered?

In what "percentage" of programs is direction change the primary cause of
low interface quality?

> It's been my experience that systems that "grow organically" over
> time often have bad user interfaces.  New features are often buried
> deep within the existing user interface structure, making it hard to
> find.  New reports, for example, are added as buttons or menu
> options deep in the work flow, where they're first needed, but *not*
> made available from higher level menus.

Why is this done? What relationship between customers, users, and
developers obtains when this is done?

Ron Jeffries
www.XProgramming.com
The Great and Powerful Oz has spoken.

> Does the "overall user experience" need to be planned up-front, even
> when functionality is implemented incrementally?

An application needs a UI metaphor as much as it needs a system
metaphor, if it is to successfully grow incrementally.

Take a look at Microsoft Word.  It's 20 years old, but the original
looks not all that different from the one you buy today.  Lots of
incremental features have been added since then, but the central UI
metaphor remains.

Or look at a graphical web browser.  The central elements of this are
essentially unchanged from early versions of NCSA Mosaic.  Blue
underlined text indicates a hyperlink.  There's a "back" button that
takes you to a previous page.  There's a "Bookmarks" menu where you can
save links to your favorite pages.  There's a history feature
(originally a menu, now sometimes a list).  And there are forms with
fields you fill out and then click "Submit".  We've added things like
JavaScript, Java applets, Dynamic HTML, and Cascading Style Sheets, but
the central UI metaphor remains unchanged.

John Brewer

Extreme Programming FAQ: http://www.jera.com/techinfo/xpfaq.html

Hi Jeff,

> It's been my experience that systems that "grow organically"
> over time often have bad user interfaces.  New features are
> often buried deep within the existing user interface
> structure, making it hard to find.  New reports, for example,
> are added as buttons or menu options deep in the work flow,
> where they're first needed, but *not* made available from
> higher level menus.

I (just some guy with no user experience expertise) suspect that
such things can happen only if the team doesn't revisit the user
experience often.  What would happen if, as part of the
conversation about every new feature, the team made a point to
explicitly talk about how the feature will fit into the user's
experience?

XP puts a gives a lot of explicit attention to simplicity from
the developer's point of view, refactoring often to maintain
simplicity.  What if the team had an analogous practice that
attended strongly and explicitly to simplicity from the user's
point of view (refactoring often to maintain simplicity)?

Dale

--
Dale Emery, Consultant
Leadership Skills for Software People
Web:    http://www.dhemery.com
Weblog: http://www.dhemery.com/cwd

I love wisdom more than wisdom loves me. --Lord Byron

I can't claim to be an expert on user interface design or agile
methods, but here's a thought that's been bothering me for a while:

It's been my experience that systems that "grow organically" over
time often have bad user interfaces.  New features are often buried
deep within the existing user interface structure, making it hard to
find.  New reports, for example, are added as buttons or menu
options deep in the work flow, where they're first needed, but *not*
made available from higher level menus.

I've found that drawing screen flow diagrams of the overall system
illustrates these problems and guides redesign of the GUI to make
the system more usable.

But...
How can one avoid this problem in "organically growing" systems?

Does the "overall user experience" need to be planned up-front, even
when functionality is implemented incrementally?

As project direction changes during implementation, what triggers
you to recognize that the user interface flow needs to be redesigned
to most effectively support the new business requirements you've
discovered?

--- In agile-usability@yahoogroups.com, "Jeff Patton" <jpatton@a...>
wrote:
> I want to thank everyone for very quickly signing up for this
> group.  I'm seeing a really great mix of participants with
> varying degrees of experience in both usability and agile
> development.

Hi Jeff. Thanks for organising this.

I may be more of a lurker, but am very interested. I am a ScrumMaster,
and find that a "self organising team" dominated by programmers can
forget about the user experience. I am wondering where, in the cycle
of Scrum, usability design fits in. I suspect there are various
answers to this, depending on the scope of the work being done...

I'll be watching. :-)
deb

--- In agile-usability@yahoogroups.com, "Jeff Patton" <jpatton@a...>
wrote:
> --- In agile-usability@yahoogroups.com, Phlip <phlipcpp@y...> wrote:
> > What kind of credentials do usability experts need?
>
> As always, the answer is "it depends."
>
> I lump usability people into three groups:
> 1. up-front people: those who work at pre-development/pre-product
> stage to determine what software is appropriate to build
> 2. design people: knowing what the software should do, how exactly
> does it do it?  Both appearance and user interaction
> 3. design validation or test people: given a piece of software
> functionality, exactly how usable is it?  What adjustments could be
> made to make it more usable?

Well, it sort of depends how you're lumping together.  Within
Landmark, when most people say "usability" they tend to lump together
  the 2 human factors folks (who have a degree in human factors), the
interaction designer (me), the domain experts (about 12), and the
documentation folks as usability due to the way the group was
originally formed (even though the group has now been disbanded and
dispersed.

Jeff's general lumping of up front folks, designers, and design
validation/testing is the most common lumping that I've seen in terms
of skill sets, interests, and activities.  I most often see the first
and last group lumped together also.

I'd expand on the up-front description a bit to include to include
conducting ethnographic research which goes into the determining what
to build.

And, as Jeff pointed out, everyone has a slightly different focus.  I
prefer to fall on the design and upfront parts, but I also do the
design validation and testing side too.

>
> > I always just relied on the "doesn't suck" principle
> > myself...
>

Perceptions of what "doesn't suck" does vary dramatically though.  For
example, I work with a developer whose perception of "doesn't suck"
means that *he* can use the software well enough to exercise the
necessary functionality.  Luckily, the perception of the dev lead is a
little different, so I get her to tell him that an interface needs to
be changed and he needs to listen to me.


>
> I think others on the list could better say what proficiencies a
> usability person should have.

I think that an important proficiency is the ability to be flexible
and adapt to the current situation.  Doesn't mean cave in and just
rubber stamp things, but understanding how to adapt, when to push, and
when not to push.

Ron

Jeff,

I want to thank you for inviting me.

Looking through the membership I see that quite a few people know me,
and mostly for my recent work on Agile Management. However, I was the
UI Architect on the original FDD project in Singapore and personally
designed 450 of the 600 screens in the GUI for that system.

I've recently been asked a few times to write more about agile UI
design and usability and I do have some stuff to share which reflects
work which I did between 1997 and 2000 before I was press ganged into
the management at Sprintpcs.com ;-)

I am overdue to post some web log entries at uidesign.net with that
material.

I'm happy to be here. Pleased that agile usability is getting
attention and I look forward to fruitful discussions on this list.

Cheers

David

--- In agile-usability@yahoogroups.com, "Jeff Patton" <jpatton@a...>
wrote:
> I want to thank everyone for very quickly signing up for this
> group.  I'm seeing a really great mix of participants with
> varying degrees of experience in both usability and agile
> development.
>

--- In agile-usability@yahoogroups.com, Phlip <phlipcpp@y...> wrote:
> What kind of credentials do usability experts need?

As always, the answer is "it depends."

I lump usability people into three groups:
1. up-front people: those who work at pre-development/pre-product
stage to determine what software is appropriate to build
2. design people: knowing what the software should do, how exactly
does it do it?  Both appearance and user interaction
3. design validation or test people: given a piece of software
functionality, exactly how usable is it?  What adjustments could be
made to make it more usable?

Like developers, there are usability generalists who do all those
things well, and specialists who focus hard on doing a particular
thing well.  Among usability people there are many different points
of view on how any of those activities are done.

What best credentials are depends on where you perceive risk to be
in your project.  Are customers unsure what to do?  Are they sure
what it should do, but hazy on exactly how?  Do you have a product
that does what it should, but does it poorly?

>
> I always just relied on the "doesn't suck" principle
> myself...

Me too - sort of.  If the piece of functionality is used by one
proficient person infrequently, I let it suck.  If it's used by
hundreds of inexperienced people very frequently, sucking might get
expensive.  Especially if you have to pay to frequently train this
people, and provide help desk support for them.  Since sucking can
get very expensive in that situation, an expert in making it not
suck can pay big dividends to a customer concerned with ROI.

I think others on the list could better say what proficiencies a
usability person should have.

Also, usability people, if you have other points of view than mine
on the 3 classes - I'd like to hear them.

-Jeff





>
>
>
> =====
> Phlip
>
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfac
es
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail is new and improved - Check it out!
> http://promotions.yahoo.com/new_mail

Jeff Patton wrote:

> varying degrees of experience in both usability...

What kind of credentials do usability experts need?

I always just relied on the "doesn't suck" principle
myself...



=====
Phlip
   http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces



__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

I want to thank everyone for very quickly signing up for this
group.  I'm seeing a really great mix of participants with
varying degrees of experience in both usability and agile
development.

Looking over the members, I know there are frustrated usability
people signed up who've recently found themselves in an agile
development environment, and now have to rethink the way they work.
And, I know there are usability people out there who were in the
same place a year or two ago and have now figured out how to adapt
and perform effectively in those environments.  So, if you're in
the former group, and have some current frustration: post a
question.  You'll likely get good advice.

I know there are folks very strong in software development, and very
strong in agile development specifically, signed up.  I think
they've seen projects succeed without specific involvement of
someone specializing in usability and may question its necessity.  I
also suspect they've seen situations where projects have fallen
into a thrashing cycle, projects where requirements seem to arrive
late and from nowhere, and projects that look good at delivery time,
but are less than warmly received by end users.  I think the
usability folks on the list may have some explanation for some of
those symptoms.

I know there are strong usability folks out there who may have not
yet worked in an agile development team.  You might have questions
on why you'd want to, and how this might change the way you
practice.

I'm hoping that in the paragraphs above that I've described
someone and given them an idea for a question to ask.  If I did and
it's you, ask.

And, while I'm addressing such a strong list of diverse smart
people, I'm likely to start pelting you with my own self-serving
questions.

One procedural note: I'm moderating posts to this list for folks
that I haven't run across before – so some posts may take a
few minutes to show up.  I really want to keep the list free of the
annoying advertising stuff I've seen kill other lists.  If anyone
wants to help moderate, please let me know – the more moderators
the better.

Thanks again everyone for showing up.

-Jeff Patton