WYSIWYG

What is WYSIWYG in A/B Testing?

WYSIWYG—short for What You See Is What You Get—is a visual editor built into many A/B testing platforms. It allows users to click and edit page elements like text, buttons, and images directly in the interface, without needing to write or understand code. What you see in the editor is what users will see when the test goes live.

These editors are especially popular in client-side testing tools, where real-time page changes can be injected into a site through JavaScript.

How WYSIWYG Editors Work

WYSIWYG editors work by letting users:

• Click on elements in a live or simulated version of a webpage
• Edit content, styling, or layout visually
• Preview the changes in real-time
• Deploy those edits as part of a variant in an A/B test

Behind the scenes, these visual changes are translated into code that is injected dynamically when a user is bucketed into a test group.

Why WYSIWYG Editors Matter in Experimentation

WYSIWYG editors help non-technical users participate in experimentation. Marketers, content managers, and product teams can launch quick tests without adding to a developer’s workload.

This unlocks:

• Faster iteration on headlines, images, and copy
• Greater experimentation velocity
• Empowered teams that can test ideas without waiting for dev resources
• Easier ideation and proof-of-concept before committing to permanent changes

“WYSIWYG, the most hilariously pronounced acronym going. The big spuds give it a lot of hate. But when your dev team has a backlog as long as your arm, it’s the ideal way to visualize and test marketer-friendly changes like copy and imagery.”

Laura Robinson, Founder at Web and Flo

Tradeoffs and Limitations of WYSIWYG

While WYSIWYG editors are powerful, they have limitations:

• Reimplementation is often required. Changes made in a WYSIWYG editor may not carry over into production. Winning variants might need to be rebuilt in code.
• Limited flexibility. Complex logic, dynamic components, or integrations often require a code editor or server-side solution.
• QA becomes more important. Because WYSIWYG changes rely on client-side injection, they can sometimes cause layout bugs or visual issues if not tested thoroughly across browsers and devices.

WYSIWYG vs Code Editors

For simple UI changes, WYSIWYG is fast and efficient. For more advanced tasks, code editors or server-side experiments are better suited.

Best Practices for WYSIWYG Testing

• Use it for small, visual changes like headlines, CTAs, and product images
• Preview on multiple devices to catch styling issues early
• Document all WYSIWYG changes so they can be rebuilt if needed
• Run QA before launching, even small visual edits can break layouts
• Defer to developers for anything involving logic, personalization, or backend integration