Improve Onboarding, Activation and Retention with a better UX with Peter Loving from UserActive

Victor [00:15 ]: Welcome back, everyone. Today’s guest is Peter Levin, founder of the UI UX agency user active. In this episode, he will share with us his strategies to improve onboarding, increase activation and retention, and his framework on when you need to redesign flows, features, or your entire product. Peter, welcome to the show.

Peter [00:34]: Thanks for having me, Victor.

Victor [00:35]: Yeah, been looking forward to this one, why don’t you tell everybody a bit of yourself your background and of course, user active.

Peter [00:42]: I come from a background of design back in university probably about 15 years ago, I studied product design. This is the industrial kind of product design with 3d consumer products. When I came out of that, I just was really fascinated by the web and the things that were happening at that time. Gradually, I moved over to working in the web. I found that there’s a lot of transferable stuff. I mean, the design processes and the design approach is very much the same. I think a good product designer in general, can translate across to digital product design. I found that really great. I’ve been designing products ever since, and now specialize in software. I run user active, which is a product design agency for SaaS. We design meaningful products, users love and focus on UI and UX.

Victor [01:37]: Wonderful, I didn’t know that you studied product design, like the 3d product design at university. The interesting part is that probably designers who only ever studied more of the UI part, and not the product design part, that’s where this entire research and what is this going to be used for and who’s my target audience, that’s, that’s all kind of the same with physical products as well, right? What people kind of forgot with UI.

Peter [02:04]: Yeah, it was such a good grounding, because you essentially learn to research the marketplace, you learn to identify problems that exist in the marketplace, and really research and understand the people that have these problems and how to solve them. That’s no different from software, it’s completely the same. It’s an amazing background to have. Then also, just think, on the other side for learning about the technical side, I think just understanding a bit of front-end programming and development really helps too. I think a good, grounded product designer should be well versed with kind of understanding the market side of things, and also the technical side, but that bringing to the table, they’re real. They’re out design skills, and their problem-solving skills. Those are the core skills for a great designer.

Victor [02:52]: Now, let’s dive into UX or a little bit, a lot of our listeners are beginning to explore what UX is and what that means for their product, especially when first designing one when first coming up with one but also, when improving UX later on. UI UX is always used very interchangeably, right? You say UI UX designer, you say, I’m going to improve the UI and UX of my product, it’s almost as if it were one phrase. What is UX? what is UX not?

Peter [03:24 ]: Obviously, it stands for user experience. Thinking about how the person experiences your product, it’s really key to think about this user, how will they do things? How will they achieve goals? Thinking about the product, what is the functionality? How does that functionality work? I feel that UX is very much a exercise of understanding the person using the product. Then using your problem-solving skills, your creative skills to enable that person to use the product in the most easy, intuitive and best way. Fundamentally speaking, UX is the process of researching and understanding somebody, and then creating a product that fits them. We do this with on the research side, we do this with interviews, observations, research, you can have focus groups, you can observe how users test something.

But we also do it with prototyping. The core skills here are kind of mapping out user journeys, doing wire flows and wireframes to provide structure put together structure and, and interactions around how the product delivers the results that it delivers. Then sometimes prototyping, which would be interactive wireframes. The great thing about that is that you can start putting that in front of users and observing how they interact with it. If your approach is providing the best experience that could be done. It’s quite a range of tasks, but really the focus here is making sure that the user has the best possible solution to their problem.

Victor [05:07]: There’s a big overlap due to product management obviously, as in terms of understanding what to build, for whom in what order also, and what’s the easiest solution to build for someone who should hire a UX specialist outside of their organization versus who should hire someone in house ideally?

Peter [05:27]: I think it depends on the makeup of the organization. Organizations that are quite adept at managing products and managing designers and understanding the process, for them, it can be quite an easy process to hire in house, particularly if they have a long-term need for this role. They will find that I mean, their experience, they know the ins and outs, and they will find that it’s not so difficult onboarding, and bring that role into their team or their organization, I would say that the organizations that don’t have experience with UX, and they don’t understand the process very well, they need a more kind of consultative approach, because there’s some education for them, that they’re learning a new kind of role and new expertise.

It can be good for them to bring in an experienced person who can come and take ownership of that role and explain and show them how it’s done effectively. It might be somebody who doesn’t need a team structure around them. Another type of organization that could benefit from using an external kind of UX consultant would be someone who just has a temporary need, maybe they don’t need it for the long term. But maybe they have some problem areas in their product or platform. They want to just address these and bring somebody in. One other area that is important as well is if you’re building something new, you might want to work with somebody temporarily when you’re building something new to have that UX expertise, so that it starts off the project in the right way.

