Bring value to your design work in every development sprint
Research and ideation phases should become deliverables
Highlighting the value of design work is always an ongoing discussion among designers and product teams: how to measure the impact of design decisions, why idea A was chosen over idea B, why did it take so long to start implementing project C, and so on... Well, one simple way the designer can help organise this confusion is to be more transparent about the design process. And how do we do that?
We can transform design tasks that are often “hidden” on backstage into deliverables that everyone can understand. The time has come to finally open the curtains and display the design process to everyone. And our main stage should be the development sprint — where all eyes are focused everyday, every week, every sprint.
What’s a development sprint?
In an earlier publication, I summarised what a development sprint is: a short period of time (1–2 weeks) containing all main stages of product development, from ideation to user testing. For a more precise description, Scrum.org refers to it as:
[…] a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.
At AB Tasty we currently follow a development cycle of 6 weeks, encompassed by 3 sprints of 2 weeks. The main objective for each and every team is to deliver something valuable for the end-customer at the end of each 6 weeks cycle.
The designer’s challenge
In a perfect world, the design work is done and ready for implementation before the development sprint starts. This means that, if everything runs as planned, the design work is always ahead of the implementation phase.
By working ahead of the development sprint, designers can have time to frame the problem and validate the solution with the right specifications. This way, the product manager and developers are able to estimate the tasks, document the project, plan the sprint and prepare all the communication material around that specific release.
Nevertheless a huge amount of these tasks are not “visible” or “actionable” and yet they consume a great part of the designer’s day-to-day workload, and that’s why is important to show them as visible steps in the development sprint.
This is how we do it
Here are two quick examples of how I am working with my team. We use Jira to manage our 2-week sprints and the main goal, as designer, is to drag the design activities to “Done” at the end of the sprint — exactly the same a developer does with their implementation tasks.
However, we should note that the cards won’t probably go through all the existing steps in the sprint board because these steps were created having the development process in mind. Depending on how your team organized them, you should drag and drop your activity through the steps that make more sense to you — or you can customize the steps on your board with your team in order to accommodate both development and design tasks.
Example #1: Design Sprint preparation
As you can see in the image above, the first card on the left is entitled “Design Sprint”. One of my goals for that sprint was to facilitate a 2-day design sprint session with my team (I already wrote an article about this 2-day approach).
Before you start the Design Sprint session, it requires preparation. So this card was very useful to gather all important information before the session started, including the description of the project, the list of participants with their dedicated roles, materials and tools required for the session, the calendar of activities, links for the slides presentation, slack channel and other resources that would be important for the day of the Design Sprint. This way, all participants were in the loop of the project and they knew exactly what to expect, how to prepare for the session and what they needed to bring beforehand.
Example #2: User testing results
Another very useful example on how to deliver design value during a development sprint is to disclose the process of user testing and its results. You can present the script and the methodology you used for the interviews, the links to the prototypes/solution you tested, the participants information and, of course, your findings — and possible next steps.
A nice bonus is that Jira has integrations with tools such as Zeplin and Invision, which provides nice embedded previews of your prototypes inside the ticket, making it even easier to scan the content and to understand the project.
Takeaways
Communicating and displaying the impact of design as process is an asset not only for the team, but for the whole company. Why?
✅ The team is in the loop of the upcoming projects;
✅ We can track the time for each research or ideation processes of a given project, thanks to the logs in Jira;
✅ Better overview of the project lifecycle and easier source for documentation (research findings, benchmarking, design specs, etc);
✅ Making all this info accessible might help other teams that are working on similar projects (or that are affected by it);
✅ It gives visibility to the design work, usually done against the backdrop!
Plus, the advantage of using Jira is that you can link all your design activities to their dedicated projects epics and development tasks, so everyone in the team is aware of the workflow of your project as much as the design decisions behind it.
I hope you enjoyed some of my tips and let me know if you have any other ideas to share. Keep up the good work and stay safe ❤️
