one-thing

Description

Like any good product release, there’s always one thing to make better. Use this skill to tidy up your website, sharpen the copy, improve performance or accessibility, or adopt a useful Framer feature, one small change at a time.

Content

Find, implement and verify one meaningful improvement to this website.

Review thoroughly, choose deliberately and keep the changes focused. One improvement can require several related edits. Complete the selected outcome across its affected pages, components and states.

Working rules

• You must make all changes on a dedicated Framer branch. Verify the active branch and that the intended edits stay isolated. If branching is unavailable, provide the proposed fix without editing.
• You must preserve unrelated work and existing functionality.
• Keep component instances connected to their source and content connected to its CMS fields. Change those connections only when the selected fix requires it, then verify them.
• Preserve product names, prices, dates, factual claims and link destinations unless correcting them is part of the selected improvement and you have a verified replacement.
• Prefer existing components, styles and native Framer features. Follow the project’s design system and brand guidance.
• Complete the implementation when the available tools allow it. An audit or list of recommendations alone does not complete this skill.
• Leave the branch ready for review. Applying it to main or publishing the live website requires the user’s approval.

Workflow

1. Ask where to focus

Start with one short question:

“Is there a particular page or area you’d like to improve, or shall I review the site and choose?”

If the user has already mentioned an area, make the question specific to it. Wait for their answer. Do not repeat a question already answered during this run.

If they have no preference, choose the improvement yourself.

2. Establish the context

Identify the website’s audience, purpose and main visitor journeys.

Read relevant project instructions. Inspect the pages, templates, shared components, styles and breakpoints involved.

For writing or design changes, use explicit brand guidance and representative approved pages as references. If none are provided, look for consistent patterns across the site and label any assumptions.

Distinguish the published website from the current project. Confirm that an issue found on the live site still exists in the version you will edit.

Use available history to build on previous improvements. Recheck earlier findings before acting on them.

3. Check the evidence

Query available analytics before deciding where to investigate. Use the last 30 days, or the available period.

Consider popular pages, entry pages, devices and existing interaction or conversion data. Record the date range and sample size.

Use the data to direct inspection. Confirm the actual problem on the website before choosing a fix.

If analytics is missing or sparse, continue with direct inspection. Do not make analytics setup a prerequisite or infer causes from a metric alone.

4. Review the relevant scope

If the user chose an area, inspect it and its dependencies. Otherwise, consider every review area below before selecting an improvement.

Within that scope:

• Inspect every page on a small site.
• For a large site, map its page types, run whole-site checks where available and inspect each distinct template.
• Follow important visitor journeys through to their destination.
• Inspect full pages, including lower sections and the footer.
• Check shared components and relevant interaction states.
• Sample CMS content with long titles, optional fields, missing values and different layouts.
• Include relevant breakpoints and localised versions.

Keep a short record of coverage and limitations. Clearly identify sampled or untested areas.

5. Choose one complete outcome

Compare the strongest confirmed findings. Consider visitor benefit, evidence, reach, effort, risk and the extent of the required changes.

Prioritise broken visitor journeys and significant accessibility problems. Then consider other clear improvements. A quieter page can still have an important problem.

Choose a concrete outcome, such as:

• Make a mobile menu usable with a keyboard.
• Replace vague copy in a pricing section with a clear explanation of the existing offer.
• Fix clipping in a shared card across its affected layouts.
• Repair a broken path from a landing page to an enquiry form.
• Correct a CMS metadata mapping that produces empty descriptions.

Keep independent issues for later.

Capture the relevant starting state and define observable success checks. Briefly explain what you will change, why it matters and what it affects.

If a candidate needs a broad redesign or migration, choose a smaller one. If no worthwhile small improvement is supported by evidence, say so.

6. Implement the selected improvement

Create or switch to the dedicated branch before editing.

Inspect the uses of any shared component or style you intend to change. Fix the shared source when the correction belongs across those uses.

Make the smallest set of changes that fully resolves the selected issue. Include the supporting edits needed to keep it working across relevant states and breakpoints.

Carry the work through the review checklist below. Keep unrelated cleanup and new services outside this run.

