Building a Design System for AccessAlly: Lessons from an Unfinished Project

AccessAlly is a powerful membership and LMS platform for WordPress that serves course creators, membership site owners, and digital product businesses. The product had been redesigned in 2021, establishing a solid foundation. However, as new features continued to be added over the following years, the UI gradually became disjointed. Without a formal design system to guide new feature development, inconsistencies crept in. Different features began using different button styles, navigation patterns, and typography treatments. What started as small deviations from the 2021 redesign had grown into a fragmented user experience that confused customers and slowed down development.

I was brought in to design a comprehensive product pattern library that would unify the interface, establish clear design standards, and create a scalable system for future development. This would be AccessAlly's first formal design system, bringing order to years of organic growth.

The project was going well until AccessAlly was acquired by Caseproof in March 2024. The acquisition meant shifting priorities and integrating AccessAlly into a larger product ecosystem. We had to pause the pattern library implementation before it was fully deployed. But the work wasn't wasted. The research, components, and documentation I created have become valuable assets for other Caseproof products, and there's still potential for the full system to be implemented in the future.

The AccessAlly team knew they had UI consistency issues, but they didn't know the full extent until we did a comprehensive audit. Working closely with the product manager, I systematically reviewed every major feature area in the product.

What we found was worse than expected:

The platform had at least seven different button styles, three different navigation patterns depending on which feature you were using, and inconsistent typography across settings pages. Some areas used blue as the primary action color. Others used green. Form inputs had different heights, border radiuses, and focus states. The Settings area looked completely different from the Dashboard, which looked different from the Offering Builder.

This wasn't a failure of the original 2021 redesign. It was the natural consequence of adding new features quickly to meet customer needs without a formal UI library to maintain consistency. The founder and main developer was focused on building powerful functionality, and without documented patterns to reference, each new feature was implemented as seemed best at the time. But the consequences of this organic growth were real.

The development team was frustrated. Every new feature meant building components from scratch or copying code from different parts of the product and hoping it worked. There was no single source of truth for how buttons should behave or what spacing to use.

Support was getting questions about where to find features because the navigation wasn't predictable. Users would learn one pattern in Offering Settings, then encounter a completely different layout in Members Settings.

