Design Principles
principles.design
principles.design
Good design is innovative
Good design makes a product useful
Good design is aesthetic
Good design makes a product understandable
Good design is unobtrusive
Good design is honest
Good design is long-lasting
Good design is thorough down to the last detail
Good design is environmentally-friendly
Good design is as little design as possibleWhich makes sense to me, it reads like a deeper "do not reinvent the wheel".
All the rest are spot on in my opinion.
Architects, for example, are always dealing with slightly unique or novel spatial circumstances, which is why they are considered designers. Building identical suburban houses from a pattern book is not design -- and it's not innovative.
I think Rams' thoughts do all make sense if seen in this light.
So I think you can see all ten rules as a complete set.
The comments here that disagree with Rams' first rule seem to me to be putting the cart before the horse and assuming that Rams is offering a prescriptive list for would-be designers. I think he's just describing what he thinks constitutes good design. It is not an injunction to innovate: it is an observation that "design" which does not innovate is inconsequential.
If the purpose of design is to solve a truly valuable problem or introduce pleasure to a process, and if these possibilities—if we're honest with ourselves—do not exist to be solved, one cannot innovate, therefore one cannot design.
A honeypot to the those who see design as surface, a challenge and call to arms to those who see it as more?
(*I'm curious if anyone knows what this type of phrase is, one that can be interpreted in two different, opposing ways. Best I can tell is _polysemy_)
Design, as the op even says, is not just (although it definitely also is) about utilitarianism! The world of successful products should at least suggest that to you, if you won’t take it as proof.
This one is forgotten too often. A good design brings the content forward, it doesn't hide it.
Good design is honest particularly catches my attention, because the design of many digital products is fundamentally about misleading the user - see for example Facebook, where users are kept in the complete dark as to why certain posts are shown to them and not others, what data about them is being collected/resold, etc.
Good design evolves.
Another important part of design is that you have to consider the medium. At all times. (I'll have to stop here before I go on a rant about mobile apps with "color samples" people use when picking wall paint colours...
https://images-na.ssl-images-amazon.com/images/I/41Ae3ah0jPL...
"Tolerant: Handle errors respectfully.
Effortless: Don’t make demands or place restrictions on your users.
Accommodating: Be approachable, uncluttered and give people room to manoeuvre.
Consistent: Follow standards, guidelines, conventions and best practices."
A framework I usually use is a "this over that", where both "this" and "that" represent things generally considered "good". The Agile Manifesto contains a brilliant example of this:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Notice how everything on the right is also a "good" thing, but the manifesto is making you CHOOSE.
It was hard to argue that those teams weren't following both the message and spirit of the agile manifesto, as individuals and interactions were plainly taking precedence over tools and processes.
It doesn't, after all, say "individuals and interactions over tools and processes, except when tools and processes make more sense".
That said, the problem you described isn't really with the manifesto, but with people refusing to use common sense - or even more likely, with incentives within the organization being so aligned that decisionmakers benefit from making bad calls. It's something that happens surprisingly often.
That's exactly how the teams I worked with applied it. They were in doubt and they decided on individuals and interactions.
>That said, the problem you described isn't really with the manifesto, but with people refusing to use common sense
It absolutely is a problem with the manifesto and it isn't a common sense decision.
Expending a not insignificant level of resources on automated regression testing and CI, or indeed, any other kind of tooling or process is far from a common sense decision - it's a pretty delicate trade off, in fact. Some tooling is worth it, some isn't.
If the manifesto said "think carefully about tooling and recognize the delicate trade offs involved" then maybe the problem wouldn't be with the manifesto. It doesn't. It says "individuals and interactions over tools and processes". Ergo meetings > tools.
If you're curious about principles backed with implementation details, check out https://cadence.cc. Looks unassuming but one of the best books on design I've ever read.
Cadence & Slang did not impress me. I read it a few years ago now so I can’t quote exact examples, but at the time it felt like more fluff to be honest. Well written fluff, but still fluff (ie will design students in 20 years, or even now, benefit from reading it like they would a classic such as “Grid systems for visual design”? My money is on no). Would be curious to hear what aspects of it you particularly enjoyed.
Sadly enough, I find that the best books on designing for interactive media are from the 80s/90s. Examples include Raskin’s “The Humane Interface”, Togazzini’s compendiums, etc.
An example paper of mine: Toward Principles for the Design of Navigation Affordances in Code Editors: An Empirical Investigation http://dl.acm.org/authorize?N37917
From what I remember of studying Human Computer Interaction (HCI) as an undergrad in the 90s, the evidence was derived from learnability studies. This meant that research favoured point and click interfaces (which are the equivalent of caveperson grunting, IMO) over command line interfaces which allow much deeper expressivity. There was basically no affordance to systems that people use day-in day-out and are happy with the trade offs in the learning curve (vi, emacs, blender, lighting desks, audio controllers, Bloomberg terminal).
I like that your example paper is about trying out different interactions in a small part of a daily-driver piece of software. But it's still trying a 'new' thing for some of the experimental users which means learnability is core. How do you manage the balance?
CHI is the biggest and most prestigious, but also most general. It will include a lot of irrelevant papers too. UIST is smaller and focuses on novel interactions. CSCW is about collaboration. IUI is about intelligent user interfaces. VLHCC publishes work on developer tools from a human perspective.
The easiest way to find these papers is through scholar.google.com. Just search for what topic you want, and it will try to find relevant research papers.
Re: C&C, a couple of things (just picking from my highlights).
Chapter 2 - Consistency & Character
This informed my own work quite a bit. Especially notes about how consistency aids clarity in the product. Also nice "hmm, now there's an idea" type of stuff like "a designer creates an architecture of information within the mind of the recipient of his work." This triggered a bit of a waterfall, leading to stuff like reading Christopher Alexander's _Notes on the Synthesis of Form_.
Also from this chapter is the point about how having a consistent behavioral language. Meaning, if two elements perform similar tasks, they should look similar to one another.
Lots of great little beats like this that have wedged themselves into my thinking.
Chapter 3 - Simplicity
The one about only forcing a user to create an account when it provides value really informed my ability to design solid onboarding experiences. Taught me to build gradually invasive products that speak to the user like you would a new acquaintance. Over time, you slowly get comfortable asking them for more and more (e.g., use things like local storage to persist data temporarily to give the feel of hitting a DB).
---
Man, is there a place to talk about stuff like this? You got my hamsters spinning.
Are there any other books you recommend?
The first few words on the Tim Berners-Lee page I saw were: “Simplicity is easily to quote but often ignored in strange ways.” which is another typo that passes spell check, but makes no sense as-written.
I've used Asana on and off since it started. Because I'm an occasional user, it feels as if every time I come back to it, something seems to have changed and I lose all reference to where my tasks are.
Right now, whenever I go there every few months, I have to remember that my client's tasks are buried in a dropdown in the top right.
Worst part is, it doesn't look like a dropdown, it doesn't look like a menu, it doesn't look like a link. It's just black text saying "Overview" next to my picture.
Also, for some reason the default task list I land on is completely empty. I have no idea why. At one point I was using it for quite a lot of stuff and there are a load of unfinished tasks in it when I start clicking in categories in the right. But there is no indication anywhere on the screen of what lists might actually contain something.
It's a bloody awful design.
Their design principle no. 6:
Be consistent and standard, and innovate when it’s worth it.
So you can have design standards all you want, but when your designers think "consistent and standard" means something completely different than your users, it turns out they're not really meaningful.