Lean IA: Getting out of the deliverables business

Updated: This topic has been expanded with a broader focus from Lean IA to Lean UX. The full essay version of the topic can be found on Smashing Magazine while the most recent presentation deck version can be found on Slideshare.

 

Traditionally Information Architecture (and its siblings Interaction Design, UX Design, et al) has been a deliverables practice. Wireframes, sitemaps, flow diagrams, content inventories, taxonomies etc defined the practice. While this work has helped define what an IA does and the value the discipline brings to an organization, it has also put IA’s in the deliverables business – measured and compensated for the depth and breadth of their deliverables (instead of the quality and success of the experiences they design). In addition this has forced niche specialization into our practice that has limited the success and growth of IA’s outside of the large organizations that can support these niches. People have become documentation subject matter experts focusing on (and being rewarded for) the quality of the document they’re creating as opposed to the end-state experience that document describes.

Enter Lean IA.

Inspired by Lean Product and Agile development theories, Lean IA is 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. It breaks the stereotype of the solitary designer working silently in a corner for a period of time with only occasional peeks into that work before it’s “done.”

The basic process looks something like this:

Concept → prototype → validate internally → test externally → learn from user behavior → iterate

Sound familiar? It should if you’re familiar with Agile or its derivatives. The difference is that this philosophy is focused strictly on the UX component of the process. Instead of pixel perfect designs, opt for sketches and whiteboards. Get the idea out and share it. Solicit feedback from your team. Iterate.

This doesn’t mean design-by-committee. By providing insight to your teammates sooner rather than further down the design road you’re:

1. ensuring you’re aligned with broader team and business vision
2. providing your developers a sneak peek into the direction of the application (speeding up development, surfacing challenges earlier)
3. further fleshing out your thinking since actually verbalizing your concepts to others forces focus on areas you didn’t think of when you were pushing the pixels

Got an idea for a flow? Put it up on the whiteboard and grab your product owner/project leader and tell them about it.

Ready to design? Rough out the first page in the flow. How does it feel? Is the flow evident from here? Put it up in a public place at the office and let passers-by comment on it.

Control

“But I’m giving up control of my design!” You’re not, actually. It just feels that way. What you’re actually doing is minimizing the amount of time you spend going down the wrong path. Also, you’re speeding up development time. By giving your team insight into the design direction they can begin laying the groundwork for that experience. Finally, you’re putting the power of validating your design direction much more quickly in the hands of the ultimate Decider – your customers.

If you spend 3 months perfecting a design only to find out it fails to meet customer needs after launch, you’ve just wasted 3 months of your life, not to mention your team’s.

Expressing your vision for the experience earlier, in rougher, less controlled forums lets your design speak for itself in the environment in which it will ultimately have to succeed.

Prototyping

This is where prototyping shines. Don’t prototype the entire experience! Pick the core user flow (or two) and prototype those screens only. Get that prototype in front of everyone who matters internally and then externally. Collect feedback. What worked? What didn’t? Tweak it. Hell, gut it if you have to – that’s the beauty of lean IA. The investment you’ve put in at each phase is so minimal that rethinking, reconfiguring or redesigning isn’t a crushing undertaking of workload and ego bruising.

Your prototype can be of any fidelity and created in any medium. Once created, it’s immediately testable with any and all users. Ideally, you can create usable code for your prototype in order to deploy to your real users. You’ll know very quickly if your design theories hold water.

Once validated, demo your prototype to the team. Explain the flows, the user motivations and why you designed it the way you did. The prototype has now become your documentation. Very little (if anything) additional is needed. Regardless, you’re there to answer questions as they come up. The beauty here is that now, design validated, the IA is freed up to move on to the next design challenge instead of spending the next 6 weeks creating a design requirements document and pixel perfect specs.

Vision

“But what about my vision? By chopping my design up and delivering it piecemeal to the team and ultimately customers I’m compromising my vision for the product!”

IA’s have traditionally worn many hats. You now have another one to add to your hall tree – keeper of the vision. In this new role it is YOUR responsibility to keep an eye on the big picture. Even as the design shifts and morphs through iterations and customer feedback you are always designing towards a greater goal. For example, “increasing time on site for return customers” can be a vision. “Deliver content, faster and in a more contextual manner” can be another. Regardless of how the design shifts, these goals drive your work.

It’s hard work though. The iterative cycle and varying opinions will try to get you to stray from your vision. This is where your push back. Ensure everyone on the team is bought into the vision and defend it as you iterate and evolve the experience.

Maintenance

Documentation has long-served as a way for an organization to maintain it’s software. It becomes a reference tool to understand the decisions of the past that then inform the decisions of the present. While this may make sense for complex business rules, it doesn’t make sense for design. The final product IS the documentation. It IS the experience.

What does that button do? Click it and find out. Etc.

Innie vs. Outie

And so we come to the question of culture. For software and web organizations, the transition to Lean IA is well within reach. You’re are in the problem-solving business and you don’t solve problems with design documentation. You solve them with elegant, efficient and sophisticated software. Working these new concepts should ultimately be an easy sell internally as you are espousing more collaboration, conversation and earlier delivery to customers. Yes, there will be culture shifts to make – shipping what amounts to minimum desirable products can sometimes be a tough pill to swallow for those used to launching big bang releases. However the ability to make quicker decisions along the way informed with regular customer feedback should ultimately trump these concerns.

Agencies have it a little tougher. Agencies are in the deliverables business. They get paid for their documentation and spend a LOT of time creating it. Each document has a specialist create it and that specialist is billable for that time. Reducing those efforts means reducing revenue.

I’ll propose that the shortfall in upfront revenue generated by deliverables creation can be easily made up and then some by delivering higher quality work, faster to your clients. By involving the client in your process, iterating quickly through design options and testing those options with real customers you will reach an optimal solution in less time than before. But wait, you say, less time equals LESS revenue?

Well, while that output took less billable time to create, it will likely be more successful and will bring that customer BACK to your shop with more frequency than in the past. In addition, you’ve made the client part of the process. This is empowering and clients like that feeling.

This is not an easy change since agency culture has been the same for many decades. Only the boldest agencies will take this on. But those who do will find that greater success will come from it and will quickly be imitated. These ideas are worth piloting on an internal project – perhaps the agency’s website redesign. Prove they work and then branch out to actual clients.

Conclusion

This is an evolution, not a revolution. IA’s need to evolve and stay relevant as our medium evolves. Lean IA gets designers out of the deliverables business and back into the experience design business. This is where we excel and do our best work. Let’s become experts at delivering great results through these experiences and forgo the hefty spec documents. It won’t be an easy road. The momentum of culture, both internal and at interactive agencies, will push against us yet the ultimate return on this investment will be more rewarding work and more successful businesses.

[Jeff]