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). What similar needs are reflected in fitness products and services and how are they met?

Fourth, consider plug-ins and widget libraries. Technical constraints may limit your options for using a particular instance of a widget or plug-in. For example, if you select PHP as your Web framework, certain Python modules are not an option. However, at this concept stage, we are interested in knowing what is possible, not at specific technical implementations. Moreover, if a widget or function implemented in Python has practical utility, someone has almost certainly ported it into every other Web framework already.

Fifth, vary the assignment of agency to action. For each step in the process, who (user v. system) does what. Does the user explicitly list preferences or do they just browse, relying upon the system to induce preferences based upon browsing behavior. What input comes from direct user entry (e.g. type in your user name) or from indirect user context (e.g. an IP address, GPS, time-of-day).

4. Explore and combine systematically

Once you have generated a pool of concept elements for meeting each component of the problem decomposition, explore the space of possible concepts by systematically combining different concept elements within the framework of one specific problem decomposition. This can be a large space that grows even more if you allow for different possible process flows. See UE Chapter 6 for techniques to prune the search space.

Conclusion.

The goal of concept generation is not to create a single concept but rather to generate a set of many different possible concepts. Given a sufficiently large set of initial possibilities, a subsequent concept selection process combines and refines the set of possible concepts to arrive at a design ready for prototyping. Apple, Inc. is well known in design circles for the ratios 10:3:1. Whether at the scale of an individual widget or an end-user product, design teams are challenged to initially develop 10 legitimately viable concepts. From those 10 concepts, three are selected for further development and testing before making a final selection.

Appendix. Concept Generation Examples.

Step 1. Scenario Definition

Consider the design of an online hotel reservations service. Imagine the following scenario:

Homer and Marge Simpson are planning their first trip to San Francisco in celebration of their wedding anniversary. They want to stay in Union Square and experience the bustle directly from their hotel. At the same time, they are traveling on somewhat of a budget.

Step 2. Decompose the Problem

To decompose the problem, we can imagine that:

1. Homer identifies his destination, date, and number in his party Notes on Concepts DRAFT 4 T. Lee and T. Eng

2. The system gives Homer a list of possible hotels along with price and location. 3. Homer can sort or filter the list based upon price and location.

Step 3. Generate Concept Elements

There are certainly norms in the hotel reservation booking domain. These include calendar/date entry conventions, line-completion when entering city names, etc. There is even a relatively standard layout of a hotel booking website. These norms quickly become apparent upon competitive benchmarking:

First, consider Travelocity, a mainstream travel site that, among other things, supports hotel bookings.

A single snapshot conveys the process and key features of the site for benchmarking purposes in the same way that a sketch could convey the design concept. Users may choose to login or search anonymously. The user first inputs destination, date, time, and number-in-party. The site produces a list in the center column that can be sorted or filtered by customer reviews and quality ratings (not important to Homer) as well as price. Not shown, but further down the left-hand navigation bar “below-the-fold” are filters for amenities and city region (which Homer also cares about). Notice the widget selection includes slider bars and check boxes.

Notes on Concepts DRAFT 5 T. Lee and T. Eng

For comparison and contrast, consider Hotwire.

Again, the basic user process flow is the same and the layout is strikingly similar. Do not deviate from the norm. The user inputs destination, date/time, and number in party. A list of options appears again appear in the center panel with filters in the left-hand navigation bar including quality-levels, customer ratings, price, etc. Hotwire also has two different features, however. Above the center panel there is a search bar that allows you to search a region (e.g. Union Square) rather than selecting from a pre-defined list in the left-hand navigation bar. Notice the difference in widget selection. Combined with the prominent placement in the center panel above the hotel listings suggests a different concept aimed at a different type of user and need. Most significantly, notice the significant difference in the process flow. The user must make a commitment before the hotel name is revealed.

Notes on Concepts DRAFT 6 T. Lee and T. Eng

Finally, consider Priceline.

The process flow and layout are again similar. Users pick a destination and date. Instead of seeing a list of options, however, the user is first presented with the same filters as additional search parameters: region, rating, etc. The hallmark of this concept is revealed in the next process step. The user selects a price.

We can characterize the significant differences between these concepts not so much in process flow or widget selection (although those differences do exist; recall Hotwire’s regional search bar or Priceline’s steps following destination and date). Instead, consider how each concept differs in their assignment of agency to action. Travelocity is similar to any baseline retail site; consider Amazon and a retail website as an analogous product. Hotwire asks users to input similar information but they select an unknown hotel based only upon the other parameters. The system does not provide hotel names (until later). In Priceline, users enter a price rather than reviewing options and available prices.

Notes on Concepts DRAFT 7 T. Lee and T. Eng

In the hotel reservations space, there any number of additional conceptual variations:

Room77 is a reservation service that provides floor plans and 3D modeling with GoogleEarth to provide an idea of the “view” from your room. Homer and Marge could see if their room overlooks Union Square.

HotelTonight specializes in same day bookings; anytime after 12 noon until 2AM where the standard limit is 11PM the same day)

YAPTA provides customers with historical price trends to help them make choices about the lowest price.

Step 4. Explore and Combine Systematically.

We can now consider mixing and matching from the different concepts and concept elements that we have seen. For example, Hotwire is already a known resource for last-minute hotel bookings for stranded business travelers. How would Hotwire need to renegotiate their relationships with vendors to support HotelTonight’s extended same day booking.

Another straightforward combination might consider the priority that Hotwire places on searching or filtering search results based upon local regions as evidenced by the prominent placement of the geographic search bar in the center of their interface above their search results. Contrast that with Travelocity’s approach that pre-populates a city-specific list of local regions as check boxes but places those check boxes below-the-fold in the left-hand navigation bar. A traditional booking engine like Travelocity might differentiate itself by providing greater local geographic (even graphical) search support.

A third combination might consider Room77’s feature of room-specific search. One could imagine a Hotwire-type service that allows users to constrain their search and make a commitment not only by local region but by room placement (by the elevator?) or by view (facing the HVAC system? partial ocean view?). In a Priceline model, users could name-their-price subject not only to general hotel constraints but room-level conditions like placement and view.

A fourth combination might incorporate YAPTA-like historical price trends to the budget conscious model underlying Hotwire. Users could explore historical price trends in a city not by hotel but by region. Certainly some regions are more expensive than others. Budget travelers might benefit in their exploration by viewing trends not only in price but also variance by region.

Notes on Concepts DRAFT 8 T. Lee and T. Eng