This week: Why speculative work suck, progressive enhancement explained, how to be different and should designers be able to code?
Why speculative design suck
The debate over speculative design has once again raised its head this week.
In case you are unfamiliar with the concept of speculative design, it is best described as the process of producing free work for a prospective client in the hopes of winning a project.
Many agencies (including Headscape) have long since rejected the idea of speculative design. However, it is still common practice within the web design community.
This week Andy Budd lays out his arguments against speculative work. Although Andy raises some good points I feel he misses the heart of the issue which is that speculative work is bad for the client.
A better argument is put forward by one Belgium Agency who is currently on strike protesting against speculative work. They write on their website…
Pitches use up energy. Energy an agency would normally use to provide its existing, paying customers with the best possible work. So the logical conclusion of the system as it now stands is that at some point you will become a victim of it yourself. The day will eventually come when your agency has to divert the creative and strategic energy you’re paying it for into a pitch for someone else’s business.
I put it even more bluntly in my own article on the subject…
In order to remain in business every company needs to recover their cost of sale. This includes web designers. As speculative work is part of the sales process, they ultimately have to charge you for it. The web designer is forced to roll the cost of that work into the project if they win.
However, it is worse than that. The web designer also has to recover the cost of speculative design done for jobs he did not win. This means that if you choose to work with an agency that produces speculative design, you are paying for their failed sales pitches! Why should you be paying for other people’s design work?
So before you next request speculative work I would encourage you to read my post on the subject.
What is progressive enhancement?
As web designers we do love our jargon. One example is the phrase ‘progressive enhancement’. I have even been known to throw the term around casually on the show with little in the way of explanation. However, I bet that a considerable number of the website owners listening (and probably more than a few of the web professionals) do not know what the term means.
Fortunately our very own Paul Stanton has provided a great analogy that explains progressive enhancement.
He explains how progressive enhancement can be seen in video games all the time, especially the big sports titles that span all of the various consoles. Each console has different capabilities with an xbox having consider more processing power than your iPhone.
The result is that although it is fundamentally the same game on all platforms it is actually subtly different in terms of game play and graphics.
Paul explains that this is very similar to progressive enhancement on the web. Each browser has different capabilities and as web designers we build to make the most of what each browser can do. It is the same website but subtly different depending on the platform.
Its a good analogy that I will be using in the future because it draws on something that the majority of people can associate with – video games.
How to be different
We walk a fine line with our websites. On one hand we want them to meet user expectations and avoid making users think too hard. On the other we want our sites to stand out from the crowd and be memorable.
In a new article on the Carsonified blog Kat Neville attempts to walk that line while challenging us to move away from Cookie Cutter websites.
The article is a challenge both to designers who tend to get caught up in the latest trend, and websites owners who are often overly conservative in terms of design. It aims to inspire with some great examples of sites that break the mould and do things differently.
Of course the suggestions are not going to be relevant to every site. You need to carefully consider your target audience to establish how far from the norm you are able to push a design. However whatever your site, it will challenge you to ask if you are just following the crowd or really thinking about design.
Should web designers be able to code?
An interesting argument has exploded on twitter this week and has since spilled over into the blogosphere too. The argument was sparked by Elliot Jay Stocks who wrote:
I’m shocked that in 2010 I’m still coming across ‘web designers’ who can’t code their own designs.
It would appear this was a somewhat controversial comment and led to a massive backlash from designers who do not code.
For fear of inflaming the debate further, I have to say I am amazed anybody could disagree with this statement. Admittedly not every web designer does code, however they should at least know how.
I am not going to layout the arguments for this position here. However, I would suggest you read three excellent posts on the subject…
- Elliot Jay Stocks – Web designers who can’t code
- Mike Kus – 5 reasons why designers should code
- Mark Boulton – On designers writing HTML
If you happen to be a designer who cannot code, I strongly recommend you read these posts. I honestly believe you are limiting your potential and undermining the product you provide your clients.