As discussed above, patterns are often mis-applied, and used as rote answers to problems. Or, they are specifically rejected because they are perceived as having to work like this, so stifle creativity.

While neither of these are true, the next problem with best practices is more insidious.

Avoiding the Heuristic Solution

Have you noticed how many fake-stucco stripmalls there are in the suburbs, or wondered why? Because they work well enough. There's no effort involved in deciding if the style or function matches the area, the audience or the businesses, but there's some assurance it will work enough for any locale.

Interactive design is much the same. We perform heuristic evaluations, apply patterns, copy best practices (or worse, common practice that has the current buzz) and design what I call the "heuristic solution." And very often this is fine, strictly speaking. There are no serious errors, satisfaction is within norms. But it's boring. And often only solves that specific issue, so must be completely thrown away for version 2.

This is indeed sometimes marginally acceptable. Call center portals probably work fine like this. Or trouble reporting forms, or other processes that don't need to stretch very much and don't expect a lot of attention for subsequent releases soon. But a lot of demands are (and should be) placed on interactive designers to meet the brand, to find and meet the users greater goals and to differentiate from an ocean of interactive products competing for attention.

Within the context of interactive design, even processes that are supposed to solve this -- such as strict application of user-centered deign or a reliance on use-case and scenarios -- also have the same tendencies:

In any case, it takes exceptional effort by individuals, and good luck to assure that intersting and consistent design emerges from the process. A revision to the process is not yet at hand, but there are procedures which do work to assist in this.

Validation Exercises

Ideally, before even starting the design, you have done user interviews, and gathered information from the business owners as to their needs. From this, you should have things like design objectives, business goals, user goals and so on. At various steps in design, there should be a formal process to evaluate the design against these principles. Occasionally a change will occur that requires violating the objectives or goals. If so, take the time to go back, change the goals and get signoff again. Never shortcut the process and just let "this one thing" slip.

User studies are another way to do this, but must be carefully designed to find useful answers. What improvement or success is being sought? Be careful not to fall into "faster horse" mode, and simply look for lift in differentiation, or reduction in errors, without achieving specific goals.

Studio Methods

The best ideas come from individuals, or small teams, working independently. To get the most good ideas, you need more of these teams. If you have a team of designers, start the design phase of every project by briefing the whole team and tasking them to go off and develop at least one good idea for the final interaction design.

The fidelity of this design is entirely up to individual process. Anything from paper, to technical charting, to high-fidelity wireframes is suitable.

Note that aside from

IA usually has to be done as a collaborative exercise, with one for everyone Info design is in the middle... IxD and visual/interface design are up to individual designers or studio teams...

Every Idea is Un-Worthy

When evaluating those ideas, you must remember not to downselect or upselect, and simply choose a winner. Continue to approach the design from a modular point of view, and evaluate the suitability of each element to the overall goals, and the overall process.

This means that even if everyone loves one of the design proposals best, by far, it cannot be simply accepted. It must be evaluated point by point. And each alternative design must be similarly evaluated. When a "clearly worse" design has a component that is more suitable, you must accept it, at least as input to the final design.

Yes, designers can use their innate skills and sense of design to re-integrate and to coordinate the overall design. Just because components are modular, and originally came from a variety of sources does not mean the design will look muddled and inconsistent. A coordinated interaction design and single interface or visual design is key.

Brainstorming is for Suckers

It is always good to get input from various teams, but brainstorming does not work. This has been known -- in the sense of "scientifically proven" -- since 1958. What works best are individuals working on their own, hence the studio methods above. But not everyone has all knowledge of the arbitrarily complex systems we work on all too much, so collaborative sessions can have value.

