I realized this week that in a traditional web app design scenario there end up being three review cycles:

1. Wireframe review – ensuring all the elements are on the page, hierarchically correct and flowing logically from screen to screen. Confirming that the right data is being captured and then presented back to the user in meaningful ways that encourage the correct actions.
2. Visual design review – once the wireframes are approved, the visual design transforms that skeletal frame into a living, breathing, beautiful work of art business solution. Colors, branding, typography, white space et al are all examined to ensure alignment and aesthetic quality.
3. Interaction review – this is when the actual code is put through its paces and stakeholders, for the first time get to play with their creation. All of the assumptions “approved” in the first two reviews are now put to the test to see if, in reality, they behave the way they were represented in the wireframes and visual mockups.

This last (and third!) review cycle, the interaction review, is the first time the experience being designed is actually, well, experienced. Any changes, tweaks, complete re-works and realizations are only now surfaced. The code has to be updated and, in most shops, the documentation leading up to that code will also have to be updated. This is wasted effort.

Prototyping gets the experience out in front of stakeholders, users and the execution teams early and often. The proposed end-state can be evaluated and estimated. Workflow challenges and nuances are far more readily exposed and solved – all without having to update ANY documentation (because none exists). Prototyping shows your executives where you’re heading. It shows your dev team what they should be building and how it should behave. And it shows your customers how you’re solving their problems  — before any major code is written.

As the experience is validated each time the prototype is presented, a finer layer of polish can be applied to the design – this includes interaction design tweaks, visual design and, if your code is good enough, code tweaks. Even if the prototype produces throw-away code (or no code at all) it is still far more effective at getting you to working software faster by experiencing the experience early and often.

Save yourself time. Prototype first.

[Jeff]

Image courtesy of: http://bit.ly/aW8G1P

“We’ll take care of it in Phase 2.”

Famous last words. This is the cry of compromise. It’s a phrase that echoes the silenced screaming of a thousand designers agreeing to less than 100% of the approved design being launched. It’s the tortured souls of disembodied drop-shadows, rounded corners, gradients and animated transitions roaming the nether regions of cyberspace — somewhere between a PSD and a hosted pixel.

But it’s not just designers who fear that phrase. Developer, too, tremble at the thought of hacks, workarounds and generally sloppy code making out to production with the never-to-come promise of future paying down of this technical debt.

And why does Phase 2 wreak such havoc in the minds of those who make web sites? Because Phase 2 rarely stands a chance in the shadow of The Shiny Object.

The Shiny Object is the next thing. It’s new. It’s young. It’s sexy. It begs to be worked on. It’s the future and it’s WAY more interesting than the “thing we JUST finished.” In a waterfall world, there’s almost no standing the way of The Shiny Object. It has the gravitational pull of a black hole sucking any notion of iterating on the feature set just released into its cold, dark center. However, in Agile environments, The Shiny Object stands a greater chance of being defeated because it is Phase 2 (and it’s siblings, Phase 3, 4 and N) that make short, iterative product development cycles possible and palatable to designers and developers.

Phase 2 holds the promise of taking the minimally viable product just released to your customers and making it that much better. That extra layer of data that makes the core experience that much more valuable? Let’s get it in there now. That extra design polish that wasn’t deemed “minimal enough” now gets its turn in the sun.  Yet The Shiny Object looms large even in the Agile workplace yet it is imperative we resist its siren song.

Image courtesy of: http://bit.ly/9ovbm5

Ignoring the need for Phase 2 destroys the promise of rapid, iterative design and development. The team inevitably gets that “half-assed” feeling for their work if, at the end of the iteration, it becomes apparent that Phase 2 will not come. In fact, The Shiny Object that has replaced Phase 2 also starts to look less shiny since, as we know, there won’t be enough time to get it truly shiny with The Shinier Object just around the bend.

Phase 2 is crucial to success. You must plan for it. Your Agile workplace depends on it. The expectations must be set early with every stakeholder that multiple phases will be needed to complete this work and that moving on to The Shiny Object will only happen when the team reaches consensus that a minimally desirable product has been developed.

Stay strong my friends.

[Jeff]

I just returned from a week in hot, sweaty and rainy Orlando, FL where I spent the bulk of my time at the Agile 2010 conference. It was my first time at such a specialized, non-design conference and I was doubly excited since I also presented. I went down with many questions — how are other organizations dealing with transitions into Agile? Is Design and User Experience even a consideration? What challenges and ultimately what solutions are people finding that work well for their teams?

I came down to Florida with those questions. I went home with them too. To be fair, I did get a slew of new tactics to try but the general vibe is that many folks are struggling with Agile — especially when trying to incorporate a design team (of any size, skillset or configuration). I focused my attention on sessions that dealt with the core problems with this integration as I see them — personalities and planning.

