Fri, Sep 16, 2005
Comparing deliverables (static vs. HTML wireframes)
Trying to elucidate why I prefer paper wireframes to HTML wireframes, I came up with a diagram that helps explain why someone would choose one or the other (or both!).
Trying to elucidate why I prefer paper wireframes to HTML wireframes, I came up with a diagram that helps explain why someone would choose one or the other (or both!).
In my practice, I don’t call them “HTML wireframes”. Semantic, valid pages are skinned with a very basic stylesheet that works more to improve readability during testing. To me they’re more like rough mock-ups than wireframes. At that stage, the layout has already been roughly determined by paper wireframes and is a matter of production.
I use basic HTML wireframes for testing application functionality. I dislike using them to iterate because it’s easier (for me) to poke at mock widgets in a drawing program. Or, as is more often the case, it’s much, much easier to iterate through rough sketches on paper. I like paper because iteration is cheaper and notation is easier.
You can view the comparison up close in your browser (68k Flashpaper file, or you can check it out in a 72k PDF).
Fans of HTML wireframes seem to like them because they more closely resembly the final product. They function like low resolution prototypes where one can test not only application functionality, but also user interaction. Additionally, HTML wireframes are accessible to a wider audience, allowing IAs to speak directly with front-end developers using their native language, as well as clearer communication with other business units: a grey-scale version of the website is a more concrete focus for communication than more abstract drawings on paper.
The drawbacks are that HTML wireframes make it more difficult to quickly iterate through designs, and more difficult to notate.
I think I’ll stick with paper for iteration, and drawn wireframes to document design decisions. However, I do think I will replace my rough development stylesheet with something more “wireframey” so I can not only test application functionality, but also test basic interaction, and communicate more effectively with other business units.
Talk About "Comparing deliverables (static vs. HTML wireframes)"