24 June 2007

Software that Behaves Like Spoiled Brats

As many people know, one way of analyzing interaction design and system behavior is to do something that has many different names, but usually sounds something like dialog analysis. Dialog analysis is the process of analyzing the software interaction as if the system is a human being who is performing a service for the client, aka the

woe-besieged user. After careful analysis of many products, it seems to us that if most commercial software and Web products were humans, they would be characterized as greedy spoiled brats. Just for an example, look at the way desktop products, customer services, and Web products behave.


Desktop Products


Office productivity tools make you do somersaults to undo their automatic formatting. They also drive you crazy with the collision of features they never knew would be used together. One word processor we were using to create a large document from many sub-documents refused to behave—auto-indenting, bulleting, or renumbering tables into items. It so destroyed the formatting and twisted the style usage that we had to resort to using flattened pictures of some tables and formats. When you try to do something that a product's designers didn't anticipate, some products exact their revenge: They do the digital equivalent of throwing everything into a heap, leaving you to clean up the mess all by yourself. This is marginally acceptable behavior from a two-year-old child learning the concept of patience. It is reprehensible behavior in adult human-computer interactions, and it turns the product into something we call a spoiled brat.


Customer Service Products


How ironic that some of the most abusive products around are software products designed for customer service. Let's just take call-center experiences as an example. Phone trees in service calls exhibit "do what I say or else" behavior. The user follows patiently along only to find 17 steps later that the end point is closed, or does not give you the information you expected, or transfers you to a busy line, or leaves you no way to return anywhere but to the beginning of the long depressing tree. Brat.


Web Sites and Services


There are also hidden brat interfaces that reflect the bratty intentions of their owners. All too many Web services abuse users by demanding all sorts of personal information, much of it completely unrelated to buying the service. They then turn around and sell your name and information to other people to spam and telemarket you to no end. These sites even brashly claim that your data is safe and that they have privacy rules and policies. Here the HCI brat is the very small print and the checkmark you will overlook that permits them to share your information with other companies with whom they have a relationship (even though that relationship only exists to sell your personal information!).


User experience as a field has a long way to go. Our bratty products do us little credit. Thank goodness we're not all brats.... There are certainly things to rave about as well!—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.

04 June 2007

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.