Kevin Cheng  

First Things First

December 5th, 2003 by Kevin Cheng :: see related comic

It’s been awhile since we’ve included our manager but there’s so much ammunition when it comes to misinformed management and HCI.

Sadly, the scenario we’re talking about this week isn’t too far from the truth. It’s very easy for both customer and management to lean towards adding more features over usability enhancements. Although one could spin a usability enhancement as a feature, too often, it’s regarded as “fluff” or “gold-plating”. Why does this happen and how do we combat it?Cost Justification
Let’s look at an example: if you’re building a car and you have a set budget, you need to choose where to spend that money. Even the most basic economics teaches us about opportunity cost: the cost of something is not only what you spend but also what you could have spent that money on instead. Do you choose to the new automatic gear shifting functionality or the more readable and usable dashboard display?

The problem here lies in marginal gain. If the car already has an acceptable dashboard display, perhaps the money is better spent on the gear shifter. If, on the other hand, the car’s dashboard is confusing and crowded and requires a great deal of cognitive processing to interpret, the money may be better spent on improving that display.

Prove you have more marginal gain than the other features and you’ll have a much easier time of it. Some of these can be done through simple user timings and cost savings; others will require more soft techniques of persuasion.

Consider the Project
Speaking of persuasion, the most effective persuasion technique is in having a discussion, rather than a debate. HCI and usability are often overlooked and ignored for the wrong reasons but quite often, we get so used to fighting the good fight that we forget the bigger picture.

Before launching a full assault to promote your usability issues and fixes, look at what other items are on the table. A usable dashboard is really important to a car but so is having an engine that works. If the schedule only allows for one, what then? As much as we want the most usable system we can design, the ability to compromise is actually a very important skill to have. Working within constraints is part of our job. Creatively solving the problems within these constraints and taking the other factors in the project into consideration are keys to not only a usable project, but a successful one overall.

Choosing Your Battles
Similarly, not all battles are worth fighting. This point may sound obvious but it’s not worth trying to get every usability enhancement in. The development process, whether in software or otherwise, is a game of give and take. Listen to others needs, determine what’s important to them, and choose your battles accordingly. This approach not only ensures you get what’s really important to you (and your users) implemented but also keeps everyone on the same side instead of being each other’s antagonists.

(Not) Invented Here
Human nature dictates that you’re more likely to prefer your own ideas over others. I’ve had several experiences where I managed to get certain points across through a fairly circular route. With one client, a colleague and I proposed an idea which we felt was the correct solution based on user data. After much debate and user data thrown around, we were no closer to convincing them. Then we stepped back and evaluated their proposed solution, focusing on their goals and reasons behind their design. As we progressed, over the course of three weeks, they eventually morphed into a different design which matched our original proposal exactly. We never pointed that out, of course.

Sound Off
There are many other approaches and tips related to HCI prioritizations. Feel free to drop off some experiences you’ve had either on poor management or ways you’ve creatively solved them.

10 Responses to “First Things First”
Bob Salmon wrote:

One of the problems with getting HCI features into a product’s release is the separation of budgets. The product development budget is the only budget the product development manager worries about. If this included the support budget, the documentation budget etc. then money would talk in HCI’s favour a bit more. (Caution: including training is a bad idea - training is often a nett generator of money, and (possibly) the worse the software is, the more training people will need…)

I suppose if the major splits in an organisation were by product rather than by function (i.e. first by product X vs. product Y, then within that by development, support, training etc.) then you’d have a better chance.

Included in all this is professional services - if it’s easy for them to customise it on behalf of the customer then it’s possibly easier to make bigger profits.

Wundt wrote:

This comic cut so close to home it hurts.

If you can find the time and money, the best solution to this is usability testing, if you can get the managers and developers in the room to watch. If you can, you are almost always rewarded when they realize that many of the problems you brought up REALY ARE problems for users. In one personal example, one powerful manager on a project vetoed a behavior I insisted on, but had to sheepishly admit we needed it after every participant in the test complained. It was VERY gratifying.

