Part of being a product designer is learning how to navigate the start of a project so you can help your team and clients understand exactly what needs to happen to get started. At Codebots, we have spent a long time refining and polishing how we start off projects. We call it “scoping”. This is the process we do before we start building a product, and many times again whilst in development. But all that learning came from somewhere, here’s a story some of you may be familiar with.
It’s a Friday afternoon in the office and you and the team are definitely still working and not at all turned around at your desks discussing the finer points of that new movie that just came out. As the jokes fly and the discussion gets louder, whilst being on the look out for the managers, of course, you get a spark in the back of your head.
An off-hand comment about the lack of continuity between the hotly debated movie and its predecessor gets the gears turning in your head about that side project you’ve been meaning to get started on. Despite having plenty of time to get started, you’ve always made an excuse and kept it in the ‘maybe one day’ pile.
With your weekend plans cancelled, you feel reinvigorated to get started on your side project. Once again, you head out the door waving colleagues farewell. Sitting on the train ride home, sandwiched between some nameless office workers all glued to their phones, your mind races with what you want to build and how you’re going to put each piece together.
You get home and throw your bag on the lounge, not even bothering to get out of those annoying office shoes. It’s project time. With a pen and paper, you start drawing out ideas and writing notes on how you can make your idea work. You’re filling pages and pages with ideas. You crank up your music, and the creative juices are flowing like a smoothie food truck at the park on a hot summer’s day.
You dust off that whiteboard you bought and left sitting in a dark corner of your home, grab some old markers and start sketching your plans. Dinner is forgotten as you keep following more rabbit holes into your brand new idea, adding more and more features to it. The night grows late as you’re up in the dark researching things online, trying to solve those pesky questions you circled over and over again on your crowded whiteboard. With hundreds of tabs open in your browser, you smile triumphantly at the amazing project you are about to embark on, and fall exhausted into bed.
The next day, as the sun peaks through the blinds and urges you awake, you roll out of bed and look at the time. “Probably shouldn’t have stayed up so late,” you groan to yourself, as you wander over to your kitchen table and peer over your night’s handywork. That oh so familiar feeling settles in your stomach.
“How the hell am I going to do all this? It’s going to take me all year…”
Now you remember why you never got started on this project, just like many others. You stand at the base of a mountain, when you really only wanted to climb a cheeky hill. Defeated, you head back to bed for a lazy Saturday sleep in, and to maybe watch the first movie in the series you were all talking about yesterday.
Hopefully this hasn’t happened to you, but it does happen to many. Starting out a new project on the worst possible foot, making everything seem so incredibly hard and complicated. Whether it be in the business world, or just by yourself, failing to understand the scope of work before you is a real killer.
What is scoping?
Scoping is first phase of any project, where the whole team gets together and works out what they actually plan on creating. Some call it ‘Designing’, ‘Discovery’ or even just ‘Planning’. No matter what you call it, the concept is the same - you’re coming up with your team’s battle plan.
At Codebots, we’ve boiled the process down to a couple of stages that work best for us. Here, I will quickly go over the process, and where it came from to provide some context for this article.
Our process for scoping follows five stages, all with the key focus of trying to work out what the problem we are facing is, and how best to solve it as quickly as possible. They are as follows:
Understand - Learning about the problem;
Observe - Learning how the problem affects people;
Ideate - Coming up with ideas;
Prototype - Testing out our best ideas; and
Develop - Making our idea a reality.
While you can come up with your own scoping process, we recommend following the same inspiration we crafted ours from: Design Thinking.
How does Design Thinking help me scope?
Design Thinking is a term that came out of John E. Arnold’s book “Creative Engineering” in 1959, which was later popularised by IDEO and Stanford University.
At its core, the process is all about putting humans at the centre of a product and shifting the conversation away from detailing out features and their specs, to how solutions solve a user’s problems and how it becomes part of the collective whole of a company’s brand.
Part of the process is scoping things from a double diamond approach. First, you diverge with gathering information and ideas, before converging back again with something you think will work. Then diverging as you test it and look for weak points, and converging again with a more solid product.
At Codebots, we shifted our thinking from just taking a list of requirements handed to us and mindlessly working at them, to instead getting down and dirty with testing, creative problem solving and research, to build products people find delight in. We quickly found projects and products landing far more successfully than their earlier, less scoped, counterparts.
How do I put all that into practice?
Every product starts the same way: as a problem in someone’s mind that they want to solve. Whether it be as complex as “How do I successfully manage the work tasks of an airplane repair crew?” or as simple as “How do I find recommended movies based off my hatred of the latest instalment in a film franchise?”.
Where most people tend to go wrong after this, is jumping straight into working on the assumed solution to that problem. Humans are natural problem solvers, and the desire to dive right to the end is almost instinct. In product development, that can lead to disaster. We’ve put together a kit of activities (that you can read more about in this article) that can help you navigate the scoping process. I have outlined the best five activities here. So, before you spend all Friday night coming up with a plan, try to take a step back and follow these steps.
Understand
Get to know what problem you are trying to solve, no matter whether it is one you or your company is facing, or one that a client has come to you about. During this stage you want to learn everything you can about this problem, especially how it is affecting users and business goals. Ask the hard questions and dig as deep as you can get so you can find the root cause of the problem instead of just trying to solve symptoms.
Only once you truly understand what you are going to solve, can you start coming up with ideas. But before you can get to that fun stage you need to diverge some more.
Observe
When you understand the problem at its core, you know what things are causing issues with people. For most this is where the solution ideating begins, but they miss out on a critical step that actually shapes the solution even more; observing how the problem is affecting people. This critical step is all about researching outwards and learning more about those people you are building a solution for.
Once you’ve armed yourself with a rock solid problem, observations and research about how the problem is affecting people, you can take all your collected information and start coming up with ideas.
Ideate
Ideating is the stage where you start brainstorming ideas and ways to solve the problem using that depth of knowledge you observed. The goal of this stage is to go wild and think from left field while making sure that the problem is being solved. Once you have let those creative wheels turn you start honing in on an idea that looks like it could be the winner.
From there, you as quick as possible make what we call a ‘rapid-prototype’, where you test the idea out with users to see if it has got any legs. Make some adjustments and test again.
Prototype
Most rapid-prototypes teams smash out a couple of hours at most, only to get the idea across to people. Now is the chance to spend a bit more time making something more real to test out with people. Here you’re looking for issues in how people use the product and how they react to their journey with you.
At this point, you’ve gathered enough research and tested out a simple solution to your problem. Now that mountain is looking more like just a series of rises. Keep working on getting to that next problem to solve, rather than tackling the whole thing at once.
Develop
From here you can start planning out what you need to do to make that prototype into something more real. You could even use what you built for the prototype to get started. The Codebots Platform helps you speed up this part of the process, and you can learn more about this here.
Conclusion
Scoping out a product can look like a daunting task when you tackle it all at once, throwing everything together and making a solution into something you realistically won’t be getting to for months. When you break down the process into smaller stages and further break the whole problem into something short and quick, things suddenly seem quite manageable.
Written by Tessa Mylonas
Head of Support and Education
If Tessa isn’t busy answering support questions or educating you about the Codebots products, she is typically found putting together flat-pack furniture, playing with her chocolate Labradors or hoarding houseplants.
