An Agile Approach to User Interface Design for Web Applications

1. An Agile Approach to User Interface Design for Web Applications InterLab 2009 Shauna Fjeld November 17, 2009 Using sketching, prototypes, and user stories to define application requirements,get client buy-in, and design a better user experience.

2. What’s the problem we’re trying to solve? • I gave them exactly what they asked for in the requirements specification. • I gave them my vision, why doesn’t the application look anything like it?

3. Waterfall vs. Agile • Waterfall Approach • Each step of process is adistinct stage, which mustfinish before next one starts • Testing doesn’t happen until system is almost finished • Changes cause massivecode rewrites • Clients are not involved sonot bought into result Agile Approach • Individuals and interactionsover process and tools • Working software over comprehensive documentation • Customer collaborationover contract negotiation • Responding to changeover following a plan

4. Waterfall Web application process • Requirements& Analysis • Design • Code • Test • Implement • Maintain

5. Agile approach Develop high-level requirements Develop user stories and task flows Prototype theuser interface Develop& deploy

6. Develop high-level requirements • Gathering needs and ideas from stakeholdersand users • Understanding how the need is currentlybeing met (if at all) • Benchmarking competitor sites • Coalescing ideas into high-level requirements • Prioritizing requirements

7. Examples of high-level requirements • Provide a mechanism for state energy offices to calculate energy savings from measures funded by the state in the five main energy sectors. • Provide reports of savings to DOE.

8. Agile approach Develop high-level requirements Develop user stories and task flows Prototype theuser interface Develop& deploy

9. Defining primary users • Having a good list of users helps us understand functional scope • Methods • Surveys • Contextual inquiry • Interviews • Focus groups

10. What you need to know about your users • How many different types of users are there? • What are their goals? • What tasks will they need to complete? • Which of those tasks will the applicationsupport?

11. Prioritizing users • Which user types do we care about most? • Why is the application being built? • What business objectives do we hope to achieve? • Which user type is the most critical to support forachieving our objective? • For a typical system, expect 2 or 3 primaryuser types.

12. Defining user stories • How are real people going to use the app? • It doesn’t have to be complicated • What does your user do for a living? • Why are they visiting your site? • What do they want to accomplish while here? • What is their level of technical expertise? • What would they deem a successful experience? • User stories deliver a “gut check” to make sure you are on the right track when defining requirements, and creating visual and functional design.

13. User story example • Olivia is an energy economist for the Arizona Energy Office. She has worked for the office for nearly 25 years and knows the program well. She needs to account for energy savings from money flowing in from DOE grants. She will use the State Energy Program Metrics calculator to convert energy saving measures funded by the state to actual energy savings.

14. Task flow diagram Choose state • The flowchart details how a user will complete all the tasks in an application from beginning to end • It can be usedas a basis forthe prototype Choose year Choose an energy sector Save and go to another sector Fill in data for that sector Save and calculate energy savings Print report Export results

15. Traditional requirements specification • There’s a gap betweenthe requirementsand the design • It’s difficult tomanage changes • Complexity meansmore pages • No way to account for different users • End result: Application doesn’t match the client’s vision.

16. Agile approach Develop high-level requirements Develop user stories and task flows Prototype theuser interface Develop& deploy

17. Agile user interface design • Working closelywith clients and stakeholders to define the interface • Design iteratively until you get it right • The design is the requirements specification.

18. Why Prototype? • Prototypes are a way to analyze the problem with your stakeholders. • Prototypes are tangible. Your clients can understand them. You are both speaking thesame language right off the bat. • Prototypes are engaging. It leads to better feedback. It gets your clients excited.

19. Why Prototype? • Prototypes are a way to envision the system. • Prototypes arethorough. They help you think of things you wouldn’t when just writing a list. They make sure the app has the features your customers need. • They help you avoid spending time writing and updating documents that may not be used.

20. Why Prototype? • Prototypes communicate potential UI designs. • Client changes come early when they are easier and cheaper to make. • They ensure you build the site in a way that your customers can use. • Prototypes enable usability testing—goal is to fail quickly, to besuccessful sooner. • It’s a reality check to implementation. It’s easier to tell if it can really be done.

21. Four types of prototypes • Low visual and low functional • Low visual and high functional • High visual and low functional • High visual and high functional

