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 lot 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.
“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.
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 where 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.
2. The Double Diamond Model
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.