As we just discussed, patterns are often misapplied and used as rote answers to problems. Or they are specifically rejected because they are perceived as having to work in a certain way, and so stifle creativity.

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

Avoiding the Heuristic Solution

Good, well-intentioned practitioners of interactive design, like you, apply well-established principles, procedures, and processes in an attempt to seek the right solution.

We all perform heuristic evaluations, apply patterns, copy best practices (or at least “common practices”), and — whenever possible — perform user research to confirm the design is good. Without inspiration or luck, all too often the end design is what could be called the “heuristic solution”—the rote, safe answer is the default result.

And very often this is fine, strictly speaking. There are no serious errors, and satisfaction is within norms. But have you ever found a design to be boring? Or that it only solves that specific issue, so you end up redesigning it for the next version?

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. Mobile especially is very competitive and has strong drivers for differentiation of your products in the market.

To develop interfaces that delight like this — or must entice users to revisit or share — requires using patterns and best practices as just one input into the design process. The product must be understood holistically, and design options must be developed tangentially in order to discover the multiple ways to approach the solution.

While there is no single method or movement to achieve better results, here are a few concepts which lead in that direction and are worth considering for your design process:

• Conduct validation exercises -- Before you even start, perform user interviews, ask the business what they want, and gather any other information about current and expected usage that you can gather. Develop measurable objectives, stick to them during design, and be sure to measure them after the product launches. Without feedback, you cannot learn.

• Use studio methods -- The best ideas come from individuals or small teams working independently. To get the greatest number of good, unique ideas, task those individuals or small teams to develop quick, independent designs and regularly share and regroup, iterating to a final solution.

• Realize that every idea is unworthy -- When working with design concepts, from competitors to the design teams just men- tioned, remember to approach the design from a modular point of view, and evaluate the suitability of each element to the overall goals and process. Do not just accept (or reject) whole designs.

• Embrace your Constraints -- Whether in conceptual exercises, during workshops, or as individual designers, only work within the domain, set preconditions, and remind everyone that the goals and objectives define the desired end state.

• Collaborate -- Design teams will, ideally, have a variety of individual skill sets, or at least multiple individuals that each has her own background and opinions. Use the individual skills of the team members to find solutions and explore concepts.

• Seek Outside Opinion -- Not everyone has all knowledge of the arbitrarily complex systems we work on all too much, so cross-functional collaboration can have great value in confirming con- cepts, getting input on the viability of concepts, and discovering tangential solutions already considered or in progress somewhere else.

Using User-Centric Execution Principles

The other key problem with interactive design is actually getting the product built. To us, this is the new, more critical “gulf of execution” and the most important problem across the practices of user experience and interactive design.

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

To encourage successful execution or implementation, UX teams should:

• Never walk away -- Always stick with the project through development, at least making yourself available for questions, rework, changes, and testing. Ideally, become integrated into the team, and attend daily meetings, test planning, and so on. Plan to do this from the start so that your budget accounts for it.

• Ensure that goals are for everyone -- The business and user goals you should have developed at the beginning of the project must be translated into actual, measurable metrics. Make sure the whole organization has these goals as their top drivers, instead of cost savings, efficiency of developers, or other internal measures. While “we’re building for the end user” may not resonate, remind the team that they work for the larger company, not just their department. You may also have to push to include the analytical tools to make sure they get built and are not forgotten.

• Use object-oriented principles when discussing and delivering -- The efficiencies and enforcement of consistency that componentized, object-oriented practice emphasizes in design are just as valuable to software developers and the development process. Sometimes this is just called “modular reuse” or something similar, as “object-oriented” is a larger set of principles. But the core concept is the same. Instead of designing every detail for every state, and building by state or building hundreds of items to bolt together, a few dozen modules are built and reused over and over in common templates.

• Design with polymorphism -- This is a subset of the preceding item in the list, but it is harder for some organiza- tions and designers to grasp, so we’ve broken it out. If there are several variations of an on-screen module you design, make sure you express them as variations of one another so that they are clear. Of course, if there is only one variant (omnimorphism), it should be explicitly stated as well. Always keep efficiency and reuse in mind.

You should not find any of these processes to be burdensome. They should instead make for a much more efficient method in which to develop, and ensure that everyone on the team works hand in hand, at every level.

It is also important to keep this in mind even if you are a developer. Make sure you do not fall into developer traps, and keep yourself true to the design principles.

Patterns are a reference, and a starting point for design. Use them carefully to avoid being overly constrained, and use the principles of modular design to efficiently communicate and build the end product.

Next: Principles of Mobile Design

Discuss & Add

Learn More About This Topic

Avoiding the heuristic solution is a part of a presentation I have posted here: http://www.slideshare.net/shoobe01/avoiding-the-heuristic-solution-creating-inspiring-mobile-design-with-ux-principles

And I will be doing another O'Reilly Webcast in January (I think) entirely on this topic. Prepare your questions and keep your eyes open for it.

The "Gulf of Execution"

This actually means something else. Don Norman came up with it to mean the gap between user goals and their inability to perform it. The classic example is trying to program the clock on your VCR. If you are old enough to know what a VCR is. Important enough concept that it has a wikipedia page: http://en.wikipedia.org/wiki/Gulf_of_execution But it's old-school HCI/HF, so no one knows. I was mean and repurposed it, but I did so intentionally so I'm clever, right?

Examples

If you want to add examples (and we occasionally do also) add them here.

Make a new section

Just like this. If, for example, you want to argue about the differences between, say, Tidwell's Vertical Stack, and our general concept of the List, then add a section to discuss. If we're successful, we'll get to make a new edition and will take all these discussions into account.