Guiding Principles for Design
An attempt to articulate the ‘why’ behind how we design, and what should guide us
Over the past five or six years I’ve spent a lot of time thinking about, tinkering with, and teaching the process of designing and building digital products. My background with the web goes back a lot further (oh, hi Mosaic!), but the advent of Responsive Design made me think about it a lot more, and led to some evolutions in process that made for significant improvements in outcomes.
Last November I saw this excellent post from Peter Merholz titled 9 Principles for Superlative Design Teams (though his was targeted more specifically at in-house teams). That got me thinking about pulling these practices together in my own take on the subject, but one that is perhaps a bit more broadly focused. They are meant to help teams stay focused on the ‘why’ before the ‘how’ and to ensure clear understanding and communication of intent along the way for both team members and clients alike.
As I begin to work with the team at Isovera to build up our own design practice, it’s very important that we keep these principles front-and-center so we can keep our own process from initial strategy on through design and development as tightly coupled and choreographed as it should be—regardless of whether or not we undertake all the steps ourselves.
1) Language Matters. A lot.
We do not ‘defend’; we educate. Never ‘what do you think,’ but rather ‘does this accomplish the goals & meet the needs of your users.’ The words we use to describe the work are just as important as the work itself. If you can’t explain it, you’re not done designing it yet.
2) Understanding over assumption
Check assumptions at the door and keep asking ‘why.’ Uncovering bias is one of the hardest things to do, because often times it’s our own that get in the way. By probing deeper we get at the heart of the issue and can design and/or build the most effective solution, rather than accept the presumed answer.
3) Communicate clearly, succinctly and often
This is two-way: you must always look for more ways to engage & educate the client, and you should share every day with your team. This may sometimes require a sketch, a diagram, or a phone call. Don’t forget that sometimes a quick check-in will avoid hours of wasted efforts.
4) Smaller cycles yield deeper insights
More feedback & iteration means less confusion & missteps. I’ve long been a fan of a more workshop-style approach, and of techniques like Style Tiles. Their limited scope and ease with which they can be collaboratively reworked is a perfect example of quick feedback loops coupled with high levels of engagement. (I’m a believer in supplying large printouts, scissors and tape)
5) Understand & internalize the medium
This should inform your design, not limit it. I believe that ‘real designers code’—or at least they can. Enough to rough out ideas and see if they hold water, and to have an understanding of how things work and what’s possible. A real ‘thing’ is always better than ‘a picture of a thing’: design rendered in code is real.
6) Think in systems
Typographic & design, patterns & components, content & data, technology & administration. This phrase is used often in design, but more often solely with regard to typography and visual patterns. But content changes, and rarely cooperates with our most carefully laid plans. Dynamic systems require us to think more flexibly about content quantity, length and permanence. Our control is over the system, not its specific contents.
7) Question everything, and ask many questions
This applies internally & externally; when in doubt, question it. This goes back to assumptions and communication: don’t spend time wondering if this design pattern can work: ask the developer. Don’t spend hours trying to match a comp, when a quick chat with the designer lets you both arrive at a better solution for the user and the code. And never forget: your client probably knows more about the reasons why this content or requirement exists than you ever will. Just by asking you’ll not only get closer to the answer but build trust and engagement with the client along the way.
These have purposely been kept rather general. While I certainly have opinions about the specifics of the process, this seemed to strike a good balance of guidance and flexibility.
I hope you find these as useful as I have, and that you’ll share your thoughts about them—and how they differ—from your own.
