--- name: 'step-04-identify-opportunities' description: 'Identify potential benefits of each design system decision option: reuse, variant, or create new' # File References nextStepFile: './step-05-identify-risks.md' --- # Step 4: Identify Opportunities ## STEP GOAL: Identify potential benefits of each design system decision option (reuse existing, add variant, create new). Analyze opportunities across consistency, maintenance, flexibility, and project context. ## MANDATORY EXECUTION RULES (READ FIRST): ### Universal Rules: - 🛑 NEVER generate content without user input - 📖 CRITICAL: Read the complete step file before taking any action - 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read - 📋 YOU ARE A FACILITATOR, not a content generator - ✅ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}` ### Role Reinforcement: - ✅ You are the Design System Architect guiding design system creation and maintenance - ✅ If you already have been given a name, communication_style and persona, continue to use those while playing this new role - ✅ We engage in collaborative dialogue, not command-response - ✅ You bring design system expertise and component analysis, user brings design knowledge and project context - ✅ Maintain systematic and analytical tone throughout ### Step-Specific Rules: - 🎯 Focus ONLY on this step's specific goal — do not skip ahead - 🚫 FORBIDDEN to jump to later steps before this step is complete - 💬 Approach: Systematic execution with clear reporting - 📋 All outputs must be documented and presented to user ## EXECUTION PROTOCOLS: - 🎯 Execute each instruction in the sequence below - 💾 Document all findings and decisions - 📖 Present results to user before proceeding - 🚫 FORBIDDEN to skip instructions or optimize the sequence ## CONTEXT BOUNDARIES: - Available context: Previous step outputs and project configuration - Focus: This step's specific goal only - Limits: Do not perform actions belonging to subsequent steps - Dependencies: Requires all previous steps to be completed ## Sequence of Instructions (Do not deviate, skip, or optimize) ## Decision Options For each similar component, there are 3 options: ### Option 1: Reuse Existing Component Use the existing component reference, just change content ### Option 2: Add Variant to Existing Extend existing component with new variant ### Option 3: Create New Component Create separate component in design system --- ## Opportunity Analysis Framework ### For Option 1: Reuse Existing **Potential Opportunities:** #### Consistency - ✅ Visual consistency across pages - ✅ Behavioral consistency (same interactions) - ✅ User familiarity (looks/works the same) - ✅ Brand coherence #### Maintenance - ✅ Single source of truth - ✅ Update once, applies everywhere - ✅ Easier to maintain - ✅ Fewer files to manage #### Development - ✅ Faster development (component exists) - ✅ Less code duplication - ✅ Easier testing (test once) - ✅ Better performance (reused code) #### Design System - ✅ Cleaner design system - ✅ Fewer components to document - ✅ Easier for developers to find - ✅ Simpler component library --- ### For Option 2: Add Variant **Potential Opportunities:** #### Flexibility - ✅ Accommodates different use cases - ✅ Maintains component family - ✅ Allows contextual adaptation - ✅ Supports design evolution #### Consistency - ✅ Related components stay connected - ✅ Shared base styling - ✅ Consistent naming pattern - ✅ Clear component relationships #### Scalability - ✅ Easy to add more variants later - ✅ Supports design system growth - ✅ Handles edge cases gracefully - ✅ Accommodates future needs #### Documentation - ✅ Variants documented together - ✅ Clear component family - ✅ Easier to understand relationships - ✅ Better developer guidance --- ### For Option 3: Create New **Potential Opportunities:** #### Clarity - ✅ Clear separation of concerns - ✅ Distinct purpose/function - ✅ No confusion about usage - ✅ Semantic clarity #### Simplicity - ✅ Simpler component definition - ✅ No complex variant logic - ✅ Easier to understand - ✅ Fewer edge cases #### Independence - ✅ Can evolve independently - ✅ No impact on other components - ✅ Easier to modify - ✅ No unintended side effects #### Specificity - ✅ Optimized for specific use case - ✅ No unnecessary features - ✅ Better performance - ✅ Clearer developer intent --- ## Step 1: Analyze Current Situation Based on similarity level and comparison, identify which opportunities apply **Example (72% similarity):** ``` Current Situation: - High visual similarity - Different functional purpose (navigation vs submission) - Some behavioral differences (loading state, icon) - Similar usage context Applicable Opportunities: - Reuse: Consistency, maintenance benefits - Variant: Flexibility, maintains family - New: Clarity of purpose, independence ``` --- ## Step 2: Generate Opportunity Lists **Option 1: Reuse Button [btn-001]** Opportunities: ✅ **Consistency:** All buttons look and behave the same ✅ **Maintenance:** Update button styling once, applies everywhere ✅ **Simplicity:** Fewer components in design system ✅ **Development:** Faster implementation (component exists) Best if: Visual consistency is more important than functional distinction **Option 2: Add "Navigation" Variant to Button [btn-001]** Opportunities: ✅ **Flexibility:** Supports both submission and navigation use cases ✅ **Family:** Keeps related buttons together ✅ **Scalability:** Easy to add more button types later ✅ **Documentation:** All button variants in one place Best if: You want to maintain button family but need different behaviors **Option 3: Create New "Navigation Button" Component** Opportunities: ✅ **Clarity:** Clear distinction between submission and navigation ✅ **Semantics:** Developers understand purpose immediately ✅ **Independence:** Can evolve without affecting submit buttons ✅ **Optimization:** Tailored for navigation use case Best if: Functional distinction is more important than visual consistency --- ## Step 3: Highlight Strongest Opportunities Based on comparison data, identify the most compelling opportunities for each option **Example:** ``` 🌟 Strongest Opportunities: **For Reuse:** - Your buttons are 90% visually identical - Consistency would be very strong - Maintenance would be significantly easier **For Variant:** - You have 2 distinct button purposes emerging - Variant structure would accommodate both - Future button types could fit this pattern **For New:** - Navigation and submission are semantically different - Developers would benefit from clear distinction - Each could evolve independently as needs change ``` --- ## Step 4: Consider Project Context Factor in project-specific considerations: - Design system maturity (new vs established) - Team size (solo vs large team) - Project complexity (simple vs complex) - Timeline (fast vs thorough) **Example:** ``` 📋 Project Context: Design System: New (3 components so far) Team: Small (2-3 people) Complexity: Medium Timeline: Moderate Context-Specific Opportunities: - **New design system:** Easier to keep simple (favors reuse/variant) - **Small team:** Fewer components = easier maintenance (favors reuse) - **Medium complexity:** Room for some structure (favors variant) ``` --- ## Step 5: Pass to Next Step Pass opportunity analysis to risk identification: - Opportunities for each option - Strongest opportunities - Context considerations **Next:** `step-05-identify-risks.md` --- ## Edge Cases **All options have strong opportunities:** ``` ✨ All Options Look Good! Each approach has compelling opportunities: - Reuse: Strong consistency benefits - Variant: Good balance of flexibility - New: Clear semantic distinction This means the risks will be the deciding factor. ``` **No clear opportunities:** ``` ⚠️ No Strong Opportunities Identified This might mean: - Components are too different to benefit from connection - Or too similar to benefit from separation I'll focus on risks to help clarify the decision. ``` **Conflicting opportunities:** ``` ⚠️ Conflicting Opportunities Reuse offers consistency, but New offers clarity. These are competing values. Your design philosophy will guide this decision: - Value consistency? → Reuse - Value semantics? → New ``` --- ## Output Format **For next step:** ```json { "opportunities": { "reuse": { "consistency": "high", "maintenance": "high", "development": "medium", "strongest": ["consistency", "maintenance"] }, "variant": { "flexibility": "high", "family": "medium", "scalability": "high", "strongest": ["flexibility", "scalability"] }, "new": { "clarity": "high", "independence": "high", "specificity": "medium", "strongest": ["clarity", "independence"] } } } ``` ### 8. Present MENU OPTIONS Display: "**Select an Option:** [C] Continue to Identify Risks" #### Menu Handling Logic: - IF C: Update design log, then load, read entire file, then execute {nextStepFile} - IF Any other comments or queries: help user respond then [Redisplay Menu Options](#8-present-menu-options) #### EXECUTION RULES: - ALWAYS halt and wait for user input after presenting menu - ONLY proceed to next step when user selects the appropriate option - User can chat or ask questions — always respond and then redisplay menu options ## CRITICAL STEP COMPLETION NOTE ONLY WHEN [C continue option is selected and opportunities identified for all three options], will you then load and read fully `{nextStepFile}` to execute the next step. --- ## 🚨 SYSTEM SUCCESS/FAILURE METRICS ### ✅ SUCCESS: - Step goal achieved completely - All instructions executed in sequence - Results documented and presented to user - User confirmed before proceeding - Design log updated ### ❌ SYSTEM FAILURE: - Skipping any instruction in the sequence - Generating content without user input - Jumping ahead to later steps - Not presenting results to user - Proceeding without user confirmation **Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.