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 an example with a new app we have been working on. It's a new bank application with standard features. There is a checking 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 that people often live paycheck to paycheck. If you have no money, but there is a subscription charging you, you're going to get an 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. To build this product, 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  propose 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 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 wants to buy something from your inventory you send a photo from from your site. Then the buyers ask for additional pictures. You might send them using WhatsApp, for instance. It's a really chaotic process. And 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 $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 or $20,000. But it was really impossible to get them into the application.

Why? Because if they want to upload everything they have it would mean uploading hundreds of photos and filling it in hundreds of input fields. Their inventory is huge.

So if you're a professional artist and you see a banner on Facebook to sign up for to app and put your inventory in one place, the onboarding process will be actually a bummer. Spending two working weeks just typing in your metadata and uploading images doesn't sound good.

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 with hundreds of artworks. I mean like bulk upload or create some way to automatically sync your Dropbox, Google Drive, or other storage location. But design and development for such a thing will take at least a month  if not more, which is against our policy of releasing 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 information whether it is in Dropbox links, Google Drive folders, spreadsheets with sizes, Word documents with prices, or wherever and we will create their accounts in their application and upload everything on their behalf.

This was a huge win for the artists because instead of having materials all over the place and struggling to even remember the price for each artwork you have your whole inventory sorted and systemized in the application.

To test this idea, we needed to hire somebody for 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 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 the main risks are and pick the most important one and test just this single thing. It is through these quick iterations that we learn what people really care about and save ourselves the 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.