When Should You Change UI Copy?

Have you ever worked on a product that has poor UI copy or design? Of course. What about poor UI copy or design that’s been around a long time and is now the standard way of doing things for that product?

When do we force the issue and change it?

For professional reasons, I can’t share the exact thing I saw recently. But here’s a similar imaginary example:

There’s a screen giving you information about a pen. On the screen, next to the type of ink the pen uses, is a button with a question mark symbol.

Something like this:

I thought I should click the ? button to get help about which ink to choose.

But actually, when I click the ? button, I get a long list of different inks. The ? button is for switching inks, not for learning more about them. The same button is used throughout the program for lists of all kinds of things.

I think this situation is… not ideal. (Excuse me while I take ten deep breaths…)

So I should change it, right?

The problem is that this software is used by hardcore techies. They LIVE in this software. They’re used to the ? button meaning “show a list of this type of thing.”

So changing it would screw them up fairly well.

It’s a smaller version of QWERTY vs. DVORAK keyboards. The better solution would cause too much headache, so new generations of keyboard (or software) customers learn the worse method.

Is there an industry standard here? A best practice? Some data to help me make a decision? I guess I’m looking for something like:

If we assume that you’ll acquire X new customers over the next Y years, divided by your current users, times a variable representing how much anyone cares, etc.

And at the end, I get something that says, “most experts agree that in your case, you shouldn’t bother changing. Or you should. Or it’s a gray area.”

Does anyone have any thoughts about this?

2 Responses to “When Should You Change UI Copy?”

  1. November 16, 2011 at 5:30 am #

    Depending on the real-life usability problem you’re referring to here (is it really one for the _users_?!), location and motor memory may help you improve the design.

    To use your Ink Type example, you could replace the label-plus-“?”-button combo with the platform-native widget for a popup menu.

    This could reduce the “shock of change” for your users, as long as:

    * it’s in the exact same location,
    * looks reasonably similar in shape, size, and organization (in this case, selection label on the left and button on the right), and
    * works similar to the existing design.

    Then again, as you write, the question mark button has been established as the widget for opening a list _across the entire system_, so it’s consistent within this context.

    Hence, this may very well be one of those cases where you shouldn’t try to fix it, ’cause it ain’t broken for the _users_ of this software. Much as it hurts whenever _you_ see it รขโ‚ฌยฆ ๐Ÿ™‚

    P.S.: As for that top image: don’t label buttons YES or NO, but always use action verbs. Fixes most dialog box problems in a heartbeat. ๐Ÿ˜‰

    • November 16, 2011 at 3:13 pm #

      Thanks for your comment; you’ve given me food for thought! I’m not worried about the current users, but about new ones. The learning curve is already high for this product, and anything I can do to plane it down would be good.

Leave a Reply