Whose profession is it? It’s Mine!

This article was the front editorial for Pabini Gabriel-Petit’s special issue on different stakeholders in the user experience.

We must step up to the plate and take ownership of experience design.

Focusing on "Whose profession is it, anyway?" you might ask, "Which profession are we discussing?" The professional interest is in "user-centered design," wherein professionals design and evaluate user experiences of human-computer interactions. There seems little consensus on who is responsible for that user experience.

Variously, we find that responsibility can fall to engineering, or marketing, or some collaborative group ownership. It seems like everyone's responsibility except our own. One might become resigned to the realization that it is politically inappropriate to claim our own expertise; but in the end this is shirking our obligation.

Taking responsibility

Attributing responsibility or accountability is different than attributing participation: We believe that UX (user experience) design is by its nature collaborative. Working with multi-disciplinary teams is a significant part of our work life. So why is it that UX design, unlike other disciplines, seems to promote a sense of collective work? Could it be that our conduct reflects our discipline's standards, rather than corporate standards?

Product management doesn't build or design products; their job is to own product vision and strategy (naturally with the other stakeholders' input). Engineers own code development and code quality, with a wide range of specialties (architecture, code design, QA, and release management, to name a few). Product marketers take clear ownership of marketing communications and product campaigns, keeping the pulse of the marketplace, and trying to detect what it will buy. Therefore, it's only logical that human-computer interaction professionals take ownership of the user experience. We are, after all, user experience experts, despite the fact that we depend on other development participants to meet user and business needs.

C-level ownership?

Why is it that we see few c-level managers for user experience? Chief User Experience Officer (CUXO) could be a formidable title. In most large software development organizations, user experience folks report in through engineering or marketing, whether there is a special group for HCI or not. That implies, however, that at the end of the day and after all possible design dilemma escalations, it is squarely the call of engineering or marketing (heaven forfend it should be our call) on what to create. We need our own high-level management who can directly compete with marketing and engineering management. (Please read that part again: This time and at this level we didn't say collaborate). Our agenda needs to be given the same respect as other disciplines. But this won't happen if we don't do our part. We must step up to the plate and take ownership of user experience design.

We've seen some positive changes in org charts: An HCI executive is no longer unheard of as we see more directors and senior vice presidents of User Experience. Little by little our agenda is slowly rising to the surface of formerly engineering-driven companies. But this puts all the more pressure on us to seize the moment and take control of our user experience.

If we aren't accountable for design, why does a software-making organization need us? If we don't fight for that responsibility, and we accept that our role is simply to suggest possible outcomes, our voices become weak and our protests unheard. We have a sneaking suspicion that our credibility is low because it's not our voices, but our rationales, that are weak. Insisting on ownership of the discipline comes with it a concomitant obligation to do the work with the highest possible standards, and that includes, like it or not, accommodating the quirks of marketing, the insanity of deadlines, and the caterwauling of engineers who have already thought of a cheaper, faster way to implement a requirement than the investment our designs require.

So what's the problem? Why don't they trust us with ownership? Are we inflexible, unschooled, uninformed, or just plain too crabby when asked to truly collaborate? Even in companies that proudly proclaim themselves "user-centered," all too often we see HCI activities included as an afterthought. When our work is conducted too late in the cycle it is pointless—if it has no effect on outcomes, it's a waste of time. Is HCI in your company just a checklist item deliverable? "Did you finish your usability testing? Great, check it off the project chart. You can look at those usability tapes when we're done with this project; we'd like you to focus on something else just now."

Some parting shots

Herewith we offer a few small pearls of truly sensible advice from some of the most difficult engineering managers ever:

• "Why bother with a usability test? It is what it is and it's too late; if you test it you'll expect us to do something about your results, and that isn't going to happen. Save the time for when it matters."
  
• "Please stop designing things. We've run out of implementation time."
  
• "Look, we're after a decent band-aid here, not elegance. Just get on with it or we'll do it ourselves."

You can always pack these concepts away for version n+1 (we call that type of cache of well-constructed design think-ahead as "blue sky"). Be a hero (if you're still there for the next release); revenge is sweet.

Other disciplines should be accountable for appreciating and abiding by our design and evaluation deliverables. It is not enough to require a design spec or a usability test's results. We've seen teams use lab testing to resolve internal disagreements when the number of test participants is barely larger than the team size; this is abdication of design responsibility to an extreme. We should not delude ourselves: There is a big difference between so-called discount methods and Machiavellian ones.
It could be that we all just need better persuasive powers, but we suggest that designating an accountable party (that would be us) in advance would (we guarantee) be much cheaper than extended debate. Engineers, product strategists, and others involved in delivering software experiences must commit to acting on our work. We'd like it if they understand it, too. Our commitment as a support to code development does not mean we can't have a controlling vote in a product partnership where consensus does not always rule.

Hold the soap

That is not to say that what a designer says is always the end of the line. We don't want to make a soapbox petition for control; we want a true dialogue on user advocacy and design sensibility. Designers need a thick enough skin to deal with critique, compromise, and collaboration, just like the developers, the marketers and the product managers. In each of our personal lives, someone, somewhere, told each and every one of us that people are supposed to just get along. This implies that the natural state of things is easy consensus. We beg to differ! It isn't supposed to be easy! You can admire and respect your competitors and your collaborators, but you do not always have to agree with them. And for the times that the discussion is on your turf, calling for your expertise, and demanding intelligent solutions from you, you need to be able to grab the ball and run with it.

When called for, we do need to be able to look any of our collaborative colleagues square in the eye and say: "I hear you. I understand your arguments; but we're going to do it this way."—eic Jonathan Arnowitz and Elizabeth Dykstra-Erickson

This is a draft version (preprint) of material which was later published in substantially the same form in my Rant column in ACM’s magazine. The published version is a copyrighted feature of Communications of the ACM. All requests for reproduction and/or distribution of the published version should be directed to the ACM.