Just make sure they are the right kind. Use collaborative techniques, and invite a representative from every facet of the business. And only after you have started the project. If there are no goals and objectives, develop those first (sure, with input from these same groups, but that's not a design session).

Constraints are the key. Only work within the domain, set preconditions and remind everyone that the goals and objectives define the desired end state. Use workshop techniques and moderators from the design teams to guide the discussion, and gather useful information.

XXXXXXXXXXXXX XXXXXXXXXXXXX XXXXXXXXXXXXX

...How using the patterns can lead to better design by re-use consistency. If you pick a pattern, don't just pick it for the screen you are working on, but add to your documentation as a component that anyone can use on any part of the project. Communicate this to development. Then, only one of them is built, and used over and over. Consistent UX, as well as savings on development, QA, etc.

I think perhaps a bit about resolution-independent design, and otherwise class-based design. Can take any design, assign to a few size classes, input classes, etc. and generate from that.

Using these, and following patterns exclusively will result in what I am calling the heuristic solution. Which is fine, and will pass all the checkmarks and get decent test results, but is not going to be differentiable. Which might be fine for some applications, or some parts of an OS or app, but is not so useful for interfaces that must delight, or entice users to revisit. Simply using more gestures, for example, is not automatically delightful. You have to understand the product holistically, and think tangentially about the multiple ways to approach the solution. Note also that these patterns are generally not very prescriptive. Not that they don't require certain behaviors, and prohibit others, but read closer: There are options, and not objects to be implemented but principles upon which your object has to be designed. There's lots of room create something all new, and then divine the underlying truths of the design so pattern level principles can be applied to assure it still meets basic needs and is usable.

ALSO: maybe we should explicitly talk about design at this time. Like, a discussion of NUI being easily taken a step too far. -- If so, riff off this article http://globalmoxie.com/blog/evolution-of-touchscreen-discoverability.shtml And especially this paragraph which is a nice guideline -- added after my gripes :) "I don't mean to suggest that we throw out all of our familiar buttons entirely. Light switches shall remain necessary, after all, and so shall buttons, especially where it's necessary to trigger abstract actions ("share via Twitter," for example). But it's important to recognize those devices for what they are: necessary hacks for moments when direct interaction isn't possible. Touchscreen interfaces allow that direct interaction in many more contexts. As new solutions arise, we should be open to putting our time-tested workarounds aside. When designing an interaction for touch, always ask: do I really need another button or control for this?"

User-Centric Execution

The other key problem with interactive design is actually getting it built. To me, this is the more important "gulf of execution," and the key problem across the practice.

What is needed are principles of what we can call user-centric execution. This is not yet a process, or series of fixed procedures. It is possible it may never be. But like the principles, heuristics and patterns of design, the idea should be followed and there are best practices. First, to principles.

To encourage successfully execution or implementation, UX teams should:

The last two are the most difficult to explain, so an example of this cooperative design/development effort might work better than more discussion. Among the difficulties are the assumption that simply designing like this is enough. But there are key communication and process points that must be coordinated as well.

All through the process of designing this particular eReading platform, the software development teams were in the room or around the corner. They understood, and approved of, the target state. The target, for multiple platforms, was entirely modular. The IA diagram looked like this:

Intro-eReadIA.png

Every view or state listed the elements within, and then the design specifications being built only focused on those re-usable elements, and the minimum amount of information needed to place them, and transition between states.

When the first iteration with UI came up we handed off just the wrapper, and the other few components needed to execute. Elements like this one, with multiple (polymorphic) variations of the same theme:

Intro-eReadSpec.png

And when the iteration was complete, and we all saw it demonstrated, it looked like this:

Intro-eReadCode.png

No, I didn't skip a step and it's all done. The developers bought into the target state so much they just took one of the comps built for a trade show like CES and used it as a backdrop (this was built into the display engine for the demo, so took literally zero minutes). The real components are overlaid on top. And since they are components, that carousel is not just done on this page, but on about 15 pages. And since the design document clearly expressed the polymorphism, there appear to be three different types of carousel, though in fact it's the same one with minor conditional changes.

This is a much more efficient method in which to develop, and makes everyone on the team work hand in hand at every level.

Next: Principles of Mobile Design