Keith Sherwood — Tue, 25 Nov 2008 16:45:29 GMT

Great article! I like to be flexible and use the right type of prototyping for the task at hand, but, with that said, I’ve used XHTML prototyping for my last few projects and the practice has definitely paid off in terms of efficiency and speed.

I’m the sole UX designer in my development shop, and while we have developers who understand markup and CSS, the largest portion of XHTML, JavaScript, and CSS work usually falls to me. Because of having to wear multiple hats of designer, lead, and trench-coder, I find that prototyping in XHTML helps me combine project phases and alleviate bottlenecks (not to mention that there isn’t a graphic design department to hand my sketches to).

The best two aspects for me would definitely be code reuse and catching “gotchas”. Having the actual markup ready by the time the prototype gets the “OK”, with maybe a few small tweaks, has increased our team’s efficiency. I’ve been able to pass the prototype on to other developers, with very little training or question answering after the fact. I don’t want to say that it enables “cut and paste” development, but there is definitely a lower learning curve for everyone.

Also, getting to see how realistic a design is in a browser, rather than Illustrator, is a huge benefit and helps us get out in front of possible issues much earlier in the development cycle. I shudder to think at how many pie-in-the-sky faux interfaces were approved in my department a few years ago, only to find that parts of them would take an inordinate amount of hours to pull off. On the flip side, having a realistic prototype that people can actually “click on” has given prototypes more of a “wow” factor than before—an idea that challenges my former love for the static graphic prototype.

Boxes and Arrows: Comments by Keith Sherwood