It’s fairly complex. I think it just comes down to the organization and their preferences and how they’re working and current time what their requirements are.

Victor [07:17]: What do you see are the biggest mistakes that SaaS founders make, when it comes to UX?

Peer [07:22]: It’s almost like I don’t see it in terms of mistakes. But quite often it’s that UX has been overlooked. Over time, they might be developing something, if you’re a software founder, and you’ve been developing a product, and you have a technical background, and your team is predominantly technical, then what can happen is that a product gets built over time. Gradually, the UX kind of deteriorates, as a product gets more complex, it’s quite hard to maintain great UX. It can be that it lapses and then it gets to a point after two, three years where the UX requires a lot of work. It’s a big project going back not just for a designer or a UX specialist, but also, changing the product for the developers to then kind of rebuild this product to provide that great UX.

That’s one big challenge that I see happening a lot. Sometimes it is also not necessarily having the best insight into the UX challenges in a project. Then after building a product and working with it for some time, there can be issues that can become apparent. There can be friction in certain areas of the product onboarding can have its friction moments. Even using the product day to day, there can be friction that’s been built in by not having great UX. I mean, the great thing about it is that that kind of issue can always be addressed and resolved and improved. It’s very much a game of iteration on the product side, you always iterating to improve. UX is another one of those things that requires the kind of constant iterations for improvement.

Victor [09:11]: It makes a lot of sense, because when you’ve been working on a product almost doesn’t matter whether you have a tech background or a different background, but you’ve been working on it for three years, you know the ins and outs of it, you know exactly where what’s its, your commonly used feature is hidden behind, three clicks or four but doesn’t matter you know. You just might not notice how that impacts onboarding or, fresh user starting to use your application, which leads me towards onboarding, activation and at retention. What do you commonly do to improve these metrics? How does that look like as a UX specialist?

Peter [09:55]: Well, there were a number of areas that you can have these issues with, right and it always depends on the situation of the company, that we’re discussing, discussing this with. Software founders are really smart people, super intelligent people generally. When you talk with them, they know pretty well the difficulties within their product. Every time when we speak with someone, they come with a with a specific problem, they say, oh, something like, hey, we’re having a problem during onboarding, that’s a particular integration we need our users to do. It’s quite challenging. It creates friction, they might need a developer to actually implement this integration.

We find that could be a cause of a drop off. What we do is we want to understand the problem, first of all right, so we want some metrics around this, how many people struggle with this particular issue during onboarding? What do they typically do? Is it costing customers and signups? You know, do they churn and then find some other product that that has a slightly easier onboarding process. We get to understand that problem, you can do that by using product analytics to monitor behavior, you can observe session recordings, you can also interview some users. One of the most powerful things is speaking with users to understand them.

Particularly, this is a bit harder, but particularly speaking with users that have either cancelled or chant, because you find out the problem or the reason why they. The first part of it is gathering a good understanding of the problem. Then once you have that, you can just go to the drawing board, we spent quite a bit of time on whiteboarding. Nowadays, you can use products like meero, which is really great for this, we map out the journey that the user currently takes. We observe it, we discuss it, we look at where the problems might be, we look at the product too. We do that journey ourselves. Then later on we kind of ideate and work through, what would the ideal situation look like?

There are always problems and restraints. The key thing is how do you design something great considering that these restraints are unavoidable that there are challenges in there that we cannot, just get rid of. Something like the integration might need to be done for a product. We have to work with these constraints and do the best we can, understanding that there’s an unavoidable challenge in there. We then iterate through designs, and this can be a process of working collaboratively with founders, with other designers getting people’s opinions, taking designs back to users and saying, hey, what do you think about this flow? Does that improve the process that you’ve taken many times within this product, do you think this would work for you.

That’s what the process looks like until you reach a great design layout. We always end up with a great UI design that incorporates all of the interactions in this flow, that we can then hand over to a developer team. Then the latter stage of this is monitoring that. We want to see if there’s uplift, we want to observe improvements, and see if there’s any tweaks that still needs to be done. But that’s the general process.

Victor [13:13]: I find it interesting because you say well, we find out there’s an unavoidable integration or bigger thing that we need to build. But I think that’s fine. If you understand, hey, this one thing is truly not avoidable. But then we know we can invest into that. We know this will actually work. It’s very likely this will fix our problem, because I think SaaS founders, especially technical SaaS founders, quickly jumped to conclusions that we need to build more, and we need to build this feature, and I’m sure that feature will improve onboarding or retention or will be loved by our users.

That can be very costly if trading outside of development before spending money on that before going down four, or five, six spreads of developing a deep integration, something might make sense to really revalidate that.

