Lean UX and Agile Development: Not So Different After All

I hope everyone is enjoying the New Year so far. Our winter wonderland here in New England is underway -- the seasons seem to move quickly and although winter has its finer points… the warmer weather will be welcomed when it arrives.

The last couple of months have been spent leading a UX design effort on a rather interesting project. The project was developed using an Agile / Lean UX methodology (which was good) and on an insanely tight timeframe (which was not so good). We’re rather pleased with the end result, and the project has given me blog musings for months to come. For instance….

Software engineers tend to be an arrogant bunch. Since I’ve been doing that particular job for 20-ish years, that comment totally comes from the “takes one to know one” drawer. Writing production quality software is hard job, with a high cognitive load on those in the field, and to rise to the rank of Alpha Geek requires being able to quickly solve esoteric problems using often obscure bits of knowledge. The problems are also generally technical in nature, rather than “people based,” so sometimes those personal interactions can be a bit rough.

Now, the point of working in an Agile methodology is to do “just enough” design work up front to get other people on the project moving along. From the UX perspective, this means figuring out the big picture of the system during the very early phases of a project, followed be enough detailed design work to get the developers going. It saves the UX team the time of creating a big thick design spec at the start (which in all likelihood will never be read in detail anyway), but it also means there is higher uncertainty at times because not every screen has been designed already. Software developers don’t like uncertainty.

At the kick-off meeting for this project, we laid out the schedule for the duration of the project, with the UX team working one “sprint” ahead of the development team to define screens and produce the required graphical assets. During the meeting, the lead developer looks at me and asks, “Can you can guarantee me that all the design work will be done and the assets will be created so we won’t be blocked on delivering features?” I replied, “No. But if we do, can you guarantee that the software will all be done on time and bug free?” This lead to a surprised look and an indignant lecture on why unforeseen technical problems can cause schedule slippage. I was amused.

But guess what? Unforeseen design problems can cause delays, too! Things like the client changing or adding the stake holders, or not agreeing quickly on an overall visual style, or particular areas just plain taking longer to design properly than was first thought; these are just a few of the things that can lead to delays from a design team. They are different issues than a development team may face, but the end result is the same: an unhappy client.

The primary goal of a good software development team is to deliver quality software, on time and on budget. One of the many goals of good UX team is to deliver a quality, implementable design to the development team, also on time and on budget. We all have to remember that doesn’t matter how awesome, cool looking, easy to use, etc., the design is if it can’t be implemented because of time or technical reasons. In reality, the distinction between UX and development teams is much less important than the one between “our team” and “the client.” Rather than arguing about who has the harder job, accept that each role has its own set of distinct challenges. When it all clicks, the synergy of developers and designers leads to what we all want: satisfied users and happy clients.