As individuals, we have many user experiences over the course of a day. Certainly over the course of a week, month, year… indeed a lifetime. In a sense, we become experienced users over time of many things, and remain inexperienced users of many other things. In some instances we feel we can extrapolate the experience by comparing it to ‘like’ experiences.
When it comes to designing apps for use on the internet, software, or web, everyone is an experienced user. At least that’s the impression I’ve gotten over the years in dealing with clients and colleagues.
Let’s take clients. They are often made up of many constituents: a business owner, stakeholders, marketers, project managers, IT geeks, editors, business analysts, and possibly even cobbled together components of a web team. Each of them has an opinion. Each of them view digital projects in terms of their own interests, experience, discipline and exposure (or lack thereof) to similar types of projects. They also have their own agendas – which are a double edged sword – that guide their actions.
I could almost forgive them, as they try hard, they all want to succeed for different reasons, and if their business does well, they will all look good. Unfortunately, just because 8 people are rowing in a boat doesn’t mean they are all rowing together – that takes time, collaboration, recognition that they are all working towards the same goals and objectives, and an honesty about their capabilities.
I could almost forgive them. But I won’t. They should know better by now.
But it’s not the clients that worry me most.
It’s people I’ve worked with over the years – and will work with in the future. The ones for whom the phrase ‘you represent the user on this project’ applies. The people who say it often have no clue what they are talking about. Of course, the only people who can represent the user on the project are, well, the users. And the Information (or Experience) Architect, who gets used to being beaten down when talking about inclusion of the user, after a time begins to believe that the only way to include the user is to ‘be’ the user. This is the one that really frightens me.
No Virginia… you are NOT the user.
The Information Architect brings a bag of skills and tools, a degree of experience, and the capability to open the doors to engaging with users on a project. The user should be the first port of call. Who are they? What do they want? How do they live? Why would they use or want a client’s products or services? When is the best time to engage them? Quantitative statistics that can only answer, to some degree, some of the questions above can only provide pathways to partially thought out designs.
The IA is often left to sort out the rest. And the worst part of this is that the more it happens, the more confident they become in their own capabilities – those of actually representing the user on projects.
Where UX represents a world of ubiquitous experiences for users (also see my blog posts on UX and the Art of Digital Appropriation and Pervasive UX – Who is Responsible?), more Information Architects, with their own values, interests, varied experiences and goals provide a dangerously seductive (and less costly) alternative to representing user experiences on projects.
I think this is something that everyone needs to be aware of and consider when they limit the potential of a project from the beginning by assuming the inclusion of Information Architects solves the issue of user engagement in the process. You cannot say you practice user-centred design when you do not engage users in the process.
No Virginia… you are NOT the user. The user is the user. Someday, you may have the opportunity to be a user on a project – where you are not doing the design. But until that day, please, everyone involved in projects, work harder to get to know who your users are, and please, do involve them in the process. It can be really quite rewarding!