When to challenge the scope

Overview

This framework helps designers make informed decisions about when and how to propose UX improvements, even when project documentation appears complete.

🎯 Guiding Principle

"Any design decision that genuinely improves the product is valid and worth proposing—as long as we stay within scope."

🤔 The Scenario

You receive a project with documentation that appears complete and polished:

✅ Defined user flows
✅ Detailed PRDs
✅ Complete data sheets
✅ Clear technical requirements

Key question: Should I intervene or follow exactly what the documentation says?

✨ When You SHOULD Propose Changes

1. You identify a significant improvement in user experience

Example: The scope doesn't mention an Admin dashboard, but you identify it would be crucial for their operational efficiency

2. You detect inconsistencies or gaps in the experience

Example: The flow is defined but a critical error state is missing

3. There are opportunities for simplification

Example: You can consolidate 3 steps into 2 without losing functionality

⚠️ When to Be Cautious

1. The change requires significant technical resources outside the current scope

Action: Document the idea for future iterations

2. The change affects data architecture or complex integrations

Action: Consult with the technical team first before proposing

3. There's already a documented business decision that supports the current approach

Action: Understand the context before challenging

🚫 Requests That Typically Fall Outside Scope

Be mindful that these types of requests usually require additional development resources and fall outside standard project scope:

Data Visualization

Dynamic charts - Custom charts that aren't available in the Airdev library, Glide Assets, or standard charting libraries
Action: Check available library options first;
Exception: If you truly believe it's necessary, consult with the PM and/or devs to verify feasibility. If it's simple to implement and genuinely adds value from a UX perspective, go for it!

Advanced Interactions

Certain types of animations - Complex animations beyond standard transitions and micro-interactions
Action: Evaluate if simpler alternatives can achieve the same UX goal

Document Generation

Generating PDF documents - Typically requires additional backend setup and third-party services
Document it as a potential feature for a future version/release

Social Features (Bubble apps)

Social sharing (e.g., sharing a generated PDF from the app to social media directly from the app)
Why it’s complex: Usually requires multiple permissions and extra configuration
Action: Consider alternative sharing methods (download + manual share)
Action 2: Document it as a potential feature for a future version/release

Integrations

Easy to implement (usually does not fall out of the scope)

- Address autocomplete (Google Maps API) - Makes form completion smoother

💡 Practical Examples

✅ Example 1: Admin Dashboard

Situation: The PRD doesn't mention a dashboard for Admin users, only individual management screens.

Your analysis: Admins need a consolidated view to monitor activity and make quick decisions.

Action: You propose a simple dashboard with key KPIs. You justify it with usability heuristics (visibility of system status) and documented use cases.

Result: ✅ Valid proposal - Improves the product and is within the Admin experience scope.

✅ Example 2: Flow Simplification

Situation: The user flow has 4 steps to complete an action you could solve in 2.

Your analysis: Fewer steps = less friction, less abandonment.

Action: You design a more efficient alternative, maintaining all required functionality.

Result: ✅ Valid proposal - Improves efficiency without going out of scope.

✅ Example 3: Address Autocomplete Integration

Situation: The form includes manual address entry fields that users need to fill out completely.

Your analysis: Users often make mistakes or abandon forms with lengthy address inputs. Google Maps autocomplete would significantly reduce friction.

Action: You propose integrating Google Maps API for address autocomplete. This is a standard integration with clear UX benefits.

Result: ✅ Valid proposal - Improves UX, standard implementation, usually within scope.

⚠️ Example 4: Completely New Feature

Situation: You think it would be useful to add push notifications, but they're not mentioned anywhere in the scope.

Your analysis: It would improve engagement, but requires backend, infrastructure, and is outside the defined MVP.

Action: You document the idea for future roadmap, don't propose it for this iteration.

Result: ⚠️ Out of current scope - Save it for the future.

⚠️ Example 5: Custom Data Visualization

Situation: You want to add an interactive, custom chart to display analytics data in a unique way.

Your analysis: The visualization would be insightful, but it's not available in standard libraries (Airdev, Glide Assets, Chart.js).

Action: Check if a similar visualization exists in available libraries. If not, propose a simpler alternative using available components, or flag this as a potential scope expansion.

Result: ⚠️ Likely out of scope - Requires custom development. Document as future enhancement or find alternative.

🎯 Expected Outcomes

By applying this framework, you should be able to:

Feel empowered to propose significant improvements
Make informed decisions about when to intervene
Effectively communicate your proposals to the team
Balance innovation with pragmatism
Add real value to every project
Recognize early when a proposal might require scope expansion

🔄 Next Step

This framework is living documentation. If you find cases that aren't covered or have suggestions, share feedback with the team to keep improving it.