Tag Archives | IA

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.

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

 

Comments { 0 }

The History of Information Architecture…And What’s Changing

Great panel to kick off the conference:

Changes they’ve seen:

  • Schleicher notes that today, more developers are moving toward IA, and prototyping is changing the conversation.
  • Scott worked at Borders.com 10 years ago, and notes that companies who don’t support ecommerce and the web do not succeed anymore.
  • Schleicher points out that people are increasingly recognizing the value of context in any decision.

Schleicher: You need to understand the impact you want to have, as much as you need to understand the user.

Stemen would love to get rid of the idea that everything needs to fit into a hierarchy. [I love this idea, but I also still struggle with getting people to understand the need for organization, finadability and even the customer experience -- never mind getting them to go beyond hierarchy.]

Schleicher: Still absolutely essential to visit real users and see their spaces or places. Did work for Ford and visited customers…and their cars. Made very effective decisions for the website based on knowing how real people used their cars.

Question from the audience: Does the panel expect all IAs will have to have development skills in the future?

Scott says no. It’s fine to, but the skills of communication, empathy and user understanding are central to IA.

Stemen: Cites Paul Resnick as saying that when you design at the edge of your understanding, your design will be amateurish. You need to understand a couple of levels deeper than where you’re designing.

Question from the audience: How have end users changed?

Scott: What hasn’t changed is basic biology and cognitive structures. What has changed is how much we use technology and how much more [frequently] we relate to it. Technology will be pervasive.

Schleicher: Most user research done 10 years ago is obsolete and dead. The user will be dead in 5 years — we will have technology as our copilot and not our servant. The changing demands of the workplace are radical right now.

Danger for the future: Stemen says his concern for the future is that IAs become all about documentation and just have to update the wireframes to match the comps….[Oh wait. That happens already.]

Comments { 1 }