ART
Role-based membership platform.

Two targets, two mental models

Before touching the IA, we mapped what each user actually needed to do, and how different those jobs were.

Information Architecture: the split that holds everything together

The IA decision that defined the entire project was treating the two audiences as two separate sites sharing one domain with a single, low-friction switch between them.

The consumer homepage is the default entry point for most visitors. Depending on the search intent, however, Google may surface either the consumer or the business homepage. Each experience includes a persistent link to the other in the top-right corner ("Sei un ristoratore?" on the consumer side and "Sei un turista?" on the business side). Once users switch, the navigation changes completely: different voice, different color (red vs yellow), and different CTA hierarchy, so the user always knows which side they're on.

Simplified sitemap — dual track structure

I proposed splitting the two experiences completely rather than merging them into shared navigation, and the team validated it during wireframing, iterating on the first sitemap.

First wireframes of the 10 main screens — consumer and business tracks.

Process

We worked across three broad phases: IA and wireframes first, then UI and membership logic, then technical implementation and edge-case resolution, though in practice the last phase fed back into the first more than once.

01

IA mapping and dual-track wireframes

We mapped the full sitemap for both tracks, identifying shared pages (account, assistenza) and exclusive ones (diventa socio, dati ristorante, consulenze). Then we wireframed the 10 key screens: homepage consumer, homepage business, product page, membership page, checkout flow, and the account page both with and without an active membership.

Artifacts: sitemap · 10 wireframes · user flow diagram

02

RBAC design — defining what each role can see and do

I designed the full access matrix: 5 user states (guest, registered tourist, free member, base member, premium member) against every gated feature. Key decision: consulting forms accessible to Premium only, restaurant data upload open to Base and Premium, and the newsletter restricted to paying members: a deliberate filter to generate qualified leads instead of spam signups.

Artifacts: access matrix · role-state diagram

03

UI design and membership page optimization

High-fidelity mockups for all key screens. For the membership page specifically: removed the extra click to see plan benefits, so all tiers are compared on a single page; added social proof through testimonials and an FAQ to cut down on support requests; and visually flagged the Base tier as "most sold": a deliberate nudge for budget-conscious small restaurants.

Artifacts: mockups · membership page before/after

Before

After

04

Technical implementation and critical issue resolution

Built in WordPress with WooCommerce, Simple Membership, and Stripe. Along the way I ran into three critical technical blockers, each one meant digging through documentation, tracking down the actual root cause, and landing on a solution that wasn't obvious from the start. Details below.

Artifacts: live WordPress site · 3 documented critical resolutions

Key Decisions

Every decision on this project came down to the same tension: making the membership funnel as frictionless as possible for restaurateurs, without opening the system to unqualified or fake signups.

Decision 01 — Stripe over PayPal

Decision 02 — Registration only after payment

Decision 03 — Stripe customer portal for subscription management

Critical issues resolved — the real problem-solving

The hardest part of this project wasn't drawing the interface, it was the three technical blockers I hit during implementation, and each one turned into a UX question as much as an engineering one. A €0 product breaking Stripe's checkout wasn't just a bug to patch; it forced me to rethink what a free-tier signup should actually feel like. Here's how I worked through each one, alone.

01

Stripe "Buy Now" can't process €0 products

Payment · Stripe API

The problem: The free membership tier needed to go through Stripe for consistency (so the user still creates a payment profile). But the standard Stripe "Buy Now" button throws an error when the product price is €0.

How I resolved it

Identified that "Stripe Buy" is for one-time payments only — switching to "Stripe Subscription" allows €0 recurring plans

Created the free product in Stripe's dashboard with a recurring €0/year price

Hit a second error: the Price ID existed in live mode but I was using a test key — had to recreate the product in test mode to get a valid test Price ID

Tested the full signup flow end-to-end, including the post-payment registration email

Result: Free tier signup works through the same Stripe flow as paid tiers — consistent UX, and every member (including free) has a Stripe customer profile from day one, making future upgrades seamless.

02

WooCommerce and Simple Membership don't share an account page

Plugin integration · PHP

The problem: WooCommerce has its own "My Account" page. Simple Membership has its own separate member area. A user who subscribes ends up with two disconnected account spaces — confusing and unbrandable.

How I resolved it

Researched WooCommerce documentation — found that custom "endpoint pages" (sub-sections like Orders, Addresses) can be added programmatically

Used WPCode Lite to add a custom PHP snippet that registers a new "Membership" endpoint inside WooCommerce's account nav

Populated the endpoint with Simple Membership shortcodes, conditionally rendered: subscribers see their status, expiry, and a manage button; non-subscribers don't see the tab at all

Flushed permalinks — the new section appeared correctly in the account sidebar

Result: One unified account page. A restaurateur sees their WooCommerce orders and their membership status in the same space, with no "you don't have access" messages visible to users who don't need that section.

03

Restaurant data submission couldn't handle file uploads

Form plugin · File handling

The problem: Base and Premium members need to submit their restaurant data (name, hours, address, photos) to appear on the consumer-facing listings. WP Forms — the first plugin I tried — doesn't support file uploads in the free tier.

How I resolved it

Evaluated alternatives: Gravity Forms (paid), Ninja Forms (free tier lacks file upload), Contact Form 7 with additional plugin (fragile integration)

Chose a dedicated form plugin with native file upload support and Simple Membership gating compatibility

Protected the entire page with Simple Membership so only Base and Premium members can access the form — guests and free members see a "members only" message with a CTA to upgrade

Result: Restaurant data flows directly into the site admin without email handling — scalable to dozens of members without creating an unmanageable inbox. The gating ensures only paying members can create listings.

Reflections

The most valuable part of this project was learning that reading documentation and working through technical constraints systematically is itself a design skill.

• The IA split between consumer and business tracks was the right call, but I underestimated how much the shared pages (account, assistenza) needed to adapt per role. A fully role-aware navigation, where the active user type changes which items are highlighted, would have been cleaner.
• Choosing Stripe's hosted portal for subscription management was pragmatic but creates a seam in the UX, the user leaves the site to manage billing. A next version would explore Stripe's embedded components to keep that flow on-domain.
• Documenting the technical blockers as I solved them (problem → investigation → solution → result) turned out to be more useful than I expected. It's the kind of thinking a product designer needs to demonstrate to work effectively alongside engineers, and it's now the most concrete evidence I have that I can do that.