Four Interaction‑Design Cases for Refining Product Requirements

Requirement documents are often poorly written, and many product managers prefer quick wireframes; however, interaction designers should first assess the underlying user needs, discuss with product managers, and then propose corrected interaction solutions.

1. Judging the Reasonableness of a Requirement – Example: Tongcheng Travel app wanted to add an “Instant Booking” button in the airport lounge privilege page, but there was no suitable user scenario. Analysis showed users would not book tickets from that page, and the feature should be replaced with a “View Supported Airports” link. The final interaction removed the booking button and added the airport list entry.

2. Using Product Data to Drive Decisions – Example: Optimizing the password‑reset flow in the Tongcheng Travel app. Data from November 2016 showed that the old‑password verification was used 17% of the time with a 19.78% success rate, while phone‑code verification was used 79% with an 80.84% success rate. The final design promoted phone‑code verification as the primary method and kept the old password method as a secondary option.

3. Avoiding Redundant Logic – Example: Encouraging users to complete personal profile information for growth points. The original flow required users to manually claim rewards, and the activity entry could be ignored. The revised interaction added prominent prompts in the profile page and automated growth‑point distribution after completion.

4. Comprehensive Consideration of Multiple Factors – Example: Adding a quick‑order entry on the homepage of the Tongcheng Travel app. The requirement aimed to show upcoming orders, personalize the homepage, and reduce user steps, but raised concerns about API load, conflicting animations, and timing logic. Three design proposals were evaluated; the final solution combined a modest countdown, limited real‑time reminders, and a lightweight card that fits the existing homepage layout.

Summary – These four cases demonstrate that interaction designers should first reason about the requirement itself, use scenario analysis, data validation, logical clarification, and competitive checks before proposing interaction solutions, thereby preventing the pursuit of misguided or ineffective product directions.