| The reasoning behind the separation in these steps is for 2 reasons: To save time on both halves. That is, the designer is designing his/her piece without worry of the difficulty, and the programmer is designing the framework without worry of user intuitiveness and style. It so often occurs that the designer and the programmer have slightly different ways of thinking. Each party has separate concerns for the final product, and each half should be individually thinking about the future of their work and how each can be maintained. This article may certainly apply to, and almost addresses, a programmer without a sense of concern for the user's experience and general usability. As a front-end designer, I need the mockup process for my own sake even more than for the sake of the final product. Personally speaking, if I were to attempt complex mockups without first laying out a grid and carefully choosing my color palette, I would quickly be overcome with the duties of writing the code, and the hundreds of short-term problem solving that would arrive. My passion is never to become a flawless programmer, but it is to flawlessly design an intuitive interface. When I am creating a mockup in photoshop, what I'm doing in my head is pretending. I imagine over and over again that I am a first time user to the site, and maybe even to the internet. This duty is daunting enough without having concern over how I will make it work. Again, this article may whisper sweet nothings to a programmer on a tight schedule, but I can guarantee you that the time to simply layout a grid and pretend will save you the time it takes to just load the monster application. And I don't know about you, but I cannot imagine a site's usability on a simple piece of paper. |
For a developer, making a HTML/CSS mockup is the same kind of pretending that you're talking about. They think in HTML/CSS terms natively. It requires extra thought for them to do a mock-up in Photoshop.