Notes on Concepts
Total Page:16
File Type:pdf, Size:1020Kb
Notes on Concepts These "Notes on Concepts" are based upon Chapter 6, Concept Generation from Ulrich and Eppinger. They translate the general principles of concept generation in product design into the specific context of Web-based (mobile) products and services. What is a concept. The early stages of design revolve around user needs and focus exclusively on “what” not “how.” Concepts are where the design process transitions from “what” to “how.” As described by Ulrich and Eppinger, a concept “is an approximate description of the technology, working principles, and form of the product. It is a concise description of how the product will satisfy the customer needs (UE Ch 6).” In the context of Web-based (or mobile) products, the technology aspect involves elements that are either already fixed (e.g. HTTP and HTML) or technical design decisions that are largely supported by all of the major Web frameworks independent of specific architectural choices.1 Therefore, online product or service concepts tend to focus on the latter two: the User Experience or UX (working principles), and the User Interface or UI (form). Representing a concept. An online product or service concept is best conveyed with (1) a scenario, (2) one or two UI sketches with accompanying annotations, and possibly (3) a text description. A scenario, also referred to as a use case, makes the problem or opportunity concrete. User interface sketches provide sufficient detail to express the range of attributes and process flow by which the product or service addresses the opportunity. Annotations and a text description are included as necessary to clarify the design. A scenario defines one instance of the problem and the specific context in which that problem occurs, described in sufficient detail to highlight the unique attributes and characteristics of the solution concept. For example, if the service includes geo-location features to customize the site's language and auto-populate form fields, the scenario should include the "country" in which the user resides. If the service has a "hide-the-boss-is-coming feature," the scenario might include the fact that the user is completing the task "while at work." Time-of-day, user persona (a student, a parent, a spouse), event (wedding, holiday, birth, death) are all possible scenario elements. Consider, for example, the following scenario: Bart Simpson is a University student on a budget, enrolled in a course on "Design and Development of Web-based Products and Services." He needs to purchase a copy of the required textbook, Product Design and Development by Ulrich and Eppinger along with his other textbooks. His "Design" instructor has indicated that although the book is in its fifth edition, earlier versions are acceptable. Because Bart is new to product design, he is also interested in related texts. A single interface sketch can convey a significant amount of detail about the specific solution concept. Consider the Amazon webpage in Figure 1, which has been divided into two pieces in order to fit on a single page (if this were a concept, this would be a sketch of the product being designed rather than a screenshot of an existing product). 1 The exception is when our product or service is itself defined by novel technology. For example, you may be designing a vehicle for a new search algorithm or a better product recommendation engine. Even in such cases, a concept is only as good as the surface that the user can see and touch. Describe the secret sauce in your accompanying concept text description. 1 Figure 1. Annotated Amazon interface screenshot to define the concept The annotations and any accompanying text description describe specific product attributes and process flow as well as assign agency to action. Agency or agents include the user, the computer, and perhaps other users in the case of a social application. Actions include any event or state change in the product or service. The search bar at the top reveals hints at the process flow or steps that Bart takes in using the online product: Rather than browsing, in step 1, Bart is the agent and the action is Bart’s input of search parameters. In step 2, the system is the agent and the action is the list of particular search results. Certain product attributes aligned with Bart's needs are highlighted in the search results. The site is personalized, perhaps to keep track of textbook purchases for all of Bart's courses. So the agent is the system and the action is the recording of purchase/browsing history. Product details are listed so that Bart is certain that he has the correct textbook. Alternate (less expensive) sources for this and other versions of the text are accompanied by prices in case Bart can make use of used copies and/or earlier versions. Recommended texts to supplement Bart's reading are also highlighted *based upon similar past purchases*. Note that concepts are not unique – there are other concepts and concept elements that could also meet Bart's needs. For example, the site could have had some visual interface resembling the layout of a shelf in a library or bookstore. Using the Library of Congress catalog system, all items on the virtual shelf "around" the Ulrich and Eppinger textbook would likely also be about product design. And rather than maintain account information about Bart, for users interested in anonymity, the site could have a "mail this reference" feature thereby relying upon Bart to save purchase and browsing history himself; Bart becomes the agent for the action associated with recording of purchase/browsing history. And rather than searching by title or author, a service might collect syllabi. Bart could search based upon University and course number and then all texts for a single course would appear at once. Notes on Concepts DRAFT 2 T. Lee and T. Eng Notice also that the concept says nothing about the underlying technical implementation. Nothing is said about the "secret sauce" behind the recommendations, the database that contains the product details, the data sources and databases created to index earlier textbook versions and alternate retailers who carry the product. These are certainly important details, but they do not come into play at this stage of design. Generating a concept. 1. Scenario definition To generate online product or service concepts, begin by defining a motivating scenario to make the problem concrete. What level of granularity is appropriate? There is no rule – simply include sufficient detail to highlight specific user needs and product attributes. In any product or service of even moderate complexity, a single scenario will not cover the full range of features and functionality. Begin with a single scenario to help focus your design and narrow your initial project scope. Then later, consider the need for additional scenarios that cover more of this range. 2. Decompose the problem First, map out the process flow by which the user will accomplish their task and navigate your website. Second, separate out specific functions and modes. The previous example with Bart represented a “search” mode. One could equally envision a “browsing” mode. Bart’s recommendations were based upon customers who made similar purchase. A different function might recommend based upon Bart’s social network or personal past purchases. As another example, if your product is an online suggestion box, you might have a “submission mode” for users to submit opportunities or suggestions. You might then have an “evaluation mode” when judges rate submissions. In a related sense, consider different possible user contexts (this will also emerge as you construct additional scenarios). Ask yourself where, when, and how does the user interface with the product. Each new context may define a different mode. Make note of key user needs. What "must have" elements must you include. For example, in a retail application, you must have prices. Finally, consider alternate process flows – e.g. must the user log-in first, or does your product or service allow for anonymous use, etc. As with scenario definition, there is no rule on the correct level of abstraction for problem decomposition. As a guideline, consider a decomposition into components for which you can identify distinct UI/UX elements. 3. Generate concept elements For each element of the problem decomposition, brainstorm, research and compile a list of different UI/UX options. First, understand the conventions within your domain. Unless a specific feature or function is a key differentiator or technological innovation of your product, conform to the norm. For example, if a user needs to input a date, there are well-defined calendar widgets. Everyone is used to a dropdown menu for inputting a country. Do not deviate from norms without an explicit reason for doing so. Second, benchmark competitor products. If you are designing a social site for recipes and groceries, what do other such sites look like? What is their process flow? How do they succeed or fail in satisfying the needs that you have identified. Think and search broadly for competitors. Try specific instances such as sites around specific grocery stores and their products or recipes and lists for specific products ("all about eggplant"). Try generalizing. Recipes and groceries are Notes on Concepts DRAFT 3 T. Lee and T. Eng about food but you might consider social sites all-about-Thanksgiving which will certainly include recipes and groceries but may also include crafts, games, and activities. Third, benchmark analogous products outside your application domain. As a hint, focus on certain features or functions and think about other domains that may share similar features. For a cooking product, a cooking recipe is like a workout regimen (a fitness recipe).