Mastering Demand and Technical Boundaries for Interaction Designers

1. Demand Boundary

What is a demand boundary? It defines the limited work scope required to deliver a product with specified features within a clear goal or version, ensuring the scope remains controllable.

Why have a demand boundary? Without it, projects may miss deadlines, incur losses, and demotivate teams. Defining boundaries sets clear targets, aids scheduling, and prevents scope creep.

How to find the demand boundary? At project kickoff, formal contracts and internal documents such as the Project Charter outline the original scope (e.g., "launch enterprise OA product"). During planning, create a Work Breakdown Structure (WBS) to break down the functional list, which becomes the guiding document for interaction design.

The functional list (see image 1‑1) serves as the demand boundary; designers must align their solutions with it, avoiding extra features that exceed scope, such as adding OCR invoice recognition when the contract only covers photo storage.

2. Technical Boundary

What is a technical boundary? It is the limited range of what can be implemented with current technology.

Why must designers understand it? The best‑experience design may be infeasible or too costly given technical limits, leading to repeated revisions.

Design reviews aim to locate a "safe zone" where business needs, technical boundaries, and optimal experience intersect. Knowing technical constraints early reduces redesign cycles.

For new products, designers must verify the functional list for features like avatar upload; if unavailable, they must adjust designs accordingly. For existing product upgrades, compatibility and reuse considerations expand technical boundaries, requiring thorough review of existing interfaces.

Interface structures also reflect technical limits; mismatched structures increase change costs, as illustrated by a banking approval workflow example (see images 2‑2 and 2‑3).

3. Other Boundaries

Legal regulations, industry standards, hardware constraints, and design guidelines also limit design decisions (e.g., risk disclosures for financial products, remote‑control input limits, or consistency with design systems).

4. Designing Within All Boundaries

4.1 Requirement analysis skill Designers must identify business needs, translate them into clear statements, and confirm with stakeholders.

4.2 Insight with courage While respecting technical limits, designers should still advocate for optimal experiences and propose extensions when feasible.

4.3 Summary Understanding demand, technical, and other boundaries enables designers to produce safe‑zone solutions quickly, yet they should also push boundaries to expand the design space.