Re: [agile-usability] Re: Syncing developers and designers
- We've done something similar on several projects. The projects basically broke down into two categories which I'll describe separately.
Category A is the "Embedded Designer/BA":
We used this when we didn't have specialized UI Design people involved. The BA (business analyst) worked with the on site business people to come up with some paper prototypes or Visio mock ups of the screens to give everyone a common understanding of what the application was about. The business people then did "wizard of oz" testing of the paper prototypes with real users. We did this on two projects back to back with the same business users. The first was a .net project and the second was an SAP ABAP project! The business people found it so valuable on the first project (see http://agileusabilitypaper.gerardmeszaros.com/) that they did it without any prompting on the second project. The end users of both projects extolled the virtues of the applications to each other and anyone who would listen. Note that the SAP application ended up looking somewhat different from the paper prototype because of the details of SAP's UI widgets but didn't detract from the value we got out of the paper prototype.
Category B is the "Separate Design Team":
We used this on two different agile projects where an outside design consultancy was engaged to do the graphical design of the application. Initially we had a lot of trouble because the designs arrived too late and were difficult to implement. Over time we were able to move to a model that was very similar to what you are describing. The key practice was having agreement on what would be built over the next few iterations and focusing the UI designers on those parts. It really confused the users/testers when they were shown UI designs for functionality that wouldn't be built for months. This required doing "high level iteration planning" one or two iterations ahead. (But we've also found we needed to do that on some projects for consensus building amongst multiple stakeholders.)
We also tried to keep the visual design and the software somewhat independent by using CSS although this was easier said than done. But if enough agreement was reached on the page structure then the CSS could be evolved relatively independently.
Best wishes for your projects!
-- Gerard Meszaros Lean/Agile/Usability Coach Author of the Jolt Productivity Award winning book "xUnit Test Patterns - Refactoring Test Code". Learn more at http://xunitpatterns.com/index.html
Well, we're just starting out with it - two projects are in the
"designer headstart" phase now.
In conjunction with one of the designers, we're going to try doing
design in two passes: once the overall design concept is done, the
designers will produce enough of a toolkit to do basic pages. This is
essentially basic CSS and layouts which will be reused throughout the
site. That's enough to get features to "done done", since we can
release like that if we have to.
Later on, designers will iterate through the cooler UI stuff with us.
Still, this is mostly theoretical, which is why I'm trawling for
comments. It'd be nice not to have to learn it _all_ the hard way.
--- In agile-usability@ yahoogroups. com, "aacockburn" <acockburn@. ..>
> Nice, Gwyn!
> That's sort of the standard recommendation, but I've not seen it
> posted as a "we did this" form before, always as a "you might try
> Nice to hear of someone actually doing it.
> (And from your posting, I presume it is working out OK for you? You
> left that part out, but I'm guessing you wouldn't have posted it if
> it wasn't working out...)
> Are there any problem areas with this way of working that you'd warn
> others to look out for?
> thanks - Alistair
> --- In agile-usability@ yahoogroups. com, "gwynatdezyne" <mail@>
> > Hi -
> > We're using an XP approach to build web applications (using Ruby On
> > Rails). We have only coders, not graphics/UI guys, so we work with
> > of several design firms on each project. Their deliverables are
> > generally photoshop files of completed pages, which we turn into
> > XHTML+CSS and apply to our unstyled code-driven pages.
> > Probably due to the nature of their work, we've found design firms
> > tend to favour a top-heavy waterfall approach, using upfront design
> > and all-at-once delivery and signoff.
> > The best approach we've got so far is:
> > Before starting iterations:
> > 1) Do the user stories and release plan.
> > 2) Wireframe as little as possible, but as much as necessary for the
> > designers to get their heads around the scope of the site. Do a
> site map.
> > 3) Give the designers a "head start", potentially of a couple of
> > weeks, to build the overall look-and-feel of the site, sort out the
> > navigation, etc. Make sure at least one of our developers is at
> > design workshop.
> > In each iteration:
> > 1) Ideally, work alongside the designers, taking a single story from
> > "not started" to "completed and fully styled" in one iteration.
> > 2) Where that's not possible, create separate stories for "create
> > designs for feature X", "write code for feature X", and "apply
> > to code for feature X". Ideally these wouldn't be more than one
> > iteration apart, and the number of unstyled features would be
> > Is anyone in a similar situation?
> > Cheers,
> > Gwyn.
> > (crossposted, more-or-less, from the 'extremeprogramming ' group)