• Competing entry points: Three separate planning paths (Request a Quote, Design Your Own, Instant Packages) with no shared structure, leaving users unsure which to use.
• Trust deficit: The outdated visual design undermined confidence for an expensive, considered purchase.
• Scope mismatch: The site read like a basic tee-time booker, not a full trip-builder covering golf, lodging, and rental cars together.

• One clear, unambiguous entry point instead of three competing paths
• A modernized visual system that earns trust for a high-cost purchase
• A structure that scales across golf, lodging, and rental car booking together
• Wireframe-first process to validate flow logic before visual design

• Visibility of system status — the four-step checkout (Traveler → Review → Payment → Confirm) keeps users oriented on exactly where they are in a longer process.
• Recognition over recall — the "Design Your Own" builder shows real course and lodging photography rather than requiring users to remember or look up options from a plain list.
• Consistency and standards — the redesign matches the linear, single-destination booking pattern used across mainstream travel sites (the Airbnb reference point), rather than introducing a novel interaction pattern GolfPac's users would need to learn.
• Error prevention — resolved directly in the checkbox-vs-linear decision: a linear flow structurally prevents the confusion of comparing incompatible multi-destination inventories at once.

This is a real evaluation method, just not a substitute for actual user testing — worth being clear that these heuristics informed design decisions, they didn't validate them against real behavior.

• Findability: A single, unambiguous entry point (segmented tabs: Request a Quote / Design Your Own / Instant Packages) replacing three disconnected paths.
• Linear Destination Selection: One destination at a time, matching how users already book complex trips elsewhere.
• Progressive Checkout: A four-step flow (Traveler → Review → Payment → Confirm) breaking a dense form into a clear, trackable sequence.
• Trust-Building Visual System: Real photography, a modern cyan-accented brand system, and reassurance microcopy at the exact moment checkout hesitation would occur.

• Design decisions were made with implementation cost already in view. When I explored the Destinations page layout, I already knew what restructuring the underlying AngularJS controllers would require — so trade-offs between "ideal" and "buildable" happened in the same pass, not as a negotiation between a designer and a separate engineering team afterward.
• The component system doubled as both a design system and a codebase. Reusable UI patterns (cards, filter chips, step trackers) were built once as both a visual standard and an actual Angular component, rather than a Figma library that engineering had to reinterpret.
• Iteration was faster because there was no handoff queue. A design change didn't wait for a sprint planning cycle to reach an engineer — I could validate a design decision by actually building it and seeing how it held up with real content and real interaction, then adjust immediately.
• I restructured existing AngularJS controllers directly as part of the frontend modernization work, improving maintainability alongside the visual and UX changes — meaning the redesign wasn't just skin-deep, it touched the underlying code structure too.

The trade-off worth naming honestly: working solo across both roles meant I didn't have a second engineer's perspective checking my technical decisions the way a real design-engineering pairing would — something worth being aware of as a limitation of the solo-freelance structure, even though the tight design-build loop was a genuine advantage.