A few days ago, one of my Twitter buddies asked me to explain how the UI designers fit in on an agile team. I have some experience working with dedicated design teams and user experience folks so I thought I'd take a stab at his question and share my perspective. Once I finished my note it seemed like it might make a good blog post. I'd be interested to hear what you guys think about my answer.

Here goes...

Just to set a little context... my friend asked me to explain the role of the UI designer on an agile team. He explained that they were creating user stories but were not sure how to incorporate the UI designers into the process.

The unfortunate thing about explaining agile is that there is no one right way of doing things. There are principles that I like to see teams apply. Agile is all about creating situationally specific strategies. You just take the principles of agile and apply them the best you can given your constraints.

That said.. my friend seemed to be on the right track. They were creating stories with using a typical agile patterns... "As a user, I want to be able to create a new account, so that I can do X". The principle that I encouraged him to apply is that the story is small enough to be done in a single sprint, all disciplines are involved in implementing the feature (including the UI guys) and at the end of the sprint, it is potentially shippable... in other words, done.

What would that ideal look like in real life? During the sprint planning meeting, the team would collaborate around a whiteboard on what it means to be able to create a new account. The developer might talk about what methods might need to be created. The QA engineer would discuss how it would be tested. The UI designer would be involved helping the team understand what the screen would look like. The product owner would weigh in on the business value and keep the implementation discussions in check.

At the end of the discussion everyone is on the same page about how the feature will be built. Since everyone is on the same page, the UI person can go off and start iteratively working on a mockup (if necessary), the developer goes off and does code, maybe the QA person goes off and starts test planning. If the team is pushing new code up every day, continuous integration in other words, everyone gets to see the evolving product and respond to it.

Just like the code evolves, the doc evolves, the plan evolves, the product evolves.

The typical response from dedicated designers and QA people is that they want to be able to do the work once and for all. Operating in this way feels like waste. I encouraged my friend to keep in mind agile principles like barely sufficient documentation, simplicity of design, deferring decisions to the last responsible moment, and constant refactoring... The key is to keep the focus on working product and off comprehensive documentation.

Just like the dev team will refactor often, the supporting team members may have to refactor as well.

But what if everyone is not in the same room, on the same team, maybe not even in the same company (external customer)? You apply the same principles and adapt them to your environment. I have seen teams do just enough UI design in the previous sprint to keep the dev team moving in the subsequent sprint.... This makes things more complicated and creates more dependencies than an pure agile approach.

When teams take this approach, I liken it to the product owner grooming the backlog and specifying requirements in advance. The UI mockup becomes like a requirement to the dev team.

As a team you just have to decide how much time and energy you want to invest in up front design. You can do agile practices with an up front design, it just causes you to do even more rework if you want to change anything. It really depends on the uncertainty of your market. If things are prone to change, invest less up front. If things are stable, you can invest more.

Originally posted on Leading Agile