The Client As a User
"The client is not the user."
It's one of those incendiary sentences that come up often in discussions and articles about user-centered design. Sometimes phrased as "You are not the user" or the "The company is not the user." A simple declaration that encompasses a larger idea where we acknowledge that business goals are not the same as user goals and "good" designs aim to improve the experience of the public user.
From the early research and planning stages, user-centered design (UCD) focuses on the users and their tasks. Design and implementation generally comes in iterative steps, each prototype or release subject to continued observation and tweaking to meet those users' needs.
For engineers and software designers, user-centered design brought forth an important mantra: "You are not the user." Our inside knowledge of a system and its interfaces obstructs us from understanding how a new user may interact with the product. In a way, UCD was a blessing. Our responsibility to "design it right the first time" was lifted. In time, even the emotional connection and ownership we had over a product or even a portion of the interface was also lifted. We built and designed things and released them to the public without the same thought that we were sending out children to the wolves. A product had no life or value until the users had accepted it, until the data had validated that we had interpreted the research and usability labs correctly.
Thus, those that build the product are not the users. But does that mean clients are not users either?
I can certainly understand the statement "The client is not the user" having worked as a freelancer and within an agency for 7+ years. Having worked with smaller companies that had no usability data—not even something as simple as Google Analytics installed-—nor the time or cost (or patience) to do user testing, the list of requirements that came to us in the planning stages were a list of business goals. I was tasked with "get more leads" rather than "make the inquiry form more user-friendly." Luckily, user goals can be tied to business goals at times and it wasn't too hard in these cases to make the argument that we should consider removing the unnecessary address and job title fields so that users would feel more confident in filling out a form (and thus get more leads for the company).
Another scenario where "The client is not the user" occurs when you're not really dealing with the company as a whole, but a representative of the company. I call it the Tyranny of the HiPPO (Highest Paid Person's Opinion). The CEO of a company, the Sales Director, the Board of Directors — people in these roles feel that they, and only they, know the mind of the customer and thus they, and only they, can make the decision about a user flow or feature. But in reality, these people are in the same situation as the engineers and designers; they are too involved in the product to know the needs of the user. Even when presented with data I've collected showing the contrary, nothing can change their mind that a feature should function a certain way. Pride and salary dictates design at this point, not the needs of the user.
But finally, let me get to the point of this article.
"The client is not the user" is the wrong way of thinking.
In an ideal world — a world where every client project is Apple, Facebook, or MailChimp — the HiPPO doesn't stand in the way of great design, the product has a near infinite amount of resources and money, we could stop right here and walk away with the wisdom already stated.
Face it, designers: that's not the way things are. Clients are strapped for time, money, people, knowledge, and patience. The feature you know will be so incredibly amazeballs for the user relies entirely on the company's ability to produce the content for it or hire staff to support it. It's hard for me to discuss this in generalizations, so here are a few recent situations that demonstrate my point.
Problem: A large B2B company sold large equipment to specialized small businesses but sold through a long-tail sales process and not via an online store. While their model was not to start an online store, data showed that the quality of leads and led to more complete sales when they had more details about their products available on their website.
Solution: An online catalog of the company's products with photos, detailed technical specs, and descriptions.
Resulting Problem: The company sold products from a number of manufacturers but hadn't secured partnerships with each that included the rights or access to assets to product imagery and copy.
Problem: The company wanted to be known as having the largest inventory of used equipment for sale in the region, but their current listings were spread across individual dealerships in the area. There was no central way of searching and there was a painful amount of spotty entries that lacked valuable data.
Solution: An robust searchable online catalog of used products that included photos and basic specs, as well as their location and proximity to the inquiring user.
Resulting Problem: There were many locations, some better staffed than others, and each location would be required to take photos and enter in data for all their products on a continual basis.
Problem: A national company had a decent catalog of products and services but no call to action for the user to take.
Solution: We proposed adding an online inquiry form for products and services that weren't purchasable online.
Resulting Problem: Inquiries had occurred previously via phone, at a location, or directly through an already established relationship with a sales rep. Each inquiry was handled differently per location and there was no person that fielded general inquiries or directed them to a location's sales rep. Furthermore, some sales reps stubbornly wanted to remain "old school" and only deal with potential sales via phone.
In each case, we had data from usability tests and surveys that overwhelmingly supported the need for each feature. Our point of contact in each case was also thrilled with the suggestions, so this wasn't a situation of end user v. HiPPO. Having to argue the need for the feature wasn't the issue.
We as designers have to take into account that the client is a user. In every project, we have to take into account the persona of the client-user, or more accurately, the Content Manager (or Webmaster or whatever title applies). What are their pain points? What makes it difficult for them to achieve their needs?
Types of Pain Points for Client-Users
Lack of Content
The content just doesn't exist at all. The client would have to hire an internal or third-party copywriter, videographer, graphic designer, or photographer in order to create the needed assets.
Lack of Knowledge
The person or team responsible for managing the site after launch doesn't have the technical skills to maintain what you've designed. If you've implemented a CMS of some sort, the admin or admins don't understand how to write HTML or even have the skills to figure out to embed images, links, or videos.
Lack of Resources
Sometimes, the resources missing are personnel: the client has no one that can act as an operator to field general calls or emails, a content manager to assign blog topics, a customer service department to deal with online transaction issues. Other times, the resource missing is the technology need to accomplish a task: the camera equipment and image editing software needed to take product or staff photos; the database, XML feed, or API that contains product or customer information; the internet connection needed to send updates from within their shipping warehouse to the online CRM.
Lack of Infrastructure
Not only is the company lack the personnel required to deal with content or knowledge deficiencies, but the company structure as a whole is organized in such a way where certain groups or people lack accountability or core management. Branches or dealers work independently and are in a constant struggle for power and leverage. Getting disparate groups to work together for a unified experience for the user is met with hostility or inaction.
Met with all these barriers, I've seen engineers, product managers, and designers roll over and cut out the proposed feature. "Maybe we can do this at a future point," they tell themselves. "Just not in this release." What a disappointment for the public user.
Creating Solutions for the Client-User
Create fallbacks and design for empty states
Sometimes a fallback can be as simple as "Image Unavailable" for an item. Other times, you need to code a complex series of if/else statements that achieve the goal of consistency across templates, but don't leave the user frustrated at constantly running into an block of missing content. Maybe your content has live text for some entries, but PDFs or videos for others. Can you alter your design enough to accommodate different types of media?
At times, the content just isn't there for one entry as it is for another one. How can the business goal of gaining more leads and the user goal of getting more information be met if you just leave it a blank? Design a solution for this context, such as adding an inquiry form where users could ask for certain details with no obligation to purchase (e.g. we asked for a bare minimum of contact info and did not add their details to an email list).
Create a usable content management system
It's rare that a website project will be designed without some sort of content management system, whether it's WordPress, Magento, ExpressionEngine, or Drupal. As a user-centered designer, be concerned not only with how the interface appears to the public user, but also how the interface functions for the client-user.
Too many times, I see engineers solely in charge of the administrative view and the client-user confused on how to add or edit content. In time, the public-facing interface will suffer as the client-user continues to fail to grasp how to go about managing their site. Be aware of how your designs are being coded and identify pain points for the client-user as early as you can.
In one recent project, we were using ExpressionEngine as the central CMS for the company website and at the national level, admins used this tool to edit content. However, the system was overly complicated for the needs of certain smaller group admins. Therefore, we create a simplified portal and interface for these dealers to manage their inventory. The portal also contained training docs and we hosted a training session for the users at implementation.
Another example is when we used an API from the client-user's existing intranet to pull in content dynamically. Rather than force the client-user to use and understand our portal, we used the intranet's data feed to automatically import the content. Thus, we were able to get around the pain point around learning new technology to accomplish the goal.
Create flexible design components
Design for the future needs of the client-user. For example, you've created an event template that tested well with public users, but the client wants to publish an event next month that has a lot more additional information like speaker bios and workshop descriptions. Create designs that can maintain their usability and effectiveness when content is added or deleted.
Create smarter lead generation
When infrastructure becomes an issue (such as not having a General Sales Manager), adjust your call to action to adapt to the client-user needs. If gathering the zip code on a lead generation form, use that data to determine which email address to send it to. For the "old school" sales reps that insist phone calls are the best at leading to sales, use phone tracking on each page and track the data.
If using Salesforce or a CRM, integrate inquiries or sales from website actions. At the very least, include data in the notifications about where the public user was (which page) when the action was made.
Love the Data
Whether deciding which product or category needs better content or which sales rep is struggling to use the system, data will help you create a plan of action for the client-user. Just as usability testing like user labs, surveys, or focus groups can help with iteritively designing a product, empirical data can help the client-user decide where to next focus their resources in bite-size iterations.
Track where the most users are seeing fallback or empty states and schedule a calendar of which products or categories needed unique content created. For example, rather than investing the time and money in product photography for their 500+ catalog, use your data to figure out which categories of 20 - 30 products could be addressed first.
If the client-user is having personnel or infrastructure problems, use the data to predict if additional personnel should be hired to meet goals or to create a leader board to encourage behavior around answering online leads or sales.
User-centered design is not a battle between the public user and the client. Learn to balance business goals with user goals, business deficiencies with user needs. Recognize the interface is not just the outward facing website, but many other views as well: the missing image, the email sent to confirm an order, the CMS to add new inventory.