A reflective conversation with a situation
My favorite way to think about the work of a designer.
For as long as I can remember I’ve wanted to craft a sturdy set of design principles. To make design less “magic” to outsiders. To help designers stay focused on what matters. To further legitimize a chronically overlooked source of value.
My favorite effort was Nelson Joyce and I collaborating with Josh Porter to write these:
I love them. They hold up beautifully. Even a decade later.
Although…
Something feels incomplete. Like the job isn’t done. There’s more to do.
But what?
I later found a masterpiece of a design book by Scott Berkun. How Design Makes the World is full of design wisdom, but no hint of design principles. I wonder if he knows something I don’t…
Maybe they’re a lost cause?
Although, Scott has a few fantastic questions. Questions that guide the designer process. Design process principles in the form of questions.
As designers, we should be continually unraveling, untangling, and attempting to answering these questions as coherently and concisely as possible:
- What are you trying to improve?
- Who are you trying to improve it for?
- How will you ensure you are successful?
- Who might be hurt by your work, now or in the future?
Something feels better about framing the work of a designer this way. Less following principles, more asking questions.
After wrestling with process and principles for a while I noticed many of the principles from Josh’s list were subcategories of Scott’s questions.
For example:
What are you trying to improve?
- Look for investment
- Model features on real artifacts
- Actual vs desired use
Who are you trying to improve it for?
- Know who your real competitors are
- Personal value precedes social value
- Users are not product designers
The rest of the principles that didn’t fit under Scott’s questions were more tactical — about executing the work.
They had a theme, though…
- Fit and finish matter
- Release quality sets expectations
- The last 10% is the hardest
- Conserve attention at all costs
- Direct manipulation is best
- One primary action per screen
- Consistency matters
- Great design is invisible
- and several more…
I see simplicity and quality driving these principles. They’re wonderful sentiments. Although, I’m not sure how useful categorizing these principles are to me or anyone else.
Fast forward a while and I bump into a critique of SOLID object-oriented programming principles by Daniel Terhorst-North. I’m no programmer, but a few of them I trust think highly of the author. Plus, I love a good critique of long standing and respected principles — they’re 20 years old!
Daniel does a great job decomposing the SOLID principles into “write simple code” over and over again.
You have to be good at writing code. You have to know how the software is intended to behave. Oh, and the code needs to reveal all that to the reader.
That is...
Hard.
At one point he says, “You can only reason about something if it fits in your head. Conversely, if something doesn’t fit in your head, you can’t reason about it.”
My brain couldn’t help but jump to a similar design conclusion.
That’s what needs to happen for a person using software. They have to be able to “reason about” what they’re trying to do with the software. They need to be able to imagine a use for the software that fits with a frustration they have in their mind. They need to be able to imagine this software helping them make progress in that situation.
That’s not possible with overly complex interfaces. It can't all fit in their head.
The software needs to be able to maintain a coherent story at all levels. From when I’m contemplating the work at large to when I’m executing the task at hand. It all needs to be easy to hold in my head.
A “simple interface” from this perspective carries a lot of weight. It’s not only simple in interface elements, language, and aesthetics. It’s simple across different stories at different levels of abstraction.
That is...
Hard.
The suggestion to “make simple interfaces” can be laughed away as overly simplistic. Or, it could be an idealized standard that’s impossible to achieve. It all depends on your interpretation.
For now, I’m scratching “make simple interfaces” onto a sticky note, attaching it to my monitor, and using it as a constant reminder to be simple in story. From the element I’m interacting with right now to the guiding purpose of the entire product. You can’t do one without the other.
That’s my only design principle.
Oh, and don’t forget! Ask a lot of questions.