Lately there has been a spate of articles cropping up about the fate of user-centered design (UCD) in today’s fast paced, iterative development landscape. Some people think traditional UCD methods such as testing, card sorts and user experience documentation (wireframes and site maps) is antiquated and unnecessary when developers can design something workable then engineer out glitches with regular releases. With the advent of rapid development (Agile), the growth of web application frameworks like Ruby on Rails, and the availability of ready-made widgets, “design” is now easy to do.
Who needs user experience when there is so much out there that a developer can string together?
Questions spring to mind- Does Agile mean there is no time for interaction design and usability? Does this signal the return of the developer designing the software? Or, as Alan Cooper might say, the inmates are running the asylum once again? Does Agile mean a developer can design and iterate until s/he gets it “right”?
Other questions need to be asked. Are users willing to endure several iterations until their needs are met?
What about the client?
The waterfall process cannot engineer out vagaries
I am not trying to be an apologist for the traditional waterfall method where each discipline lead does her job then passes it off to the next person in line until voila something is developed. This method certainly has its failings. There’s a lack of collaboration throughout the process and no clear responsibility for the end-to-end solution. It also prescribes a final design that resists iteration as it has already been documented and approved. Because of the prior (oftentimes signed) approval it’s difficult to deviate from the prescribed solution even when there’s real need. You’re basically out of luck if a developer, in the weeds, uncovers that a major feature is impossible or requires a hack that might not be optimal from a usability perspective.
The waterfall method tries to nail down user needs and project goals through careful documentation with reviews and sign-offs. Still, the issue remains- whatever initial documentation is created is often a shadow of what gets developed due to scope changes, indecision, or a shift in strategy.
So why not use a hybrid model? Use waterfall to set up a solid foundation and the use Agile methodologies to react to the inevitable issues.
Waterfall Model
Agile process and its discontents
Agile tends to break development into smaller discrete parts or features instead of the whole. Smaller is better for rapid development because you can isolate and test and iterate again without affecting the whole. The danger with this thinking is the fact that the whole is often ignored which can result in a less than cohesive user experience.
So what’s a user experience professional to do?
Can we get along?
The answer is yes, we can make it work by creating multi-discipline teams who work together on a solution instead of having each discipline “own” a piece a la the waterfall method. The team can offer suggestions and ideate solutions better than a discipline lead working in isolation. Once an approach is agreed upon the UX lead can rapidly storyboard or paper prototype the cohesive solution while identifying where the feature integration points happen. The Developer can start working on the discrete bits while having an idea of the complete picture but not being bogged down by the “whole.” The UX lead and developer will work in parallel as each discrete is being paper-prototyped and developed.
Agile Model
What the user experience professional needs to do
User experience professionals must be agile, too. User experience should do as many upfront tasks as necessary prior to diving into the agile process. This means any user research and analysis (card sorts, expert reviews, etc.) needed to inform a design solution should be done prior to development. And, once a problem is defined, we need to decide which tool(s) should be used for the solution. We don’t need to use every tool in the UX toolbox but the right tool or mix of tools. So if discount usability testing with 5 users on paper-prototypes is the only thing the project has time for, then, great- we all know that any testing is better than no testing at all. Also the beauty of the Agile development process is that it likely won’t be perfect the first time but you’re by definition blessed with a second (and third, and fourth..) chance to improve upon the site or application.
Excellent post Judith.
I recommend the book “Subject to Change” by the bright folks at Adaptive Path for you and your readers with an interest in the union of agile and UCD.
There are a few of forward-thinking Agilists I know of who are nudging us toward user-experience and UCD (e.g., Jeff Patton’s User Mapping and incorporating user personas in our thinking about features…David Hussman and others). I summarize what I’ve learned at http://bit.ly/sIoLo.
Bob, I actually have the book you mentioned but I have yet to crack it open. Your comment has inspired me to pick it back up again as this is a subject that is timely for those in UX professsion.
Also, thanks for the link to your post, it has a lot of great information about weaving user needs into tangible stories that describe a user by her characteristics and values. User stories or personas tend to resonate more effectively than a series of outlined requirements. A designer, developer or member of the QA team can always refer to the user story to validate the design by asking how “Jane” would do something, etc.
UCD and agile must come together in order to improve seamless site updates with the least disruption to your customer. To achieve this, you must have a strong project lead that brings multi-discipline teams together and manages change effectively. It doesn’t hurt to have a strong vision and defined requirements before starting the project.
Kathy, I wholeheartedly agree with your comment about the need for strong leadership to keep the project in line and the team on message. If the leadership isn’t there then project and team loses focus and the end-product suffers. Likewise, any gains the Agile method can bring to the table will be lost too.