The Future of Web Design 2013 in Retrospect

October 10, 2013

The original text of this article can be found at:
http://www.freshtilledsoil.com/the-future-of-web-design-2013-in-retrospect/

On Tuesday the folks at Future Insights were kind enough to take a chance and let me get up on the stage at the Rising Stars track of the Future of Web Design 201 conference in New York City to talk for a while about my thoughts on prototyping and the design process. The response I’ve received since giving my talk has been overwhelmingly positive, and I wanted to take a moment to thank everyone who participated and address a few points that seemed to hit home with the audience.

If you’re interested in the slides for my talk you can find them here on Speakerdeck. During and immediately after my time on stage many people took pictures of and posted the following slide. Since it appears to have struck a chord I’d love to explain each point a bit further.

Sketch a lot, it’s quick and efficient.

At the beginning of designing a product or site, when you don’t know much yet and you aren’t familiar with the problem, it’s not a good idea to burn time on ideas that don’t yet have an opportunity to be proven in any way. Instead, you want to get to “good enough” as quickly as possible so you can build and test something. To that end, why not use a method that focuses on speed and efficiency, like sketching?

By spending less time on individual ideas you can generate more of them, which gives you a wider pool to evaluate. You can begin to ask questions about those ideas and see how they relate to each other, and you’ll get the obvious out of your system. You can iterate on successful ideas quickly and try to improve them. And you’ll have something to share and talk about with others that’s a bit more solid than abstract thought.

Stop wireframing, start prototyping.

I tend to think of wireframes as an intermediary step, meant for making clients comfortable, rather than a necessity. A set of good sketches accomplishes much the same purpose in a great deal less time. The only real advantage of a set of polished wireframes is that they’re prettier and more presentation ready.

Your client shouldn’t be paying you for pretty (yet). They’re paying for functional, and until you test your work you won’t know if you’ve achieved that goal. Use your sketches to start the conversation about what is and isn’t working. Then move over to prototyping quickly so you can actually learn what’s right for their users.

Test early and often.

The sooner you take that prototype and test it the sooner you’ll know if you’ve met your goals or not. Rather than spending weeks debating whether or not something was a good idea you can stick it in front of users and find out definitively. The earlier you do this the earlier you’ll remove speculation from the process. And the more often you do this the more correct your final solution will be.

Avoid comps for every screen and state.

Creating a polished visual document for every single facet of a product is a sheer waste of time. Take the opportunity throughout your project to do visual studies in whatever medium helps you solve the current problem, and then carry what you learn back into the prototype. Get that work into code ASAP so you can make tweaks in the medium that best supports it: CSS.

Would you rather tweak a border radius in every instance of a button across dozens of files or change one line of code and be done with it? That’s what I thought.

Eliminate redundant parts of your workflow.

My points on emphasizing sketching and avoiding polished comps feed directly into this idea. A great deal of the traditional design process is pure waste, designed to make clients feel fleetingly comfortable and to prove that you’re earning money. There is a great deal of repetition involved, such as when you execute your sketches into the straight lines and smooth typography of a wireframe document.

I think you do the client a much greater service if you can demonstrate early and often that you’re evolving their product in a positive direction rather than showing them pretty pictures. You can get a great deal more work done if you remove the redundant steps in your process, and provide your client a great deal more value over the life of a product.

Process is not a straight line.

Do NOT do the things I’ve discussed in a step-by-step manner. Do whatever solves the problem at hand. Don’t shy away from sketching just because you’re in Photoshop today; don’t avoid code because you haven’t gotten there yet. Every time a new problem comes up, one of the tools in your arsenal will be most well-adapted to solving it, and you should use that tool—not the one you happened to be using when the problem came up.

Creativity is not about following a straight line to an answer. It’s about connecting seemingly disparate thoughts and insights into something new and wonderful. It’s messy, disorganized, and beautiful. Your process should mimic that model.

Thanks to everyone who came to see my talk and to everyone who had kind words to say afterwards. And thanks to the Future Insights team for giving me the opportunity. The care and effort they put into their conference is evident, and I hope they’re around for years to come.