When to prototype in code
Eli Schiff has written a series of posts discussing the way design is currently viewed in the technology industry. He criticises the expectation that every designer working with interactive media must be able to prototype in code, and that this skill is more important than many others, including visual design.
A good design, like a good prototype, meets the needs of certain people in certain situations; no design is universal. It’s unrealistic to expect a design to serve all purposes, in all of the places it could be used, at all times and for all people.
Prototyping serves more than one purpose. If the purpose of a prototype is to probe the material qualities of a medium, then it should be made in that medium, but in other cases the choice of medium is less important.
A prototype is an abstraction — a tool for thought, exploration and communication. Some prototypes explain an idea so that it can be discussed with other people. Others help the designer think about the purpose and features of a product. Low fidelity prototypes can be used to gather feedback about big picture ideas, while high fidelity ones generate feedback about the specifics of function and style.
Many of the people quoted in Eli’s posts are critical of Photoshop as a prototyping tool for web pages. That disdain may stem from working with mockups meant to represent the final result pixel-for-pixel. However, Photoshop isn’t the problem; it can be a quick and efficient tool when used by a skilled designer who understands the web. The problem arises when people expect mockups to be turned into pixel-perfect reality.
A good designer understands that prototyping serves many purposes, and that prototypes can play different roles. They will choose the right tool for the required form, fidelity and medium. For some designers, being able to prototype in the browser is a useful and powerful skill. For others it isn’t, and that doesn’t diminish their capacity to produce great work and communicate their ideas effectively.