Paul Reinheimer wrote:

My story doesn’t have a happy ending.

I will continue your car analogy if I may, with John the Mechanic, and Bob the car designer.

John: The car is really good, but if we could just move the steering wheel somewhere convient, add seats, and include a manual rather than inscribing it in the wheel well, we would be set.
Bob:… Hmm, yeah, its on the list.
..Two Months Later…
John: The car is even better! But if we could just move the steering wheel somewhere convient, add seats, and include a manual rather than inscribing it in the wheel well, we would be set.
Bob:… Hmm, yeah, its on the list.
..Rinse and repeat for a year..
Bob: Why doesn’t anyone drive our car anymore?
John: Well, they started driving another brand of car, it isnt quite as powerfull, but it has seats, a usefull stearing wheel, and a small manual.
Bob: Oh. I see
John:… Well, are you going to add seats, move the stearing wheel and include the manual I wrote last year?
Bob: Yeah, that stuff is on the list. I will get to it.
Bob Returns to tweaking fuel injection system.
John Cries…

Yeah, I’m john, and %90 of what was our customer base is now using another software package. So rather than using our old method of giving away the software with an ad banner, there is crappy third party installs, to make up the revenue difference, which in turns, pushes more users away. Oh joy

Arthur Law wrote:

Yeah, I’d definitely have to agree with Kevin on this one. Fighting the good fight, while it may be gratifying to win one debate, ultimately sets you up for the same fight each release ad nauseum. Working together is usually better but not always plausible. At the large and heavily bureaucratic organization I worked at, it sometimes worked out to skip over the official issue list and have a little chat with individual developers.

Jimmy Wan wrote:

You’re leaving out the single most important reason why it is easy to overlook usability. It’s not a problem until after the product has already been sold. In most cases, usability does not become a problem until you have real users that are using your product. In many situations, the initial product evaluation does not happen until several competitors are brought together and compared against a feature checklist. Sometimes, before actually using a product, there are a set of features that are designated as “required”, even if they aren’t useful. If your product can’t get past this stage of evaluation, it doesn’t matter how usable it is…

Marian Steinbach wrote:

Regarding Usability as a Feature

The problem about usablity starts when business regards it as an add-on. Using Kevin’s car metaphor: When car manufacturers provide a usable part as a costly replacement for a standard part, something is screwed. This is very much different from providing an automatic gear as a replacement for a manual gear.

The same goes for software development, I would argue. As long as companies (not only managers!) understand “be usable” as an option, things won’t work out in favor of usability. And “plugging in” usability into a piece of software usually doesn’t work, as usability aspects effect nearly every part of software. This is why usability must be thought of from the very beginning of the product development process (that is long before the first line of code is written, as people here know already).

Alhtough, if I’m wrong and adding usability on top of unusable software, I would like somebody to point me to the Microsoft Word Usability Plug-In. ;-)

Daniel Harvey wrote:

I’ve worked both as a quality assurance manager and as an interaction designer so I can laugh and cry at this weeks cartoon from multiple perspectives.

It is far easier to get your fixes in if you refrain from simply throwing your work over the wall, handing it on to the next discipline in the production cycle, etc. Too often interaction designers will simply abandon a project once they’re done drafting wireframes or once they’ve worked with a visual designer. Too often programming and quality assurance resources aren’t brought to bare early enough. It is infinitely easier to have a conversation, to be persuasive, if people are actually functioning as a team rather than a disparate group of individuals.

Chris Law wrote:

Hmm… as a product manager this one hits a close to home for me.

The best way to convince me to spend resource on HCI is to set up a clear measurable objective that has good business benefit.

Many times the enhancements requests that I’m given ARE gold plating or they’re not presented in a way that makes it clear why I should put them into my requirements doc.

Bad way to convince me:
Our installation sequence sucks and we really need to create a better one.

Good way to convince me:
Our current install rate is 50% and I think that by streamlining the processs that we can get it up to 75% which would mean that 2M more users will have access to the product.

