lanehalley

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.