Image credit: dynamicz34

UX Yin and Yang

Balancing Organizational Goals and the Needs of Your Users

4½ minute read

The disciplines of user-centered design have taught us to go to great lengths to ensure that we meet the needs of users when it comes to our products, but we shouldn’t be doing so at the expense of the organization’s goals.

Call it a lesson learned. Awhile back my buddy (whom I’ll call “Ted,” in an attempt to spare his identity) completed a project that he’d spent significant time designing and building. His team had gone to great lengths to make this Web-based application a user-centered winner: They’d researched, created detailed user personas, interviewed and observed real users in their native environments, prototyped their brains out, iterated. They had it all figured out.

The purpose of this app, in a nutshell, was to replace a manual process whereby customers would create custom orders on paper forms or PDFs and either fax or email them to his company’s Sales team. The Sales team would then create an order and forward it to the Production team to fabricate the finished item. These orders represented a small but tedious step in a larger process for their customers, so they needed to make it easy for them. Furthermore, it needed to tie directly into the production equipment that did the customizing. They were going full automation.

When the happy day came that Ted and his team were finally ready to roll their app out to customers, they were pretty stoked. It looked great. It worked great. They were UX gods and goddesses.

And then their Sales Operations Manager called.

Apparently, this shiny new app was creating additional work for Sales and Production. While they had given the user all kinds of flexibility, they were introducing new complexities for their internal teams.

Wasn’t the purpose of this tool to save the support reps time (They weren’t sure, but that sounded right)? And wouldn’t it have been great if they had included them in the conversation during development to get agreement on what they really wanted to get out of this app (it sure would have)? Ted and his team had gotten so excited about providing their customers with a useful, engaging product that they forgot to take a step back at the beginning of the process and identify the organization’s goals surrounding it.

They’d gone full-yang without considering the yin of the application. Business needs and user goals comprise the Tao of digital product development. The cost of this lack of balance was additional time and energy spent after the fact fixing a half-right situation. Without balance, your product suffers.

The Goals of the Organization

Every project should start by identifying the organizational goals that the product or service is intended to meet.

In a user-centered design team the user is, obviously, a primary focus, but don’t forget the business for whom you’re building the product.

As Margot Bloomstein puts it in her excellent book Content Strategy at Work, “user advocacy is simply a way of ensuring that a project achieves business goals.”

Every project should start by identifying the organizational goals that the product or service is intended to meet. In addition to creating user personas, identifying key user workflows, and understanding where the product fits into the user’s larger world-view, it is critical to answer the questions, “Why is my company or client building this? What do they get out of it?”

Examples of organizational goals might look something like:

• Reduce the number of calls coming into the Sales and Support Teams
• Increase brand awareness
• Cut down on the number of customer errors in the ordering process
• Meet the challenge of a competitor who offers a similar product
• Provide a new revenue stream

In Ted’s case, the biggest organizational goal he missed was “reduce the amount of work for the Sales team.” What he’d actually done was create more work for them. To say that this was an unpopular realization is, shall we say, an understatement.

Make Money-Money

The goals you identify early in the game will provide important guideposts as your research, prototypes, and iterations invariably start to change the scope and drive of your project.

Have another look at that list. “Provide a new revenue stream” seems like a universal organizational goal. A no-brainer. In fact, I’m pretty sure that all organizational goals can be boiled down to some variation of either “make money,” “save money,” or “don’t lose money.” To wit:

• Reduce the number of calls coming into the Sales and Support Teams (Save money)
• Increase brand awareness of the product that this tool supports (Make money)
• Cut down on the number of customer errors in the ordering process (Save money)
• Meet the challenge of a competitor who offers a similar product (Don’t lose money)
• Provide a new revenue stream (Make money)

It’s tempting to generalize. It is important, however, to call these objectives out specifically, at the outset of the project. The goals you identify early in the game will provide important guideposts as your research, prototypes, and iterations invariably start to change the scope and drive of your project.

Just as important: Make sure that you get stakeholder buy-in on these goals before you soldier down the path to user-centered nirvana. Ask the questions, “Why are we making this product? What objectives are we as a company hoping to achieve?” Ask your highest-level stakeholders. Write the answers down. Refer to them often.

The Organization Is a User 

The user interface doesn’t stop at a Web page or fancy online form or buttons on a remote control. It exists anywhere that users will interface with the product or process.

This brings me to the concept of the organization as a user; more accurately, “the users in your organization.” Users aren’t just the people outside the walled garden who interact with the front-end of your product. Your users include all of the players in the game.

Don’t forget to create a persona for your Salesperson. Consider the guy in Production who actually fabricates the product. Don’t miss out on the hidden, but important internal — or indirect — users of your product.

When designing a product, it is important to remember that there is more to it than a fancy GUI. The user interface doesn’t stop at a Web page or a fancy online form or buttons on a remote control. It exists anywhere that users will interface with the product or process. Whether those users are customers, or individuals within your organization.

With that in mind, it is critical to remember that your organizational objectives and business goals need as much TLC as your user needs. It’s a yin-yang situation: both sides coming together to form a whole.