Client-Centered Services

By Tal Bloom

Published: April 22, 2013

“Just as we ask our clients to focus on users when making design decisions for their Web site, shouldn’t we similarly focus on our clients when making service decisions for a project?”

As UX professionals, we practice user-centered design—which means we stay focused on users and their needs when designing a Web site, product, or service for a client. We may spend days, weeks, or sometimes even months surveying or interviewing users or conducting diary studies or focus groups. Often, we create personas to crystallize our understanding of users and their needs. Ultimately, a Web site exists for the sake of its users. If users are not able to find or comprehend the information or functionality that a client’s Web site provides, it won’t be useful to them. On the other hand, if we endeavor to consider the user’s perspective in making every design decision, we can help to ensure a meaningful and successful experience for the users of a client’s Web site.

To actually put this into practice, though, we need to convince our clients to follow our UX approach. Why is this sometimes difficult? Because our clients are naturally more focused on their business goals than on user needs. In truth, though, there’s no contradiction here, because users are an essential part of any business. A Web site’s users are the people who, hopefully, will buy a client’s product or service and avail themselves of the resources and knowledge that it provides—thereby generating income for the business and keeping it running.

Well, just as we ask our clients to focus on users when making design decisions for their Web site, shouldn’t we similarly focus on our clients when making service decisions for a project? After all, a Web-site design project exists for the sake of the client. So, perhaps if we endeavor to consider the client’s perspective in making every service decision, we can help to ensure the successful delivery of the project on time and within budget.

Figure 1—Consider your client’s goals and user needs to create a usable design and useful content

Consider your client’s goals and user needs to create a usable design and useful content

View the full-size image

In this article, I’ll flesh out these ideas, but first, let’s take a look at a case study.

Case Study: Cultural Roadblocks

“There was another way to get the project moving forward: help my client solve their problems.”

A recent client of Stamford Interactive had many difficulties with the user-centered design approach. It became apparent early on that they were steeped in the traditions of their medical profession and used to having the final decision. Their existing Web site was typical of the 90s. I had spent a little while browsing through it when the penny dropped: the site was entirely business centric. Each of the primary sections was named after the business unit that managed its content and had its own variation of branding, and much of the content wasn’t relevant to anyone outside the business. Presumably the business units just wanted to let the world know what they do.

So, how did this realization affect my approach? I spent three-quarters of the kick-off meeting explaining the user-centered design approach to the client. I asked the stakeholders to tell me what they understood to be the purpose of their Web site: “It represents the business.” “It’s a portal for our users.” “It’s the technical interface with our doctors.” Then, I endeavored to demonstrate how each of their answers was really a component of something greater. “Really, you have a relationship with your doctors,” I said. “Your doctors want to be able to serve their patients, and your services are designed to help them do this. The purpose of the Web site is, therefore, to facilitate your relationship with your doctors, helping you better help them.” We then proceeded with brainstorming the user profiles for the Web site.

They loved the kick-off meeting, and everything went smoothly for a couple of weeks as we continued the project with workshops, stakeholder interviews, and other requirements-gathering activities. Eventually, we got to a content workshop, during which we began the process of compiling a list of the site’s necessary content to use for card sorting. The workshop went well, and we left the client with the task of finalizing the content list. One week, two weeks, three weeks went by. I didn’t receive any content list, just excuses. “What’s going on here?” I asked myself. After gently nudging and dropping hints about our project’s timeline, it eventually came out: They needed the business units to create their relevant content and were having serious difficultly selling the user-centered approach to managers who didn’t want to see their business unit’s name fall from the glamorous heights of the primary navigation bar.

Okay, so I managed to convince my client, but how on earth do we convince the other stakeholders in this political web? The classic project-management options to get this project moving again would be to either

  • find a way to connect with these stakeholders and get them on board, beginning by acknowledging their concerns, or
  • concede that they’re not reachable and just proceed the way they want, with the risk of compromising the user experience

On this particular project, though, there was no way for me to get in front of the stakeholders, and my head spun when I tried to envision how I would design a Web site that organized the information according to business units. This problem had me stumped until it occurred to me that I should shift my focus from the project to the client. I realized that I actually have a relationship with the client. Therefore, there was another way to get the project moving forward: help my client solve their problems.

Turn Up Your Warmth

“By taking a more client-centered approach, you can quickly uncover the underlying problems that are causing your client’s recalcitrance, giving you the ability to keep the project moving by helping them solve their problems.”

