Senior Product Designer and Design Engineer based in Denver, Colorado. I design complex systems and build them in code, and I came up through marketing automation, which is product strategy with a funnel attached.
Spring '26 — Open to rolesResearch-informed interfaces and the systems underneath them. Enterprise platforms, regulated products, and the parts of the journey nobody wants to map.
Strategy + SystemsCuriosity. Collaboration. A stubborn habit of asking why one more time than is strictly polite. Lately — AI as part of the toolkit, not a replacement for craft.
Open to remoteI'm a Senior Product Designer and Design Engineer. Before product, I spent five years building marketing automation for companies like Intel, designing behavior-triggered journeys with complex segmentation and dynamic content, then instrumenting them and reporting on what actually moved the numbers.
That was product strategy in everything but name: funnels, systems, edge cases, and metrics. I carried all of it into design. Today I frame the why before the build, design the whole flow instead of a single screen, and prototype in code with AI as a collaborator. The strategy did not get left behind. It became the foundation everything else is built on.
From a young age I've been drawn to problem-solving — queue hours of MythBusters marathons. In college I realized that while becoming the next Adam Savage wasn't realistic, I could pursue a career that blended artistic influence with my analytical nature.
I'm first and foremost a team player. I like being set loose on my own for projects but always for the greater good of my coworkers. Constructive criticism pushes me to be better.
I actually enjoy critical thinking. I chalk it up to my love for problem solving — I may have wanted to major in criminology at one point.
35+ interviews, 370 insights, 4 drivers. The strategy is naming what’s actually holding the system up — and what isn’t worth fixing.
A blueprint sales, marketing, and product can all read stops alignment from being a meeting. The artifact does the work.
NN/g’s ten heuristics, applied with discipline, sort “this feels off” into prioritizable, business-aligned moves.
One product card. 13 toggles. 40+ permutations. Engineering implements once; product turns the dials.
Specs at refinement, bi-weekly engineering syncs, component usage held to in code. Process is a design surface too.
Findability ties to engagement. Hierarchy ties to conversion. The audit lands when leadership sees what it pays back.
AI runs through every stage now — research synthesis, strategic framing, and prototypes that drive stakeholder conversations before pixels harden. I work in code and in the terminal as fluently as I work in Figma. The question isn't can AI do this. It's where in the process does it compress time without compressing thinking.
370 raw notes, 35 interviews. AI helps cluster, surface frequency, pressure-test themes. The framing — what the data means, what to do about it — stays mine.
A thinking partner for systems work — pressure-testing operational models, naming the drivers under the noise, sharpening the recommendation before it hits a deck.
Built in code, not stitched in a no-code tool. From a Figma flow to production-fidelity HTML in a day — real states, real data shapes, real edge cases. This portfolio is exhibit A.
Real flows, real recoveries, built fast enough to walk through in a working session. Feedback gets specific. Dev gets a working spec, not a slide.
Designers are now building in code. Once you have 8 screens of it, there's no way to see the system. FlowScope is the zoom-out — assemble the flow, surface every state across viewports, present end-to-end, and hand off to dev with comments lifted back to Claude Code as code references.
She got hands-on with Claude Code alongside our senior engineers and built it into her actual prototyping workflow — producing interactive concepts at a fidelity that usually requires a developer.David MastersonSr. Director, Product Management · Exclusive Resorts
Anna was instrumental in revamping essential features of the new MOXé responsive platform — product cards, inventory, and list management. Exceptional grasp of UX fundamentals, strong product thinking, and a great eye for detail.Michael HelmanSr. UX Design Leader · US Foods
One of the rare designers genuinely fluent in the developer's world. She walked me through working prototypes built in our actual frontend stack, which made handoff conversations dramatically smoother.Hassan ShahzadFull Stack Software Engineer · Exclusive Resorts
Transitioning a traditionally offline customer base — restaurants, hospitals, hotels — to a digital-first ordering platform.
Post-COVID, US Foods needed to move a long-tail of foodservice customers from phone-and-fax ordering to a digital-first platform. MOXē became that platform — across web and native apps — for restaurants, hospitals, hotels, schools, and small operators.
I led design across the ordering, inventory, and reporting surfaces. I worked solo on the UX side embedded in a multi-pod engineering team, partnered with a single PM, and reported into the broader product design org.
The user base was unusually heterogeneous — a chef counting walk-in inventory on a phone, an accountant pulling end-of-month reports on a desktop, a kitchen manager re-ordering on an iPad in a service window. Designing for all three from one component system was the central technical and conceptual problem.
Three constraints stacked: a customer base that hadn't asked to go digital, an engineering velocity that wanted weekly releases, and a product surface that touched ordering, inventory, reporting, and account management across web, iOS, and Android. The design system had to absorb that variability without fragmenting.
I conducted user interviews across the customer types — chefs in walk-ins, accountants at desktops, kitchen managers on iPads — ran competitive teardowns of Amazon Business, Instacart, and Walmart B2B, and partnered with category PMs and the data team to ground assumptions in real ordering behavior.
The critical needs that surfaced repeatedly: fast re-order from history, flexible product representation (since the same SKU could behave differently across customer types), inventory visibility tied to ordering, and accessibility on the warehouse floor — high contrast, large touch targets, minimal typing.
Rather than redesigning surface by surface, I started with the most-shared component — the product card — and used its constraints to drive system decisions outward. From there: inventory, count mode, and reporting.
The same product card had to render for a single SKU, a multi-pack, a substitution suggestion, an out-of-stock state, a price-locked promo, a customer-specific contract item, and several others. I built a single Figma component with 13 toggles producing over 40 valid permutations — every permutation accounted for in design tokens, spacing, and accessibility tree.
Engineering implemented one card; product turned the toggles. The leverage was enormous: a new card type became a flag, not a redesign.
Inventory was the surface most tied to physical context. Most users counted stock on a phone in a walk-in or pantry. I rebuilt the experience mobile-first, with progress trackers, drag-and-drop reordering of count lists, an offline-tolerant draft state, and a simplified count mode that stripped chrome down to the count action and a back button.
For multi-select edit on count lists, I borrowed the long-press-to-select pattern from Squarespace's editor and the floating action toolbar from LinkedIn's saved posts — both already familiar to a wide swath of users. Every gesture had a visible button equivalent so the pattern stayed usable for members who couldn't or wouldn't use long-press.
Customers often tracked items they bought outside US Foods — produce from a local supplier, paper goods from Costco. I designed a distinct "non-US Foods" item type so members could mix supplier sources in one list while the data model and the UX both stayed honest about origin.
The All Inventories landing page needed cards that summarized each inventory at a glance — before a user drilled in. Each card had to surface the right hierarchy without becoming dense: inventory name, creation date, total value, line-item count, last-updated metadata, completion status. I iterated through several variations on the treatment before landing on a layout that read fast on mobile and still held its hierarchy on desktop — with state (Completed) made legible via a vertical tag rather than a buried label, and the line count and total value paired in a way that scanned in one glance.
Alongside the card work, I updated the PDF export of inventory reports for readability — paring back the digital chrome that competed with the data when printed.
Throughout the project I kept design two sprints ahead of dev, posted detailed design links on tickets at refinement, and held a bi-weekly walkthrough with engineering to keep component usage consistent. The work was solo on the design side; the leverage came from process.
MOXē shipped on schedule across web and both native apps, with the product card system absorbing every new SKU pattern through the toggles rather than design rework. The team reported inventory engagement climbing once count mode landed, and the bi-weekly engineering syncs became a model for the broader design org.
The project taught me that on a regulated, slow-moving customer base, the win isn't the redesign — it's the component decisions that make the next ten redesigns cheap. The single product card with 13 toggles is the artifact I'm proudest of; the process that kept design ahead of dev is the muscle I rely on most now.
Six months at a healthcare client serving Medicare and Medicaid members — one IA strategic initiative and six feature design efforts across two platforms that had been designed and built in isolation, for a member base that ranged widely in digital comfort.
Healthfirst is a nonprofit health insurance provider serving Medicare and Medicaid members in New York. I came in as a UX designer on the team responsible for member-facing digital experiences across both the mobile app and the desktop portal, working with a Lead Designer and a UX Researcher. Over roughly six months, I worked on a series of design initiatives — one focused on strategic information architecture and member research, and six separate feature design efforts.
The unifying thread wasn’t a single design problem. It was the client and the user base. Members spanned a wide range of digital comfort levels — older Medicare members in particular — and they were navigating a fragmented experience where mobile and desktop had been designed and built by different teams without visibility into each other’s flows. Every initiative I worked on served the same goal of improving member access. But the initiatives were separate bodies of work, not one connected redesign.
The IA work started as a focused card sorting exercise with 30 members — 3 Medicaid, 15 Medicare, 12 Commercial — recruited through Sago, plus a short questionnaire to gather feedback on the experience. The brief was straightforward: validate the existing sitemap against member mental models and recommend updates.
The analysis revealed something bigger. Category alignment across the existing structure never exceeded 52% — Rewards 52%, Payments 43%, Find Care 30%, Communication 27%. Specific items split predictably across categories that didn’t map to how members thought: Pharmacies split 50/50 between Find Care and OTC, Medication Finder ended up across three categories. The accessibility problem was concrete — “My Plan” was only accessible through the Customer Center, not on mobile, which caused systematic confusion. And the member quotes were direct in ways the metrics weren’t.
“Paying bill is a task now we are getting older to go through so much it’s not good on our brains please do something and make it easier for us thank you.”
Working with the UX Researcher, we analyzed the data together and produced new member-based sitemaps for every section of the portal — My Plan, My Health, Find Care, Communication, Rewards, Payments, Profile, OTC. The recommendations grouped into three areas: continuity across experiences (consistent language and UX across platforms), closing UX gaps (enhanced feature organization to match member expectations), and a full IA rebuild with reflected redesign. Each recommendation had a sprint-level effort estimate so the team could prioritize quick wins (renaming “Utility Payments” to match Customer Center language) against the longer work (an IA update with subsequent redesign at 8+ sprints).
As we developed testing guides to validate the new IA, the scope expanded. I stepped back and built a strategic UX deck — Designing for Clarity: IA, Research, and Experience — making the case that IA alone wouldn’t deliver the outcomes the business needed. The deck framed a 5-pillar approach: information architecture, user research and data analysis, visual and interaction design, validation, and implementation and iteration. It integrated a quantitative ROI model the UX Researcher had built — $14,395/month in potential support cost reduction tied to findability friction — as part of the business case. It cited industry benchmarks. It advocated for research-based personas to replace the proto-personas we’d been working from, with a clear comparison of what each type was good for. And it documented what had been completed against what still needed funding.
Not all of it got approved. Card sorting and proto-personas were already complete. Survey work ran. The full research-backed personas didn’t get funded. Tree-testing and content audits were scaled back. I shipped what was approved and documented the rest as foundation for whoever picked it up after I left.
Six feature design efforts ran in parallel during the engagement, each with its own scope, timeline, and constraints. Each one touched the coordination gap from Section 01 from a different angle. The senior judgment in this body of work isn’t in a single decision — it’s in where I chose to invest depth versus where I scoped tight.
Prioritization across feature deployments was the work behind the work. With multiple features running in parallel against shared engineering capacity and stakeholder attention, where to spend prototype time, analysis time, or workshop time was a daily judgment call. Twenty prototypes for LexisNexis was a deliberate over-investment. Tight scoping on OTC was a deliberate under-investment. The depth profile across the six efforts wasn’t accidental.
Payments — deep research analysis on native vs. responsive hosted. The mobile native flow had diverged from the desktop flow. I compared them side by side in design and production states, mapped gaps and opportunities for unification, and produced high-fidelity mockups for a unified web-hosted-in-native-frame solution that preserved mobile-specific functionality. The analysis covered pros and cons of each approach — member experience implications, engineering implications, maintenance implications — and was the artifact that shaped the team’s decision to move toward the unified version.
LexisNexis 2FA — twenty prototypes across three workflows and three risk levels. Risk-based authentication needed to handle three workflows (new registration, returning login, forgot password) across three risk levels (low, medium, high). I built more than twenty functional prototypes covering the matrix so internal teams could test scenarios and finalize risk thresholds and routing. The deepest single-feature craft investment of the engagement.
Ride History — a tabbed approach for upcoming vs. past. Members could book rides to medical appointments but had no clear way to view, manage, or cancel them after booking. I designed a tabbed interface separating upcoming and past rides, with prototype behaviors that adapted based on ride status.
OTC Product Search — paused at the vendor handoff. The OTC search experience was hosted by an external vendor, which constrained what could be redesigned directly. I built a “dream state” vision and workshop materials to facilitate a future conversation with the vendor. The conversation paused before I could present. Scoping tight here mattered more than over-investing in something the org couldn’t act on — the dream-state vision stayed on file as a documented artifact for whenever the vendor conversation resumed.
Rewards — user flows across the earn-and-redeem ecosystem. The rewards experience needed to make member-earned rewards more visible — most members didn’t realize that joining (welcome checklist) and yearly (health checklist) activities returned cash back they could spend on OTC products and other categories, tied to healthy-lifestyle engagement with Healthfirst. The work spanned multiple connected flows: viewing checklists, checking off items, viewing earned and redeemed points, the redemption flow itself, and the redemption history. The defining design move was the diagramming approach — each flow as its own self-contained ecosystem with explicit decision points and named entry and exit nodes that linked to the other flows, rather than one tangled mega-diagram of cross-connectors. Cleaner handoff, every screen accounted for, no confusing web of arrows.
Two operational moves crossed the entire body of work.
The prototyping-standards partnership. Stakeholders had been requesting full functional prototypes even for minor UI changes, which created maintenance overhead and pulled designers away from new work. I partnered with another designer to establish a team-wide standard: full prototypes for end-to-end experiences, static mocks for minor updates. The standard was adopted across the team.
Cross-designer syncs. Mobile and desktop had been working without visibility into each other’s flows. I established regular syncs with the desktop designers to keep shared spaces aligned — payments, communication preferences, anywhere mobile and desktop touched the same data. Operational fix to a structural coordination gap rather than waiting for organizational change.
Ride History, Rewards, and the unified responsive-in-native-frame version of Payments were all developed. The LexisNexis prototypes helped internal teams test scenarios and finalize risk thresholds. The prototyping standards were adopted across the team. The cross-designer syncs continued.
The IA initiative landed differently. The strategic deck became a reference document the team would carry forward — exactly how far the recommendations got implemented after I left is uncertain. Card sorting and proto-personas were completed; the deeper research the deck advocated for didn’t get funded. The foundation was set; what got built on top of it is partly visible to me and partly not.
The honest acknowledgment about a multi-initiative engagement is that no single initiative had a quantified outcome I can claim. The Payments analysis shaped a development direction. The LexisNexis prototypes shaped risk thresholds. The IA deck remained a reference. The work spanned surfaces, feature complexity, and analytical depth — at a healthcare client where the work mattered for members who relied on getting the experience right.
The work that shipped is the work that shipped. The work that became reference material did its job.
Strategic UX audit of Ulta's mobile app using NN/g's framework, paired with competitive benchmarking against Sephora, Target, and Glossier.
I'm rebuilding this case study as part of the portfolio refresh. The short version: ten heuristics applied with discipline, five strategic opportunity areas, each tied to loyalty engagement and conversion impact. Full walkthrough available on request.
Request walkthrough →Replacing a fastest-finger booking race with a fairer, quarterly weighted lottery.
Exclusive Resorts is a private members-only luxury travel club. For years, members got access to high-demand and newly released vacation inventory through a system called “roll-in” — a fastest-finger race where everyone competed to book the moment dates dropped. The fix was a quarterly weighted lottery called the Reservation Allocation System (RAS): members submit a wishlist of destinations, rank them, allocate flat per-tier points to signal preference intensity, and a backend draw decides who gets what.
I led design across two surfaces: the member experience (a 3-step wishlist submission flow) and an ambassador dashboard concept that would plug into Compass v2, the existing internal operations platform, during quarterly RAS cycles. I worked the algorithm out on my own — five multiplicative factors, fairness boosts for repeat losers, penalties for repeat winners — synthesizing it from the stakeholder meetings and conversations shaping the solution, and built a working React prototype with AI as my dev collaborator that became the alignment artifact for stakeholder reviews, including a presentation to the member advisory board (MAC).
The members who won most consistently in the previous system — “roll-in,” a fastest-finger booking race — weren’t the ones who wanted the trip most. They were the ones with the most flexible schedules. The redesign couldn’t just be fairer; it had to give members real influence over the outcome, even though most of the actual fairness work would happen in a backend they’d never see.
That backend was a five-factor multiplicative weight — rank × points × tier multiplier × loss multiplier × recently-vacationed penalty — each with its own rules and edge cases. Plenty of moving parts. Stakeholders (product, the new president, eventually the MAC board) needed to commit to a direction before engineering could scope the build, and the conventional move would’ve been a Figma click-through with state mocked frame by frame. But you can’t really evaluate a system this dependent on live behavior — drag-to-rank, points reallocation, on-behalf flows, results acceptance — by clicking through static screens. The mock would’ve lied about what the experience actually felt like.
So I built it. React, Vite, Tailwind, dnd-kit, no router. AI was my dev collaborator — Claude Code for the architecture and component build, with me directing through detailed prompts and component specs. One designer’s pace ended up matching the team’s pace, because I wasn’t waiting on a separate engineer.
The prototype was built to drive conversation. A working, clickable system gives stakeholders something tangible to react to — and decisions move faster against a thing you can use than against frames you have to imagine. The architecture leans into that: a “Prototype” pill in the header (in case anyone forgot what they were looking at), and a mode segmented control between Member, Ambassador, and How it works so a single review could move between three audiences without me cracking open three different files. The destination experience inside it was designed for the three ways members actually find trips — open-ended browsing of inventory, targeted search by destination or dates, and curated slots for the trips the business wanted to surface or promote.
A working prototype built fast can still feel rudimentary in a stakeholder review if the visual layer isn’t there. I ran iterative AI-driven design critiques against the live prototype to pull brand fidelity up — square editorial markers replacing the checkout-funnel progress circles, an asymmetric featured hero in place of two equal-weight cards, a dark navy break in the destination grid. The brand work was secondary to the user flow, but it mattered for one specific reason: when stakeholders looked at the prototype, it had to feel like an Exclusive Resorts product, not a wireframe in costume.
What was inside the prototype mattered as much as the prototype existing at all. The hardest design problem was knowing what the interface should expose and what it had to rigorously hide. The challenge wasn’t choosing whether to show the algorithm. It was knowing exactly where to draw the line.
I picked a middle path: calibrate what the interface exposes (points budget, rank order, a strategy hint or two) and rigorously hide the rest (weight formulas, multipliers, loss boosts, demand modifiers).
The hardest design problems are the ones where the complexity has to be invisible.
The flexibility window is the agency lever I introduced for members. The previous system gave them no control at all. I added a date flexibility option — Exact, ±1 day, ±2 days, ±3 days, ±1 week — built right into the destination request flow. It looks like a calendar nicety. Mechanically, it’s how members tune their own match probability: loosening flexibility gives the lottery more options to match them, which materially improves their odds without exposing any of the math. A direct answer to the headline emotional problem with roll-in: “I never get my top destinations.”
The Sunday check-in tip. Operations had quietly known for years that requests starting on Sundays tended to match better — Sundays freed up more inventory than other start days. That kind of insight tends to live in tribal knowledge and ambassador conversations, not in the product where it could actually help anyone. I surfaced it in-context, inside the destination request flyout, framed as a tip rather than buried in a help doc. The member gets actionable information; the system doesn’t show its hand.
Specific-unit requests. Members can flag the specific units within a destination they’d accept, rather than leaving “any available unit” as the only option. The inventory for that property surfaces directly inside the request flyout, so members don’t have to leave the flow and dig through the portal to confirm a unit fits their party before submitting. The lottery match becomes the trip they actually wanted, not a near-miss they’ll have to sort out at confirmation.
The cancellation wishlist hook. The portal already had a cancellation waitlist for trips that opened up post-booking. When the prototype’s draw doesn’t grant a member’s request, the unmatched-result card surfaces a one-tap “Add to cancellation wishlist” action — the recovery path sits next to the loss instead of on a different surface. A member who didn’t win still has a clear way to grab the trip if someone else releases it.
The visible accept-by deadline. Once results run, members have a fixed window to accept their matched trips before the inventory is released back to the pool. The deadline timestamp sits on every won-result card and at the top of the results dashboard, so the accept-by timing is always in view — not buried in an inbox.
Members were one half of the prototype. Residence ambassadors were the other — they live in their internal operations platform, Compass v2, every day, but during each RAS cycle they need a clean, focused way to see what each of their member families is doing: who’s submitted, who hasn’t, who has results to accept, and who they’re going to need to act on behalf of. Two cadences, different surfaces, one underlying system.
The wrong move would’ve been to design the member flow first and then layer ambassadors on top as an internal admin view. That treats ambassadors as a second-class user, which they aren’t — for some members, the ambassador is how they interact with the company. The right move was to design members and ambassadors as one system with two lenses, sharing the same underlying request model but with different surfaces, attribution rules, and information density.
The ambassador surface gets a portfolio dashboard with status indicators, submission progress per member, and demand-tier badges visible only to ambassadors. (Members don’t see demand tiers for the same reason they don’t see the rest of the algorithm: exposing demand creates anxiety and invites gaming. Ambassadors need it as operational context.)
The interaction patterns are designed for trust because every ambassador action is on behalf of someone else with money and emotion at stake. The CTA wording is explicit: “Submit on Behalf,” “Accept on Behalf” — not “Submit” or “Accept” with an attribution footnote no one reads. The confirmation modals state plainly that the action is auditable and attributed to the ambassador, with the ambassador’s name visible in the same modal that previews what the action will do. When you act on someone else’s behalf, accountability isn’t a footnote — it’s the message of the screen.
Two architectural calls landed after I left. Both are invisible at the screen layer, and both are the work that survived past my exit.
The variable points architecture. Points are the explicit signal of preference intensity — members allocate them across ranked requests to say “this one matters more.” The business hadn’t actually decided the final points distribution model when I started, and there were a few competing proposals on the table. So I designed the architecture to be agnostic to specific values. The interface holds whatever the business decides — flat per tier, scaled to vacation days, scaled to membership type — without a redesign. The design didn’t have to wait on a business decision that wasn’t ready to be made.
The algorithm simplification. Working through the algorithm myself produced one simplification that landed in the next engineering spec revision: reclassifying property demand from algorithm input to analytics-only. The math showed that demand applied uniformly to every competitor for the same slot was neutral — it inflated all the weights equally and had zero effect on relative win probability. Removing it simplified the formula without changing any outcomes.
The clearest signal that the work landed is what happened next. The project was presented to the member MAC (Member Advisory Council) board as an upcoming feature on the way to a March 2027 first release. The next revision of the backend specification, written after my work, incorporated the design constraints I’d established — including the algorithmic simplification of moving property demand out of the formula. Engineering scoped the implementation against the prototype.
The honest acknowledgment: the project hasn’t shipped yet, and won’t until 2027. Several decisions stayed open at handoff, most notably the member-facing demand indicator, which was mine to help resolve. But none of that takes away from what the foundation enabled — the working alignment artifact, the stakeholder buy-in, the announced roadmap commitment. The project kept going without me, which is what a foundation is supposed to do.
Joining a private member community at MVP, doing end-to-end product strategy across two phases of growth, and shaping what the Clubhouse becomes.
I joined as the sole Sr. Product Designer in September 2025, after the Clubhouse MVP had launched feature-flagged to roughly 200 memberships — the Seabourn Once-in-a-Lifetime Journey cohort. The MVP was small by design: a landing page, a profile wizard, a member directory, a single discussion forum specific to the Seabourn cruise, a trip review tool, and a curated photo gallery from the journey. It was a controlled rollout meant to answer questions about whether members would complete profiles, use a directory, talk to each other on a board, and write reviews.
The next phase planned destination-specific discussion forums, but they wouldn’t live inside the Clubhouse. They’d live on Destination Pages out in the broader member portal, gated behind Clubhouse signup so members had to opt into the community before they could access the conversation. The gate was meant to drive Clubhouse signup. The forums were meant to drive value on Destination Pages.
But the Seabourn forum was going away. It was tied to a specific cohort and a specific cruise — once the next phase launched, it would be retired. That left a question. If the new forums get gated behind Clubhouse signup and the only existing forum inside Clubhouse is being removed, what does the Clubhouse itself become once members get there?
I went end-to-end. Full information architecture across what the platform needed to become, a feature analysis across two phases of growth — what would eventually be Phase 2 and Phase 3 — and a MoSCoW prioritization to figure out what shipped when. The analysis wasn’t about Phase 2. It was about the trajectory: where Clubhouse needed to land, what had to exist to get there, what could wait.
The MoSCoW buckets sorted features across the two phases. Must-haves for Phase 2 launch: the gated destination forums, member notifications, and — once the analysis surfaced the return-loop gap — the passion teaser and launch-stage My Feed. Should-haves: the full Golf Passion page, the Destination Pages tab restructure. Could-haves: Persons of Interest, additional Passion teasers. Won’t-haves for Phase 2: full personalization, Circles, and member-hosted flex — all sequenced into Phase 3 and beyond.
What the analysis surfaced about Phase 2, specifically, was straightforward. The planned scope — gated destination forums on Destination Pages, plus the retirement of the Seabourn forum — left the Clubhouse itself with marketing content, a profile wizard, and a directory. No reason for members to come back once they’d signed up to unlock the forums. The gate worked against the loop. Members would enter Clubhouse to access conversation that lived somewhere else, and then have nothing inside Clubhouse to return for.
I pushed for passion + My Feed to be added to Phase 2 alongside the gated forums. A passion page placeholder/teaser — not the full Passion experience that would ship later, but enough to signal to members that real interest-based community was coming. A My Feed inside Clubhouse that aggregated the most recent posts from across the destination forums, so members had a reason to open Clubhouse itself, not just the forums they’d signed up to reach. Phase 2 couldn’t be a phase 2 with nothing new in the actual Clubhouse interface. Passion teaser and My Feed are on the Phase 2 roadmap because of it.
The MVP had a single Seabourn forum living on a landing page. The architecture had to hold not just for Phase 2 but for what was already designed for Phase 3 and beyond. The work in this section is the design that flowed out of the strategic plan from Section 02 — the four-pillar IA that gave the Clubhouse a shape, the Passion pages that anchored the Phase 2 teaser, the Destination Pages recommendation that gave the new forums somewhere to live, and the Phase 3 Circles system designed in advance of build.
The four-pillar IA. I restructured the Clubhouse into four pillars: The Latest (the Clubhouse homepage, replacing the MVP landing page), Passions (interest-based community pages with their own forums and member tabs), Circles (private groups, designed for Phase 3), and The Editorial (curated member stories and editorial content). Each pillar had its own scope and content types, but they cross-referenced each other through contextual entry points — a Circle tied to a Passion surfaced on that Passion’s page, a post in My Feed routed back to its origin forum or Circle, content in The Editorial linked into the Passion or Destination it described. The original Seabourn discussion board, which had lived as a flat element on the MVP landing page, got moved out of Clubhouse and onto the Seabourn Destination Page where it belonged.
My Feed, staged for personalization. My Feed sits inside The Latest as the homepage stream — but the design wasn’t a mega-feed. Leadership had been clear that posting from a single all-content thread wasn’t a direction the platform wanted to go. The challenge was building toward personalization without giving members a flat aggregated stream, and without making them wait for full personalization to ship before anything useful appeared. I designed My Feed in three stages so that each phase delivered something concrete on its own while building toward an ideal state. Launch stage: My Feed surfaces posts happening across destination forums (tying the new gated forums into Clubhouse itself) plus notifications for engagement on the member’s own posts — destination-aware content and an engagement loop, but not personalization yet. Intermediate stage: as Passion pages roll out, My Feed adds posts from Passions the member follows; members start to opt into more interests, more groups, more Circles. Ideal state: a fully curated stream pulling from destinations the member has traveled to or favorited, Passions they follow, and Circles they belong to. Designed once and scoped so the launch stage could ship without the personalization infrastructure that wouldn’t exist for another two phases.
Passion pages, with Golf as the Phase 1 anchor. Golf was the first full Passion page — the model that future Passions (Wine, Wellness, Family Travel) would follow. Each Passion page carries a Discussion forum, a Members tab, and a conditional Circle tab that only appears when a member belongs to a Circle tied to that Passion. The Golf page included editorial content (golf-specific articles, a member interest list, exploration of a unique angle where members could flag willingness to host other members at their home country clubs), the discussion forum, and the conditional logic that would surface the eventual Phase 3 Golf Club Circles only to members who belonged to them. The Passion architecture was designed once to hold across every future Passion: same structure, different content.
The Destination Pages tab restructure recommendation. Destination Pages weren’t part of Clubhouse — they lived in the broader member portal. The existing pages used anchor-link navigation and were flooded with marketing content. Know Before You Go — the genuinely useful trip-planning information members actually needed — was buried as an accordion at the bottom of the page. When the team planned to add destination-specific forums to these pages, bolting them onto the bottom of a marketing-heavy anchor-link layout would have buried them too. I recommended restructuring the destination pages from anchor-link nav to a tabbed UI (Overview, Residences & Calendar, Trip Planning, Know Before You Go, Member Insights). Tabbed gave the forum its own dedicated home in the Member Insights tab. Tabbed gave Know Before You Go its own full tab where members could actually find and use it. And tabbed deprioritized the marketing content for an audience that’s already members — they’re deciding where to travel, not being sold on the brand. The recommendation was adopted. Costa Rica is the pilot.
Before — anchor-link nav, marketing-heavy long scroll. After — tabbed UI with Member Insights and Know Before You Go promoted to their own tabs. Costa Rica is the pilot.
The Circles system. Circles was Phase 3 work, designed in advance of build because the architecture wouldn’t hold without it. The trigger was a stakeholder request in early April 2026: a private, invite-only Golf chapter, the Denver Chapter. Ongoing, no end date, passion-linked, centrally managed membership. As more use cases stacked up — once-in-a-lifetime curated group trips with their own coordination thread, real-time in-destination meetups, eventually member-hosted groups like book clubs — it was clear that the originally-planned Events model couldn’t hold any of it. Events were rigid. The use cases needed flexibility across lifecycle (ongoing vs. time-bounded vs. ephemeral), governance (centrally managed vs. member-initiated), and linkage (passion vs. property vs. date).
The design abstraction was that all Circle types share the same structural DNA — a header with context, a tab bar, and a content area — and each type configures those elements differently based on its lifecycle and purpose. Five types from one shared system — Club, Trip, Event, Destination, and Member-hosted Circles. The two that pushed the abstraction hardest were Destination Circles (real-time, opt-in, ephemeral by design — privacy was the constraint that shaped the entire flow) and Club Circles (ongoing, passion-linked, with the nested-Event logic for later phases). The system couldn’t be solved in static mocks. State changes, conditional tabs, type-specific configurations, multi-entry-point discovery, the empty state that most members would see before they were ever in a Circle — none of it would have read in flat Figma. I built interactive HTML prototypes in Claude Code to work through the navigation logic, the type variations, and the invite-to-acceptance flow. Because Circles are invite-only, the empty state had to educate without feeling exclusionary — type-preview cards with informational tone, “membership comes to you” framing, no fake gating.
Live prototype — click to interact. Built in Claude Code to work through navigation logic, conditional tabs, type-specific configurations, and the invite-only empty state.
The Destination Pages tab restructure is in Costa Rica pilot. The rest of Phase 2 — the passion teaser, My Feed, the Golf Passion page, the gated destination forums, the Know Before You Go redesign, the new maps — was in active development when I transitioned off. Phase 3 work, including the Circles system, was designed and waiting.
The team shipped in deliberate chunks — Phase 2 in the strategic doc lands as Phase 1.5 in execution, which is the realistic cadence I designed inside. None of Phase 2 shipped during my time on the project.
What landed was structural. The architecture is set — four pillars, defined Passion logic, conditional Circle integration, a forum UI that supports multiple contexts. The priorities are set — MoSCoW prioritization across two phases of growth, with the Phase 2 push that changed what got bundled with what. The recommendations changed the roadmap — passion and My Feed added to Phase 2, the Destination Pages tab restructure adopted and piloting. And the next phase has design work ready to go — the Circles system with prototypes that demonstrate the navigation logic the team would otherwise have had to figure out from scratch.
None of Phase 2 shipped while I was on the project. The architecture, the prioritization, and the Phase 3 design work were ready.
A self-initiated UX/UI audit across two mobile codebases — built without a mandate, dismissed at the leadership level, rebuilt around the member survey that validated it.
When I joined as Sr. Product Designer in September 2025, the second-day walkthrough of the native mobile app surfaced the gap. The Club — the native iOS + Android app — and The Source v2 — the responsive Next.js portal embedded as a webview inside The Club — had been built by different teams with no shared design system, no platform ownership model, and no awareness of each other. The webview showed its own nav and footer alongside the native app’s nav. Touch targets fell below the iOS minimum on both platforms. The native app had 23 font sizes defined and a color palette that included four different reds for errors.
Members felt the fragmentation. Bookings capped at 90 days when the desktop portal allowed further. Profile features were missing. The mobile product was bounds behind what the portal could do.
It wasn’t on the roadmap for the next several quarters. The team was short-staffed and prioritized elsewhere.
I did the audit anyway.
The audit ran February through April 2026 on my own time. Code-level on both products. 154 files of native code, 763 hardcoded values, full mobile-responsive review of the Next.js portal, with the webview-awareness gap as the central technical insight. The web app inside the native app had no idea it was inside a native app — it showed its own header, its own footer, its own back-button behavior, all redundant with what the native app already provided. Two platforms running parallel implementations of Explore and Search, creating maintenance burden and inconsistent experiences for the same task.
I drafted a platform decision framework — native for device integration, performance-critical screens, and platform conventions; webview for content-heavy flows, frequently-changing content, forms, and administrative interactions. Then I mapped 19 features against current vs. recommended platform ownership. I produced a 20-item priority matrix and a 4-phase roadmap.
Then the 2026 member survey came back. App satisfaction 3.50 out of 5. Booking ease 3.54. The open-ended feedback aligned with everything the audit had already surfaced.
The first attempt to share the audit alongside the survey readout didn’t land at the leadership level. The survey had the team’s attention; an analytical artifact built on the same problems didn’t.
So I rebuilt the deliverable. With the survey data in hand, I layered it into the audit and built an interactive HTML report in Claude Code — a six-tab navigable artifact with the survey data visualized alongside the audit findings on the same page. The alignment was no longer something I had to argue for. It was something stakeholders could see for themselves.
Live report — click to interact. Built in Claude Code as a six-tab navigable artifact; opens here on the Member Survey tab where the audit findings sit alongside the 2026 survey data.
The second distribution went to Head of Product and PMs as an async-readable artifact — one they could navigate on their own time, land on the Survey Data tab first if that was the question they cared about, then move to Recommendations or Roadmap in whatever order matched their thinking. It landed.
The integrated audit produced three strategic artifacts the team didn’t yet have for mobile.
The platform decision framework. Before fixing any individual issue, the team needed a principle for which platform each feature belonged on. Native for device integration (camera, GPS, push notifications, biometrics), offline capability, performance-critical screens, and platform conventions. Webview for content-heavy flows, frequently-changing content, forms, and administrative interactions. Paired with a feature-by-feature mapping — 19 features audited for current implementation vs. recommended platform. Some moved (Get Ready flows shifted from native to web, where form complexity belongs and where changes don’t need an app release). Others stayed — Connect and messaging in native, because real-time push depends on it. The hardest were the ones running in parallel: Explore was duplicated in both places at once, which was the maintenance burden and inconsistency root cause.
The priority matrix and the 4-phase roadmap. Twenty issues, ranked by impact and effort, sorted into P0 / P1 / P2. P0 fixes — webview detection so the web app could hide its nav and footer inside the native app, 44px touch targets enforced on both platforms, the formal platform-ownership decision — sized to ship in a single sprint. P1 was next-quarter scope (unified design tokens, sticky CTAs on conversion flows, keyboard avoidance on forms, deep linking, typography cleanup). P2 was longer-horizon (accessibility remediation, form component libraries, the native-to-web bridge for auth and push). The phasing sequenced these into four phases: Establish the Contract (define ownership, kill the duplication), Fix the Foundation (close the critical UX gaps every member touches), Consolidate Native Flows (migrate Get Ready to web), Elevate to Luxury (visual polish that earns the brand on the platform members actually use it on). The roadmap translated diagnosis into a buildable plan.
Scroll within the frame to see the full 20-card priority grid.
The interactive HTML format, built in Claude Code. The format was a deliberate choice. Stakeholders consume strategic work on their own time, not in a meeting where I’d be there to walk them through it. An async-readable report with deep-linkable tabs meant they could land on the question that mattered to them — Survey Data first if that was the entry point — see the data sitting next to the audit findings on the same page, and form their own read. I’ve worked across the AI tool stack — bolt, cursor, Figma make — but for shareable, technical artifacts like this one, Claude Code is where I land.
The integrated audit landed with Head of Product and PMs. Feedback was positive. Some of the work started: bottom buttons on destination pages — a small slice of the native mobile design direction the roadmap called for — moved into next-quarter scope. The platform decision framework gave the team a vocabulary for the native-vs-webview conversation they hadn’t had before. The audit content has been referenced in subsequent platform discussions.
The full 4-phase roadmap hasn’t been adopted. The organization ships on deliberate timelines, and mobile is one priority among many at a short-staffed team. Whether the broader work gets picked up in the next two quarters or later, I don’t know.
What I can claim is that the strategic spine is on the shelf and ready. The audit established the problem with code-level evidence and member-voice validation. The framework established the criteria for what belongs where. The matrix and roadmap established the sequencing. The interactive report made all of it consumable without me there to walk through it. When the team is ready to take the work on, they don’t have to start from a blank page.
The audit was self-initiated. The strategy is ready when the team is.
A UX strategist engagement that mapped a lead management experience nobody had ever seen end-to-end — through multi-population research and a stakeholder-validated opportunity framework.
At a global agricultural products company, the end-to-end lead management experience spanned two product business units (GHX and Enogen), two distinct external populations (sellers in the field, farmers as end customers), and at least four internal teams. The flow had pieces owned by different parts of the organization, but nobody had ever mapped it as a single connected system. As UX strategist on the agency engagement, I led the research and synthesis that produced the blueprint.
Before this, the lead experience had only ever existed in pieces. The blueprint is what made it a system.
Most CX engagements scope research to the customer side. This one didn’t. Sellers are the field-facing role responsible for managing lead-to-sale conversion at the agricultural client; farmers are the end customers buying the products. Treating either population as “the customer” would have left out half the lead flow. So the research scoped both, plus stakeholder interviews across the four internal teams that owned different pieces of the flow: Strategy & Change Insights, Marketing & Communications, Sales Insights & Strategy, and Data Technology & Analytics.
Seven seller interviews. Five farmer interviews. Multiple stakeholder conversations to map the organizational structure that sat underneath the customer-facing flow. The synthesis was less about finding individual pain points and more about reconciling four internal views of the same lead flow against what sellers and farmers actually experienced.
This is where the GHX/Enogen alignment opportunity surfaced. The two product business units ran in parallel through what should have been a shared lead flow architecture — but the touchpoints, terminology, and handoff patterns diverged in ways neither team had visibility into. Mapping them as parallel tracks in the blueprint made the alignment opportunities visible for the first time. Without the multi-population scope, the alignment work would have stayed invisible.
A blueprint is a diagram until something tells the team what to do with it. The framework layer on top of the visualization is what turned this from a diagnostic artifact into an actionable handoff — through a categorization system, a validation step, and an embedded measurement layer.
The opportunity categorization framework. Every opportunity surfaced in the synthesis was sorted into one of four categories. New — opportunities the lead-to-conversion journey didn’t yet include and should. Simplify — current actions that could be reduced or streamlined. Enhance — actions already happening but with room to improve. Align — opportunities specifically for GHX and Enogen process alignment, the parallel-track findings from the research. The four categories gave the team a vocabulary for prioritization that didn’t yet exist, and the categorization is reusable for future CX work after the engagement closed.
The “Filled Opportunity” validation step. A raw recommendation list is easy to produce and hard to act on. The blueprint distinguished priority opportunities — specifically validated with the client’s core stakeholders — from the broader set. Walking the team through the categorized opportunities and getting their endorsement on which ones rose to priority built downstream alignment into the artifact itself. By the time the blueprint was delivered, the priority opportunities had buy-in from the people who would have to act on them.
The KPI infrastructure baked into the blueprint. Each touchpoint in the lead flow carried a linked measurement layer — user engagement metrics on tactical CTAs, form visits and form abandonment rates on conversion points, lead source comparison and demographic capture on event-driven touchpoints. Each metric block included a “Return to Blueprint Location” link, so a reader following the measurement thread could navigate back to where the metric mattered in the flow. The blueprint was instrumented for measurement, not just diagnostic — a layer most CX artifacts skip.
Each touchpoint in the blueprint carries a linked measurement layer — engagement metrics on tactical CTAs, conversion rates on forms, funnel-stage progression on relationship-building touchpoints. Each KPI block links back to its location in the blueprint so a reader following the measurement thread can navigate to where it mattered in the flow.
The engagement closed at the blueprint. Implementation was the client’s next phase — typical for consulting work that hands off strategic deliverables for in-house execution. What I can claim with confidence is what was delivered, validated, and handed off — not what got built afterward.
Delivered: the blueprint itself, in Miro, as the working file the team could keep using; a readout deck packaged for leadership consumption; the four-category opportunity vocabulary as the framework the team would carry forward.
Validated: the priority opportunities, walked through and endorsed with the client’s core stakeholders before final delivery. The alignment between the recommendations and the people who would have to act on them was built into the artifact, not appended to it after.
My working belief is that the opportunities were pursued. I don’t have implementation outcomes to claim; I have a handoff at the right altitude.
The engagement closed. The framework didn’t.
Some clients ask for confidentiality. Reasonable. Email me for the password if you're a hiring manager actively reviewing.
The password is shared with serious recruiters and hiring managers on request. Email me and I'll send it with a one-line note about scope.
No password? Email me — I'll send it.