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.

A UX Manifesto – Presented

This last Friday I had the honor of presenting the keynote for the Tulsa TechFest 2012.  Very well-organized event considering its size–good job to all the organizers and volunteers!

My talk was a talkified version of my recent “UX for Devs Manifesto” blog I wrote earlier this year. It was nice to get it out and share the ideas in person. It seemed to be well received.

Anyways, I said I’d post the slides and a few related resources, so here ya go.

[Original KeynotePPT | PDF ] <– These have notes

In my talk, I referenced a few resources:

Did I forget something?  Let me know!  Also, check out my UX Book List for some recommended books.

What’s Up with UX Design Patterns?

Over there on on the User Experience group on LinkedIn, there is a loong thread cataloguing existing UX/UI design pattern repositories.  Recently, a few folks have been asking, “so what’s up with these UX design patterns, anyways?”

Given that I’ve had a lot of experience with design patterns, both in software architecture and, more extensively, with UX/UI design patterns in my work on Infragistics’ free UX/UI design pattern explorer and design tool, Quince, I thought I’d offer some food for thought.  I put most of the following as a comment there, but I figured making it more top-level in this post would help.  Hope it helps you out. Feel free to ask questions/comment if you want! 🙂

Design Patterns have a very well-defined, long-lived meaning. As Steven H (another commenter) noted, we inherited the formal denotation first from physical-world architecture via Christopher Alexander and, indirectly, through software architecture. They are not just a new word for an old thing…

Using a pattern does not mean you are copying someone’s work. Design patterns are not algorithms, templates, or rote repeatable solutions. Design patterns rely on context heavily, both to validate that they are applicable and to inform the concrete design. That’s why it’s important to understand not just the problem that they solve and not just the solution (and certainly not to simply copy examples of it), but also the context and rationale behind them.

Like many things, design patterns are a tool, and they are not always applicable or even helpful. To effectively leverage them, you first need to understand what they are and when they are applicable.

In the end, design patterns are there, and you use them whether or not you acknowledge them formally. Every time you use a textbox in a UI, you’re using a pattern. Every time you use a drop down, you’re using a pattern. When you put a search box in the top right area of your app, you’re using a pattern. The list goes on and on and on (check out Quince for more examples, or any of the other design pattern repositories).

Where it can help to formally recognize them is to make you a more informed and cognizant designer, so you can better choose when to leverage which patterns. They can also help to form a common vocabulary to enhance team communication, and they can be building blocks for any particular design language. Personally, I think they are indispensable in a designers’ toolkit. At the very least, they make you more aware of and able to articulate the rationale behind your designs, which is crucial in arriving at the best possible design.

Interaction Design Is Creative and Synthetic

The UX Honeycomb

A while back, I was reading this post over at Optimal Usability about the gaps between interaction designers (IxDs) and visual designers (VDs). I am director of Design at Infragistics, which in practice means that both visual design and interaction design report to me (along with something we call “developer interaction design”).  Our core business for about 20 some odd years has been making reusable UI components and tools for developers. A few years ago, we started to diversify with designer tools, such as Quince and Quince Pro, and we are working on some other nifty stuff focused on helping designers, so we tend to think about them a lot, in addition to our own practice internally.

A lot of what Adeline says rings true for me as well–there is definitely a distinction in perspective and modes of thinking between IxDs and VDs. And in terms of not totally compartmentalizing design disciplines, of course, that makes sense.  Cooper advocated something similar back in 2008 and has been on the road with that “unified design” concept for some time.

But I have noticed what seems to me to be something of an unfortunate trend, and that is the tendency to characterize interaction design as an analytical and systematic discipline focused solely on optimizing for the user (basic usability and task completion concerns) while tossing, it seems, all aesthetic, business, and other considerations into the domain of other folks. The solution advocated, then, becomes something to the tune of “let’s involve everybody throughout the design process to ensure all of these concerns are represented.”

Involve Everybody!
In the article on Cooper referenced above, the proposition for this is in part based on a concern about apparent power struggles over the design itself.  Exemplifying a possible dispute about information density in which the IxD cites research, they say, “If the visual designer has no direct experience with that research, where does the conversation go from here?”

