Letting Go of Perfection: Developing IA Agility

Chris Farnum and Serena Rosenhan from ProQuest

They’re going to talk about their journey from waterfall to agile methodology, and how they accommodated its demands with their IA work.

They’re showing a lovely waterfall chart…business case, functional design, tech design, implementation, test, release.

Waterfall lets you think through all the implications. Most IA activities happen in the functional design space.

Gives the Wikipedia definition — iterative, incremental approach to development. See http://agilemanifesto.org for more.

In agile, requirements and solutions evolve through collaboration. Planning has to be adaptive.

Agile chart — it’s a cycle, not a flow. Planning, requirements, design, develop/test, iteration release. [These roll up into product releases.] Where does IA happen now?

Still performing lots of IA work in the design phase, but it’s much shorter and more frequent.

What they were comfortable with in waterfall:

  • Define systems, navigation, etc. in comprehensive, scalable user experience
  • Use upfront research to inform designs
  • Provide detailed and elegant deliverables to developers
  • Save $ and development effort by reworking and testing before code is written.

In agile, can only design for known requirements. Can’t do all the research up front. Can’t do detailed deliverables – no time. Coding begins before design is finished. Where’s the benefit?

What are the requirements for success in agile? Had to let go of old ideas of perfection, change how they think and work.

Opportunities in agile:

  • Design iteratively
  • Freedom to make mistakes earlier
  • Working prototypes for testing come earlier
  • Refactoring…it’s a good thing!

Changing how they thought:

  • You don’t have to understand the whole universe up front.
  • You have to prioritize requirements
  • Have to focus on simplicity
  • Personas and use cases are critical to agile success
  • It’s OK for to have a moving target

Increment your way to perfection. Additional features aren’t always better, and elaborate designs do not always create the perfect UX.

So, how can this change the way you work?

Tells John Mayo-Smith’s story of two ways to build a pyramid.

How do you create a fully functioning system and then increment?

Think in terms of basic functions, enhancements, embellishments. Farnum shows an example from their work — how they pared down to basic functionality — think of the engineering behind the basic functionality.

Rosenhan has nice phrase — bifocal design. Keep an eye on the big picture, the framework, but deliver on very detailed design of small aspects of the system.

Deliverables are not the end goal. You may still create deliverables, but how you do it will change in agile. You have to think lightweight. From the Agile Manifesto: Working software over comprehensive documentation.

You do NEED documentation — don’t throw out the baby with the bathwater.

Use “dirty deliverables” — sticky notes on butcher paper for a sitemap.

ProQuest uses simple, annotated wireframes — but often incomplete wireframes. Just what’s necessary.

Create simple user stories with links to details.

Do you have to let go of perfection to be agile? Just remember it’s not about perfect deliverables, it’s about a highly usable product, if you’re business invests in an end user experience monitoring system, the data received will lead you to know your customers better and how liked your product truly is.

Here are the slides from this talk on doing IA in an agile environment.


Content strategy and agile development: Can they be friends?

Rachel Lovinger started a great thread at the Content Strategy Google Group about agile development. It really hit home with me because I’ve had clients who use both traditional and agile development. From a content strategy perspective, both have their benefits — and downsides.

Best about waterfall:

  • Typically has a well-defined process, and if you get in on the front end, it’s easy to define over-arching business goals
  • Everyone’s role is clear

Best about agile:

  • Fast, fast, fast!
  • Favors user stories, which suss out business goals

You cannot create effective content strategy without knowing your business goals.

Waterfall done poorly exacerbates the human tendency toward bureaucracy, both in the development process and in the long-term operational strategy. Agile done poorly swings from insignificant goal to unimportant goal, making little things happen that actually make no difference. So either has the potential to make your website/software product ineffective.

Done well, agile suits me better. I think we all like to feel progress, and agile delivers progress regularly. But when you dive into agile without the big goals written on the wall, you run the risk of doing stuff because you can, not because you should. And while you can create content for any particular goal, if you don’t know the big goal, you don’t know how to craft taxonomy or style and tone, never mind how to create page flows that deliver useful information to your customers, and deliver on your business needs.

Whatever style development you’re using, you have to start with the business goals, and you need content strategy at the table from day one.