When a client seems to be creating unnecessary project hurdles, it may be tempting to play hardball and tell them that the timeline and budget slippage will cost them or, at the other end of the spectrum, to concede and do anything just to get the project over the finish line. But, by taking a more client-centered approach, you can quickly uncover the underlying problems that are causing your client’s recalcitrance, giving you the ability to keep the project moving by helping them solve their problems.

There is an old Jewish adage that is a great illustration of the principle that is relevant here: One day the sun and the wind were watching a man walking through the desert, and they both noticed that he was wearing a jacket. It seemed strange to them that anyone would wear a jacket in the desert, where it was very hot. The wind said to the sun, “I’ll bet you that I can get him to take his jacket off faster than you can.” The sun said, “You’re on!” Then, the wind blew and blew, trying to blow the man’s jacket off, but the harder he blew, the more tightly the man grasped hold of his jacket. After a while, the wind stopped blowing and made way for the sun to have a go. The sun shone brightly with extra warmth, and in a short while, the man slipped off his jacket all by himself.

What’s the lesson? Although it is sometimes tempting to push a client when they’ve become too aloof or to push back when they’ve become a bit too demanding, the truth is that the best way to keep a project rolling and sustain a healthy relationship with the client is to turn up your warmth. What do I mean by this? Be exceedingly collaborative, practice immense patience, and focus your attention on solving your client’s problems.

Change Your Motivation

“We need to endeavor to discover the motivations underlying our clients’ behavior to help us make informed service decisions.”

To help our clients solve their problems, though, we need to understand their problems and see the situation from their perspective. Our clients are people, too. Just as we go to great lengths to get to know a Web site’s users and strive to understand what drives their behavior to help us make informed design decisions, so too, we need to endeavor to discover the motivations underlying our clients’ behavior to help us make informed service decisions.

This is true at all times, but becomes essential to providing good service when a client’s behavior becomes irrational or unreasonable. In such a case, after some probing, it could come to light that they’re still stuck in a business-centric mindset, with their focus on business goals, not the user experience. Or perhaps they’ve got a manager breathing down their neck asking when the Web site will go live because they want to impress some of their overseas stakeholders. Or maybe they’ve got personal issues.

In any case, rather than just trying to figure out how to get what you need from your client—even for the honorable purpose of keeping their project on track—or just agreeing to whatever they say at the expense of the user experience, the client-centered approach endeavors to see things from the client’s perspective, so you can figure out what you could do differently to help them solve their problems.

Be Willing to Reconsider Your Approach

“It can be the path of least resistance to rethink your planned activities to see whether it’s possible to spend the remaining budget in a different way to get to the same desired Web site.

Far and away the easiest way to uncover what’s going through a client’s mind is by having a conversation with them—preferably face to face. Of course, you can’t just ask them, “What’s going on in that head of yours?” Instead, when you seem to have hit a rough patch with your client, you might gently ask some probing questions at your next meeting with them. If you don’t have a meeting scheduled, think of a useful reason to hold one. For example, perhaps you could suggest having a mid-project review meeting to get everyone back on the same page or holding a workshop with the client—and maybe some stakeholders—to answer some questions that have arisen.

Once you’ve discovered what the underlying problem is, you can take action to help to solve it. Sometimes all that is necessary is to help clarify some aspects of the user-centered design process, document your design-decision rationale so they can pass it on to stakeholders, or revisit your user research to further validate the project direction. Whatever it is, your aim should be to help empower your client to resolve their problems.

In dire situations, however, you may even need to rethink your whole approach to the project—within reason. Again drawing a parallel with user-centered design: Although the Web site exists for the sake of users, there are usually some constraints within which you must make design decisions. Of course, there are budget and timeline constraints, but often there are also technical constraints or brand requirements that limit the scope of your options in addressing users’ needs.

Likewise, with client-centered service: Although the project exists for the sake of the client,  there are some constraints within which you must make service decisions. Of course, there are again budget and timeline constraints, but often there are also resource constraints or business strategies that limit the scope of your options. In most cases, however, you can rely on two things:

  1. At the end of the day, the client wants their new Web site.
  2. They’ve already signed off on a certain budget to make it happen.

This being the case, it can be the path of least resistance to rethink your planned activities to see whether it’s possible to spend the remaining budget in a different way to get to the same desired Web site.

