Native Component UX
You’ve built your component. You understand how it works, but your users might not. This tutorial shows what to do after building: refine variants, organize layers, and create variables so your native components are easy and intuitive to edit.
0. Why Post-Build Cleanup Matters
You’ve finished your component. It works, it looks good, and you know exactly how to edit it.
But:
Will someone who didn’t build it know where to change the text?
Will they know which properties are safe to edit?
This guide is about what happens after the component “works” – the steps that turn it into something that’s easy to edit, hard to break, and pleasant to use.
Use it as a checklist every time you ship a native component.
1. Drop It In Like a User
Start by acting like someone who has never seen your component before.
Do this:
Create a new page or empty canvas.
Paste your component in.
Don’t detach it. Don’t touch layers.
Look only at the right-hand panel.
Ask yourself:
What is the first thing I’d want to edit here?
Can I find that control in under 2 seconds?
Are there any properties I don’t understand at a glance?
Are there properties that feel unnecessary or duplicated?
This quick scan gives you a realistic view of the editing experience.
If the panel already feels overwhelming or confusing to you, it will be worse for your users.
2. Decide What Should Actually Be Editable
Most components are either over-exposed (too many controls) or under-exposed (important things hidden inside).
Before touching variables, decide what should and should not be editable.
For most components, users should clearly be able to:
Change main text: headline, body, labels.
Swap images or icons.
Change button labels and links.
Adjust key colors (brand, background, accent).
Toggle optional elements: badge, image, secondary text, secondary CTA.
And usually should NOT:
Adjust internal spacing and padding.
Change layout hacks or nested wrappers.
Toggle tiny decorative details that don’t matter.
3. Give Variants Real Names
Most components ship with variants like Variant1, Variant2, which only make sense to the creator.
Your goal is to make the variant menu read like clear options a user would actually choose.
Rename by purpose:
Layout: Horizontal, Vertical, Split, Stacked
Breakpoint-style: Desktop, Tablet, Mobile
Size: Small, Medium, Large
State: Default, Hover, Pressed, Active, Disabled
Then:
Delete test and duplicate variants.
Set the default variant to the clearest, most common one.
The variant menu should read like a tiny settings panel, not a list of versions you tried while building.
4. Audit Variables: Missing vs Too Many
Now, go through the properties panel and see what should be editable.
A. What’s missing?
Typical missing controls:
Headline text is hardcoded inside the component.
Button label and link are baked into layers.
The main image is not a variable.
Badge or label text can’t be changed.
Add variables for anything the user might want to edit.
B. What’s unnecessary?
Typical overkill:
Separate color variables for tiny inner elements.
Padding variables all over the place.
Radius controls for nested frames that users never see.
Toggles for subtle visual details nobody needs to manage.
If a variable only tweaks a tiny detail or duplicates what another control already does, remove it or merge it into a single, more useful property.
Rule of thumb:
If it’s safe and useful for 80% of users → expose it.
If it’s fragile, niche, or likely to break layout → keep it internal.
5. Rename Variables Like a Simple Form
Most users edit components from the panel only. Variable names are your UX.
Bad experience: “Which of these 12 properties changes the thing I’m looking at?”
Good variable naming feels like a simple form.
Good examples:
Heading
Subheading
Card Title
Card Description
Button Label
Button Link
Show Image
Accent Color
Weak examples:
Text 1, Text 2
Title Main 1, Color, Visible
Content, Body Copy
Tips:
Add context where needed: Card Title, Hero Title, Footer Link Label.
Keep naming consistent across your component set.
Name toggles as statements: Show Icon, Show Border, Show Secondary CTA.
If you can read the panel top to bottom and it feels like answering a form, you’re in a good place.
6. Group Properties by Purpose (Using Order + Descriptions)
Framer doesn’t have collapsible groups for variables, so order is everything.
A simple, predictable order works best:
Content: Headline, body, labels, images, icons.
Actions: CTA labels and links.
Visibility: Show/hide image, badge, secondary text, secondary CTA.
Style: Background color, accent color, radius, border.
Advanced (only if really needed): Things like animation timings or rare options.
Use descriptions as visual dividers
The Description field can double as a visual separator.
Use it to:
Separate content from style.
Mark advanced settings.
Group related controls without adding extra UI.
The goal: a panel you can scan in two seconds and instantly understand.
7. Use Placeholders as Safety Hints
Placeholders in Framer live in the input field, not on the canvas. They’re most useful as hints when a text value is empty, especially after a user deletes everything.
Use placeholders to:
Explain what kind of text goes in a field ("Short title, max 2 lines").
Help users understand a field even after they clear the text.
Avoid using placeholders as:
A way to keep important text hidden by default.
A substitute for real, visible default copy on the canvas.
The only way to "hide" optional lines – use toggles or proper visibility logic instead.
If the user needs to see the text on canvas to understand the layout, use normal default text and let the placeholder exist purely as guidance when the field is cleared.
8. Add Short, Useful Descriptions
Descriptions are displayed directly below the control name.
They’re great for:
Explaining how a property behaves.
Giving content length guidance.
Marking optional behavior.
Clarifying scope (“Card background, not page background”).
Examples:
Recommended: 1–2 short lines.
Best with 1:1 images.
Applies only to the hover state.
Keep them short. If you can’t explain it in one line, the property might be too complex.
9. Clean Internal Layers (For When People Peek Inside)
Even if your panel is perfect, someone will eventually open the component.
You don’t need to over-engineer the internal naming, but you should avoid chaos.
Typical problems:
Generic 'Stack' & 'Frame' names all over the component
Clean-up pass:
Name layers by function: Image Wrapper, CTA Button, Badge.
Mark structure groups: Card, Content Group, Media, CTA Group.
This makes it safer for advanced users to tweak the layout without hunting.
10. Do a 2-Minute Edit Run
Final step: treat your component like something you just bought in the Marketplace.
In one fresh instance:
Change the headline and description.
Swap the image or icon.
Update button text and link.
Toggle optional pieces (image, badge, secondary text, secondary CTA).
Switch between key variants (state, layout, theme).
Try leaving non-essential fields empty.
Notice any moment of:
“Where is that controlled from?”
“Why did that disappear?”
“Why are there three ways to change this color?”
Fix those points. That’s the friction your users would feel.
Quick Checklist
Before you ship or publish:
Variant names are clear and minimal.
Only important things are exposed as variables.
No “mystery” variables that don’t do much.
Variables are named clearly
Properties are ordered by purpose (content → actions → visibility → style → advanced).
Placeholders are used mainly as guidance when fields are empty (safety + hints), not as the main way to hide important content.
Descriptions clarify tricky or important controls.
Internal layers have meaningful names.
A fresh instance is easy to edit in under 2 minutes.
Details
Justyna Dabrowska
