A “design dictator” is someone who has the authority to make design decisions and does so constantly and without fear, never ever works in a design-by-committee situation, and who’s wrong decisions may only ever be measured after a product’s release. A dictator asserts that he knows best and that the rest of the company should listen.

This sounds like it could be a horrible idea. And yes, it certainly can be. That said:

A good dictator is one who is actually right. One who makes good decisions and consistently puts out good work and produces positive results.

A design dictator can work extremely well without the so-called benefits of user research, and can succeed in an environment where User-Centered Design methods simply don’t work, due to a lack of time, resources, etc. He can run purely on instinct most of the time, and be right most of the time.

This is true, though, only when a system of support is in place. No, dictators don’t normally have systems of support - usually they’re systems of sheer control - but in the commercial software world, they definitely must. As long as a dictator is supported by people who question his decisions and make sure everything has been thought out, the company is fairly well safe-guarded against absolute failure while still enabling risks to be taken in the effort to become great. If the designer is made to justify his decisions, his designs improve. It makes him think things out more thoroughly in the first place.

Is this what Apple does with its team of top-notch “iDesigners” (my term, not theirs)? Is the how the iPhone came to be? Is this why Apple can so frequently put out innovative products that send fans into a frenzy? I have no idea.

But I know that this system can work in any company, anywhere in the world. All you need is to take one good, level-headed and smart designer, surround her with people who can competently question her decisions, and give her the power she needs to make them.

Do not ever force him to design by committee. Don’t ever ask a good designer to come to a consensus with a group of people less qualified than him to make design decisions. When this happens, people get dumber, and designs suffer.

If you’re the boss, let someone step up. People are well known to step up and kick ass when you give them ownership of something. A designer with ownership will surprise you. She’ll put out great stuff because she has to. She may not realize great design has been inside of her until this happens, but she’ll realize it.

At Apple, the team can question every decision Jonathan Ives makes, and financial failure is the ultimate risk. In most other companies, a dictator can be questioned by other team members as well, and the ultimate risk is simply being fired. No, being fired isn’t fun. But if you’re given the role of design dictator, odds are you won’t ever get fired unless you abuse your position.

If you’re the dictator, Be intelligent. Question your own decisions. Let others question you. Justify everything you do. You’ll do great.

OK and Cancel buttons are omnipresent on the web. Of course, they aren’t always labeled OK and Cancel and they don’t always have the same purpose, but we’ve seen them a million times nonetheless. The combination of the two buttons has maintained its position as a global standard for a very good reason: almost any action you perform in a web application can be canceled. This is seen often in round-trip interactions, in which the user starts an interaction on Page 1, completes it on Page 2, and is then returned to Page 1. It’s also seen in inline interactions, such as changing the title of a Backpack page.

Typically, the set of buttons is displayed as two side-by-side HTML buttons. This is true in many desktop applications as well. Sadly, this design has persisted for years and has found its way into millions of apps. See, the unfortunate side-effect of standards is that people often stop questioning them, and progress almost completely stops regardless of whether the standard is the best solution.

Here’s a typical OK/Cancel button set:

In this case, the object of the interaction is to create or edit a title and then either save or cancel it. Simple enough. So what’s the issue? Well, there are numerous ways to solve any given design problem, and even something as simple as this requires a few decisions.

The first decision to make is about the position of the buttons. It really doesn’t matter much in terms of usability whether the buttons are right-aligned or left-aligned to the field above it, but I generally stick to the left side for a few reasons. First, left-alignment keeps everything flush to the left edge, forming a nice, straight line from the top of the form to the bottom. Second - and this is simply an aesthetic choice - it seems to create a visual “end” to the form. As you complete each field, you move steadily downwards, and placing the action buttons at the tail end of it seems to anchor the form. But that’s just me. The most important reason will be explained in a moment.

The second decision to make is how to label the buttons. Sure, using the standard OK and Cancel requires less effort on a case-by-case basis, because you can simply label them without really thinking about it and move on, but are these terms really helpful? “OK” will work fine in a lot of cases, but more meaningful button labels can go a long way towards setting a user’s expectations about the result of clicking the button.

What does clicking OK do in this example? It probably saves the title. But elsewhere in the application, saving a setting might return the user to the page where he started the interaction, such as a Profile page. In that case, simply clicking OK doesn’t set a clear expectation. There, we should use something like, “Save and return to profile”. And since that’s true, we should maintain consistency and use meaningful button labels everywhere in the application.

On a more basic level, it’s simply more polite for us to set clear expectations regardless of what the user is doing. It makes things more understandable for them, and it makes us look good as a result. Do you need more reasons than that?

Despite all this long-winded logic, labeling the button in a meaningful way is really no big deal.

All we really need to do is change the label from OK to “Save title”. Rather painless.

The final thing to think about here is the thing that goes unchallenged by designers most frequently. It’s the fact that equal weight is often given to both buttons, the two of which trigger remarkably different results. I can understand why this started. Two options equates to two buttons. But this is not what we want to do. Instead of thinking about the number of options, think about the most likely option.

The most likely option for users who have decided to create or edit this title is to save the changes. The less likely option is to cancel the changes. But by giving both buttons equal amounts of visual importance, users have to actually read the labels - on both buttons - to decide which one to click.

Applying Fitts’ Law, which dictates that the time it takes to hit a target is a function of the distance to the target and the size of the target, the ideal solution is to take some of the focus away from the Cancel option by turning it into a text link.

(UPDATED: I changed the link color to black in this screenshot and removed the underline. Those who left comments here are right - a standard blue, underlined link stands out too much. Thanks for your contributions.)

This way, the “Save title” button is prominent and easier to hit with the mouse, while the Cancel link is less prominent and slightly less easy to hit with the mouse. Is it any more difficult to see both buttons? No. But it’s slightly more difficult now to click the wrong one. Your eye is drawn to the large button. And it’s easy to recognize, subconsciously, that the large button is the probably the one you want to click.

This, incidentally, is also why I prefer to keep the buttons left-aligned. It simply looks better to have that large HTML button aligned to the left edge of the field above it than it would to align the Cancel link to the right edge.

So why is it so important to keep the button on the left and the text link on the right? Because any user who uses the Tab key to move through form fields will reach the “Save title” button first, again putting focus on the most likely choice while simultaneously taking focus away from the less likely choice.

UPDATE: Jakob Nielsen has posted an Alertbox article called “Command links” that provides guidelines for when to use text links to trigger commands. His recommendations are very much in line with the example I’ve offered in this post. He recommends using command links for:

Designing the Obvious is on the list of Informit Editors’ Picks for Best Books of 2006.

Thanks for the kudos, InformIT!