Earlier today, I was reading a discussion in the LinkedIn User Experience Group about User Experience design and how it fits in with an Agile Process. It was an interesting conversation, so I'm making a note of it here to make sure it doesn't fall off my radar.

Read the discussion in full

The main thrust of the conversation centered around the amount of up-front work should go into UX design. There were opinions all over the place. Some people said that you need to have the design as close to being finished as possible before code is written, others thought design could go more hand-in-hand with an Agile development process. For the most part though, most people believed that some up-front work was necessary. It's common sense, but I found it a little difficult to articulate where the line was. What are the right things to focus on in the initial planning phase and what can wait until you're in the process of rapid iterations?

I thought about it for a while and started to see a distinction that made sense. There are some design activities that are of the most value before you start, and some that actually work much better deeper in the process.

The goal of the up-front design work and research is to know what you *think* you're about to build. The trick with agile is, you let go of the assumption that you can *know* exactly what is required. By having a strong core concept and iterating outward, the important stuff reveals itself and the cruft falls aside.

However, the up front work to get to those core assumptions can be significant, especially when you're building something that will be used by someone other than yourself or people you closely identify with.

Jeff Patton makes some good points about why this is in the first part of this post.
http://agileproductdesign.com/blog/emerging_best_agile_ux_practice.html

I can't find a concise quote so I'm paraphrasing (read the post, it's good, albeit a little long). Agile development came out of internal projects where someone was "scratching their own itch" and solving their own problems. When you're solving someone else's problems, you need to understand them sufficiently enough to make assumptions about their needs.

That's where the value in the up-front planning is. Knowing the pain points, understanding the context the product will live in. Getting the UI and interaction design right is something that can be dialed in on later in the process.

That's been my experience, as I stumble through trying to design in an Agile development culture. So far it's been working pretty well.