How to Simplify Interaction Designs and Slash Development Costs

1. Timing of Simplification Work

Simplification should be performed during the "functional architecture diagram" stage, when designers have a clear overview of required features but before detailed interaction mockups are created, allowing large‑scale changes with low cost.

The architecture diagram must be detailed; a coarse diagram can leave hidden risks that later revisions will expose.

Include both functional and interaction‑level descriptions in the diagram; an example of a web video comment feature architecture is shown.

2. Basic Principles of Simplification

2.1 Priority Formula

Priority = Experience Impact / Cost

Experience impact is the difference between the perfect and compromised solutions multiplied by scene usage rate:

Experience Impact = (Perfect Score – Compromise Score) × Scene Usage Rate

Thus, Priority = (Perfect Score – Compromise Score) × Scene Usage Rate / Cost.

2.2 Scene Width and Depth

Scene width refers to the variety of scenarios a feature supports (e.g., text, image, GIF, voice comments), while depth describes the richness within a single scenario (e.g., responsive text box height). Wider and deeper scenes increase product scope and cost; reducing them saves resources.

2.3 Experience Value

Experience value ranges from normal (0) to excellent (+50%) or poor (‑50%). Projects may define target and baseline experience values. Subjective rating scales can be used to assess experience without detailed dimensional breakdown.

2.4 Scene Usage Rate

Scene usage rate is the proportion of all user interactions that involve a specific feature. For estimation, it can be approximated by user adoption rate. To cut cost, prioritize removing low‑usage scenes, as usage typically follows a power‑law distribution.

2.5 Cost

Cost mainly refers to development effort, including front‑end, back‑end, algorithm, and QA testing. Teams can estimate total cost in person‑days and record it in the priority evaluation table.

2.6 Calculating the Priority Coefficient

Insert the measured values into the formula; optionally apply a square‑root reduction to cost and multiply by a constant (e.g., 1000) for readability. The example yields a coefficient of 32 for a lazy‑load comment feature.

3. Starting the Simplification Work

3.1 Materials Preparation

Detailed functional architecture diagram (electronic version).

Priority evaluation table (downloadable).

Meeting room with screen sharing capability.

3.2 Evaluation Objects

Identify contentious items in the architecture diagram that can be debated; focus the simplification effort on these.

3.3 Evaluation Personnel

Interaction designer.

Product manager (to address requirement aspects).

Technical lead or anyone able to estimate development cost.

3.4 Evaluation Process

All participants collaboratively fill the priority evaluation table, avoiding separate scoring and averaging. The discussion typically lasts about 40 minutes and results in a consensus on which features or interaction points to simplify.

4. Final Summary

The theory is extensive, but the actual simplification process takes about 40 minutes and can save substantial development time.

Doing simplification during design, not at PRD review, captures details that designers add later.

Schedule simplification right after the functional architecture diagram is ready; delaying leads to repeated revisions.

For urgent projects, early simplification prevents later “time‑not‑enough” crises.

Record removed features for future versions.