design and agile

New methods for managing people making Web sites are big these days, with the most popular being Agile. Basically it boils down to making a small team of builders completely responsible for a project, and enforcing constant communication as people work on it in well-defined chunks. There are many engineer/programmer proponents for this, but few designers seem to have adopted the approach (though there some, but others are skeptical or downright hostile to it).

The difference is another example of Aristotle vs. Plato, the scientific, evolutionary approach vs. the aspirational large vision. Design wants to create a beautiful vision up-front for what a new world would be, but divorced from the deeper and more meaningful design that engineers do.

Without going into the problems and tensions that have been common in these projects, I think it’s safe to say that no one has developed a great ‘best practice’ for how it can actually work (and I’ve worked within dozens of Agile teams and read quite a bit about it, so anyone who claims to have it solved I can say is probably pulling your leg). So what could work better, at least?

Just Start

Often there is the assumption that designers need time to develop separate deliverables and have their ideas specified out before they can talk to builders. This is a breeding-ground for mistrust, and more importantly the designers shouldn’t be working without an intimate knowledge of the technical design–what information is gathered, how it moves around, and what’s done to it. Designers should get into the project at the very start, talk through the project in detail with the whole team, and make decisions with the team. They should be making sketches or prototypes the first day.

Visual and Interaction Design Comes Last

Many sprints I’ve worked on have tried to have design done a sprint ahead of implementation, or a week, etc. This is sadistic. When engineers are iterating and improving as they go but designers get one shot at it before they’ve seen any working code, everyone is set up to fail. Rough interaction design and pages should be done collaboratively with engineers as they work, and detailed interaction design and visual design should come last, as a refinement of that.

Actual Alignment

Much of the attempts at collaboration between designers and engineers in Agile projects have put the designer in a rough spot, between the product owner and their team. The designer makes mocks/comps/boards to should how the thing could look, and the product person signs off on that before the sprint starts. The documents for what will be built, however (e.g. the stories, acceptance criteria, etc.), doesn’t include the designs. Inevitably, the team makes changes to the designs as they implement, and the designer is either out of the loop (working on a different part, or not part of the team), or has to redesign on the fly in mid-sprint. Designers and engineers should put aside time for ‘alignment’ tasks, where they discuss and agree on what they will build, either as part of the pre-sprint tasks or the sprint itself. This is similar to ‘engineering-only’ sprints, which focus on the ‘plumbing’ of a project and not what users see.

The alternative to having these kinds of deep integration of designers into Agile teams, I believe, is mediocre work, or a lot of additional work to fix the inevitable breakdowns that happen when talented people work together. This is actually much more simple human nature stuff that’s been going on in offices everywhere, for a long time, probably since cave-people first called a meeting.

Post a Comment

Your email is never shared. Required fields are marked *