Skip to content
All work

Design editor / design system

A powerful design editor that enables professionals to create accessible, compliant documents—without requiring technical expertise.

Role
Lead product designer
Team
PM, Designer, EM, 3 Engineers
Company
Venngage
Focus
Accessibility, design systems
The Venngage editor with an Executive Summary document open and the Accessibility panel alongside it, listing checks such as Color Contrast, Heading, and Text Size as passed and Alternative Text as failed.
Compliance + VPAT
WCAG AA
Trusted by education, healthcare, nonprofits
Used a11y features
15%
In their first session; 20% made accessible designs
Accessibility leads
50+
Within three months

Problem

Compliance without the expertise

For many of our users, especially in government, education, and enterprise, accessibility isn’t optional. These teams must produce accessible documents at scale but often lack the technical expertise, so they’re stuck with complex remediation tools like Adobe Acrobat Pro and CommonLook PDF Validator.

I redesigned our editor from the ground up: rebuilt the design system, designed new accessibility features, and rethought key user flows with inclusion in mind. This effort earned VPAT certification and strengthened our credibility among business users.

Who we designed for

Three personas

With the PM, we ran 15 discovery interviews across compliance-driven industries, which surfaced three distinct user types. Catherine is our primary ideal customer profile (ICP).

  • Catherine Johnson

    Accessibility advocate · Primary focus

    A public university administrator who must make student-facing documents accessible each semester, with no time to train teams or audit manually.

  • Darron Mitchell

    Business-first executive

    Operations director balancing accessibility against budget and business priorities.

  • Zeo Anderson

    Screen reader user

    Accessibility specialist slowed down by poorly structured documents and inaccessible PDFs.

Phase 1 of 3

Accessible at its core

I took ownership of rebuilding our design system to meet WCAG 2.1 AA, with contrast-compliant palettes, legible typography, accessible iconography, keyboard-navigable components, and guidelines for inclusive writing. This redefined our visual language, increased design velocity, and streamlined handoffs.

The design system in Figma: Buttons and Input specs with button size guides and icon buttons, and Informational components such as dialogs and snackbars, with local text and color styles in the side panel.
Design system: buttons, inputs, and informational components
Design system foundations: an iconography set for general, left panel, page manager, and sharing actions; blue, green, and violet palettes from 50 to 900 with contrast labels; a text size guide; and radius tokens.
Themes: palettes, iconography, typography

Components

I partnered closely with engineers to add ARIA labels, intuitive tab navigation, and full screen reader support, making the editor fully accessible for people like Zeo. Building on this foundation, I redesigned the editor with a cleaner UI and stronger visual hierarchy.

Left widget menuContains and manages all widgets for easy access.
Chart widget panel open in the editor’s left menu, listing chart types such as pie, donut, column, bar, combination, and Pareto.
Control menuFloating panel offering quick access to controls.
Editor control menus: a sharp Page Size menu (standard page size, custom width and height, orientation, apply to pages) in focus, surrounded by blurred accessibility and alignment menus.
Buttons and focus stateStandardized buttons with focus indicators for keyboard navigation.
Editor top bar with Download, Preview, and Share buttons, a help icon, and a user avatar. The Share button shows a visible keyboard focus ring.
Snack barShort feedback on system processes.
Editor with two dark snackbar notifications: “Page duplicated” with an Undo button, and “Design duplicated – A copy was added to your drafts.” with a View button.
In-context menuRelevant actions while working on canvas.
Right-click context menu over a document canvas, listing Cut, Copy, Paste, Duplicate, Delete, and layer ordering actions, each with its keyboard shortcut.
Tooltip / toggle tipTips and guidance in context.
Color picker flagging #174363 as Low contrast at 1.3 : 1, with a dark toggletip listing WCAG 2.1 AA contrast requirements: 4.5:1 for normal text, 3:1 for large text, and 3:1 for meaningful graphics.

Modernizing the interface

Building on this foundation, I redesigned the editor interface with a cleaner UI and stronger visual hierarchy. I ensured consistent styling and full WCAG Level AA compliance, making it more intuitive for all users, including those with low vision or motor impairments.

