Conference Review: IA Summit 2011: Part I

The Main Conference: More on Agile UX

During the main conference—which began on Friday, April 1st, and comprised three full days of sessions—there were two more excellent sessions on agile UX, which I’ll review here, carrying on the theme for this part of my IA Summit 2011 review.

Letting Go of Perfection: Developing an IA Agility

Presenters: Chris Farnum, Joanna Markel, and Serena Rosenhan

In this session, Chris, Joanna, and Serena, shown in Figure 11, shared their experiences in helping to define and implement an agile development process at ProQuest and their approach to working on an agile UX team. Participants from the workshop “Creating an Agile UX Manifesto” that had occurred the previous day were still hungry for information about practical applications of agile UX and attended this session in force.

After briefly describing their work at ProQuest and comparing traditional, waterfall development with agile development, as shown in Figure 12, the presenters led an agile development exercise: making a paper airplane. Figure 13 outlines the requirements for the exercise.

Its title notwithstanding, this session focused on their team’s strategies for coping with the need to initially deliver less fully formed designs in order to enable development to begin, without sacrificing quality and usability. Although they build “user experiences in layers, by delivering just enough, just in time,” their ultimate goal is to achieve great UX design. Doing this requires “[letting] go of old ideas of perfection, [rewriting] your value proposition, and [changing] how you think and work.”

In speaking about changing how you think, Joanna described the biggest challenge of agile UX: “You’ve lost your up-front design phase.” But the opportunities agile UX presents include:

• iterative design
• the “freedom to make mistakes earlier”
• early working prototypes for testing

How do you understand the difference between wants and needs? “Prioritize requirements,” continued Joanna. “Go back to your user personas and scenarios. What do users need to accomplish their goals? What’s the simplest thing that could work? Increment your way to perfection. Think just enough, just in time. Start simple. It’s okay to refactor your design.”

Chris spoke about changing how you work: “Put first things first.” To meet business requirements, progress from basic functions to enhancements to embellishments over time, as Figure 14 shows, rather than designing the ultimate solution for a specific requirement all at once.

“Good layering [of basic functions, enhancements, and embellishments] creates a fully functional system more quickly,” advised Chris. “Starting basic is also important at the next level of granularity.”

When you’re considering how to produce design deliverables like those shown in Figure 15, “Think lightweight,” continued Chris. “Communicating layered designs is very important. Deliverables should be quick to produce and easy to consume.” Some quotations Chris shared about creating design deliverables for agile projects, shown in Figure 16, demonstrate that figuring out the right amount of design documentation to create is a challenge.

Chris showed us an example of what Eric Reiss calls dirty deliverables—a site map comprising Post-it notes on butcher paper, shown in Figure 17. They’re considered dirty deliverables “not because they’re imprecise or lack detail, but because they can change,” said Chris.

Chris’s additional thoughts on creating lightweight design deliverables include the following:

• Keep user stories short and precise. Some agile teams define succinct, “bite-sized requirements” on note cards.
• Use a template to keep requirements consistent. At ProQuest, requirements “start with a user statement.”
• “Create annotated, low-fi, grayscale wireframes. Using a narrow column for notes helps to keep them brief.”
• “When modifying screens, try mashing up screenshots with drawings. Modify them and highlight what’s important.”
• “Don’t keep a master set of wireframes or specs documenting the current system.”

This presentation about the practice of agile UX concluded with these thoughts: “Do you really have to let go of perfection? Not really. Being agile is not about perfect deliverables; it’s about working toward a highly usable product. It’s a goal, not an end-state. It’s a lesson we’re all still learning.” For the full presentation, see Figure 18.

A lively Q&A followed the presentation. Here are some of the questions and answers:

• How do you incorporate UX into development? “We have cross-functional teams and sit with Development.”
• Do you do design reviews? “Yes, we do internal reviews within the UX team. We meet once or twice a week to review designs that are about ready to go into development.”
• Do you do a scrum of scrums with UX people? “We group senior and junior UX people together to keep style and conventions consistent.”
• How do you determine your audience and requirements? “We do up-front research to figure out the audience, then create personas and define requirements during a pre-planning phase—Sprint 0. We maintain a set of known requirements over multiple releases, and in each release, there are also newly defined requirements. Requirements go through a review cycle with business, during which we can provide feedback and inject our UX perspective.”
• Do you create style guides in advance? “Our language styles grow incrementally.”
• What is the role of a Product Owner on your product teams? “Product Owners are accountable for delivering products to the business. They’re also responsible for prioritizing bugs and signing off on showstoppers. We have a conversation about how bugs will impact users. We consider challenges and the level of readiness according to acceptance criteria we’ve defined. UX writes acceptance criteria for developers—what has to get developed—and Quality Assurance tests against our UX deliverables. Product Owners also review our wireframes.”

Lean IA: Getting Out of the Deliverables Business

Presenter: Jeff Gothelf

Inspired by agile development and lean startup approaches, Jeff Gothelf conceived of lean IA or lean UX—which he said “is about putting less emphasis on deliverables, not throwing them out.” Jeff, shown in Figure 19, is Director of User Experience at TheLadders.com, where he has put lean UX into practice. According to the description of this session in the program, the intent of this approach is to overcome the problem of stakeholders’ defining the value of IA or UX according to the quality of design deliverables rather than the success of designed user experiences. A noble intent.

While most of this presentation was great, it unfortunately started on an off note, with two false claims:

