Many development teams are now working in some form of agile—be it Scrum, Kanban, or another form of agile that a team has adapted to their own needs. Thus, most teams organize their work in sprints. Sprints start with planning and end with reviewing the goals that you’ve accomplished and the process you’ve followed. However, because many UX designers think agile methodologies are primarily for developers, they face the problem of not knowing exactly where their work fits into the development process.
In trying to solve this problem, Google Ventures created the idea of design sprints. During a process that usually lasts just one week, a team considers the problems, ideates a solution, tries it out, and learns from the experience. Ideally, all members of a product team participate in the design process. Leaving individual members or disciplines out of the product team can lead to miscommunication and barriers in the path of future implementation.
Champion Advertisement
Continue Reading…
Design Sprints Versus Development Sprints
In a nutshell, design sprints go like this: On Monday, the team considers the problem and highlights key user stories. On Tuesday, they sketch solutions. On Wednesday, they select design ideas. On Thursday, they turn the ideas they’ve selected turned into a high-fidelity prototype. On Friday, they test the prototype with real users, using realistic scenarios, and consider their findings. Certainly, following this process week after week at the beginning of a design process could be exhausting. It requires the time of many people in the organization who might not always be available.
Plus, you may have already spotted an issue: design sprints last a week, while the sprints in Scrum usually last between two and four weeks. How can you work within that reality? First and foremost, you should work only in ways that fit your team and your goals. Every team has different needs, and every project somehow alters those needs. In synchronizing design and development sprints, you must ensure that, when the developers end a sprint—for example, at the end of week 2—designers do, too, at the end of their weekly sprint. That way, the designers won’t have to slow down their work to match the developers’ sprints, and the developers won’t have to wait half a week for a design to be ready for implementation.
For design sprints to be effective, they must have certain characteristics. For example, the entire organization must be committed to participating in the design process, and teams must schedule a design meeting at the beginning of each week to reflect on their previous findings and plan their next steps—such as what the designer will deliver and when the team will test it.
Issues with the Google Ventures Design Sprint
However, in looking at Google Ventures design sprint, there are some questions worth considering: Why is there is no upfront investigation or early user participation, but rather ideation that is limited just to team members? How can you target the right users and determine what points to focus on rather than basing design decision entirely on the assumptions of your team members? Google Ventures’s solution is to conduct user interviews before starting a sprint, but if one sprint finishes on a Friday and the next one starts the following Monday, how can you accommodate that work before the next sprint?
Where does the developers’ work come into it? Of course, your design and development sprints could happen simultaneously, with the development team working on implementing a solution only once the designers have finished their sprint and have moved on to working on something else. However, what if the team discovers additional problems later on or needs to make further design refinements, requiring the attention of a designer who is now working on something else? What if the team discovers, by the end of the week, that the design they proposed during the previous sprint is useless? In this case, your development team would be blocked by the lack of a design that they can implement. Rather than your designers’ completing their design work before your developers can do their work, couldn’t you design with them?
To address these questions, I propose some revisions the five-day design sprint.
Revisiting Design Sprints: Day by Day
Let’s consider what happens on each day of a week-long design sprint.
Monday
This is the day on which you define your questions. Last Friday, you interviewed your users and came to some conclusions based on your learnings. Today, you’ll discuss your findings with the team. Development, User Experience, and Product Management reflect on the current state and on the deliverable you’ll complete by the end of this week. Are your objectives in line with those of the business? Is your design feasible to build?
Rather than using your morning design meeting to consider what problems you should attack, this meeting now focuses on answering the question: Which users are currently experiencing these problems? As soon as this is clear, go out and determine whether the intended users are actually encountering this problem. Quickly interview these users. If they are not having the problem you are expecting, inquire about the problems they are having. (It is helpful to have a ready-made list of the priorities your team is considering so you can easily inquire about them.) Try to schedule some quick usability-testing sessions for Friday. Report the users’ responses to the team, letting them know whether you need to discard the current plan because there are new problems that you should tackle this week instead.
You won’t be able to repeat your design meeting the next day because doing so would disrupt the cadence of your sprint. Confirm that the team agrees on the user stories to address. If the problem you’ve defined is too large for a one-week sprint, you might want to chunk it and prioritize certain parts, then work on the others during the following sprints. Think about which are your highest-risk, highest-reward features, and define a minimum viable product (MVP). The important point to address on Monday is defining what problems to work on for the remainder of the week. Whether that means confirming your hypothesis or completely changing it, you have achieved your purpose for today.
Tuesday
Ideate, ideate, ideate. Once you’ve defined and verified the problems that your users are encountering and written your requirements and user stories to address them, discuss possible solutions. Do some affinity diagramming, ask yourself some How might we...? questions, and engage in brainstorming or any other activity that you choose. If possible, let your developers and product managers have a say in ideation. Do not design for them. Let them design with you.
Spend the morning on your ideation process, sketching as many ideas as you can, then spend the afternoon reviewing the sketches and refining the solutions that seem to fit better. If you were not able to do this yesterday, verify the times for usability testing on Friday and confirm your participants.
Wednesday
On Wednesday morning, come back to work with a fresh mind and have a final round of conversations to decide on the best solution or solutions among the ideas you came up with yesterday—if you want to test more than one prototype on Friday. Now, your wireframing or prototyping process begins. If possible, work shoulder to shoulder with your front-end developer, so he can start implementing the design as you design it.
At this point, you might want to review your work and perhaps alter some of the solutions you came up with during previous sprints. If you run into bugs of any sort or realize that some of the features you previously worked on need some redesign, make yourself available to assist your developers in this redesign effort. Ideally, you have a style guide that you and your developers can leverage, which provides the building blocks you need to achieve a design that looks closer to the final product.
Thursday
Continue with your prototyping process. You should strive for just-good-enough design, in terms of both fidelity and functionality. Ensure that the prototype is testable. Keeping in mind that you’ll be testing tomorrow, don’t put any more stress on yourself than is absolutely necessary. Focus on creating just a complete MVP, in which everything you need to test can be tested.
Thursday afternoon is a good point at which to plan your usability-testing sessions that are to occur the next day. By Thursday, you should have already agreed on a time for each participant’s session. What are you going to test? What testing methods are you going to use? Based on the answers to these questions, you should have an idea of how long each testing session should take. It is always a good idea to let your participants know in advance whether the time you’ve estimated for completing their session might exceed that on which you agreed at the beginning of the week.
Friday
It is Friday, and today is testing day. A full day of usability-testing sessions can, indeed, be exhausting so, when you agreed on the time and structure for each testing session, you should have left some time free for breaks between sessions. In the afternoon, gather and analyze users’ feedback and put together a structured report to present during your retrospective on Monday.
Conclusion
Every team has a particular ecosystem in which they function optimally. They have their own specific methods and pace of working. So feel free to use or discard anything that I’ve described in this article, as appropriate to your teams’ needs. Include whatever suits your team best in your sprint process.
Perhaps you might find that Tuesday or Wednesday is the perfect time for storyboarding. Or you might not always be able to get your front-end developer to sit with you and build your prototype. Maybe you’ll find that Jeff Gothelf and Josh Seiden’s suggestion of testing on Thursday and doing planning on Friday is more appealing to your team. Ultimately, each of us needs to discover our own way of making our work more user centered and making our agile team more agile.
Gonzalo is an internationally experienced designer with a focus on UX design, user interface design, and digital art. He has experience in diverse domains, including ecommerce, Software as a Service (SaaS), and application development. His cultural and commercial experience has enabled him to acquire skills that pertain to all phases of project management, marketing, and production. Read More
