I often encounter recommendations from evidently seasoned Scrum practitioners that UI design should be developed in sprints prior to development, or even generated in backlog grooming/sprint planning meetings outside of sprints. As a designer who’s been using Scrum since 2004, this continually baffles me; While these folks no doubt would argue that system architecture (high-level software design) can and should be done incrementally and iteratively in regular sprints along with the rest of the development work, they express the opposite opinion on UI design without any sense of irony. Evidently they see no contradiction in the paradoxical treatment of these conceptually nearly identical types of work. Why the special treatment for design?
Part of the problem no doubt lies in the historically difficult relationship between UI design and programming. In the old days, this relationship was fraught with all sorts of turf battles and smoke-blowing as designers and programmers fought tooth-and-nail for the limited time allotted between planning (design) and implementation (code) stages of predictive-process development. Designers struggled for design time while programmers chomped at the bit to start coding so they could meet their already insufficient management-dictated development schedules.
Maybe we designers made too much of the issue, and convinced the rest of the now agile development community that UI design really is special. But I doubt it. More likely is that design has been left in the dust as the other phases of waterfall went agile. Why? Likely because designers continue to dig in their heels, suspecting that agile is just the latest industry name for the age-old practice of chopping design time down to a nub. So designers resist, holding onto the idea that BDUF gets you the best design money can buy. But here’s one designer who’s not buying it, and here’s why.
Design – like architecture and testing – is simply work that needs to be done to construct a potentially shippable increment of product. And most of this work can happen during a sprint with everything else. There’s nothing terribly mystical about design, except maybe that it’s a human-facing concern rather than a machine-facing one, and meeting human needs is usually a lot more scary and unpredictable than meeting machine needs. Conceptually, though, UI design/information architecture is more or less equivalent to system software architecture: it’s just that one is concerned with grey-matter processors while the other is concerned with silicon-and-copper processors.
The agile (and lean) approach of delaying irreversible decisions until the last responsible moment works as well for UI design/information architecture as it can for system architecture. Likewise for prototyping and iterative review of proposals prior to those irreversible decisions. This approach is necessary for only a minority of UI tasks, though – usually the larger, Information Architecture-type ones; Otherwise, most UI can be designed and coded in the same sprint without the world coming apart. If it’s not right, then it gets iterated over in a later sprint as part of the normal process of rework.
Just as programmers need to get over the idea that rework is waste, so do designers. In fact, since nearly all design disciplines traditionally employ “crits” to inspect the suitability of proposed designs prior to the next rounds of refinement, I’d argue this concept is easier for designers to adopt than it is for programmers – provided, that is, there’s an environment of openness and trust between disciplines. Once you have that, and programmers and designers trust each other and respect each others’ contributions, then it’s dogs and cats living (and iterating) together.