design-tenets-for-decision-making

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.