Building bridges: our approach at product design
The design of a product can be thought of as building a bridge: our initial problem is that we need to get from point A to point B, and there is something in the way that prevents us from simply walking to the other side.
However, it is important to note that there is at least one major difference to take into consideration: the expected bridge failure rate is 1 out of 4,700 annually, while on average 68% of IT projects fail, according to a report issued by IAG Consulting.
That same report indicates that these projects fail most often due to poor business analysis capabilities. This means that we can’t simply pile stuff up and hope it turns into a bridge along the way. We find that the most efficient way to design a product is to work simultaneously from both banks, and meet halfway:
a) on one side, we start out with an analytical and constructive approach: understand what we know and what we don’t, lay out every piece of the puzzle we have, figure out how they might combine, etc.
b) on the other side, we start out with a narrative approach, with the goal in mind, on a qualitative and visionary note.
Let’s take a look at how this works.
We begin with research, exploration and idea mapping, and then divide progress along two paths: from an analytical perspective, we use the Jobs To Be Done framework to capture and organize our customers’ needs into an actionable scheme and, from a narrative point of view, we use a narrative structures to encapsulate concepts that can go along our customers in their journey from problem to fix.
Research, exploration and idea mapping
The secret to doing good research is always to be a little underemployed. You waste years by not being able to waste hours. –Amos Tversky
Desk research is a process that enables us to find out our status of knowledge. We use the Rumsfeld Matrix, because it’s simple and powerful: it lets us map what we know (knowns), what we know but aren’t aware that we know (unknown knowns), what we don’t know (unknowns), and be aware that there are things we don’t even know we don’t know:
For almost every problem one can think of, there is a series of previous attempts at solving it. We need to find them, and understand what worked well and what didn’t, to avoid reinventing the wheel and to find inconvenients that we may encounter down the road.
We conduct our research in two stages, starting with an exploration phase: the goal here is to gather as much information as possible about the client, their customers, their partners, ourselves as providers, the competition, the market. We dive deep into scientific publications, studies and articles, which in turn lead to perusing other tools that compete with our product and tools that solve a neighboring problem.
During this phase, we seek to collect a large volume of information to expand on our knowledge. We aren’t trying to find the answer, only gathering information to know what questions we’ll need to formulate.
Then we move on to an analytical phase: depending on the problem, we might use different techniques, but the goal here is to see if we can find ways to put together all the pieces of the problem in a way that makes sense as a whole. Ideally, we like to get a visual expression of all the information we’ve gathered. We use mind mapping, cluster diagramming (also known as Rico clustering), combinatorial matrices, or a combination of all those to find insights into a plausible solution.
From that point on, our roads fork. One path goes down into the requirements analysis, while the other takes a step back to try and see the full picture form.
The near shore: Jobs To Be Done
To design is to devise courses of action aimed at changing existing situations into preferred ones. — Herbert A. Simon
The initial exploration phase generates a large volume of data points. We then need to narrow the arch of ideas and focus on those that have the most in common with our project.
Like many product design teams, we used to start out by outlining Personas: constructed but realistic representations of target users, based on data captured during market and user research. We now prefer to start with Jobs To Be Done:
Customers often buy things because they find themselves with a problem they would like to solve. That’s the Job To Be Done.
Before creating Personas, we need to leverage the data we gathered about our target audience to understand their mission and motivation. The Jobs to be Done framework gives us a practical way to narrow down our results and weed out potential solutions that don’t make sense.
Paraphrasing Theodore Levitt, people don’t want to buy a quarter-inch drill; their job is to make a quarter-inch hole. We don’t really need to know what Alice or Bob like to do on their weekends to help them get their job done. We do need to understand what that job is and why they need to do it. Personas come in handy at a later stage, where we need to empathize with target users to design the user experience.
Once we have gathered enough data to figure out what job our customers need to get done, we can begin to look for patterns, which give shape to customer clusters.
The other shore: Building around a narrative
No word matters. But man forgets reality and remembers words. –Roger Zelazny
Customers don’t make decisions in terms of abstractions such as features. Too many companies get stuck in the weeds of ‘how it works’, but customers never buy ‘just a product’, they buy the value that the product offers them and the function it performs: they mostly want to know “why should I care?”, and the answer should point them in the direction of getting their job done. In this second path, our actions are guided by the question:
What is the story we want to be able to tell once the product is built?
Customers buy products because of a story they tell themselves about who they are and what those products do for them. Our best shot at creating successful products is to find those stories and align our design efforts with them.
From this second shore, we build a narrative that goes hand in hand with our discoveries about our customers. This narrative is not a fixed thing; it should be fluid and constantly adjusting to incorporate new facts and hypotheses we formulate. It’s also not something vague and fictional: our narrative is the resulting image of connecting the dots we put together during our research.
While the initial research stage was an expansive moment of accumulation, and the first path of thorough analysis was of a descriptive nature, this narrative instance is an attempt to synthesize and explain our customers decisions and actions. Exploration, description, explanation.
Knowing what our users will attempt to solve with our product makes most decisions easier. Endless arguments about whether we should make it look great or make it run fast no longer make sense when we can understand our customers’ actions. (No one wants it to run slow, if you were on the fence with that one). When in doubt, we err on the side of the customer’s benefit.
In the fever of the ‘move fast and break stuff’ mindset that populates the technology industry lately, most product design projects start prototyping right away and miss this point. They become too focused on things like technology stack, features and specs. This dramatically increases the possibility of building the wrong thing. A narrative helps us incorporate new knowledge into an ecological whole, that keeps the customer front and center, and focuses our efforts towards solving their problem.
User Experience Design
People ignore design that ignores people. –Frank Chimero
Having conducted this analysis, we have a multilateral understanding of the narratives our customers’ are immersed in, and we can take actions to solve their problems by helping them get their jobs done. We need to have done this work to grasp what it is that our customers need, and why they want it. How that will become a reality is the user experience, and it is the corollary of our exploration, description and explanation design process.
Now, the term “user experience” probably ranks among the most misunderstood terms in recent history. It is taken to mean that focus should be on the user or customer. This is a misconception: what it really means is that you should focus on the user from a business perspective.
UX is better understood as a set of business decisions aligned towards what you want your users or customers to experience: it is about creating an environment or context that moves your customers to act in a certain way; not any way, but a way that aligns their needs with your business goals. In simpler terms:
Product design is about finding balance between user experience and business convenience.
Designing the flow of experience is a delicate mix of science and art, one that aims to balance the needs and wants of both customers and business. During this phase of the product design process, we focus on understanding when, where and how our customers will interact with the product. Each interaction should be meaningful by design and result in a positive experience that also drives the business forward.
The key concepts here are alignment and balance. Between customer satisfaction and business success. A meticulous analytical approach and an encompassing narrative serve as a caliber to find that balance.
Putting it all together
We began by saying that product design can be thought of as building bridges. The purpose of these products we design is, precisely, to bridge the gap between our customers’ current situation and the one we envision for them.
Over the course of our years helping others build their bridges, we have come to a method that does a few things well: it presents our customers with an original way to see what they do for their customers, it gives our team a better grasp on the problem and our imagined solutions, and it provides a checking mechanism to ensure we’re on the right track.
If both ends meet, it means we’re on to something. It means the narrative can hold every piece of the puzzle in place, and that every piece individually contributes to the overarching narrative. It makes sense.
In a way, this can also be thought of as a bridge. Between user experience and business convenience. Between meticulous analysis and an overarching narrative.
The best way to build bridges, it would seem, is to build bridges.
