How to balance user objectives with business goals

userobjective

 

In the development process of any app, you have two stakeholders. You have the one which is present – the app owner – and the one who isn’t – the eventual users. Both have distinct needs which often don’t line up. So how do you make sure you’re satisfying both parties?

The first thing is to clearly establish what these needs are. At Pocket App, we refer to them as ‘user objectives’ and ‘business goals’.

User objectives consider what the audience will want to get out of the app. If the app in question is Trainline, users want to find and buy cheap tickets. If it’s Citymapper, they want to put in their destination and find the quickest route.

Most often, user objectives are to do with making a person’s life easier – and that’s just as true when it comes to internal apps that are going to be used by the app owner’s employees. If your app doesn’t add any value, then – unless it’s absolutely mandatory – they aren’t going to utilise it.

However, where most app owners begin, logically enough, is with the business goals. Clients generally come to us with a clear idea of what they want an app to achieve for their business, whether it’s increasing sales, improving engagement or building brand awareness.

These goals rarely overlap with the user objectives. Take for example Pocket App’s recent app for Sky. The business goal was to sell more Sky Protect insurance packages, via the network of engineers who visit customers’ properties for a new installation or repair. In this case, the user was the engineer, whose objective is being able to load up the app as easily as possible and give it to the consumer without having to field any questions.

These are two very different objectives. And that’s only natural. What you have to be very careful about is that one doesn’t end up driving the other.

Finding a happy medium

Meeting user objectives is what keeps people using your app – but if you focus purely on that side, the app won’t be making any money or doing whatever it needs to for your business. If it’s not going to hit any KPIs or generate ROI, then it’s ultimately a pointless app.

On the other hand, if you put the emphasis wholly on the business goals, to the detriment of user experience, then no one’s going to use it. And that means they’ll never actually generate any value for your business.

So how do you balance both sides? Make sure you’re considering user and business goals alike from the very beginning of the process. It can be helpful to list two or three objectives on each side – breaking down the business goal into more granular parts if needed – to make sure it’s equally weighted.

It’s also important that the objectives don’t run contrary to one another. There will most likely be some conflict along the way. Certain decisions might lead to users potentially spending more, at the cost of irritating or even putting off a proportion of the audience, requiring a cost/benefit analysis to decide the best course of action.

But ideally, the business goal should be a natural extension of what the user naturally wants to do with your app. This is easiest if your business goal is enabling a user behaviour. For example, if you’re a retailer aiming to drive more transactions, that lines up neatly with the user objective of buying things with minimal friction.

Also consider the longer roadmap for your app. On day one, your priority may be different than it is further along the line. Look at app giants like Instagram, which focused on meeting user objectives first – by making an app that was nice to use, and thus attracted a mass audience – before figuring out how to monetise the app and make it meet business objectives.

That’s obviously not an option for everyone, especially if you’re developing an internal app. As a general rule, though, your MVP needs to meet at least some user objectives for it to gain any traction. Business goals can come further down the road, if necessary.

The benefits of getting it right

Clearly establish your user objectives and business goals early on, and they should help guide the rest of the process.

Say you’re at the wireframe stage, trying to decide whether a particular piece of functionality should be on the homepage, or whether it should even be included at all. You can simply ask whether it meets those objectives: Is adding this going to help the business in any way? Does it help the user, or hinder them? That should answer the question.

These objectives can also help post-launch. Deciding where to focus ongoing development and support work is easier when you know exactly what you’re trying to achieve, for both parties.

At this point, you’re likely to be re-evaluating both halves of the business/user equation. For example, maybe you’re seeing a 10% uptick in sales after launching an internal app where that is the core business goal. But when you get feedback from users, it says they’re not using it as much as they could because it’s fiddly.

So if you could do a better job of meeting those user objectives, and encouraging them to use the app, perhaps that increase could be boosted to 15%.