I think that what really motivates me on a daily basis doing my role is discovering ‘magic moments’ and seeking evidence to help users avoid ‘pain points’.
In the case of usability, I think that we have to spend a lot of time convincing various project stakeholders and the client where potential pain points are and subsequently trying to design our way out of or around them. Although I still think that this an important part of the job that we need to do, I think that this presents it’s own series of challenges. So, what constitutes a pain point?
Sometimes I think that it is a lack of recognition of something as an issue. From my experience, I often recognise more often than not that not being able to ‘fix’ these are driven by budgets and timings. We also find that stakeholders simply don’t see these as pain points because they are simply too close to the nuts and bolts to see what someone else can’t see in circumstances. Especially where they so familiar with how it actually works. So what’s the best way that we can avoid these?
Simply user testing would draw attention to these. No problem there, if we get the budget or buy in to make the investment. But we must recognise that as owners, designers and builders we are not the best test subjects. We have acquired a certain knowledge that benefits our understanding to avoid what isn’t as obvious to others; this is learnt behaviour. We have to look up from the parapet occasionally to really understand how and where are products are being used to become empathetic to that pain that our users are experiencing
Performance measurement would reveal insights in the behaviour. No problem as long as behavioural KPI’s have been addressed that reveal the kinds of interaction we need to recognise. A/B or multivariant testing would also reveal insight into testing hypotheses.
But what about getting to this before a project is delivered? Mmmmm.
Magic moments though are few and far between. To understand these we must have a real insights in to our users, the products and the business. It’s about asking the right questions at the right time. This for me, this is the path to innnovation, and is sometimes the most difficult. However, this comes with a massive warning – attempting magic moments badly very usually leads to WTF moments. Get it right and it works. Get it wrong and damage will be done. Perhaps this is another reason why agile is sometimes the great UX prevention process.
Apple has been really good at identifing these which seems cool, but be aware that these don’t just come about from uttering the words ‘expelliarmus’ and a flick of the wrist (it would be great though) but they come from a deep understanding and painstaking research at great expense to create the most simplistic of elements. Simplicity is the ultimate sophistication
Only by having a thorough understanding of user behaviour will we even begin to address these. They can mean the difference between users just using something as apposed to users feeling that they need to be engaged in something that is more than just colours and words on a screen. Then we might be able to start to talk about these experiences in terms of behavioural attachment.
Making small incremental changes to your interfaces can in certain instances only make the experiences you are seeking to fix worse for your customers. But being brave and think bigger may also lead you further. True innovation starts by accepting those contexts and driving to match you products to solve for these instances means that users could truly start to love your products.
