Differences between revisions 32 and 33
Revision 32 as of 2011-05-14 23:02:40
Size: 6174
Editor: shoobe01
Comment:
Revision 33 as of 2011-05-14 23:08:10
Size: 6533
Editor: shoobe01
Comment:
Deletions are marked like this. Additions are marked like this.
Line 18: Line 18:
 * Validation Exercises -- Before even starting, perform user interviews, ask the business what they want, and gather any other information about current and expected usage you can. Develop measurable objectives, stick to them during design, and be sure to measure after it launches. Without feedback, you cannot learn.
 * Studio Methods -- The best ideas come from individuals, or small teams, working independently. To get the most good, unique ideas, task those individuals or small teams to develop quick, independent designs and regularly share and regroup, iterating to a final solution.
 * Every Idea is Un-Worthy -- When working with design concepts, from competitors to the design teams above, 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.
 * Collaborate -- Design teams will, ideally, have a variety of individual skillsets, or at least multiple individuals, each with their own background and opinions. Use the individual skills of the team members to find solutions and explore concepts.
 * Seek Outside Opinion
-- It is always good to get input from various teams, outside of design. You do not know everything, about the business, the industry, or the customers. Someone else in the organization might, though. Ask them.
 * '''Validation Exercises''' -- Before even starting, perform user interviews, ask the business what they want, and gather any other information about current and expected usage you can. Develop measurable objectives, stick to them during design, and be sure to measure after it launches. Without feedback, you cannot learn.
 * '''Studio Methods''' -- The best ideas come from individuals, or small teams, working independently. To get the most good, unique ideas, task those individuals or small teams to develop quick, independent designs and regularly share and regroup, iterating to a final solution.
 * '''Every Idea is Un-Worthy''' -- When working with design concepts, from competitors to the design teams above, 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 concepting exercises, 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.
 * '''Colla
borate''' -- Design teams will, ideally, have a variety of individual skillsets, or at least multiple individuals, each with their 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 k
nowledge of the arbitrarily complex systems we work on all too much, so cross-functional collaboration can have great value in confirming concepts, getting input on the viability of concepts, and discovering tangential solutions already considered or in progress somewhere else.

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

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 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, satisfaction is within norms. But it can very easily be boring. And often only solves that specific issue, so might have to be completely thrown away for the next version.

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. 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 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 that direction and are worth considering for your design process:

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

  • Studio Methods -- The best ideas come from individuals, or small teams, working independently. To get the most good, unique ideas, task those individuals or small teams to develop quick, independent designs and regularly share and regroup, iterating to a final solution.

  • Every Idea is Un-Worthy -- When working with design concepts, from competitors to the design teams above, 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 concepting exercises, 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 skillsets, or at least multiple individuals, each with their 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 concepts, getting input on the viability of concepts, and discovering tangential solutions already considered or in progress somewhere else.

User-Centric Execution

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

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:

  • 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 on this from the start so your budget accounts for it.

  • Assure 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 that 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 everyone 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, 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 development process. Sometimes this is just called "modular re-use," or other things, 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 re-used over and over in common templates.

  • Design with polymorphism -- This is a subset of the previous one, but is harder for some organizations and designers to grasp, so has been broken out. If there are several variations of an on-screen module you design, make sure you express them as variations of each other so these are clear. Of course, if there is only one variant (omnimorphism) then that should be explicitly stated as well. Always keep in mind efficiency and re-use.

None of these processes should be burdensome, but should instead make for a much more efficient method in which to develop, and assure that everyone on the team works hand in hand, at every level.

Next: Principles of Mobile Design

Successfully Designing with Patterns and Heuristics (last edited 2013-04-08 20:02:22 by shoobe01)