Responsive design workflow, a review
Today, twenty years ago, the first web page was published on the web, and the web was made available, for free, to everybody. This has changed the lives of everybody who reads this post. I’ve seen many tweets about this anniversary, but there’s one tweet by Jared Spool that I like in particular.
20 years ago this website launched. http://info.cern.ch/hypertext/WWW/TheProject.html Works on my phone today. Will your site work on available tech 20 years from now?
The responsive web is the web as it was intended.
This is the first of many, many highlights I made in this book. It is literary filled with excellent quotes like these. I could have highlighted the whole book if I wanted to. This ought to be enough encouragement for most people to go and buy the book, but if you’re not easily convinced, please read on.
The old workflow
Stephen has been around for a while. He’s been working in design agencies since the early nineties. He knows, and explains, where our deliverables come from and why they’re not suited for the web. Like many of us, he thinks we need different deliverables and a different way of working. The way we used to design was never good enough, but in this age of responsive design it is truly outdated. What he proposes is a:
multidisciplinary, iterative approach to design work for the web that allows clients to experience the evolution of a design from the very beginning with no opportunities for unpleasant surprises
That unpleasant surprises bit is spot on. The design process used to be filled with fantastic promises which resulted in terrible surprises in the development phase. To prevent this from happening again, Stephen says:
I propose overlapping and combining disciplines, eliminating silos within the design process
The new workflow
Many more people are convinced that this is the way to go. I’ve been having some discussions about this lately myself. But changing the design and development workflow means that people have to do different stuff. The things they were doing to get the job done are not sufficient anymore. This book is about the designers’ workflow. It wants to help designers with getting rid off detailed wireframes and complete photoshop templates, and it wants to help them in moving to a pure, web based design approach. While I completely agree with Stephen that this is probably the best way to design for the web, I do fear that many designers will just stop reading once the book gets too technical.
Keep reading this book if you are petrified by the technical parts!
You can just skip the technical bits if you don’t understand them, but be sure to read everything in between! And then, when you’re done — and you’re convinced that indeed, the best way to design for the web is by using the web — go ahead and read the technical bits.
The exact workflow that Stephen works with is clever. Everything he does, from wireframing to prototyping is done with real content, in HTML and CSS, in the browser. Things start off easy, with content reference wireframes in well structured HTML. But pretty fast things get more complicated with the use of pandoc, a command line tool for working with markdown. This is actually an extremely useful tool. If you are serious about the things you write, use markdown and use pandoc to turn it into whatever format you prefer. So yes, every contemporary web designer should get rid of their fear of the command line. It is not scary, and Stephen is a very patient and thorough teacher. You’ll be fine.
there are commands that will erase your entire hard disk or a portion thereof. Just don’t type those commands.
The argument is that it’s easier to do something stupid like that in the command line. And arguably it is. In fact, many things are easier to do in the command line, not just stupid things.
The most complex part of the responsive design workflow, as I see it in a big agency environment, is the design of the different breakpoints. Stephen works with a wonderful solution that he calls breakpoint graphs. During the design process the different appearances on different resolutions are sketched next to each other. This is why I hate books. It’s an elegant solution, yet it is too complex to just explain it here in a few words. I want to link to it but I can’t. Stephen should really publish that chapter somewhere, or blog about it so we can link to it. This is the one tool that designers really need.
Stephen creates a highly automated, extremely nerdy form of documentation. This chapter is by far the most nerdy. You’ll install tools in the command line, you’ll generate documentation with these tools, and you’ll take screenshots of parts of a page with a headless browser! Fantastic stuff! If you want to be an excellent web designer like Stephen, unfortunately, these are the tools you have to work with. I say unfortunately, because these tools are not visual, and they’re not intuitive. Wake up Adobe, or better, wake up someone else and create these tools. Until then, this quote says it all:
If you’ve ever wondered about the “should web designers also be able to code” debate, wonder no more. The answer is yes
The best parts
But for me, the best parts of the book are not the technical bits. It’s the theory. He truly understands what’s wrong with our way of designing stuff. Are we designing the content, or are we really just trying to please our client? And he truly understands the way the web works. The whole book lives and breathes progressive enhancement. And he really understands how you can design for this weird, weird web. And above all, he knows how to explain it.
It’s time to stop designing pictures of websites and start designing all aspects of the user experience simultaneously and in a practical way.
Who should read this book?
If you work in an agency where your colleagues have a hard time getting rid of photoshop templates and detailed wireframes as a deliverable, read this book. It is filled with all the arguments you need to convince your colleagues. Or just let them read this book.
If you’re a web designer who wants to excel in their profession, read this book. If you’re a front-end developer who wants to excel, read it. Project managers should definitely read parts of the book.
Wow. This is a pretty positive review, isn’t it? Am I biased because Stephen is a friend of mine? It could be, but I don’t think so. The issues Stephen describes in this book are the issues that real world designers and agencies are struggling with right now. Not all proposed solutions will fit literary into each and everyone’s workflow, but most of the ideas definitely do.