Pattern Library

03.1 /

The first version

After Radancy's creative team moved from Adobe Creative Suite to Sketch as its primary design tool, it built its first shared Pattern Library. The effort was led by an experienced designer who joined through an acquisition and brought previous design-system experience. The goal was to establish a useful foundation, learn from how the team used it and improve it over time.

Before the library, designers often started from older project files, referenced live sites, relied on what they already knew about the platform or reached out to colleagues when they were unsure whether a particular design solution was feasible. The Pattern Library gave them a more consistent foundation and a set of established options they could adapt to their work.

That first version was built while the creative team was still learning Sketch, and some patterns did not fully align with what we knew about usability, accessibility or the platform's requirements and limitations. The library was always meant to evolve alongside changes to the product and implementation process, so some refinement was expected.

Because my work was so closely tied to the creative team, the company aligned my role more directly with theirs by pairing me with a manager from that side of the business. Around the same time, I moved from Axure RP to Sketch to make the wireframe-to-creative handoff more efficient. That put me closer to the designers using my wireframes and gave me a better view into how they worked with the Pattern Library, while putting me in a better position to improve it from a UX perspective and give them clearer product guidance. The library had already proven its value, but we knew it needed a full audit to make sure it was current and dependable enough for designers to trust.

03.2 /

Auditing for trust

An existing pattern in the library could work well from one perspective but still not earn its place in the Pattern Library. For example, something that was visually strong might not be feasible within the platform, while something that was accessible might still introduce usability concerns. If the library was going to be something designers could depend on, no single discipline could define what belonged there on its own.

My manager and I brought in partners from development and accessibility, with each of us reviewing the library independently in Sketch from our own area of expertise. I focused on usability and UX, but the lines were rarely that clean. I might flag something as confusing and also note a possible accessibility concern, while another pattern I had no UX issue with might already have been flagged for a development limitation. Reviewing separately gave each of us time to look closely at the work, and seeing those perspectives overlap helped expose problems that may have been easy to miss otherwise.

Once everyone had finished, we regrouped to discuss the findings and make sure we understood why each pattern had been flagged. Some only required small adjustments, others could be consolidated and some no longer represented options we wanted designers using. From there, my manager and I worked through how to apply those decisions to the library, with me handling much of the updating and redesign work.

I tried to make those changes carefully rather than treating the audit as permission to rewrite everything at once. When a solution was obvious, I moved forward, but when it felt more subjective, I kept the original nearby or worked through the change separately so my manager or one of the other review partners could weigh in before we published the update. The goal was not simply to clean up the file. It was to make sure that if something remained in the Pattern Library, designers had good reason to trust that it had been considered from more than one angle.

03.3 /

A safer way to retire patterns

The audit made it clear that some patterns should no longer be presented as approved options, but removing them from the library entirely created another problem. Some older project files were still connected to the shared Pattern Library, which meant deleting a Symbol could affect work that designers might need to reopen later.

Leaving those patterns where they were wasn't a good answer either. A designer starting a new project could still find one in the library and reasonably assume it was approved for use.

I proposed a status system that let us retire or flag patterns without immediately removing them. I created reusable Sketch Symbols designed as status stamps that could be placed directly over affected patterns, with three statuses based on what we had learned during the audit.

No Longer Supported identified patterns that shouldn't be used on future projects. Pause Usage gave us a way to temporarily stop designers from using something while it was being reevaluated. Use With Caution covered the less clear-cut cases where a pattern could still work, but only with specific usability, accessibility or implementation considerations.

Each stamp included the date of the change and, when needed, a short explanation. For project files that remained connected to the shared library, those updates would appear when the file was reopened. I also organized unsupported and paused Symbols into clearly labeled folders within the library's Symbol folder structure so designers browsing for something new were less likely to select them in the first place.

The system wasn't a perfect safeguard because designers who had detached a Symbol from the shared library would not receive those later updates, but it gave us a way to preserve older work without continuing to present every legacy pattern as a current recommendation.

03.4 /

Keeping it useful

