Sometimes, when discussions are really interesting, I find it hard not to chime in.
Mark Boulton tweeted:
I wonder if #RWD looks the way it does because so many projects aren’t being run by designers, but by front-end dev teams.
Then the fine Mr. Tim Kadlec wrote a great post, followed by observations from Susan Jean Robertson. There were also a few thought-provoking responses to Mark’s tweet.
Tim and Susan (and others on Twitter) seem to agree that workflow/process—specifically lack of communication between designers and developers—tends to lead to the type of design sameness we’re observing today. I agree that this is a problem for many aspects of the design process; in fact, I wrote a book about it. And with the utmost respect for Mark, Tim and others, I tend to be skeptical that getting designers and developers to work together will solve the design sameness problem. That’s not to say it doesn’t need to happen; it certainly does.
In my experience, most projects are not run by front-end developers, as Mark suggests might be the case. Of course, that’s just my experience. In fact, I observe that front-end devs often get the short end of the stick, basically forced to implement whatever gets thrown on their plate by designers and requirements. In the same way, the visual designers before them in the waterfall process must implement that which has been handed to them by interaction designers, UX designers, or whoever might be in front of them. A slightly longer stick, but still pretty short. This is a workflow problem, and one of the main things I’ve spoken and written about for the past few years.
But this doesn’t necessarily explain why responsive sites share similar visual characteristics.
At the moment I can think of three things that I theorize might be at least as important as workflow, in regards to RWD design sameness:
- Lack of a solid graphic design foundation
- Excessive reliance on tools
- Lack of critical design thinking when copying the work of other designers
Lack of a solid graphic design foundation
Now that design education has fragmented somewhat between “traditional” graphic design and web/digital/whatever design (even though students are often required to take both), I get the feeling that many designers live with the assumption that these are two separate worlds. It’s probably our fault (I know I’m guilty of it): we keep hammering on the differences between design for web and design for print.
But web and print are simply media. Design is problem-solving. Design is—and for the umpteenth time I quote Paul Rand—”the method of putting form and content together”. Contrary to popular web-belief, good web design is not only typography. Web designers need to know how to design. They need a solid foundation in the principles of design. And when they choose their preferred medium, of course there are always specifics that are only relevant to that medium.
A problem arises when designers lack a basic design foundation, yet have a working knowledge of medium-specific design concerns. Lacking the foundation, their creative potential has a fence around it. And, if what Mark says is true and devs are designing, that foundation might be lacking as well. And, no, I don’t mean go read The Elements of Typographic Style and you’re off to the races. Graphic design is a formal, legitimate field of study.
Judging by what I’ve observed while guest-lecturing to web design students, I suspect that tool-based education and reliance on tools and frameworks is partly to blame.
Excessive reliance on tools, frameworks and pattern libraries
Similar to Mark, I’ve often quipped that 50% of the web looks like Twitter Bootstrap. And it shouldn’t be surprising when a good portion of web design education is tool-focused. Photoshop. Illustrator. Web-based answers to Dreamweaver (“but they generate better code!”) that use frameworks as a Foundation for the generated code. (See what I did there?)
No matter how you look at it, tools are just tools. In my book, I present the Tool Rule: it’s not about the tools. Frameworks are prefab. These tools are about execution, not design. Design involves first thinking, then execution. And when one designs for a particular medium, they need not be shielded from the inner workings of that medium. Designers who want to know how to change Bootstrap need to know the inner workings of Bootstrap; have fun switching frameworks down the road. But why hide the web from them behind an abstraction layer? Would designers come up with more appropriate visual patterns if they knew more about what was possible outside the confines of a framework?
Yes, designers must learn tools. Which tools would make them more effective at being able to effectively design for the web: those that teach them about the web, or those that teach them a particular framework? I don’t know the answer; I just have my opinion.
Lack of critical design thinking when copying the work of other designers
Designers copy/steal trends all the time. Sometimes this is mandated by bad clients (“my competitor does this so it must be good”—oh, the logic), and often designers emulate the bits they like from others’ work into their own projects. It’s not only graphic designers doing this, but interaction/UX designers and developers as well. We copy patterns we like. We have pattern libraries. Prefab building blocks to help us work faster. Faster perhaps, but not always better.
Emulation is a part of the evolution of design. And the web, for that matter. But design sameness tends to fade when one forgets all of the existing patterns, all of the Bootstraps, all of the preconceived design solutions. Design sameness fades when designers stop focusing on which solutions for their problem are out there and start focusing on the problem at hand.
Solve that problem, and maybe the solution is exactly what your peer implemented, in the exact same way. But maybe not.
(Thanks to Mark Boulton for reviewing this post.)
In terms of ‘samey’ design, I hold my hands up and agree, time and money is the reason I often have to take the easier option. I think the use of a frameworks being partially responsible is a good call. Although we don’t use them I can see frameworks are great for people putting together bespoke sites quickly, in isolation often on a small a scale . They are often very clever and well put together but I struggle to understand why they are so readily pushed by designers, magazines and blogs. Often those same channels are quite damning when people stray from the ‘Semantic Path’ yet they encourage people to use libraries which have thier users using class names such as ‘2column’,’grid6′ or worse still ‘awesome big orange button’. This is why, like @susanjrobertson we don’t use them. Working on a large platform, within a big team of design, developers and designers who develop, both internal and external we strive to have that clear separation between our markup and and styles. This means we can work a lot like Zen Garden and give people markup to work with, where they are not having to override styles which are named after a particular layout or look. Sorry, strayed a bit off topic there.
I think we are forgetting that the stick is held by other parties, who have others behind them holding more of the stick. In the end, many of the parties involved in the creation of a site feel they have the short end of the stick. Often times, people want to see more of what they’ve seen before, because its comfortable and it’s “proven” in their minds to work.
I agree, there is a workflow problem between all the hands that play a part.
I think it’s lack of knowledge on the subject – from both developers and designers alike – which means we’re following what’s working out there; following rather than leading e.g. Twitter Bootstrap.
I also occasionally wonder if we need to examine whether “design sameness” is necessarily a bad thing.
For every person I hear complaining about Yet Another Bootstrap Site, I have at lest two happy readers to hand who can get at the content on N different devices in a sane way.
Is the uniformity we have now actually a better jumping off point to better designs?
Steven, you’ve nailed it – spot on. Critical design thinking and lack of a solid graphic design foundation are at the heart of the problem. These are the two key aspects I’m looking for when hiring designers at Nomensa. That’s not to say that we only hire designers that have a traditional graphics education – as I’m confident we have an environment to teach that – but having an enquiring mind and ability to dig deep into the why of things is vital.
Also, some popular frameworks have been around a little while now and as a result the aesthetic of the default UI have become very fashionable with young designers. This is a shame as, although some of them are not particularly accessible (that’s another matter), the code is usually well separated. That means there is no reason not to create something more unique or appropriate for the customer.
You nailed it!
I often marvel though at how far the web has come. When I first started, the design decision mainly hedged around simple resolution: 1024×768 and 800×600. Now wire-framing websites for all environments has become a full time career in many ways let alone browser compatibilities and html5 approaches.
Technology can be hard to keep up with that I am sure that is why so many resort to “tools” to do it for them. Not saying they are right by doing so though.
There is a tension between Designer vs Usability.
I recall a presentation by @aarongustafson that highlighted “design != art”, where art serves the artist (ego). Which I interpret to be “look at my work, it is _different_”. Maybe it is different, but is it clear to users? Look at the trend to remove underlines from links – a long established hint for users for what is clickable. Looks prettier, but is less usable.
I would a post around designing better implementations than just glossy difference.
@Brian: Feel free to read the post again if you think I’m talking about “glossy differences”.