Summary: User advocacy is one of the central activities of UX. User advocacy means recognizing that users are different to the people who create software and services and that because of this gap, user needs and desires need to be acknowledged and included in the design process. Anyone involved in UX work needs to be a good user advocate and see things from a user’s point of view, or fight for their needs where appropriate.
Why user advocacy does not happen naturally
User advocacy is a learned skill. Our natural default is to think of what we know, and assume others are behind us or have not put in the time to learn what we know. If you design with that assumption, you are probably guilty of ego-centered design.
IT professionals, designers, or managers were average users at one point. The difference is the average user has not learned sophisticated coping strategies for figuring out software/ products or UI technical problem-solving. Average users don’t care how a program works any more than you care about how a radio transmits signals while you listen to it or how plants metabolize sunshine to remain green when you look at them.
Average users don’t stop to think about how the programmer may have designed a system, how the database is working (as they wait for the round-trip of data back to the user interface) or what an icon or screen behavior means. The average user doesn’t know, doesn’t want to know, and has expectations that technology will work “as advertised” and “as expected”.
Defining “average user”
An “average user can include:
Anyone not working in IT, and not actively learning how software works. They just use it and expect a high standard of ease of use. If they do not discover features or how they work, they tend to ignore them, ask for help or use them in their own way (regardless of design or programming).
Average users might be:
- Your customer who wants things to “just work”
- A relative: someone in your family (mother, father, grandmother, grandfather, spouse, partner etc.) or what is often called “general population”.
- Someone with no formal IT background and/ or no “computer” exposure in school. This could be older but plenty of young people are not IT-savvy. Mobile or tablet yes, but web applications providing services might be complex for them.
- Someone from the Global South who has not had exposure to software/hardware experiences.
- A literacy-challenged person: someone who is new to or intimidated by complex words or instructions or even a keyboard/mouse or smartphone.
- A non-IT exposed person: a person who has not spent a lot of time with technology due to their circumstance (an elderly person; a young child; a person with disabilities).
Perform an “average user test”
1. Ask the person to open an attachment, edit it and then send it back to you. (Average users don’t understand that this requires selecting a non-system file area of your hard-drive first; saving it and then replying with the document as an attachment).
2. Ask the person to take a picture (with a digital camera) and send it to you. Depending on the usability of the hardware manufacturer, the user might fail to get past transferring the images to the computer. If they figure this out, where they store images on the computer may be the show-stopper (Average users don’t understand that a custom location needs to be defined and a novel name needs to be given to this “set of photos”).
3. Ask the person to reduce the size or lighten the image and send it to you. Image editing is not layperson-friendly. Mac OS makes this a little easier than Windows but the average user is not using a Mac generally, so we’re talking Windows for most average users. Also the average user is not installing all sorts of photo editing programs to find the “best one”. By chance they have installed what was provided with the camera, the printer, or something a friend or relative gave them- or all three. The average user did not install the software on their system of their own accord.
Rules for playing nicely with your “Average User”
1. Interaction with system level functions ain’t going to happen. This means set-up, installation, onboarding and all other “Out of Box Experience” (OOBE) aspects need to be considered carefully for average users. Decisions about exposing “back end” processes and rules should be made with caution. Where possible shelter the average user from “Preferences, Settings, Options” or at least centralize access to this area.
2. Customization and personalization behaviors are limited. Instead, study default behaviors and spend time getting default functions right (this can not be over-emphasized). Defaults are the comfort zones for users that keep them in their world, without entering yours.
3. Avoid Configuration. See “Configuration Hell- The Case for the Plug and Play User Experience”
4. Anything not apparent, transparent, obvious, intuitive, and explained may be problematic. Anything requiring understanding is not intuitive. Intuitive means it does not require understanding.
To simulate the cognition of the “average user” consume one alcoholic beverage and then try to focus on work (if you don’t drink, sit at your desk and play with social media for 20 minutes, then try focusing on a new task). That state of distraction, de-focusing, and inhibited response is close to how the average user processes your design. Conduct a usability test using the “think aloud protocol” and you’ll quickly realize how true (and I hope, funny) this is!
5. Get sober about your technology- on purpose. It’s easy to get pulled into the cool value of a technology, harder as a designer to step back and see the bigger business picture or user needs (gained from real observed user behavior). UX and user advocacy techniques are not designed to under-value technology, but rather to make technology or specific user interfaces -subordinate to user interests. This is why user-centered designs historically have out-performed system-centered design.
6. Ignoring the average user can lead to self-fulfilling prophecies. I often hear product managers say “our users are power users” or “if they don’t get this, they are not our users”. These assumptions are largely self-preserving and seem to counter the usability attitude of “user advocacy”. Promote a culture within your team of “Outside-In” design. Stop defending the merits of features and functionality without some independent outside verification from your users.
Remember user advocacy is as much realizing how technology or system-centric your own professional attitudes or behaviors are as much as those of your users.
Best wishes,
Frank Spillers, MS
