Humbleteam is a design products and services company that delivers a digital experience at the intersection of users and business needs.

How do companies instill innovation in their employees?

Many startups ask us about the best approaches to come up with new creative and useful features. Even though there is no kind of silver bullet, or a single method to design the best UX possible, there is a method to improve the quality of your product design process: make better design decisions. And the key to making better design decisions is to iterate more.

You need to go live with your iterations as fast as possible and collect as many user feedback pieces as possible. If you can iterate, you will eventually come up with great design ideas. If you have releases every five weeks it means only 10 experiments for a whole year. 10 opportunities to share the product and collect feedback.

The key for releasing great features is having the shortest time to market possible and iterating as fast as possible. Thats why we believe teams should have three weeks to test the product hypotheses including the implementation. Let me explain why exactly three weeks is better than two or five for instance. Basically, if you have three weeks, within a year, you can have up to 18 experiments, 18 different releases. Imagine you spend, for instance, four weeks from an idea to release you will lose like 30% of experiments. It's 13 versus 18.

How do you actually achieve such a tight timeline?

It’s tough to meet these deadlines but here is one with a new app we have been working on. It's a new bank application with standard features. There is a chequing account, debit card, savings account, transfers, top up, and all these standard flows you probably already know. Imagine you want to add a new feature to help people save money on their paid subscriptions, like Netflix, Spotify, all these things.

From our statistical data, we know they live from actually a paycheck to paycheck. If you have no money, but there is a subscription charging you, you're going to get a overdraft fee. Imagine multiple subscriptions charging you at the same time, that's going to lead to pretty significant fees in total. It's even worse because you already have no money in your pocket. So there is definitely a pain point to address. Users have late and overdraft fees, and they're 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. Basically, first of all, you need to onboard users, you need to recognize subscriptions in their transactions, empty screens, edit subscriptions, repayments, you know, a lot of things.

Let's plan how we will release such a feature for our application within a three week interval. A lot of smart startup-ish people will be, let's put an MVP for this, not a full scale feature, but just an MVP to test the idea. But a functioning MVP still requires a lot of work that we can’t achieve in 3 weeks.

So here is the main thing. We want to get back to the assumption we wanted to ask initially and 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 a launch, our onboarding will be not convincing enough to convert users and people will not sign up for a feature at all. Or maybe after a launch, people will convert, they will add subscriptions, they will use the feature eventually, but it will have like zero effect on the retention rate, which is our ultimate goal. Or maybe people will not pay the debt back, right? There are a lot of risks, actually.

You can prioritise those risks to solve the most important ones first. It seems like the number three is the most important one, because if you have no retention increase, it doesn't really matter if people have no subscriptions, they pay or do not pay. This third risk is the most important one. And we can focus on testing these main risks only, because if we fail here, the rest doesn't really matter.

Based on this, we can tweak our plan to test the retention assumption. And here's how it's gonna look like. We can manually select people who live from paycheck to paycheck, because they're more likely to use our feature and we don't need extensive onboarding to convince them. 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 other onboarding screens from the MVP. And also, we don't really need any interface to edit or change it, since we do it manually. This reduces our MVP dramatically so that we can deliver within three weeks.

So, to summarise, determine the value proposition you're trying to test, identify all the risks in your assumption and pick one risk that you're most likely to face.

Do you have another example of putting this into practice?

We created a mobile application for artists. If you're a painter, you usually have materials of yours all over the place. When somebody wanted to buy something from your inventory, you send a photo from from your site. Then the buyers ask for additional pictures. You send them using WhatsApp, for instance. It's a really chaotic process. And the app solves these issues becoming kind of like 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 $1,000, you can just like, boom, send them everything in one single email or in one single WhatsApp message.

But we had a problem. We had tens of thousands of users, but we didn't have any top-tier professional artists at all. And our audience was hobby painters who sell paintings as a side gig. We wanted to attract those professional folks, real professional artists with 30 years of experience whose artworks sell for $10,000, $20,000. But it was really impossible to get them into the application.

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 it in hundreds of input fields. Their nventory is huge.

So if you're a professional artist and you see a banner on Facebook, like sign up for to app and put your inventory in one place, the onboarding process will be actually a bummer. You click on the banner and you need to spend like two working weeks just typing in your metadata, uploading images, so it doesn't really look any good.

And so here is the situation. We think that our app will benefit from professional artists. But they don't really want to spend their precious time uploading everything they have in the application because they don’t yet see the value.

So what should we do? It's absolutely obvious that we need to optimise onboarding for those people, for people with hundreds of artworks. I mean like bulk upload, create some way to automatically sync your Dropbox, for instance, a Google Drive, whatever. But design and development for such a thing, that will take like a month minimum, which is kind of against our policy to release every feature every 15 days. So we decided to get back to the assumption we want to test.

We need to check if top class artists will help us onboard other artists instead of testing if they can go through the onboarding process. We want to test if pro artists will retain the app, and they will recommend the app to many other folks they know or not.

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, like Word documents with prices, and we will create their accounts in their application and upload everything on their behalf.

And you can imagine, if you're an artist, you have all your materials all over the place, struggling to even tell the price for the artwork because you simply, forgot it. And then just like, you have your whole inventory sorted, systemized in the application and everything you need, login, email, and password in the application, which of course, you know, you can set up later.

To test this idea, we needed to hire somebody one month to transfer a bunch of JPEGs and texts into the application, manually type them in, and we didn't need to create a single additional screen in the application. So 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.

What is the benefits from looking at it with this approach?

The core idea is that when we want to release any feature, we need to understand what are our main risks, pick the most important one and test only one, only this single thing. It is through these quick iterations that we learn what people really care about and save ourselves teh hassle and expense of building features people don’t want or don’t deliver on our business value.  

We need to pick the most probable risk and create a flow to test it. And that's pretty much it.

Get latest articles straight to your inbox

A weekly list of the latest news across Product, UX, Design and Dev.

We care about the protection of your data. Read our Privacy Policy.

You might also like

UXDX is my favourite newsletter. Incredible content across the key areas in our industry.

Dennis Schmidt
Dennis Schmidt
Product Designer, COYO

Subscribe to the UXDX Newsletter

We care about the protection of your data. Read our Privacy Policy.