I redesigned a cabin-rental website and booking journey inside LiveRez templates I could not restructure. Through UX strategy, prototyping, custom CSS, and publishing guardrails, I launched a clearer experience in four months.
See Figma slideshow
New owners acquired a respected mountain-cabin business while transitioning from manual reservations toward digital-first booking. They had already selected LiveRez, which offered essential reservation functionality but rigid Bootstrap templates, limited metadata, and restricted page control.
I redesigned the layers available to us: brand application, information hierarchy, property discovery, content patterns, responsive presentation, custom CSS, and the owner-vendor workflow. The experience launched before the first peak season under new ownership, while reusable patterns and clearer review boundaries reduced revision cycles by approximately half.
Problem
New ownership was already moving the business toward digital-first booking
The owners inherited high-quality properties, an established reputation, and a reservation process still dependent on phone calls and manual credit-card handling. They selected LiveRez to provide real-time availability, reservation management, and listing content. The transition created an opportunity to make online booking central to the operation. The work needed to launch before the first major season under new ownership.
[Asset: Manual reservation model → LiveRez-supported operation.]
The locked platform and open-ended review process slowed the transformation
LiveRez offered aging Bootstrap templates, limited content controls, exposed CSS, and little authority over the booking architecture. Many competitors used similar templates, making differentiation difficult.
The owner was deeply involved and had direct WYSIWYG access. He preferred to revise copy personally and frequently applied heavy bolding, capital letters, red text, and yellow highlighting. When everything demanded attention, genuinely important information lost hierarchy.
Weekly conversations with the LiveRez representative also generated new questions and suggestions. Without firm decision boundaries, the scope remained open and tasks for both designer and vendor developer were repeatedly reconsidered.
[Assets: Competitor templates; original experience; editable-versus-locked layers; examples of hierarchy drift.]
insight
⇪ Back to Top | ⇦ Previous | Next ⇨
Which parts of the guest journey could be improved within the platform’s constraints?
I spent two nights at a property while helping migrate reservation data, interviewing the owners and staff, and observing how bookings were processed. Historical analytics revealed differences by age and behavior. I reviewed new versus returning guests, phone-first versus digital-first customers, local versus out-of-town visitors, mobile use, payment preferences, and abandonment patterns. Competitor analysis showed how strongly LiveRez’s default structure shaped the regional market, while Lighthouse testing established technical performance baselines.
[Research assets: Analytics segments; competitor audit; Lighthouse baseline; booking observation; platform-constraint map.]
Digital-first guests were abandoning before the business could earn their confidence
Younger and mobile-oriented visitors were leaving the experience disproportionately early. The digital interface was filtering out the audience the new operating model most needed. The research also showed that one universal path would not serve everyone. Returning guests still valued phone support, group organizers needed flexible payment and communication, and out-of-town guests needed dependable directions through mountain roads.
The opportunity was therefore not to remove every traditional channel. It was to make digital booking credible while preserving human options for users who valued them.
Jobs to be done: When guests plan an important trip, they need to understand property differences, price, availability, logistics, and the booking process quickly enough to commit confidently. When owners maintain listings, they need predictable structures that protect presentation and search quality without requiring a designer for every edit.
Jan
Jordan
Steve
decision
⇪ Back to Top | ⇦ Previous | Next ⇨
I improved every controllable layer instead of waiting for a more flexible platform.
I considered three realistic directions:
- Apply minor styling and accept the default experience.
- Improve photographs and property descriptions while leaving booking presentation largely unchanged.
- Redesign the full controllable journey through brand systems, content architecture, prototyping, and custom CSS.
Design tension: The booking experience needed to feel distinctive and trustworthy despite a rigid platform, limited structural control, and direct owner-managed publishing.
I chose the third option.
- Prioritize discovery, comparison, and booking.
- Make the identity modular.
- Prototype outside LiveRez.
- Use CSS as a system layer.
- Protect owner-managed content.
- Preserve useful phone support.
- Establish clearer decision and scope boundaries.
The tradeoff was accepting structural limitations in exchange for speed, maintainability, and a viable launch before peak season.
[Decision asset: Controllable versus locked layers with chosen interventions.]
Solution
⇪ Back to Top | ⇦ Previous | Next ⇨
I made the brand usable within a rigid platform.
The inherited identity was dated, while the replacement logo introduced constraints through a crest, multiple typefaces, and fixed text. I separated the identity into reusable elements and built prototype controls so the owner could compare arrangements in context. I also tested the About-page voice with local residents. Their feedback prompted a shift toward stewardship and community partnership.
I prioritized the path from discovery to booking
I organized pages according to their role in selecting and reserving a property rather than reproducing competitors’ navigation. Search, comparison, availability, pricing, and booking actions gained prominence. Secondary promotional content moved out of the primary path. Research became feature decisions: retain phone booking, support communication preferences, accommodate group payments, provide safer directions, and clarify property differences.
- Guest booking-journey map
- Annotated property-search page
- Listing or availability interface
- Original manual credit-card process beside the revised experience
I turned custom CSS into a lightweight design system
I wrote a custom CSS layer over the Bootstrap templates. Brand and utility colors became variables, while typography, spacing, controls, links, filters, and recurring regions gained consistent rules. The Webflow prototype functioned as the visual specification and vendor handoff. CSS carried those decisions into production. This turned overrides into a lightweight governance layer for a platform without native design-system support.
[VISUAL: Pair a CSS-token excerpt with the resulting interface component. Avoid using code alone; always show the user-facing consequence beside it.]
I protected the experience after handoff
The WYSIWYG portal allowed direct editing, but manual formatting could quickly dilute hierarchy through excessive emphasis, all-caps text, harsh colors, and highlighting. I established rules for headings, images, descriptions, links, calls to action, and reusable content sections. The prototype remained the shared reference, while CSS absorbed presentation decisions that should not depend on manual styling. These guardrails reduced the number of design choices required for each listing and helped the experience remain coherent after handoff.
Recommended assets:
- Editable-versus-locked platform layer diagram
- Content-entry or formatting guide
- Reusable property-content pattern
- Owner portal beside the resulting front-end page
- Screenshot showing the site after owner-managed updates
- Annotated example of a content rule preventing layout or hierarchy drift
Suggested gallery caption:
Documented content rules and reusable CSS patterns helped the owners update property information without recreating the visual hierarchy for every listing.
collaboration
⇪ Back to Top | ⇦ Previous | Next ⇨
I delivered through prototype, Trello, vendor handoff, and browser-based implementation
Webflow provided a controlled place to test IA, brand arrangements, sections, and responsive behavior before translating decisions into CSS and vendor instructions. The owner and I used Trello to track deliverables, questions, responsibilities, and progress. This gave the project a shared operational view while the prototype preserved the current approved design direction. Reusable patterns reduced repeated review, and the site launched within four months.
[Delivery asset: Trello → prototype → vendor implementation → CSS QA.]
I aligned a highly involved owner and platform vendor around clearer boundaries
The owner was simultaneously learning the acquired business, migrating operations, and shaping a new brand. His hands-on style sometimes extended into task-level direction for both me and the LiveRez developer, while new questions introduced during vendor meetings kept decisions open. I responded with clearer responsibilities, prototype comparisons, reusable decisions, and firmer scope boundaries. I owned research, IA, UX/UI, brand application, Webflow prototyping, CSS, content standards, and vendor handoff. The owner retained business policy and final content authority; LiveRez retained booking logic and deployment control.
[Collaboration asset: Owner, designer, and vendor responsibility map.]
Validation
⇪ Back to Top | ⇦ Previous | Next ⇨
I tested decisions against behavior, owner review, and Bootstrap constraints
Validation included historical analytics, interactive prototype review, local feedback on brand voice, Lighthouse benchmarks, vendor feasibility, and post-handoff content observation. I used browser Inspect and DevTools to test CSS directly against LiveRez’s existing Bootstrap rules, diagnose cascade conflicts, and validate responsive behavior across templates. Trello provided a shared record of deliverables, review status, questions, and progress. The project lacked event-level funnel analytics, so conversion-abandonment claims should remain directional.
[Validation asset: Analytics, prototype review, DevTools testing, Trello acceptance, and durability checks.]
IMPACT
⇪ Back to Top | ⇦ Previous | Next ⇨
I launched before peak season with a maintainable digital booking experience
The site launched in four months, while reusable patterns and clearer review boundaries reduced revision-cycle time by approximately half. Guests gained clearer comparisons, filterable search, real-time availability, improved directions, and a more direct booking path. The owners gained a digital-first operating model and maintainable content structure. CSS and publishing guardrails differentiated the brand despite shared platform templates.
[VISUAL — IMPACT: Use a desktop/mobile before-and-after pair with annotations. The current before and after screens are visually similar at thumbnail size, so explicitly mark the improvements: removed editing artifact, clearer hierarchy, stronger availability controls, cleaner header, and preserved responsive behavior.]
Jan
Jordan
Steve
REFLECTION
Designing within a locked platform required equal attention to interface quality and decision governance
The project demonstrated that meaningful UX improvement does not always require control of the underlying product architecture. Information hierarchy, content structure, visual systems, custom CSS, responsive behavior, and clearer handoff practices materially improved the guest experience even though LiveRez’s booking logic remained fixed. It also showed that maintainability is partly an organizational design problem. The interface could not remain coherent through CSS alone if routine content editing continually reintroduced competing emphasis and formatting. The strongest long-term contribution was therefore not any individual page. It was the combination of reusable interface rules, owner-facing content guardrails, and clearer boundaries among the owner, designer, and platform vendor.
I would defend governance, measurement, and platform boundaries more firmly
- Advocate more strongly for hands-off visual formatting. I would more clearly explain—and formalize in the engagement—that owner access to copy should not imply unrestricted control of typography, color, emphasis, and layout. Excessive bolding, all-caps text, harsh red, and yellow highlighting weakened the hierarchy and made genuinely important information less visible.
- Separate content authority from presentation authority. The owner should retain control of business facts, policies, property descriptions, and final messaging, while the design system governs how that information is visually expressed.
- Enforce firmer scope and decision controls. Weekly vendor meetings repeatedly introduced new questions and ideas that reopened prior decisions. I would establish clearer acceptance criteria, change-request rules, and decision deadlines to prevent the project from remaining perpetually exploratory.
- Instrument the booking funnel. I would track search behavior, property comparison, availability checks, booking initiation, abandonment, and completed reservations rather than relying on bounce rate and qualitative evidence.
- Plan platform migration before CSS reaches its limit. Custom CSS was an effective bridge, but it could not resolve inaccessible booking architecture, limited analytics, or uncontrolled WYSIWYG behavior. I would define the thresholds that should trigger migration to a more flexible platform.