I just ran across Ditch Traditional Wireframes in UX Mag. I agree with the basic premise–that static, especially high fidelity, wireframes should be eschewed, but the conclusion I draw about what to do instead is a bit different.
The author of that article, Sergio Nouvel, propounds the wonders of just jumping right into code by doing HTML-based prototyping after nailing down initial concepts with other low fidelity options. The problem is that Nouvel does not identify the drawbacks from such an approach:
1) Despite the relative ease that frameworks like Bootstrap and Foundation provide, jumping into code has the immediate effect of warping the designer’s mind. I don’t care how disciplined you are, when you start dealing with code, your brain is forced to start thinking from the code perspective. It is not acceptable to switch at the interaction prototyping phase from a human-centric focus to a code-centric focus.
3) It forces the designer to learn to code. That is a double-edged sword, as I discussed not long ago in To Code or Not to Code.
4) To be truly easy to maintain and change takes a LOT of planning up front. Even developers struggle with this, and they’re all about reuse and minimizing effort for changes. To pretend that just using code means things are automatically easy to maintain is just wishful thinking. Sure, maybe changing a font color, but changing shared navigation, layouts, etc.–things that are far more pertinent to rapid design iteration–are not easy changes in code. At all.
5) Interaction prototyping is not the same thing as production coding. To pretend that the code a designer writes in a prototype is going to be good for the real product misses several key considerations:
- Devs are notorious for being picky, and rightly so, about their code (see the last point about code reuse). The chances they’ll just run with prototype code are quite slim, especially if that code relies on prototyping frameworks.
- The focus of a good interaction prototype should be the interactions, not to have clean, well-layered/encapsulated/maintainable production code. If you use code for prototyping to have “build the real thing,” you’re missing the point of interaction prototyping.
- Using HTML prototype code as production code only applies, and only sometimes, for Web apps, and simple ones at that.
- What about statefulness and data? Are you really going to spend time on that in your prototype? Anything beyond a basic informational Web site needs this sort of thing.
6) Worrying about responsive design at the interaction prototyping phase is premature. We’re in the higher point of the hype cycle for responsive design. Yes, it is nifty for some design needs. But it is hardly a panacea, and more importantly, it (like code or tech) should not be the big thing you’re worried about when doing interaction prototyping. Why? Because from a user experience point of view, it’s just not that important. Many of your users will never know if your site is responsive, and very few will care, as long as they get what they want from you.
7) How are you going to share your prototypes? Using HTML means you’re going to need to secure a hosting place, deploy it, and ensure it is accessible for people. And you have to keep updating that. One more thing you have to learn to jack with just to get some design ideas fleshed out and tested, one more thing in your way when you should be simply focused on exploring and evaluating design concepts from a human perspective.
So what should you do instead of static wireframing? Why interactive prototyping, of course! Before you shake your head and say it is too hard or too cumbersome, I suggest you try Indigo Studio. Full disclosure: I had a hand in making it, but the reason we made it is because we think it addresses some real needs, such as:
- The need for rapid exploration of design ideas from a user-centric perspective.
- Being able to do rich interactions and animations without worrying about code or learning to code.
- Integrating stories and human contexts into your digital design.
And guess what, Version 1 is totally free, forever. There is no obligation, no time bomb. So yes, definitely, ditch traditional wireframing, but not for code. It is good for some needs, but when you’re doing interaction prototyping and design exploration, that’s not the time to saddle yourself with all those ancillary concerns.
Give Indigo Studio a Try! I recommend watching the videos–they give a good idea about how Indigo Studio is different and tries to address these needs.