Design Decisions for Rubric Mastery

This is the comprehensive design decisions page. Each decision is documented with its rationale, rubric alignment, and evidence templates. Judges can use this page to trace any design choice back to a rubric category and forward to specific implementation evidence.

---

Decision A: User Feedback Loops to UI Changes

Rubric Category: User Experience

Rationale

The Technovation rubric rewards projects that demonstrate iterative design based on real user feedback. SisterShield documents iterative testing cycles, each producing specific, evidence-backed UI changes.

Template for Documenting Testing Cycles

Each cycle follows this structure:

1. Who was tested: Participant count, demographics, recruitment method.
2. What was tested: Specific tasks with measurable outcomes (completion rate, time, errors).
3. What was found: Key findings with direct quotes.
4. What changed: Specific UI modifications with before/after evidence.
5. How it was validated: Metric measured in the next cycle to confirm improvement.

UI Change Justification Format

Every UI change is documented in this standard format:

“Based on Cycle [X] feedback: [specific data point or participant quote], we changed [UI element] from [before state] to [after state] to achieve [measurable goal].”

Evidence Placeholders

Cycle	Change	Before	After	Evidence Link
1	TODO: Change description	TODO: Screenshot/description	TODO: Screenshot/description	TODO: Link
2	TODO: Change description	TODO: Screenshot/description	TODO: Screenshot/description	TODO: Link
3	TODO: Change description	TODO: Screenshot/description	TODO: Screenshot/description	TODO: Link

See the full User Feedback Loops page for complete cycle documentation.

---

Decision B: Target Audience + Avoid Harm to Calm Color System

Rubric Categories: User Experience, Avoid Harm

Trauma-Informed Rationale

Users of SisterShield may be in crisis, under stress, or experiencing anxiety. Research in trauma-informed design suggests that:

• High-saturation colors increase physiological arousal and cognitive load.
• Visual clutter makes it harder to identify the most important action.
• Competing visual elements create decision paralysis in stressed users.

The Calm Color System addresses all three concerns.

Purple Reduction: Brand-Heavy to Priority-Heavy

Aspect	Brand-Heavy (Before)	Priority-Heavy (After)
Purple usage	Headers, buttons, links, accents, backgrounds	Single primary CTA per screen only
Visual coverage	~40% of screen elements used purple	~5% of screen elements use purple
User perception	TODO: Quote from testing	TODO: Quote from testing
Cognitive load	Multiple competing focal points	Single clear action hierarchy
Harm mitigation	Purple overload could increase anxiety	Reduced stimulation, clearer path to safety

Avoid Harm Design Checks

This checklist is applied to every screen in SisterShield:

• No victim-blaming language in any text, label, or error message.
• No triggering imagery — all visuals are abstract, positive, or neutral.
• Quick Exit is visible and meets accessibility tap target size (WCAG best practice: 44px).
• Crisis resources are accessible without navigation.
• Color contrast meets WCAG AA (4.5:1 for normal text, 3:1 for large text).
• Non-color cues supplement all color-coded information.
• No auto-play media that could attract unwanted attention.
• Session behavior is safe — Quick Exit clears state.
• Error messages are supportive, not blaming (“Something went wrong” not “You made an error”).
• Data collection is minimal and justified.

Documenting Harm Checks

For each screen, complete this checklist and store the results. This creates a paper trail showing that Avoid Harm was systematically applied, not an afterthought.

---

Decision C: Technical Learning to Semantic Token Architecture

Rubric Categories: Technical, Growth & Perseverance

What Are Semantic Tokens?

Semantic tokens are design system variables named by purpose, not by appearance:

Raw Token	Semantic Token	Usage
purple-600	--color-primary-action	The single primary CTA on a screen
gray-100	--color-surface-calm	Default page backgrounds
gray-700	--color-text-body	Body text
red-500	--color-feedback-error	Error states
green-500	--color-feedback-success	Success states
amber-500	--color-feedback-warning	Warning states

Why Semantic Tokens Are Scalable

