Chris Farnum and Serena Rosenhan revisit their presentation from IAS2011 for World IA Day 2012 in Ann Arbor. This presentation is about the challenges of making the mental shifts needed to apply IA thinking to agile development.
Scaling API-first – The story of a global engineering organization
WIAD2012 A2 - Letting go of perfection: Developing IA agility
1. Letting go of perfection: Developing IA agility
World Information Architecture Day 2012
Ann Arbor, MI
Chris Farnum, Serena Rosenhan
@crfarnum @SHRosenhan #WIAD
2. Background – UXD/IA at ProQuest
Build search applications for academic and
corporate users
Translate business requirements into user
experiences that can be implemented by
development
Sit within development group
Have shifted from traditional (waterfall) to agile
development processes
Work on large scale agile projects
Global
Multi-year
@crfarnum @SHRosenhan #WIAD
3. IA - Traditional development cycle
Business
Case
Functional Design
Business
(prototyping, JADs
requirements
usability testing )
Functional Technical
requirements Design
Design Implementation
IA documents
processes Test
Release
@crfarnum @SHRosenhan #WIAD
4. What’s agile development, eh?
Wikipedia’s definition:
….a group of software development methodologies based on
iterative and incremental development, where requirements
and solutions evolve through collaboration
between self-organizing, cross-functional teams. It promotes
adaptive planning, evolutionary development and
delivery, a time-boxed iterative approach, and
encourages rapid and flexible response to change. It is a
conceptual framework that promotes foreseen interactions
throughout the development cycle.
http://en.wikipedia.org/wiki/Agile_software_development
For more see: The Agile Manifesto - http://agilemanifesto.org/
@crfarnum @SHRosenhan #WIAD
5. IA in agile development
Core IA
Design Processes
Prioritized Develop/Test
requirements
Planning
Iteration release Product
release
@crfarnum @SHRosenhan #WIAD
6. Agile challenges traditional IA value
proposition
Working in Waterfall Working in Agile
Define site/application systems Can only design for known
(navigation & labeling, metaphors requirements.
etc.), resulting in a comprehensive
and scalable user experience
Use upfront research to inform Cannot do all research up front.
designs
Provide detailed and elegant Smaller deliverables produced
deliverables to developers much more frequently
Save money and development Coding begins before design is
effort by reworking and testing finished – inevitably has to be re-
designs before one line of code is worked.
written
@crfarnum @SHRosenhan #WIAD
7. How can IAs be successful in agile?
Let go of old ideas of perfection and . . .
Change how you think
Change how you work
@crfarnum @SHRosenhan #WIAD
8. Change how you think
Understand the opportunities for IA in Agile
You can design iteratively
•Freedom to make mistakes earlier
•Working prototypes for testing
come early
•It’s OK to refactor... Really!
@crfarnum @SHRosenhan #WIAD
9. Change how you think
Want-to-have vs. need-to-have
How do I know the difference?
• Prioritize requirements
• User personas and use case
scenarios
• “What’s the simplest thing that
could work?”
• Remember that it’s a moving
target
@crfarnum @SHRosenhan #WIAD
10. Change how you think
Increment your way to perfection
Think just enough, just in time
• Additional features ≠ better.
• Elaborate designs do not
always create the perfect UX.
• Iterations provide room to
make incremental progress
@crfarnum @SHRosenhan #WIAD
11. Change how you work
An example…
Goal = A pyramid for the Pharaohs tomb
Pyramid example courtesy of John Mayo-Smith, Two Ways To Build A Pyramid,
InformationWeek, 22 Oct 2001
http://www.informationweek.com/news/development/tools/showArticle.jhtml?articleID=6507351 @crfarnum @SHRosenhan #WIAD
12. Change how you work
Approach 1 – Build the foundation
Pyramid example courtesy of John Mayo-Smith, Two Ways To Build A Pyramid,
InformationWeek, 22 Oct 2001
http://www.informationweek.com/news/development/tools/showArticle.jhtml?articleID=6507351 @crfarnum @SHRosenhan #WIAD
13. Change how you work
Approach 2 – Build up the pyramid
Pyramid example courtesy of John Mayo-Smith, Two Ways To Build A Pyramid,
InformationWeek, 22 Oct 2001
http://www.informationweek.com/news/development/tools/showArticle.jhtml?articleID=6507351 @crfarnum @SHRosenhan #WIAD
14. Change how you work
General requirement: Users must be able to save and organize
articles they find on your site into a personal account space.
Place in Attach the
multiple whole article
Email multiple as a PDF
folders articles Ratings
Search saved Share notes
Save articles article full text and ratings
to folders with others
Auto-fill Add/edit notes
search box
Email a link to Create a
an article. personal
account
Search saved
article titles Add / delete
Customize
articles to a Change
colors and
list password
layout
Business Ability to save Ability to email Ability to find Allow users to
Create a
Requirements personal
articles articles saved articles add notes
account
@crfarnum @SHRosenhan #WIAD
15. Change how you work
Back to the pyramid
@crfarnum @SHRosenhan #WIAD
16. Change how you work
It’s tempting to build requirements vertically...
Edit, Move, Attach the Share notes Customize
Embellishments Rename whole article
Auto-fill
and ratings colors and
search box
Folders as a PDF with others layout
Enhancements Save articles Email multiple Search saved Change
Ratings
to folders articles article full text password
Basic Functions Add / delete
Email a link to Search saved
Register for a
articles to a Add/edit notes personal
an article article titles
list account
Business Ability to save Ability to email Ability to find Allow users to Personal
Requirements articles articles saved articles add notes account
@crfarnum @SHRosenhan #WIAD
17. Change how you work
Good layering creates a fully functional system more quickly.
Edit, Move, Attach the Share notes Customize
Embellishments Rename whole article
Auto-fill
and ratings colors and
search box
Folders as a PDF with others layout
Enhancements Save articles Email multiple Search saved Change
Ratings
to folders articles article full text password
Basic Functions Add / delete
Email a link to Search saved
Register for a
articles to a Add/edit notes personal
an article article titles
list account
Business Ability to save Ability to email Ability to find Allow users to Personal
Requirements articles articles saved articles add notes account
@crfarnum @SHRosenhan #WIAD
18. Change how you work
Starting basic is also important at the next level of granularity.
Edit, Move, Attach the Share notes Customize
Embellishments Rename whole article
Auto-fill
and ratings colors and
search box
Folders as a PDF with others layout
Enhancements Save articles Email multiple Search saved Change
Ratings
to folders articles article full text password
Basic Functions Add / delete
Email a link to Search saved
Register for a
articles to a Add/edit notes personal
an article article titles
list account
Business Ability to save Ability to email Ability to find Allow users to Personal
Requirements articles articles saved articles add notes account
@crfarnum @SHRosenhan #WIAD
19. Change how you work
Layered design example
1st layer – Saved list of articles
@crfarnum @SHRosenhan #WIAD
20. Change how you work
Layered design example
2nd layer – Add navigation, article details, sorting
@crfarnum @SHRosenhan #WIAD
21. Change how you work
Bi-focal design
• Attention to framework, architecture, big picture
• Deliver detailed design on very small aspects of system.
@crfarnum @SHRosenhan #WIAD
22. Change how you work
Many of these are familiar, but how you
produce them may change.
Personas
Use cases
Sketches
Wireframes
User stories
Process flow
Prototypes
-and-
Ad hoc – what the project needs now.
@crfarnum @SHRosenhan #WIAD
23. Change how you work
Deliverables– think lightweight!
The Agile Manifesto
“Working software over comprehensive documentation”
Austin Govella
“There’s a dangerous, anti-deliverable meme lurking about that
damages good teams.”
Anders Ramsay
“UX designers continue to struggle with letting go of the
deliverables mentality, the idea of UX being one of creating
pretty-looking design artifacts before starting to create
software.”
@crfarnum @SHRosenhan #WIAD
24. Change how you work
Try using “dirty deliverables” for some situations.
A basic site map – post its on butcher paper (courtesy of FatDUX)
@crfarnum @SHRosenhan #WIAD
25. Change how you work
Wireframes work well side by side with annotations
FIG 2: My Saved Articles FIG 2 Notes:
1. Page title
2. Count of all items in the list.
• Increments as items added
1
2 4 • Decrements as items deleted
3. Link back to last set of search
3
5 results
4. Sort options:
• By date added – reverse chron
• By date published – reverse
6 chron
• Alphabetical by title
5. Checkbox to select all items in the
list
• Checking selects all items
• Unchecking deselects all items
6. Articles. Each item includes:
• Checkbox
• Number in list
• Citation – in same style as in
search results
• Date added – DD Mon YYYY
@crfarnum @SHRosenhan #WIAD
26. Change how you work
User stories – keep them short and precise. Link to details
Title: Article list view
User statement: As a researcher, I want to see a list of articles that I have selected during my session.
Acceptance criteria:
1. The page appears as in the wireframes.
2. The titles of all articles the user has selected during the session are listed in alphabetical order.
3. The articles are numbered.
4. Each article can be deleted from the list.
Wireframes: http://www.mywireframelink.com
Owners:
JMarkel – IA
JJones - DEV
SSmith – QA
Related Stories:
1287 Link to article list from utility nav.
History/notes:
1. 1 Apr 2011, JMarkel - Story created
@crfarnum @SHRosenhan #WIAD
27. Conclusion
Do you really have to let go of perfection to be agile?
It’s not about perfect deliverables, it’s about working
toward a highly usable product.
It’s a goal, not an end-state.
It’s a lesson we’re all still learning.
@crfarnum @SHRosenhan #WIAD
28. Bye
Questions?
Contact info:
Chris.Farnum@proquest.com
Serena.Rosenhan@proquest.com
Slideshare
http://www.slideshare.net/ChrisFarnum/
Special thanks to Joanna Markel and Carissa Demetris!
without whose Agile know-how this presentation would not have been possible
@crfarnum @SHRosenhan #WIAD
Editor's Notes
ChrisToday we are going to talk about the experience of having to shift from doing IA in a more traditional development cycle (waterfall) to doing IA in an agile development cycle. We are going to share some things we have learned from our time working with agile, some practical tips & tricks – may help some of you just getting started or possible offer some new ideas for those of you that have been doing this for awhileShow of handsHow many of you have experience working with agile development?How many are about to get experience with agile?
ChrisFirst some background…(Review points)(Handoff to Serena)
SerenaClick - In a traditional development cycle there is an upfront Design phase where we work through the site structure & designAt the end Deliver a design specification , wireframe set, etc. to development team for implementation.
Serena(quick review of def)ProQuest transitioned to agile dev in 2008.The big question – how does IA fit in?
SerenaAgile involves iterative and incremental development. Collaborative teams are working in smaller development cycles (1-4 weeks) Idea is to get to something working and testable earlier and to have smaller releases of functionalityRole of the IA is still to translate business requirements into user experience, to document the requirements for development (user stories, acceptance criteria) Click - No longer happens in a single design “phase” – design is now incremented in the various, generally working 1-2 cycles or sprints ahead of the development teamDevelopment begins much sooner and never stops – constant need to feed story cards to development (feed the backlog -- many of you can relate to this)
SerenaGoal of every IA: design “perfect” experiencesAgile pressures challenge the traditional value proposition we have worked so long to build up in companies. This was certainly our experience. Working in agile:Designing the comprehensive experience –> can only design to known requirements – but must still scaleA lot of upfront research -> all the reqs not known = cannot do all the upfront researchDetailed design deliverable -> smaller deliverables, more frequentSave money & development effort by doing designs & testing up front -> Coding begins before all designs complete, there will be rework
SerenaWhat we can do as User Experience designers and information architects working within agile development processes to reclaim or re-write the value proposition for IA in agile?What we wish we had known 3 years ago – help save you from our mistakesLet go of your old ideas of perfection – detailed design packaged in elegant deliverables and…
SerenaTransitioning to agile requires a mental shiftNo longer have a long upfront design stage to perfect the designYou need to understand the opportunities for IA in agile and to harness its iterative natureMake mistakes faster = opportunity to reworkWorking prototypes = If things stay on paper, they may be beautiful experiences, but they will never get to a user. In the demo - Team B – had a working prototype much earlierEnd goal is still to come up with a timeless design, but you don’t have to lock it in before coding is done. Be willing to make mistakes and part of changing how you think is being willing to hand over less-than polished workArtist – crumbling up paper They discard the artifact, but they don’t discard what they learned from creating it.
SerenaThe demoNeed to have – a plane that fliesWant to have – stripes on the wingsHow to know the difference:Priority - What is core to delivering a working system?Go back to your personas and use cases – what is essential to the experience?Ask yourself “What’s the simplest things that could work?.” It’s often the best starting point for incrementing your design. And also probably the easiest for your developers to get something running.Moving target - Yesterdays want-to-have’s become tomorrow’s need-to-haves as your design matures. Demo – logo – an upfront “want to have” for early cycles becomes a “need to have” closer to final release
SerenaComplexity can be your enemy. Simple designs can often be more intuitive and easier to understand– coffee machineStart simple, test, iterate as neededDo not try to design the ultimate end state up front
ChrisA classic agile example of building a pyramid to demonstrate two approaches to layering functionality – John Mayo-Smith, Two Ways To Build A Pyramid,InformationWeek, 22 Oct 2001http://www.informationweek.com/news/development/tools/showArticle.jhtml?articleID=6507351The end goal = The Pharaoh wants the tallest pyramid in which to have his tomb
ChrisBuilder 1 builds a perfect base to create a pyramid of the desired height based on the Pharaoh’s expected life expectancyKeeps adding more height The Pharaoh dies early and there is no pyramid! – in software development, the unexpected can and does frequently happen
ChrisA different approach – start with a small pyramid, build out the height of the pyramidAt each stage, he still has a complete pyramid Next let’s translate this into an example from our own project experience
ChrisIn our organization, user experience designers are given business requirements like these to flesh out.They often lead to brainstorming the functionality to deliver the business requirements.Imagine a white board filled with post-its.
ChrisThe pyramid example offers a framework for organizing and evaluating functional brainstorming.
ChrisBuilding vertically means it may take longer before you have a system that fully delivers on the business requirements.
ChrisBasic functions – concentrate on “need to have.”Also plan for things that your development team will need to implement first.Building horizontally – with the first cut at basic functionality completed is better for getting working system started.
ChrisLet’s focus on just one basic piece of functionality, the kind you might need to be delivered in just one or two sprints.
ChrisWhat seems like a small feature or requirement can often raise a host of questions about how complex the design should be. Looking at examples of mature designs on the Web can sometime help solve problems. But sometimes it also pushes us to add complexity before the project is ready. Again, it’s important to start by asking, “What’s the simplest thing that could work?”Don’t start with embellishments.Even this simple design might take several stories to get started. And it could be dependent on the personal account registration requirement.
ChrisAdding article details goes hand in hand with sorting.In future layers you might add “select all” and toolbar with a “delete” button.From a design and coding perspective, performing actions on multiple items at the same time is more complex than performing an action on one thing at a time.If other features are being planned at the same time, you have a chance to see how they work together in your design. For example, in this design, select all and delete can be combined with a toolbar that handles several related functions.
SerenaNot without challenges and tensions: Designing piecemeal tends to keep you submerged in details. It can be a challenge to keep the big picture in focus. This meant we had to develop ability to do “bi-focal design” Attention to framework, architecture, big picture and what was coming in the future (click) -- sometimes working outside and ahead, sometimes looking back and reworking designs -- taking all new elements into consideration (We had to carve out time for this, no one told us to do this.) Deliver detailed design on very small aspects of system. (click)A related challenge was how to ensure our team of 28 different uxdcontributers -- all working incrementally and iteratively – shared the same big picture and could collectively build a unified and coherent end user experience? (Met this challenge with lots of planning, and lots of group reviews, and occasional re-factoring.)
SerenaThere are many types of deliverables that IAs produce in Agile. This is just a short list of common examples. Many of them are the same as in waterfall (at least in our organization).Many of the daily deliverables and work products are not significantly different. The difference is in how you produce them.Paraphrasing Anders Ramsay – don’t think of your UX deliverable as the end goal… they document decisions made as part of a conversation.Ad hoc – maybe the project needs a word table of format definitions, or a tracking spreadsheet…
SerenaAgile Manifesto – The ethos is not to make a pretty, bound deliverable.There is some debate over how to approach deliverables.Deliverables don’t need to be pretty to be useful. But they shouldn’t be sloppy or leave important questions unanswered.http://agilemanifesto.org/http://www.andersramsay.com/2010/11/06/findings-from-the-state-of-agile-ux-surveyhttp://www.thinkingandmaking.com/view/agile-ux-yourDiscuss how this replaced the big giant spec
SerenaEric Reiss says dirty deliverables are great for client meetings and underscore that the design is not set in stone.
SerenaWireframes supplement stories and provide a deeper level of detail. Usually produce wireframes before user stories.Leaving a thin column for annotations encourages you to keep them brief.Just enough – just in timeDeliver annotated wireframes rather than complete requirements documentsDeliver incomplete designsRefactor, refactor, refactor
SerenaRelate to article favorites list example.Should not be too long. Guideline – 8 to 12 ACs max. Using too many subpoints is cheating.If too long, break into another story.Could be used in solutions like Scrumworks or on paper index cards.Use a template! - Template helps with consistencyUser statement – refer to persona, a brief scenarioACs – used by both developers and QAHistory – create, modify, place on hold, approve
SerenaWays to approach-Sometimes they should be black and white only to avoid over specifying design.Sometimes screen clipping with some drawing overtop is the best way to communicate your designTry sketches on paperBase it on the situation and what works for the teamIssue: multiple people in a large team might be modifying the same page at the same time. Find conventions in your wireframes and stories to highlight only the parts of the design that are changing. Idea – circle or note the specific pieces that are affected. Or grey-out the parts that aren’t changing.