| Great writing. But as someone who also came from a different design field, I'm not sure it's obvious to new designers where and what they should start learning. It would have been great if the author had identified tools for a replacement workflow (though I'm sure Treehouse must get more into that elsewhere on their site). I came into the world of UX and UI design by way of architecture, and it was quite a while until I found tools that really made a sensible workflow: • Dot grid paper, index cards, pencil, and scanner for sketching & wireframing or paper prototyping (white boards too of course) • Fireworks, Photoshop, and/or Sketch for creating graphic assets or the occasional mockup • HAML for generating HTML • SASS & COMPASS for creating CSS • Foundation as a CSS framework for prototyping • Sublime Text with Emmet(Zen Coding) • Live Reload running on browsers in another monitor • Git & Github to get things on the development server My web developer partner and I sometimes refer to this as the "designer's stack". [Edited for clarity] |
The prototype should be just that - a prototype to be thrown away after starting the product - it should not be used to translate to another medium, or as a final spec sheet which is frozen and cannot be modified during implementation. What you use to prototype doesn't matter - it could be on paper, grid paper, photoshop, HTML, whatever gets it done quickest for you and keeps the client happy. I find sketching on paper then HTML pretty good for prototyping, but whatever works.
Directly translating a static image to HTML leads to a couple of big problems - it encourages an artificial separation between design (which should be how it works, not just how it looks) and development, and it encourages the designer to imagine that their styles will survive contact with the medium and the content (they won't without modification).