The audit and initial round of updates solved the immediate problems, but maintaining the library became an ongoing responsibility. My manager and I continued co-owning it, with both of us making updates as needs surfaced and using our regular check-ins to stay aligned. New product features required new patterns or updates to existing ones, while day-to-day project work often exposed Symbols that behaved oddly or were harder to use and customize than they needed to be.

When I ran into those issues, I would go back to the shared version and improve it rather than work around the problem only in my project file. That meant real client work became a natural way to keep testing and improving the library over time.

New additions worked much the same way. While many patterns were added to support new product features, I also added them when they filled a meaningful gap. If I came across a strong solution in my own work or elsewhere that felt broadly useful, I would consider adding it to the library. The same was true when I noticed the creative team regularly gravitating toward an approach that was not yet represented. In either case, I would develop it further, review it as needed and publish it for broader use.

By that point, I knew the career site product well enough to make many of those calls independently. When I was less certain about a technical or accessibility constraint, I went back to the people who knew that area best before treating the pattern as something other designers could rely on.

03.5 /

Bringing AI into the library

One of the bigger examples of that ongoing responsibility came as Radancy prepared to launch a new set of AI-powered career site features. By then, I had already been involved in the initiative, reviewing previous concepts and helping the AI team think through the overall experience from a product, career site and job seeker perspective.

As the features moved closer to implementation, the creative team needed clearer guidance on what they were actually being asked to design. My manager was responsible for making sure the team had the resources they needed, so she worked closely with the AI team to document how the features worked, where designers had flexibility and what needed to remain fixed. Because of my earlier involvement, I was able to contribute product and UX context as that guidance took shape.

When it was time to translate those rules into the Pattern Library, I was responsible for building the Sketch resources. I started by following familiar library conventions where it made sense, then created the AI-specific elements, components and patterns around the constraints we had worked through. If part of a feature needed to remain fixed, I structured the Symbol to make it harder for designers to make unsupported changes rather than relying on documentation alone.

I also worked through how the new resources should be named and organized so designers could find them easily, then built full page templates showing how the AI features fit into the existing career site experience. That was especially important because the AI search experience did not completely replace the standard job-search flow. It added new modules to some existing pages, introduced entirely new pages and required designers to understand how the AI and standard search experiences worked together when building a site.

When the updates launched, the new patterns and templates were paired with the internal documentation and a short overview presentation shared through the global creative Teams channels, while my manager led walkthroughs with the creative team. The templates became the reference designers were directed to when working with the new features, giving them a much clearer starting point than the mix of previous concepts and pitch designs that had existed before.

03.6 /

Closing thoughts

For all the improvements we made, the Pattern Library still had limitations we knew we eventually wanted to address. It had been built in an older version of Sketch, and while we could take advantage of many newer features as the application evolved, a major update in 2023 significantly changed how Symbols and Smart Layout worked.

After that update, newer versions of Sketch made it possible to build more flexible components that could resize and adapt more intelligently. The existing library still worked, but taking full advantage of the newer functionality would have meant rebuilding a significant portion of its underlying structure rather than simply updating a few patterns.

To avoid forcing the master Pattern Library file into the newer version before we were ready, my manager and I kept both an older and newer version of Sketch installed. Current project work happened in the newer version, while library maintenance required returning to the older one because it handled the existing Symbols more predictably. The workaround kept things moving, but it also made it clear that maintaining the existing library and rebuilding it properly had become two different problems.

Creating a Pattern Library 2.0 came up several times in our discussions. The priorities were a cleaner naming and organizational structure, fewer nearly identical variations and more flexible components built around the newer Sketch features. I also felt we needed a clearer way to distinguish foundational product patterns from more flexible content patterns that designers had more freedom to interpret. Doing that properly required time to understand the best way to use the newer Sketch features and workflows, rethink the library's architecture and account for a possible move to a different tool that many of our customers' in-house creative teams were already using.

That rebuild never happened while I was there. Instead, we kept improving the system we had, fixing what we could and making sure the resources designers depended on continued to reflect the product as accurately as possible. The Pattern Library itself was always meant to be a living system that evolved alongside the product. Maintaining it reinforced something I had learned throughout the project. A shared design system only stays useful when someone keeps questioning whether what it says is still true.