Category: Career Reflection

The Problem Hasn’t Changed

A look back at more than twenty years of creating consistency, scalability, and better developer experiences.

If someone asks me about design systems today, I usually smile. Not because I’ve spent the last few years working on them. Because I’ve been building them for almost my entire career.

Long before Figma libraries, design tokens, Storybook, or component-driven development became industry standards, I was already trying to solve the same problem:

How do we help teams build products faster without sacrificing quality or consistency?

The tools have changed dramatically.

The problem hasn’t.

It Started Before UX Had Modern Tools (2005 – 2014)

“Consistency depended almost entirely on who happened to be building that page.”

When I began my career, there was no Figma, Sketch, or Adobe XD. Most interfaces were designed in Photoshop, and developers recreated everything by hand. Every project had its own buttons, spacing, colors, forms, and interaction patterns. Consistency depended almost entirely on who happened to be building that page.

Very early on, I realized that approach wasn’t scalable. I began creating reusable front-end component libraries using HTML, CSS, JavaScript, jQuery, and centralized repositories, giving multiple teams a shared set of UI components they could build from. Looking back, they were design systems.

We just didn’t call them that yet.

TimeKeeper (2014-2015)

TimeKeeper was one of my first opportunities to introduce formalized design systems.

We worked in a Ruby on Rails environment using Photoshop before eventually transitioning into Sketch.

I implemented Bootstrap, but support inside Sketch didn’t exist yet. So, I built my own.

Instead of recreating interfaces from scratch, I created reusable Bootstrap-based UI assets that allowed designers and developers to stay aligned.

Even then, my focus wasn’t simply making screens.

It was creating systems that made everyone else’s work easier.

📒 Case Study: https://danolsavsky.com/timekeepr-a-time-and-project-tracking-app/

Stackup (2015-2016)

At Stackup, the system became more mature.

Working in Angular with UXPin, I built and maintained a customized Bootstrap design system while also developing a reusable HTML/CSS/JavaScript component library.

Unlike many design systems that stop inside a design tool, ours extended directly into implementation.

The same patterns designers created became the patterns developers shipped.

I also maintained a continuous integration process for the component library and worked closely with engineering to keep everything synchronized.

That experience reinforced an important lesson:

A design system isn’t successful because the files look organized. It’s successful when designers and developers are building from the same source of truth.

📒 Case Study: https://danolsavsky.com/designing-a-reading-analytics-platform-for-k-12-students/

T-Mobile (2017-2018)

Joining T-Mobile meant contributing to an established enterprise design system instead of creating one from scratch.

Working in Angular with Sketch, Zeplin, and InVision, I helped extend GLUE (Global Library for a Unified Experience), T-Mobile’s enterprise design system.

My work focused on expanding GLUE with components for internal applications while participating in governance reviews and contributing components back into the shared library.

It was my first experience operating within large-scale design system governance.

That taught me something new:

Sometimes leadership isn’t inventing the system. Sometimes it’s knowing how to improve it without breaking consistency for everyone else.

📒 Case study: https://danolsavsky.com/designing-a-secure-legal-data-request-platform-for-t-mobile/

Scaled Agile (2018-2025)

Scaled Agile represents the largest and most impactful design system work of my career.

When I joined the company, there wasn’t a centralized design system. There wasn’t even another product designer.

There were multiple teams solving similar problems in different ways.

As a shared product designer supporting several product teams, I had a unique perspective across the organization.

I saw the duplication.

I saw the inconsistencies.

I also saw the opportunity.

I created the first version of SALSA (Scaled Agile Library for Styling Assets), a design system based on Salesforce Lightning that supported Salesforce, WordPress, responsive web applications, and numerous third-party integrations.

As the company nearly doubled in size, our design and engineering organizations grew with it.

The design system had to grow too.

We eventually transitioned from Sketch and InVision to a modern Figma workflow supported by our new library LiME (Library for Modernized Experience), and Storybook.

The migration wasn’t just about changing tools.

It required helping an entire organization change the way it worked.

I created Figma training materials, built onboarding curriculum inside our learning management system, and helped teammates transition into new workflows.

Because I had already gone through the learning process myself, I understood where people struggled.

That made it easier to teach.

Along the way I also helped establish governance, distribution, documentation, and cross-functional collaboration across product designers, engineers, technical writers, graphic designers, and motion designers.

The system became much more than a component library.

It became a shared language.

📒 Case Study, https://danolsavsky.com/scaling-ux-and-design-systems-for-a-global-platform/

The Evolution of Design Systems

If you look across my career, the tools have changed constantly. Photoshop gave way to Sketch, Sketch eventually became Figma, static mockups evolved into interactive prototypes, and component libraries matured into Storybook, design tokens, and modern design system workflows, and AI capabilities.

What hasn’t changed is my philosophy.

Good design systems create consistency without limiting creativity. They reduce repetitive work, improve communication between designers and engineers, simplify onboarding, and help organizations scale.

Most importantly, they allow teams to spend less time rebuilding the basics and more time solving meaningful customer problems.

Looking Forward

“Helping teams create better products together will always be the real purpose of a design system.”

After spending more than two decades building products, I’ve realized that my favorite work isn’t designing individual screens.

It’s building the systems that help hundreds of people design better screens.

Whether that means architecture, governance, education, documentation, developer collaboration, or mentoring the next generation of designers, I still find the same challenge fascinating.

Technology will continue to change.

Design tools will continue to evolve.

But helping teams create better products together will always be the real purpose of a design system.

More Than Product Delivery

What two decades of technical leadership has taught me about helping people, processes, and products grow.

My Leadership Approach

People often ask me about my leadership style. I usually start by talking about curiosity.

Every person is different. They come with different experiences, confidence levels, fears, and ways of learning.

Start With Curiosity

