Yes, Ditch Traditional Wireframes, But Not for Code

Just Say No To CodeI 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.

2) Especially in non-WYSIWYG environments, you are forced into imagining what tweaking this bit of markup, CSS, or JavaScript will have, then you do it, and then you verify it. And you often find it’s not quite what you had in mind, and repeat. With that, you end up wasting a little time here, a little time there, a little time everywhere fighting with the technologies just to do the simplest things.

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.

Advertisements

3 thoughts on “Yes, Ditch Traditional Wireframes, But Not for Code

  1. “jumping into code has the immediate effect of warping the designer’s mind.”

    So what? The delivered solution will ultimately be some sort of compromise between what’s best for code and what’s bets for the user. Isn’t it best for the user to have a designer perform that compromise rather than having a developer do it? It’s foolish and useless for a designer to keep a “pure, unwarped mind” while designing. If that’s how they’re designing, throw their design away and start over.

    1. This: “It is not acceptable to switch at the interaction prototyping phase from a human-centric focus to a code-centric focus.”

      There is a time and place for everything. More importantly, coding and everything that goes with it is a distraction from discovering the optimal design *for the user*. Once you know what that is, *then* you can, if technology feasibility demands, back off from that to find a good enough compromise.

      I never said the word “pure.” It’s not as if I am suggesting the designer doesn’t need to have familiarity with technology constraints–he absolutely should have ideas of the capabilities and limitations *at a conceptual level*. But coding a prototype is far beyond that–it is asking the designer to become enmeshed in *how* to make the technology form according to his design, while the designer should be focused on what is optimal for the user. I even dispute that a designer ever *has* to know how to code to be a high-quality, effective designer (http://www.infragistics.com/community/blogs/ambrose_little/archive/2012/06/26/to-code-or-not-to-code.aspx).

      Further, I think it’s actually better for the designer and developer *to work together*, if it comes to needing to find some compromise. The dev is the expert coder; the dev will almost always be better able to determine if a desired design is feasible or not, and then to implement it or even, as has often been the case in my experience, to suggest a good workable alternative that the designer can possibly tweak/enhance with the dev.

      At the end of the day, this doesn’t have to be an either or question. Start doing prototypes in lower fidelity media like sketching and Indigo to explore, iterate, and synthesize. Then if you feel the need for further validation, that could be a good time to do a coded prototype.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s