I found Lisamarie Babik‘s session on Coaching Introverts interesting and useful as it focused on pulling the quieter members of the team into the process more. I also spent time in Jean Tabaka‘s Visioning session. While it was a bit fluffy for my tastes it did give me some good ideas on how to focus the team on the things they want to achieve and not on the negative perceptions of an Agile design environment.

Jeff Patton and Desiree Sy — both UX/Agile legends at this point — provided strong tactical sessions on how to plan product design activities into the sprint timeframes. I found those sessions valuable and both individuals extremely friendly and forthcoming for conversation and differing opinions (Jeff I’d met once before but this is my first time meeting Desiree in person).

My presentation on integrating UX and Agile is embedded below. I feel like it struck a nerve with the folks who attended as it dealt directly with the failures we experienced at TheLadders as we’ve been integrating UX into Agile. But, more interestingly than that, it showed that even when good ideas fail, you can iterate, tweak and try them again — which is the essence of being agile.

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]

I work in an Agile shop. It’s been challenging making the transition and we’re still far from comfortable but we’re making progress. There are many changes to the way “we’ve always designed” when adopting an Agile philosophy. This post will focus on one realization I’ve made recently – there are no job titles, we are all designers. Traditionally we’ve segmented our work into IA, visual design, prototyping, etc. When we first rolled out the Agile framework we desperately tried to maintain these differentiations. This came both out of muscle memory for the waterfall process but also from a respect and understanding of other disciplines and our own limitations.

The outcome of this however turned out that our new two week sprint world was now cut down, in most cases, to one week as each role tried to complete their work in time to hand off to the next one and provide them the time they need to do their work. As if two weeks weren’t short enough to create quality designs, we now had one.

It’s worth mentioning that we eased into Agile with the introduction of a suite-wide style guide that was public, wiki-based (and therefore a living document) and easily reusable. The team was generating prototypes using the assets from the style guide so no matter who created them, IxD or visual designer, the end product looked “designed.” It dawned on me at that point that there was no need to break the design process down in the way we’d done in the past.

In practice, we are all designers. Yes, we each have unique strengths, weaknesses and capabilities and it’s exactly those qualities that determine how the work gets allocated. Each person now owns a feature for the full two week sprint – effectively doubling the time they had to work on it in the past. The style guide has helped us reuse patterns as they’re needed without having to reinvent elements each time they come up. The designers on our team work can now focus more acutely on the design challenge at hand and not as much on whether form labels go on top or on the left and what color to use for secondary navigation. It’s proved to be far more efficient and productive. In addition, it’s empowered AND educated our team on the other disciplines.

Now, this doesn’t mean there’s no collaboration. The team is encouraged to reach out to their counterparts to seek advice, input and fine tuning of their work. This collaboration is a team building approach as well as a cross-pollinator of expertise. Everybody wins when everybody’s a designer.

[Jeff]

I just finished reading @37Signals product design/development manifesto, “Getting Real.” I came out on the other side of this read so full of energy — motivated to go back to work in the morning, fire everyone except my favorite developer and product person (I’d do the design, natch) and set out to change the world with a kick-ass product. The no specs, get-it-out-in-the-wild and iterate, evolve and grow into something huge approach was the breath of fresh air I didn’t know I was missing. But then I stopped and paused to reflect on my current (and frankly, the bulk of my career) situation and reconsidered.

Can an organization that is carrying a full complement of employees, roadmaps, operating plans and budgets adopt this lean philosophy wholesale? I don’t think so. There are elements of the approach that can be watered down and used to augment some current behaviors but the kind of cultural shift required by this approach means retro-fitting an existing organization (of a certain size) is not possible.

Here are just three of the areas where I think the “Getting Real” philosophy breaks down with an existing organization:

1. You are NOT your customer — the book states you should build products for yourself — that YOU are your customer. This is simply not true with an existing org. The quantity and variety of folks working with you cannot all be your customers. You MUST interact with your customers to learn the true nature of their problems.

2. Epicenter design — frameworks are very popular in existing companies. The need to define the infrastructure for a system, interface or experience is a priority. These frameworks determine how many other people need to get involved, at what capacity and which systems need to talk to each other. In addition, the feature being developed in all likelihood is going into an existing product. That product has it’s infrastructure components already defined and these constraints are bequeathed to the feature you’re plugging in.

3. Technical and UX debt — in my experience, existing companies never go back and fix “little stuff.” If a feature failed or has a major bug then fixing that becomes a priority. Otherwise, it’s a steady march forward to release more product faster. Going back to tweak a mediocre implementation that still works is not a priority for any product owner. The compromises made during the lean product development lifecycle would simply  be treated as an admission of that compromise in index card form stuck to a debt board no one looks at.

I think the bulk of the advice in “Getting Real” is fantastic — IF you’re the 3-person startup described in it. In that situation you should definitely be producing working product at a very fast pace. In an existing org, however, there are elements of the day-to-day administrivia that you can hope to remove but effecting a wholesale transition to this approach would fail.

[Jeff]