Again, the proposed solution is that all of the design disciplines should be involved in research so they all, in theory, can use “research” to beat each other over the head with when disagreements arise.  One key problem with this, though, is that more often than not, you’re dealing with interpretations of research.  So even if both parties are involved, they will still argue based on their interpretations and prejudices (in the absence of ever elusive definitive data to resolve things).

At Infragistics, we hear the same concerns, coming not just from visual designers but also from developers/engineers. The problem I see is that research, in these discussions, tends to be seen more as a tool to used in disagreements over designs to support “my” opinion on the right design direction. People at this point tend to look at it through the eye of proving their point rather than considering it all holistically as input. Exploratory research, on its own, can rarely be used to support this or that particular design choice, so it’s usually an exercise in futility anyways. If you want that sort of information, you typically need to do focused A/B testing, and be very careful about how you frame the tests.

More to the point, interaction designers are trained and practiced in looking at research holistically, and letting the data speak for itself. It takes practice to separate yourself and your opinions from the data, and often those not practiced in this are only too quick to latch onto the data that seems to support their preconceived notions and to minimize or ignore what doesn’t. I’m not saying IxDs are never biased, but the point is that this is part of the IxD discipline, and it takes practice and conscious effort–things that other disciplines either aren’t interested in investing in or can’t due to other demands on their time.

And that brings me to the broader concern about involving everybody in research–except on small, startup-sized teams, it seems to me to be impractical and, in the business owner’s eyes, expensive. Especially so if your teams are geographically distributed. Not only that, as your teams grow, involving them all can seriously intimidate the research subjects, which screws up the data.

One suggestion to deal with this is to have the other team members only go to this or that research session. But that seems potentially worse because those team members will come away with skewed ideas, basing their notions on isolated bits of the research instead of the research holistically. And if they’re not trained and practiced in research (as most other team members are not), it’s all too easy for them to build up such skewed notions, and later to use them as weapons in design discussions–they know enough to be dangerous but not enough to be effective in terms of informing design directions.

On the other hand, I heartily agree that interaction designers should be involved in research as much as possible; ideally I’d even say they are the primary participant, with the design researchers (if such a specialty exists for a team) facilitating and executing research sessions and compiling the research for later reference. The IxD, in orgs without dedicated research teams, should be the folks who take over the researcher’s tasks. Of course, they won’t be able to do it as thoroughly as dedicated researchers, but they are the natural fit due to training and what is required of them to fill that gap as best they can.

It is the IxD’s job to take this research, to understand it, and most importantly to synthesize it into a holistic, coherent interaction design. That, I repeat, is the primary activity for IxD, and as such, the designs they produce should normally sufficiently embody and reflect the research so that it is not necessary for everyone to be involved in the research. The interaction design itself should speak for the research.

The other product disciplines need to trust that the IxD is doing her job. That doesn’t by any stretch mean that designs should never be questioned–quite the contrary, the more a design is put under fire, the stronger it should become. But if the IxD listens to the concerns and suggestions, can explain the rationale, and ultimately says, citing research if applicable, that this is the right design direction, then that decision should be respected as part and parcel of the IxD’s role and responsibility on the product team. It’s quite possible they could change the design in response to their peers’ criticism–I hope they would if the suggestion makes the design better. But this idea of getting everyone involved in the research so that everyone can leverage their interpretations of it to push the design in the direction they prefer is just unhealthy and can quite simply stall out forward momentum on the product. Design by committee is a sure recipe for disaster.

We’re Both Designers
The article on Optimal seems to imply that in order to get “lateral thinking” and thinking outside the box (“challenging conventions”), you really need to engage the VD. They also identify that the VD “has absolutely no input or access to the project until the wireframes are handed over” as a problem.  They say that IxDs are “great at models that work well for users” and testing them.  In the end, they, too, advocate plugging in folks throughout the process.

Now, first let me say that I 100% agree that collaboration and good communication between the various product disciplines is essential to great products. It seems almost axiomatic. And I might even be inclined to agree that good VDs tend to be more aesthetically oriented and good IxDs tend to be more analytically capable. I’d go further in agreeing that simply handing off annotated wireframes to a VD and washing your hands of it is a Bad Idea. But I don’t agree that the reason to involve VDs in the IxD process is that they are more creative/lateral thinkers.