Peter [14:09]: Yeah, I’ve seen that many times, actually, I mean, touching on your point of continually building something, that’s the temptation to be, continually releasing features into the product. Because it’s seen as a more kind of powerful product that has more functionality. But the real thing that makes a big difference is focusing on activation. Each time a new feature is developed, it’s putting all your energy into activating that feature, making sure that there’s uptake and that your existing users are starting to adopt that feature. Because otherwise you get into the danger of having features that are not being utilized. That’s actually really costly, not just financially, but it’s costly to the product experience as well.

I think the challenge with that is that if you have a technical team, the expertise is in Building functionality and features. But the activation side of things is almost a product management product marketing element. It needs the core skills of sharing, distributing and learning people, raising awareness of this feature and the power of it and how they can benefit from it. The other thing is about, something unavoidable within the onboarding process. While sometimes we come up against that, there is an integration that simply has to be done for the product to work. But other times, we do find things that we can remove, and they have an incredible improvement on the experience. It’s not always just massive constraints that we’re working with. Sometimes you see something, you think, hey, actually, we don’t need to make them do this at this step in the onboarding process, we can remove it, and that can really make the task a lot easier.

Victor [15:55]: Are there very specific UX patterns within the SaaS industry that people should be following? Is that something that you deploy oftentimes, and I guess the simplest one is, where to find settings where to find billings, but that’s less of a core feature I would say. Are there other patterns that really do exist, and people can break by not employing them?

Peter [16:19]: Generally, we there’s a few tools that we use, over and over again, in SaaS, we also SaaS who it works for which product it works for, but generally, throughout sign up, it’s making that that sign up, easy, frictionless. Once the user is in the product, and particularly for brand new users, to give them a really great product experience we start off with, okay, the first thing we want to do is make them feel motivated and excited about the product. We present them with a congratulations, kind of welcome to the product, welcome screen or flow, it can just be a simple thing, it could be a video, or it could be a nice graphic and some good copy. From there, we usually recommend giving the user an orientation of the product. Showing them this product, understand the context of their challenges and what they’re trying to achieve.

Then highlighting the key value points within the product. This might be three to five slides just running through, okay, this product is really going to help you get this result, it will be great, then here are the three or four key features that you should really get value from and what they do. Then something that just kind of wraps up that interaction and drops them into a good starting point within the product. We call that an orientation flow. We think that’s a really important kind of first experience to just orientate your new user. Once they’re in, we use things like checklists, to get them through the process of adoption, get them to start using the product. We use walkthroughs with tooltips.

These are a number of kind of patterns that we use over and over again, and a huge one that I come across a lot, and sometimes surprises me how much we see this is empty states for screens within software. A lot of times a user who’s new to a product can land into particular screens might even be the dashboard. It’s empty, because obviously their account has no data yet. What we would do as a designer, you’re trying to make that experience great and treat it as a starting point. It’s like a welcome to this screen this new this feature that you haven’t used yet, here’s what it can do, and how you would use it. Hey, get started here and begin your flow for populating this screen with data. I think it just it just enables them to visualize this product, benefitting them and how it would work once they get going.

We kind of get some past that hurdle. Whereas when you land in an empty screen that’s quite uninspiring if there’s no encouragement to get started and nothing, visualizing how that screen can work for you. Yeah, those are some typical patterns and flows that we use in our design, we find that we repeat those quite frequently.

Victor [19:07]: That is super helpful. I wanted to touch on another thing you mentioned, because you spoke a lot about getting data from users qualitative data, especially talking to users interviews, and I wanted to speak a little bit about quantitative data for a second, what tools you use, how do you gather quantitative data within a SaaS?

Peter [19:30]: We genuinely break it down into two types. We take behavioural data, behavioral data from analytics tools, and then we take feedback, feedback at scale. For behavioral data, we’d use something like mix panel or connected into the product. It just enables us to see analytics. We might be observing something like how many users get to the end of a flow in a certain journey. We’re tracking how many people from the start to the finish how long it takes. We track things like utilization, which features are being utilized the most, and how, and I find just the top-level statistics and analysis is really, really helpful for that.

Then the second type of gathering user feedback at scale can be things like just pop ups within a product that says, if you’re monitoring a particular feature or interaction, you might say, how useful was this feature and give an option out of five, because what you want is a kind of score or a rating that you can aggregate and you can get insight from, and you want it on something specific. You can say that this new feature, the majority of users found it, a three out of five, in terms of how useful it was, or how easy it was, would be tracking things like that, how useful and how easy is this feature.

