The value vs effort graph you should always keep in mind
Sometimes, when building a product, you might have to choose between adding more value and making it easier to use, onboard or integrate. When the perceived value is high, people would usually be willing to jump through more hoops to get it, while something that's really easy to get started with might be picked up even if the perceived value is lower. Like any framework this isn't always correct or even relevant, but I often like to look at the product I'm currently building through this lens, really plot the value and effort lines and see if there are any adjustments to be made.
A walk through the graph
The x-axis is progress. This usually happens over time, but read the section below about the dangers of assuming things actually always progress over time.
There are 2 y-axes here:
The first is value, colored green and representing the benefits and well... value that your product brings to its users.
The second called "effort" is highlighted yellow and represents any of the following: how hard your product is to use, to onboard, to install and integrate, or to set up, depending on what the product actually is.
The solid lines are a hypothetical balanced scenario where investments are made in both adding value to the product and making it easier to use.
The intersection of those solid lines is where the ROI calculation in the users' minds has passed the threshold of "it's worth it". I.e. the effort they have to invest to use the product is worth the value they can get out of it.
The dashed lines represent two other hypothetical scenarios, one investing heavily in bringing more value to users without making the product easier to use, and the other is focused on an effortless experience but with limited value.
Each intersection again represents that point where users find enough value for the effort required to extract it.
This graph scales up and down from a product level to a feature level and can help when you're trying to debug a problem with a feature or improve a flow. By estimating how your own graph looks like, you can understand whether you need to build more value (or just highlight the value that's already there) or simplify the product's usage.
Let's start with an example
Many applications rely on referrals from their satisfied members to spread the word to more relevant potential users.
If your referral program offers really great rewards, like considerable sums of money, you'll probably find it even if it's buried in the app somewhere, you have to copy the code manually and send it to your friends, and even remind them to sign up or take the action that gets you that reward.
However, if the rewards aren't perceived as valuable, you'll have to put a callout to refer in a prominent place, have to badge it, make it really easy to broadcast to your existing contacts, etc.
More often than not you'll encounter constraints that force you more towards one route (for example, all your engineers are busy and cannot create a fancy referral section, or you're tight on cashflow and are forced to reward with credits, or in app currency).
In some complex situations, the effort and the value are not even affecting the same persona. The visual studio we built at Stackbit, now Netlify, is a tool for marketers and business people, but it has to be set up and integrated by developers. We've constantly had to strike the same balance between making the editing experience better, or making the none-trivial onboarding and integration simpler.
Perception is everything
Keep in mind that the value your product offers might not be easily apparent to your users, nor can they always estimate the effort they'll need to put in to use it, and it's your job to make sure they see it.
Think of a classical signup flow and you'll notice that most apps would show you a glimpse of their value even before asking you to sign up, and might even delay it further till you've experienced an "a-ha" moment and are more likely to have understood the value. This will help get you through the signup process, even if it's a bit longer, asks for personal information, etc. It's also a good idea to highlight to the user how short the signup flow is, show progress and countdown to its end, to make sure it doesn't feel monumental and ongoing.
Don't mistake motion for progress
This classic quote is always true and just as often ignored.
Sometimes in an attempt to add more value we actually detract from it, or simply make the effort of using the product higher. We've all seen bloat-ware that keeps adding features and functionalities to satisfy tangential personas, or idea-filled executives. Even if those features are implemented well, in a way that doesn't hamper the core functionality, the perceived value for those core users might get overwhelmed and dwindle.
In an effort to be accurate with the graph, I've called the x-axis "progress" rather than "time", as over time our tendency is to always add more surface area, features and capabilities to the product.
One of the examples that comes to mind for me is the first iPhone app I've ever purchased. It was called "Captio" and all it did was send a text email to yourself. Brilliant! Especially in those early days, quite a few people's method of setting a reminder that was accessible across all devices was to send an email to oneself. For $2, instead of opening the email app, hitting the compose button, typing in your own address, and writing a subject and/or a body, you could open the app, write something in a text area and hit "send". Over time the developer added the ability to add attachments, schedule the send, see the history of sends and so on, that were all "natural" extensions that one might build when the mindset is "what else can I add".
Applying it in practice
When developing something new, try to be intentional about what's more important and call it out. The entire team should know whether its optimizing for a really effortless experience, or whether core value needs to be super high, even at the expense of some initial hardship.
You might be tempted to split the efforts among different teams. Often a growth team comes in and makes incremental updates that can relieve pressure point in flows, explain value, send notifications that bring people back, offer promos to encourage finishing a hard flow, etc. If you decide to go this route, make sure there's a good synchronization and communication cadence among those teams, otherwise you might end up with an experience that feels like shipping the org chart.
How to make sure you're actually moving in the right direction of increase your value and reducing the effort needed to get it?
Determine proxy metrics that can indicate ease of use (funnel metrics, abandaoned flows, error message) and after establishing a base line, set some alerts to make sure you're aware of major changes.
Set reminders every few months to go through the most important flows from scratch. You'll often find changes introduced by different teams that might not play great together, or that their cumulative impact feels too heavy.
Look at actual users working with the product. This can be with UX research, or simply observing real users through tools like FullStory or Hotjar. They might have different patterns of usage, different machines, different screen resolutions and so forth.
Try to see if your users' composition has changed. You might have expanded into and unlocked an adjacent user type to the ones you've had so far, and their needs or proficiency might be slightly different.
Establish a CAB (customer advisory board), or run regular user studies, to understand their perception of the value of the product, what's hard and what's easy for them, etc.
Lastly, there’s a tipping point where adding more value no longer yields significant impact, or when the effort is already low enough that further improvements aren't meaningful to the user. You could consciously push beyond this point, turning an easy experience to magical, or make your application consolidate the functionality of three others you had to synchronize.
Drop me a line with feedback, adjustments to this line of thought, or examples where you've applied this framework.