ian ward wrote:

One scenario that leads well intentioned managers down this path is classifying usability requirements as features instead of constraints. The problem is compounded when usability professionals or interaction designers also use the phrase without understanding its impact (as i saw in a couple responses in this discussion). Since features can be de-scoped depending on any number of factors during a release cycle, usability features are easy targets for culling. Usability requirements are actually constraints within which the functional requirements must be implemented. If the functional requirements are the “what”, usability requirements are the “how”. They are not to be discounted any less than performance constraints (often closely related), or security constraints.

Part of our jobs is to understand the vocabulary of our users, but some of us often fail to make the same effort to understand the semantics of the development processes we must influence. We rant that managers and developers don’t understand us, but I see peers contributing or even causing the problems themselves in this way.

Additionally, I think that incomplete specifications are more often to blame than not. It is extremely difficult and time consuming to specify every detail of an interaction design, and designers are unfortunately expected to often ramp up on the a project at the same time as developers and make our primary contributions before they begin implementation. I have often made assumptions about how my designs will be interpreted, or even the developers’ level of familiarity with any UI design guidelines, much less the one specific to the platform we are delivering on. In these cases, we are the victims of the schedule, but no less responsible for the misinterpretations.

One strategy to address this scheduling syndrome is to preface your requirements with the design guidelines of the platform you are designing for and present your spec as the “detailed” requirements including exceptions to convention. The sooner you can do this, the better.

Another strategy that can leverage the current move toward web services and markup-based UIs (XAML/Avalon) is to suggest that the development team begin by delivering XML data feeds which can later be augmented and married to UI designs. This gives us a little time that we wouldn’t typically have in a typical development cycle to deliver a more refined UI spec, and generate credibility with your dev team

Influencing staffing and scheduling of projects is the best way to confront this and helps to at least shake out the perspective of management so you can start your fight earlier rather than later, but honestly this is a level of control that few of us have.

Peter Centgraf wrote:

Addressing Chris’s comments back a step, I think he exposes a critical chicken-and-egg problem with HCI requirements. Most often, scheduling and prioritizing gets done after a very short investigation period with limited resources. Given these limitations, the best results a well-equipped HCI professional can muster will be discount evaluations: recommendations based on guidelines or heuristics, some simple task analysis, and paper prototyping with a few users (if you’re lucky). An extremely lucky HCI pro might have access to some previous marketing research (for a commercial product), and that marketing data might vaguely address an actual usage scenario or problem. It is highly unusual for an HCI team to have enough access to users to be able to make honest and responsible a priori sensitivity analyses.

There is a more important point: even with infinite resources, however, it would still be impossible to produce the kinds of quantitative predictions that managers seem to expect.

Let’s look at your own example in more detail. Suppose that I, as a designated HCI analyst on this project, identify several problems with the install process using discount methods. Because of my software development background, I know that several options are available to improve the situation, but I am not intimately familiar with the implementation details of this project. In order to determine how much improvement can be expected over the status quo, I need access to developers with strong knowledge of the project — the developers most critical for the implementation of the rest of the project. In order to determine the scope and importance of the problems, I need non-trivial access to users and sufficient time to work with them. Where do those resources come from, if not from early allocations during goal-setting meetings? If I were to quote you a statistic in those meetings like you suggest, I hope you would be wise enough to disbelieve it.

I agree that HCI recommendations need to be grounded in the other requirements of the project (e.g. technical, business, aesthetic), but some part of the solution has to come from the management side. There is only so much that can be done with limited resources, and ultimately the decision will have to rely on trusting the judgment of the HCI pro, just as technical prioritization and scheduling relies on the judgment of technical domain experts.

Leave a Reply

OK/Cancel is a comic strip collaboration co-written and co-illustrated by Kevin Cheng and Tom Chi. Our subject matter focuses on interfaces, good and bad and the people behind the industry of building interfaces - usability specialists, interaction designers, human-computer interaction (HCI) experts, industrial designers, etc. (Who Links Here) ?