How the Craziest UX Ideas became Successful Products

Sergey Krasotin at UXDX Community: EMEA Online Series. Video: https://www.youtube.com/watch?v=fDYcCE2MJm4

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.

How Humbleteam started

[00:00:00] I'm going to start with a quick introduction for myself. I'm a design director here at Humbleteam, and we are a design team. We basically love two things: the first one is startups and user experience is the second one. Five years ago I was a founder of two startups myself, and I will say our marketing and sales components pretty much sucked, and business-wise we failed miserably, but everybody actually loved the design and the user experience. This is how the whole Humbleteam thing started.

[00:00:39] Since then we've done some amazing stuff, like designing different fintech apps that got plenty of money. Many companies from Y Combinator and Dexter[?] came to us, and other cool startups. Recently even engineers from NASA came to us to design a system to manage cargo storage on the International Space Station. So I will say that being extremely bad at sales and marketing actually paid off. In total we've worked on more than 100 different projects with a lot of investments around. That's my build up, and now it's going to be the act.

Design is about iterations, and iterations need speed

[00:01:28] Many startups ask us about the best approaches to come up with creative and useful features. Even though there is no silver bullet, no single method to design the best UX possible, there is a method to improve the quality of your product design process. There are two things to understand before we go deeper into our cases. I think that design is all about iterations, and basically the more you iterate, the better the user experience you have. The key is to make better design decisions, and the key to make better design decisions is to iterate more.

[00:02:15] That's the main thing. In a design process, to make good design decisions you need to go live with your iterations as fast as possible and collect as many pieces of user feedback as possible. If you can iterate fast, you will eventually come up with great design ideas. And if you release, I don't know, one feature in six months, you don't have this luxury of iterations. So that's the key for releasing great features: basically having the shortest time to market possible and iterating as fast as possible.

[00:02:55] Our main topic for today will be how to come up with great design ideas and test them as quickly as possible, because speed is a very important factor. In my humble opinion, a good release cycle is something like up to three weeks, including the implementation. Let me explain why exactly three weeks, and not five or two, for instance.

[00:03:23] Basically, if you have three weeks, then within a year you can have up to 18 experiments, 18 different releases. Imagine you spend four weeks from an idea to release. In such a case you will lose like 30 percent of experiments. If you spend the whole month to release some feature in your product, you have only 13 launches annually, and it's 13 versus 18. It sounds a little bit scary to me, because such a pace will be thoroughly bad for your product.

[00:04:00] And if you have releases every five weeks, it's going to be completely disastrous, because it means only 10 experiments for a whole year, 10 opportunities to share the product and collect feedback. So that's going to be our conclusion: we need to stick to an idea that we need to try to test product hypotheses, product ideas, in three weeks, including the implementation.

The banking case: a credit line for subscriptions

[00:04:23] Now I'm going to go through a particular example from our experience, and I'm going to show you the design process, how it should look to meet this three week deadline. A description of the app we've been working on: it's a new bank application, with pretty much standard features. There's a checking account, debit card, savings account, transfers, top up, all the standard flows you probably already know.

[00:04:59] Imagine you want to add a new feature to help people save money on their paid subscriptions, because imagine a user with tens of subscriptions, like Netflix, Spotify, all these things. A lot of them, from our statistical data, live from paycheck to paycheck. Here is the main trick: if you have no money right now but there is a recurring subscription charging you, you're going to get a fee. And imagine multiple subscriptions charging you at the same time. That's going to lead to pretty significant fees in total, and it's even scarier, it's even worse, because you already have no money in your pocket.

[00:05:46] So there is definitely a pain point to address. Users have late and overdraft fees and they are not really happy about that. To solve this issue we wanted to offer a line of credit for our users, simply 50, 60 bucks to cover those subscriptions with no interest. From this point, let's simply plan how we will release such a feature for our application within a three week interval.

