| name | design-tenets-for-decision-making |
| description | Create high-opinion decision-making tools (tenets) to resolve repetitive design debates and ensure product cohesion. Use this when a team is stuck in circular arguments, when scaling a design culture across fragmented teams, or when defining the core DNA of a new product. |
Design tenets are strategic decision-making tools that force a choice between two valid directions. Unlike "design principles," which are often indisputable platitudes (e.g., "make it simple"), tenets provide a specific point of view that allows teams to move from a mindset of control to one of choreography.
Core Principles
- Argue the Opposite: If you cannot reasonably argue the opposite of a statement, it is a principle (a platitude), not a tenet.
- Limit to Three or Four: Tenets must be memorizable. If a team has to consult a handbook to remember them, they will not use them in real-time debates.
- Decision Utility: A tenet's primary job is to settle a debate once and for all so the team doesn't have the same argument every six months.
The Process for Creating Tenets
1. Identify Repetitive Debates
Audit recent design reviews and product meetings. Look for "bifurcation points" where the team consistently splits into two camps. Common areas include:
- Power vs. Simplicity
- Compatibility vs. Innovation
- Customization vs. Standardized UI
2. Draft "Paper vs. Plastic" Statements
Write tenets that explicitly favor one approach over another. Use the "X over Y" or "X is a failure" format to ensure the trade-off is clear.
3. Test for Memory and Utility
Socialize the draft tenets. If a team member cannot recite them from memory after 24 hours, simplify the language. If a tenet doesn't immediately clarify a current design bottleneck, discard it.
4. Apply During Reviews
Use tenets as the objective criteria for feedback. Instead of saying "I don't like this," ask "Does this design help the user opt-into complexity, or is it forcing complexity on them by default?"
Examples of Effective Tenets
Example 1: Apple Keynote (Early Development)
- Tenet: Optimize for innovation over PowerPoint compatibility.
- Application: This allowed the team to ignore legacy file constraints and focus on cinematic transitions that were impossible in PowerPoint at the time.
- The Opposite: "Prioritize seamless compatibility with existing corporate standards." (Also a valid, but different, strategy).
Example 2: ThoughtSpot (Enterprise SaaS)
- Tenet 1: Documentation is a failure state. If a user has to read a manual, the design failed.
- Tenet 2: Start simple; opt-into complexity. The interface should look like a search bar for "mere mortals," but allow power users to turn on advanced analytics filters.
- Tenet 3: Look and feel like it came from a single mind. Prevents "Conway's Law" where the product looks like a collection of disparate features from different engineering pods.
Common Pitfalls
- Using "Apple-pie" Words: Terms like "intuitive," "beautiful," or "fast" are useless because no one argues for "counter-intuitive" or "ugly." If everyone agrees with the statement by default, it's not a tenet.
- Creating Feature-Specific Tenets: Tenets should operate at the design strategy/brand level. If they are too granular, they lose their power to align the entire organization.
- Ignoring the Tenet When Convenient: If an executive overrules a tenet for a one-off feature, the system breaks. Tenets require "air cover" from the highest levels of leadership.
- Relying on High-Fidelity Too Early: Do not try to define tenets using high-resolution comps. Use "block-frame" diagrams or words only to focus on the conceptual model before the visual expression.
