Downloaded 201 times
Uploaded byuxpin
Agile Prototyping Best Practices
The document discusses best practices for agile prototyping in user experience design, emphasizing the importance of clear communication and collaboration between clients, designers, and developers. Key recommendations include prototyping in chunks, prioritizing use cases, pacing fidelity, annotating user flows, reusing components, and validating small builds frequently. These practices aim to streamline the design process, enhance client understanding, and improve project outcomes.
More Related Content
Similar to Agile Prototyping Best Practices
Agile Prototyping Best Practices
- 1.
- 2. About Me Nate Ginesi SeniorInformation Architect Background is in visual design and marketing. Started in design and SEO and moved to Information Architecture and User Experience because the problem solving aspect and psychology of design is always what intrigued me. I love that I still get to use my design problems solving skills while solving complex business problems for users. ME
- 3. About LookThink LookThink isa full service user experience agency focusing on B2B enterprise product design. LookThink.com
- 4.
- 5. $ COMPLEXITY TIMEFRAME Days YearsLessComplexMoreComplex $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ Our Projects Varywidely … • in scope. • in timeframe. • as to when we enter the project. • in client involvement. • in the number of people working on them.
- 6. What I hopeyou get out of this • Help you move to a more Agile design process. • Obtain faster approvals from product owners. • Create natural collaboration with design team, development team, and clients. • Provide smoother handoffs to developers. • Make your lives easier.
- 7. So let’s talkabout how we got here ... PROTOTYPINGSTATIC WIREFRAMES
- 11. Shown to clientsfor approval:
- 12. Note the versioning,and reference to the 187 page requirement document. Easy to follow, right? Given to developers for development:
- 13. I kid younot … this happened
- 14.
- 15.
- 16. What the clientsaw: Is this going to be open all the time? Can I click this image? What does this show when clicked? Why is this turned off? What happens when I click the map? Where will this go? What page is this? What happens when I click the video? Can I click on these? So, can users click these? Why is this turned off? What happens when there are more than 20 results?
- 18. We put animage here to build trust in the brand. The results page can only support one search category at a time. We reduced the number of links here to two to increase focus. Users are now enticed to search first and can find what they are looking for easily. Confused users can now easily access the video explaining who you are. The table is more well spaced to provide easy scanning. Suppressing the button will clue users into the selection access. Users will care about the location of their results, so a map is critical to them finding usable results. Users can now easily access a particular facility. What we wanted the client to see:
- 19. We realized wewere losing the fight, not to our work, but to the static wireframe as a deliverable
- 20. We committed tocodeless prototyping as our method of Agile delivery
- 21. Committed to theswitch in one month 1 2015 START USING PROTOTYPES!
- 22. STYLE TILES PROTOTYPING WIREFRAMES Now, EVERYTHINGwe deliver prior to development gets delivered in UXPin AaDESIGNS
- 23.
- 24.
- 25.
- 26. If you’re goingto make the move to prototyping, here are a few things to consider: 1. There WILL be a learning curve with the technology. Practice makes perfect. 2. Don’t panic when you feel like you’re spending WAY more time up front. What you lose in time you’ll save in frustration. 3. Timelines for deliverables will be different throughout the project. But you’ll get more out of each deliverable. 4. Accept that there will be things you can’t demonstrate. Look for other examples online to help.
- 27. How do weincorporate these prototypes into our process?
- 28. Why am Ihere talking to you? What have we learned? What has been successful?
- 29. Best Practice #1 Prototypein Chunks: Depth vs. Breadth vs.
- 30. … EVERYTHING FORME STARTS ON PAPER
- 31. … THEY AREN’TPRETTY … THEY’RE BARELY LEGIBLE
- 32. … BUT THEYWORK
- 33. Simple boxes Links topages Light interactions Content if possible
- 34. Are we donehere? How do I retrieve my tasks? How do I see what I sent? How do I know when tasks are complete? What do the permissions look like? What defines a complete task? Can I put deadlines on tasks? Nope: This is too much for this sprint.
- 36. Option 1 Option2 Option 3 Option 4 For dropdown example, see navigation at www.theopen.com www.theopen.com Link to references online to save time.
- 37. Best Practice #2 Prioritizeyour use cases for prototyping
- 38. When deciding whatto prototype first focus on targets that will ease approvals and create clarity
- 39. Keep your earsopen for statements like: “I’m just not sure about this.” “I don’t think people will get it.” “I don’t understand what’s happening here.” “Can you explain to me why we have to do this?” “Do you think people are going to see that?” Priority #1 Has the client expressed confusion or concern over a particular piece of functionality? Having a client or stakeholder hung up on a piece of functionality is a sure fire way to add hours to a project. Recognize confusion and address it quickly!
- 40. Priority #2 What arethe highest value targets? Target the critical pieces first. If there are critical spots in the application, e.g. posting a photo in a photo sharing app, focus on getting those interactions in front of people and vetted before building out things like the settings. Do this before this
- 41. Priority #3 What arethe most complex interactions? You may not have to build it out. If it’s doing something similar to another site, save time and reference that. Option 1 Option 2 Option 3 Option 4 For dropdown example, see navigation at www.theopen.com www.theopen.com
- 42. Priority #4 What piecesare using commonly accepted UI patterns? If you’re not doing anything novel, it can probably wait. If you’re dealing with a known entity, you can usually wait to prototype the details, reference another instance, or avoid it altogether, e.g. a standard login.
- 43. Priority #5 What partsof the product have we not figured out yet? You can’t prototype what you don’t know. Create the page so you don’t interrupt flow, but leave it blank if you don’t know what it is yet. ?
- 44. Best Practice #3 PaceYour Fidelity
- 45. Two types offidelity: INTERACTIVE (FUNCTIONAL) FIDELITY How complete are the links, interactions, of the prototype? DESIGN (VISUAL) FIDELITY How complete is the design with regards to colors, shapes, hierarchy, layout, content etc.?
- 46. Fidelity over time Aquick landscape of prototyping fidelities. (Image credit: Fred Beecher, Boxes & Arrows)(View large version)
- 47. Benefits of yourlo-fi version • Acts as sitemap, a 10,000-foot view • Just the basic interactions to get through the app • Low investment • Helps find holes in your requirements
- 48. If you don’thave content, write it!* • The more you write for web products, the better you get at it. • You get a much deeper understanding of the product. • The best way to get the right content from the client, is to put in wrong content. *obviously there are instances when budget and timeline don’t allow for this, but if you’re having a hard time getting content from a client, this is an effective way to get them to act.
- 49. The more realisticthe content, the better both designers and devs can understand the full scope of the system
- 50. Visual fidelity overtime A quick landscape of prototyping fidelities. (Image credit: Fred Beecher, Boxes & Arrows)(View large version) Designs get a separate prototype. • We lower the functional fidelity, but raise the visual fidelity to a production level design. • These are often done in Sketch and exported back into UXPin. • Since stakeholders have already seen the functionality in the functional prototype, we don’t have to spend time recreating it in the visual prototype. • Allows design and IA to work in parallel. Designs
- 51. Don’t recreate the prototypein design. • Focus on a few key interactions and states. • Use simple toggle and hide functions and leave out any complex logic. • If you’re building for user testing, focus only on the things you’re testing.
- 52. Best Practice #4 AnnotateYour User Flows and
- 53. Your prototype becomesthe documentation Developers follow on screen annotations to understand what the app DOES, and not just follow the documentation and acceptance criteria. Your documentation here
- 54. Highlight functionality ona user journey E.g. “A user arrives on a page with a table of data. A search bar is available for the user to find a specific data element. When the user hits search, the table will narrow the results. Upon clicking a result, the user will go to the individual record.” And then the underlines would show the focus state, the search results table, and link to the individual record respectively.
- 55. Reduce confusion byincluding states Ensure you have all the different states the page could be in and ensure developers can find them easily instead of having to click around. Provide triggers on the side of the page and use documentation to supplement by providing the story. Side of your prototype Native UXPin documentation
- 56. Reuse elements (links, triggers,toggles, etc.) When it makes sense, you can repeat elements in your off screen documentation. Best used to reinforce functionality for elements that UXPin doesn’t let you clearly pin. Modals MultistatesHidden elements
- 57. Benefits of thedocumentation? - Ensures that devs see all the interactions. - Devs get a better sense of the product as a whole. - It allows the devs to plan ahead before their spring begins. - Gives QA folks more contextual acceptance criteria. - Creates a common language between devs and designers. - It bakes in a level of user testing.
- 58. Best Practice #5 Re-useYour Components
- 59. Reusable elements forall team members
- 60. Expand upon whatis already provided Input and search fields that clear on click Simulated “Spotify” style search Custom examples we’ve created with UXPin library as a start: Tooltips that stay active on hover
- 61. Expand upon whatis already provided Custom examples we’ve created with UXPin library as a start: Easily editable sliders Self contained modals that can be dropped anywhere
- 62. Why use aUI kit? - Very quickly creates visual clarity and “value” to clients. - Translates easily into a design language. - Anyone on the team can use it regardless of skill level. - No lost momentum worrying about the HOW it works. - Enormous time savings.
- 63. Best Practice #6 ValidateSmall Builds Often
- 64. The more youvalidate, and the more you communicate, the more agile you can be
- 65. Early validation increasesagility • Finds small mistakes before they’re big ones. • Finds holes in the product. • Prevents over-architecting. • Increases communication.
- 66. Validate small, completepieces • If demoing incomplete thoughts, do so in person. • Focus on flows first. • Move to smaller interactions next. • Demo only once you’ve added clarity. • Don’t abandon the user. • Reference earlier reviews to validate decisions for better buy in.
- 67. WHAT HAVE THERESULTS BEEN LIKE?
- 68. Things just runsmoother We’re able to spend more time on real business solutions and user experiences, and spend less time dealing with … the crap. (for lack of a better term)
- 69. Benefits of agileprototyping - There’s no risk of someone opening the wrong PDF from the email last week instead of the most recent version - There’s a common language between client, developers, and designers. - When we work in UXPin, everything is viewed at the correct size in a browser. - No zooming issues. - We can easily set breakpoints. - We know it will display reliably on the client’s devices. - THIS is why we put designs back into UXPin
- 70. Benefits of agileprototyping (cont.) - We’ve seen faster approval from clients. - Clients aren’t caught up in the deliverable. - They can focus more on business solutions and UX work we did for them. - They can interact with the deliverable instead of guessing. - Higher quality and consistency of our work.
- 71. Benefits of agileprototyping (cont.) - Less cycles are being wasted on petty stuff. - Better conversations and relationships with developers. - Comments and feedback are more easily managed. - No more crazy email threads. - Feedback cycles are much faster. - Better questions during reviews.
- 72. Overall, life isjust easier with prototyping CLIENT IA DEV DESIGN
- 73. Best practices foragile prototyping (summary) 1. Prototype in Chunks: Depth vs. Breadth 2. Prioritize Your Use Cases for Prototyping 3. Pace Your Fidelity 4. Annotate Your User Flows 5. Re-use Your Components 6. Validate Small Builds Often
- 74. THANK YOU! If you’reinterested in seeing more of what we do www.lookthink.com www.lookthink.com/blog Thank you for your time! Questions? and