[00:06:21] A lot of smart startupish people will say let's put an MVP for this, not a full-scale feature but just an MVP to test the idea first. Let's check what will be an MVP for such a feature. We can list all the screens we need to design and develop to launch such an MVP. You don't need to read all the things on the screen, it's just to give you an understanding of the amount of work that is needed to launch such a feature.

[00:06:57] First of all, setup: you need to onboard users, you need to recognize subscriptions in their transactions, you need to cover edge cases like subscription cannot be added, you need to edit subscriptions, a lot of things. And then when people use this feature it's going to be even more screens. Here is my list of subscriptions to pay, empty states, overview, payments, credit lines, credit line repayment, etc, etc, etc. So in total more than 20 screens, and it looks like a lot, much more than a design and development team can handle during the three week interval.

Prioritize the risks, test only the one that matters

[00:07:37] So here is the main thing, what we're going to do. We wanted to get back to the assumption we had initially, and let's check our risks. People probably will not add subscriptions at all using our feature, and then we have no data to offer them a credit line. Maybe after launch our onboarding will not be convincing enough to convert users and people will not sign up for the feature at all. Or maybe after the launch people will convert, they will add subscriptions, they will use the feature eventually, but it will have zero effect on the retention rate. Or maybe people will not pay the debt back. There are a lot of risks actually.

[00:08:31] But here comes the main point of our design process. You can prioritize those risks to solve the most important ones first. To me it seems like number three is the most important one, because if you have no retention increase, it doesn't really matter if people have or have not subscriptions, if they pay or do not pay, if they have or don't have late fees. This third risk is the most important one, and we can focus on testing this main risk only, because if we fail here the rest doesn't really matter. And if retention does go up, we will somehow solve the rest: the better onboarding flow, I don't know, the buggy flow for changing the subscriptions. We're going to solve the rest somehow if we cover this main point.

[00:09:31] So based on this, we can tweak our plan to test the retention assumption, and here is how it's going to look. We can simply manually select people who live from paycheck to paycheck, because they are more likely to use our feature and we don't need extensive onboarding to convince them. So we can cross out the first screen in our MVP. We can also manually check transactions and we can add subscriptions manually on users' behalf as well, so we can get rid of the other onboarding screens from the MVP. And we don't really need any interface to edit or change it, since we do it manually.

[00:10:25] To add those subscriptions manually, it could be actually a super cheap workforce, like a freelancer who will check the database of users, check their payments and just manually mark subscription payments. It's an easy busy gig for like two working days. So as you can see, we're already 50% done with our scope just by hiring a student who will do the manual work. The core idea is that when we want to release a new feature, we need to understand what our main risks are, pick the most important one, and test only this single thing.

The process for testing a hypothesis, and the typical risks

[00:11:10] Based on this case, we kind of forged the process to test a new hypothesis. Here is going to be the first step: determine the value proposition you're trying to test. It could be, do you want to test if adding a line of credit for paying subscriptions will increase retention in our application? Then secondly, you need to identify all the risks in your assumption. Those are typical risks.

[00:11:43] It could be, for instance, that users do not recognize the product value. For example, you've added a crypto trading option in your application, but all the users are already using services like Coinbase or levels[?], so there is simply no need for this additional feature in your product.

[00:12:05] It could be hard to acquire users. We have had this quite a lot. Imagine you have created an application that allows you to find a medical professional in Europe, and it turned out that most major European cities have one of their own and they know their local market very well, and you're in indirect competition. It's going to be super hard to get users.

[00:12:38] It could be hard to make money out of the feature: the product is being used but the profit and loss statement is still in red, that kind of situation. And last but not least, it could be simply hard to execute such a feature. Let's say your application offers help at moving, and as soon as you reach, I don't know, 100 requests daily, the city is suddenly out of van drivers with no possibility to recruit more in time, so the feature is going to be useless.

[00:13:14] So here are our risks, and now we've reached the most important part. You have the assumption, you have the risks, and now you need to pick one risk that you're most likely to face. And as additional information, if you want to read more about testing hypotheses this way, I can definitely recommend an amazing article from Maven's cion[?] on firstround.com. There are additional things to check there. That's pretty much the approach we use for the startups we work with.

