.jpg)
UX CASE STUDY · HARMONY EDITOR 2025
Rethinking
Page Permissions
Summary
TEAM
1 PM, 2 DEVS
MY ROLE
Design strategy, UX
Page Permissions decides who can see a page on a Wix site. Bringing it into the new Harmony editor, I went beyond a visual refresh to untangle its deeply nested access logic and design for every state, shipping a clearer, more trustworthy way to control access.
USERS
Who needs page permissions anyway?
Page Permissions matters most to the Wix users whose business depends on showing the right content to the right people.
Course creators & educators
Teachers and online-course sellers who gate lesson content behind the right pricing plan, and use roles to separate what students and teachers each see.
Membership & community sites
Sites built around exclusive, members-only content, the heart of any members area, where only logged-in members get in.
Paid & subscription businesses
Businesses that lock premium pages to members on a specific plan — the Silver / Gold / Diamond tiers, gating content behind a subscription.
CONTEXT
What are page permissions?
Every page on a Wix site has a setting for who's allowed to view it. Owners can keep a page open to everyone, lock it behind a password, or restrict it to site members via roles created in the back office.
The members path goes a step further: access can be narrowed to specific members based on the roles they hold or the pricing plans they've subscribed to.
It's a small panel that carries real consequences: set it wrong and you either expose a private page or accidentally lock out the people who paid to see it. That gap between low surface area and high stakes is exactly what made the existing experience risky.
The brief vs.
what I took on
THE ASSIGNED TASK
Update the UI so Page Permissions matched the new Harmony editor's layout and design language. A UI updated, scoped narrowly.
WHAT I TOOK ON
Restyling a confusing flow doesn't fix it, it just makes the confusion look more polished. So I audited the panel end-to-end and mapped where it failed users first, so the redesign could be measured against a better experience, not just a refreshed one.
AUDITING THE CURRENT FLOW
Big decisions, without the support to make them
My UX audit surfaced issues that clustered into three themes. Together they painted a panel that asked users to make consequential choices without the context, structure, or feedback to make them confidently.
UX TEAR DOWN
Where the access flow quietly breaks
A single settings panel decides who can see a page. On the surface it looks tidy — but each interaction below hides a decision, loses input, or confirms something that never happened.
01
Undisclosed branch.
A binary choice quietly nests a whole second set of options inside the second path, with no signpost. Pick “Specific members” alone and nothing is actually saved.
02
Silent data loss.
Toggling a selection off and back on makes the chosen plan disappear entirely — quietly destroying the user’s input.
03
Lack of context
You grant access by role, but the picker shows only the role’s name as a chip, no hint of who belongs to it or what it actually permits. You’re choosing blind.
04
False confirmation.
A toggle can be switched on without picking a plan or role. Nothing saves, yet the control looks active — so users assume a choice was made.
05
Purposeless status.
A read-only status block sits at the bottom with no clear meaning and nothing to act on. The disabled button also goes against acccesibility guidelines.
THE OPPORTUNITY
Reframing the goal
This shifted the project. The real goal was never "make Page Permissions look like Harmony." It was:
Redesign Page Permissions so owners can confidently control page access — understanding each choice, navigating the complexity without getting lost, and trusting that what they set is what gets saved — all within the Harmony system.
My part was the section in pink, but I had full control of how this would look and feel. It would require communication and collaboration between multiple teams at Wix. That in itself was a challenge.
UX & VISUAL EXPLORATION
Finding the right way to hold the complexity
The hard part wasn't styling — it was structure. How do you present a decision that branches three levels deep without overwhelming someone who just wants to lock a page? I explored a few directions, each handling that nesting differently.
I explored several approaches to the panel’s behavior. In one variation, a dropdown was used to define page access permissions, which dynamically adjusted the content shown in the panel.
Visual exploration with real data (not lorem ipsum), alongside feedback from stakeholders allowed me to quickly rule out using the panel for both selection and display. It was too complex for such a narrow space.
Back to the drawing board
I went back to Figma to build a more flexible layout, moving the selection process into a modal and leaving the panel to display only the summary. It tested well internally and meant we could move on in the design process.
😖
UX Issue 1
The dropdown as confusing and lacked clarity. The options felt not discoverable enough.
😤
UX Issue 2
Navigating through the modal wasn't intuitive enough. Users wanted to know more about the options at their disposal.
🕵️
Secret internal testing
All prototypes and mockups were tested internally with stakeholders only, instead of customers who use this feature because, shhhh, the new editor is a secret!
😀
Modal concept wins
The modal concept was deemed much more intuitive. It enabled users to configure their settings and use the panel as the summary.
FINAL DESIGNS
Designing for every state
Page access isn't one screen — it shifts depending on whether someone picks everyone, a password, a single role, or a stack of plans and badges. I mapped every state the panel could land in, from empty states to extreme full states.
extreme full state
01
Start simple, reveal on demand
The decision opens with three plain choices, Everyone, visitors with a password, or members. Choosing members reveals the next layer, so the complexity only appears when someone actually needs it.
02
Progressive disclosure
The modal opens with three plain choices. Selecting Members reveals just one more question, all members, or specific ones, so the deeper rules stay hidden until they're actually needed.
03
Information hierachy
A theory that I tested internally was to find out if members should be more clear up front via another
selection: Specific Members. After rigorous testing, we went back to three choices. This felt less overwhelming to users.
Too many options upfront was confusing.
opens in new tab
04
Granular, without leaving the flow
Roles, plans, and badges each get their own toggle with inline selection, owners can combine rules exactly how they need, all inside the same modal.
05
Create in place
If a user has no plans yet, they can create one inline and return exactly where they left off — keeping their place in the flow instead of starting over.
LOOKING BACK
01
Look past the brief to the real problem
This was scoped as a visual refresh, but a quick audit revealed deeper UX issues worth addressing. I made the case for solving them — without compromising the original scope or timeline.
02
Map the people before you map the problem
Across this many teams, knowing early who owned what and who my point of contact was turned days of chasing answers into quick syncs. Establishing that map up front kept a project with lots of moving parts pulling in one direction.