This thing we call ‘User Experience’ – it’s a strange old beast, isn’t it? A fairly meaningless term in and of itself, yet the discipline, the skill set, the expertise it represents is absolutely fundamental to our industry.

The key word there is discipline. Sadly, it seems that all too often user experience is treated as just a step in a process, a task in a project plan, a department within an agency or a specialist within a team. But that’s not what it should be. It’s a state of mind, a way of thinking – a discipline that permeates everything we do as an industry.

Why?

Well first, what do I mean by user experience? It seems to me that everyone has their own version of it and, at the risk of digging up old controversies, I’m not even sure UX is the right label for it. So I’d better define my terms.

For me, user experience is the process of designing a product or service in such a way that it effectively, efficiently and hopefully enjoyably meets the needs of its users. It’s product design. Design in its broadest sense. Essentially, it’s just good design – because how can we design well if we’re not putting users at the heart of our thinking? (So if it’s just good design, why do we need to call it something else?!) But I think it’s so much more than just that.

I suppose the most obvious core pillars of UX are, on one side, User Research – the ‘input’ if you like, the gathering of data, evidence and information that allows us to derive insight and understanding of our users – who they are, what they need, what they expect and so on. On the other side is Interface Design – the ‘output’, the presentation of content and functionality in a way that enables the user to get or do what they want in the way that they want.

But it goes beyond that. We’re not just designing interfaces – we’re designing systems. And we’re not just thinking about user needs – we have to consider business requirements also. And business constraints. And content – copy, assets, data, information; where it comes from, how it’s managed, how it’s structured and classified.

Let me elaborate.

Digital products and services are created to meet a need – typically commercial, sometimes social, sometimes artistic. I’ll refer to these as the business requirements – because even if they’re not commercial, they’re still business-like. They’re the objectives set by whoever is paying or otherwise commissioning us to do the work. Whether it’s a web site, mobile app, intranet, extranet or whatever – it will have business requirements. Selling more physical product, raising brand awareness or improving brand perception, streamlining processes, easing access to information, driving membership, or just providing entertainment.

At the beginning of a project, these business requirements will often be vague, may be poorly conceived and are probably over ambitious. They’ll need working through in more detail and refining. Now, depending on the structure of the project team, and the particular roles within it, not to mention the processes of the agency, studio or department running the project, doing that may be Someone Else’s Job. They’ll probably have a title like Business Analyst, Planner or Account Manager.

They probably won’t have much UX expertise, though ideally they should have. It’s going to be much easier to derive realistic business requirements if all stakeholders have an appreciation of, and empathy for, their users. That empathy is at the core of the user experience discipline – so it’s not just designers who need it. It should run throughout every aspect of the business. But in its absence, the UX designer’s role can – must – include an element of business consultancy, guiding and influencing requirements.

Equally, we can’t design a good user experience without fully understanding the business requirements. Because it’s not just about designing something that lets the user do what they want to do – it’s about designing something that lets the user do what we want them to do, in a way that allows them to be happy doing it.

So we, as designers, need to understand the business we’re serving. It’s not enough to rely on someone else gathering that insight and then telling us what’s needed – we have to get right inside it for ourselves.

And it’s not just the front-end users that we need to think about. We also need to consider the back-end users, the administrators, the people inside the business who will be managing, monitoring or publishing to the product we’re designing. Which brings me on to business constraints.

Most web sites, intranets, apps etc are going to need managing to a greater or lesser extent. There will be content that needs creating or moderating, users that need managing, technical systems that need maintaining. There will probably be a CMS (content management system) or other back-end administration system. This may be off-the-shelf or it may be a bespoke build as part of the project. Either way, there will be interfaces that need to be designed and built or probably at least configured to meet the needs of their users. That’s the back-end administrator users – so we’ll need to know about them as well as our front-end users.

We’ll need to consider their skills, experience, preferences, availability… No point having a front-end user experience that relies on frequently updated content if no-one has the availability to create or manage that content. And perhaps best not to give a fully-featured WYSIWYG page editor to an admin who has no experience of page layout or typographic design, or where structured data input is more appropriate – that’s a sure-fire way to ruin that lovely front-end user experience you spent so much time designing. Or perhaps the solution is to train up the admins – does the business have the appetite for that? Do the users want to be trained? Should we be pinning the success of our user experience design on the successful outcome of a training course?!

All of those considerations are going to influence our design decisions in creating both the front-end and back-end user experiences.

Neither can we design a good user experience without knowing what the content is going to be. The type, the amount, the frequency of change, what needs to happen to old content as newer content arrives, the tone of voice and writing style if we’re talking about copy, the visual treatment if we’re talking about image assets… all are as much a part of the user experience as the interface itself. Not to mention interface messaging – errors, confirmations, instructions.