After: the redesigned editor with a light icon rail, a simplified top bar, and the same Project Proposal design on the canvas.
Before: the old editor with a dark, text-heavy left sidebar and a dense toolbar above a Project Proposal design.
BeforeAfter

Phase 2 of 3

Making accessibility part of creation

Accessibility shouldn’t be a final step. I built guidance into the moment of creation, so people like Catherine can make accessible choices without specialist knowledge or outside tools.

100%
During creation, the contrast checker and AI alt text generator nudge accessible choices. Before publishing, the Accessibility Checker scans the document and shows how to fix every issue.

Feature highlight

Real-time color contrast checker

Users like Catherine had to use third-party contrast checkers, adding extra steps to her workflow. I integrated a real-time WCAG 2.1 AA contrast checker directly into the color picker. It evaluates selected colors, warns users when combinations fail, and suggests accessible alternatives.

The editor with the color menu open beside a Software Upgrade Proposal design. A selected heading is dark blue on navy, and the picker flags it as Low contrast, 1.3 to 1.

Usability testing

To find out what actually helped users choose accessible colors, I tested three versions of the menu, each combining different ways to surface contrast:

  • Live contrast ratios with WCAG AA levels
  • Contrast borders around swatches
  • Highlighting the accessible range in the picker
  • A visual simulator for perspective switching
Three wireframe versions of the color menu: one with a contrast ratio row and AA and AAA badges, one with a contrast preview and visual simulator, and one with contrast tags placed right under the picker.

Goal

Find out whether users could pick accessible colors confidently, without leaving the editor or needing to understand WCAG.

Format

  • Moderated and unmoderated usability tests with 8 users
  • Example tasks: “Choose an accessible text color for this heading” and “Fix a low-contrast button”
  • Measures: task success, time to pick an accessible color, confidence rating

What I found

  • Version 3 performed best: contrast tags linked each color to its accessibility result.
  • Users preferred simple pass/fail feedback over technical contrast ratios.
  • Real-time previews added little value.

Result

  • 63% task success: 5 of 8 users chose an accessible color on the first try.
  • Confidence increased: 2.8 → 4.2 / 5.
  • Next opportunity: Users wanted AI-generated accessible color palettes.

Final version

In the final design, the contrast tag sits right next to the color picker, so users know instantly whether a color works as they choose it. A plain-language label (“Low contrast,” “Good contrast,” or “High contrast”) updates live with every change, and users can click the tag to see the exact ratio and WCAG level.

Phase 3 of 3

Validate accessibility before publishing

Catherine needed a final review before publishing, but external tools like Adobe Acrobat had a steep learning curve. I designed an all-in-one accessibility checker with automated audits, fixes linked directly to each feature, and a full accessibility report.

The editor with a Common Size Analysis document and the Accessibility Checker panel showing 8 issues remaining: Color Contrast, Text Size, and Links pass, while Alternative Text fails with two images missing alt text.
The Accessibility Checker sits alongside the document in the editor.

I built an all-in-one Accessibility Checker that audits the whole document before publishing. It flags issues like missing alt text, low color contrast, and small text, and links each one straight to the tool that fixes it.

It combines an automated audit with guided manual review across 11 WCAG AA categories, marking each one as pass, fail, or needs review. Automation catches what’s measurable, like missing alt text or low contrast. Manual review covers what needs human judgment, like whether alt text makes sense or color alone carries meaning.

Expanded checker cards: Color Contrast failing with two items, Text Size passing, Alternative Text failing with three images missing alt text, Document Language needing review, Tables reviewed, and Headings passing.
Clicking a flag shows guidance on how to fix it. Users fix issues right in the editor and check them off as they go.

Learnings

Design with accessibility in mind

Accessibility goes beyond a checklist. It’s a mindset that should shape design decisions from the beginning, not be added at the end.

Co-creating with users

Talking with users like Catherine, and experiencing the product with a screen reader, helped me close the gap between best practices and practical, intuitive design.

Take ownership and keep learning

I rebuilt our design system with accessibility at its core, strengthening both the product’s design foundation and my Figma skills along the way.