# Dağınık Arayüzden Tasarım Sistemine: Beş Panelin Hikâyesi

> Dağılmış beş yönetim panelini design token'lar, ortak bileşenler ve buton hiyerarşisiyle tek bir tasarım diline taşıdım; işi iki arkadaşımla yürüttük.

Source: https://omergulcicek.com/blog/daginik-arayuzden-tasarim-sistemine

Yakın zamanda frontend takım lideri olarak katıldığım bir şirkette beş farklı yönetim paneli vardı: OMS, CMS, PIM ve back office gibi. Hepsi aynı işi yapan, aynı yapıda arayüzlerdi. Ama her biri sıfırdan, birbirinden habersiz kurulmuştu.

Bu yazıda bu beş paneli nasıl tek bir tasarım diline taşıdığımızı anlattım.

## Sorun

Zamanla projelere farklı geliştiriciler girdikçe yapı her gün biraz daha dağılmıştı. Her panelin kendi butonu, kendi dropdown'u, kendi renkleri vardı. Bir özellik ya da tasarım değişikliği istendiğinde beş ayrı projede yüzlerce butonu, menüyü ve dropdown'u tek tek düzeltmek gerekiyordu. Küçük bir revizyon bile ciddi bir iş yüküne dönüşüyordu.

## Önce Analiz

İşe girer girmez ilk işim kod yazmak değil, bu dağınıklığı analiz etmek oldu. Hangi bileşenler tekrar ediyor, hangi renkler aslında aynı rengin farklı tonları, hangi boşluklar rastgele seçilmiş? Bu analizden ortak bir temelin neleri kapsaması gerektiği çıktı.

## Temeli Kurmak

İki şey kurdum:

- **Design token'lar:** Renk, border, boşluk, tipografi ve köşe yuvarlaklığı sabit değişkenlerden üretildi. Örneğin CMS'te bir marka rengi değişkeni tanımladık ve tüm primary butonlar bu değişkeni kullanmaya başladı.
- **Ortak bileşenler:** Projelerde dropdown'lar birbirinden farklı stillerdeydi. Hazır bir dropdown'ı alıp panellerin ihtiyaçlarına göre geliştirdim ve tek bir dropdown bileşenine dönüştürdüm. Butonlar ve menüler de aynı yoldan geçti.

Token'ların katmanlarını ve isimlendirmesini [Design Token Mimarisi](https://omergulcicek.com/blog/design-token-mimarisi) yazısında ayrıntısıyla anlattım.

## Buton Hiyerarşisi

Tutarsızlık yalnızca stilde değildi. Bazı sayfalarda iki üç tane primary buton yan yana duruyordu ve kullanıcı hangisinin asıl işlem olduğunu anlayamıyordu. Bir sayfada her şey öne çıkarsa hiçbir şey öne çıkmaz.

Her sayfada asıl işlemi bulup yalnızca onu primary yaptım. Diğerlerini önem sırasına göre secondary ve tertiary olarak düzenledim. Böylece ortak buton bileşeni sadece görünüşü değil, sayfadaki önceliği de tutarlı hâle getirdi.

## Ekibe Devretmek

Sorumluluğumdaki ekipte 10 frontend geliştirici vardı; bu işi içlerinden ikisiyle birlikte yürüttük. Temeli ben attım, sonra tekrar eden işleri bu iki arkadaşıma devrettim: yeni bileşeni sayfalara tek tek uygulamak ve eski stilleri token'larla değiştirmek. Her adımda neyi neden yaptığımızı anlattım. Bana güveniyorlardı, bu yüzden süreç hızlı ilerledi.

Sıralama her projede aynıydı:

1. Önce bileşen: dağınık butonlar ve dropdown'lar ortak bileşene geçti.
2. Sonra değişken: elle yazılmış renkler ve ölçüler token'lara döndü.
3. En son kontrol: sayfaları tek tek gezip boşlukları ve hizaları düzelttik.

## Sonuç

Artık tek bir değişkeni değiştirdiğimizde paneldeki bütün renkler ya da border'lar birlikte değişiyordu. Bileşenler tek bir yerde olduğu için revizyonlar çok daha hızlı çıkıyordu. Beş farklı proje olmasına rağmen hepsi **tek elden çıkmış gibi** görünüyordu.

## Geriye Dönüp Bakınca

Orada dört ay çalıştım ve bu sürede her projeyi kendi içinde iyileştirdim; ortak bileşenler her projenin içinde yaşıyordu. Biraz daha zamanım olsaydı bir sonraki adım monorepo olurdu: bileşenleri ve token'ları tek bir yerde toplardım. Böylece beş proje aynı kaynağı kullanır, bir düzeltme tek bir yerden hepsine ulaşırdı.

## Özet

- Önce analiz: neyin tekrar ettiğini görmeden ortak bir temel kurulamaz.
- Token'lar kararları, ortak bileşenler kullanımı tek bir yerde toplar.
- Her sayfada tek bir primary buton olur; diğerleri secondary ve tertiary olarak sıralanır.
- Temeli kur, tekrar eden işi nedenini anlatarak ekibe devret.
- Sıra önemli: bileşen, değişken, sonra sayfa sayfa kontrol.
- Birden fazla proje aynı dili konuşacaksa ortak kaynak en baştan düşünülmeli.