Kevin Cheng  

Sure, We Listen

June 18th, 2004 by Kevin Cheng :: see related comic

I was sitting in a meeting with my program manager and a few developers. The meeting was a routine triage to go through the issues database, discuss progress and assign new issues. An HCI issue comes up and the match begins. Ding Ding! I give the first blow by providing an informed opinion and decision on the matter. Bam! The PM disagrees with me based on, so far as I could tell, personal bias. Pow! I deliver what I believe to be the knockout blow with user research data. Whack! What’s this? The PM is back up and he’s called in reinforcements. He calls another usability person in our team and asks for her opinion. Whap! Only to find she supports the decision and delivers the knockout. The PM sulkily walks away, defeated at last.”Everyone’s a critic”

I don’t know who said it but it’s certainly true in this profession. Colour commentary aside, the experience I discussed really did happen. An element of “you had to be there” exists, but it was clear that he was fishing for somebody to agree with his personal view - user data be damned. While such an extreme case isn’t common, sometimes, I’m reminded of another quote from an unknown source (to paraphrase):

“I don’t go over to your bedroom and tell you what to do with your wife.”

When’s the last time a manager told their programmers what data structure to use to program their database? When you hire a lawyer or accountant, are you questioning their advice at every turn? When you hire an architect, do you question their structural decisions?

Obviously I’m taking a rather extreme viewpoint. Healthy criticism, especially from peers other experts, is encouraged and useful. While user data is powerful, I’m aware that they are not the only ones affected by a system in the bigger picture. Other stakeholders need to sign off on the product decisions. In addition, although I would like to think I am perfect, my opinions aren’t always correct.

Nevertheless, designing on a manager’s instinct and preference for pink isn’t usability. Organizations need to put some faith in their usability engineers and interaction designers. A lot of money and lip service is being paid to these disciplines, signifying recognition at some level but within organizations, many people are simply trying to check off a box on their checklist rather than use the information and skills provided to them. Doing so is a waste of money and time - not only for the organization paying the bills but for the usability people, too.

It’s kind of like paying to research the environmental effects of carbon dioxide emissions and then disregarding the results. Hang on …

20 Responses to “Sure, We Listen”
Andrei Sedelnikov wrote:

“Everyone’s a critic”

Yea, you’re right. Everyone is going to have his own opinion concerning the user interface issues. And I think I know, why: Because it’s visible. You never see which data structures developers create, you never see which business lunches your PM is making, but result of your work is available to everyone.

The same thing is true for the “visual designers”, too. But they are usually treated as “artists”, so it looks like they do not have to prove their opinion with research data.

Steve Nelson wrote:

You brought up an interesting analogy with: “When you hire an architect, do you question their structural decisions?”.

Isn’t deciding that swinging a door to the left vs right more in tuned with HCI decisions than deciding you need a 12″ header above the door that’s in a load bearing wall?

I know you’re just using analogy and it proves nothing, but deep down do you consider HCI to be on the same level as structural engineering a building?

Jay Zipursky wrote:

Isn’t deciding that swinging a door to the left vs right more in tuned with HCI decisions than deciding you need a 12″ header above the door that’s in a load bearing wall?

The difference in that case is that if I hired the architect, I’m probably the user of that design.

To keep the analogies clear, it’s as if the project manager you’ve hired to manage your house’s construction is arguing with the architect over which way the door should swing.

Bottom line: Ask the users. (No, not necessarily directly… that’s what usability tests and all our other techniques, including informed opinion, are for.)

I do agree with the gist of Kevin’s article. It’s frustrating but, at the same time, these types of discussions can highlight problematic portions of an interface that may be missed.

Andre R. wrote:

Its true in HCI, but its true as hell in visual design. In that case, even the guy grabbin’ the garbage in the company has as strong an opinion as the CEO!!!

Nice one, keep it up!

Dermo wrote:

Dropdown or radio buttons, hmm now there’s a Hobson choice - both being completely ineffective for the job (30 items) in context.

Saying that, in my roughly (and some times very rough) 10 years experience, the programmers generally have the best understanding of any one group of how to design an interface - perhaps they are used to thinking in terms of efficiency etc.

In the research I am now doing I’ve discovered that in audio libraries users are constantly looking for more complex interactions than what is available and that researchers have fouond that with a small amount of experience, users are able to perform complex searches over multiple modalities. But why do these interfaces not exist?? They ask users what they prefer after 5 minutes playing around - what kind of test is that? Of course they pick the one suitable for retards and HCI fails to develop. That is why a manager is probably better off trusting the instinct of a good developer rather than the witchdoctery of a usability ‘expert’

