RE: [agile-usability] Re: plugging the big picture hole
From: William Pietri [mailto:william@...]>
> On another point, I think your example illustrates the difficulty with
> keeping the "whole product" concept coherent when your only
> representation is story cards and UIs. If you don't have a physical
> artifact to check, it's easy to overlook connections across the parts.
Well, I think it's an intrinsically difficult problem, no matter what
representations you use, especially given that any single representation
necessarily discards a great deal of information.Absolutely, and you're giving us a success case here... I'm not saying we could have done better, only playing with the issues.Personally, I like
something as obviously inadequate as the cards. With a 200-page spec,
people often yield responsibility to the spec. With a stack of index
cards, it's clear who has the answers: the team.
But perhaps I'm using the wrong representations. Let me give you the
full details and you can suggest a representation that would have found
the problem sooner and at a lower cost.
The feature in question was a very simple content management system that
controlled the pages of static content on our site. E.g., who we are,
what we do, the FAQ, our terms and conditions, and so on. It was
scheduled not for the upcoming release, but the one after that.
While we were implementing one of the stories related to payment, a
programmer noticed that we needed more explanatory text on one of the
UIs to convey the full terms. But it was really more text than would
fit, and the best thing to do was to give a short message to satisfy
most users, and link to the terms and conditions for the few that wanted
The static content story, though, was scheduled in the following
release. So we, as a group, spent perhaps ten minutes talking over
alternatives. Eventually, we split the story in two, putting the
necessary part of it in this release and the fancier features in the
next.Total cost of this change was perhaps one person-hour of discussion, and
perhaps two minutes updating our artifact. The HTML mockups were
ignored; they're only kept fresh when the designer is thinking hard
about the future or when they're the best way to communicate the details
of a feature we're building that week.
What representation would have you used to detect this scheduling error
sooner, and at lower cost?Our approach to this is through what we call a software floorplan or User Environment design. It shows all user-visible features and how they are arranged into coherent screens/windows/pages. When we're planning releases (haven't used this in an agile project) we do cuts across the floor plan and run a discussion of whether the cuts are coherent--each delivers complete, useful function and can be delivered independently. So in theory, running such a process would have identified the problem.In practice, such a discussion takes a good deal more than an hour. Besides, this was an additional need discovered during implementation--we might have found it up front, but might not.What I'm wondering about is whether maintaining such a "floorplan" could be useful for keeping design coherence on the user experience side. So in your case, you would have walked to the floorplan on the wall, which might have been marked in colors to show what was being delivered in this release and the next. You'd make your decision, and draw a box to represent your detailed terms box, in the color for this release. If any other user-visible features were affected by moving the static content work into this release, you'd change the color on those. Then you'd split the story and be done.Benefit is that the next person who's looking at what's happening in this release--maybe another team member discovers another change that depends on some static content work--only has to go glance at the plan to see what you've done.Does that seem potentially useful?Hugh
- --- In email@example.com, "Ron Vutpakdi"
> On the other hand, the core problem wasn't one of which development
> process was used during the implementation. The core problem was
> of poor management. I still believe that the toughest part ofhaving
> a successful project isn't the design (internal or interaction), itcompany,
> isn't the development, and it isn't the testing: it's the human
> element of working with each other, management, others in the
> customers, and users.this jives with my experience as well -- cheers, Cecilia