The product manager shared customer feedback showing that new users found the platform overwhelming. Part of that was inherent complexity (it's a powerful tool), but inconsistent UI patterns made the learning curve steeper than it needed to be.

We team members, support, certified experts, and reviewed customer feedback tickets. The pattern was clear: the lack of design standards and information heirarchy confusion was slowing down development, confusing users, and creating unnecessary support burden.

I proposed building a comprehensive pattern library in Figma that would serve as the single source of truth for all UI design decisions. This wasn't about redesigning AccessAlly from scratch. It was about documenting, standardizing, and improving what already worked while creating clear patterns for future development.

The foundation: Design tokens

I started with the fundamentals. I defined a complete color system with accessible contrast ratios (WCAG 2.2 AA compliance), established a type scale that would work across all features, and created a spacing system based on an 8-point grid. These tokens would be the building blocks for every component.

Component library

I designed standardized versions of every UI element: buttons (with primary, secondary, and tertiary variants), form inputs (text fields, dropdowns, checkboxes, radio buttons), data tables, cards, modals, and navigation components. Each component had clear states (default, hover, active, disabled, error) and usage guidelines explaining when to use which variant.

The charts and metrics cards were particularly important. AccessAlly shows a lot of data (course completion rates, membership statistics, sales figures), but it was being visualized inconsistently. I created a unified charting system with consistent colors, typography, and interaction patterns.

Documentation and guidelines

For each component, I wrote documentation explaining not just how it looked, but when and why to use it. "Use a primary button for the main action on a page. Use secondary buttons for alternative actions. Never use more than one primary button in the same context." This kind of guidance would help developers make consistent decisions without needing designer approval for every implementation.

I also established accessibility guidelines for color contrast, keyboard navigation, and screen reader support, ensuring the pattern library would improve accessibility across the platform.

Design systems need champions, not just designers.

The biggest challenge wasn't designing the components. It was getting organizational buy-in for the ongoing maintenance and governance a design system requires. A pattern library only works if people actually use it, which means it needs to be maintained, updated, and enforced. This requires dedicated resources and leadership commitment.

Start with the pain points, not the pretty components.

I initially wanted to design everything at once. But the product manager wisely pushed me to prioritize based on developer pain. We focused first on the components that were being recreated most often (buttons, forms, tables) because those would deliver immediate value to the development team. The fancy stuff could come later.

Documentation is as important as design.

Developers told me the written guidelines were more valuable than the Figma files. Knowing when to use a component mattered more than having a pixel-perfect spec. This shaped how I approached the entire project, spending as much time on usage documentation as visual design.

Phase 1: Audit and documentation (Weeks 1-2)

I started by taking screenshots of every major interface in AccessAlly and categorizing them by function. I documented every button style, every form pattern, every navigation treatment. This created a visual record of the inconsistencies and helped me identify patterns that were worth keeping versus ones that needed to be replaced.

I also interviewed the development team to understand their workflow and pain points. What components did they build most often? What parts of the codebase were hardest to maintain? This informed my prioritization.

Phase 2: Foundation and core components (Weeks 3-6)

I designed the foundational systems first: colors, typography, spacing, and the most commonly used components (buttons, forms, inputs). For each component, I created multiple variants and documented when to use each one.

I worked closely with the lead developer during this phase, showing him progress weekly and getting feedback on technical feasibility. Some of my initial designs were too complex to implement in WordPress, so we simplified them. Better to have a simple pattern that gets used than a perfect design that's too hard to build.

Phase 3: Complex components and patterns (Weeks 7-10)

With the foundations established, I moved on to more complex elements: data tables, charts, metrics cards, and navigation systems. These required more research because they needed to work across very different contexts (course management, membership settings, sales reporting, etc.).

I, along with the product manager, also designed some new patterns that didn't exist yet, like the favorites/bookmarks system and the redesigned top navigation with common tasks. These were proposals for future improvements, not just documentation of current state.

Phase 4: Documentation and handoff (Weeks 11-12)

I created comprehensive documentation in Figma explaining every component, wrote usage guidelines, and prepared to hand the system off to the development team for implementation.

When AccessAlly was acquired by Caseproof in March 2024, the pattern library project was about 80% complete. We had finished all the core components, design tokens, and documentation. What remained was implementation: actually applying the new patterns across the existing product and building new features with the system.

The acquisition shifted priorities. Caseproof needed to integrate AccessAlly into their existing product ecosystem, which meant different technical requirements and potentially different design standards. Rather than rush to implement a pattern library that might not fit the new strategic direction, the decision was made to pause implementation.

But the work wasn't wasted.

The research, components, and documentation I created have become valuable resources for other Caseproof products. The accessibility guidelines, component documentation, and design thinking behind the pattern library have influenced how the broader team approaches UI consistency.

More importantly, the process taught me valuable lessons about designing systems for mature products, working within technical constraints (WordPress, PHP, legacy code), and the importance of organizational readiness for design system adoption.

There's still potential for the full pattern library to be implemented in AccessAlly in the future, once the product integration stabilizes and the team has bandwidth to tackle the systematic UI updates. The Figma files and documentation are ready when that time comes.

What I delivered:

A complete Figma pattern library with over 50 documented components, comprehensive design tokens (colors, typography, spacing), usage guidelines and best practices, accessibility standards (WCAG 2.2 AA), and proposals for new navigation and organizational patterns. All ready for implementation when the timing is right.

Not every project gets finished, and that's okay.

This was my first major project that got paused before completion due to external factors. Initially, that felt like failure. But I learned to reframe it. I delivered everything I was asked to deliver. The circumstances changed. That's business. The work still has value, even if it hasn't been implemented yet.

Design systems are organizational change projects, not just design projects.

Creating the components was the easy part. The hard part is getting an organization to adopt and maintain a design system. That requires executive buy-in, dedicated resources, clear governance, and cultural change. I can design the perfect system, but if the organization isn't ready to use it, it won't succeed. This taught me to ask different questions at the start of design system projects about organizational readiness, not just technical requirements.

Constraints breed creativity.

Working within WordPress and PHP constraints forced me to design simpler, more practical solutions. My first drafts were often too complex to implement. The developer feedback pushed me to find elegant solutions that were actually buildable. Those constraints made the final system better, not worse.

Document for humans, not for perfection.

The most valuable part of this project turned out to be the documentation and guidelines, not the pixel-perfect Figma components. Developers needed to know when to use something and why, not just what it looked like. This changed how I approach design documentation. I now spend as much time writing clear guidelines as I do designing the visual components.

What I'd do differently:

I would have pushed harder for a pilot implementation earlier. If we had implemented even one section of the product with the new patterns before the acquisition, we would have learned valuable lessons about adoption challenges and technical constraints. Instead, we did all the design work upfront without real-world testing. That's a risk.

This project taught me that sometimes the value of design work isn't immediate implementation. It's the thinking, the documentation, and the standards that influence future work. The AccessAlly pattern library may not be fully implemented yet, but its influence is felt across the Caseproof product ecosystem. That's still impact, even if it's not the impact I originally envisioned.