You'll note that in exactly none of Rams' original points does he tell how one is to go about designing.
In fact, I could even go so far as to say "Good design doesn't tell you how to go about creating it." It's difficult, and it lends itself to many different processes and methods depending on the situation.
It is not necessarily iterative, sometimes iterative design detracts.
What's more, it contradicts point 7: "Good design is long-lasting." How can something be iterative and forever improving, and also long-lasting? You could go into the details and argue with me, but if you do I'll just say you're missing the greater picture.
The "good design" Rams' was talking about is not a process or a means or even a specific thing. It is a static idea of quality, one which is intended to be achievable, and a final product. Iterative might lead to that quality, or it might not. But adding an "11th point" so trivial and insignificant alongside the others dirties the entire collection. It deserves better.
If a design is thorough and long lasting, then why would you need to iterate, much less "ship every day"? Sure, iteration might eventually lead to a good design, but the intervening designs by Rams's definition are not good.
The exception would be when each iteration is thorough and each successive iteration represents a new innovation (principal 1). But most iterative development is not a sequence of distinct innovations. It is a sequence of partial or tentative designs either because there is a business need to ship prior to arriving at a complete design or because the complete design hasn't yet been figured out.
Wells says that the design of physical things can't be updated often, if ever. He says, "This doesn’t work for software anymore." But perhaps that is the problem with much of the software we produce these days. Quantity (of updates, frequency of new features) supercedes quality (of both function and design).
Wells does not seem to quite get Rams.
- Good design is iterative
- Vitsoe 606 Shelving system, designed in 1960 by Dieter Rams. They still make them today, and to the same spec.
It simply makes it the final iteration in that development branch.
Edit: and it has in fact been improved in several regards, mostly materials: http://www.nytimes.com/2012/03/08/garden/dieter-ramss-606-sh...
I'll add another quote: "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." - Antoine de Saint Exupéry.
Eventually you get there. Or close to it.
Too: Rams worked in physical media. Eventually you've got to ship, and in his case, he couldn't push updates twice a day. This happens even in software and web design. The "bones" of Linux were layed down in AT&T's labs over 40 years ago. For mainframe computing, history starts over 50 years back.
Even today's major websites have their own mass and inertia in the form of their code base -- you can push changes every 12 hours, if you like but things have to work together, and either modularity or fragility will impose limits on what you can reasonably change and expect to have functioning, stable code.
See also calinet6's comment.
And would users say that the constant UI rearrangements in modern apps are good design? Absolutely not. The UI paradigm of putting buttons in set places on screen doesn't jive with constantly changing their positions, because you memorize the UI by those positions. This is particularly annoying with rarely used features because every time you use them it's a totally different UI.
Depending on constant iteration is not good design. It is a crutch permitted you by software. You can still come up with long lasting solutions if you give them some thought.
Not everything needs to be shipped every day. Or built. Or tweaked.
An architecture that supports iteration may be deemed good design per Rams if the support for iteration is more useful than if it did not. To developers, that architecture could also be more aesthetic, innovative, long lasting and even environmentally friendly (consuming less resources). Sometimes agile architectures are more understandable, but often they are less so.
This is an interesting point. Does the "agency mindset" really dictate that once a project is finished, it's finished? Even more, what's the difference between having an agency/designer on retainer as opposed to employed? The only difference I see is the amount of time/effort it takes to get an idea implemented (which is wholly based on that company or individual). Moreover, that chasm creates time to let an idea develop (and no, I'm not saying over thinking but at least considering the value/utility of the change or addition).
I think it's a matter of identifying your company's needs. Some can get away with a one and done approach; startups, too. It really depends on what you're making.
A solid agency will help to identify any caveats and get the design to a point where it doesn't have to be iterated on. There's always room for improvement, though, it's possible to make something excellent happen on the first swing.
First I take a bit of umbrage at the term the "agency" mindset because it seems to indicate its our fault. Its more of the "agency relationship* mindset.
Unfortunately despite that its a bit true. We generally are in the business of getting things done and out the door so we can go onto the next project. Its very much the nature of the business. But a lot of this is also driven by our clients. The best clients realize this is a phased a approach and build in separate phases to accomodate user testing A/B testing and realize that the work isn't done after the work is dropped. Its great when we get clients such as these, because we get to really focus on the product. Unfortunately they are few and far between. Most are much more budget focused and when we bring things up like A/B testing and phased approaches, they get excited, when we show them the costs for this kind of work, most of the time these kinds of "extras" are what gets dropped.
Now part of this problem also comes from larger agencies. There's some folks out there who won't do a project thats not $500k or larger. Trying to tack on an additional $100k of improvements post delivery isn't something they're interested in doing. This isn't just hubris, if you're running a shop of 100 folks a "small" 100k project presents problems, it utilizes resources better used elsewhere, and you'd be running your sales and account folks ragged managing 4 or 5 of these small projects (One account manager on one 500k project is a lot better then one on five 100k projects).
This tends to get worse on the dev side, for dev we do the best we can to get a nice clean codebase out the door, but frankly once it "works" its done. Unlike design which actually does have some iterations and polish built into the design process dev is more "does it work to spec" and done.
A solid agency will help to identify any caveats and get the design to a point where it doesn't have to be iterated on.
I'm not sure this is true, the better the creatives working on a project the closer you'll get to it, but its always a tradeoff against budget and time.
I suppose I should have said that a good agency will be able to get a design to a point where it doesn't need to be iterated on but can be. It's certainly an important thing to acknowledge that getting a 100% perfect release is difficult with budget and time constraints.
A lot to think about.
The nice thing about iterative development is you can build amazingly complex systems that way, systems that are so complex they have no obvious deficiencies. Of course that's also the not-so-nice thing about iterative development too. But either way iteration is a development process. It isn't something that is a design characteristic.
I do think however that good design is flexible. It tolerates changes on all sides. Users can repurpose it. Developers can improve on it. Good design is robust in that it handles these changes. If you want to use that to iterate the design, go ahead, but that's the design principle.
Software is tricky, the needs of the users can change over time, and the developers understanding of the project will most likely change over time as well. If not for any other reason than keeping up with competing technologies, or the introduction of new technologies.
So I would agree, iterating your application's design is very important. But ideally, if it was designed in strict adherence to the 10 principles of design, the essence of the application would be long-lasting. This would mean any needed changes would be intuitive.
The 606 Shelving system certainly went through many iterations, tweaks and changes. At the time of its inception the method of production doesn't allow for the continuous deployment and testing of changes. To me, design from that period is monumental by definition because of this. You had to build something perfect because it only happened once.
http://williemorris.tumblr.com/post/30410924657/no-need-for-...
Can you imagine the user experience if everything was constantly changing. Yikes.
For us humans we're not as intuitive with nature. We have many distractions and conflicting goals. It takes us more, and longer, iterations to figure out these things. We're just not lazy-enough.
If it's iterative then you never have a final design by definition, so how can you judge anything? You can just say "it's beta, it's not finished" to avoid criticism. That's the typical BS we hear from poor software developers all the time.
I can't help but feel this when i look at architecture. Medeival stone masonry, for example. When it takes decades to build, you can tweak the design. In particular, this is evident to with respect to "human scale," 3-dimensionality, volumetric balance, and proportionality. Much early modern architecture, was just designed to look cool as a model; or to photgraph well in publication. Much of this architecture has a PRE_FAB feel to it (brutalist, etc). Ironically this emerged in the context of (a) more powerul modeling tools; and (b) more degrees of freedom in plastic materiel (ie, modern materials, RC etc).
Edited: brevity
