UI Guidelines and Acceptance Testing
- 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
Here's our process in a nutshell:
1. We have a set of UI Guidelines that all screens are supposed to
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 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
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!
- I'm still in the early parts of the project, so a lot will certainly
change, but I'm planning to start by introducing some easy ideas on a
small scale, but on a project that is a "pain point" in terms of the UX.
That will, ideally, teach us about what works in this particular software
development culture while having the appropriate social and political
effects. In other words, whatever we do will have to have results that
are immediately useful to the development and produce results that are
observable by management.
In terms of techniques, I'll probably start with some lightweight
usability testing and persona development incorporated into the next
development cycle for a single team, but I don't know yet. As a company,
they've already done a little contextual research--going out to customers
and just seeing what it is that people do with their stuff--and that's
proven to be quite effective in communicating the value of user-centered
methods, so maybe we'll continue that.
Like I said, a lot will depend on the specific situation, and I'm only
just learning about the company culture.
On Mon, 9 Aug 2004, Jeff Patton wrote:
> --- In firstname.lastname@example.org, Mike Kuniavsky <mikek@o...>
> > I'm also starting a parallel project to
> > train and coach their teams in user-centered practices....
> Mike, while looking at your original post on UI guidelines, I noticed
> the above line. I'd really like to hear about the approach you're
> going with here. Are there specific techniques you'll teach? Are
> there specific artifacts - models, uses-cases, UI prototypes, etc..
> you'll expect the team to create? Will the work they do happen
> concurrently with development?
> Yahoo! Groups Sponsor
> click here
> Yahoo! Groups Links
> * To visit your group on the web, go to:
> * To unsubscribe from this group, send an email to:
> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.