Jay Zipursky wrote:

They ask users what they prefer after 5 minutes playing around - what kind of test is that?

I think you’ve found the weakness of many usability tests: over-emphasis on novice or first-time users. However, for release 1.0 of a product, I think it’s hard to test for usability issues that will crop up after hours and months of usage. (If someone knows how to do this, I want to hear about it!)

IMO, you have to look at usability in the context of the product’s lifecycle. If you think some complex search mechanism will really benefit users, then leave it in. Then do studies of version 1.0 in the field with experienced users so you can learn what’s limiting users today and put improvements into 2.0.

Kevin Cheng wrote:

Dermo, given that I personally know you’re a trained usability person, I have to assume that you’re stating your position to play devil’s advocate so let’s play.

First, I have a pretty clear stance on what I think of developers making UI choices. Bottom line: they’re so far removed from being users that having them make design decisions is downright silly. How many MS Word users do you think understand Big-O notation?

Secondly, while you bring up an valid point about usability testing, it’s not always the case. I’ve performed tests on multiple occasions specifically geared towards users who have been using a similar or earlier version of a system for a year or more. How else do you ensure that your changes are an improvement over the existing process, afterall?

Further, there are different tools for different scenarios. GOMS is a great model but only truly useful for predicting changes to a system involving experienced users. You wouldn’t use GOMS for first time users (or retards).

Dermo wrote:

Kevin, you can’t blow the whistle on me when I’m having a bit of fun! I think a good example of a reliance on user testing is mobile phone menus. Over the years I switched from Ericsson to Nokia as I preferred the Nokia menus. However, the menus on Nokia change with every new phone I get(iteration). The differences between each model and competitor models indicates to me that they don’t know what is the best way to design a phone menu. I would suggest they are looking in the wrong place to begin with, and probably making changes based on customer feedback resulting in every phone being different. If more standard CS was put in place then there would be more menu systems based on efficiency and they should be more similar to each other. For example, most TV remote controls in western countries have the channel numbers running from 1 to 9, top-to-bottom; left-to-right because it is sensible and easily understood. Hence, they all look more or less the same.(Except for B&O, but lets not go there!)

Tobias wrote:

Hey! I like the layout on my B&O remote. And it is similar to my calculator and my keyboard.
(Ups - sorry for going there)

Lana K. Moore wrote:

Once upon a time about 9 years ago (that’s 63 years in HCI years) I had a PM insist that the best usability for a health care phone messaging application was to have a big red flashing link in the upper right hand corner of the page.


Since then, education and visibily into the world of HCI and usability for PMs became essential in 1) gaining the respect of your PMs, developers and other stakeholders within an organization and 2) allowing user data to speak for itself.

In time, user testing with prototypes and iterations on the visual interface before a single line of code is written gives all teams insight to the “why” a design decision is made. It is beneficial in that it exhibits that even the HCI professional’s opinion is removed from the equation. It is the HCI professional’s experience, especially *with* user data, that enhances the user experience.

Education may take many forms. These may include:

1) A summary of results from user testing of a prototype including usability metrics. An example of the simplicity of a result could be, “At first, users spent an average of 5 minutes completing this task. The most recent iteration finds users completing this task in under 2 minutes.”

2) Simple, but short presentations on HCI and/or Interaction Design principles and fundamentals. For example, Fitt’s law is often misinterpreted. Explain how your product either meets or disregards Fitt’s law. It’s easier to start with fun things like how your product meets a principle. Talk about the good stuff first and wiggle your way into the “needing help” department in subsequent short presentations.

3) Name and phrase dropping. Yes, everyone hates a name.. or phrase dropper. But this *can* be done in such a way that it does not come off as pompous or arrogant. In conversation, drop a phrase.. like learnability. Whiteboard that phrase, jot down some key points about learnability and ask the person with whom you are speaking how *they* could meet the objectives of your point. Ask questions and guide them…lead the horse to the water.

While the rate of adoption will differ from organization to organization, you’ll begin to notice a change. Critism will blossom into directed questions as to how to make the interface better instead of personal opinions. The lack of respect will subside. And user data will have more meaning.

Dey Alexander wrote:

