Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (8)
Similaire à Agile UX - expanded and reworked
Similaire à Agile UX - expanded and reworked (20)
Dernier
Dernier (20)
Agile UX - expanded and reworked
- 1. Agile UX How to do Design Up Front when you’re not allowed to do Big as shown at hello@sparrk.co.uk http://sparrk.tumblr.com
- 2. Can I have some
- 3. The Five Minute Introduction To Agile
- 4. The Five Minute Introduction To By WayAgile Of Analogy To Popular TV Shows
- 5. High Level
- 6. Team of Generalists Specialists with Domain
- 7. Plan Your Build Strategically
- 8. Start Building As Soon As You Know Enough To Get
- 9. You Know The Release Date
- 10. You Aim To Build Only As Much As The Requirements
- 11. You Build Something Releaseable And Enhance
- 12. Change Happens And You Adapt To It
- 13. The Lightweight Option Always Beats The Heavily
- 14. You Can Do Well Or Badly Depending On How You
- 15. And Then You Iterate
- 16. It’s Surprisingly Easy To Bugger It Up
- 17. The Iteration or Sprint
- 18. A Release* i1 i2 i3 i4 i5 *One project may have many releases And they are not necessarily public releases
- 19. Have a Design Design Design Design Design fucking for i1 for i2 for i3 for i4 for i5 party i1 i2 i3 i4 i5 THIS NEVER
- 20. Agile’s Dirty Secret: Planning ~= Design
- 21. Gather Requirements Agile’s Dirty Secret: Planning ~= Design
- 22. Gather Analyse Requirements Requirements Agile’s Dirty Secret: Planning ~= Design
- 23. Gather Analyse Write Requirements Requirements Epics Agile’s Dirty Secret: Planning ~= Design
- 24. Gather Analyse Write Scope Requirements Requirements Epics R1 Agile’s Dirty Secret: Planning ~= Design
- 25. Gather Analyse Write Scope Write Requirements Requirements Epics R1 Stories Agile’s Dirty Secret: Planning ~= Design
- 26. Gather Analyse Write Scope Write Plan Requirements Requirements Epics R1 Stories R1 Agile’s Dirty Secret: Planning ~= Design
- 27. Methodologies For Rethinking Our ✦Lie ✦Cheat ✦Steal ✦Do Some Work
- 28. Lie ✦ Find the places where UX strategies can be aligned with existing Agile strategies ✦ UX Mobile First == Agile Minimum Valuable Product ✦ UX Paper Prototyping == Agile Spike ✦ UX Guerilla User Testing == Agile Showcases ✦ UX User Benefit ~= Agile Business Value
- 29. Cheat ✦ Get BAs to do half your work in planning ✦ Exploit Automated Testing for partial accessibility testing ( http://code.google.com/p/web-accessibility- testing/downloads/list) ✦ Structure test data so as to stress the UI ✦ Use rapid deployment to create user testing environments - bonus if your team uses Devops
- 30. The BA Is Your Best ✦ You need to have exactly the same understanding of the product ✦ As the BA is decomposing business needs into dev-ready stories, you should be decomposing them into user-ready interactions ✦ This synergy can help drive certain requirements - taxonomies, sitemaps
- 31. Gather Analyse Write Scope Write Plan Requirements Requirements Epics R1 Stories R1 Begin Begin broad IA Identify UX Wireframe site Wireframe Hi-Fi (to feed Requirements Epics design Stories i1 of R1 into Epics) language
- 32. Steal ✦ Technical Debt ✦ Stubbed/Mocked Interfaces ✦ Behaviour Driven Design/Test Driven Design
- 33. UX Debt “Good enough” or “quick fix” solutions that get you past a problem quickly But too much debt can choke a project further down the line So you must address UX debt periodically - during i
- 34. Stubbed/Mocked ✦ Stubbed Designs act as placeholders for features that haven’t been designed yet ✦ They can also be your progressive enhancement baseline ✦ They should be simple, but they don’t need to be ugly
- 35. You can flag stubs too .stub:before{ width : 64px; height : 64px; background : url(/core/images/nodeploy/flag-stub.png) right top no-repeat; display : block; content:" "; position : absolute; right : 0; top : 0;} .stub{position : relative;}
- 36. The Last Resort ✦ Our deliverables need to work harder ✦ Be ready to refactor - deliverables AND code ✦ Don’t be precious about “done” ✦ Fight for research - it begins outside the Agile lifecycle, and continues beyond it ✦ Be continuously available
- 37. Prepare to ✦ Organise Refactor for change your files to prepare
- 38. Prepare to ✦ Organise Refactor for change your files to prepare http://photoshopetiquette.com/
- 39. Prepare to ✦ Organise Refactor for change your files to prepare ✦ Use design/UX patterns wherever possible ✦ Use stubbed design and UX debt ✦ Build a reusable asset library early on ✦ Use a preprocessor like LESS to ensure your CSS can be quickly refactored ✦ Focus on high-friction targets first - the UX debt will be less painful for users on the low-friction ones
- 40. The web is not flat images any more ✦ We need to be able to show multiple states and animations easily ✦ We need the rest of the team to be able to understand the scope of a design unambiguously ✦ We need to be able to refactor our deliverables quickly, and have the refactoring cascade through the whole project ✦ We need to have a tool that supports patterns
- 41. Hannah Donovan ✦ What does our 3/4 view look like? ✦ http:// www.webdirections.org/ resources/hannah- donovan-designing- without-the-browser/ ✦ http:// www.webdirections.org/ resources/hannah-
- 42. Jan Srutek http://www.slideshare.net/JanSru/ communicating-and-selling-ux-design- deliverables
- 44. Defining “Done” ✦ Don’t be precious about signoff ✦ If it works well enough, sign it off and raise an enhancement - let the client decide how important design perfection is ✦ Or track imperfections as defects or UX debt and raise tasks to fix them ✦ Be open to developers’ suggestions but stand firm on the really important stuff
- 45. Fight For Research ✦ Agile sees human users as external dependencies that can’t be stubbed or automated, and tries to route around them ✦ It’s cheaper to push back planning than development if the business needs to do more UX research ✦ Releases are outside of The Iteration - you need to stick with them, because the process doesn’t.
- 46. Continuous ✦ Availability Is horrible and makes it difficult to get into the zone and you can’t listen to music and YOU HAVE TO DO IT ✦ If developers think you’re unapproachable, they’ll guess at implementation – THIS IS BAD ✦ Be available with your body language as well as your speech: “My time is infinite and you can have as much as you want”
- 47. Continuous ✦ Availabilityare >1 The Sacrificial Lamb – when there people in a role, they rotate their availability ✦ The Scary Face – a physical flag you can raise when you need to focus, but it requires a lot of discipline ✦ No-meeting Hours – you stay available to the team but no meetings can be booked, reduces the chance of being pulled away ✦ Be careful not to overuse these and drive devs away!
- 48. Agile Won’t Wait http://www.flickr.com/photos/uriel1998/
- 49. Now go and build incredible things.
- 50. Thank You http://sparrk.tumblr.com hello@sparrk.co.uk
Notes de l'éditeur
- \n
- Can I get a show of hands for: -People who know what Agile is; -Keep your hands up if you’ve used Agile on a project before; -Keep your hands up if you found Agile made it harder to do the UX, or if people complained that UX requirements made it hard to be Agile\n
- OK, so what I will do is try to give those who aren’t familiar with Agile a very quick five-minute introduction to the discipline...\n
- ...in terms that should be pretty accessible. What I’m going to do is describe an “idealised” Agile process in the usual form that developers will explain it. Agile’s a very developer-led methodology so this is the perspective it usually gets explained from. Don’t worry, I will turn it around later on.\n
- You start out with high-level real-world requirements. Not “I want a system that does these things,” but “I want a system that fulfils these needs.” For most of us that means user requirements, because happy users spend money.\nWhich is a bit like the initial challenge conditions for Scrapheap Challenge.\n
- The ideal Agile team is made of generalists who have very broad T-shaped knowledge, but you often have domain specialists involved. That domain may be a business-related one, or it may be something else like UX.\nWhich is a bit like the Team + Expert dynamic from Scrapheap Challenge. Lisa Rogers is, sad to say, not guaranteed to be present in every Agile team.\n
- Here’s where Agile starts to come into its own. Instead of documenting everything then building it, you plan a flexible implementation model based on the idea that as you build the product, your understanding of the requirements will change.\nWhich is a bit like the early strategy sketches the teams do in Scrapheap Challenge, before they know exactly what components they’ll be able to find on the heap.\n
- Then you start building as soon as you’re confident you understand the requirements well enough. I’ll explain why later, but in the meantime it means a lot less boring paperwork.\nWhich is a bit like the way Scrapheap Challenge teams do the minimal planning before they send the scavengers out to find bits of scrap to build into their machine. No point planning the fine details before they know what they have to work with.\n
- This is a key thing: Agile wants to deliver fast and often. So you have a product scope, a release scope, and a release date. If you slip behind - and what software project doesn’t - you can move the release date *OR* cut the release scope. But doesn’t that mean you release unfinished software? No, for two reasons we’ll talk about in a second.\nThis is a bit like Scrapheap Challenge, in that teams have a time limit to build machines that fit the challenge terms, and if they run up on that limit, they have to build something that can be “released” to the challenge.\n
- Agile likes to test things. And one of the tests should be, does this feature fulfil an existing business requirement? If yes, it gets built. If no, it gets tossed. And bear in mind this is an equation with two sides: The business may have realised it doesn’t need that requirement after all.\nWhich is a bit like the way Scrapheap Challenge teams don’t mess about with extraneous features that don’t help them meet the challenge.\n
- Here’s the other key thing. At the end of every iteration your aim is to have a product that *could* be released if it had to. It may not be feature complete but it doesn’t fall over and it’s not broken. So you may build a single feature across several iterations, building then enhancing it with new functionality.\nWhich is a bit like the way Scrapheap Challenge teams use “tinker time” to enhance their machines by painting them in team colours... sort of... this is a bit of a reach to be honest.\n
- The market changes; the business realises it wants to target a different segment; or the business has a grand new idea. You take the change and run with it as soon as you can. Because your structure is flexible and you have a product that’s theoretically ready to go, the cost of changing direction is low, and you can go to market fast with it.\nWhich is a bit like the bit in Scrapheap Challenge where the melancholy guitar chord comes in. The scavengers couldn’t find something on the heap, or something breaks, or something doesn’t work they way they thought it would. Sometimes the scavengers will find something BETTER on the heap than they expected to, and the solution gets rebuilt around it. Teams that win are the ones that keep their plans flexible enough to embrace both positive and negative change.\n
- Lightweight structures can change fast, heavyweight structures can’t. The ability to change swathes of code rapidly is called refactoring, and it’s key to both enhancing features and keeping the cost of change low.\nWhich is a bit like the way the teams in Scrapheap Challenge always conveniently split along lightweight/heavyweight lines. And the lightweight one usually wins.\n
- Agile is a team discipline and your team can do it well or badly, based on how well it works together to adapt to emerging challenges.\nWhich is a bit like the way one team always does better than the other on Scrapheap Challenge. The teams that don’t win don’t always fail, either. Different architectures, filtered through the SC process, can end up competing very closely.\n
- This is where the Scrapheap Challenge analogy breaks down, because SC is like just one iteration - they get a requirement and build a feature. A Release in an Agile project consists of several iterations to meet a target set of requirements (which is, of course, malleable). Ideally you’d want a version of SC where each week they get more requirements and have to enhance their machines to meet them. Which is a bit like less-well-known SC spinoff The Scrappy Races.\n
- And finally, although Agile seems like a simple recipe, it’s surprisingly easy to miss the key aims and practices and bugger it up completely. Which is a bit like the fucktrocious Series 11 of Scrapheap Challenge where they got rid of the hosts in favour of moustachioed former contestant Dick Strawbridge, dropped the time limit, added more than two teams and ruined the series so badly Channel 4 never even bothered to show all the episodes.\n
- So to move this more towards software dev, one iteration lasting one or two weeks maps roughly to an episode of Scrapheap Challenge. This is a developer’s view of Agile because it’s where all the fun dev stuff happens. But there’s slightly more to Agile than just the iteration. Let’s look at the view a different actor has. What does Agile look like to a Business Analyst?\n
- So here’s your release, and as you can see there are bits outside the “classic” understanding of Agile that don’t map to SC. Developers tend to ignore these bits because not much code gets written in them, therefore they are boring. But these are key parts of how we UX people can work better within the Agile process.\n
- Here’s a model that doesn’t work, and unfortunately it’s a very popular one with PMs. Lynn Miller wrote a paper recommending it that has been widely adopted. This is a development-led view of Agile, and by tying UX to the iteration cycle, it makes UX subservient to development. That’s an abusive relationship. Design and development effort are highly orthogonal - it can take a long time to code a feature that’s fast to design, or conversely it can take ages to design something that comes together very quickly in code. If you follow this plan the chances are design will quickly start to slip behind development. And at that point you have developers building stuff that’s been specced but not designed. That’s not a good outcome for the user.\n
- Here’s how that initial planning phase expands out from a BA’s point of view. Devs perceive requirements as being trickle-fed to them at the start of each iteration. But that’s not how businesses conceive of products, nor how they run feature discovery. What this proves is that “No Big Design Up Front” depends a lot on your definition of “Design.” I posit that by aligning ourselves outside the iteration as BAs do, we can find some space to do the design we need to.\n
- Here’s how that initial planning phase expands out from a BA’s point of view. Devs perceive requirements as being trickle-fed to them at the start of each iteration. But that’s not how businesses conceive of products, nor how they run feature discovery. What this proves is that “No Big Design Up Front” depends a lot on your definition of “Design.” I posit that by aligning ourselves outside the iteration as BAs do, we can find some space to do the design we need to.\n
- Here’s how that initial planning phase expands out from a BA’s point of view. Devs perceive requirements as being trickle-fed to them at the start of each iteration. But that’s not how businesses conceive of products, nor how they run feature discovery. What this proves is that “No Big Design Up Front” depends a lot on your definition of “Design.” I posit that by aligning ourselves outside the iteration as BAs do, we can find some space to do the design we need to.\n
- Here’s how that initial planning phase expands out from a BA’s point of view. Devs perceive requirements as being trickle-fed to them at the start of each iteration. But that’s not how businesses conceive of products, nor how they run feature discovery. What this proves is that “No Big Design Up Front” depends a lot on your definition of “Design.” I posit that by aligning ourselves outside the iteration as BAs do, we can find some space to do the design we need to.\n
- Here’s how that initial planning phase expands out from a BA’s point of view. Devs perceive requirements as being trickle-fed to them at the start of each iteration. But that’s not how businesses conceive of products, nor how they run feature discovery. What this proves is that “No Big Design Up Front” depends a lot on your definition of “Design.” I posit that by aligning ourselves outside the iteration as BAs do, we can find some space to do the design we need to.\n
- Here’s how that initial planning phase expands out from a BA’s point of view. Devs perceive requirements as being trickle-fed to them at the start of each iteration. But that’s not how businesses conceive of products, nor how they run feature discovery. What this proves is that “No Big Design Up Front” depends a lot on your definition of “Design.” I posit that by aligning ourselves outside the iteration as BAs do, we can find some space to do the design we need to.\n
- So we need to change our relationship with Agile, and that means getting some traction in a discipline that already has a mature understanding of itself. Fortunately I have several methods of doing that, grouped into families of strategies that as UX people we should be highly proficient in.\n
- So what we can do is take the tools that we need to use, and lie about their names so that they get framed in terms Agile PMs will understand and buy into.\n
- Where we can cheat is to lean on Agile to get unexpected benefits from existing entrenched strategies and patterns.\n
- BAs are running parallel discovery processes to the ones we need to run. We can leverage this to speed up our own process, streamline stakeholder involvement and improve the UX-compatibility of the resulting dev-ready stories.\n
- So here are the BA’s high-level tasks and the corresponding UX tasks. Oooh! I see a synergy! It’s not a direct mapping but you can see how BA outcomes can feed into UX processes and how UX outcomes can support BA processes.\n
- We can even steal existing Agile methods from other areas of the cycle and reform them into patterns that serve our needs.\n
- This isn’t the only strategy for dealing with UX debt – you have to work out what works best for you and your team. You could also work one day a week on UX debt, or (if you hate yourself) use the last iteration as a stability rush. Other suggestions for what might constitute UX debt - Legacy Browser Support, or CSS3 enhancements; give example of MW SecondaryAction buttons\n
- Stubbed design means that forthcoming requirements don’t need to hold up development in the present. Maybe you have an ugly but functional flow that you can add with minimal branding. Or maybe you have the visual design roughly set but the behaviour is still being refined. Get it to a form where it can be included - maybe that’s just a static image - and get it in there\n
- Flag your stubs so stakeholders in demos clearly know what’s functional and/or final and what isn’t.\nWe use a class to put the stubbed element into pos:rel so that the specificity required to override it is very low - this way we don’t mess with any prior-positioned elements. Also you can set the nodeploy folder in SVN not to be deployed on releases, so even if the stub class stays in the doc, the image won’t be, and no-one with a life will be any the wiser.\n
- But we can’t simply map bottom-up methods onto a top-down strategy. We have to rethink the way we do our own jobs to fit into - not onto - the iterative world. The question here boils down to, what’s the most efficient way we can communicate user needs with developers working in iterations?\n
- \n\n
- This is the Photoshop Etiquette Manifesto, it’s intended to implement standards to make it easier for developers to understand work passed to them by UI designers, but following these guidelines will also make our deliverables more organised and hopefully easier to change. They can be applied to just about any design tool, not just PS.\n\n
- Change is a fact of life in software products. So polished, perfect PSDs where it takes days to change something small but site-wide are not the way forward. We need to be able to apply the principles of refactoring to the artefacts we produce.\n
- And anyway, a PSD is a bad mapping for the way we build sites now - often independent modules on a canvas, rather than discrete whole pages. The question that all this begs is, do we need a new tool that handles these requirements for deliverables, or do we need a new process that augments or replaces deliverables to meet these requirements?\n
- Here are a couple of people thinking about the same question. Hanna Donovan’s presentation about the shark is very telling - can you get as much insight about the character of your latest product from a couple of wireframes as you can from just these few views of the shark?\n
- Jan Srutek’s thinking about deliverables as well. I love his idea of turning our UX skills inwards on the profession, I think he’s spot-on here. If we present our deliverables differently, we can make them do more with less work.\n
- Project Meteor wants a new tool to address the state of the web as it is now. Adobe Muse is one of the suggestions they have. Whatever the solution, it’s going to need to support web fonts. The Photoshop plugin is a start, but only a start: http://www.extensis.com/en/webfontplugin/\n
- We don’t want to be bound by the iteration, but we need to keep up with the pace of delivery. Noodling back and forth on features that are imperfect but shippable will hold the whole team up. Use the tools I’ve given you to work around imperfections without slowing the pace.\n
- Agile wants metrics, and automated processes are great because they deliver great wodges of metrics constantly. Human processes are messy and hard to quantify, but user metrics are the only way to elevate user testing to the same importance as green/red builds. Stay with the product during UAT, to be sure the feedback is user-centric as well as business-centric.\n
- I don’t hate developers! I want everyone to make themselves approachable, because no matter how perfect your deliverables there are going to be grey areas needing clarification. The more you can work out in discussion, the less work your deliverables will need to do, and the more understanding the devs will take forward. Although it may feel like a lot of work initially, this is actually a virtuous circle.\n
- Don’t be like the creative director I knew who put his scary face up at 9:30 on Monday morning and took it back down at 4:30 on Friday afternoon. And make sure you communicate this stuff to the devs, so they understand you’re not being spiky, and you will make time for them asap.\n
- Agile, as a discipline, is 10 years old this year. It’s rapidly becoming THE way that software is built. It’s not going to stop and wait for us to catch up, and it’s going to keep innovating and keep making the process leaner. We can try and keep bending our existing tools and processes around Agile, and watch as the theory and practice become ever more divergent, or we can start running to catch up. I believe we can get it right, and we should get it right, because...\n
- ...this is what happens if we get it right. For the 100th anniversary of the Wright Brothers’ first flight, Scrapheap Challenge and its US cousin Junkyard Wars gave two teams 20 hours to build working planes from a junkheap. Both teams succeeded and both their planes were FAA-certified. Agile can build amazing things quickly as well. And I want us all to build amazing things.\n
- Thanks for listening. This talk is the starting point for a dialogue and I hope you’ll help me expand, refine and apply these and other techniques to make UX and Agile work together better. Please get in contact if you think we can.\n