CkBooks Online – Free Online Books

GoalDirected Design Model

Underlying the goaldirected approach to design is the premise that product must balance business and engineering concerns with user concerns. You begin by asking, “what do people desire?” then you ask, “of the things people desire, what will sustain a business.” And finally you ask, “Of the things people

desire, that will also sustain the business, what can we build?” a common trap is to focus on technology while losing the sight of viability and desirability.

3. Distributionplan

Understanding the importance of each dimension is only the beginning, which understanding must also be acted upon. We are familiar with this process along the business and technology dimension; you create a business model and then develop a business plan, and similarly create an engineering model and specification. The goaldirected design process is an analog to these planning processes. It results in a solid user model and a comprehensive interaction plan. The user plan determines the probability that customer will adopt a product. The business plan determine the probability that business can sustain itself up to and through launch—and that sale will actually support growth thereafter. And technology plan determines the probability that the product can be made to work and actually deliverable. Multiplying these three factors determines the overall probability that a product will be successful.

A process overview

GoalDirected Design combines techniques of ethnography, stakeholder interviews,

market research, product/literature reviews, detailed user model, scenariobased design, and a core set of interaction principles and patterns. It provides solutions that meet the needs and goals of users, while also addressing business/organizational and technical imperatives. This process can be roughly divided into five phases:

• Research
• Modeling
• Requirements Definition
• Framework Definition
• Refinement

These phases follow the five component activities of interaction design identified by Gillian Crampton Smith and Philip Tabor—understanding, abstracting, structuring, representing, and detailing—with a greater emphasis on modeling user behaviors and defining system behaviors.

Research

The research phase employs ethnographic field study techniques (observation and contextual interviews) to provide qualitative data about potential and/or actual users of the product. It also includes competitive product audits, reviews of market research and technology white papers, as well as oneonone interviews with stakeholders, developers, subject matter experts (SMEs), and technology experts as suits the particular domain. One of the principles out comes of field observation and user interviews are an emergent set of usage patterns—identifiable behaviors that help categorize modes of use of a potential or existing product. These patterns suggest goals and motivations (specific and general desired outcomes of using the product). In business and technical domains, these behavior patterns tend to map to professional roles; for consumer product, they tend to correspond to lifestyle choices. Usage patterns and the goals associated with them drive the creation of personas in the modeling phase. Market search helps select and filter for valid persons that fit corporate business models. Stakeholder interviews, literature reviews, and product audits deepen the designers’ understanding of the domain and elucidate business goals and technical constraints that the design must support.

Modeling

During the modeling phase, usage and workflow patterns discovered through analysis of the field research and interviews are synthesized into domain and user models. Domain models can include information flow and workflow diagrams. User models, or personas, are detailed composite user archetypes that represent distinct groupings of behavior patterns, goals, and motivations observed and identified during the research phase. Personas serves as the main characters in a narrative scenariobased approach to design that iterative generates design concepts in the framework definition phase, provides feedback that enforces design coherence and appropriateness in the refinement phase, and represents a powerful communication tool that helps developers and managers to understand design rationale and to prioritize features based on user needs. In he modeling phase, designers employ a variety of methodological tools to synthesize, differentiate, and prioritize personas, exploring different yupes of goals and mapping personas across ranges of behavior to ensure there are no gaps or duplications. Specific design targets are chosen from the cast of personas through a process of comparing goals and assigning a hierarchy of priority based on how broadly each persona’s goals encompass the goals of other personas. A process of designating persona types determines the amount of influence each persona has on the eventual form and behavior of the design. Possible user persona type designations include:

• Primary: the persona’s needs are sufficiently unique to require a distinct interface form and behavior
• Secondary: primary interface serves the needs of the persona with a minor modification or addition
• Supplement: the persona’s needs are fully satisfied by a primary interface
• Served: the persona is not an actual user of the product, but is indirectly affected by it and its use
• Negative: the persona is created as an explicit, rhetorical example of whom not to design for

Requirements definition

