Use when a product direction or Apple-platform interaction needs decisions among purpose, agency, responsibility, familiarity, flexibility, simplicity, craft, and delight.
Installs into .claude/skills of the current project.
Are you the author of Apple Hig Design Principles?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/ayushrajsinghparihar-apple-hig-design-principles)
---
name: apple-hig-design-principles
description: Use when a product direction or Apple-platform interaction needs decisions among purpose, agency, responsibility, familiarity, flexibility, simplicity, craft, and delight.
---
# Resolve a product tradeoff
Read [Design principles](../../references/design-principles.md). Inspect the brief and existing flow; identify the person, useful outcome, competing goals, and supplied evidence. Establish whether the request calls for a new direction, a review, or adaptation. Keep the existing implementation stack; this procedure's decision record is application advice, not an Apple-mandated document.
1. Express the core outcome as something a person can accomplish. If a feature does not serve it, remove or defer that feature in the authorized artifact. If the outcome is unclear, mark the assumption rather than inventing research.
2. Locate the real tradeoff. For simplicity versus agency, preserve essential choices and reversibility while progressively revealing secondary work. For delight versus familiarity, put expression in feedback/content while preserving recognizable commands. For personalization versus responsibility, explain the benefit and reduce data collection before requesting access. For density versus flexibility, preserve context and action locations as space and input change.
3. Compare at least the plausible alternatives for that tradeoff using consequences for the actual task. Do not give every principle an artificial score or claim a universal visual style follows from them.
4. Produce the chosen flow, revised copy, design specification, or scoped implementation. A review should identify the supplied decision that harms the outcome, its consequence, and the replacement; an adaptation should show how familiar control and task continuity survive the move.
**Worked transformation:** Before, a language journal requires a celebratory tutorial and profile survey before writing. Decision: immediate writing serves purpose and agency; optional reflection can supply personality later. After, the first screen opens a blank entry with a skippable hint, undoable edits, and optional personalization after saving.
Walk the outcome with a newcomer and a returning-person scenario. Fail if the revision still gates essential work on unnecessary guidance/data, removes meaningful recovery, or makes equivalent commands behave differently. Label untested usability claims as hypotheses; static documents cannot establish real-setting reliability or emotional response.
If a tradeoff becomes a concrete layout question, use [Layout](../../../apple-hig-foundations/.topics/apple-hig-layout/SKILL.md); for unnecessary data use [Privacy](../../../apple-hig-foundations/.topics/apple-hig-privacy/SKILL.md); for a platform adaptation choose the relevant neighboring designing-for-platform procedure.