Over the summer, I had a chance to participate in several short projects with balanced teams.  These projects were in different product domains (entertainment,  e-commerce, social media), on different platforms (iPad, iPhone, Web), with different sized teams (3-7), but all of them had the following aspects in common:

• The project was run within an agile framework (focus on the customer, continuous delivery, team sat together, lightweight documentation, team ownership of decisions, shared rituals like stand-ups, retrospectives, etc.)
• The team contained people with a mix of skills (front and back end development, user experience and information architecture, product management and marketing, graphic design, copywriting)
• The people on the team generally performed in their area of expertise/strength, but were supportive of other specialties and interested in learning new skills.
• All the projects were early stage “green fields” projects where we were simultaneously trying to discover how it would be used, how it would look and behave and how we could build it.

My background is interaction design and product management, so I brought my toolkit of methods for problem definition, user research, modeling, storytelling, sketching and prototyping into the mix. Here are a few techniques that I found successful when working with balanced teams on projects like these.

Incorporate other team members’ ideas about the user experience

When I envision products, I think from the user’s perspective. What is a particular person’s objective, and what does the product show and do as they interact with it? The other people on my team have different, equally valid, perspectives of the system we’re building, for example data relationships or information architecture.

I found the most effective way to align our understanding was to ask other people to talk about (and sketch!) what was happening in the system and think about what the user would see along the way. I’d use that as a starting point for further conversation. When talking to developers, sometimes it was easier to start with a flow diagram and then build up from there. Once we built the model together, we could have productive conversations about the user interface because we all felt joint ownership and agreed on the experience we wanted to deliver.

Build shared physical artifacts

In my prior work as an agency interaction designer, I usually started by interviewing my client (one or more project stakeholders) to understand the business objectives. Then I did ethnographic interviews/contextual inquiry with users (or potential users) to understand their needs. Based on this understanding, I’d work solo, or with other designers to create scenarios, storyboards and/or prototypes, which would be validated with the stakeholders and sometimes the users.

When working with balanced teams, spending time away from the group advanced my understanding, but didn’t help the group develop a shared understanding of the product we were building. I found the most effective documents/artifacts I produced were the simple lightweight ones that encouraged conversation and participation. For example, quickly building a crude paper prototype the group could use to walk through a scenario to understand screen flows.

Create a shared vision of the product’s look and behavior

Before a product gains critical mass and has a visible framework, or many screens, it’s hard to work together in support of a shared goal. When just using story cards and conversation, I noticed teams spending a lot of time arguing about how things would work and what they would look like. I’ve seen teams spend a lot of time in debate about what stories should get built first and what could wait. There’s also tension around how long it will take to reach a minimum viable product (MVP) that people will use, love and depend on.

My observation is that these problems come from a lack of a shared vision about the product’s behavior and appearance. Most people find it difficult to imagine something they have not seen, especially if it involves complex interactions and state changes. It’s even harder to make sure that everyone in a team is holding the same complex interaction in their heads without making it real through detailed pictures or working software. There are people (and many of them are interaction designers) with a talent for imagining and communicating complex interactions. However, balanced teams don’t need a “rockstar designer” to hold the product vision and keep the team on track.  I found my role with balanced teams was to help the group envision, critique and agree on what we were building at a higher level than user stories.

Lead with conversation, trail with documentation

We were moving fast enough on these projects that my attempts to create a user interface specification or build a clickable prototype too early made me a bottleneck in the process. I realized that I didn’t want to create a well-crafted deliverable that I had to explain to other people, I wanted to make things with the team that advanced our understanding as a group.  I had better success when I started with conversation and group sketching and then built a lightweight paper prototype. We then validated the prototype as a group, and put it on the wall for annotations and additional detail created by the team. We continued to revise and extend the model over the next few days as we start to build out the product screens.

At this point, I was ready to translate the team’s decisions into documentation. I created a clickable prototype in Balsamiq to work start thinking about some positioning/screen layout issues and help further validate the product with people outside the team while we were building it.

Use personas and scenarios as back-story, not as deliverables

In my practice before I started working with balanced teams, I would often use personas and scenarios to help me understand the problem domain and frame the context of use while working through design concepts. I’ve found personas to be a very helpful method when working with other designers because they are useful shorthand for lots of information about people we’ve met. I find scenarios, by themselves, are a good tool for working with other people who are comfortable envisioning complex interactions, but they are less useful for people who need to see pictures to “get it.”

When working with balanced teams, I still often create personas and scenarios, but I do it in a more spontaneous way, when we reach a situation where they solve a problem we’re having.  If we’re having trouble figuring out what features matter, or what goes together, or how to present something, I’ll work with the team to create provisional personas that document our understanding of users, and then work towards validating those assumptions when we get a chance to talk to or show our product to actual people. I’ll create scenarios as a part of my own process for creating interaction designs, and then use it as part of the story I tell with through a sketch, paper prototype or more polished concept. “So, let me show you how Raj uses our product to do this…”

So, that was my summer vacation. From the buzz I’m seeing on #auxretreat and #agileux, it really feels like something cool is happening. We’re mixing things up and working in new ways for happier teams and better results. I’d be interested in hearing your stories. Are you working in a balanced team? What’s working for you?