An antigoal is an explicitly identified outcome or condition that a system design should avoid. It acts as an inverse statement alongside goals, narrowing both the problem space and the solution space. section 4.2
Use antigoals to make tradeoffs visible before implementation:
- Strike out qualities that do not materially improve the system’s main objective. section 4.2
- Prevent an endless list of competing goals from making the design impossible to satisfy. section 4.2
- Keep the boundaries visible during design-document review, where vague requirements can later become change requests. section 4.6
A boutique-store recommender
For an internal reporting system, processing time can be an antigoal when reports only need to be ready by morning. For a boutique store with fewer than 1,000 products and low traffic, scalability is an antigoal: supporting millions of items would add no useful value. section 4.2
Figure 4.1 A shop with <1,000 goods for sale and low traffic should not aim for scalability when building a recommendation system, as almost any tech solution can handle its load these days.
Use the figure to see how product count and traffic can make scalability an unnecessary design target. section 4.2
