Understanding the Problem

by February 12, 2005

During the Future of Digital Product Design panel last December, a question was raised about who the decision maker on a product team should be and which discipline takes on the role of “innovator”. In both cases I replied: “the one who best understands the problem”.

Understanding the problem is an essential part of any product development process. Different disciplines, however, come to understand a problem through different processes and through different artifacts.

For instance, marketing teams may create mission statements, business overviews, target market descriptions (outlining potential customers), competitive landscape surveys, product goals, and success metrics. Development teams, on the other hand, might model (the process of designing software applications before coding) use cases, scenarios, and classes to develop a firm understanding of how business functionality, end-user needs and scalability, robustness, security, and extendibility requirements will be met.

Understanding the problem from a design perspective requires knowledge from both marketing and engineering project definition processes, in addition to design-specific processes and artifacts. Market and consumer research (especially ethnographic) paint the customer landscape and technological opportunities and limitations help chart the end-user’s terrain. User experience brings the two together with a cohesive map to guide a product’s audience in a manner that meets both business and end-user goals.

As a result, it’s quite useful for designers to understand how a problem is being defined in engineering and business processes and to potentially embrace some of that methodology in their way of thinking. To that end, Norm Carr introduces use cases to Web designers at A List Apart and John M. Artim discusses UML (Unified Modeling Language) from the HCI practitioner's perspective.