While it may be true that the focus of interaction design is optimizing designs for human interaction and that visual design is focused on, particularly, visual aesthetics and the related communication (and even rhetoric), the people serving in either of these capacities are still (normally) designers. That is, they share a common way of thinking about problems–from the human perspective–and they both need to be thinking creatively about the design.

It is possible to dissect and consider the human perspective as its elements, but as we all know, people experience them together.  (And that is largely the reason these design disciplines have to coordinate.)  And while it is possible to dissect experience for the purpose of reasoning about it and engaging specialized skills and talents, that doesn’t mean that people who focus on this or that element are incapable of considering the other elements.  Nor does it mean they are incapable of considering other non-human-focused constraints.

If that were true, why would we specialize?  We do so because there are special skills and effort that go along with the various discipilnes.  Many people buy into the “T-shaped” skill set idea as valuable, in fact. Be competent across a variety of skills but really good/deep in one.

[rant]I am going on this point because it is tiresome to hear the phrase “creatives” and have it apply to one particular specialty, as if the other disciplines are not creative. Having been a software developer, I can tell you there is a lot of creativity in that discipline as well. So implying that only some (e.g., visual) designers are the “creative” ones, the ones who can think “laterally” and “challenge conventions” and so on is just hogwash. I would even go as far as to say they are not (as a group) any better or worse at this.  I’ve reviewed many a portfolio and worked with many VDs, and they can follow the crowd just as well as the next guy.  (In fact, that’s what being “fashionable” is all about.)[/rant]

Just so, interaction designers are creative. To do good interaction design, they must think creatively, laterally, and yes, challenge conventional notions. This is especially true when “redesigning” an existing solution or when considering a design in light of existing competition.  They must consider aesthetic elements, including especially that of the aesthetics of interaction.  They must account for brand identity, the “personality” of the app, the content, and the business constraints in their design. It’s my opinion that they should be the role that owns unifying all of these elements, even if they do not personally execute on all of them.  To pretend that brand can be addressed through visual design alone is anything but unified design.

And while interaction design necessarily involves more analytical capability, the best interaction designers also have a talent for aesthetics and, most importantly, synthesis.  Interaction design is not the sum of its methodologies; you can give the same design challenge and tool set to two different IxDs, and they will produce distinctly different designs.  There is, what I like to call, a “Design spark” that you can see (and as a hiring manager, need to look for). IxDs need to be able to analyze and reason through all the various inputs into the design process (business/stakeholder considerations, user considerations, and medium/technology constraints and capabilities) and then synthesize those into design solutions.

And yet it remains that there is a distinct talent in visual design that is not necessary for good interaction design. Unlike some of my contemporaries, I do not denigrate this talent by implying that it’s “just styling” or “lipstick” or “dressing it up.”  In addition to simply being able to effectively manipulate visual design tools (which take time to become skillful with), there is a particular talent when paired with the craft’s skill that makes or breaks good visual design. It is not creativity. It is a sense of balance, harmony, appropriateness, and beauty, and being able to express and enhance this through visual artifacts. Some visual designers can also extend this sense–this talent–into other media and other elements of experience as well (such as motion design, which is integral with visual design).

Visual design is both highly skilled and talent driven, and high quality visual design can make a huge difference in any given unified design.  But even so, a visual design necessarily accounts for only part of the human experience.  And that is OK. It has sufficient value and requires sufficient skill and talent to stand on its own–everybody doesn’t need to be concerned with everything.

I am saying all this to shore up that visual design does indeed stand alone as a distinct and valuable competency–without having to dilute it and stretch it into other areas of specialization or having to carve out their specialty as being “creative.” Both IxD and VD are design disciplines. At their best, both require lateral thinking and challenging conventions. That’s not the essential difference between them nor their distinctive values that they bring to a product.

Yes, they do absolutely need to integrate and communicate, and by and large, I agree with what the Optimal article proposes. When possible, looping in VDs during IxD conceptualization and later even during critique can help, and vice-versa–IxDs can and should participate in the VDs conceptualization and iteration. But this is because they are both designers, and having more trained and talented design brains contributing during ideation and critique tends to result in more alternative exploration and more critical input into the synthesis process. That can only be a good thing.