One of the most challenging times as a product builder, or in my case a designer, is knowing when to cut down your ideas to something focused, or to take something you really like and expand upon it. When you are developing a product, a good skill to have is being able to diverge your ideas and then converge back down on something you can move ahead with.
I found myself working on a project not too long ago where I was dealing with a rather simple premise. The problem we were trying to solve was straight cut and everyone on the team had a good understanding what to do next. We sat down and laid out plans to build the first part of the product, and then roll it out to market. Being such a simple idea, we breezed through that session.
However, what we didn’t know was that it a recipe for disaster! All of us on the team had built products before, but never one so easy. In our minds it gave us a prime chance to go and start diverging on the product’s original idea and start planning out what we should do next. Nothing too sinister, but we all forgot to do one thing: converge.
A bright and sunny Saturday rolled around, and we decided to head to the state library to have a change of environment. The other designer and I met up and we heard from the lead developer, he wouldn’t be able to make it last minute. Not to worry, we would push on anyway, and we went in and found a meeting room.
We quickly began running through our scope and laying out ideas and features that could enhance our product and make it something truly great. Ideas were thrown around the room left and right and many a post-it note was slammed onto the wall. We kept going down and down the rabbit hole of our ideas. Giving birth to a product that was truly unique and innovative right there in that meeting room. The air was electric with creativity and we began laying out plans on how all the parts of the system would interact with each other.
A few weeks later, when we had a chance to meet up with the lead developer again, we began spinning the tale of what the project had become. With that familiar glassy-eyed look that I’m sure most designers have become accustomed to see when telling their developers about their ideas, he sat in state of mild PTSD before realising the behemoth we had created was standing before him.
Thankfully, he was never one to shy away from a challenge and with a little bit of planning we began working on this truly horrifically sized product. It had gone from maybe a 2 or 3 week-long build to something we would need a good year investing in. But we loved the idea, so we were determined to get started.
After less than a week we all hit the wall hard. Realising just what we had set out to do. I stared at the design files for a good 30 minutes trying to work out what to do first, when I closed it down. The other designer spent all his time trying to get just the basics of everything up and running and burned out. Our developer, in true form, simply took the first piece of work and got it done; but for the other pair of us it seemed like this had gotten out of hand.
In our excitement and stupidity, we had diverged our idea and scope; but never actually converged it back down to something manageable. Sure, we had created a roadmap of what order we wanted to tackle it in, but it was still such a massive undertaking. We quickly learnt our lesson and after another catch-up we decided to gut everything back to our original plan: the simple product we hoped to build. The weight of trying to make this entire system work was gone and we could focus on the first part again.
What is diverging and converging?
When we talk about diverging and converging in scoping, we are referring to the different mindsets a team must have to successfully solve the problem. First, we diverge our ideas and go as wide as possible, then we must find a point of focus and converge back down to something small. This form of thinking is normally represented in the double diamonds. At the start of a project you begin with a single problem you are trying to solve. These statements are a jumping off point to get the team in the right mindset.
Taking that single problem, you start to diverge on it; coming up with new ideas and solutions based on what that is. It is here that your team is at its most creative. The sky is the limit with what can happen. Diverging from that first point is so important as it opens you up to innovation; a failure to do so creates products that can only be described as ‘fine.’ While fine might be good enough for you, is it enough for your users? For example, if a person came into your cafe and ask for breakfast and you brought out some plain buttered toast, they would leave having had breakfast, probably never to be seen again.
Compare that to if the same person came in, and you instead went back to the kitchen and told the chefs to come up with something to make sure that person came back everyone morning. I’m sure they would bring out some sweet blueberry stacked pancakes, delicious shakshuka or homemade granola with forest berries. The diner leaving happy to return again and again, and maybe even telling their friends about you.
The same lesson can be learnt from product design. Allowing your team to diverge on ideas lets you step into that new wild space of crazy breakfasts. With that said, you then must converge. Taking the best parts of those ideas and turning those into a focused target to test with so you can get the best results quickly. Else you will wind up in a situation like myself, with a beast of a product.
If those chefs brought out 20 dishes for the diner to eat instead of just one, I’m sure they would quickly get overwhelmed, burn out, and the diner would sit there for ages waiting to eat. Whilst you are in your most creative space in divergence, now it is the time be more analytical and work out the best way to execute that ideal solution you came up with.
Together, the pair of these mindsets and phases of the product scoping stage help teams come up with innovative and focused solutions. Part of the double diamond comes into play after you get your first solution from diverging. Going away, testing it out and making adjustments on how to make it better, before once again honing it down to being the best it could possibly be.
Out in the wild
Most teams or companies tend to favour one side of the diamond over the other. Whether it be by company culture, business values, or the type of people the team is comprised of. Some teams tend to be more prone to analytical thinking, when a problem arises, they jump right into problem solving mode and within a conversation will have an idea to start working on. While this favours speed greatly, it means more solutions are surface level ideas without any research to back them up, and they rarely take the users into account.
On the other side, some teams to tend to be more creative thinkers and spend most of their time tackling new problems by following every idea under the sun until one shines the brightest and they begin executing. While the swiftness may be lost, these ideas tend to be very well researched and thought out. Meaning they can arrive too late to solve problems users are having at the time.
It is important to remember both sides can work in certain environments, but neither can work as well as a team which considers both sides equally. Taking the time to move from mindset to mindset, valuing speed, but not at the cost of quality, is the solution that is needed.
Switching from one to the other
Being able to perform each mindset is one thing, being able to make the switch is much harder! Moving between the two is what we call in Design Thinking as ‘The Groan Zone’ as it normally frustrates many people involved. You are suddenly getting the team to go from creative to analytical and vice versa. Not only is making the switch hard, but knowing when to do so is another challenge
Steve Jobs was a master at getting his team across the Groan Zone, knowing when to focus in the creative efforts of a product, and when you expand outwards again. It is something that comes down to experience, but here are a few tips:
Converging
Knowing when to converge can be tricky, when the ideas are flowing you don’t want to stop the good times rolling. The danger being they keep going and nothing is ever made; or something is made, but is so far from the original concept its basically something else entirely (that can sometimes be a good thing).
- The moment the team finds an idea that has serious legs, where everyone is confident it could work, is the best time to converge. If left diverging for too long, you start to see diminishing returns on solid ideas which people understand, and start going into wild spaces. If your first idea doesn’t work, you can always return and see what those crazy left field ideas are.
- Let the team decide on how to push the idea into the convergence space. Coming in like a wrecking ball: picking the idea and making everyone switch on the spot, can lead to whiplash. The team has invested their time and energy into these ideas, and many might get attached to things. Picking the direction and then challenging the team to now converge on that one, while seeing what other things they can drop or add from other ideas, gives them a stepping-stone to transition over. I’ve found this method keeps the team engaged and helps them feel still in control of creativity when coming up the solution.
- Make it clear it is time to converge on the single idea. There is nothing more frustrating than a team member still trying to bring their idea back to life, while the team is focused on something else. This mostly stems from them not being able to have closure on the thing they really got passionate about. I normally take all the ideas and put them in a ‘Bucket-o-cool’ board on the wall where all those ideas can live. Not forgotten, but segmented away for another time; they may end up being features you bring to your product, or even ideas that could be turned into a new product altogether. Other teams take the ideas which didn’t make it and throw them on the ground and into the bin, ceremoniously killing your darlings to show that they are not worth anything now the team has decided on a focus. Both work as shifting the topic away from divergence. Do whatever works best with your team’s personalities.
Diverging
Moving to a diverging mindset is a lot easier to cross, as it encourages a person’s natural curiosity. However, it can still have its challenges to overcome. It is important to always diverge at some point in the project, as tunnel vision down a single path means the team is missing a vast number of opportunities to make it easier or better.
- If you see your team barrelling down a solution, and testing keeps coming up negative, or the team is constantly needing to explain or justify their reasoning, these are good indicators the team is on the wrong path. A good solution should be obvious and easy for people to understand. The desire to make something work no matter what, can create solutions which only work for the team building it, not the users.
- Have the team step back sometimes and take a breather. Sometimes just stepping away for a day and looking at something else, lets the team get some perspective and see if they are on the right track. When doing testing on a prototype everyone loved and thought was a great idea, but which failed with the users, get them to take a step back. Maybe the idea worked well on paper but not in practise. Time to expand your horizons and take those learnings into a new direction to see if there is another answer.
- Fail fast, learn fast, a common phase in the product industry and very important here. Spending too much time trying to solve a problem one way, adding compromises and band-aids to try and make it work, is not going to help anyone in the long run. Better to kill/park the idea and look at it again from a fresh angle. Failing is a good thing. It tells you what not to do. It is only a bad thing when you don’t learn something from it. I always encourage my teams to fail as much as possible, because every time they do it means they are closer to a viable solution. Watching someone lose all momentum and drive to complete a product because it is just working, compounds the chances of it crashing and burning. Plus, going into development and spending your budget on a dud, is a very hard and expensive lesson to learn. Better to get your team to diverge in scope and save that money for the launch party.
Activities for switching
The Codebots Activity Kit is our series of methods you can follow to successfully scope out a project. Here are a few ones which can help guide your teams in the Groan Zone:
User testing
User testing is one of the best and most important activities you can do while scoping and developing. Sitting down and listening to your users yields so much valuable information and helps you see where you need to refine. Whether it be converging on a concept or feature they all love and really see value in or diverging from a common pattern they are all saying you never explored. Do it often and be open to what they say.
Pattern recognition
When looking through ideas, research and feedback there is always a golden opportunity to look for patterns. Doing everything the users want or what research says is a bad practice and can quickly create a Frankenstein of a monster project. Instead sit down and start looking for common patterns you keep seeing. These are the threads you can start converging in on. If you have 10 viable ideas with wildly different directions, look for a common thread amongst them all and focus in on that.
Pattern Recognition
User journey
Understanding what the user journey is when interacting with your product or system, is vital to knowing where areas of opportunity lay. By user journey, I don’t mean a user flow of screens and buttons a user is pressing on a product, I mean a break-down of all the steps they are taking, both on and off the product. How they use it in their environment, and what reactions we want to elicit from them. Getting the team to flesh this out, allows them to see points they can start exploring and solving. This is especially good for a legacy migration off an older system. Looking to see how the users interact and how they desire to act can give your team the chance to build something great. Simply doing a direct replication on a new technology solves very few problems. What if the system was designed for desktop originally, but the team wants to be more mobile? What if the users journey involves so many unnecessary steps that could be dropped for a later date?
Prioritising
If you are finding yourself with a vast number of ideas and features that all seem important and viable to add to your product, it is a good time to prioritise them. This activity of cutting through what needs to be done first and what should be focused on, gets teams moving in the right direction and stops them spending too much time worrying about the future. Like in my story before, we really needed to prioritise so we didn’t design such a big system and burn us out before any code was written. It is a great way to converge your team back whilst keeping all those other great ideas in the back of the mind.
Summary
All products and projects go through a stage of convergence and divergence. Knowing how to navigate them is a skill. What is key, is allowing your team and yourself to spend time in both, to understand at what points you need to switch and cross The Groan Zone. This mostly comes from experience and a few trial and error attempts, but you can get there. Don’t be afraid to fail or throw away an idea which isn’t working. Don’t be caught up in the frenzy of creativity; of coming up with every idea under the sun. Know as long as you do both, you are going to create something beautiful.
Written by Shannon England
Branding, Communications and Marketing
Shannon is our branding and marketing go-to. When she isn’t working on our communications and marketing campaigns, she is typically drinking coffee or at the local plant shop.
