10 Lenses for Creating a Better Product

Divya Tak at UXDX Community: Failing Forward for Better Products. Video: https://youtu.be/_PJwXuoS0Ns

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction: borrowing lenses from other domains

[00:00:00] Hi, I'm Divya and I am a product designer, a podcaster, a game designer. I make art also. I have a background in physics, and one of the things that has been the best about coming from physics and then moving into design, and learning a lot by myself and working on a lot of different things, is you get to learn how different domains see things differently. Of course, because problem statements in each domain are unique, you have specialized lenses that you will use to solve for those. But sometimes these lenses can be used in other domains.

[00:00:35] I have found that some of the things that I learned in game design have really helped me evolve my product thinking. Similarly, some of the things that I learned while making products have helped me make better games. Or how podcasts have helped me think about storytelling, how art has helped me think about what my vision is. And so I put together this thing just so that I can bring some structure to some of those lenses that I often use when I'm having conversations with the people I'm working with and when I'm building my own things. Okay, so let's jump right in.

Velocity is not speed

[00:01:09] The first lens is from physics: velocity is not speed. The core concept is that velocity is a vector, which means that it has two things. One is a direction and one is a magnitude, and speed just has a magnitude. Oftentimes when we are building things we can mistake magnitude for moving in the right direction. But sometimes even the smaller magnitude, as you can see on the arrows on the right-hand side, they're smaller in magnitude, but because they are aligned together you can move further in the same direction.

[00:01:45] How I often apply this thing in practice is when I'm building a product I ask myself, is a user engaging a lot, and then what is the quality of that engagement? Let's say you have built a product and you have created an amazing onboarding, people are going through all of the different steps. Are all of the steps cumulatively adding towards building into the user learning, okay, these are the points and I will be using this product? Or are they just doing the steps because they are doing the steps? Are they running too fast nowhere, or are they actually moving in a particular direction? These are the questions that help me answer if I'm looking at things as speed or velocity.

[00:02:35] In all of these lenses I will have some questions at the end that I use, and of course you can think about your own questions, and depending on what your product is, that will vary. I generally work with B2C products and I generally work with more early-stage products, so that also changes how I apply these things.

What's your empathy blind spot?

[00:02:57] The next lens is one from psychology, which is: what's your empathy blind spot? In psychology you have a lot of different personality models to understand who you are, how you behave, how you act in any particular situation. I'm using the Big Five model, which is the most popular one, called OCEAN. It has five different scales: openness, conscientiousness, extroversion, agreeableness and neuroticism. It scales you across six factors within each one of these and puts different markers on, okay, are you open to new experiences or are you very closed off to new experiences, are you highly conscientious or low conscientious, are you highly extroverted or are you introverted, high agreeableness or disagreeableness, low neuroticism or high neuroticism.

[00:03:49] Now, this is where I am at. I'm very open. You will find this actually in a lot of creator domains, that openness to experiences is a very high scaling thing. And very interestingly, neuroticism, for example, is highly correlated with intelligence. But this is like a model, and these are my markers on where I stand on each one of these traits, which means that what I don't understand is the reverse of it. Those are my blind spots.

[00:04:21] So for example, if I'm trying to design a product, I will be very easily able to design something for someone who has very high openness, but I don't think I'll be as easily able to imagine for low openness. And of course it's not going to be easy to have emotional empathy, but just pointing it out and just looking at this: how will a user who has low agreeableness react to this product versus how will a user who has high agreeableness react to this product?

[00:04:51] Agreeableness is actually a very good one to think about, because if you are somebody who is hostile to instructions, you might feel other users are also hostile to instructions, and you might not be able to design a product that would work more with highly agreeable users, and vice versa. Same with extraversion: how much stimulus do you like in situations, and how much stimulus do other people like in the same situation? The reversal of your spot is your blind spot.

[00:05:20] Just thinking about that is very helpful, at least to me, when I think about it: okay, this is a behavior that comes naturally to me. If I was low extroversion, how would I go through the same product? If I was low on conscientiousness, how would I go through this product? If I was low on neuroticism, how will I go through this product? You might have different models that you are utilizing. Some people use MBTI, there are a lot of other models. But just thinking about what is the reversal of my behavior and what would those people act like can really add a lot of empathy and richness to what you're building.

Multiplying by zero

[00:05:57] In math, you know how if you multiply something by zero, everything else that came before it just goes to zero? You can also call it a critical system-breaking error. What I have found is that oftentimes you will design, because designing a product, building a product, is a very long chain. A lot of things need to happen for the user to have an excellent experience. Sometimes we miss out on these small things and that can really lead to a breakage, regardless of whatever effort has gone in, regardless of what the quality of everything before it is. It doesn't matter.

