|
Size: 14054
Comment:
|
Size: 6174
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 7: | Line 7: |
| 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. | Good, well-intentioned practitioners of interactive design like you apply well-established principles, procedures and processes in an attempt to seek the right solution. |
| Line 9: | Line 9: |
| 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. | 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. |
| Line 11: | Line 11: |
| 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. | 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. |
| Line 13: | Line 13: |
| To develop interfaces that must delight, 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. | 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. |
| Line 15: | Line 15: |
| 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: * '''Reactionary''' - Solutions are sought to specific problems, and are solved within their specific domain, instead of reconsidering the entire process. * '''Single view''' - ...design for one screen at a time, or one device at a time. other screens, or the same application on a device with different resolution is totally different. Worse, is that it is totally identical, but doesn't fit either the space or the method of operation... * '''First solutions''' - There is no incentive to find the best possible solution. As soon as a solution is found that meets the needs, * '''Rote solutions''' - There is no incentive to find unique, interesting or differentiable solutions, so the heuristic solution will always be used. When a client (or user needs) demand something different, there is no method to explore what this means, so any differentiation will do. This usually results in copying the latest trend, often in visual design along. * '''High-level''' - Insufficient detail is specified, and reasoning behind design is jargon-laden or requires a background in UX or HCI. Visual designers and developers working on the design subsequently will not understand which position or process relationships are important, so will change them to suit immediate needs, potentially ruining the overall experience. |
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. |
| Line 22: | Line 17: |
| This is not just at the level of the IA or the UX designer, but across the industry. If your company gets a (very useful) customer satisfaction survey from the leading vendors, they also perform a heuristic evaluation, and suggest ways to fix, including screenshots of competitors who have a good pattern. This seems great, but the product owners who see this say "now there's no need to think, explore and do user research to figure out which of these three options is right." That's an actual quote I've heard lately. In any case, it takes exceptional effort by individuals -- and a fair bit of 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 for some teams, some projects, and some phases of most projects, independent work is difficult. Certain information should be either discovered in advance, or developed as a team. Information architecture (the "sitemap" and process flows) usually has to be done as a collaborative exercise, with one of these guiding everyone, and every team. The interaction and interface design then can be allowed to explore a variety of solutions. === 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. === Collaborate === Collaboration best employs the skills and knowledge of each individual. 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. Each member should contribute as they know best, but be aware of what they know. Explanations of contributions and decisions must be forthcoming, so the upsides and downsides of each option can be understood by the rest of the team. Trust is the only way to make everyone believe in a decision and keep working collaboratively. For any team, a good leader is key. Even for ad hoc collaboration, someone should clearly be the lead designer. For larger, and more permanent teams of any sort, a dedicated team lead is best. === Seek Outside Opinion === It is always good to get input from various teams, but brainstorming -- at least as generally practiced -- does not work. To the degree there's not much point in discussing the right way to get it to work. There are better methods to generate ideas, as discussed above. But 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. Make sure sessions are run well, in order to get useful information and not waste the time of the participants. Use collaborative techniques, and invite a representative from every facet of the business you can get ahold of. Only perform these 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. Then once everyone leaves, gather the design team up and evaluate the results. Many of the same techniques used for studio evaluations are useful for the output of larger collaboration sessions. Evaluate every idea, including the clearly dumb ones; there may be a clever nugget in there that can be used. |
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. * 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. |
| Line 72: | Line 26: |
| 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. | 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. |
| Line 77: | Line 31: |
| * '''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. |
* '''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. |
| Line 82: | Line 36: |
| 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: {{attachment: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: {{attachment:Intro-eReadSpec.png}} And when the iteration was complete, and we all saw it demonstrated, it looked like this: {{attachment: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. |
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. |
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.
- 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.
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.