Review areas

Writing and brand voice

Look for copy that leaves visitors unsure what the website offers or what to do next.

• Identify empty promises, repeated benefits, vague headings and unclear calls to action.
• Replace buzzwords and inflated language with supported details about the actual offer.
• Cut introductions or explanations that add no useful information.
• Simplify repetitive sentence patterns and forced rhetorical phrasing.
• Keep the site’s recognisable tone, useful terminology and personality.
• Check that button wording accurately describes its destination or action.

Treat this as editing for clarity. Do not guess whether AI wrote the text.

Never invent evidence, testimonials, capabilities or results to make a sentence sound more convincing.

Design and responsiveness

Check overflow, clipping, spacing, alignment, text hierarchy, image crops and consistency with the project’s existing styles.

Review component variants and widths between breakpoints. Look for isolated deviations from an established pattern.

Check whether motion interferes with reading or interaction. Change it when there is a concrete usability, accessibility or performance benefit.

Accessibility

Check heading structure, semantic elements, accessible names, image alternatives and decorative images.

Review contrast, keyboard operation, focus visibility, form feedback, responsive reflow and reduced-motion behaviour.

Check whether essential meaning depends only on colour, position or animation.

Performance

Inspect media delivery, fonts, embeds, scripts, effects and layout shifts.

Measure where possible. Check what Framer already optimises before adding workarounds or changing assets.

Preserve the intended appearance and functionality while addressing the observed problem.

Navigation, links and forms

Follow menus, buttons, anchors and important visitor paths.

Verify suspected broken links and replacement destinations. Distinguish a confirmed broken link from a request that could not be checked.

Check form labels, validation, error feedback and success states. Use a safe test setup for submissions; a preview can still send a real enquiry.

Content and CMS

Look for placeholders, outdated information, inconsistent terminology and missing content.

Check template behaviour when fields are empty or unusually long. Fix the source or mapping responsible for a repeated issue where appropriate.

Preserve CMS bindings when editing connected content.

Search and sharing

Check page titles, descriptions, headings, canonical URLs, search visibility and social previews.

Look for metadata that is missing, duplicated or inconsistent with the page’s subject.

Review CMS metadata mappings and fallback values. Report indexability and confirmed indexing separately.

Confirm the intended behaviour before changing URLs, redirects or search visibility.

Framer features

Consult current official documentation and updates:

• Framer Help
• Framer Updates
• Performance guidance

Look for native features that resolve an existing issue or simplify a workaround.

Check compatibility with the project and its plan. Adopt a feature because it improves this website.

Review checklist

Track relevant checks using:

• Passed: You inspected or tested it successfully.
• Issue found: A confirmed problem remains.
• Needs manual testing: Available tools could not verify it.
• Not applicable: The check does not apply.

Before finishing:

• Recheck the original issue against the success criteria.
• Compare the relevant before-and-after states.
• Test affected breakpoints, component variants and interactions.
• Verify shared changes across their affected page types.
• Confirm that CMS connections and linked components still work.
• For copy changes, reread the surrounding section and check text wrapping, button widths and layout.
• For interactive changes, test behaviour as well as appearance.
• For performance changes, use comparable measurements and distinguish measured results from expected benefits.
• Inspect the final changes for unrelated edits.

Fix regressions you introduced and repeat the relevant checks.

If the fix cannot be completed within the intended scope, revert only your changes and consider another suitable candidate.

Do not mark an untested check as passed or claim full accessibility compliance from a limited review.

Report

Lead with the outcome. Keep the handover short and concrete:

• Improved: What changed and where.
• Why: The observed problem and benefit of the fix.
• Before and after: Relevant wording, screenshots or measurements.
• Checked: What passed and anything still unverified.
• Review: The actual branch or preview reference.
• Next: Up to three other confirmed opportunities, when useful.

For copy changes, show the edited wording so the user can judge it directly.

Write the handover plainly. Describe the actual result without inflated claims or generic praise.

If no changes were made, explain the specific reason.

Stop after the selected improvement is complete and checked. Leave the branch ready for the user’s review.