[00:06:36] So for example, you could have great marketing, it targets the exact right user, sets them up for the right expectations, you have an amazing onboarding, but the way your home screen is set up, your key CTA is just hard to remember. People don't remember, okay, this is what I'm supposed to do here, or this is why I want to come here. The user will not return. At that point you will see a major drop. Sometimes it's just important to think about, huh, okay, am I actually doing anything that is reducing all of my efforts to zero?

[00:07:10] So yeah: is there any point in your system that makes everything that comes before it worthless? It's just useful to think about it, especially when you're looking at your product as a whole, or even if you're looking at your part as a whole. It can be useful to think about, okay, if I'm designing this part and somebody else is designing this part, when they come together, is there any point in this where something towards a later point negates everything that came before it?

Activation energy

[00:07:42] The fourth lens is one that comes from chemistry, called activation energy. You might have heard, actually I'm unsure, but you might have heard or remembered from a chemistry class that all chemical reactions require activation energy. Some elements are highly reactive: oxygen is highly reactive, chlorine is highly reactive, sodium is highly reactive. But despite however highly reactive something might be, there is some activation energy that is needed.

[00:08:16] So it is useful to think about: when you want your user to do anything, even if it is a very small action, they will need some activation energy. It can be something like, oh, this looks shiny; oh, this makes sense; oh, this feels like the natural thing here to do; oh, they understood what I am trying to do. But just asking, okay, will the user require any activation energy, and how, and why?

[00:08:44] Of course we all think about things where the user has to do a large action, or has to do a difficult action, or has to do a conscious action. We generally try to counter that and add activation energy there. But it's also useful to think about it in small spaces and in small actions. What I think about once I have designed a flow is, okay, what actions do I want the user to take, and what would be the activation energy that would be required for each one of those actions?

Be brutal with what is fun

[00:09:22] This is the first game design lens that we are discussing. A lot of my learnings are from game design, and while fundamentally game design and product design can seem like they are both creating digital products, it's very interesting how different they are. Because game design is very centered around fun, there are a lot of systems that are around how to make your fun better, denser, richer.

[00:09:51] One thing that I have found, which is a very short and sweet learning, is: be brutal with what is fun. And how I implement it is, remove the bottom 30%. So if I'm making games I would remove the bottom 30% of the levels. I try things out, whatever is engaging, whatever isn't engaging, I list it out and remove the lower third.

[00:10:18] It's often very tempting, especially when I have worked on products, it's often very tempting to keep adding features, keep adding new things, and never remove the old things. What that ends up doing is it leaves a lot of long-tail behavior, where some of the people are using some of the features some of the times, but it dilutes the emotional connection that people have with you and your product, and that's probably not the thing that you want.

[00:10:44] So just thinking about what are the features that are least engaging. Some of them might be essential, but how essential are they, and what can you remove, can be a very useful heuristic. Of course, maybe 30 is too harsh a number for a product that's already in use, but you can just keep thinking about how can you, with every second cycle or every third cycle, how can you revise things and how can you just clean up stuff that is no longer being used?

Availability bias and the hedonic treadmill

[00:11:13] This one is availability bias and the hedonic treadmill. Availability bias says that when something is in front of us quite often, we will be able to recall it quite quickly. That's why marketing shows ads again and again. That's why people say that you have to be exposed to a brand n number of times, you have to be exposed to a concept n number of times before you can internalize it, because what you're checking for is availability bias. Of course, if you have seen something months back, it might not be as top of your mind as something that you might have seen yesterday.

[00:11:52] The same thing with exposure is hedonic treadmilling: the more often you see something, the lesser the emotional impact is. So when you are building something it's very useful to think about this curve, where if I'm being exposed to a stimulus for the first time and it needs to hit emotionally, it's probably going to hit emotionally hard the first time, and the value of that will decrease. So the delight that your user might get from a singular interaction that you have very beautifully designed might be the highest the first time, and after some time they'll just get used to it.

[00:12:31] But the more frequently they are exposed to something, the more they're going to remember it. So it's very useful to think about, okay, which feature falls in which category, or which part of my experience falls in what category? Where do I need to pace myself and where do I need to just lay it out there because I don't need the emotional component here, I just want people to remember this thing? So yeah, asking yourself what behavior needs to be remembered and what needs to feel impactful is super useful.

Where is your maxima?

[00:13:02] This is a concept from mathematics called: where is your maxima? Maxima and minima are regions where any function takes a maximum value or a minimum value. So if you look at this graph, you have a lot of different maximas. If this was your entire region, there are six different points where there are maximas.

