WIAD2012 A2 - Letting go of perfection: Developing IA agility
•Download as PPTX, PDF•
3 likes•2,262 views
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.
Recommended
More Related Content
What's hot
Similar to WIAD2012 A2 - Letting go of perfection: Developing IA agility
Similar to WIAD2012 A2 - Letting go of perfection: Developing IA agility (20)
More from Chris Farnum
More from Chris Farnum (14)
Recently uploaded
Recently uploaded (20)
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.
- Chris- Conclusion