The artists app: getting professionals on board

[00:13:57] I do have a couple of other examples, because this keynote is originally like a two-hour talk for accelerators we participate in as mentors. The background of the project: it's a mobile application for artists. It basically helps artists have their own artworks in one place. It's kind of like a Google Drive for artists where they can store everything they have. If you're a painter you usually have materials for your artworks all over the place. When somebody wants to buy something from your inventory, you send a photo from Dropbox, a description in email, then buyers ask for additional pictures, you send them via WhatsApp, for instance. It's a really chaotic process.

[00:14:42] The app solves these issues, becoming a single source of truth where you can upload all your photos, prices, artwork sizes, metadata, pretty much everything. And if somebody asks you, do you have any artworks for my living room below, I don't know, one thousand dollars, you can just boom, send them everything in one single email or in one single WhatsApp message.

[00:15:06] But we had a problem. We had tens of thousands of users, but we didn't have any top tier professional artists at all. Our audience was hobby painters who sell paintings as a side gig, and we wanted to attract those professional folks, real professional artists with, I don't know, 30 years of experience, artworks they sell for 10, 12, 20 thousand. But it was really impossible to get them into the application.

[00:15:44] Why? Because if they want to upload everything they have in their mobile application, it means uploading tons of things. It's uploading hundreds of photos, filling hundreds of input fields. The inventory is huge, there are many, many artworks. So if you're a professional artist and you see a banner on Facebook, like sign up for Marcel[?] app and put your inventory in one place, the onboarding process will actually be a bummer. You click on the banner and you need to spend like two working weeks just typing in your metadata and uploading images. So it doesn't really look anyhow good.

[00:16:20] So here is the assumption. We think that our app will benefit from professional artists. They can invite other artists, they can promote our application, they're thought leaders. But they don't really want to spend their precious time uploading everything they have in the application, because they simply see it for the first time in their life.

[00:16:43] What shall we do? It's an absolutely obvious thing that we need to optimize onboarding for those people, for people with hundreds of artworks. Bulk upload, create some way to automatically sync your Dropbox, for instance, or Google Drive. But design and development for such a thing will take a month minimum, which is against our policy to release every feature every 15 days. So we decided to get back to the assumption we want to test.

[00:17:16] This is what our MVP must check. We need to check if top class artists will help us get new users on board, other artists. And we don't want to test if they can go through the onboarding process, or if they will manage to upload 100 artworks. We want to test if pro artists will retain in the app and will recommend the app to many other folks they know, or not.

[00:17:42] So what if we reach out to professional artists? We can ask them to send all their Dropbox links, Google Drive folders, spreadsheets with sizes, Word documents with prices, and we will create their accounts in the application and upload everything on their behalf. You can imagine, if you're an artist you have all your materials all over the place, struggling to even tell the price for an artwork because you simply, I don't know, forgot it. And then just like that you have your whole inventory sorted and systemized in the application, and everything you need is to log in with an email and password in your application, which of course you can set up later.

[00:18:28] So basically, to test this idea we needed to hire somebody for one month to transfer a bunch of JPEGs and text into our application, manually type them in, and we didn't need to create even a single additional screen in the application. This example took zero development time, because the designer needed to create only a bunch of emails for those professional artists within the marketing campaign, and that was it.

[00:18:54] Here is the quick recap, in the form of our scheme. The value proposition we were trying to test was, we want to test if professional artists will retain in our app. And then here are the risks: artists will abandon the app, they will not upload artworks, they will not pay, et cetera, et cetera, et cetera. There are many of them, but we need to pick the most probable risk and create a flow to test it. And that's pretty much it.

[00:19:24] I don't know if we have some time left, probably not really, we have like maybe one minute. So that's pretty much the last case study I wanted to go through. Once again, if you have any questions, I'm checking LinkedIn, YouTube and Slack, let me know and we'll be happy to address them.