[00:13:26] But in product design, what I have seen is you'll generally get stuck in a particular region and your iterations can only bring you up towards that maxima. So if I am in the rightmost part, what will happen is I'm probably going to iterate my way to the peak, but I can only iterate my way to this peak, I can never iterate my way to the global peak.

[00:13:53] This is why sometimes when people are designing things from zero to one, there is a tussle where somebody thinks no, we need to go in this direction, and another person thinks we need to go in that direction. And if one person suggests, oh, let's just iterate and test it out, the person who is opposed to that idea is like, no, but that wouldn't solve it. And this is my understanding of why that wouldn't solve it: because when you're choosing the region, it's very hard to figure out just via iterations whether you are even in the right region. How do you even test for it? So when you are stuck in a problem and iteration isn't solving things, it's very useful to think about, am I stuck in a local maxima?

Double it or halve it

[00:14:40] One of the solutions that I have found for this comes from, if anybody has played the game Civilization, this quote is from Sid Meier, who was the designer of Civilization one, two, three, four, five, six. He says that when you're designing any system, especially initially when you figure out okay, this is where the error is coming from, don't try to go for, I'll change it by five percent, I'll change it by ten percent. Don't make those small changes. Double it or halve it, because that will give you actually the direction of, oh, do I need to decrease or do I need to increase? Only then should you start iterating, because iterations only move you in small steps, just like we discussed in the maxima conversation.

[00:15:28] So now here, for example, if this is your original area, if you double it, it goes into a different region; if you halve it, it goes into a different region. This will give you the right, quote unquote, direction to move towards. An example of this is, sometimes let's say you have a menu, and you have a menu with five options, and one person says, oh my God, five are too many, and you do four. Does that really give you an idea of whether four was the right amount or not? I would doubt that it gives you clear data.

[00:16:05] A lot of these two lenses are about getting crisp and clear data about what is the right direction to move in, so that you can iterate even better. And halving it, so for example if you have five options and you just give two options, does the interaction rate increase for both of those options by a significant amount, or is it such a minor change that you realize, oh okay, it's not the number of options that is the issue?

[00:16:36] It's easier to implement some of these things in particular solutions. Here, if you were building a strategy game, it would be very easy to change, if you're thinking oh, ten is too many tiles, let's make the tiles five, is it moving the game in the right direction? Or let's increase the tiles to 20, and is that making the game better, what kind of gameplay is emerging? Of course in the context of games this applies differently, but I have found that especially in the micro design spaces for my products, this technique really works in clearing out what can be solved by iteration and what needs to be changed up completely. So the other question you can ask is, is this minor iteration going to give you a clear answer for your hypothesis?

The learning loop

[00:17:23] This is the ninth lens, coming from psychology, but I have seen it much more in the context of making games. It's the learning loop. When you encounter anything, you have a mental model of it: this is what this thing is. Then you take an action. Let's say I look at my mic, and I have a mental model, oh, this is a mic, it has some buttons. Then I might connect it, start speaking. There's an impact: something gets recorded. And the feedback is, then I can hear and change the settings in my mic.

[00:18:06] What this loop results in is: I have a mental model, and by acting and getting the feedback, seeing the impact and getting the feedback from that action, I can update my mental model. You can have, oh, my mental model was correct and I can reinforce it, or my mental model was wrong and I can evolve it. This is how learning happens. You encounter a problem, you take some action, you think oh, it's going to be solved like this, and you realize did it or did it not, and you just rotate through that.

[00:18:39] What's interesting about this entire thing is that you realize people are constantly evolving. So often when we are designing for users, when we are designing for personas, we think okay, this is the person, this is why they're going to come, and we don't think about, okay, how is each and every interaction with my product going to change their behavior? The first time a person comes to your product is very different from the third time they're going to come to your product, and from the tenth time they're going to come to your product.

[00:19:06] It's very useful to think about, okay, how can I design for an evolving customer? And thinking about what actions will they take, what impact will that have on the system, and then what feedback are they getting so that they can update the mental model? The relationship between I took this action and so it did this gives you clear feedback. Sometimes when users are asking, huh, I don't know why that happened, what did that do, that is when you have a feedback problem or an impact problem, and it's useful to categorize those questions in those ways.

[00:19:41] If you can fit that into the model, you can try to design your product in terms of a user who is evolving through each interaction. This is hard. This is not how most product design is done, at least whatever I have experienced, this is not how it's done. It's also impossibly hard when you're trying to make games, because it works when you have a linear experience and products are not. But it's useful again in small snippets, and I've been able to use this, I've been able to construct more robust behavior loops for people.

The lens of play

[00:20:14] And the last lens is the lens of play, of course. In the previous lens we talked about learning, and learning happens through play and it happens through story. Story is, we look at other people's mistakes they've made and we learn from that. Play is when we do things not in a space of stress, not in a space of threat, but in a space of, I wonder what will happen here, I'm doing things just because.