So, with an open mind and an awareness of the project constraints, you can begin recalibrating your approach. Remind yourself of the overarching purpose of the Web site—namely its role in achieving specific business goals—then question each planned activity to judge how useful it would still be in achieving the project goals, given the existing situation. Don’t be afraid to take resources from less useful activities and allocate a larger part of the budget to more useful activities or to entertain the idea that certain standard, user-centered design activities might not be useful at all in this case and that non-standard activities might be more useful. Really exert yourself to look for ways in which you can achieve what’s best for the client.

Empathize for Success

“Empathizing with our client, seeing the project through their eyes, and appreciating their problems is the best way to help solve their problems … and achieve their business goals.”

With my last words echoing in your mind, perhaps you’re thinking to yourself: That all sounds very nice, but how do I know that we’re not going to burn through the rest of our budget and end up taking a loss just to deliver a Web site that compromises the user experience? Let me answer your question with another question: Why is it that user-centered design has been so successful?

We know that empathizing with users, seeing a Web site through their eyes, and appreciating their needs is the best way to ensure that a site meets their needs and is intuitive and friendly for them to use. And by extension, a business is more likely to achieve its goal of selling a product, service, resources, or knowledge that ultimately generates income and keeps the business running.

Similarly, we need to realize that empathizing with our client, seeing the project through their eyes, and appreciating their problems is the best way to help solve their problems, ensure the project runs smoothly and efficiently, overcome hurdles, and achieve their business goals. And by extension, your consultancy is more likely to achieve its goals of having happy clients, getting repeat business, and building a great portfolio of work.

Case Study Redux: A Cultural Shift

Going back to the case study that I described earlier: The situation of the organization was that it had such a deeply embedded culture of business units protecting their own slice of the business that our client was stuck. On the one hand, they wanted to pursue user-centered design. On the other hand, not too surprisingly, changing an organization’s culture from one extreme to another may meet strong resistance and, therefore, cannot be achieved overnight.

After a few discussions, we agreed to rearrange the project plan. I was to go ahead and draft an information architecture, prototype a couple of key user journeys, create some low-resolution visual designs, and document my design rationale—all based on my current understanding of their domain and my years of consulting experience. The goal was to use these deliverables as sales tools to convince all of the business stakeholders that the user-centered approach would produce a solution that would be far easier to use, more useful, and therefore, more successful than their current Web site. Subsequently, we planned to proceed with a cut-back version of the project plan, assuming that what I had managed to produce would give us a head start on many of the UX activities.

I had never done anything like this before. Usually, I would advocate that the safest way to undertake a Web site design project would be sequentially collecting business and user requirements, doing a card sort to establish the site’s information architecture, creating a prototype, and testing it with users before beginning any visual design. But in this case, I conceded that the project plan needed to be dynamic—within budget, of course! In the end, the client was happy because, not only were they going to get a beautiful new Web site that would be useful and usable, they would also receive help in finally shifting the culture that had caused so much division within the business. They admitted that, for a number of years,┬áthis cultural issue had been an Achilles heel for the business, and try as they might, they hadn’t managed to make much progress in transforming it into the desired culture of collaboration and unity—until now.

Build Client Relationships

“To create a great user experience for a Web site, it may be necessary to help solve a business’s problems by helping to shift its culture.”

By now, you can appreciate that—although a client’s Web site comprises useful content that is presented through a usable user interface—in a deeper way, it is the face of the business. Just as a person’s facial expressions communicate to the outside world what’s happening inside, a Web site reflects the internal state of a business. Therefore, to create a great user experience for a Web site, it may be necessary to help solve a business’s problems by helping to shift its culture. Attempting to do this may seem quite confrontational to your client and stakeholders, so be sensitive in your approach. And remember, even though you may achieve what seems like only a small shift from where you’re standing, it may well be a monumental shift from their point of view.

Everything begins at the kick-off meeting. So, rather than focusing on a UX project’s usual matters—scope definition, project plan, and resourcing—though you must, of course, cover these bases, shift your focus to establishing your relationship with the client. Get to know the people who represent the client—their personalities, their culture, and their personal interests in the project. Perhaps you can even ask them for their preferred way of engaging: Do they prefer weekly, face-to-face meetings or email messages and phone calls; regular reviews of work in progress or presentations of more polished outputs?

Always be sure to take your client—and preferably the other stakeholders, too—on the journey with you. Explain what you’re doing and why, and walk them through the feedback you receive from users as you go. This way, not only will they feel more comfortable with the user-centered design process, you’ll have more opportunities to strengthen your relationship with them, become familiar with the problems they’re facing, and thereby, be able to put into practice the idea of client-centered service.

Join the Discussion

Asterisks (*) indicate required information.