Clients are often confused as to how to get started, whether it’s a new project or a takeover of an existing one. The main challenge is that there is a gap between the clarity they think they have and the clarity we need to provide project costing and timelines.
To overcome that confusion and form a clear, mutually comprehensible action plan, we at Slash have developed our own approach. In a series of articles, we will present the predefined phases of our processes. Let’s talk about Design Research.
Design research is in many ways the hardest phase to implement. It is highly creative and strategic, and yet very data-driven. It has less of a playbook that is copy-paste and is more consultative. The objective of the design research process is to extract problems that users want to solve, design solution concepts that may solve the problem, successfully validate those with users and finally consolidate the findings into a design brief that will guide the next product design phase.
Let’s dig in.
Problem Research: fishing for jobs-to-be-done
Users evaluate products based on price and perceived value. Price is a key deciding factor, but as for value, the product has to be functional, aesthetically pleasing, and it has to demonstrate legacy or connection to a group and have an impact on the society. The more of these elements the product has, the more value it brings.
Here is the brief outline of the process:
- Jobs to be done
- Elements of value
- Design thinking
- Strategy canvas
The late Clayton Christensen, the author of the “innovator’s dilemma”, famously said: “People hire products and services to get a job done.”
In this context, a job is a need that isn’t met – something as simple as brushing teeth or more complicated like presenting complex data in a brief and compelling way. When we want to have that need satisfied, we look for solutions, and they are provided through services or products such as better toothbrushes or software that collects data.
The Jobs to be Done framework is a powerful theory of consumer action. It describes the mechanisms that cause a consumer to adopt an innovation, or to make a purchasing decision.
The framework is widely used and gives us 2 benefits:
- It allows us to extract key user needs (“jobs-to-be-done”) within a short period of time.
- Often those needs are ever-green and solution agnostic. While new solutions may emerge as a result of technological innovation, these solutions usually address the same underlying human needs.
The challenge for any new product or service is to figure out what users really want and really narrow down the problem to its essentials. We call this “fishing for jobs-to-be-done” or problem research.
What’s interesting about this process is that it usually leads to underlying problems, fundamental human needs.
There are many methods in the market to accomplish this, including Design Thinking, Ethnographic Research, Blue Ocean Strategy Canvas, Elements of Value and Hooked. We will explore those methods, their pros/cons and considerations, in future articles.
Let’s see how this works in the example of Intercom. Intercom is an in-app chat service.
Soon after launching Intercom, the company added a map for the clients to track where their customers were in the world. It quickly became popular, but the company was struggling to define why. As a solution, Intercom looked at how exactly its clients were using the map and for what purposes. What they learned was that most clients liked to show the map at conferences, post it on Twitter, share it with investors. They did it because the map looked impressive. To put int simply, the map was a showpiece – something to boast about to others.
Before figuring this out, Intercom focused on geographical accuracy and clustering when making improvements, but the clients didn’t like the updates. They didn’t need the map for a map. So, Intercom shifted the focus to making the map look good, hide sensitive data, and be easy to share. And naturally, that was the update that everyone loved, because it improved not the map itself, but the showpiece.
First, we need to redefine the problem you need to solve, i.e. a human need that you want to meet. For instance, you are unhappy with the garbage collection in your city, and you want to improve it. It is a need, and it’s also a job to be done.
Now, let’s imagine that the job you want done is listening to music. In different time periods, you would access different services and products to get that job done: go to a concert, buy a CD, stream music online. Over the years, the way to get that job, solve that problem has changed, but the job remains the same. Most jobs are like that – solution-agnostic. New solutions typically emerge based on technological advances, and new jobs may emerge over time based on technological advances and cultural evolution.
So, how do you define the job? Following the rule of three, here are the questions that do the definition:
- Motivation: Why do customers buy your product?
- Situations: Why did customers switch from another product?
- Anxieties: Are customers struggling with your product?
This is the concept design process of defining the job that needs to be done.
Design Research at Slash
Whenever a client or partner approaches us with a market opportunity based on their understanding of the problem they want to solve (and possibly the solution they may have), our first reaction is to take a step back and seek supporting evidence that indeed the problem exists and is defined clearly and accurately.
Redefining the job you need done is at the heart of our product work – this is design research. Our emphasis at Slash is on digital products and startup architecting, though the same methodologies can be used to an extent for non-digital work (e.g. consumer packaged goods, shoes, etc.).
We follow a pragmatic approach to digital design research. We blend design thinking, hooked products methodologies, human psychology, and blue ocean thinking to inform our design research practices and create highly engaging and differentiated digital products.
We structure our Design research process in 4 steps:
1. Client Vision: Through facilitated workshop(s), we explore the personal and organizational motivations and constraints behind a project, reframe the high-level problem and opportunity space as needed, and baseline the objectives for key stakeholders until we’re all aligned on the project vision.
2. Problem Research with Users: In this step, our goal is to identify the user personas (or proto-personas) and what value they expect from a product (the jobs-to-be-done). We typically do this through a series of (virtual) workshops with key stakeholders and by speaking to a pre-agreed sample of end users over video calls, or in some cases in-person meetings.
At Slash, we limit the scope of physical fieldwork. If extensive and nuanced field work is required, we involve design research partners such as Heist who have significant experience in conducting complex ethnographic research with user sample sizes of dozens or hundreds of participants.
3. Concept Design and Testing: In parallel to the problem research, we quickly start to ideate low-fidelity prototypes, visual sketches and core business concepts of what potential solutions may look like with the client and end users.
Since we tap into our experience in startup architecting, we often combine product design and startup design concepts early on. These concepts are then tested and refined collaboratively with the client and users, sometimes near real-time over several small iterations.
4. Consolidate Design Brief: Finally, we consolidate the vision, user personas and what value they expect from the product and the concept design into a design brief to guide our detailed product design phase where the product will take full shape.
Tag CloudAgile - Agile Delivery - AI - Animal Framework - Autonomous weapons - B2B - blockchain - Clean code - Client consulting - cloud platform - Code Refactoring - coding - Computer Vision - cryptocurrencies - Deepfakes - Deep Learning - DeepMind - Design Research - Developer Path - DevOps - Digital Ownership - founder equality - founder equity - front end developer - Fullstack Engineer - Growth strategy - Hook model - innovation - Manual Testing - Metaverse - methodology - Mobile Engineer - Natural Language Processing - NFT - NLP - playbooks - Podcast - product versions - project management - Quantum Computing - Recruitments - Remote Work - Robotics - Sales machine - Self-Driving Cars - Slash - Software Development - Software Engineering - teamwork - Tech Talks - tech teams - testing playbook - The Phoenix Project - Unit testing - VB Map podcast - Venture Building - virtual retreat - Web3