Angle2 🇺🇦

Starter design language kit for the agency cross-functional teams

Design language

Duration

August 2023 — April 2024

At our design agency, our small team — consisting of me as the Design System Owner and a UX Designer, along with one Developer —set out to create a unified in-house design kit.

We based it on our most effective practices to help everyone work more efficiently. With no official time allocated, we initially treated it as a side project. Over time, it evolved into a solid, well-structured system that we were proud to present to agency leadership and begin integrating into our design process.

Problem

Lost knowledge

From one side, information gets lost when moving user flows from UX to UI. From the other side, high turnover of employees makes it challenging to manage such transitions or transfer projects without losing knowledge.

Wasted resources

After the UX phase is done, the UI designer usually starts to create a design direction for the interface from scratch, even though the UX designer has already used the critical components to build the interface.

Higher solution cost

Time spent rebuilding the same components could be used to solve more critical user problems instead.

Challenges

Unify designer workflows

Different people work differently — we needed a basic, non-intrusive approach that actually helps everyone.

Separate internal process from external stylization

We didn't want all client projects to look identical, so we had to find ways how to separate our internal logic from the final results our clients see.

Flexible design-to-code handoff

Clients use different environments, so we needed to find ways to base our kit on a popular system that other developers could follow smoothly.

Design approach

After studying existing design systems and reviewing our agency's past projects, we chose our direction.

Material Design as a language foundation

Easy structure that adapts to different environments. We reused their language for our flexible components due to low dependencies, good developer support, and tech we often used in-house.

Build layered components: Base → UX → UI

Separate concerns for UX and UI work, but keep clear structural logic so components easily move between stages during handoff.

One Figma dictionary for properties

Design styles, spacing, and components should follow the same naming patterns across all projects to make collaboration easier.

Pillars of the starter kit

UX designer and I tested ideas in-between commercial projects to find common solutions that may work for our whole team.

List of 24 critical components

We focused on the most important ones like buttons and inputs with clear interaction rules. Instead of trying to cover everything, we made sure instead the essential components work perfectly across all projects.

Keep it simple

All components use the same system of sizing, spacing, and corner radius. If you need something different, you have to justify why. This makes components align smoothly and gives developers easy-to-follow spacing rules.

Role over style

We grouped colors and text styles by what they do, not how they look. This keeps the purpose clear and separates logic from what we see as a result.

Headless

Just copy the starter kit and start working immediately locally. Inheriting the components from one library limits the creative process, which in a design agency should never be the case.

Gets better over time

With each project, we collect more patterns and useful components from agency projects to add for future use. Makes a process more horizontal and open to collaboration.

Enclosed helpful resources

We inserted recommended commercial grids and icons inside the kit to simplify the life of every designer.

Component anatomy

The hardest part was defining rules for what goes where and why for each component. I encouraged the team to use the following set of components:

Base

Focus on structural variability and correct balance, leaving the visual details for later.

UX

Main concern is how the element and its role fits in the overall interface hierarchy.

UI

Focus on interactions and accessibility standards.

First test and results

A client asked our agency to build a radio web interface for the weather operators. Accidentally, two of us were appointed to the project, so it was a perfect ground to test our first kit in a collaborative environment. Here is what we found out:

Component driven design

Instead of UI process copying UX wireframes, we used our core components to rebuild UX designs atomically. In this way, UX-driven logic naturally evolves into a visually cohesive feel-n-look.

Complex UX prototypes shall stay

We now could update UX user flows without losing complex intertwined prototypes, which solved a major knowledge loss problem we had with most projects deliveries.

UX components do not define visual results

We worried that using the same system would make all projects look identical. Our test showed that the flexible separation of UX and UI concerns in the components structure allowed maximum customization while keeping the benefits of using a system.

Integration into agency projects

After presenting our test results to agency leadership, we got approval to integrate the system into our company design process. During my final six months, we achieved these results:

Quick wins

Used in 4 Projects

We saw that we lost much less information from UX to UI building stronger solutions. Two projects had developers on the client side, and they appreciated us basing our design process on the existing framework.

Faster developer communication

Using the same component structure and Material Design language helped us iterate faster and build testable prototypes quicker.

20% time savings per project

We cut setup time for design environments, giving us more time to dig in the problems and build better solutions.

Obstacles

Getting team buy-in

We often heard "Why change our process?" and "Why this way?". Some designers took it personally when we suggested changing their methods. We managed to minimize the negative impact through one-on-one conversations, sharing feedback and explaining our decisions based on the evidence.

Speed gain with creative loss

Ready-made components made designers lazy — they used defaults instead of exploring options. I guess, this is human nature. To solve this problem, we added a concept UI stage where designers work without the starter system first. After approval, designers planned how to adapt our components to match their vision.

Deciding what to add to the kit

When we had multiple versions of the same components among the projects, it was hard to choose which one to include. Thus, we created a document listing only the core elements we were missing and needed most. If every project uses it — we generalize those components into one. Everything else goes into a patterns library as inspiration for solving similar problems.