October 30, 2009 I attended Agilepalooza in Natick MA. The event was hosted by VersionOne. This was an openspace event, so the participant created and hosted the agenda. I wanted to talk about UX stuff so I proposed a talk "Visual Artifacts for Agile Teams." Here are my notes from the talk.

To start the talk, we did a silent brainstorm and collected topics for our backlog. I wrote out two posters that said "What is Working?" and "What are our Challenges?" to collect our comments. After that, the talk was fairly free form. As we ran down on a topic, we went to the backlog to see what else we wanted to talk about.

What are our Challenges?

The group identified a lot of challenges related to keeping everyone informed about the evolving product UI

1. Changes to mockup not communicated to QA, who test the wrong behavior
2. Marketing says "change this" to one developer, how does rest of team know?
3. Team decides to change product, how do you estimate impact of UI changes?
4. Going to code too soon. Failing to visualze and validate the user experience. 

What's Working?

Visual artifacts help keep the team focused on a shared product concept.

two kinds of visual artifacts
Product mandate: mission, scope, dependencies, agreements
Product look and behavior: sketches, storyboards, scenarios, user models

Integrate UX person into scrum team, attend standups, work with developers (50%-%100 works)
Get lightweight. Draw over printouts of existing visual design, rather than modify the source
When showing design concepts to people, don't ask "do you like it?" ask them to perform tasks so you understand what they can do and can't do.
Different artifacts for envision and construction phases of projects.

High res, Low res

We also got into a good discussion about the uses of low res and high res sketches and prototypes

Use of low res or high res depends on what you're trying to do. You can use high res during envisioning to help people imagine what it could be like, you can also use low res during envisioning to encourage people to participate in co-design.

Low res
More sketchy, observer can project/imagine
Easier to show to subject mater experts who can imagine what could be happening
Harder to show to managers and end users
Can be technology agnostic.

Hi res
Can be specific about look, information and behavior
More real, observer is responding
Easier to show to managers and end users who aren't good at imagining interactivity
If using for construction, you need to understand/take into account the technology platform so as to not waste effort creating things you can't build

Team Activities

At the end of our talk, we discussed some techniques you can use with your team to co-create visual artifacts and do visual problem solving

Design studio

Product box

We also talked about how scenarios can relate to user stories. In the early phases, a scenario can be a single story "buy house" later on, the scenario grows more specific and contains many user stories that define more specific activities.

It's good to have larger scenarios in your backlog before you break them down as they act as a placeholder you can keep in the back of your mind while you work on other things.

There are some photos of the event on flickr too.

Tom Scott posts that Dave Thomas proposes an “envisioning” and “definition” phase to be added to the front of the Agile “development”  and “release” cycles. Thomas assumes that developers perform all roles, and there’s still no place for documentation that isn’t code, but this doesn’t seem that far off from what Alan is proposing. There’s even this quote, that sounds rather like Alan’s recent presentation “The Envisioning Team provides a clear definition of what needs to be built; the Definition team designs how to build it.”

Interesting.

There's another post that references Dave Thomas here and opens the larger question about how to do Scrum with larger teams.

"Using Agile methods with large teams is a reality - the old Agile = Small Team equation is no longer valid. Nonetheless, team size is still an issue. How important is team size and what, if anything, should we do about it?"

The development community hasn't come up with an answer to this problem yet, perhaps the IxD community can step up and help?

At the IxDA Interaction '08 event in Savannah, I heard many stories about how interaction designers are taking stakeholders out on customer site visits, doing collaborative synthesis, working through design problems with developers. Why? Business stakeholders and developers don't have the same skill set or motivations as interaction designers, but there's something about using our methods to work through problems together that helps everyone be on the same page. They don't have to learn to be interaction designers to benefit from the techniques we use.

Interaction design provides great solutions, but it also is necessary to facilitate those solutions into the organization. I don't believe that the people who provide those solutions should be the "boss," they have to be the guide, leading people to the right place. Just as we can't justify our design decisions "because we think so" we also can't own the design, it has to be a owned by everyone who contributes to solution we're building. Interaction designers must use our skills to identify the problem, find a workable solution and get it all into peoples' heads before anything will happen. We have to engage and inspire the organization to get something good built.

In this spirit, I like the idea of figuring out how IxDs can collaborate more with developers because it helps create better understanding of the design and sense of ownership. Now, exactly what "collaborative design" means and where it fits in the process is open for debate, but I feel there's something in there that could work. The "big design doc" approach is problematic for many companies, and I'm thinking about ways we could do it better. It worked well in a recent project where the document followed the design, rather than the other way 'round. I think we could use more collaboration time with the development team on most of our projects, starting as early as the framework. I think there's great value in communicating more about the problems our framework is trying to solve, and leaving some of the implementation details up for healthy discussion. I think we could meet with different stakeholder groups separately to address different concerns, as well as together to build mindshare.

So...I guess at the root I see this as a design communication problem. How do we get developers to understand and believe in our designs so things are built properly? Part of the solution may be to facilitate them into it, rather than dictate to them.