Aiden App UX Improvements

A collection of UX improvements shipped or planned for the Aiden wedding planning app, covering mobile responsiveness, accessibility, onboarding, inclusive language, and date logic validation. These changes reflect a deliberate shift from feature development toward stability and polish.

Mobile Responsiveness

All phone-screen layout issues have been resolved. The fix was validated using an automated Playwright tool that renders screenshots across every possible screen size and checks for overflow, horizontal scrolling, and other layout breaks.

• All layout errors are now resolved
• Karly to test on phone and iPad to confirm from a real-device perspective
• One remaining minor stacking issue on the homepage when the sidebar is collapsed — flagged for a quick fix

Accessibility

The Playwright tool also surfaced accessibility warnings:

• Low contrast: Light purple text on a champagne background does not meet contrast thresholds for users with low vision. The purple should be darkened.
• Small text: Several areas use text that is close to the minimum readable size.

The app currently passes accessibility checks, but these items are flagged as "close to the edge" and should be addressed before a wider launch.

Onboarding Walkthrough

New users land in a collapsed admin dashboard that can be disorienting. The agreed approach:

• Keep the sidebar collapsed by default (cleaner initial experience)
• Add a first-time user walkthrough that highlights key sections (tasks, vendors, budget, guests, website) so users understand what's available without having to discover it themselves

This mirrors a pattern common in competing wedding apps and directly addresses UX feedback from the competitor analysis.

Inclusive Language

The app previously used "bride" and "groom" throughout. This has been updated:

• All partner references now use gender-neutral "partners" language
• This accommodates same-sex couples and non-binary users — estimated to represent ~20% of the wedding market
• Future consideration: allow couples to self-select their preferred terminology during onboarding setup (e.g., "bride & groom," "groom & groom," custom), which would then propagate through the app

Wedding party roles (bridesmaids, groomsmen) are a related area — current trends include "groomsmaids" and "bridesmen" crossing sides, which the role system should eventually support.

Date Logic & Validation

Multiple date fields exist across the app (wedding date, rehearsal dinner, ceremony, etc.), and previously there were no rules preventing illogical entries. Two improvements were shipped:

1. Validation rules — prevents impossible date combinations (e.g., rehearsal dinner scheduled after the wedding)
2. Cascading date updates — when a key date (e.g., the wedding date) changes, the system warns the user that dependent dates will also need to be updated and guides them through the adjustment

Karly to test the date integrity and warning flows and send feedback to Mark.

RSVP QR Code Logic

The current system generates a unique QR code per guest, which works well for digital invitations but is impractical for printed physical invites (each invite would need to be individually printed with a different code).

Proposed solution: Add an option for a single event-wide QR code that prompts guests to enter their name when they scan it to RSVP. This mirrors how most physical wedding invitations work in practice.

Both modes (per-guest and per-event) could be offered as options. Per-guest codes remain valuable for digital sends where tracking individual opens matters. Mark to investigate and propose an approach.

Related

• ^[1] — client overview
• ^[2] — new backend control panel
• ^[3] — CI/CD and test coverage context
• ^[4] — source meeting notes