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.
