The "Villanova Knicks" design captures a unique moment in time—a celebration of the excitement and anticipation when four Villanova alumni reunited on the New York Knicks roster. For a brief summer, New York City was buzzing with the idea that Jalen Brunson, Josh Hart, Donte DiVincenzo, and Mikal Bridges could rekindle their shared history and chemistry, building something special on the professional stage.

‍

‍

‍

‍

Inspired by the vintage NYC Subway token, a symbol deeply tied to New York’s history, the artwork blends this iconic imagery with the Knicks logo. The two diamond shapes in the design mirror those found on the old subway tokens, but they carry a deeper significance here. Each of the four corners of the diamonds represents one of the four Villanova players, united within the design to symbolize their shared journey, commitment, and mission to make their mark on Knicks history.

Even though DiVincenzo is no longer part of the roster, this design is a tribute to the strong bond the Villanova Knicks brought to the city—a bond that still exists as the team pushes forward. Like the subway connecting millions of New Yorkers, the remaining three players continue to be part of something larger, weaving their journeys into the city’s vibrant basketball culture.

Ultimately, the "Villanova Knicks" design is more than just a nod to the players; it’s a celebration of New York, its deep basketball culture, and the long-term promise this team represents. The design embodies a sense of unity, optimism, and resilience, reflecting the belief that this young core will continue to grow and thrive over the next few years. By combining elements of the past with a forward-looking vision, this piece honors both the legacy and the bright future that Knicks fans believe in, as the team builds toward lasting success.

‍

Establishing a System Mindset

‍

To move the organization forward, I knew we needed a shared understanding of what a design system really is. I suggested that a small group take a design systems course early, so we could align on the principles needed to build something scalable and usable. Leadership approved it, and three of us took Dan Mall’s course together. It gave us a shared language, a common mindset, and a solid foundation to move forward as a unified team.

Listening First: Research Across the Org

‍

We met with senior leaders, PMs, engineers, and designers across the organization to understand their expectations and challenges. I asked how they defined a design system, what successful adoption looked like, and where the gaps were.

‍

Common themes

• Lack of documentation
• No accessibility guidance
• Low adoption
• Inconsistent support
• No shared vocabulary
• Unclear starting point for teams

Listening first gave me a clear picture of what teams truly needed and helped shape a system grounded in real problems.

‍

‍

‍

Building the foundation

‍

‍

Audits and extraction

‍

I reviewed old style guides, previous system attempts, and product UI across teams. I extracted reusable decisions to build a more stable foundation.

‍

‍

Token architecture

‍

I worked with engineers early and agreed on a Tailwind-compatible structure. I taught myself Token Studio so I could generate JSON that engineering could use into their build process.

‍

This helped build trust and saved engineering hours on mapping design to code.

An Inclusive Entry Point For Everyone

‍

Different roles needed different ways in.

• Designers used Figma.
• Engineers used Git and Storybook.
• PMs needed a clear place to browse.

Mockingjay on Zeroheight became the central hub. No matter your role, you could start from where you were most comfortable.

‍

This boosted adoption and made the system feel approachable.

‍

Design Decisions With Intention

‍

I documented not just the “What,” but the “Why.”

‍

Examples

• Popover vs Dialog vs Drawer
• When to use which and why
• Sizing rules
• Behavior expectations
• Best practices that matched engineering constraints

This reduced ambiguity and helped teams make faster decisions with fewer reviews.

‍

Accessibility Built Into the System

‍

Public school products must meet strict accessibility requirements, and without them, our products cannot be sold to schools. Engineers needed clear and actionable guidance, so I documented ARIA roles, focus behavior, keyboard patterns, and accessible defaults.

‍

I also served as a design advocate in our Accessibility Center of Excellence (ACE), helping teams shift from “checking the box” to designing with inclusion from the start.

‍

Accessibility became a core value of the system.

‍

Writing For Everyone

‍

Documentation was written at a seventh to eighth grade reading level to ensure clarity for everyone. This helped:

• ESL team members
• Non technical roles
• New designers
• New engineers

I focused on clear, simple language over complexity.

‍

I used Scholastic’s own Harry Potter series as inspiration. Part of its success comes from being written in a way that readers of many ages and reading levels can understand it. I brought that same approach to our internal documentation.

‍

Process For Faster Work

‍

‍

Figma sticker sheets

‍

I created grab-and-go layouts based on real product patterns. Designers did not need to customize or rebuild components. They copy and paste.

‍

This cut design time and improved consistency.

‍

‍

Metadata and search

‍

Different teams used different words for the same thing, so I added alternate keywords to help everyone find what they needed.

‍

Everything Stays Connected

‍

To make the system easy for everyone to use, I connected design, code, and documentation in one flow. From Figma, teams could jump directly to Storybook for engineering details and to Zeroheight for full documentation. No one had to search for specs or wonder where anything lived. Every component carried its own links, so the context traveled with it.

‍

This kept designers and engineers aligned, reduced back-and-forth, and made the system simple to use across all tools.

‍

Designing With data

‍

I used Figma analytics to track how components were being used, where they were getting detached, and where designers were running into friction. When I noticed a pattern, I reached out directly to designers to understand the real problem behind it.

‍

One clear example was the Tabs component. The first version only supported three items, but designers kept detaching it because their use cases needed more flexibility. After hearing that feedback, I expanded the component so teams could add more tabs. Once I shipped the update, detachments dropped and consistency across products improved.

‍

Government With Boundaries

‍

In a design system, boundaries keep the whole organization moving in the right direction. I learned early that I could not say yes to every one-off request. If I tried, the system would slow down and lose trust.

‍

So I kept it simple.

If a component supported multiple teams, helped us scale, or aligned with company goals, it moved forward. If it only solved one team’s unique problem, I guided them toward local solutions instead.

‍

Setting clear expectations, being transparent, and explaining the “why” made collaboration easier. It kept the system healthy, and it helped teams understand how to work with me while still feeling supported.

‍

‍

Championing The System

‍

I stayed close to the teams using the system. I opened a dedicated Teams channel so people always had a place to ask questions, share ideas, or get quick help. I also hosted regular office hours and live demos so we could walk through new components together and make sure everyone felt supported.

‍

Any time something shipped or changed, I shared clear updates with context and links so teams always knew what was new and why it mattered. The goal was to make the system feel approachable, helpful, and easy to use.

‍

Over time, people began reaching out earlier in their process, asking for guidance, and even promoting system updates on their own. That is when you know a design system is doing its job.

‍

Real Adoption, Real Momentum

‍

As the system matured, teams began using Mockingjay without being pushed. It showed up in product demos, planning sessions, and cross-team discussions.

‍

Impact

• Designers and engineers became advocates
• More teams asked to onboard
• Releases shipped faster and more consistently
• The system became part of the natural workflow
• Teams trusted the system because it solved real problems


Mockingjay started as a tool, but it grew into a shared culture.

‍

‍

Reflection: The system is easy, people are hard

‍

I learned that the system is the easy part. The real work is supporting people who are under pressure and juggling deadlines. Sometimes that stress shows up as frustration with the system, but it is never personal. I learned to listen, stay patient, and meet teams where they are. When people feel heard and supported, the entire system gets better. That is what makes the work meaningful.

‍

Personal Reflection

‍

Mockingjay was more than a system. It was a team effort that showed me how much is possible when people trust each other and work toward a clear vision. Leading it helped me understand the kind of designer I want to keep growing into: someone who builds with people, listens with intention, and helps teams move with clarity and confidence.

‍