Agile development process and User Experience design

An interview with Charlie Kreitzberg of Cognetics Corporation discussing the Agile development process and User Experience design.

John: We are speaking with Charlie Kreitzberg of Cognetics Corporation (www.cognetics.com) about Agile Development and how user centered design and user experience methodologies fit best. Charlie, how do we integrate the usability techniques that we know and love into this new agile development process?

Charlie: My sense is that the fit between user experience design and agile development has not been as comfortable as one would hope. That’s surprising considering that Ux design and its components like interaction design and information architecture are essentially Agile processes themselves and are highly iterative. I am not sure why it has been so difficult for the Agile people and the usability people to get together.

One barrier may be cultural. I do not think that user experience thinking has quite penetrated the development community yet although that is changing very rapidly. But developers tend to focus on functionality and maintainability and while they acknowledge the importance of user experience they’re not necessarily comfortable with it

John: Why do you think that is?

Charlie: Certainly the developer’s view of a software product is very different from the experience of end users. As a result developers may not see some user experience issues as important. And Ux is concerned with engagement and relationships. Many developers are not particularly social and so their interest in experience issues is less than Ux designers who enjoy it. And in terms of process, there is a tendency to view the UI as the last thing to focus on. I think that has been a significant error. I believe that user experience, design and wire framing and coming up with a very clear concept are essential at the very beginning. But not everyone in the development community agrees.

John: So it’s a culture-clash issue?

Charlie: Partly. Another reason has to do with timing. The nature of Agile is that you typically go through quick design iterations and make a lot of decisions on the fly. That’s also true for Ux design. But in both cases you need to start the iterative process by developing a clear vision of the foundation and architecture you will be using. Without a good foundation in place, you run the risk of creating a patchwork quilt where you meant to have a integrated whole.

In agile development there is often an “iteration zero” which is used to setup the tools and environment. Perhaps what we need is a Ux iteration zero. But I think the problem may actually be deeper than that.

Some people embrace an extreme form of agile that is built around just in time decision-making. I think that some design elements need to be thought about holistically. Others can be designed as needed. If you don’t get that right, it’s easy for the UX designer and the developer to step on each others toes or to make architectural decisions that may not be exactly the right ones. My advocacy here is that you need to inject a little bit of waterfall mentality through a design stage during which the high-level design for the UI is thought through. Use this opportunity to bring the design to a point where at least the basic architecture of the presentation layer is understood. Get a sense of the navigation, the high-level functionality, how the information architecture will be managed. Then use this model to engage in the Agile process and refine the user interface iteratively.

John: You noted that sometimes the Ux designer and the developer can step on each other’s toes.

Charlie: Generally, when I am in that kind of environment, I try to keep the user interface design one or two cycles ahead of the development rather than in lock-step. As a result, you are moving forward on the user experience side while the developers are actually building something that is a little bit further in the past.

John: Would you say that you have applied a kind of hybrid model to the Agile process?

Charlie: It’s not that I consider it hybrid but that think that there are initial conditions that are needed before you begin the iterations. And the context of almost every business-financed product I’ve encountered is sequential. Every one begins with a business case, setting up a team, planning, coding, testing and release. Some people might call that “waterfall” but I think that we need to remember that the context in which agile takes places tends to be built around sequential stages at a business level.

I think the flow also changes depending on where you are in the product’s lifecycle. When you are developing a brand new product, there are many stake holders who need to get clear about what is envisioned. But when you have an established product, and people really know where it is going, most change can be conceptualized in an incremental way.

But, in the early stages, it is important not to get on the wrong path and not to make some decisions about the user interface that later on do not work and force you to make changes you would prefer to avoid.

John: So you are thinking that the initial user centered design model should be input to the first iteration of Agile before coding begins.

Charlie: Yes, that is correct.

John: So are you making the analogy that when you are building a house, you need the architect to come up with a blueprint before the carpenter starts nailing up the walls?

Charlie: It’s a good, if well-worn, analogy. When you are building a house, you cannot decide to alter the footprint once the foundation has been poured. If you poured a slab you cannot later decide you want a basement. And if you designed a one-story ranch you cannot decide to make it a two-story house – at least not without a lot of work and investment.

On the other hand, there are a lot of decisions that you can defer for later. Non-supporting walls can be moved, you can change a lot of the interior spaces as long as the structural support is present. The trick is knowing which decisions can be deferred and which have long-term consequences. If you get the bearing walls right, you can always push the partition walls about. You can certainly change the colors; you can add a window or a door. But if you try to change something that is essentially structural you have a real problem. I think the same applies certainly to the user interface

I break requirements gathering into two phases. Initially I focus on the high-level conceptual design and functionality. The second phase is detailed design. Early on, in the envisioning process, I’ll think about functionality that may not be planned until later in the future. The reason is that I want to create a user interface that is extensible and architecturally can accommodate the evolution of the product over a long period of time.

John: So are you concerned about Agile becoming “cowboy coding” rather than responsible development?

Charlie: I wouldn’t equate Agile with cowboy code but there are some developers who may think that that is the way to go. The reality is that waterfall methods, while they appear logical and structured, often fail. The reason is that you can never completely specify everything upfront. What Agile offers us a way to make design decisions in a just-in-time fashion. And that works well as long as the decisions with long-term consequences are made correctly.

I believe a framework needs to be established upfront that lays out the basic structure of the user interface and is based on an understanding of task and activity flow.

John: Tell me about the LUCID framework you developed.

Charlie: LUCID is a framework for user experience design that I developed with some of my colleagues starting in the 1990’s. The name is an acronym for Logical User-Centered Interaction Design. We created it because we saw a need to help product developers structure the Ux components of a project.

When we conceptualized LUCID we attempted to blend both sequential and iterative elements. It was sequential at the highest level meaning that we went through a series of phases to get from the business case, through product envision, through prototyping, build and deployment. But LUCID is highly iterative in the design stages. Now what we didn’t do in the early versions of LUCID was to really look at the integration with development methodologies because what we found at that time was that in a highly waterfall world, a lot of the user experience work was ideally done before the development process even began.

LUCID became a very popular methodology surprisingly because we did not do much publication on it, but we did place it in the public domain and made it freely available to people. It started to work its way into university courses and occasional text books and at one point I actually encountered a research study which said that it had become the most popular proprietary methodology for design. That was really nice. I think a lot of that had to just with its pure simplicity.

What I am engaged in now, and this is just getting started, is starting on a new version of LUCID. One thing I would like to address in “LUCID 2” is the fit with Agile environments.

I am planning on building LUCID 2 in an open source collaborative environment. I hope we can engage developers, business analysts and usability specialists to work together and exchange ideas about how to work well together.

John: Okay. Well that is really great. We look forward to progress on LUCID 2 and hearing more about it. Thank you very much for agreeing to be a guest and being recorded for my blog. I appreciate it very much.

Charlie: Well, I am delighted to talk with you John, and I hope that if any of your readers are interested in getting engaged in the LUCID 2 project they’ll write me at charlie (at) cognetics (dot) com. I’d be happy to hear from them. There some more information about LUCID at http://www.cognetics.com/UserExperienceDesign/LUCIDFramework/tabid/178/Default.aspx. This is an unfunded effort but fortunately in our Web 2.0 world it’s easy to put a website together and to start the discussions going.

John: Well thank you and thank you for participating.