There must be a Dermo (a real one, not just one playing devil’s advocate) in every organisation. We’ve got one, and he surfaced in a very similar manner - over the choice between a large set of checkboxes, versus dropdowns.

Anonymous wrote:

When’s the last time a manager told their programmers what data structure to use to program their database?

Well, they tell us “must be written in [insert programming language here]”, or “must use [insert latest buzzword here]”, or…

Nathan Egge wrote:

Haha, I wonder if I’m the only one who got the reference in that mug. Good job kev.

Kayla C. wrote:

Oh, the UI shoppers! I remember these guys.

Story: I was the hypothetical PM (note: never work in a company where the org chart has cycles in it), and the war was with one of the developers over whether it was okay for one level of a tree control to have insert-after drag&drop behavior and another to have insert-before. We, of course, were the ones saying no. After calling in every single employee we had, he eventually found one willing to answer his leading questions ‘correctly’ and left it. The documentation - while accurate - remained carefully ambiguous to the end, showing a polite if stilted face to outsiders while internally it was a perfectly executed bit of black humor.

Kevin Cheng wrote:

Well, they tell us “must be written in [insert programming language here]”, or “must use [insert latest buzzword here]”, or…

Touche. I guess that’s why Dilbert exists though isn’t it? No doubt programmers get their fair share (if not more) inexplicable interactions with management and marketing but as one reader has mentioned, things you can see (the UI) get much more unsolicited feedback than the design of a backend.

never work in a company where the org chart has cycles in it

… I’m trying to understand how any organization could come up with this … and failing.

Bob Salmon wrote:
never work in a company where the org chart has cycles in it

… I’m trying to understand how any organization could come up with this … and failing.

Kayla C. was obviously working for M.C. Escher and Sons Ltd. An occupational hazard was the pointer reaching out from the screen and moving the mouse.

Steve wrote:

I’m a documentation manager with a lot of HCI /Usability experience. I have this theory that if a software program is difficult to use it will be difficult to document. Conversely if a product is easy to use it will be easy to document. So it is in my interest to channel usability requests and suggestions back into the product.

However, I find that I spend more time forging alliances and developing relationships with development personel with a view to improving the usability of the product than I do documenting the product.

All too often developers are being pushed by the misguided instructions from managers/business heads.

My saving grace is that should Development decide to ignore logical, evidence supported usability suggestions, then the results of their decision receive prominent exposure in the user documentation. . .

Nothing wrong with a littl name and shame every now and again . . .


Kayla C. wrote:

> M.C. Escher and Sons

Good one, I’ll have to use that.

It was a small company. The owner had a primadonna coder he practically worshipped. Of course egotistical coders don’t run twelve-person projects very effectively, so various other people cycled through that job - being officially PM, and unofficially project babysitter / primadonna whim-monitor. Knowing the politics from the start, I survived a record six months at the job before ’successfully’ finishing the project, saving the boss from losing his house. Then we started on plans to actually finish the project, however, it was not to be. Where I saw the most gelled team I’ve ever had the pleasure of working on, they saw a threat. I resigned almost immediately, having no interest in taking the blame for things I had no control over, or working for idiots who wanted me to be incompetent.

Good news, I’m again working with two members of that team, including one whose unique contribution was the willingness to grovel obsequiously toward people much less competent than he. (I wear many hats, but not that one.) Bad news, that skill is still quite handy here.

Anyhow - nothing unusual about the phenomenon, sadly, just my terminology. An actual circular org chart was drawn by one of the other members of the project team his second day there, and the idea stuck, as did many others from those days. It’s amazing what a seventeen hour work day will burn into your brain.

That anonymous fella again wrote:

Kevin, I wasn’t trying to be funny, just point out that developers get the same kind of crap that you do. Heck, sometimes about the same things, for those of us doing UI development.

I’ve only once worked with a professional UI designer, and I must say it makes a huge difference (heh! he was the one that got into all the “discussions” about lists vs. radio buttons :-) . I am no more able to design a good UI than he was able to develop it, but between us we got something good put together.

Johan wrote:

Recursive position, apply within…

Back a long time ago [pre 1984] I worked at Apple. Not as large a company as now, but not small either. A Mr. S. Jobs was then Chairman of the Board and also head of the Macintosh division. This had some amazingly bizzare ramifications (I worked at the time in the Lisa division… soon to be combined with the Macintosh division minus about 200 engineers formerly comprising the Lisa division).

Yep… stay away from recursive org charts. People using two hats sometimes forget which one they should be wearing.

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) ?