How Structured Product Thinking Solves Complex Error Messaging Challenges

Preface: Misconceptions About Product Thinking

In business discussions we often hear: "You need product thinking to solve this problem" or "I want to improve my product thinking". While product thinking helps designers drive projects, its dimensions are vague and lack concrete definitions and actionable guidance. What is product thinking? How does it add value to design? How is it manifested? How can we learn it? These questions feel elusive, lacking clear definitions and actionable steps. I, too, struggled with the myriad types of product thinking presented in books and articles. Eventually I realized there may be no absolute definition; different roles (product, design, product lead, business lead), contexts, goals, experiences, and mindsets lead to varied understandings and applications. Thus, instead of learning a single product thinking, we should build our own product thinking system, continuously enriching it through practice. Today's share uses an "error prompt" case to illustrate three core product‑thinking tools and their application.

Part 1

Essential Thinking: Diagnosing from Symptoms

One day a developer said: "We defined an error code only for the email login scenario, but now users encounter the same issue in the sending scenario. Can you provide a message for this version?" I instinctively replied, "Sure, I’ll send it later." However, I soon questioned why the omission occurred, why the unified message rule failed, whether other sending‑scenario errors existed, if changes required a new release, and why real‑time configuration wasn’t used.

We discovered that error definitions were fragmented by module: login errors were defined only for login, sending errors only for sending, yet many processes (login, receive, send) share account validation, causing overlap. The problem was redefined as:

How to comprehensively define all error scenarios?

How to achieve real‑time effectiveness of error‑prompt configuration?

Just as symptoms indicate underlying disease, we must trace the root cause rather than merely treating surface issues.

Part 2

Structural Thinking: Building Complex Problems

After redefining the problem, the first step is to collect and organize all product error codes. With hundreds of errors across protocols (IMAP, SMTP), platforms (mobile, desktop), and scenarios (login, sending), we need a systematic approach.

We use a two‑dimensional management table: each tab represents a protocol; rows list each error code; columns capture error‑message components for different scenarios. This ensures every error has a clear definition and avoids omissions.

We then extract commonalities to establish standards, such as unifying message formats, reusing wording for account‑risk errors, and standardizing translations.

Typical structural methods include:

Decomposition: break the problem into parts and sub‑parts (MECE principle).

Modeling: create analysis models like user‑experience maps.

Formulation: identify core variables and their relationships.

Part 3

System Thinking: Activating Design

Beyond organizing error prompts, we need a system that allows flexible, real‑time configuration. Traditionally, error messages were hard‑coded in the client, requiring a new release for any change. By moving configurations to the server, the client fetches error codes and displays the appropriate message dynamically.

We also implement automation to reduce unnecessary prompts, offering auto‑retry or one‑click fixes where possible, and establish monitoring to capture unknown high‑frequency errors for future definition.

In summary, applying product‑thinking tools—essential, structural, and system thinking—helps us diagnose root causes, standardize error handling, and build a configurable, automated, and monitorable error‑prompt system that delivers long‑term value to both product and users.