22. Low visual and low functional • Stickies, sketches,white boards • Useful to determine • If the system has all thefeatures required to supportthe user’s goals • If the workflow makes sense at a high level • Which user interface concept works best • If the vision meets stakeholder’s expectations

23. Low visual and high functional • HTML interactive • Useful for • Validating if requirementsare implementedcorrectly • Validating UI design direction with stakeholders • Evaluating the usability of proposed designs with users • Especially remote testing (hard to do with low fidelity solutions) • Serves as documentation for development teams

24. High visual and low functional • Artist’s Photoshop file • Useful for • Testing the visual design • You can do paper prototypesor hot link them with image maps to do browser testing. • More useful for content sites than applications

25. High visual and high functional • Coded and beautiful • Takes time and effort • Useful for • Evaluating the usability ofproposed UI designs for anexisting system • Performing usability tests withnon-savvy user groups

26. Begin with low visual low functional • Two approaches • Sketchboarding • Adaptive Path – user interface and user experience design consultants • Design Studio • Jeff White and Jim Ungar presented this at User Interaction 08 • Jim Ungar formerly worked for Sandia

27. Sketchboarding • Hang up a large sheet of paper • Paste up requirements artifacts like • User stories • Task flow analysis • Functional requirements • Research findings • Helps focus on solving the right problem

28. Sketchboarding

29. Sketchboarding • Toss various UI elements onto thepage because you know they’ll needto be there • Try to get the most important ideas down • Design several possibilities. Never do just one. Force yourself to be creative • Gradually refine the layout, organization, and interaction of each element until you have a design that makes sense

30. Sketchboarding • Sketch at two levels: • Multi-page template • to quickly force out a half-dozen(or more) approaches to a problem • or to convey a flow of anexperience across many pages • Single-page template • to “zoom in” on a particular thumbnail idea

31. Sketchboarding • It’s not meant to be pixel perfect • It’s fast • It eliminates needless detail • It reasonably conveys highlyinteractive experiences

32. The Design Studio • Getting ready for the studio • Establish goals for the product(features and functionality) • Give the team all the information that needs to be there. Don’t give them hierarchies. • Give them user scenarios of what a person might do there. • Provide a simple list of tasks the user needs to be able to accomplish.

33. The Design Studio • Before the studio • Have the team prepare several rough sketches (pen and paper); the idea is to explore different concepts • Don’t spend more than 20 minutes on one sketch • Don’t spend more than a couple hours total for 4 to 7 concepts

34. The Design Studio • During the studio • Put sketches up on the wall • Have each person present concept • Critique for 8 to 10 minutes – document good and bad • Consolidation – review goals, discuss trade offs, make decisions • Final design = good parts of many concepts

35. The Design Studio Benefits • It establishes • Credibility of design team • Team ownership of design • Client buy-in because they’ve beenthrough process • Rapid development of design direction

36. Prototyping next steps • Validate against user stories • Walk your user through the prototype • Can they achieve their goals? • Is there anything you’ve missed?

37. Close the cycle with usability testing • Useful because • Enables us to gather the user viewpoint early on • Enables client to see things from a user perspective • Helps us to determine if the approach is working • Helps us determine what we are missing • Incorporate the feedback, and, if appropriate, move on to a higher visual or functional prototype. • Lather, rinse and repeat, as needed.

38. Agile = Success •  1. You save time and money • Clients, stakeholders, and designers are all on the same page • Fewer changes when programming means it gets done faster and better • 2. You have a satisfied client • They are engaged in product • The product matches their vision

39. References • “User Interface Prototypes,” Agile Modelinghttp://www.agilemodeling.com/artifacts/uiPrototype.htm • “The Design Behind the Design,” Boxes and Arrowshttp://boxesandarrows.com/view/integrating • “Just Build It: HTML Prototyping and Agile Development,” Digital Web Magazinehttp://www.digital-web.com/articles/just_build_it_html_prototyping_and_agile_development/ • Designing the Obvious. 2006. Robert Hoekman, Jr. • IBM Agile Resourceshttps://www-01.ibm.com/software/ucd/agileuxd.html • A Project Guide to UX Design. 2009. Russ Unger, Carolyn Chandler • “Sketchboarding,” Adaptive Pathhttp://www.adaptivepath.com/ideas/essays/archives/000863.php