All you do is be mindful of when the team repeats design desires. This could be several members of the team say the same thing in a slightly different way, or that you keep circling around and around a problem but struggle to articulate it. By being mindful at all times to this a team can quickly pull together principles that are derived from doing the work on their particular problem rather than principles which are imposed on the work. An important difference.
This is a fascinating exercise—take a good set of design principles and test them for reversibility. The results are entirely plausible.
I’ve taken this exercise to the extreme. The philosophy behind inclusive design is that the thing you create works for everybody, no matter the context. The idea behind this experiment in Exclusive Design is that you design something for one specific person, in a controlled environment, in a specific context. Tailor made.
Maybe I should add these to my collection.
- Provide a unique experience
- Ignore situation
- Be inconsistent/innovative
- Take control
- Offer the best possible solution
- Prioritise identity
- Add nonsense
I love John’s long-zoom look at web development. Step back far enough and you can start to see the cycles repeating.
Underneath all of these patterns and practices and frameworks and libraries are core technologies. And underlying principles.
These are foundations – technological, and of practice – that we ignore, overlook, or flaunt at our peril.
I like this list:
This is not a checklist. Instead, it is a set of broad guidelines meant to preserve an underlying value. It can be used as a guide for someone working on implementation or as a tool to evaluate an existing project.
I’ve added them to my collection of design principles.
A series of questions to ask on any design project:
- What are my lenses?
- Am I just confirming my assumptions, or am I challenging them?
- What details here are unfair? Unverified? Unused?
- Am I holding onto something that I need to let go of?
- What’s here that I designed for me? What’s here that I designed for other people?
- What would the world look like if my assumptions were wrong?
- Who might disagree with what I’m designing?
- Who might be impacted by what I’m designing?
- What do I believe?
- Who’s someone I’m nervous to talk to about this?
- Is my audience open to change?
- What am I challenging as I create this?
- How can I reframe a mistake in a way that helps me learn?
- How does my approach to this problem today compare to how I might have approached this one year ago?
- If I could learn one thing to help me on this project, what would that one thing be?
- Do I need to slow down?
Analysing what the web is. It’s not the technology stack.
To count as being part of the web, your app or page must:
- Be linkable, and
- Allow any client to access it.
I think that’s a pretty good definition.
Mind you, I think this is a bit rich in an article published on The Verge:
The HTML web may be slow and annoying and processor intensive, but before we rush too fast into replacing it, let’s not lose what’s good about it.
Still, we can agree on this:
Preserving the web, or more specifically the open principles behind it, means protecting one of the few paths for innovation left in the modern tech world that doesn’t have a giant company acting as a gatekeeper.
Ellen goes through the principles behind the tone of voice on the new Clearleft site:
- Our clients are the heroes and heroines, we facilitate their journey.
- Speak as an individual doing whatever it is you love. Expose lovable details.
- Use the imperative, kill the “-ing”.
- Be evocative and paint the picture. Show don’t tell.
- Be a practical friend.
- Be inquisitive. Ask smart questions that need solving.
Some proposed design principles for web developers:
- Focus on the User
- Focus on Quality
- Keep It Simple
- Think Long-Term (and Beware of Fads)
- Don’t Repeat Yourself (aka One Cannot Not Maintain)
- Code Responsibly
- Know Your Field
The styleguide, design principles, and pattern library for British Airways. It’s the “global experience language” for BA …so it’s called BAgel.
I really, really like Heydon’s framing of inclusive design: yes, it covers accessibility, but it’s more than that, and it’s subtly different to universal design.
He also includes some tips which read like design principles to me:
- Involve code early
- Respect conventions
- Don’t be exact
- Enforce simplicity
Come to think of it, they’re really good design principles in that they are all reversible i.e. you could imagine the polar opposites being design principles elsewhere.
I think Tyler’s onto something here:
I noticed three qualities that recurred in different combinations. Without at least two, the projects seemed doomed to failure.
I certainly think there’s a difference in how you approach a pattern library intended as a deliverable (something we do a lot of at Clearleft) compared to building a pattern library for an ongoing ever-evolving product.
Y’know, I think PPK might be on to something here. It’s certainly true that developers have such an eversion to solving a problem twice that some users end up paying the cost (like in the examples of progressive enhancement here).
I will be pondering upon this.
Marvellous insights from Mark on how the robustness principle can and should be applied to styeguides and pattern libraries (‘sfunny—I was talking about Postel’s Law just this morning at An Event Apart in Boston).
Being liberal in accepting things into the system, and being liberal about how you go about that, ensures you don’t police the system. You collaborate on it.
So, what about the output? Remember: be ’conservative in what you do’. For a design system, this means your output of the system – guidelines, principles, design patterns, code, etc etc. – needs to be clear, unambiguous, and understandable.
A wonderfully thoughtful piece on typography, Jan Tschichold and the web. This really resonated with me:
It’s only been over the past year or so in which I’ve recognised myself as a ‘Web designer’ with a capital W, as I now believe that something happens to information and technology, and even typography itself, when people pass through these interconnected networks and interact with hypertext.
It’s for these reasons that I don’t believe in “digital design” or “designing for screens” and it’s why I’m often attracted to one particular side of this spectrum.
Robin proposes three “principles, suggestions, outlines, or rather things-that-I-ought-to-be nervous-about when setting text on the web”:
- We must prioritise the text over the font, or semantics over style.
- We ought to use and/or make tools that reveal the consequences of typographic decisions.
- We should acknowledge that web typography is only as strong as its weakest point.
There’s an in-depth look at applying progressive enhancement to web type, and every single link in the resources section at the end is worth investigating.
Oh, and of course it’s beautifully typeset.
A great little primer on the origins of the internet and the web, by Aleks.
Very thoughtful and sensible thinking from Paul.
I really like the way that Paul’s talk builds on top of ideas laid down by Ethan and Frank. Good stuff.