So we start getting into content strategy. We may not be responsible for devising that strategy, but we certainly need to understand what it entails, and we ideally ought to be closely involved in the decision-making. The platforms our product or service will need to run on, the screens we’re designing for, the other tools or functionality that will need to be available at the same time as the content, the interaction modes and input devices that will be used at the front-end… All these are likely to present constraints and opportunities that should be considered in the content strategy. UX and content strategy should not be separate processes – they are intertwined, iterative, mutually influencing.

And similarly, information architecture. The structure and classification of content is going to have a bearing on the user experience, and ideally vice versa. The type of experience we want to give our front-end users should ideally dictate the type of classification we use for our content (think facet navigation). But of course there are often business considerations that compromise this – the content may need to be classified differently behind-the-scenes for business reasons, or it may already be classified in a less-than-ideal way with no resource available to change that, or the ideal classification may be impractical to implement because of ongoing admin resource considerations. Either way, we’re going to need an appreciation of taxonomies and metadata schemas – we may even need to devise them ourselves – and at best ensure these enable the desired user experience, or at worst, design the experience to shield the user as best we can from what may be a very messy content repository behind the scenes.

Then there may be business processes, such as workflows and approvals, that need to be reflected in the administration interfaces. But what if those processes don’t actually work, aren’t fit for purpose? What if, in an environment where speed to publication is often more important than perfect copy, an approvals process takes so long that the content is out of date before it reaches the front-end? The obvious answer is to change the business processes. Or failing that, change the business requirements – and hence likely also the user experience – of the product or service. It is not at all uncommon, in my experience, for a project that initially, on the face of it, seems like a fairly straightforward user interface design job, to turn into a business transformation exercise.

Now, that may seem like the sort of thing that’s way beyond the remit of your average user experience designer – but should it be? If designing the right user experience necessitates business change, who’s job is it to explain that, to identify what needs to be changed, and to make the case for it? (Sure, it’s probably a business consultant, but wouldn’t you – as the designer of the user experience, as the owner of that vision, want to be at least closely involved in that, if not leading it? Or failing that, wouldn’t you want a business consultant who’s well-versed in the UX discipline?)

So, taking all of that into account, what we’re really doing is designing systems. Front-end and back-end user interfaces, content structures and hierarchies, metadata schemas and taxonomies, navigation, interactions and functionality, business processes and workflows (including sometimes offline processes, outside the system itself), data flows, data capture, metrics and analysis…

That means our role goes far beyond just ‘design’. I’d even argue that the actual design piece is really only a small part of what we do. We need to wear a lot of different hats. We need to be as much consultants as designers. We need to be content strategists, information architects, probably even writer-editors too.

And I haven’t even mentioned technical considerations – yes, UX designers should know how to code, at least to a basic level. We must understand the materials we’re working with.

Nor have I addressed the approaches, techniques, tools we might use to understand our users, to gain insights into their needs. So we need also to be researchers, facilitators, listeners, analysts…

Yep, we wear a lot of hats!

And we need to have a lot of fingers in a lot of pies… To design – and execute – a great user experience, we need to be involved in the project right from the beginning, and across all of its stages and processes. UX isn’t a time-boxed task that can be slotted into the project plan somewhere between requirements gathering and development. It needs to run throughout.

We need to understand the business context and inform the business requirements; we need to understand and engage with specialists from other disciplines – especially content and technical – to design the solution; and once the solution is designed, we need to own and champion that vision, to ensure the product eventually delivered lives up to it.

But equally, UX goes far beyond our own role. Business stakeholders, analysts, planners, account managers, content strategists, information architects, developers… all need to put users at the heart of their thinking. UX is relevant to everyone. Ideally, everyone involved in the project would be well-versed in the UX discipline.

But that’s almost never the case and likely will not be for many years to come – there’s a huge shortage of UX skills and experience, even within the UX community, let alone outside it. So for now, UX remains a role, a specialism, a task someone gets brought in for. Not how it should be, but how it all too often is.

So there’s a tension between UX as a role and UX as a discipline, between narrow and broad definitions of the term.

As a role, UX has a fairly narrow definition, focussing literally on what the end user experiences – in which case let’s just call it interface design and be done with it.

Or we take a broader definition, encompassing all of the other things that impact on the end-user’s experience, in which case it’s more like product design, architecture – it’s a discipline rather than a role, a way of thinking, a set of functions that rarely can be covered by one person alone, yet which diminish in effectiveness the more they are separated from each other. Perhaps one could say UX is the glue that binds these otherwise fairly traditional functions together and makes them work in the context of digital or interactive media. It’s a mindset that everyone should have, whatever their role.

So what then, exactly is a UX Practitioner? Ah… Well, that’s for you to decide. Many years ago I wrote an article in which I argued that we should ignore job titles and instead focus on the role. I would say that still holds true today.