Why I am a UX Designer
This Week's Challenge: Imaginary Film

Convince Me Otherwise


Reading through recent dialogues about the value that a UX professional brings to design and development work, and whether all the other web designers and developers out there should deepen their UX skill sets to complement their current skills—rather than hiring a "UX expert" on projects—has made me realize that many designers don't understand the secret weapon that UX designers wield as part of their toolbox.

It isn't the ability to conduct generative research, or create mental models, or bang out wireframes. Neither is it the ability to facilitate usability studies, write functional specifications, or prove out user flows.

I'd argue that you can't be an effective UX designer without the ability to specifically describe to a client why something should not be created.

Say what? Most frequently come to designers and developers when they want a site, application, or other tangible product to be realized. At the beginning of any project, everyone's excited that in knowing that it's your role is to facilitate the creation of those things. UX designer, make it real! Plan our future!

But as you move through the discovery process, it's often clear that what the client wants at the end of the project may not be appropriate for the users, feasible via the delivery technologies you've chosen, or contribute to your fiscal success. And you're the first person in line to explain why. A UX designer, as an informed facilitator across a large-scale project, is often the only person with the data to support killing a feature, or carving a section out of a website, or questioning the creation of yet another mobile application.

This means that beyond your opinion, or your making skills, that you're able to support the decisions that you make about removing or reducing complexity with the right kinds of data. Sometimes, the data is part of an empirical argument. If data doesn't exist, however, I may be working with other designers or developers or UX professionals to frame up a counter-argument, which may consists of anything from user flows to working prototypes of solutions that may run orthogonal to a client's stated ask, but fulfill the strategy we've agreed to in a manner that's more powerful than anyone had realized.

Some designers and developers are very good at doing this kind of thing. Some, not so much. Besides, an idea provided from (or killed by) a "UX professional" isn't an expert opinion, created in isolation. It's the point of view of all parties on the project: designer, developer, strategist, architect, all rolled into one. Each person creates a facet of the diamond—not just the UX designer.

Having come from a craft- and a (limited) code-based design background, I feel like I can understand and better communicate why things are wrong. I can be the glue between disciplines and try to be the point person to facilitate the most productive exchange. In a small design firm dealing with small projects, this was possible based on experience. If necessary, I could prove things out from wireframe to high-fidelity comp to full HTML.

But when creating large-scale products, expert systems, or transcending the browser as a delivery vehicle, the cognitive scale of kind of work is far beyond one, two, or sometimes even a few dozen people's full-time focus, especially if pursuing something that hasn't been seen in market before. Understanding that making these crucial, often transformative decisions can transcend your ability—or even a large-scale team's ability as a design professional—takes maturity and humility. You just can't do it all yourself.


The comments to this entry are closed.