Interfaces need editors

by Joshua Porter  |   8 Comments  |  shortlink: http://bokardo.com/p/693

Jason Fried on editing interfaces. He says:

“What matters is the editing. Software needs an editor like a writer needs an editor or a museum needs a curator. Someone with a critical eye and the ability to say “No, that doesn’t belong” or “There’s a better way to say this.” Physical constraints create natural limits for books and museums. Books have pages and museums have wall space. Software, on the other hand, is virtual, boundless.”

I completely agree with Jason on this. You need someone pushing back as much as you need someone pushing forward. You need, not necessarily a critical eye, but a concerned eye that isn’t colored with the effort of creation. A creator is almost never equipped to be objective about their creation. (nor should they be)

When I create interfaces for clients, I ask for feedback on everything. I want to be edited, I want that push-back because it makes the design better, which is the only goal. (but, of course, it makes me better too). It’s amazing how many times we end up scratching something that was in the original interface because we realized that it’s just not providing core value.

Without an editing step, you don’t get to the point where you ask “is this really necessary?”. You never get to “but is this providing core value that we can’t live without?”. In addition, without an editing phase you improve much, much slower. Without editing you start drinking your own kool-aid.

Also, another point. The editing phase isn’t as much about the look and feel as it is about message. Editing is mostly about clarity and making the interface concise. It’s a lot of copy-writing, and only a little rounding corners.

Here’s a great bit from On Writing Well. It nicely sums up the act of editing/rewriting/interface design:

Rewriting is the essence of writing well: it’s where the game is won or lost. The idea is hard to accept. We all have an emotional equity in our first draft; we can’t believe that it wasn’t born perfect. But the odds are close to 100% that it wasn’t. Most writers don’t initially say what they want to say, or say it as well as they could. The newly hatched sentence almost always has something wrong with it. It’s not clear. It’s not logical. It’s verbose. It’s klunky. It’s pretentious. It’s boring. It’s full of clutter. It’s full of clichés. It lacks rhythm. It can be read in several different ways. it doesn’t lead out of the previous sentence. It doesn’t…The point is that clear writing is the result of a lot of tinkering.

Check out my latest project: Make them Care!, a book on designing great sign-up experiences. Get reminded when it's published.

Links to this Post

Comments

1.  Todd Kalhar 7:30pm, Wed 10th, 2007

Great catch, Joshua! Cooper uses a collaborative process for their projects that involves an interaction designer (IxD) and design communicator (DC). By having both people present, they can play off of the strengths of each, plus act as editors of the final product.

In my current work, it’s frustrating how often a product manager wants a finished solution rather than a collaborative effort toward something great. Without that collaboration/editing/review, the result is never quite as good. I never claim to be infallible and I learn more from constructive criticism and feedback than I do from blind acceptance.

Two heads are better than one!

2.  Gordon 11:34am, Thu 11th, 2007

I’m a technical writer and have pushed hard to get involved with interface design. As well as the basic English, it’s surprising how many developers struggle to think in terms of ‘task’ rather than functionality.

I have, previously, been allowed to edit the interface itself, something the dev guys welcomed as it saved THEM from having to do it, and made my job (documenting the software) MUCH easier.

3.  Michael Chui 5:00am, Thu 18th, 2007

I read this and thought he was talking about code. And now, realizing my error, I think you should have it with code, too. But it’d be expensive…