smithery/samarv

design-tenets-for-decision-making

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.

Installation

$ npx skills add smithery/samarv --skill design-tenets-for-decision-making

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from smithery/samarv · top by installs.

npx skills add smithery/samarv

Browse all from smithery/samarv

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 3,807 B
  • docs SUMMARY.md 313 B

History

  1. First recorded snapshot · 0 installs

SKILL.md

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.