Then things like NPS is a really good thing to be tracking. It’s an easy one to do just get a get a score of how likely somebody is to recommend the product to somebody else. General feedback. I mean, if you want open text feedback, it’s great to get a sense of specific issues or requests users have, but it’s quite hard to use that data at scale to aggregate that data and to get insights that can be applied generally, across the product, they’re usually quite specific things. For that reason, we take things like, metric scores or out of five or out of 10. For feedback at scale.

Victor [21:42]: The last topic I wanted to touch on is, we kind of spoke about that, I think in like one or two words. But I guess that’s what a lot of people fear. You said, especially after a few years that there’s a risk of that, when do I need to really redesign my entire product? When does that happen? What’s like pretty definitive, like sign that says, hey, you might want to look into not just redesigning a small flow or onboarding or this feature, but actually, we should look at your entire product?

Peter [22:15]: The best time is, when you find that there’s a problem, that’s hurting the business, right. Usually, we don’t tend to recommend redesigning the whole product, because a lot of products can be really big and complex. There’s a lot of work that might go into that. What we do, which is really common, and a lot of founders say this to me is, you probably heard this term, it’s getting the low hanging fruit, they always say,

Victor [22:45]: Everybody wants the low hanging fruit.

Peter [22:48]: Everybody wants to start with the low hanging fruit. It makes sense, it’s really great. What are the things that we can have the biggest impact on with the least resource or effort. We always think about the quick wins, I don’t always recommend just only focusing on the quick wins, because they might be in very different areas of the product. The best way to approach this is the biggest problems, the biggest problems in the product. Is there’s something that’s making the product difficult to sell? We worked with a software company that have had their product for around 15, 16 years. It’s a great product, technically quite advanced and functionally rich, but the UI was starting to look old. They were finding that some of the feedback was the UI looks quite dated.

It got to a point where it’s costing them sales and the investment in re skinning or refreshing the product would really pay off in the long term. That’s a great example of investing. Then another experience with a client we’ve been working with is a frictional point in the onboarding journey, which is costing new users, what might happen is that they can go off to a competitor who might have a more seamless onboarding. You lose a potential users to a competitor, which can really hurt. If you’re seeing issues like that, other examples might be, churn is getting high utilization is low activation on features, or adoption of the product overall, isn’t great. These are things that can be improved, that will actually affect bottom line revenue, they’ll have an impact on MRR.

We take them in isolation, we look at the problems, and we put together a design sprint to resolve this particular problem. We’ll do a product that way. If it is, over time, a whole product that needs redesigning, we would do it piece by piece, looking at what area of the product working on that later moving over to a certain feature or screen by screen. That enables us to work to a roadmap and also it means that we’re collaborating with the development team. We’re handing off as we’ve resolved the design for one section, we’re handing it off and moving over to another. We’re building momentum. Sometimes it’s just parts of a product. Sometimes it’s the whole thing. Yeah, number of a number of reasons. But mostly, I would say if it’s costing you costing you revenue, or other, problems that are impacting the business.

Victor [25:19]: If I wanted to work with UX specialists, like yourself, what should I prepare so that you can help me best?

Peter [25:29]: I think having a good handle on what needs to be done first of all, what you want to focus on. What are the big problems. Like I said earlier, software founders know the problems within their product. They usually know the issues, they have a really good handle on it. A vision as well, what is it that you want to improve? In software, we talk about the desired outcome for users? But I always talk about this in design sprints, what’s the desired outcome? If you invest in product design, what do you want the result to be? Are we looking for increased adoption? Are we looking to extend the lifetime value or reduce churn? If we think about it in terms of investment, which design definitely is, then what’s the ROI? You know, can we track that? Can we quantify that in terms of revenue?

If you’re losing, say you have about 1000 new users a month, and 40% of those churn, and they have a lifetime value of $7,000, you can really quantify that, if we improve the onboarding process by 20%, that could save a significant amount of revenue over the long term. We can actually quantify it. Coming with an idea of the desired outcome for your investment in design is great. I’d say often they have an idea, but they don’t know. But we actually go through that exercise. We say, okay, we’re gonna design to these targets, and we’re gonna monitor, have we been successful with this design sprint in achieving the impact that we wanted to?

Victor [27:09]: That is super helpful. Thank you so much, Peter, for coming on the show. This is really interesting and insightful. Where can we learn more about you, as well as user active?

Peter [27:19]: If anyone needs help or advice, feel free to reach out to me just by email. It’s peter@useractive.io. I’m always happy to help founders, I love looking at products. You know, whether we work together or not, it’s something that we always do. You can check out our website user active.io. You can book a call if you need to but that’s generally one, I’d recommend reaching out. Perfect. Well, thank you so much. Thanks for having me really enjoyed having a having a conversation with you today.