How to make your design process agile
•Download as PPTX, PDF•
2 likes•465 views
You know you need a great user experience, but you're on a deadline. Can you have good design at speed? Running a design sprint allows teams to utilise the best parts of agile, design thinking and 'gamestorming'. This talk will go over how to run a sprint successfully, with advice on pitfalls, breaking down departmental silos and how to adapt the process to fit your team.
Recommended
Recommended
More Related Content
What's hot
What's hot (19)
Viewers also liked
Similar to How to make your design process agile
Similar to How to make your design process agile (20)
More from Joanna Franchetti
Recently uploaded
Recently uploaded (20)
How to make your design process agile
- 1. Jo Franchetti Frontend engineer at Ticketmaster Swing dancer and cake pusher @thisisjofrank DESIGN AGILE
- 3. GET EVERYONE INVOLVED The more people who are ideating, the more problems you’re going to solve up front
- 4. “User experience is no longer just the remit of designers, we are all striving for a great user experience, regardless of what our role is exactly” @lily_dart https://youtu.be/gharV9h-lzg
- 5. RUN A DESIGN SPRINT a structured brainstorm based on design thinking
- 6. Google Ventures Design Sprint - 5 Day Recipe PrototypeSketchUnpack Decide Test
- 7. PREPARE ➜Choose a problem ➜Gather your team ➜Clear your calendars and make a deadline ➜Schedule a user study before you start the sprint ➜Book a room
- 8. STEP 1. UNPACK set the scope for the sprint
- 9. STEP 1. UNPACK set the scope for the sprint
- 10. STEP 2. SKETCH get solutions down on paper
- 11. STEP 3. DECIDE converge on a solution
- 13. STEP 5. TEST find out what to do next
- 14. WHAT NEXT?
- 15. LEARN FROM OUR MISTAKES Get everyone invested in and comfortable with the Design Sprint process Have someone in the room who understands the business side of the product Appoint someone to keep the team on track and to deadline Discuss the results of the testing Test your AV
Editor's Notes
- So, before I get started, just a quick introduction, My name is Jo I’m a front end developer at ticketmaster, I’ve been in FE for about 5 years now. I’ve worked on a wide range of teams both in house and for agencies but every place I’ve worked, we’ve had the same problem, the handover of designs never goes smoothly. Getting the right balance of communication between the designers, UX, and developers is really tricky. In most of the teams I’ve worked on, design and dev are separate and finished designs get handed over to the developers to code up. And many times, as a developer you have those WTF moments. like what was the designer thinking?! This is going to take months to build! We get frustrated that designers often don’t think like a developer, and designers get frustrated when we don’t fully adhere to their designs, I know I am certainly guilty of rounding down the odd 11px margins… So what we want is a way of including the designers in our agile way of working. I realise that I may be preaching to the converted here, agile design is becoming more and more accepted, so apologies if you’re already running with this my hope is to spread the word for those teams who are still struggling with a waterfall design approach.
- Designers traditionally work separately from developers. They do their research, preform idation and then finalise a design. It is this finalised design that gets handed over, the developers don’t tend get included in their iteration towards this finished piece I’d call this an ‘over the wall approach’ The two teams are separate, there is little to no feedback and flaws or bad UX patterns only tend to show themselves once the build has started Whereas as developers, we’ve learnt use the agile approach, it allows us to deliver software quickly and to handle changes smoothly. Much of the Agile Manifesto is fundamentally relevant to designers. Interactions above processes Collaboration above negotiation. Feedback, improvement. All things that designers want While designers and developers look at the world from different viewpoints, There are still ways to fit quality design work into an Agile process. So how do we achieve this?
- So, step one Get more people involved with the ideation, this needn’t just be the remit of your designers/UX. Before you even start to think about designing, get as many people as possible generating ideas. The more people you have on idea generation, the more ideas you’ll generate, obvious hu? Not only that, the more diverse the group, the more likely you are to think up potential problems and solutions,. the more perspectives you have on a problem, the easier your development will go later on. Lily Dart made an excellent point in her talk at last year’s epic FEL where she said
- ‘User experience is no longer just the remit of designers, we are all striving for a great user experience, regardless of what our role is exactly’ I've linked to the video of her talk there, I highly recommend giving it a watch! Make sure you’ve a wide range of interests, experience and expertise in your ideation team and then you’re ready to move, so how do we actually go about making design more agile?
- Well at Ticketmaster we recently implemented the ‘Design Sprint’ , which has been working pretty well for us. A design sprint is a fast and structured way of developing ideas Each ‘sprint’ focuses on a specific design challenge, an idea or a problem. And because ‘sprinting’ is so quick, the team can explore a range of ideas in a relatively short space of time. At Ticketmaster we’ve run a fair number of design sprints now, and honestly, at first we made a lot of mistakes, but we’re getting pretty good at them now, so I wanted to share what we've learnt and how we’ve developed our own processes
- Our design sprints are heavily inspired by the Google Ventures Design Sprint recipe, which i’ll link to at the end of the talk We follow their template pretty closely. They split the design sprint into 5 stages Unpack, sketch, decide, prototype, test and the stages are spread over five days, Each day focuses on a different set of techniques and aims, with a view to getting a tested prototype out at the end. But, before we talk about the stages, there are some things you’ll need to prepare before you start your sprint.
- Firstly, be clear on what it is that you’re going to be working on. What is the problem you’re fixing? Are you making a product, a feature or a solution? I imagine most people here won’t find it difficult to think of some part of their projects that needs improvement, or that they’re struggling to make progress on. It could be something big like defining a product for the first time, or a redesign, or it could be something smaller like a new module or feature. Secondly, as I said before, get people involved, Ideally your sprint team will be between four and eight people, make sure you have at least one: Designer Product manager Someone who knows your users. Anyone with direct contact with your customers would be great, as they tend to have things to input from the start Stakeholder - if your stakeholder can’t give you a whole week then try to bring them in at key decision-making moments. It’s also great if you can include: Engineer, Marketer, Anybody else who’s interested and keen thirdly, It might seem obvious, but make sure that everyone involved in the design sprint is able to actually be there, as in they have the time booked out, they’re not going to be interrupted or have to leave the process half way. Breaking focus can really ruin the creative process, and if someone misses a day, it can waste time getting them caught up. 4. Schedule your user testing in advance Once you know the dates for your sprint, recruit users and schedule the user testing You don’t want to be trying to organise this while you’re sprinting, and people can be hard to tie down last minute. 5. Book a dedicated room for the duration of the sprint You’ll need a room with whiteboards and wallspace to fill with ideas and preferably with space and natural light, cos you’re going to be in there for a week! 6. Have the right tools You’ll need: Post-its Pens/pencils Whiteboards and markers blank paper: Timer Blu tac Snacks and caffeine are optional (in some opinions), so provide these if you want and finally get as much relevant data as you can Google Analytics, User research, competitor review, anything you can think of, if you’re worried that you don’t have enough data then maybe schedule a few user studies or deploy a very short survey with questions related to the problem you’re going to tackle in the sprint, So, now you’re ready to start sprinting
- Day one is spent getting everyone in the room on the same page This is called the unpack phase you bring everyone together and “unpack” all of the knowledge of the problem within the team. This will likely take the form of - An outline of the problem and the business opportunity it presents - this will usually given by a stakeholder or product owner A presentation of the results of competitor analysis A review of user personas Review of any analytical data available It is really important to involve the whole team in the unpack stage. Don’t let an individual or group dominate proceedings, try not to let people go unheard. Once you’re ‘unpacked’ you’ll want to use your common understanding to collaboratively define the ‘user stories’ So, we tend to think of our user stories as ‘what does the customer want from the product/service’ and ‘what do the stakeholders want from the product/service’. Your answer will usually take the form of a flow chart.
- So for example, at Ticketmaster, while sprinting for an ‘artist page’, which, unsurprisingly, is a page with artist details on we might have a User Needs flow chart that goes - ‘land on page, see artist name and photo, see show locations and find show dates, buy ticket, and then of secondary importance they might want to - read/watch artist bio find similar artists, sign up for offers and as far as the stakeholders are concerned, they want to make sure that the user sees the most adverts possible and then goes on to buy a ticket, and of secondary importance, signs up for offers We can use these two flows to organise the modules on the page, you can already start to see a plan for the page coming together. The user stories need not directly impact the layout of a page, it could be the steps a user needs to take to use your product or feature This step can be difficult, but it’s critical! Getting a flow diagram on the wall (like the one above) is invaluable for grounding the discussion and keeping everyone on the same page.
- So, the second day is sketch day. The point of this day is to get as many solutions as possible down on paper. Looking at your flowchart from yesterday, break up the project into sensible chunks and start coming up with ideas for how to bring them to life We use a process called ‘Crazy 8’s to get the ideas flowing. Everyone is given a piece of paper folded into 8 They then have 5 minutes to fill every slot with a sketch. Thats 40 seconds each, so you’re not going to have time to go into too much detail, and it doesn’t matter if an idea isn’t going anywhere, abandon it, start another. this method ensures maximum number of variations with minimum time wasted on groupthink or discussions. Once the 5 minutes is up, everyone sticks their designs on the wall, briefly talks through each one and then we have a vote on the ones we think are best by putting a mark against that square people can vote for their own designs and we tend to limit the number of votes a person can have to three, but you don’t have to. If there is an obvious winning idea then this can be taken to the next stage, if not then run another round of crazy 8s, developing on the ideas that got the most votes. If people are struggling with ideas then try breaking up what you’re designing into smaller components, or running a brainstorm before the crazy 8s I love this technique because it highlights how wide the spread of good ideas is, they don’t always come from the designer, this is also a really great way to get people feeling ownership of the product.
- By day 3 you’ve gone from having 99problems to potentially having 99 solutions and you’re going to need to narrow them down. You’ll need to review each idea with an objective in mind. Will you be looking to take a single great idea forward to prototyping ? or are you going to pick say a Top 5 and take them all forward and find out which idea the users like best? You should be looking to constantly refine your list and remove ideas that simply aren’t feasible. the last part of Decide Day is to create some storyboards for your ideas. This is a step by step breakdown of the user interaction and will become your specification for your prototype. You’ll also want to start thinking about what you need to get out of the user testing, what are your theories about the interactions you’re designing? Are you making any assumptions about the interactions, or users, or available technology? How will you measure whether the prototype was a success or not? Also, make sure to double check that you’ve got your testers ready for testing day. If you’re finding it difficult to find testers, then look internally, anyone who isn’t directly involved in the prototyping can test it, and would give you useful feedback.
- So, hopefully by the end of day 3 you’ll have what is essentially a specification for a prototype. As a team you need to decide how that prototype will be made, this will heavily depend on the resources you have available You’ll need to decide if you’re going to code it or if you’re going to use something like keynote or invision, or dare i say it, even powerpoint In its simplest form, a prototype is anything a person can look at and respond to, it doesn’t have to be complex in order to learn what you need from testing, and it certainly doesn’t need to be pixel perfect. Make it minimally real, as low fi as you can get away with, it could even be a wireframe. You’ll be amazed at how much real feedback a user can give you on a slide deck of mockups, as long as they are able to interact with something you’ll get insights into what they understand and what they don’t understand about your product/whatever and they’ll be able to tell you what they’d expect to see or do. ‘I’d click here, or look there for such and such’. One important point when building your prototype is to use real copy, don’t fill it with ipsum, you need to see if your users understand your instructions and you’ll learn about the constraints of your layout, will that text fit in that button/area/etc? The google ventures blog has loads of great advice on building prototypes, and i’ll put a link to that at the end. Also on day 4, whoever is running the user testing will want to be considering their testing script too, look back at the assumptions and theories that you wrote down in step 3, how are you going to make sure that your user is going to give you the data you need? Writing good testing scripts is difficult, and honestly the topic for an entire other talk, so i'm not going to talk about it here, but, again, i’ll include some resources at the end.
- Before you begin user testing make sure that your interviewer is comfortable with the prototypes and with the plan of action for testing Correctly set up and or double check your testing suite, especially the AV, it can go wrong at unexpected times and you need to make sure that you’re recording and able to listen in on the testing While you’re testing, as many people as possible who will be involved in the production of the piece should watch the tests happen, watching real humans use your product is a great way to improve your understanding of UX what you’re aiming to get out of Test Day is a list of ways that you can improve your prototype, you should also ask your testers about what they think of your product as a whole, which competitors they use and why. Try to think beyond just the prototype you’re testing Record your findings in a useful way, you could use spreadsheet, whiteboard, or trello board or whatever you want, get everyone who is watching to record their own opinions of the tests then compare notes and draw your conclusions from there
- We tend to run our design sprints two sprints ahead of our dev sprints so that we have time to revise the prototype, the designer has time to take the prototype to high fidelity, and we have time to plan the build. Design sprints can come out with mixed results, sometimes the reports are glowing, sometimes they’re less so, you’re not going to hit the nail on the head every time So you need to look at the results of your tests and decide what to do next, if Most of the stuff worked - Tune your existing prototype and get ready to sprint as you usually would It was well liked but there are still some questions to answer - Build on what you have, learn from your testing results, tweak your prototype and test again. If you need to, break it down and test individual features Everyone hated it, This is ok, at least you learnt something, it only took a day to build, and now you have a lot of feedback from testing to help you to try again. Imagine if you’d taken that idea into production? this is what this whole process is for, to avoid you spending time and money developing the wrong idea!
- Introducing the design sprint into our process wasn’t an entirely smooth transition, we got, and I’m sad to say this, a lot of opposition from the design and UX teams who believed that as the experts, the rest of the team should be deferring to them we’re still in the process of bringing them round, but i think that we’ve all noticed the improvement to the workflow, and there are much fewer *ahem* heated discussions *ahem* during the build As far as possible keep everyone invested in the process, keep the team positive and make sure that everyone’s voice is being heard, don’t let one person dominate the proceedings * Make sure that you’ve got a stakeholder or someone who knows the business well in the room or you could end up with something entirely tangential to what the product needs, if you can’t get them for the full week, book out checkins with them at the end or beginning of each day. * try to be rigorous about keeping the sprint on track, don’t let people get bogged down in a particular idea, and make sure that you’re not going to miss each day’s deadlines * Talk about your testing results, the first time we ran a design sprint, one person ran the tests and fed the results back to us, which lead to somewhat biased account of what had occurred, get everyone watching the test and recording their own views, then discuss your findings and plan actions accordingly * Finally - Double check the setup of your testing suite, we’ve wasted precious time on faulty microphones/cameras/internet connections etc, pissing off your testers is not the best way to get accurate results from them In finishing all i can say is, if you’re suffering from handover woes, or need a way to inject new energy into your ideation process or need help defining your UI, just give this a try. Running a design sprint has made a massive difference to our design handovers, having engineers and designers work that closely together makes the build itself much smoother, and you catch so many potential issues right up front. It has allowed us to quickly make tested prototypes, a process that is already showing improvements in our user engagement And finally, they’re a great way to get the entire team onboard with and proud of an idea
- A message from Shia
- I'm running an event with Ticketmaster on the 24th March called Achieving Diversity in the Tech Industry. You can find us at www.achievingdiversityin.tech and @talk_diversity Our first event will be a showing of ‘Debugging the Gender Gap’ and then will run monthly with talks on how we can work to improve diversity in our industry. If you'd like to come along, there is a link to sign up for an invite on the site, if you're interested in speaking or getting involved some other way please drop us an email or a tweet!