Agile UX How to do Design Up Front when you’re not allowed to do Big Design Up Front [email protected] http://sparrk.tumblr.com a s s h o w n a t 

Can I have some hands 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 

The Five Minute Introduction To Agile 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... 

The Five Minute Introduction To Agile By Way Of Analogy To Popular TV Shows ...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. 

High Level Requirements 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. Which is a bit like the initial challenge conditions for Scrapheap Challenge. 

Team of Generalists Specialists with Domain Knowledge 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. Which 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. 

Plan Your Build Strategically Not Worrying About The Details 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. Which 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. 

Start Building As Soon As You Know Enough To Get Started 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. Which 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. 

You Know The Release Date You Fit The Feature Set To It 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. This 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. 

You Aim To Build Only As Much As The Requirements Demand 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. Which is a bit like the way Scrapheap Challenge teams don’t mess about with extraneous features that don’t help them meet the challenge. 

You Build Something Releaseable And Enhance As Time Allows 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. Which 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. 

Change Happens And You Adapt To It 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. Which 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. 

The Lightweight Option Always Beats The Heavily Engineered One 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. Which is a bit like the way the teams in Scrapheap Challenge always conveniently split along lightweight/heavyweight lines. And the lightweight one usually wins. 

You Can Do Well Or Badly Depending On How You Adapt 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. Which 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. 

And Then You Iterate 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. 

It’s Surprisingly Easy To Bugger It Up 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. 

The Iteration or Sprint 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? 

i1 i2 i3 i4 i5 A Release* *One project may have many releases And they are not necessarily public releases Often they are more like internal milestones 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. 

THIS NEVER WORKS i1 i2 i3 i4 i5 Design for i1 Design for i2 Design for i3 Design for i4 Design for i5 Have a fucking party 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. 

Agile’s Dirty Secret: Planning ~= Design Gather Requirements Analyse Requirements Write Epics Scope R1 Plan R1 Write Stories 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. 

Methodologies For Rethinking Our Relationship With Agile ✦Lie ✦Cheat ✦Steal ✦Do Some Work 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. 

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 ✦ UX Principles == Agile Cross-Cutting Requirements 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. 

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 ✦ Co-opt the Fail Fast pattern to get traction for user testing Where we can cheat is to lean on Agile to get unexpected benefits from existing entrenched strategies and patterns. 

The BA Is Your Best Friend ✦ 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 - for “free” out of the analysis process 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. 

Gather Requirements Analyse Requirements Write Epics Scope R1 Plan R1 Write Stories Identify UX Requirements Wireframe Epics Begin site design language Hi-Fi i1 of R1 Wireframe Stories Begin broad IA (to feed into Epics) 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. 

Steal ✦ Technical Debt ✦ Stubbed/Mocked Interfaces ✦ Behaviour Driven Design/Test Driven Design We can even steal existing Agile methods from other areas of the cycle and reform them into patterns that serve our needs. 

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 zero or UAT are good times 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 

Stubbed/Mocked Designs ✦ 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 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 

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;} Flag your stubs so stakeholders in demos clearly know what’s functional and/or final and what isn’t. We 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. 

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 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? 

Prepare to Refactor ✦ Organise your files to prepare for change 

Prepare to Refactor ✦ Organise your files to prepare for change http://photoshopetiquette.com/ 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. 

Prepare to Refactor ✦ Organise your files to prepare for change ✦ 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 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. 

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 and modularity ✦ HTML prototypes are too low on discoverability for this 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? 

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-donovan- telling-stories-through-design/ ✦ @han 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? 

Jan Srutek http://www.slideshare.net/JanSru/communicating-and- selling-ux-design-deliverables 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. 

Project Meteor http://projectmeteor.org/ 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/ 

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 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. 

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. 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. 

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” 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. 

Continuous Availability Strategies ✦ The Sacrificial Lamb – when there are >1 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! 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. 

Agile Won’t Wait http://www.flickr.com/photos/uriel1998/ 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... 

Now go and build incredible things. ...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. 

Thank You http://sparrk.tumblr.com [email protected] 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.