In an Agile process, sometimes there’s very little time to front load a project with an in depth UX design process. Sprints happen so rapidly, there’s often little time to fit an entire UX development cycle of sketching, wireframing, user stories, user testing, etc…and its associated multiple iterations. So what to do?
Well, here at Methink, we rely heavily on HTML wireframes (a.k.a. hi-fi wireframes, HTML prototypes, HTML mockups, etc). There are many benefits we find in taking the extra effort to produce these, which is probably best summed up in this article, “HTML Wireframes and Prototypes: All Gain and No Pain” from Boxes and Arrows. Many of the benefits we find with producing HTML wireframes are basically all listed in the article, and in an Agile environment, those benefits are even more pronounced.
Producing HTML wireframes & prototypes really brings the development team as close as possible to the end product. It helps disqualify poor ideas, and qualify ideas that work…especially if the wireframes can show user flow and page flow. It does not cost a lot of money and time to change HTML wireframes (if you’re working with good developers). Users can actually start to touch, test, and play with HTML wireframes, whereas sketches, Visio, and Photoshop mockups are static in nature. The biggest gain comes when the wireframes get the green light; everything is already in place to implement for back end coding. There’s no transition from paper to computer, no translation from PSD to HTML, many of the CSS styles are already defined, and implementation is immediate because HTML wireframes are usually more defined in scope.
Here at methink, we take it one step further by building out every possible page with HTML wireframes to leave no room for error. The reason we have the ability implement this type of HTML wireframing process is expertise and speed. We’ve adopted this HTML wireframing process for years, and producing these HTML prototypes are almost as quick as sketching out ideas and concepts with pen and paper. While other shops tend to break down this UX process into several steps, we try to merge it into 1 efficient step.
If “a picture paints a thousand words”…HTML wireframes paints millions as far as ROI goes. If your UX development team is NOT providing HTML wireframes, I think it’s valid to question the rationale behind it…or ask if it’s due to an mere technical inability to provide such wireframes.