Design methods employed by teams during the requirements definition phase provides the muchneeded connection between user and other models and the framework of the design. This phase employs scenariobased design methods, with the important innovation of focusing the scenarios not on user tasks in the abstract, but first and foremost of meeting the goals and needs of specific user personas. Personas provide and understanding of which tasks are truly important and why, leading to an interface that minimize necessary tasks while maximizing return. Personas become the main characters of these scenarios, and the designers explore the design space via a form of roleplaying. For each interface/primary persona the process of design in the requirements definition phase involves an analysis of persona data and functional needs, prioritized and informed by persona goals, behaviors, and interactions with other personas in various contexts. This analysis is accomplished through an iteratively refined context scenario that start with a “day in the life” of the persona using the product, describing highlevel product touch points, and thereafter successively defining detail at everdeepening levels. As this iteration occurs, both business goals and technical constraints are also considered and balanced with personas goals and needs. The output of this process is a requirements definition that balances user, business, and technical requirements of the design to follow.

Framework definition

In the framework definition phase, teams synthesize an interaction framework by employing two other critical methodological tools in conjunction with context scenarios. The first is a set of general interaction design principles that, like their visual design counterparts, provide guidance in determining appropriate system behavior in a variety of contexts The second critical methodological tool is a set of interaction design patterns that encode general solutions (with variations dependent on context) to classes of previously analyzed problems. These patterns bear close resemblance to the concept of architectural design patterns developed by Christopher Alexander. Interaction design patterns are hierarchically organized and continuously evolve as new contexts arise. Rather than stifling designer creativity, they often provide needed leverage to approach difficult problems with proven design knowledge.

After data and functional needs are described at this high level, they are translated into design elements according to interaction principles and then organized using patterns and principles into design sketches and behavior descriptions. The output of this process is an interaction framework definition, a stable design concept that provides the logical and gross formal structure for the detail to come. Successive iterations of more narrowly focused scenarios provide this detail in ht refinement phase. The approach is often a balance of topdown design and bottomup design.

Refinement

The refinement phase proceeds similarly to the framework definition phase, but with greater focus on task coherence, using key path and validation scenarios focused on storyboarding paths through the interface in high detail. The culmination of the refinement phase is the detailed documentation of the design, a form and behavior specification, delivered in either paper or interactive media as context dictates. Goals, not features, are key to product success Programmers and engineers—people who are intrigued by technology—share a strong tendency to think about products in terms of functions and features. This is only natural, as this is how developers build software: functionbyfunction. The problem is that this is not how users want to use it. The decision about whether a feature should be included in a product shouldn’t rest on its technological understandings. The driving force behind the decision should never be simply that we have the technical capability to do it. The deciding factor should be whether that feature directly, or indirectly, helps to achieve the goals of the user while still meeting the needs of the business. The successful interaction designer must be sensitive to user’s goals amid the pressures and chaos of the productdevelopment cycle. The GoalDirected process, with its clear rationale for design decisions, makes persuading engineers easier, keeps marketing and management stakeholders in the loop, and ensures that the design in question isn’t just guesswork, or a reflection of the team members’ personal preferences. Most computer users know all too well that opening the shrink wrap on a new software product augurs several days of frustration and disappointment spent learning the new interface. On the other hand, many experienced users of a program may find themselves continually frustrated because the program always treats them like rank beginners. It seems impossible to find the right balance between catering to the needs of the firsttimer and the needs of the expert. One of the eternal conundrums of interaction and interface design is deciding how to address the needs of both beginning users and expert users with a single interface. Some programmers and designers choose to abandon this idea completely, choosing instead to create software with a beginner mode and an expert mode, the former usually being an oversimplified and underpowered subset of the latter. Of course, nobody wants to be caught dead using software in beginner mode, but the leap from there to expert mode is usually off a rather tall cliff into a sharkinfested moat of implementationmodel design. What, then, is the answer? The solution to this predicament lies in a different understanding of the way users master new concepts and tasks.