[00:20:45] One of the benefits of making products is products are interactive, and interactive things are inherently fun. People like to be engaged, people like to do things. It's very useful to just think from the perspective of, how could I add something that is playful and leverages the interactive side?

[00:21:06] One example here is this wireframe of a design that I did. Almost every product that you encounter will have some of those, these are five slides of the introduction of our product. But what we did here was, we had an analogy. This was a mental health product, self-improvement oriented, and we were trying to build this idea of, this is going to be challenging, this is going to be hard, but we will support you, but it will feel like climbing a mountain.

[00:21:37] The interaction here is you put your hand on the ball and you drag it upwards. You don't slide through different sides, you just drag the ball upwards, and at some point there is a tiny dot that represents the product that comes up, and you just climb to the top. The interesting thing is, whenever we showed this thing to people they were so enthusiastic, they really remembered this part of the onboarding and they were like, oh my God, that was so fun, and I realized oh, this is what's happening and I've never seen that before.

[00:22:15] That made me realize, especially coming from somebody who makes a lot of games, how little playful interaction exists in the realm of products and how much space there is to add more and more of those. So just asking yourself, can I add a playful element somewhere in this interaction, somewhere in the sequence, somewhere in this flow, would really elevate how your user experiences your product. All right, so thank you, that was me, and you can find me online in these places, and I'd be happy to have questions.

Q&A

[00:22:50] Host: Great, thank you very much, Divya. That was a stunningly beautiful presentation, as well as very good on content, so thank you very much.

[00:23:00] Divya: Thank you.

[00:23:00] Host: Just a reminder for everybody, if you have any questions please post them either on UXDX, the website there, or on any social platform that you're watching on, and we'll pass those questions through to Divya. But while you're thinking of your questions, I'd like to start off. I thought the blind spots one was really enlightening, because it's highlighting that you don't see the inverse. But how are you supposed to empathize with people when you don't? I know you talked through some tactics, but particularly if I'm looking at the example you gave of being more cooperative, I think was the word you used. How do you recommend people try to snap out of their inbuilt biases?

[00:23:46] Divya: I can give a personal experience. My game design personality is on the cooperative to competitive side, I'm very much on the cooperative side, I do not like to be competitive. So if I am designing things where I want to create multiple players in a system, what I can think about is, I can naturally think okay, when everybody works together this is what will happen, because that comes empathetically to me. But if I say, okay, so I would take this action if I was trying to help this person, what if I did not take this, what if I did the reverse? How would the game accommodate for that? What happens when I'm trying to break the system rather than trying to work with the system? So just, whatever is my instinct, the inverse of that, and what happens. Of course, that's why I said it's a very hard exercise to do, but just doing it a few times at least helps me design better.

[00:24:43] Host: Brilliant, yeah. It's like when people say, how would you, if you were a bad actor, how would you use this in a negative way? And then the local maxima, I love the graphic and the example. How do you get, because I've read as well, okay, you want your experiments to fail, you want them to be so challenging that if they actually pass then that's a really good sign that something's happening. But how do you, if you're a designer and you're trying to pitch this to a team, they might be saying no, that's a bit too extreme, like your example of let's halve it, so what happens if we do that and it goes bad? So how do you try to encourage people to take that step or take that risk?

[00:25:39] Divya: So there are two parts. Thankfully I have worked in small teams with people who it's been easy to explain some of these concepts to. But generally, even when I was working with slightly larger teams, what has been useful is just first sitting and helping people understand the theoretical framework that I'm trying to go for. It's very difficult to convince someone, oh, I'm doing this because it's my taste, or I'm doing this because I feel like it. Nobody wants to go with you. But if I can explain, okay, this is the theoretical framework that I'm trying to use, most of the times people are willing to give it a shot.

[00:26:16] Divya: Especially if you are willing to also accommodate their frameworks, because that's what's going to happen: if you bring something up they will be like, no, but I'm thinking about it like this. And just being adaptive at that moment, that's also how a lot of these things have formed. I worked with people who had different models, and then, okay, how can I incorporate their model within what I am doing and refine my thinking? So I guess rather than trying to think about conversion or convincing someone, I think about, okay, this is how I can elaborate and explain to you why I'm doing this, and then what do you think about it?

[00:26:52] Host: I can't hear you, sorry. That's a great suggestion and model for people. If you do have any other questions out there, please just keep posting them in and we'll put those onto the UXDX Community Slack group. But I think that brings us to time now, so I just wanted to thank you, Divya, for sharing all of your insights.

[00:27:13] Divya: Thank you so much.

[00:27:15] Host: It's really lovely.