1. That “UX began with Information Architecture,” when, in fact, user experience predates information architecture, in the sense in which we use the term today, by several years—more than ten years if one counts Don Norman’s descriptive references to the user’s experience in his 1986 book User Centered System Design: New Perspectives on Human-Computer Interaction.
2. That “IA evolved and expanded into IxD and her sisters,” though Bill Moggridge and Bill Verplank coined the term interaction design in the late 1980s.

The need for lean UX exists because, while “traditionally, deliverables helped define the practice, … value has ultimately been placed on the deliverable, not on the experience being created,” argues Jeff. He defines lean IA or lean UX as follows: “It’s the practice of bringing the true nature of our work to light faster, with less emphasis on deliverables and greater focus on the actual experience being designed.” Figure 20 depicts the lean UX process for an in-house team.

“Sketch it out. Concept it. Prototype it. Get your work out there quickly. Get it out there raw,” recommends Jeff. “It is much easier to take critique on something you worked on for an hour than something you worked on for a month. Iterate quickly and often. Post your work where it can be seen. …

“Constant collaboration is where shared understanding comes from. What tool is the right tool to use now and at what depth? You’re doing just enough work at the right time. …

“This is not design by committee! Even nondesigners provide feedback, but you’re the one who uses that feedback.”

“Lean UX is:

“Control—You’re not giving up control of your work. You’re still in charge. You don’t need The Spec to keep control. You’re refining your work, based on feedback, to create the best solution. Less paperwork doesn’t mean you’re doing less work. Minimize waste. Focus on what’s key.”

The slide in Figure 21 makes a very important point about the likely consequences of not validating design concepts early.

“Designers shouldn’t be expected to get it right the first time,” argues Jeff. “Nobody else has to. Keep getting that feedback. It helps you maintain the vision. You are the keeper of the vision. The greater goal of the design is your responsibility. Everything is focused on that goal.

“Momentum—Everyone’s engaged. Everyone’s motivated. Keep everybody moving forward—your clients, stakeholders, your design, and you. There’s a perceived momentum to the project. You’re involving folks in the process.”

“Quality—Don’t compromise on quality.” Go for the gold, not the bronze medal, as the slide in Figure 22 aptly describes comprising on quality. “Iterations mean quality continually improves,” as Jeff shows in Figure 23. “Get the idea out there early. Get feedback. Iterate.”

“Feasibility—Make sure it can be built—and built well. Prototype it! But not all of it. Pick the core flows and prototype those, not the entire design. Minimize the amount of prototyping you’re doing. No additional deliverables are necessary! An additional benefit of prototyping is that you can do usability testing. Test whatever is ready to go—a sketch or a prototype—with three people for a half day every Friday. Once validated, demo it to the team. People get used to seeing incomplete work. You’re clearing the big boulders from the road. Then show it to your customers.

“Fill in the gaps—What did you not think about? The more you talk about it, the more you realize what’s missing. Constant communication and collaboration help you fill in the gaps.”

Next, Jeff described the differences between working with in-house teams and interactive agencies and the difficulty of selling lean UX to the latter. About in-house teams he said, “You are in the problem-solving business, and you don’t solve problems with design documentation. You solve them with elegant, efficient, and sophisticated software. Nothing demotivates a team more than not releasing software.” Figure 24 shows a lean UX process for an interactive agency, which is different from that for an in-house team, shown in Figure 20. Jeff told us, “Agencies are in the deliverables business. They sell Photoshop mockups, design specs, strategy decks, competitive analyses, personas, workflows. Reducing deliverables efforts reduces revenue—in theory,” but as Figure 25 shows, the reality is quite different. “Invest in your client’s success. It shows the confidence you have in your work,” he advised.

Is lean UX good for every project? Jeff recommended that we “use it where it makes sense. Functional, task-flow projects work well. There’s a clear end goal. Highly experiential marketing projects will suffer. Time to ideate and create options is essential. What about content-heavy experiences? Some up-front planning is necessary. Can distributed teams do lean UX remotely? If they’re [part of your organization], it’s on! If not, not bloody likely. With third-party, offshore vendors, this may not work.

“How do you get started? Get everyone involved early—talking, sketching, figuring out solutions to problems together, doing design exercises.” Figure 26 shows the output of a collaborative design session.

Who created all of these sketches? Jeff’s entire cross-functional product team, collaborating in a design studio, as described in Figure 27.

Jeff suggested that we start small, working with a small team on three or four small design projects, then tackle something big. Define the problem space before you kick the process off. Then, during the design studio, capture “six of your best ideas as fast as possible. Refine them to three or four better ideas and add detail. Then, do one final, detailed design. Let your one best idea shine.

“Designers are used to being heroes, but this process is distinctly anti-hero,” he observed. “It is a team-based process. Agencies push the hero model. But the more collaborative the process, the fewer change requests there are.”

This approach to collaborative design is very much in line with the way I work with product teams, so I can assure you that it is a very effective way of working.

Jeff concluded with this rallying cry: “Lean UX is an evolution, not a revolution. Evolve to stay relevant. Let’s get back to the experience design business.”

For Jeff’s full presentation, see Figure 28.

In the next installment of my IA Summit 2011 review, I’ll cover the keynote address and more conference sessions. 

Read more:

• “Conference Review: IA Summit 2011: Part II”
• “Conference Review: IA Summit 2011: Part III”