Whenever we start a new digital project, there’s always a temptation to jump right into the details. Get right to the tactical nitty-gritty, the dirty details of solving the problem.
That’s because solving problems feels good. It’s satisfying to finish the day and say “I know how we’re going to do this.”
But in reality, most problems aren’t solved that way. Digital projects are long, complex, and thorny issues, where quick fixes, while they look obvious, are rarely the best way forward.
Unfortunately, knowing that quick tactical solutions aren’t the best way forward and actually figuring out what to do about it are two very different beasts. So today, we’re going to tackle the latter — with design and discovery.
In this post, we’re going to cover:
- What design and discovery actually are
- Why the design and discovery stages are critical to a successful digital project
- The business case for design and discovery
Here we go!
What are design and discovery, and why should we care?
Design is far too broad a concept to define. For this post, what we're talking about is when you follow a specific methodology or way of thinking to approach a project or problem. Depending on your framework, that design approach will likely involve:
- Understanding the problem for the business and the user
- Brainstorming lots of creative solutions to the problem that work for all stakeholder
- Trialing lots of these ideas as quickly as possible
- Honing in on a single idea that works for everyone
In contrast, a lot of projects and products don’t start this way. Rather, they start with an assumption about reality, and progress from there.
For example, a founder might think that they have a better way to administer higher education exams, because they hated their own exam experience, and build a product to solve that problem.
Without the design step, the rest of the stakeholders won’t be consulted, resulting (potentially) in a huge waste of resources as the founder learns that it’s only them who has this specific issue.
Design thinking can mitigate or erase those sorts of problems, because it focuses on understanding the reality of other relevant stakeholders, rather than assuming that reality.
Discovery, in contrast, is a more specific subset of that design process. It’s when a UX, design, product, or project team takes time to understand the business case and end users, as well as the ecosystem, technical requirements, and network that a product or project will ultimately live in.
In short, the discovery phase of a project is all about the research. It’s when you uncover what problem you’re truly trying to solve, for whom, how they’re solving it now, and some possible solutions that work for everyone.
The business case for design and discovery
Because a design approach and discovery are not seen as mission-critical, they are often cut from projects with disastrous consequences. That's why both practitioners and internal teams need to be capable of building excellent business cases for design and discovery.
The fundamental argument for design and discovery from a business perspective is “spend now, save later.”
That is, if you spend money on design and discovery up front, you’ll save money down the line. Those savings come about in shorter, more productive dev cycles, better technology purchases, more success product launches / value propositions / sales and marketing efforts, fewer iterations to reach a released product, and less scope creep because you have a tight product definition.
Therefore, the business case for a design and development phase to any digital project should be focused on measuring the impact of those cost savings down the line. This might mean:
- Taking time to review past project overruns and see how much it would save to deliver a project on time
- Reviewing costly technology purchases that had low adoption. What did the initial purchase cost, and what did the new tool cost?
- Putting a dollar figure on the slow pace of procurement when you have as poorly defined project
- The opportunity cost of a longer development process (e.g. what other projects the team isn’t working on).
These won’t necessarily entirely justify the cost of design and development. However, in addition to these quantifiable benefits, there are also numerous, more nebulous perks of having a design and development phase:
- Projects happen faster and teams stay focused
- You have better buy-in due to a wide base of consulted users
In short, design approach combined with a discovery phase will make your project run more smoothly, probably get it done faster, and will definitely make everyone feel a lot better about it at the end, increasing adoption and mitigating malicious compliance.
4 tactics to communicate the value of design and discovery
Of course, not everyone is going to see it this way. Lots of time we’ll go into organizations with a discovery approach only to find out that there’s not the buy-in for a full discovery phase.
Here are our top tactics to get the buy-in you need.
- Run a stakeholder workshop
This is a little devious, but if you’re struggling to get everyone to buy into your design and discovery plan, then a short workshop with a few of the known stakeholders can be an easy way to highlight the need for your process.
The idea is that lots of projects come about because of assumptions of reality. Therefore, an easy way to get buy-in is to highlight people’s assumptions of reality to themselves. So, get everyone together and get them talking about the project, and their assumptions will become clear.
- Conduct a quick bought of user testing
Oftentimes, organizations will have a solution in mind before they’re really defined the problem. Running some guerilla user testing with a paper prototype of the solution can quickly expose some fundamental flaws in the suggested course of action.
- Run guided user interviews
While it’s one thing to tell people their assumptions are just that — assumptions — there is nothing quite as powerful as seeing real users struggle immensely with what you think is a relatively simple task. Seeing that happen will convince even the most opposed stakeholder of the need for proper discovery.
- Remind then that you don’t know their business
It might seem obvious, but if you’re an agency working for a new client, then reminding your client that you’re new the business can work wonders. It’s rare that someone would expect you to instantly know everything, but people tend to not know what other people will or won’t know. And in big organizations in particular there is so much tribal knowledge it can be difficult for new vendors just to follow the conversation, let alone understand what’s going on. Reminding teams of that can be extremely helpful.
Planning and discovery are, we believe, completely essential parts of any digital project or product development. It’s when you really clearly uncover and then articulate the problem you’re solving, who you’re solving if for, and a few good ideas for what that solution might shake out as.
It’s also the phase when you put your new solution into the context of the broader stakeholder, technology, and business process ecosystem to see if it makes sense at all.
While it might feel expensive, design and development accelerate mistakes and wrong paths early, when it’s extremely cheap, and saves organizations from late-stage fixes and changes that are both more annoying and a lot more expensive to make.
The point of any product, solutions, project, or even business transformation is to move an organization from a current state to an ideal state. Design and discovery is all about understanding where you are now, where you’re going, adn who’s going with you.
Because it's always easier to get somewhere if you know where you’re starting from and you know where you’re going.