Skyline Mountain Guides is a premium alpine guiding service built around safety, approachability, and genuinely fun days in the mountains. I led an end-to-end redesign and rebuild of their website, turning an outdated WordPress setup into a scalable Framer CMS and a booking-forward trip library. I also helped implement Flybook as their booking system so users could book trips directly instead of emailing back and forth.
How might we help climbers find the right trip and book confidently, while giving a small guiding team a system that scales from a few trips to 60+ without manual page builds?
My design approach: Conducted a heuristic audit of the existing WordPress site and benchmarked premium adventure brands to understand discovery and trust patterns. Used insights to build a CMS-first Framer rebuild, then iterated through real-content testing and QA to refine filtering and booking.
My Role
UX/UI Designer
Framer Developer
DURATION
3 Months
Tools
Figma
Framer / CMS
Adobe Illustrator
Adobe Photoshop
Flybook
React
WordPress
Website Design
CMS
Content Strategy
Responsibilities
I led the end-to-end redesign and rebuild, from discovery and IA to UI design and Framer development. I implemented a CMS-first trip system, collaborated on the filtering component, and owned the booking flow, QA, and launch.
DELIVERABLES
I shipped a full Framer rebuild with a scalable CMS, trip templates, region + trip-type filtering, site search, and supporting pages like Guides and About pages. I also implemented Flybook booking and built a custom handoff component to route users clearly between group and private options.
BUSINESS OBJECTIVES
Skyline needed a website that could scale from a few trips to 60+ without manual page builds and make it easy for customers to find the right trip and book online. The goal was to reduce support emails while presenting a premium, trust-first brand experience.
Impact at a glance
665
Increase in completed bookings
by improving trip discovery and creating a clearer, booking-forward path into Flybook
68
Trips in CMS - up from 3
by building a CMS-first content model and reusable trip templates that scale without manual page builds
85
Fewer support emails
by answering the most common pre-booking questions directly on trip pages and clarifying the booking path
Days
Min
Trip publishing time
by turning trip creation into a structured CMS entry instead of designing and formatting pages manually
Problem
The website didn’t match the product with scattered trip info, no structured discovery, and a manual booking process that created friction and support overhead.
Solution
A premium, booking-forward experience built in Framer with a scalable CMS, region + trip-type filtering, and Flybook booking to reduce confusion and increase conversions.
Problem
There was no structured way to explore trips by filtering. Users had to bounce between pages to find what fit, which slowed down decision-making and booking momentum.
Problem
Trip pages weren’t built for decision-making. Key details like pricing, dates, and how to book (group vs private) were unclear, so users had to reach out before committing.
Solution
I created a CMS-driven trip template with a booking panel for group/private options, pricing, and dates, plus a sticky sub-nav that organizes the full trip details into clear sections.
The Problem
This indicated the trip discovery and decision experience wasn’t designed to support fast, confident booking, creating a clear barrier to scaling bookings without scaling support.
Land on site
Browse trips
Confirm fit and details
Book online
✕ Misaligned with a high-trust purchase, because users had to work too hard to find decision-ready details and a clear next step.
A guided climb is a high-trust, high-consideration purchase. Users need clear trip fit, decision-ready details, and a confident next step to book.
This indicated the trip discovery and decision experience wasn’t designed to support fast, confident booking, creating a clear barrier to scaling bookings without scaling support.
Needs clear prerequisites and reassurance
Weekend warrior
Needs fast comparison and quick booking
Needs speed and familiar booking flow
Booking a guided climb is a high-trust decision, and different users browse the catalog in different ways. Mapping key user types helped clarify what information needed to be surfaced earlier and more consistently across every trip.
Trip Fit
Is this right for my skill
level?
Prereqs + skill level
Duration + difficulty
Trip Details
What’s included + what to expect?
Itinerary + inclusions
Gear + preparation
How do I book and what dates, is it private/group?
Pricing + dates + CTA
Group vs private choice
When any of these are unclear, users hesitate, drop off, or email support.
How can Skyline’s website support a high-trust booking decision while scaling to 60+ trips without increasing operational overhead?
Help users find the right trip fast (region + trip type)
Make trip details decision-ready (fit, itinerary, gear, pricing, dates)
Enable confident online booking without relying on support emails
My Approach
I kicked off with a heuristic audit to identify usability gaps and found
3 key problem insights.
Fit wasn’t obvious
Prereqs, difficulty, and expectations weren’t consistently surfaced, so users couldn’t self-qualify quickly.
Discovery wasn’t guided
Without region + trip-type structure, users had to hunt and click around to find relevant options.
Booking wasn’t a confident next step
Booking relied on contacting the team, and the path to “Book” wasn’t obvious or consistent across trips.
I benchmarked three leading guiding sites to see how they handle trust, scannable trip info, and a booking-forward flow, then translated those patterns into Skyline’s templates and discovery system.
Rapid Ideation & Userflows
Insights from landscape research guided concept sketching, shaping landing navigation and trip detail pages.
I rapidly ideated on key problem areas using insights gained form high performing usability patterns found in landscape research.
UserFlow
Old browse-to-book flow created drop-off before booking
Original trip booking flow
Land on site
Browse trips
Confirm fit & details
Inquire to book
Users stalled at “confirm fit + details” when key info and booking steps weren’t consistent.
New flow supports fast discovery and confident booking
New trip booking flow
Land on site
Filter by region/trip type
Open trip page
Review key details
Choose group/private
View pricing + dates
Book via Flybook
The new flow reduces uncertainty by standardizing trip details and making the next step clear.
Wireframes
Structure before polish.
I translated the user flow into low-to-medium-fidelity wireframes to lock in the information hierarchy and template structure before moving into visual design. The goal was to make trip pages decision-ready and scalable, so every trip follows the same layout and users can find key details fast.
Module 1
Trip detail page template
Problem: Trip pages had no consistent structure, so users couldn’t reliably find key details and the team couldn’t scale content without rebuilding layouts.
Solution: I wireframed a repeatable trip detail template with a clear hierarchy (fit, details, preparation, itinerary, FAQs, booking) and modular blocks designed to map cleanly to CMS fields.
Module 2
Trip discovery + categorization
Problem: As the catalog grew, trip discovery became overwhelming. Without clear categories and a guided entry point, users couldn’t narrow options fast enough to stay in momentum.
Solution: I wireframed a category-driven discovery experience, including a homepage trip module and region + trip-type organization across the site, so users can explore naturally and find the right trip faster.
Validation & Technical Deep Dive
Catching constraints early, before they cost real time.
Wireframes helped me validate the core structure before investing in high-fidelity design and development. I used early walkthroughs to pressure-test the browse-to-book journey and catch constraints while changes were still cheap.
Early Validation Insight: Booking Handoff Constraint
I did validate the wireframes early through structured walkthroughs, both as a team and individually. The goal was to get fresh eyes on the flow, identify confusion points, and surface technical constraints before we committed to the final build.
What the walkthroughs revealed
The trip detail template could display both group and private options (pricing and dates), but it only supported one clear "Book Now" action. That exposed a real constraint: Flybook treats group and private trips as separate entries with separate URLs, so a single button couldn't reliably deep-link users to the correct checkout.
An early proposed workaround was to drop users into Flybook's all-trips list. But that would restart users mid-journey, break context, and introduce a high drop-off risk right at the most important funnel moment.
Problem: Annotated wireframe showing the booking handoff constraint — a single CTA needed to route to two separate Flybook destinations.
Design decision: Keep one CTA, route intelligently.
I kept one primary CTA to preserve clarity, and introduced choice only when the system required it.
Outcome
Custom React component
Catching this early prevented costly redesign and rework later in the build. The final experience preserves a single, consistent CTA pattern while still routing users to the correct booking destination — reducing confusion and protecting booking momentum during high-intent moments.
How I built and implemented it
I built a custom React component powered by two CMS fields: a group booking URL and a private booking URL. The routing logic works like this:
Both URLs exist → Clicking "Book This Trip" opens a modal where users choose Group or Private, then deep-links to the correct Flybook page.
Only one URL exists → The button deep-links directly — no extra step.
No URL exists → The component shows a fallback message (inquire for availability) rather than a broken or misleading CTA.
Solution: The custom booking handoff component — when both options exist, a modal lets users choose before deep-linking to the correct Flybook page.
I used AI to accelerate initial code scaffolding, but I owned the component logic, edge-case handling, debugging, and testing across real trip configurations in the CMS.
Consistency across dozens of pages.
I built a lightweight design system to keep the site consistent across dozens of trip pages and new supporting pages. The system defined typography, spacing, color, and reusable components so the experience stayed premium and scalable as content expanded.
Mood board
Setting the tone: bold, elevated, and natural
Atomic design system
3-tier token design system
High-Fidelity Designs
Refining hierarchy, tone, and trust signals.
After wireframes and early validation, I moved into high-fidelity designs to refine hierarchy, tone, and trust signals. The focus was making trip content scannable, guiding users through long-form details, and keeping the booking action clear at the right decision points.
Hero + key stats
Surfacing essential trip info (difficulty, duration, elevation) above the fold so users can self-qualify before scrolling.
Sticky sub-nav
A persistent navigation bar on trip pages that lets users jump between sections without losing context on long-form content.
CTA placement
Booking actions positioned at natural decision points — after key details, after pricing, and persistently accessible via the sub-nav.
Discovery modules
Homepage carousel and library layouts designed for browsing by region and trip type, optimized for both exploration and intent.
Outcomes
A scalable booking platform.
The rebuild turned Skyline's website into a scalable booking platform. Trips became easier to discover, easier to understand, and easier to book, while the team gained a CMS workflow that supports growth without manual page building.
665
Increase in completed bookings
by improving trip discovery and creating a clearer, booking-forward path into Flybook
68
Trips in CMS - up from 3
by building a CMS-first content model and reusable trip templates that scale without manual page builds
85
Fewer support emails
by answering the most common pre-booking questions directly on trip pages and clarifying the booking path
Days
Min
Trip publishing time
by turning trip creation into a structured CMS entry instead of designing and formatting pages manually
Reflection
What I'd do next.
This project reinforced how much "premium" is about clarity and consistency, not decoration. I'm proud of what shipped under real constraints, and the biggest improvement I'd make next is stronger instrumentation and structured usability testing now that the product is live.
What I'd improve with more time
Analytics funnel tracking — filter usage, CTA clicks, modal choices, Flybook outbound
Moderated usability testing — discovery, comparison behavior, sub-nav use, booking handoff
Use insights to prioritize Phase 2 content - expansion based on what users actually search for and where they stall