Before I can help someone grow, I need to understand who they are, so the first thing I do is listen. I want to know what excites them, what frustrates them, what they’re afraid of, and where they want to go.

Most importantly, I want to know why.

“Before I can help someone grow, I need to understand who they are”

From Understanding to Alignment

Once you understand someone’s motivations, coaching becomes much more personal than simply assigning work or reviewing designs. It also helps you understand how they solve problems, where they struggle, and how they collaborate with others.

That context makes it much easier to align people around shared goals, resolve disagreements, and build processes that allow the entire team to succeed.

Design systems scale products.
Processes scale teams.
Leadership scales people.

Optimizing Teams Through Systems

Throughout my career, I’ve been drawn to learning new tools, technologies, and workflows, not because I enjoy technology for its own sake, but because I enjoy understanding how people work. Once I understand both, I start asking better questions.

Where is the friction?

Why does this process take so long?

Why are two teams solving the same problem differently?

Can we standardize this? Can we automate it? Can we simplify it?

Whether the answer was introducing a design system, migrating from Sketch to Figma, building onboarding curriculum, creating reusable templates, improving governance, or documenting better workflows, my goal has always been the same:

Help people spend less time fighting the process and more time creating great products.

Leadership Has Taken Many Forms

Over the past twenty-two years, leadership has taken many forms. Sometimes it meant leading teams of designers. Other times, it meant improving the systems around them.

Team Leadership

Leading design teams, running internship programs, mentoring students, and helping people collaborate during workshops and hackathons.

Operations and Process

Managing vendor relationships and budgets, streamlining workflows, improving documentation, and introducing more effective ways of working.

Teaching and Coaching

Teaching college courses, conducting portfolio reviews, mentoring designers, and helping people build confidence in their skills and decisions.

The roles were different, but the mission remained the same: invest in people, improve the processes that support them, and create an environment where teams can do their best work.

Sometimes leadership means helping one designer grow. Other times, it means aligning an entire team around a shared direction, introducing a new workflow, or improving the tools that make everyone’s job easier.

My Philosophy

I believe leadership begins with trust. People need to know it’s safe to ask questions, admit they don’t know something, and make mistakes.

Trust Creates Room to Grow

When people are afraid of looking foolish, they stop taking risks. And when they stop taking risks, they stop growing.

That’s why I’m transparent about my own mistakes.

No one expects perfection. They expect honesty.

Adapt the Approach

No two people learn the same way. Some need structure. Some need encouragement. Some want detailed critique, while others simply need someone to believe they’re capable.

My job isn’t to force everyone into one mentoring style. It’s to adapt my approach to the person in front of me.

The same principle applies to teams. Every team has different strengths, communication styles, and ways of working.

Part of technical leadership is recognizing those differences, finding common ground, and building processes that help everyone move in the same direction.

Confidence Changes Everything

Confidence creates momentum. Momentum creates action. Action creates growth.

One lesson I’ve learned over and over again is that technical skills usually aren’t the biggest obstacle.

Confidence is.

I’ve worked with incredibly talented designers who consistently underestimated themselves. They already had the skills to succeed. What they lacked was the confidence to trust their instincts, speak up in meetings, or take ownership of difficult problems. Sometimes they just needed someone to remind them they belonged in the room.

I jokingly call it “gassing people up,” but there’s something much deeper behind it. Confident designers make better decisions. Confident teams move faster because they spend less time second-guessing themselves and more time solving real world problems.

Building Capability

Creating Resources That Scale

Throughout my career, I’ve created training curricula, assessment rubrics, workshops, coaching programs, portfolio reviews, blog articles, and, more recently, AI coaching tools.

Making Learning Easier

Each resource served a different purpose, but none of them was created simply for the sake of producing content. The goal was always to remove barriers to learning, make knowledge easier to access, and help people grow with greater confidence.

Improving the Way Teams Work

The same mindset applies to tools and processes. Whether I’m introducing a new design tool, improving a design system workflow, or documenting best practices, I’m looking for ways to reduce friction, eliminate repetitive work, and help teams focus on meaningful problems instead of fighting their tools.

Ultimately, I want people to leave every interaction feeling more capable than when they arrived. Sometimes that means teaching a technical skill. Sometimes it means offering career guidance. And sometimes it simply means helping someone recognize potential in themselves before they can see it on their own.

The Greatest Compliment I’ve Ever Received

Over the years, several mentors have told me something that has stayed with me:

“You have a gift for unlocking talent.” 

I didn’t know there was a name for what I enjoyed doing. I just knew I loved watching people surprise themselves and accomplish things they never thought they were capable of.

One of the greatest rewards of my career has been watching the people I’ve mentored continue to grow long after our time together.

Some have become senior designers. Others have gone on to become design leaders, directors, and vice presidents. Watching their careers flourish has been every bit as rewarding as the milestones in my own.

Why This Matters More Than Ever

I’ve worked across healthcare, finance, education, enterprise software, startups, and consumer products. The industries have changed. The technology has changed. Even the job titles have changed. But one thing has remained remarkably consistent.

Great organizations are built by growing great people.

Design systems scale products. Processes scale teams. Leadership scales people.

If I had to choose where I find the most fulfillment today, the answer is easy. I still love solving complex UX problems, but what excites me even more is helping someone else discover that they can solve them too.

Watching someone grow into a more confident designer, a stronger leader, or the person they always had the potential to become is one of the most rewarding parts of my career.

That’s the kind of leader I’ve always tried to be, and it’s the kind of leader I hope to continue becoming.

Design systems scale products.
Processes scale teams.
Leadership scales people.

Image note: The images in this series were AI-generated using real-world photographs as visual references. They are not photographs of my home and are not intended to be exact replicas of any real location -although I do have a pretty nice view ;o)