Defining user experience

User experience (UX) is made up of all the interactions a person has with a brand, company or organization. This may include interactions with your software, your website, your call centre, an advertisement, a sticker on someone else’s computer, a mobile application, your Twitter account, over email, maybe even face-to-face. The sum total of these interactions over time is the user experience. While user experience spans multiple practices, in this article I will specifically speak about UX from the perspective of a website, mobile app or software.

Studies over the years have shown that business-to-business (B2B) software (and to some extent websites) is just not delivering the same experience as its business-to-counter (B2C) counterparts. In this piece, I will address why we need to consider UX more in the process of creation in B2B, then some of the inherent problems B2B brings to UX, followed by how we can begin to address some of the issues practically.

Good user experience is built from a variety of factors:

  • Flow: Users are so engrossed in what they are trying to achieve that they forget everything else around them.

  • Delight: Yes, you are actually trying to deliver delight through the tiniest interaction to the final outcome.

  • Frameworks: These define design patterns to allow users to understand their interaction intuitively.

  • Hierarchy: A way to ensure the audience understands what’s important.

  • Control: So users feel in control of the decisions they make, rather than being confused by the options presented to them.

Ultimately, what you are trying to achieve through the experience are results, efficiencies, advocacy and return on investment.

The mind’s eye does not naturally distinguish between individual elements that compromise an interactive system. The parts of the User Interface (UI) are not experienced separately by the user, but as a complete synthetic language that is apprehended and used as a unified whole. User experience is the art and science of integrating all of the various elements that comprise the UI. There is a careful balance between users’ expectations being served and organizational objectives met.

The UI is composed of more than you may think: written language, graphic design, sound, motion, information architecture, interface design, interaction design and programming — quite a lot more to consider than just ‘a bunch of wireframes, a bit of copywriting and a set of PhotoShop files’, which is what we as marketers tend to buy.

At MOI, we have a process called the 7Ds (see Figure 1) that we apply to every discipline, although they were essentially born out of digital design. The 7Ds are:

  • Discover (the audience and business needs);

  • Define (what needs to be delivered in strategy and information architecture); creative iDea (ok, we had to cheat a little bit there — this is where we start to pull a concept together based on our strategy);

  • Design (where we look at wireframes, copywriting, motion, sound);

  • Develop (the programming);

  • Deliver (where we test and deploy our solution);

  • Data (understanding how the product is working and making iterative changes).

Figure 1
figure 1

The 7Ds process design with UX weighting

Full size image

Depending on the type of project and the solution’s stage of maturity, this can be a two-week or a six-month process. Most good agencies or in-house teams will have a process similar to this. Where UX is involved in our process — and the weighting it is given — is shown by the size of the shapes in Figure 1. This should be true for anything you deliver. UX is involved in every part of the process along the way.

Some of the issues and how to address them

Typical B2B products and services can often be complex beasts answering multiple business challenges. Deciphering these and ensuring that the message is single-minded and clear can be challenging. This is not necessarily the responsibility of your UX expert, but should he or she flag this as a problem, it must be addressed.

There is a simple methodology taken from a tactic the US Army uses to prioritize decision making, called ‘Commander’s Intent’. A simple goal is set at the beginning of an engagement that holds throughout, regardless of whether the situation changes. If you use this principle for every single page designed, it becomes very useful. For instance, if it seems that the page or screen you are designing has more than one primary purpose, you probably need more than one screen.

Or what if, rather than adding more functionality, we spent our time perfecting the functionality we have?

It seems, as marketers, that we are increasingly asked to do so much with so little and user testing may get missed — first because of budget and secondly, because it can just be hard to find our ‘users’. There are many different ways to deliver user testing on a budget, but the key for me is to allow time for it — this is invaluable for the success of your activity. Pushing to hit a deadline (while important) should be weighed against how successful you want the campaign to be. User testing on a budget is possible. Tools such as fivesecondtest.com allow you to send tests to users and gather insights. Or simply find individuals within your business who may have a similar aptitude for the web (or apps) as your target audience and quickly ask them to run through a set of tasks, then monitor where they slip up.

I am sure there are some enterprise apps that will require training. I have witnessed and experienced consumer apps with similar levels of complexity that have been incredibly easy to understand. For instance, look at the difference between some of the popular marketing automation tools versus more consumer-focused apps, such as Campaign Monitor and Mail Chimp. I would argue that, when looking at like-for-like functionality within these tools, the latter makes it so much easier to do things and even delights you along the way. Whenever building applications, whether mobile, online or desktop, make your starting point ‘the user will learn as they go’ and not ‘we’ll need a training manual for this’.

Every industry has a vocabulary and acronyms — it’s our way of defining topics and themes that are important to us. Part of the issue is complicating the user journey with unwanted terminology that confuses users. I’ve always been a strong advocate of KISS (Keep it Simple Stupid) — removing jargon when it’s not needed. Taxonomy (not taxidermy!) is a methodology of using language to help define a user’s journey through a website using cues. These are important for a couple of reasons. For example, take the term ‘success stories’ versus ‘case studies’ as a menu item on a website. Success stories are defined as stories of people being successful in their roles. Case studies are defined as examples of how suppliers have delivered successful projects to their clients. Now, while only slightly nuanced, success stories drive user interest at the start of the buyer journey (How can I be successful?) while case studies may show buying intent to purchase towards the end of the buyer journey (How did this business do it for their client?).

Perhaps one other issue (and this last one is a complete assumption that I’d like to hear your opinion on) is that a lot of B2B products are dreamt up (and rightly so) by those who live and breathe development. These guys have their heads so stuck in code and making things work from a functional perspective that they forget the user and end up building a clunky product. It is almost a case of creating something to a point where it works and then, in true 1998 style, adding a drop shadow plus bevel and embossing and calling it design. OK, so this may be a flippant remark, but the quicker you can get the idea from the developers and test some of their theories, the better the product you end up with. I have heard stories of UX people refusing to work on projects that have gone too far down the line — they have felt it was almost impossible to be able to influence the project in a meaningful way.