Designing For Growth | Benjamin Berger | Skillshare

Designing For Growth

Benjamin Berger

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
15 Lessons (53m)
    • 1. Introduction

      1:17
    • 2. What is Growth?

      2:34
    • 3. The AARRR Funnel

      4:36
    • 4. The Growth Mindset

      3:40
    • 5. Creating a Funnel - Part 1

      2:45
    • 6. Creating a Funnel - Part 2

      4:45
    • 7. Research

      4:58
    • 8. Brainstorming Problems

      4:12
    • 9. Brainstorming Solutions

      3:31
    • 10. Writing Hypothesis

      2:59
    • 11. Design Experiments

      8:43
    • 12. Experiments Tips and Tricks

      4:23
    • 13. Increase Confidence

      1:25
    • 14. After the Launch

      2:27
    • 15. Conclusion

      0:55

About This Class

In this class, discover the role designers can play to move business metrics. Learn how to design with a growth mindset, using practical framework to define your growth project and run experiments with a high rate of success.

Any designer, product manager, entrepreneur, building software and new to the term “growth” will discover a new way to look at their work.

Materials required

  • Any design software (Sketch / Adobe XD (free) / Figma (free)
  • Sign up to Whimsical.co to create your funnel (first project free) 
  • Download the hypothesis template to brainstorm your solutions 

Transcripts

1. Introduction: Hi everyone. My name is Benjamin Bergen. I'm a digital product designer, currently working at wix.com. Today I'd like to talk to you about growth. What does it mean to design for growth? What can we do as designer in this area? For more than the past four years, I've been working with big companies, small companies. I've been even creating my own startup, and I've seen that this is a concept that is often misunderstood by designers, and I think that there's a lot to learn in this area. I had the chance to join the growth team of Atlassian about three years ago, and I spent two years in this team, shipping experiments on huge produce, like bit bucket and Jira Software. I've been able to experiment a lot, and test a lot walking in an amazing environment with a great team, and I've seen us failed and, I've seen us succeed. Today, I want to share with you some of those learning. I want to talk about what it is to design for growth. What is growth from a designers point of view. I want to help you adopt the right mindset. I want to help you understand what is the process step-by-step to design your own growth experiments. I really hope that by the end of this lesson, you would have known a lot more about this topic, and I would have enriched your process as a designer. Let's get started. 2. What is Growth? : Let's start by understanding what is good and why should we care as designer. In most companies, growth and design doesn't seem to belong together. Designer, we mostly care about the user and the user experience whereas growth is all about the business side of things. It's about increasing business KPI, like active user or the revenue. As designer, we tend to think that in order to achieve that, we need to compromise on the user experience. We need to create dark UX patterns that are going to trick the user into doing what they don't want to do. But there's actually much more and I personally believe that as designers, we need to understand the fundamental of business, we need to understand the business model of the company in order to create a product that will both benefit the company and the user. Growth before anything else is a mindset that we need to adopt in order to take better design decisions. Usually when we talk about a product designers work, most of the time what we refer to is actually some feature work. By that, I mean creating something new inside of the product or fixing some bugs, improving some existing functionalities. That work is actually all about solving a user problem. Usually when we start, we defined some users needs. In other words, it's all about creating some direct value. When we do growth work on the other hand, I personally like to define it as a new layer on top of your product. Something which aims to connect the user to that value that you've created to your product. This connection can happen at a lot of different points. It happens in your marketing assets when you acquire new users, but it's also happen directly inside the products when you on-boards your user to your product on the first time expanse. Or when you launch a new feature and out of your user have to discover this new feature. That's an area when I started working on this, I initially thought that not working to create new value would be something very frustrating. But what I've found to be even more frustrating was knowing that I have some great products and great feature that fix and solve a lot of problems and aren't so very good needs and knowing that's actually no one on show you that. There is nothing worse than a product that doesn't have user, so growth and feature works are the two key parts of your product that he needs to go hand in hand. 3. The AARRR Funnel: There's a great framework that we use when discussing about growth that will probably help you practically understand where you can operate as a designer or what you can do to impact growth. We call that framework the double A triple R funnel. It's a nice framework that sum up the different steps of a customer life cycle. It's tense form. The first A is about acquisition. Acquisition thinks of it as anything that happens outside of your product. Like those social media ads. Your landing page is about acquisition is basically when a user just to learn about your product and you're trying to get him, it's the very first step of the funnel. Usually it stops at the Sign Up button. Once a user have sign-up, we say that acquisition has stopped and you've succeeded that step. The next A, is called the activation. Activation is the process of turning your new user into active one. We associate these parts to the onboarding. That's the most known part of growth and that's what a lot of people talk about when they say designed for growth. It's about activation and it's about the onboarding. In other words, the first user experience that you have inside of the product. Don't think of onboarding as a way to just point out to each of your feature, was putting dots and in log dialogues. Instead, try to answer this question, what is the co-value of my new user interested in how to deliver it as fast as possible. That's what activation is all about. The next step is color retention. It's about the stickiness of your product. Do you user come back regularly? This can be associated to the direct usability and the value that you'll provide on your product. So this is very close to what we do as a designer and very close to feature work. If you have great features, retention is probably going to be higher. There's also a bit more to it. You can think of it as different channels like e-mails. How do you get people to come back? How do you send or write e-mails to right points? How do you deliver the right information to have people come back and find the value in what you're offering. The second R is called a Referral. The easiest way to think about referral, would be to think of it as a word of mouth on steroids like optimized for the wizard technology. It's a way to use your existing user as the new acquisitions trim. Using incentives, for example. A good example of this is Dropbox and very famous for their referral campaign. They offered any user some additional storage space in exchange of sharing Dropbox and getting more user to try out and to sign up for Dropbox. The last step of the funnel is the Revenue. This one is all about monetization. It's all about your business model. For designer, this will touch mainly the pricing pages and to check out flow in products. Cell touch points. If you have a premium model, how do you transition from free to paid? This is where a designer will touch on the revenue. That's the growth funnel. Double A triple R. This covers most of the steps of what a customer will go through when they hear about your company up to the point where they become a paying customer. So that's your goal. Of course, this is a funnel, so this means that every time you're going to bring a lot of people at the beginning and each steps and they're going to decrease a little bit. The game of growth is actually try to patch those holes and to make sure that, that's the least amount of possible of user who turn from one step to the other. Of course there's a lot more that you can learn to every steps if you're interested in the marketing or the business aspects. There are very interesting things to learn on this. Everything is to be treated differently because those have different topics. But we're going to see in the next lessons what type of process you can adopt to tackle each one of those. All right. Now that we've seen some of the fundamentals. In the next lessons, I really want to go more deep into the actual process of designing for growth. 4. The Growth Mindset: During my first year as a designer, I would sometimes stay like hours looking at my screen, wondering if I've found the best absolute solution through a program. This is actually the worst type of mentality you can have for successful project. We are always looking to create like at least a dozen different solution to the same project problem because every solution will be very relative to the context of our product, to our user. We always want to try to optimize for different type of things, see how things would look like if we take it from a different angle. This is especially true when we work for growth. We can never be 100% sure that the Chancery Law is going to have a positive effect on our user. We can never know how they're going to respond to that. It's always a game of test and iteration. Constantly try something, get something that iterate, try again. In order to embrace that uncertainty, when we work for growth work, we use a methodology according to scientific method, as an ongoing process. We're going to see right now what it looks like. All right, so this is the method. I've rearranged the original one used by scientifics to fit a little bit more for our design work. You can see that it's divided in four steps with one in the middle. The first one is the research on top, then we go down to the hypothesis, then to the experiments, and finally the implementation phase. Those are the four steps of a growth project life-cycle, basically. Let's take a quick example to make it clearer. Let's say that you're working on an app and you'll have this feature that no one is using. First step is that you're going to understand what is happening and why is it happening. Those are your research, and as you do that, you're going to try to come up with some reasons. You're going to make some supposition on why no one is using that feature. Those are your hypotheses. Then the next step is you're going to come up with some design solution that you're going to launch on your products as experiments to verify whether your hypothesis is right or wrong and whether you can have more people to experience this feature. If the problem you'll find out during your research is the actual problem and the actual reason why no one is using that. Then you'll have some results and you'll see whether or not your hypothesis was right or wrong. If it's wrong, you're going to start again, if its right, then you can implement into your real product. Experiments are the main tool of growth designer. This is basically all we will deliver. They are very much like A/B tests, there are a different version of your product that's going to run against your current product. They're going to run in parallel on two different sets of user and you'll be able to compare how they work one against the other. On AKV test, we call them growth experiment because they are going to touch a lots of different things inside of your primitive data into change, many, many variables. Whereas AB tests they usually touch only one little thing like the copy on a page or the color of a button. They are much, much smaller while its growth experimental are much much bigger. Now that we've seen what the process is on a high level, in the following lesson, we are going to go much deeper into seeing how we can create that experiments. What are all the different steps that we can go through? 5. Creating a Funnel - Part 1: As we've seen previously with the double and triple our framework, in growth, we like to divide things into a funnel by chronological steps. While this framework is very under Maxwell developed the customer life cycle, we can reapply the same ID really at any steps inside of our product on very micro level. Basically anything can be a funnel. Think of you creating a new feature. You can really think of it in terms of acquisition. How do people discover the feature, activation, what is their first experience, retention do they come back to it and so on. So this idea of funnel is really key to the methodology and the process of growth. We will constantly get back to it. So before we can create any funnel, we always need to answer the question, what does success means? In other words, we need to define a success matrix. This is particularly important because the scientific method that we've seen previously only works if we can measure the success and if we can say if an experiment was positive or if it was negative, so to do so we need to have some success matrix. In design, it's really, really hard to measure anything. That's why we use a business KPI must have the time like an active user rate or feature usage rate, and we're going to use data. But in other words, you can think of it, that's where a funnel can also really be just a customer journey maps. You go from point A to point B and your success metric is point B. It's the point where you want the user to go. If you don't know where you want the user to go, it's really hard to do steps, to go all the way step-by-step. Your funnel is your customer journey and your success metric is the finial stage of your journey. I've prepared a case study for us, some example to go through each step of the process together. In this case, I've designed a fake e-mail app and the goal is to increase the activation and the engagement rate of the application. In this app we have this cool feature of smart folders, where the user can create a folder and basically add some rules to filter the email and be better organized. We've seen that the usage of the feature is pretty low. But of the user who used that, they have a high engagement and high activation race. We see some correlation. The project is to see if we can lunch some experiments to see if by increasing the engagement with the feature, we're going to increase the overall active user rates. That's how we're going to define those success. 6. Creating a Funnel - Part 2: I've put together the app in InVision to simulate the interaction. We can create some new folder, we get the model, we can fill it up. When we create the new folder, I have this little notification here and everything's been created. Let's get back to the beginning. What I like to do to create the funnel is, I use this app called Whimsical. It helps you create user flow very easily and I can go and create step-by-step. I am going to use that for my funnel. The first step is, I'm going to create, to define my user. Very important to not have very weird and very long monstrous map at the end is you start, you define your user. Here we're going to put together this, and I'm just going to put some text. Lets put it in small. My user is a user who has set up the account, but has never created any folder. That's my user. What is the user intent? Is basically what is the goal of this journey. The intent is the user wants to set up a smart folder. That's going to be released to basis. Here let's make it look nice, have those two things. You can put both of them bold, here with set up. Now the next step is to define success. As we said, what is the end state of might show in here? The n step will be, has created folder with smart rules. Let's put that, nice. Align this. Here we set up, we get the user state and we get the user. Now it's just about creating the story. Usually what I do, I just go on the tour, I take a screenshot so you hit Command Control Shift 4. Here I get my screenshot tool. I just take a screenshot, I go to whimsical, its pretty big. Reduce that. Then I have my first step. Now next step and put this around, is going to go over here. This is one of the entry point for the folder so I come over here, I take a screenshot same way. I go to whimsical, reduce the size, put them all together, then here just press "C" to create a connector. Select one screen to the other, I add text, use over on the button. I'm going to do this for all of the steps of my training. Over on the button, click on the Popover, over on the new button click there, have the model, fill out the model and create the folder. That's what's made showing this link to be like. Here I put them together over there. We see the training we have those two entry point over here. This is particularly important because these artifacts, you're going to be using it in every steps of your process. That's very, very important to have your funnel defined. Another thing I like to do is to have the small conceptual ID. Like define each of the steps, they all have different concept way. This one, for example, I like to call it the discovery. This is what we said is the acquisition, for example, from the direct super R. Here I put discovery. Let me choose a different color. Here we have the creation. Here we have to pay attention or the engagements with the feature once they've been created. There we go, we have our funnel, each of the steps have been documented. Now we're really in good place to keep working. 7. Research: A common problem I've seen with many growth theme, is that because we work with hypothesis and we test a lot and we work very fast, we tend to forget that research phase and we go straight inside the ideation. We try to generate as many ideas as possible, and that's all we care about. But the problem with that is that not every idea should be treated equally, and that's not because we can test, that we should test everything. The way I tend to see it is that, imagine you're trying to shoot something in a dark room. You can either try to shoot in every possible direction and really hope very hard that you're going to create it, or you can try to understand the room layouts. You can understand where's the light switched, turn on the light, and then throw something much more precisely. For me, that's what research is when you're doing some growth design. There's really two main types of research that you can do, we call it quantitative and qualitative. The first type, quantitative research, will be your data analysis. We often say that it is what is happening, because it's really describing. We just know that this amount of people went from one step to the other, or this amount of people click on that button. The second one is called qualitative research. You can understand them as anything like talking to your user, user interview, usability session, user feedback, or application review that you receive, really anything coming directly from the voice of the customer. We call it the "why", because it help us understand a little bit more, why is something happening. Those are really this quality insights that you receive. Of the two type of research, qualitative one are the most overlooked usually in growth themes, mainly because they are not statistically significant and they can be very hard to perform. But I personally think that they are very important. They're really the place where you can shine the most as a designer. Most too often the growth project are started from a business side. You're going to think, how can I increase this feature usage or how can I increase this engagement rate? You'll just think about the business side of things. But you can really shift the question, just like you would do with a feature, you would think, what are my user needs? What are the problem we're trying to solve? You can do the same for growth, shift to question and think, how can I connect them to that value? What value are they looking for? Are they in univariate mode? Then, what are they looking for in that product? What is the feature that I really need to show them? In this case, the user has some real problems like, how to receive my e-mails, how to read them with the best experience possible, how to stay organized. All of these, those are what's the product concern, you've defined those needs and you've solved that problem with your product. During the first experience when it's come to do a growth project, you can shift those problem to become, how does this solution answer my needs immediately? Can I set up multiple accounts? Is it worth my time going through the setup? Can I trust this app? This is where those user interview comes in handy. You can even define some evaluator profile to understand different type of user and do some experiment to see, what does this mean to design for this evaluator or to design for this evaluator? You can understand which one of your 20 feature you should emphasize on during the first trial, for example. Don't waste time trying to test 20 onboarding that are going to focus on one different feature, but instead do some research and understand which one is the most valuable at this time. Then you can test 20 different experiment to do a variation on the specific feature. Now that we've performed all of those research, I've added every bit of information onto our final map. This is the same as before, except that you can see all of those things are there inside together. In yellow, those are the user interview pieces of information we've extracted, like when they asked how they organize and find out e-mails, the user mentions such, for example. In blue, I have all of those data, quantitative information. Twelve percent of all user interacts with these feature. This is the number we want to move really. Each of the steps, I've added new information. Here in red, I've added the churn data. Here, the user who opened the model, 58 percent cancel without an action. This is pretty interesting, people opened the model, but they don't do anything. What can we do to increase that? We have this information that we've added all the way through, and this other facts we're going to use in the next step. It's very important for the brainstorming in order to create some very powerful hypothesis based on those facts. We'll see in the next class how we can use this as a group together to create some solutions. 8. Brainstorming Problems: Now that we've created this trunk funnel map, I believe that the hardest part of the process is done. We see clearly, we understand the current state of the product. We understand how the flow look like, what people are doing, their action, and we even get some insights on why they're doing that. So we've done the research phase and now it's time to think of some hypotheses to supposition about what we can do to improve the funnel. I would like to do that in a brainstorming. In the brainstorming, it's usually very important to include one representant per crafts so a designer, some product manager, some developers, any person who is going to have a different perspective on what we're looking at. Always start your brainstorming with a presentation to introduce everything that you figure out during this funnel to make sure that everyone in the room has a fresh idea and have one of their [inaudible] in their hands. Then you start by brainstorming some problems. Before going into any solution it's important to really define the problems we're trying to solve. Finally, we're going to the solutions and we finished by refining things. Always try to prepare your room before you do brainstorming. What I like to do is to set up our funnel map onto our wall. I think it's really powerful to have people walk through the funnel to get to understand the topic, what we're walking on in and what we figured out previously. In order to brainstorm some problems, it's always very important to start with direct question. I have a simple framework that I learned in order to ask a good question and it's based on three steps. The first one is to create an image to get everyone to think with empathy and to put themselves into users boots. The second one is to expand on that image to keep the participant engaged and keep on thinking and the third one is to ask a direct question. What does it look like? Is asking. For example, imagine that you are using your e-mail app regularly. You feel overwhelmed with all of your e-mails. So you're building that image. Then you expand the image, you continue with different examples. Finally, you ask the direct question, "What prevents you from creating better organization for your emails?" "Why don't you create those smart folders?" That's the direct question you want to answer. All the way through that question you've built up up to that last step and then have the person who walk the wall, the funnel and adds some are posted to it. Add the problem and bring some altogether on this. We've brainstormed with our team on this funnel. We've adjusted the data and now we've formulated what are the program that we actually need to solve. We've transformed those insights into problems that we're going to walk with. If we look at this, we had this discoverability issue. Very few people actually use the feature. We've understood that icons are not very well understood. This is what we're going to have to solve and these default folder over there, no-one is clicking on this, no-one is opening that. That's another issue that we'll have to figure out a different solution for this. Over there we were talking about that model. Here people didn't quite understand the value or they're not sure what the feature is for. Maybe there's something we can do here in terms of hierarchy, in terms of explaining what you'll have to do, what you can do, giving some example. Those are just some random solution I'm coming up with but the point is that we figure out what is the problem that we need to solve and that's the most important here. I just want to share with you this model that I really like. It's called the Fogg Behavior model designed by a professor at Stanford University. Basically it puts into two different axis, the motivation and the usability and I think it's pretty interesting to see here what's he divide is that sometimes you can have someone with lots of motivation, but if you don't have the right amount of usability, the action will never be performed. So you really have to find that right balance and understand when is it a motivation problem and when is it a usability problem and I like to divide those program into those two categories. It's really helps me to understand what I'm trying to solve. 9. Brainstorming Solutions: We've made a lot of progress and it's finally the time to get to the solution and generate some ideas. Let's the creativity flow. When it comes to solution, I like to differentiate them into two different parts. The first one would be the optimization. The micro-improvements won't have a huge impact, but also don't take a lot of risks and sometimes they're necessary to create a great product and to remove some friction inside of your Fenner. So inside of this, you're going to want to revisit sometimes the hierarchy makes sure that you're using AR messages everywhere that you have the rights labels, the right placeholder everywhere, that you're using the right copy for your button and on the other hand, the solution would be the disruption parts. So those one would be much bigger, so we can already talk about experimentation in this case because we are not very sure that the impact is going to be as expected. It's much bolder change, much different experience that we want to try out, and that we expect to have a positive impact. So how to decide between those two type of solution? most of the time is going to come down to how much traffic you have, how many experiments can you run, how long is it going to take to get some results? because all those small improvements there might not be worth your time, if you are going to have to run your experiments for four months before getting any results. Also, another thing to consider is, can you take a lot of risks? do you have a user-base, so can you try to disrupt them or not? That's very important to consider and finally, the last thing is how long is the effort's going to be How much developers do you need to create those solution? and how much time do you have before you want to solve that program? so all the things to consider when brainstorming some solution, but we can very much and decide to brainstorm any type of solution first, and then segment them into those different types. To brainstorm the solution, I really like to walk in small loops of two-minute. Each participant has a post-it note and no shopping and the goal is to generate as many ideas as possible and stay very high level. During the first loop, you want to have everyone walk very freely and put everything out of their mind, and then you can create another loop where you're going to add some constraints. So think of what it is to walk if to design the solution, if you use social proof or what it is to design for curiosity and you can even create your own constraint. Imagine using your own persona for your product and say what it is to design for this person specifically, or to create one loop per program that you've identified and once you've generated all of those ideas, it's time to share them and use those votes to figure out what you want to take further. So you're going to end up with a lot of solution and as you go for each steps, you'll want to reduce the sum to really just focus on the most interesting one. Finally, it's time to pick the one that you're interested in taking further and write down the hypothesis for them. So the hypothesis is using these three key points, is first you write the solution, then you refine what is the success metric and finally, what are the evidences that justify this solution? so we're going to see in the next lesson how to write down this hypotheses for our case study. 10. Writing Hypothesis: We've brainstormed some solutions, and now we've come up with some stuff that we feel pretty comfortable working with. The next step is to make sure that we create some very good hypothesis. So I want to walk through the steps with you and go through the process. If you remember, we had this screen, and this one we said that we had some discoverability issue. We said that this button is not very well seen. Same goes for this button over here and this default folder is not very used. The process for writing any hypothesis is like this, so we've always start with, we believe, and then we write the solution we come up with. Let's say we believe that changing the icons and removing the default folder and maybe making the CTA more prominent. That would be our solution for this experiment. Now, let's say what is the success metric? What is the results? The results is going to be, increase the feature discoverability and then increase the feature usage. Finally because. Why do we think that this is a good solution? What are the evidences we've seen? User told us, and let's put that in bold, user told us that they don't understand the icons, no one is using the folder. The last one is that the feature is not being used a lot. Here we go. We have our hypothesis and we're going to be able to work with this. I prepared a few more hypothesis for us to work with. Let me walk you through them. The second one is about this trend that we set, we believe that explaining that the folder free up your time, and this means that explaining the value of the feature when the user gets here, will result in increase of feature usage because the user don't interact and don't understand the features. That's the evidence that we've seen, the data that we saw. Here we want to do a lot of work on this screen. Finally, this one is a bit more exploratory at some and this is taking advantage of this search. We discovered that the user used the 'Search' feature a lot when they're lost in their immense, so we believe that this is a good opportunity to increase the discoverability and usage of the feature, because those two features are related. This is the three hypotheses that we get. Now let's see how we are going to design the screens. 11. Design Experiments: Here I've recreated our final inside of sketch so you can see how it's screen step by step, the same way we had on our final map before. The first thing we want to do we need to understand which screen we're going to modify and at which point up to final we're going to have some design changes. In this case, we know that we'll have some changes in the sidebar in the homepage because this is the start of the experience and then I'm going to have some changes on this page on the folder. Then we said about the search, so this will be in this area. I prepared the screen on another page. Here we have everything. I always like to put the hypothesis close to me when I work so I can always get back to it, make sure I've got to the essence and I really make sure that I'm designing for this hypothesis. In this case we said we want to change the icon make them more prominence. This is a layer that we want to change. We can just remove it or remove that and I've prepared the assets over here. Here what I want to do is I'm going to put the sit here, a bit more prominence over there as a secondary action. We put that here, we're going to move out of that sidebar a bit down so on to keep a nice grid. The other thing is this icon that we said no one really understood what it meant, and we can blame them because it's just a plus. We've changed it to actually have an icon with a plus on it. This should probably have some positive impacts, so we get this over here and over here we get our first hypothesis. We've changed into label and we think that this one could have some positive impact. Now let's see about the next one. Same process, same thing, over here we believe that explaining that the folder free up some time, so giving operator a bit of value and there's also a bit of clean up we can do probably on this cause we see there is not very good hierarchy. We don't know which field is mandatory, so I've already prepared something, a little bit more cleaned up. I'm going to put this one over here and just center it. But here we get this mutator here. We see this folder, the name is mandatory, so we'll put the asterisk. Maybe here we can also add a label to say attachments. Here we've already improved a little bit of the hierarchy. Another thing that we want to do is we want to add some value. I think what could be interesting is to think of what we could do if we were to create first steps. So let just depict it that and have some sort of mini onboarding under feature. If we remove everything, what we could have would be something like maybe: let's keep the data just remove this, let's uncrop that. Let's say, "Smart folder helps you free up your mind". That's our first value. Let's add another thing. Let's say, "Create some rules, never get lost and organize your e-mails". We add a subtitle. Let's change this to regular. Let's put a smaller side "14", so we a subtitle. That's something that we could experiment with so I'm not going to design everything right now. But we could say, what if we had some templates? It's like this is my work folder, this will be my family folder, create your own. This way we could start by saying, start with one of our template and this will help us get started off, start by creating your own and this will move to the next step here, "Create your own". We would have basically this work folder. Here we fast forward into the step of the final. If I say click here, I got directly to the final step. If I click here, I will go to the top. This could have some interesting impact. This is how we can with a small experiment change a couple of things and expect to have a positive impact based on our hypothesis and our research. Finally, for our last experiment, we were talking about this search thing. I think that's what pretty interesting that we believe that when a user is searching and we said that we filter the e-mails in the search. This could be a great opportunity to focus the value and highlight that we have this feature that can basically create, use your search query and put it inside a folder so you never get lost and you always have your e-mail organized. Here what I've done is this is the right place where we can have this type of onboarding pattern or highlight the value and try to find some nice warning to go with. In this case, this is exactly the type of onboarding pattern or cross pattern that we use and what we want to do is make sure that they come up at the right moment and they can really deliver the best value to the user not just annoy them, that would be the worst thing that we want to do. Here I think this is much older type of experiment where we try to segment the user and give them the value at the right moment. That's pretty much it about how we can design those experiments. A very interesting topic to discuss about when talking about designing for growth is how much designing is enough. My personal rule is to always design at least the 80 percent. The reason for that is, first of all, quality have a high rate of success and you really want to make sure that you don't misjudge to potential of your hypothesis based on the results of a poor execution. You don't want to ship something that takes the risk of coming back inconclusive because there was some hierarchy mistakes, there was some small things here and there that's creating some noise and adding some new friction. The other thing is that when it's going to be time to implement, you don't want to move too far away from what you just designed. You want to make sure that you reproduce the same thing that you had on the experiment. That's why don't just design a little bit and think that you will have time to come back to it. The last thing is, I tried to leave aside all the superfluous. The thing that are not mandatory to answer whether this hypothesis is right or wrong, I tried to leave them aside. So sometimes it's going to be the last polished finish on the design and It's okay because we'll be able to add those ones later on when we know that this experiment is a success and we want to ship it in production for sure. 12. Experiments Tips and Tricks: Before we finish on this design part, I want to conclude by giving you a few tips and tricks, something that I've learned by designing a lot of experiments and seeing those results. There are really two main things, the first one is that obvious always win in design. It sounds silly but I've seen a lot of experiments that I've designed, a lot of different screens and most of the time whenever I could think someone might not get it, or it might go wrong, it always went wrong at some point for some user. Obvious always win, try to always be obvious in your design. The second thing, and that's a big one, is that I've always seen that the concept is way more important than the visual part. So no matter what you want to do in visual, no matter how many tricks you want to apply, if your concept is not right, if you're not showing design at the right moment, if people are not interesting in performing the action, no matter how many tricks you're going to apply, it's not going to work. Let's see that with a few examples. This is a great case of obvious always works better. In here we use often this type of empty states on part of our product, and we sometimes don't want to put another situation because we already have in the hierarchy of our product, this immensity here. Most of the time I've seen user interacts with that, they try to click on this because there's a plus here, there's an illustration and they just want to perform an action. They're not going to go the extra step into trying to figure out your interaction model or your user interface model. In most of the time, what you want to do, I've seen a lot of person put this type of arrow like this and not disturbing the product, but really this is not as obvious. I'll just, either put a CTA in there and have the action doubled, and it works most of the time. The other thing is you can have this small tricks. Just remove the empty states entirely, and just integrate that thing entirely inside of user screen. This is the time where obvious always win. Another thing about those concepts, I work on a screen like this one, so we had those two action. Either I start by myself or I go on and I create a team. We really wanted people to create more team because it led to better parts of the product and more things. What we put on those sign up screen is either you start as yourself, or you start with a team and I tried some tricks to make it look more prominent, looks bigger. I can tell you that none of the time it worked. All the time, people who wants to start by themselves, they're going to go through organizing yourself and just perform the action that they want to take. This is a case where the visual could not impact the concept, the user just do what they want. You're going to tell me that this is something that's a pattern we see regularly in some pricing page. That's true that in those case, when I'm working on pricing, this is actually much more complex type of action that just performing an action. In this type of pricing page, the user has to think which one he wants to purchase, which one makes the most value, so he's going to compare different pieces of information. Whereas on the previous screen it's really just about taking an action. I already know that I want to start by myself, so I'm not going to go the extra step trying to learn anything else. Finally, about those concepts, I've seen those onboarding patterns used a bit everywhere. Most of the time we argue about the best visual, should we put a human face in there, stay with an illustration, just choose an icon, use those little tool tips or should we use a banner? I can tell you, most of the time this really doesn't matter at all. Because what's really important here that you provide the user with what they want to know and at the right points. No matter how many tool tip and popup and banner you're going to put everywhere, they're just noise to the eyes of a user. Just try to valorize the concept way much more than the visual. 13. Increase Confidence: We're almost there. We've designed great experiments and we'll make sure that they match our hypothesis. However, there's still a few things we can do to increase our confidence, make sure that we launch the best experiment possible, and make sure that we remove all of those small execution mistakes that could take us the risk to not validate our hypotheses. Let's see what we can do. The first step, I think it's always very important to get feedbacks all the time. As much as possible, get feedback from your coworker. If you can get feedback from me, real user, makes sure that you don't walk isolated and you're constantly asking for those grades information that will help you really answer some of those question and make sure that you're not making any mistakes. The other thing we can do that I really like is those quick usability test. They really helps you remove any type of mistakes that could come down to the execution to make sure that your hierarchy is great, that your content makes sense. Do you get the contrast to nail down? The interaction are all in order. With those quick usability, sometime it's just a matter of putting together a small survey or a small design tasks and asking user to go through them and gathering some results. It's sometimes can take really such a short amount of time, but comes with so many great results. I really recommend doing any of that. 14. After the Launch: We've shipped and we get results. Now what? The first step is to make sure that you've prepared how you're going to get some learning. What interaction would you like to track? It's very important to not to just limit yourself to the success metrics, but look at different steps of your funnel and understand what went wrong or what went right. So you can reproduce those result was another experiment, and if the experiment failed, it doesn't matter. What's important is that you make sure that you learn from it, and that's you'll try every single things so you can have a much better hypothesis for the next time, or that you won't reproduce the mistakes that you've made. The next thing you can do is take your experiments to the qualitative phase, you shift an experiments, you've gathered some new quantitative data. We've observed some new things in the funnel. We've made some changes. Now I like to imagine this quantitative and qualitative research as a ping pong game between the two. You learn, you gather, you understand the new thing that are happening. Now, let us go talk to user, interview them, show them the new experience and understand why they happen this way. Why is it a failure or why is it a success? This is very important to always keep coming back to those two types of research, and finally, what if the experiments failed? It's really not a big deal because you shouldn't treat the experiments as something that you'll want to succeed as at any point. Of course, it's pretty if we manage to move the success metric, but see it as a way to validate or invalidate some hypotheses because that's really the true purpose and the true meaning of this tool in the scientific method, so if it failed, you learn from your mistakes and most experiment fails or comeback inconclusive, so it's really not a big deal, and that's why we always think of going 100 percent when we design them, because we should be able to throw them away if they're not a success. The other part is don't be afraid to move on if the experiment failed and if you've never manage to move that metrics, maybe you're focusing on the wrong part of the funnel or maybe you're not focusing on the right feature, on the right thing at all. Maybe you should try to figure out something else to do, and once again, don't get too attached to your solution. Growth walk is really unpredictable. You never know how users are going to respond to a change and to your solution. 15. Conclusion: All right. We've made it through the end of the lesson. Thank you so much for following through, and I really hope I was able to teach you something here and you get a couple of takeaways. To sum it up, I will say there's those four things to remember. Always do your research qualitative and quantitative, walk with a funnel, it's really important that the artifact that is going to, follow you through all of your projects, define your success metrics, without them, you can't really do anything in growth, and work with hypotheses and make sure that you create great hypothesis and if you follow those four steps, you cant really go wrong here. If you want to create a growth experiments following the lessons of the stresses, I would really love it if you can share it. I can see what you came up with. If you have any feedbacks for me, I really would love to hear from it. Thank you very much and have a great day.