When you are working within a product team that works by the means of scrum, you as a designer are presented with countless problems to fix, one after another. And it’s even worse when you’re just starting out. You are presented with a shitload of methodologies, workflows, frameworks, canvas this and canvas that. But there is not a single place that I know of, that tells you how these brilliant tools actually fit together.
So it seemed only logical to dive in myself. Like others, I graduated and took some knowledge with me. The Double Diamond model, a beautiful Kanban board and of course the pocket edition of Eric Ries’s Lean Startup.
But then you hit your first job. And Kanban isn’t the same as Scrum. Everyone has interpreted Eric Ries’s brilliance in their own way and no one has ever seen the Double Diamond model before, let alone understand the methods that you are trying to pursue.
After years in the field it has come to my attention that I have spend countless of jobs redefining how my methods, knowledge and tools actually fit together with every new project and client. And even though it has proven itself valuable to keep realigning with my surroundings, I felt there was room for some improved guidance. A simple workflow to fall back to, for new and veteran designers alike.
“The problem lies with the waterfall nature of our beloved Double Diamond model.”
The problem lies with the waterfall nature of our beloved Double Diamond model. It is designed to be simple, you follow four phases to assess a problem in order to come up with the best solutions. But like I said, we are not facing one solution, we face multiple. And the linearity of our model makes it hard for us to follow during our sprints.
This is where we need to stitch things together. By making clear how the Double Diamond model fits this continuous workflow I have created a model of my own that we can reflect upon. A simple reference to help us clarify whether we are still on track.
In order to create this overview I took the Scrum methodology, the Double Diamond model, our methods and our ever expanding tools apart, and mapped them out in a single reference. I call it: the ux sprint. It’s neither a framework, or canvas. It’s a little bit of both.
When we first look at this template it may feel both complex and familiar. so in order for us to properly understand its use, let us take it apart and start with the centre.
This is the sprint (scrum) workflow as you know it, it consists of four parts. The planning, development, learning and review.
This is where you and your team come together to allocate points to user stories prioritised by the Product Owner.
This is where the team works on completing said user stories, which are usually tracked using a Kanban board (to do, doing, ready for review, done).
This is where you and your team find obstacles that were unexpected, these obstacles are used to refine or create new user stories.
This is where you and your team come together to reflect on how the sprint went and which parts of working together you would like to improve. I motivate my teams to also include knowledge sharing here.
Now that we have a common understanding of how a sprint works, let’s move to the next circle and see how the different phases of the Double Diamond model add to the workflow of the team.
This is the Double Diamond, but not as you know it. The initial model has a start and end, which would prove logical of you are only solving a single problem. You enter the discover phase and at the end one or multiple solutions come out.
When working in a continuous work environment it is essential to plan your work from each phase into the sprint. This could mean you start with planning three discover stories in your first sprint. And implement stories related to the other phases as you progress with your cases.
The hardest part is keeping a clear overview of which problems you are trying to solve. Make sure to talk with your Product Owner a lot, he is (supposed to be) the one with the vision of the product. And you help him focus on the most important parts of making his product user friendly and valuable.
“The key ingredient here is understanding that the Double Diamond model is not a linear process.”
Each sprint you will get feedback and new insights through your team members, which will create new cases for you to research. The key ingredient here is understanding that the Double Diamond model is not a linear process. You can take out the methods and tools used in each phase to solve different situations.
The only thing that stays the same is that whenever a new problem shows itself, you use your discover methods to come to an understanding of the scenario, which could result in new user stories for you and your team to work on.
Now this concludes that the design process is messy, which is fine. Make sure you learn to adapt and adjust because the vision of your product may change at any given moment. And since this is the case let the UX sprint help you maintain an overview of the steps you can take to solve a new problem.
In addition, I have added room to adjust the model to include your own methods and tools. Let’s have a look at how I mapped out these methods that I prefer to use during the discovery phase.
This is both the easy and the key part of our model, this gives you the handles to reflect on your work process. The idea is to fill out the whole map and share it with your team, talk them through it. This will give proper insight in how complex our work can become and which methods you will be using to develop the best product in the world.
Feel free to download and share this as much as you like, with anyone, anywhere. If you improve the model, have feedback or want to discuss something, drop me a message, write a response or keep clapping this article until my head pops off.
Every once in a while I will share my experiences as a developing User Experience professional. If you are interested in reading some more of my work, head on over to my articles here. Thanks for reading 😁
I’d like to give special thanks to some of my dear friends and colleagues who help me proof read my articles. Renée Schipper, Jeffrey vd Dungen Bille, Wessel Grift & Giorgio Lefeber, you guys are the best! ❤️