1. Theme changes without component refactoring: To create a high-contrast theme, remap --color-surface-calm from gray-100 to white and --color-text-body from gray-700 to black. No component code changes.
2. Consistent behavior: Every component that uses --color-primary-action automatically updates when the token value changes.
3. Documentation as code: Token names are self-documenting — a developer reading --color-feedback-error knows the intent without checking a style guide.
4. Onboarding: New contributors (or future team members) can understand the design system from token names alone.

Technical Video Talking Points

When presenting the semantic token architecture in the technical video:

• Show the token definition file and explain the naming convention.
• Demonstrate a theme switch by remapping tokens (e.g., calm mode to high-contrast mode).
• Explain how this connects to the trauma-informed design rationale.
• Highlight this as a technical growth area — learning to build scalable design systems.

Growth Narrative

TODO: Document the learning journey from inline styles or utility classes to a semantic token architecture. What resources were studied? What mistakes were made? What is the result?

---

Decision D: Growth & Perseverance to Before/After Paper Trail

Rubric Category: Growth & Perseverance

Before vs After Template

Each Before/After entry demonstrates a specific improvement:

Field	Content
Issue	TODO: What was wrong? Be specific.
Discovery Method	TODO: User testing, self-review, mentor feedback, analytics?
Hypothesis	TODO: What change would fix it, and why?
Before	TODO: Screenshot, code snippet, or description
After	TODO: Screenshot, code snippet, or description
Outcome	TODO: Qualitative (user feedback) and quantitative (metrics) results
Commit/PR	TODO: Link to the specific code change

Challenge & Ambiguity Log Template

For moments where the right answer was not obvious:

Field	Content
Challenge	TODO: What was the problem?
Ambiguity	TODO: Why was there no clear right answer?
Constraints	TODO: Time, tech, design, ethical limitations
Option A	TODO: First alternative considered, with pros/cons
Option B	TODO: Second alternative considered, with pros/cons
Option C	TODO: Third alternative (if applicable)
Decision	TODO: What was chosen and why?
Learning	TODO: What transferable insight was gained?

Quality Over Quantity

Three deeply documented challenges are more impressive than ten shallow ones. Show genuine difficulty, honest reasoning, and real learning.

---

Decision E: App Function to Quick Exit Validated

Rubric Categories: User Experience, Avoid Harm, Technical

Why Quick Exit Is Critical

For users who may be accessing SisterShield while being monitored by an abuser, the ability to instantly leave the platform is not a convenience feature — it is a safety feature. Quick Exit must be the most reliable, most discoverable, and fastest interaction in the entire application.

Quick Exit Validation Checklist

Check	Criteria	Status
Global accessibility	Quick Exit button is visible on every screen without scrolling	TODO
Priority hierarchy	Quick Exit is the most prominent safety control, visually distinct from other buttons	TODO
Click behavior	Redirects to weather.com (plausibly innocent external site)	TODO
Session clearing	Authentication session is cleared on exit	TODO
Limitations disclosed	Tooltip explicitly states: “Cannot erase browser history”	TODO
Keyboard shortcut	Escape key triggers Quick Exit	TODO
Dialog guard	Confirmation dialog prevents accidental activation from Escape key	TODO
Response time	Sub-1-second from key press/click to navigation	TODO
Mobile accessibility	Button meets accessibility tap target size (WCAG best practice: 44px) on mobile	TODO
Screen reader	ARIA label: “Quick Exit — leave this site immediately” (or equivalent)	TODO

Usability Test Task

Task: “Without any instructions, find a way to quickly leave this website.”

Success criteria: User finds Quick Exit within 5 seconds.

Result: TODO: Completion rate, average time, participant feedback.

Demo Video Integration

Quick Exit appears in two scenes of the demo video storyboard:

• Scene 1: Landing page Quick Exit button click (demonstrates the feature exists).
• Scene 8: Escape key shortcut from any screen (demonstrates keyboard accessibility and speed).

Keyboard Shortcut Implementation

