Hang around long enough with UX designers, and you’ll hear someone say it: “I’m an advocate for the users.” If the designer is especially nerdy, she’ll quote Tron: “I fight for the users.” She’ll go on to explain she’s the one who brings the users’ voice into “the room.” (A euphemism to describe the project team.)

This is an alluring stance for designers to take. (I know — I’ve said it myself earlier in my career.) For one thing, it sounds heroic. (Again, cue the image of Tron holding his disc over his head, ready to sacrifice himself for what is just and good and true.) For another, it clarifies designers’ position vis-a-vis the tough decisions ahead. Or so they think.

As compelling as it may be, “I fight for the user” is a misguided position for designers to adopt. Yes, it’s important to consider the needs and expectations of the people who use the organization’s products and services. But user needs aren’t the only forces that influence design.

The subtext to “I fight for the user” is that in this context (in “the room”) the user needs a feisty advocate — perhaps because others don’t care. This sets up a false duality: if I’m here for the user, you’re here for other reasons: making money, saving money, reducing call center volume, etc.

This framing isn’t healthy. Everyone should come to the room with the understanding that user needs will be important. It’s table stakes. If this attitude is not present from the start, then the designer should strive to bring it into the room — but as a way of building alignment with colleagues, not drawing distinctions between them.

So if designers aren’t in the room to “fight for the user,” what are they there for? Designers are there to move the project towards alignment between forces that could otherwise pull it apart. These forces include (but aren’t limited to):

  • Deadlines

  • Budgetary constraints

  • Regulatory/legal constraints

  • Production constraints

  • Business goals

  • Customer needs

  • User needs

  • Social needs

Striking the correct balance between these forces requires understanding their relative importance, which varies from project to project. (For example, healthcare projects have different regulatory constraints than those in entertainment.)

The team may get the initial balance wrong. That’s why we test prototypes in real-world conditions: We establish feedback loops that move the product or service towards ever-better fit with its context or market. Design’s role is in this process is making the possible tangible, progressively moving from abstraction to concreteness as the team iterates through increasingly better prototypes.

Eventually, the product or service will be in good enough shape to put into production. Design’s role then shifts to translating the intended direction into artifacts that guide the people who will build it. This requires understanding what developers need to do their work effectively. (It’s worth noting that this doesn’t need to​ happen in a strictly sequential “waterfall” manner.)

Shepherding this process calls for clarity and nuance. Good designers understand the relevance and directionality of all the forces shaping the project. User needs are an essential force, but not the only one. To pretend otherwise is to do a disservice to ourselves, our organizations, and design itself.