In November last year, we hosted our first design workshop — ‘Product before Pixels’. This was part of an ongoing set of events that we‘d created at Zomato, such as the Product Huddle, to seed the product and design ecosystem in India, and Delhi NCR in particular.
Even though the event is some months old now, we felt that the content of what we shared during the workshop can be of use to the wider community.
The theme of this workshop was to introduce designers to the idea of Product Thinking.
What is Product Thinking?
The phrase ‘product thinking’ is finding a lot of resonance these days. At the time we did the workshop, this medium post seemed like the only one that talked about product thinking. Since then, we’ve seen it mentioned by Julie Zhuo (Facebook) as well as by Cap Watkins (from Buzzfeed). In Buzzfeed’s recently published document on design roles, they call out Product Thinking as one of the explicit skills that their designers need to master as they grow in their careers.
Here’s what Julie Zhuo says:
Strong product thinking means that you understand what a good outcome is, and how to design an experience that would lead to those good outcomes. The better you are at this, the bigger and more ambiguous the problems you can take on, such as “design a new user experience that helps people understand the value of this service so that they come back again the next day.” The latter requires a much deeper understanding of human motivation and comprehension.
A related concept that gets mentioned in Product Management writing is “product sense”. Here’s Ken Norton’s essay on hiring PMs that talks about product sense.
I am a strong believer that certain people are born with innate product instincts. These people just know what makes a great product. They’re not always right, but their instincts usually point in the right direction. And it can be tuned, but it can’t be learned. Product management, especially in highly dynamic environments like the web, involves lots of small decisions. Sure, there’s a lot of big thinking and strategy. But it’s the little decisions where a great PM distances him or herself from a decent one.
Ken likens this skill to a “spidey sense”. We believe that no matter how spidey a skill is, our aim should be to deconstruct it. Only then can it be taught, making it more accessible to everyone.
Visual Design, Interaction Design, Design Thinking, Product Thinking
When it comes to designing digital products, there is a fairly large body of writing and examples around certain aspects of the digital product designer’s toolkit. These are visual design, interaction or UX design, and design thinking.
Visual design and interaction design are the primary skills one uses in crafting the design details of a product. You master these by learning things like alignment, contrast, whitespace, design patterns, content hierarchy, transitions, affordances, colour theory and so on.
To help figure out what to build in the first place, there is design thinking or human-centered design. You start by gaining empathy for your user to understand their latent and unmet needs and use a process of ideation and prototyping to generate new and groundbreaking product concepts. Google Ventures’ Design Sprint is a compressed version of applying design thinking.
But isn’t there something still missing here? There are a bucketload of soft and hard skills that a designer needs to master besides these, especially in product organisations. You need to communicate the rationale behind your design decisions succinctly and clearly. You need to be able to use data as a design tool. You need to get good at negotiation and facilitation because you work with engineers, product managers and stakeholders. Or as Ken Norton has written, you need to get great at making tons of little decisions that can make or break a product.
We think that product thinking is one of these skill sets. It is a set of skills and behaviours that leans towards shipping the right product. It is the bridge from the blue sky world of design thinking to the reality and nitty-gritty of getting something out of the door. There is a strong bend towards implementation while being fully aware of the impact this would have on your users or your company’s business.
Often this happens rather informally within a product team. You rarely see the product thinking process, you just see the decisions. Within Zomato as well, we often do most of these things rather informally. We used this workshop as an excuse to formalise some strategies and take a first stab at articulating some of them.
Feature Placement: Context Maps
A few years ago, we realised that while we were an excellent restaurant directory, we offered limited features for restaurant discovery. That meant that unless you had a very clear idea of what you wanted, often a specific restaurant, you might be lost using our product.
So we introduced Collections — thematic, mood-based curated lists of restaurants, and a powerful discovery feature. In their first incarnation, they appeared right on the homepage of the app, easy peasy.
But as we grew and added more features like online food ordering and revisited our approach to mobile advertising, the real estate on the home page got used up. So, we had to find another location for Collections and we places them on a standalone tab like this:
As you can imagine, this reduced the usage of Collections as a feature. The users who did know about it, raved about it, but most users never even discovered it.
Why? Just because you have a kickass feature, it doesn’t mean that people are going to discover it on their own. You need to be careful about how you surface it to users. We’ve found that a way to design more effective feature surfacing is by having a more nuanced understanding of your product’s context of use. In what scenarios is your produce used? What triggers someone to open your app? In what scenarios are they already using existing features?
Here’s where we wrote down some variables that would play into a user’s context of use for Zomato:
One can immediately see that our Happy Hours collection should surface at a time that the user is looking for nightlife, and Sunday Brunches should appear on a weekend. Pocket-friendly bars should surface for a different user than the ones for whom we surface Luxury Dining. We’re still working on the most effective ways to execute this, but context mapping can help you group and connect features more meaningfully in your product.
Design Debates: Constraint Lists
Here’s a conversation that might be all too familiar to a designer and a product manager.
Designer: What do you think of this (Design A)? I’ve changed it, and now it’s more material design.
Product Manager: But we want people to write more photos and add more reviews. This is too muted.
Designer: Everything does not need to be highlighted. These big call-to-action green buttons should just be one per page. Also it’s rare to use these round shape buttons — the call to action is usually at the end of a card in material design.
Unhappiness soup in the making.
If you look beyond what’s being said, it’s just that the product manager and designer are solving for different constraints:
This poor little add photo button has at least four different constraints shaping it:
- Give predictability of behaviour to the user (“…it is usually at the end of a card”)
- Consistency of design language for the platform (“…this is more material design”)
- Surface the actions that help create user generated content (“…this is too muted”)
- Simple is better (“…not everything needs to be highlighted”)
A very large number of design conflicts happen because people are arguing about different constraints. For instance, you might be making a case for consistency. And the Online Order business head may be making a case for more orders. These constraints arise from design philosophy, business needs, engineering constraints, and often even unarticulated personal tastes and philosophy.
Instead of getting mired in arguing about the specifics, what we’ve found helpful is to list down these objectives and constraints and use them as a validation checklist. For example, below is a list of constraints for one of the redesigns of the core product. By making the constraints explicit, you can get to a shared decision framework between engineers, PMs, designers, and stakeholders.
Since working with so many constraints can be hard and impossible to keep it all in your head, teams often synthesise these into a smaller set of guiding principles.
For example, here is an excellent talk on growth by the folks over at AirBnB and they share the ‘growth principles’ they use to direct their decision making.
This or That? Feature Prioritisation
Another thing that causes much pain within teams is the challenge of deciding what to work on first. When we had just launched online ordering on Zomato, we spent a lot of time improving the order conversion funnel.
The funnel was the following:
Open Order app → Pick a restaurant → Add items to the menu → View Cart → Select an address → Verify phone number → Make a payment
If we were to pick this up, we could start with any number of themes. For example, how might we make it easier to choose a restaurant? How might we avoid choice overload when selecting items from a menu? What if we add photos to the menu? Should delivery times be ranges instead of fixed numbers? Could we make the payment method selection effortless? And so on.
But a simple look at numbers on the funnel indicated to us that the “Select an address” step was causing a lot of drop-offs! Seriously? Adding an address is a pretty standard step in any e-commerce business, why would that be an issue? If you look at this (very old) design, we had added a field called “Locality” at the beginning of the form.
Why did we need this? Because we had a limited set of localities to which a restaurant can deliver. We needed to know from the user whether his address was within that set. This makes this form different from traditional e-commerce address forms where the delivery can be anywhere. When we did some user testing, we noticed that people were just typing their full address in the locality field. So, this is what we fixed first.
Obviously data can make it easier to prioritise and help you choose, as a team, what to work on first. However, even in the absence of data, you can use your intuition and judgement to prioritise. One framework we use is an impact-effort matrix.
It is best to do this as a group to get to a shared set of priorities.
Behaviour change expert BJ Fogg has a tool called Priority Mapping that is very similar to this.
Another tool we’ve found that is helpful is Ryan Singer’s Terrain Map. You imagine your feature set as a set of parts of a terrain and rank them in their order of importance (relevance to customer, nice-to-have/must-have, how far you have to take it).
Practice, Practice, Practice
What did we do with these? Well, we turned the workshop attendees into teams of “DID” aka Design Investigation Departments.
We asked them to take some existing apps (like Uber, Tinder, Whatsapp) and deconstruct how those teams *might* have made design decisions using these tools.
We are still developing our product thinking toolkit. If you try any of these tools, let us know how they worked for you. If you have strategies around product thinking in your teams or organisations, do share with us.