Key	Behavior	Guard
Escape	Opens Quick Exit confirmation dialog	Dialog prevents accidental exit
Enter (in dialog)	Confirms exit, redirects to weather.com, clears session	Only active when dialog is open
Escape (in dialog)	Dismisses dialog, returns to current screen	Prevents double-Escape exit

---

Decision F (Senior): Entrepreneurship to UX Changes Tied to Growth

Rubric Category: Entrepreneurship

Linking UI Refactors to Business Metrics

For the Senior Division, judges want to see that UX changes are not just user-driven but also connected to acquisition and retention.

UI Change	User Feedback Driver	Business Metric Impact
TODO: Change description	TODO: Testing cycle data	TODO: Expected impact on registration, retention, or course completion
TODO: Change description	TODO: Testing cycle data	TODO: Expected impact
TODO: Change description	TODO: Marketing data	TODO: Expected impact

Funnel Metrics Placeholders

Funnel Stage	Metric	Baseline	After Change	Delta
Awareness	Unique visitors	TODO	TODO	TODO
Visit	Time on landing page	TODO	TODO	TODO
Register	Registration conversion rate	TODO	TODO	TODO
Start Course	First course start rate	TODO	TODO	TODO
Complete	Course completion rate	TODO	TODO	TODO
Return	7-day return rate	TODO	TODO	TODO

Marketing Experiments Log

#	Experiment	Hypothesis	Channel	Result	UI Change Made
1	TODO	TODO	TODO	TODO	TODO
2	TODO	TODO	TODO	TODO	TODO
3	TODO	TODO	TODO	TODO	TODO

See Marketing & Feedback Integration for the full marketing strategy documentation.

---

Decision G: Global Framework to Global Safety Footer + SDG Mapping

Rubric Categories: Ideation/Potential Impact, Avoid Harm

Global Safety Footer Specification

The Global Safety Footer ensures that internationally credible crisis resources are always visible, regardless of where the user is in the application.

Placement: Every major screen — landing page, dashboard, course player, course listing, profile.

Resources:

Resource	Contact	Type
UN Women	unwomen.org	Global information and advocacy
StopNCII.org	stopncii.org	Non-consensual image removal
Crisis Text Line	Text HOME to 741741	US/UK/Canada/Ireland crisis support
NNEDV Safety Net	techsafety.org	Tech safety for survivors
Women’s Emergency Hotline (Korea)	Call 1366	Korea crisis support

Wording Guidelines:

• Empowering: “Resources are here when you need them.”
• Non-triggering: No graphic descriptions of violence types.
• Action-oriented: “Talk to someone” not “Report your abuse.”
• Non-judgmental: No implications of fault or weakness.

Footer Discoverability Evidence

Test	Method	Result
Can users find the footer without prompting?	TODO: Usability test	TODO
Do users understand the resources listed?	TODO: Comprehension check	TODO
Does the footer feel safe (not alarming)?	TODO: Subjective feedback	TODO
Is the footer accessible on mobile?	TODO: Device testing	TODO

SDG Mapping Summary

The feature-to-SDG mapping is fully documented in the Global Framework & SDG Alignment page. Key mappings:

• Interactive courses to SDG 5.2 (eliminate violence against women)
• AI content generation to SDG 5.b (technology for empowerment)
• Crisis resources to SDG 16.2 (protect children from abuse)
• i18n to SDG 16.10 (public access to information)

---

Decision Summary Matrix

Decision	Primary Rubric	Secondary Rubric	Evidence Status
A: User Feedback Loops	User Experience	Growth	TODO
B: Calm Color System	User Experience	Avoid Harm	TODO
C: Semantic Tokens	Technical	Growth	TODO
D: Before/After Trail	Growth & Perseverance	—	TODO
E: Quick Exit Validated	User Experience	Avoid Harm, Technical	TODO
F: UX-Growth Link	Entrepreneurship	User Experience	TODO
G: Global Safety Footer	Potential Impact	Avoid Harm	TODO

Complete All Evidence

Every TODO in this page must be filled before submission. This page is the single most comprehensive evidence document for judges — incomplete entries undermine the entire scoring strategy.