This article was originally written by Martin Polley.
Most of the work we do as UX designers is either for the web, or related to it in some way. The things that we design are often web sites or web applications. And even if they aren’t, web technologies are finding their way into more and more things: native iOS apps, Android apps, even desktop software.
And the web is a-changin’. Gone are the days when all you needed was a desktop web site or application with a fixed width of 960 pixels. These days, there is a vast range of different devices and screen sizes that you need to think about. And that range is only going to keep getting bigger.
If you’re still using static wireframes to design this stuff, you are doing yourself (not to mention your client, employer, and/or colleagues) a great disservice. Wireframes just aren’t up to the job of showing subtle interaction details—the things that make the difference between an application that is a delight to use and one that frustrates and annoys.
And even if you’re using a more sophisticated prototyping tool, you’re still not doing yourself any favors, because these tools don’t allow your designs to adapt to the multitude of different screen sizes that are out there.
37signals have been vocal proponents of this approach. In this post from back in 2008, Jason Fried explained why they don’t make mockups in Photoshop, instead preferring to “go right from a quick paper sketch to HTML/CSS.”
In an interview with Johnny Holland magazine in 2009, Todd Zaki Warfel, author of “Prototyping: A Practitioner’s Guide” gave some compelling arguments for prototyping.
I can also give our clients examples of how prototyping enabled us to uncover hidden problems, explore design solutions, and make informed decisions prior to launch that we simply couldn’t have done without prototyping…
Prototypes are about show and tell. They’re a visual way of communicating the design of a system. First and foremost, they communicate your design…
In nearly every case in the past three years, prototypes have become our documentation. … It still takes less time to build a prototype and write a 20 page supplemental spec than it would to write a 200 page spec and get consensus on it.
Any design based on a written spec is a design based on theory. A design based on a prototype is a design based on experience and practice.
I think another significant insight is that reactions we get to from our prototypes from clients and customers is far beyond anything we were ever able to achieve with wireframes and static Photoshop visual comps.
In 2010, Aza Raskin wrote a blog post that also touched on the subject.
To design is to inspire participation. To do that, you need to be respected. For that, you need to be a designer-coder.
In May of 2011, Jared Spool wrote the post that really opened up the can of worms.
Interestingly, it isn’t the designers who get to decide if coding is a valuable skill. It’s the hiring managers. And right now, based on today’s jobs market, it’s pretty clear where they stand. Many want to hire super designers—designers who can also code.
… those designers who have proven, practiced coding skills can demand a higher salary than those who don’t.
This provoked a flurry of responses. Matt Nish-Lapidus added to the career and team fit aspects that Jared covered:
I firmly believe that in order to do good design the designer must work with their materials. We can’t continue to just make pictures and flat representations of the things we’re designing. There is a time in the design process for making pictures, but it should be about generating ideas and refining them. There is no way to know what your web site, app, or other software, will actually be like without making a realistic version of a working interface.
Jenifer Tidwell agreed with most of Jared’s arguments, but cautioned that “organizations often value coding skills more than design skills. And when that happens, and you have two skillsets, which one do you think will get used more? Yeah.”
Nathan Curtis of EightShapes recorded a podcast with UIE around this time, and made a great point about the start-up cost of prototyping.
… once that start-up cost has been paid, whether it’s a day of prototyping or even a four hour chunk here, a six hour chunk there. Then things start to really move quickly. That’s in part because our ability to re-use and re-factor different things becomes a lot easier. As opposed to, “Well, you want to make the header twice as large.” In HTML we just change the height from 50 pixels to 100 pixels.
But in a wireframe, suddenly we’re caught going into 16 different files, having to move everything else on the page down, and all of those seemingly subtle changes end up costing a lot, too.
Jack Moffett brought up an important point—knowing how to code increases your scope of influence.
So for me, the ability to code is less about earning “cred” and communication, although I’m sure it has helped with both, and more about dependency and scope of influence. I am less dependent on the abilities and attention to detail of the developers, and I now have greater influence over the entire course of a project. As a result, the final product is better.
These posts also sparked interesting debates on the IxDA mailing list and on Quora. Despite a few dissenting voices, most seemed to agree that being able to code prototypes is a valuable skill for a UXer.
A number of workshops have been put together to teach UX designers how to code, but they’re only any good if you live close enough to the venue to attend. There are short webinars available that show you the why, but that aren’t long enough to go deep on the how.
Originally posted on capcloud.com.