Deconstruction of User Objectives
Deconstructing user objectives is a simple exercise that I like to perform as a way to challenge any preconceptions that my product team may have about our users needs. It’s a mechanism for playing devils advocate and questioning if what we’re leaning towards building is really the way to proceed from the standpoint of the end user. It forces you to really question every aspect of what a user is trying to achieve and ensures that you don’t boil the ocean when a simple solution may give a user 90% of what they need. It also ensure that you don’t rush off down one path and build completely the wrong thing because you’ve misunderstood the intricacies and hidden needs of the end user.
Let me give you an example:
So let’s assume we’re building an mobile application for a financial services institution and as conscious product managers/owners we perform some user research and deduce a number of user objectives. Let’s take this objective and word by word deconstruct the statement to challenge underlying assumptions and ensure our understanding is complete and perfect. At first the objective seems pretty straight forward – we need to build an application that allows a credit card holder to pay off their credit card balance. Simple.
Hang on, there’s lots of different types of credit card holder i.e. supplementary, premium, multiple cards – do these users needs differ? Likely. The demographic of the users we’re developing for is probably the thing that we’d want to ensure we’re clear about and sanity check before proceeding further!
Ok, so let’s pick another word in that statement – ‘pay’. Do you want to know your balances before you pay? Do you want to be able to credit your account or make an auto payment – would this give you more peace of mind? If you’re keen to pay on your mobile device I imagine you’re a busy individual who needs flexibility when it comes to managing your credit cards – so maybe driving/enabling auto payment enrolment via mobile is a more fitting way to address your needs vs. having you manually log on and make a payment?
Now we’re getting somewhere – so next word, you want to pay your ‘balance’. Great, which one? Your minimum payment due? Current balance? Statement balance? Fixed amount? New balance? Do you even understand the balances you’re paying? Would the user perceive us to be ‘tricking them’ if we promote high interest but numerically lower balances? Would the user benefit from being able to set alerts when a balance is above a certain threshold to save them having to log in repeatedly? Oh wow – now we have a whole lot more thinking to do.
The beautiful thing about this exercise is it forces you and your product team to really scrutinize the needs of your user and in doing so you get to know your users more intricately and make better informed decisions and prioritize your features accordingly. The results of deconstructing user objectives can sometimes be mind boggling albeit very fruitful.