Design Principles: What You’re Not Going To Do

Jared Spool

June 16th, 2011

“Innovation isn’t about saying YES to 100 ideas. It’s about saying NO to 1000 ideas.” – Steve Jobs

As we study how teams can best use design principles, we’ve discovered that project specific principles are far more useful than generic overarching principles, which many teams develop. Take Facebook’s published principles, which include generic phrases like clean, human, and universal. Good thing to strive for, for sure.

But how do these principles help the design team? How does a team decide if a design idea is human enough? And if they aren’t for the design team, who are they for?

What we’ve realized is good principles don’t tell the design team what to do. They tell the team what not to do.

A good principle clearly draws a line in the sand, telling you exactly why the majority of ideas you’re looking at won’t cut it. It helps you say, “This isn’t quite there, let’s try again.”

One team we’ve worked with recently was working on a point of sale system for appointment-based businesses. Several operations, such as rescheduling appointments, took time. Watching the receptionists during a rescheduling, the team realized that they had a problem. If another customer called or tried to check out, the receptionist had to make the second customer wait until the rescheduling was done.

The team realized, for their redesign of this functionality, they needed to follow a principle of “Allow for multitasking to handle interruptions.” It’s a simple principle, generated completely from the problems the team saw in their field observations.

What’s beautiful about this principle is it helps the team say NO to ideas. Any design proposal that can’t easily be interrupted for a new appointment or to check a customer out is immediately out of the game.

Sometimes, it might only take a few tweaks to go from “not meeting the principle” to “meets and exceeds.” And that’s perfect — the principle is doing its job of guiding the team to a better design solution.

Years ago, we found when you gave a team of designers a specific problem to solve, they had no trouble coming up with solutions. Solutions are the easy part. Understanding the real problem is the hard part.

An actionable, research-based set of design principles helps a team define and understand the problem. That gives them the power to come up with solutions that really work for the users.

2 Responses to “Design Principles: What You’re Not Going To Do”

  1. Christopher Fahey Says:

    We do this in a very specific way sometimes. I call it the “do not want” list.

    I’ve always found it interesting how much a good design brief resembles a good business contract, specifically a Statement of Work. Good SOWs spell out clearly what *must* be done and what *should* be done, but the best ones seem to always also articulate what *wont* be done: We’re not building this in Flash. We’re not taking any photos. We’re not responsible for moderating the user generated content. This list is, of course, infinite, but it helps to sit down and think of all the ways expectations might take the project team down a costly wrong path, or even a costly but correct path, and enumerate them now. When the client later asks you to do these things, you can rightly point out that it wasn’t in the contract and that it will require some renegotiation.

    Likewise, in a design brief, you might want to say up front certain things that will pre-emptively shut down a lot of potential bad directions the designer(s) might find themselves exploring: We will not crowd the site full of features. We will not try to become a whole new social network. We will not use skeuomorphic design. The site must not look like Facebook.

    Rules are meant to be broken, and many are eventually broken for good reason, but if design is a game good rules help make the game more fun and rewarding.

    Just say no.

  2. StartupDigest Design – June 24, 2011 Says:

    [...] Design Principles You’re Not Going To Do By Jared Spool, User Interface Engineering [...]

Add a Comment