I call it undiscovered country. You can imagine it like a bunch of ships arriving on the shore of this new land, and there’s a town there. And that town was iOS when it was first created. You land and you claim this area around it. You’re out there, and you always land to explore. And we’re very much in the infancy of touch-based design. The interesting thing is that we’ve just landed on the shore, and some people are spending all their time designing, effectively, in the town they’ve landed at.
All these ships are arriving, and more people are arriving on the shore and turning up in this town every day. And some of us are saying “Oh my God, you can go over there and claim a mountain and stick a flag on top of it”, and that’s the thing you can do. Loren Brichter was out there and he planted one. There’s a hill right outside the town, a little way down the road but off the beaten track. And he went right out there to stick his flag and claim pull-to-refresh.
That’s the way I look at it. We’ve got this amazing opportunity to go out there and claim mountains for ourselves. It will never come again. We’ve got this opportunity right now to go and claim these mountains right close to the shore. Afterwards, in the distance, people will have to travel further. You’re going to get across mountain ranges in order to find something new, in order to get something new to explore. I want to go to the top of those closest mountains and claim those myself.
That mountain – once you get to the top of it and standing there and saying “Oh my God, that really worked, that was amazing”, and you see all these people and boats clustering down there, and you’re going “Guys, guys, over here”. And down the other side of this mountain, in the valley down hill, there are all these other things that we can do, and that’s the most amazing thing. When you’re at the top of one of those mountains, you get to see things that other people can’t, and that’s where I feel I am right now. Some of us are at the top of mountains looking down the other side into grassy valleys.
A few years ago, in a company whose name doesn’t really matter there sat a programmer working on fixing a few bugs and adding a few features. And as he was sitting there, an idea struck him. An idea for a feature which was kind of related to what he was doing. And he leaned over to his cube mate and outlined the idea. And the cube mate told him that it’s a nice one. And that he should see if the idea can be turned into a patent. Not because that idea would actually be turned into a feature. But because everybody else tries to patent ideas, no matter how small or big they are. Or no matter what actual connection they have to what you’re doing in the office. Play the game. Send an email. Let the process begin. Sit in a couple of meetings. And then a few years later, if it turns out to be an actual patent, get some extra money. Just for having had that idea.
And the programmer sent that email. And got a conference talk scheduled for the next week. A talk with a patent attorney. And with every day that passed, the programmer’s excitement has declined. And declined. And declined.
It started with patting self on the back and kind of marveling at self for coming up with the idea. And hey, extra money doesn’t hurt. Not that it’s a lot of money. But not loose change either. But with every day, the realization of how ridiculous and pathetic it is to think that an idea for a pure software-side flow is patentable started to sink in. Growing claws. Clawing at the inside, reducing the self-built pedestal to a heap of quick sand.
And then the time came to sit with the attorney. And the programmer was so dejected at that point that he just wanted to make it all go away. And the attorney sat there and said that he was going to just read this paragraph. And he started reading from the piece of paper. And, sentence by sentence, in six or eight short sentences it described the exact flow that the programmer had in mind. And then he asked whether it was in any way similar to what the programmer had in mind. And the programmer said that it was exactly the same. And the time to sit with the attorney was over.
And ever since then, the programmer has hoped to never be in such a situation again. To never bear the burden of self-inflicted aggrandizement of self. To never think that a mere idea in the realm of pure software is worth the notion of being patentable. To remain humble. To stand on the shoulders of others. To push himself to hone his craft and become better at it every single day. To hope that one day some of his ideas and code will be useful to others. And to never presume to claim that they were original in any shape or form.
Over the last few months I’ve read at least a couple dozen online articles, threads and discussions about skeuomorphic and flat design. The articles came in three waves. The first wave was about how skeuomorphic is well past its prime time and needs to go away. The second wave was about how flat is the exact opposite of skeuomorphic, and how it is the new direction of visual interface design. And finally, the third wave is about the poor usability of flat design.
Some of this discussion is happening on Twitter. There’s only so much one can say in 140 characters. Even when you break your argument into multiple consecutive tweets, the argument – more often than not – gets a simplified presentation. And sometimes the simplification of presentation leads to cutting logical corners.
Flat is indeed the exact opposite of skeuomorphic, but only if you consider the constraints that the designer employs in choosing his palette. Leaving the restraint part out of this argument leads one to believe that as the opposite of skeuomorphic, flat design is always done well. That, of course, can’t be further from the truth. This omission, by the way, can be deliberate.
If one can simplify the argument to pure one-dimensional comparison, and follow the stripped down logic to the “necessary” conclusion that flat is good – and immediately show bad examples of flat design, then the entire argument falls apart. Now, if you trace the refuted conclusion back to its beginning, the implied coup de grace is that flat is bad.
The opposite of a poorly done skeuomorphic design is not a well done flat design. The logical fallacy here is taking one part of the constraints/restraint spiral and extending the comparison to include the second one. The opposite of a poorly done skeuomorphic design is a well done skeuomorphic design. The opposite of a poorly done flat design is a well done flat design.
The opposite of a poorly done design is a well done design. Well done design that takes a long, deliberate and careful look at the available tools (constraints) and plunges into a long exercise of applying restraint in using a subset of those tools to arrive at the final product.
Design lives and dies by two things – constraints and restraint. Constraints bound the variety of tools at designer’s disposal, while restraint guides the designer’s hand at how the chosen tools are used to create the final product. It’s rarely a sequential process, but rather a spiral that tightens toward the end, where the outcome of the previous steps informs and guides the next iteration. And each step – in both spaces – requires painstaking attention to details, paced deliberation and continuous pursuit of honing one’s craft.
There is nothing inherently wrong in what people have come to call “skeuomorphic” design. The choice of fewer constraints gives you a wider selection of tools to work with. Glossy bevels, generous drop shadows, intricate textures, strong gradients and more – all of these justly belong in a rich skeuomorphic visual palette. There’s no shortage of examples of strikingly beautiful visual design. Design that combines multiple textures, gradients and materials in a consistent form. Design that exercises restraint in how the rich palette is used. Restraint in how elements are chosen, which elements are left out and, most importantly, how the chosen elements are combined together.
On the opposite hand of the spectrum, if you will, is the “flat” design. Design that chooses to constrain itself to a very small number of visual elements. Sharp corners, solid colors, simple shapes, absence of drop shadows or, for that matter, absence of a global lighting model. The stark beauty of flat design is particularly impressive given the constrained choice of the tools. One may even be led to believe that the simplicity of this palette translates directly into the simplicity of the overall design iteration spiral.
This couldn’t be farther from the truth. Tighter constraints that result in a reduced palette do not necessarily obviate the need for restraint. Restraint is not only which tools you choose from that palette. It is also – and much more so – about how you combine the tools together. How you define and implement a visual language that stays true to the flow and shape of the interaction.
It is trivial to create a bad skeuomorphic design. There are entire blogs dedicated to ridiculing poorly-executed mashes of garish textures, exaggerated lighting and gaudy 3D controls. It’s not surprising to see these sites – and most recent blogo-bashing of skeuomorphism – focusing on pure visual aspects of such interfaces. On the other hand, as more designers dip their toes into the field, we see an increasing number of badly executed flat designs. The drive-by critics focus, this time around, on the usability blunders.
When you constrain yourself to simple shapes, solid colors and lack of depth, it becomes much easier to sacrifice usability. A hurried design executed from a rich skeuomorphic palette will look garish, but at least there are enough visual tools to help set the different pieces of content apart. With so many textures, gradients and shapes to choose from – and little restraint – one can still create a fairly usable interface. Usable in the sense that a button “looks” like a button – something that can be pressed to initiate some kind of an action. When you directly migrate this hurriedness into flat design, it is much easier to end up with an interface that jeopardizes the structure of your content.
Flat design necessitates deliberate definition of the visual language. How do you convey the logical structure of your content and maintain the logical separation of blocks in the visual realm? How do you convey the behavioral difference between the different blocks? How do you convey the logical importance and relationships between the content blocks?
When everything is a flat rectangle, and you only have a few accent colors to use, you have to exercise a much higher degree of restraint in defining that visual language. When your tool palette is restrained to a very few elements, you cannot afford to use the same element to mean two different things with no significant user-facing distinction. If your buttons and your section headers are the same flat solid-fill magenta rectangle, but the section headers are not tappable, you are not exercising enough restraint in how you’re using your palette.
It is hard work to create a strikingly beautiful, aesthetically pleasing and well-behaving skeuomorphic design. The restraint that the designer must exercise at every turn of the spiral to use the rich variety of tools at his disposal takes attention, energy and time.
It is hard work to create a strikingly beautiful, aesthetically pleasing and well-behaving flat design. The restraint that the designer must exercise at every turn of the spiral to use the small variety of tools at his disposal takes attention, energy and time.
Finally, skeuomorphic and flat are just two extremes of the same spectrum. One does not have to go from one extreme to the other. There’s enough space in between to carve out your own, unique niche. The closer you get to one of the ends, the closer you get to the “extreme” choice of your tools – be it the rich palette of skeuomorphism or the small palette of flat. But the size of the palette has nothing to do with the next phase of the spiral – defining, refining and restraining your usage of that palette.