---
title: "Tasarım Sisteminizi Yapay Zekaya Nasıl Hazırlarsınız? Kurumsal Ekipler İçin Rehber"
description: "Yapay zeka markanıza uygun arayüz üretsin istiyorsanız tasarım sisteminizi markadan ayrıştırın, nötr bir çekirdeğe dönüştürün ve bir repo'da yaşatın."
date: "2026-11-03"
updated: "2026-11-03"
lang: "tr"
tags: ["tasarım sistemleri", "yapay zeka", "design.md", "kurumsal UX", "AI native"]
seoTitle: "Tasarım Sistemini Yapay Zekaya Hazırlamak — Things"
translationKey: "preparing-your-design-system-for-ai"
---

# Tasarım Sisteminizi Yapay Zekaya Nasıl Hazırlarsınız? Kurumsal Ekipler İçin Rehber

Aynı hafta iki ekip, yapay zeka kodlama asistanıyla birer ekran üretiyor. Biri sipariş listesini, diğeri müşteri profilini. İkisi de çalışıyor, ikisi de tek başına bakıldığında "doğru". Yan yana koyduğunuzda ise iki ayrı şirketin ürünü gibi duruyorlar: farklı mavi tonları, farklı buton yükseklikleri, farklı boşluklar. Tasarım sisteminiz var, ama yapay zeka onu kullanmıyor.

**Kısa cevap:** Yapay zekaya bir kural dosyası verdiğinizde ajan o kurallara çoğunlukla uyar. Ona kodda yaşayan bir tasarım sistemi verdiğinizde ise sistemi kullanır, uydurmaz. Bu yüzden tasarım sistemini yapay zekaya hazırlamanın yolu, onu markadan ayrıştırıp nötr bir çekirdeğe dönüştürmek ve bir repo'da, yaşayan hâlde tutup geliştirmektir.

Bu yazıda bunun neden böyle olduğunu ve adım adım nasıl yapıldığını anlatıyoruz.

## Tasarım artık nerede yapılıyor?

Uzun yıllar tasarım sistemleri Figma'da yaşadı. Bileşenler orada çizildi, renk stilleri orada tanımlandı; geliştirme ekibi de bunları koda "aktardı". Tasarım sistemi konuşmalarının çoğu bu yüzden aktarım üzerineydi: Figma'daki adlar koddakilerle nasıl eşleşir, bir değişiklik koda nasıl taşınır.

Bugün üretim farklı işliyor. Tasarım giderek daha fazla doğrudan kodla birlikte, yapay zeka araçlarıyla yapılıyor. Tasarımcı bir ekranı çizip devretmek yerine, onu gerçek bileşenlerle, tarayıcıda, ajanla birlikte kuruyor. Bu durumda tasarım sisteminin asıl yeri de değişiyor: Sistem, ekranların gerçekten üretildiği yerde, yani kodda olmalı.

Figma ortadan kalkmıyor. Keşif, hızlı eskiz ve görsel tartışma için hâlâ çok iyi bir araç. Ama artık kaynak değil. Kaynak repo.

## Kural dosyası mı, repo'daki sistem mi?

Son dönemde design.md gibi kural dosyaları, yapay zekanın tasarım sistemine uymasının çözümü olarak sıkça anılıyor. Bu dosyalar faydalıdır; markayı, ses tonunu ve kuralları ajana düz metinle anlatırlar. Ama bir sınırları var ve bunu dürüstçe söylemek gerekiyor.

**Kural dosyası olasılıksaldır.** Ajan bir kural dosyasını okur ve ona göre davranmaya çalışır. Çoğu zaman uyar. Ama yapay zeka ajanları design.md gibi kural dosyalarını %100 uygulamaz. "Birincil buton sayfada bir kez kullanılır" yazsanız da, uzun bir görevin ortasında ajan ikinci bir birincil buton ekleyebilir. "Ana renk lacivert" yazsanız da, ajan ona yakın ama farklı bir renk kodu yazabilir. Kural yön gösterir, garanti vermez.

**Repo'daki tasarım sistemi belirlenimcidir.** Sistem gerçek bileşenler, token'lar ve tipler olarak kodda durduğunda, ajan onu tahmin etmez; içe aktarır ve kullanır. `Button` bileşeni yalnızca tanımlı varyantları kabul ediyorsa ajan üçüncü bir varyant uyduramaz. Renkler token olarak tanımlıysa ve kod incelemesi doğrudan yazılmış renk kodunu kabul etmiyorsa, yanlış mavi ekrana çıkamaz. Repo'daki tasarım sistemini yapay zeka ajanı mutlak bir şekilde okur, uydurmaz.

Fark şudur: Kural dosyası ajana ne yapması gerektiğini anlatır. Koddaki sistem ise ajanın yapabileceklerini belirler. Biri tavsiye, diğeri zemin.

Girişteki iki ekibi düşünün. İkisinin de elinde aynı kural dosyası vardı; ajan iki ayrı görevde kuralları iki ayrı biçimde yorumladı. Aynı iki ekip, ekranları repo'daki ortak bileşenlerle kursaydı, sipariş listesi ile müşteri profili aynı butonu, aynı mavi tonunu ve aynı boşlukları kullanırdı. Çünkü ikisi de aynı kodu içe aktarırdı; yorumlanacak bir şey kalmazdı.

Bu yüzden design.md'nin yeri, repo'nun içindeki dosyalardan biri olmaktır: Sistemin neden böyle kurulduğunu ve kodda ifade edilemeyen ton gibi konuları anlatır. Dosyanın kendisini [design.md nedir](https://things.com.tr/blog/design-md-nedir-tasarim-dokumantasyonu) yazımızda anlattık. Ama garantiyi o dosya değil, koddaki sistem verir.

## Tasarım sistemini neden markadan ayırmalısınız?

Kurumsal bir projede tasarım sistemi genellikle o projenin markasıyla iç içe doğar. Butonlar o markanın renginde, köşeler o markanın yarıçapında, metinler o markanın tonundadır. Proje bittiğinde sistem de o markaya kilitlenmiş olur. Bir sonraki ürün, ya da grup şirketlerinden biri, aynı sistemi kullanmak istediğinde iki seçenek kalır: Ya her şeyi kopyalayıp tek tek değiştirmek ya da sıfırdan başlamak.

Bir tasarımcı olarak yapabileceğiniz en iyi şey, projenin tasarım sistemini marka öğelerinden ayrıştırıp nötr bir hâle getirmek, bir repo'da yaşayan hâlde tutmak ve geliştirmektir.

Bu ayrım iki katman demektir:

| | Nötr çekirdek | Marka katmanı |
|---|---|---|
| Ne içerir | Bileşenler, etkileşim kalıpları, durumlar (yükleniyor, boş, hata), boşluk ve ızgara mantığı, erişilebilirlik kuralları | Renkler, tipografi, logo, ses tonu, görseller |
| Nerede yaşar | Ortak repo, sürümlü | Her markanın tema dosyası |
| Kim değiştirir | Bütün markaları temsil eden küçük bir grup | O markanın tasarım sorumlusu |
| Ne sıklıkla değişir | Yavaş, inceleme sürecinden geçerek | Markanın ihtiyacına göre |

Nötr çekirdek, bir ürünün nasıl çalıştığını tarif eder. Marka katmanı ise nasıl göründüğünü ve nasıl konuştuğunu. Çekirdek bir kez doğru kurulduğunda, marka bir tema olarak üstüne giydirilir.

## Kurumsal şirketler için kazancı ne?

**Yeni ürün sıfırdan başlamaz.** Bir grup şirketinin yeni ürünü, ortak çekirdeği alır ve kendi temasını yazar. Tablo, form, filtre, bildirim gibi her üründe tekrar eden bileşenler zaten hazırdır ve zaten test edilmiştir.

**Tutarlılık kendiliğinden gelir.** Bütün markalar aynı bileşenleri kullandığı için davranış aynıdır. Bir kullanıcı grup şirketlerinin iki ayrı uygulamasında aynı formla karşılaştığında aynı şeyi bekleyebilir.

**Tasarım ve geliştirme aynı kaynağa bakar.** Tasarımcının ekranda gördüğü bileşenle mühendisin içe aktardığı bileşen aynı dosyadır. Aradaki "tasarımda böyleydi" konuşması ortadan kalkar.

**Her proje sistemi büyütür.** Bir projede eklenen ve çekirdeğe uygun olan bir bileşen, bir sonraki projede herkesin kullanımına açılır. Sistem bir proje teslimi olmaktan çıkar, şirketin varlığına dönüşür.

**Yapay zeka her markada doğru çalışır.** Ajan bir marka için ekran üretirken aynı çekirdek bileşenleri kullanır, yalnızca tema değişir. Yanlış renk seçme riski büyük ölçüde ortadan kalkar, çünkü renkleri seçen ajan değil, temadır.

## Repo'da yaşayan bir sistem neye benzer?

Kurgusal bir "Atlas" sistemi için tipik bir düzen şöyle görünebilir:

```
atlas/
├── core/                  ← nötr çekirdek, markadan bağımsız
│   ├── tokens/            ← boşluk, ızgara, köşe, gölge ölçekleri
│   ├── components/        ← Button, DataTable, Form, Toast ...
│   └── patterns/          ← boş durum, hata, yükleniyor
├── themes/
│   ├── marka-a/           ← renk, tipografi, logo
│   └── marka-b/
├── docs/
│   └── design.md          ← ton ve gerekçeler
└── CHANGELOG.md           ← her sürümde ne değişti
```

Dosya adları ekipten ekibe değişebilir; önemli olan üç ilke:

- **Çekirdek hiçbir markayı bilmez.** Çekirdekteki bir bileşen "lacivert" demez; "birincil renk" der. Değeri tema verir.
- **Bileşenler sınırlarını kendileri taşır.** Bir bileşenin hangi varyantları kabul ettiği, tiplerde tanımlıdır. Ajan ya da insan, tanımsız bir varyantı kullanmaya çalıştığında kod bunu kabul etmez.
- **Sistem sürümlenir.** Her değişiklik bir sürüm numarasıyla gelir; ürünler hangi sürümü kullandığını bilir ve ne zaman güncelleyeceğine kendisi karar verir.

## Tasarım sistemi yapay zekaya dört aşamada nasıl hazırlanır?

Biz bu işi AI native bir süreçle yapıyoruz. AI native, yapay zekayı sürecin her adımına yerleştiren stüdyo demek. Aşağıda dört aşamanın tasarım sistemine uyarlanmış hâlini anlatıyoruz.

**Keşfet.** Yapay zeka mevcut ekranları ve kod tabanını tarar; tutarsız renkleri, birbirinin kopyası olan bileşenleri ve adlandırma farklarını listeler. Hangi farkın bilinçli, hangisinin kaza olduğuna ekip karar verir. Kazanç: Sistemin gerçek durumu görünür hâle gelir. Bu taramanın nasıl yapıldığını [yapay zeka ile UX/UI analizi](https://things.com.tr/blog/yapay-zeka-ile-ux-ui-analizi) yazımızda anlattık.

**Kurgula.** Sistemin hangi parçasının çekirdeğe, hangisinin markaya ait olduğuna karar verilir. Yapay zeka bileşenleri tarar ve markaya bağlı değerleri işaretler; ayrımın son kararını ekip verir. Kazanç: Markadan bağımsız, tekrar kullanılabilir bir çekirdeğin planı.

**Hayata Geçir.** Çekirdek bir repo'ya taşınır; bileşenler, token'lar ve tipler olarak kodda tanımlanır. İlk marka bir tema olarak üstüne giydirilir. Tasarım bu repo üzerinde, doğrudan kodla birlikte yapılır; ajan ekranları çekirdek bileşenlerle kurar, ekip inceler. Kazanç: Tasarımda onaylanan, tarayıcıya aynı biçimde ulaşır. Ayrıntısını [yapay zeka ile tasarımdan koda](https://things.com.tr/blog/yapay-zeka-ile-tasarimdan-koda) yazımızda anlattık.

**Büyüt.** Her yeni proje çekirdeğe katkı yapar. Yapay zeka ürünlerde tekrar eden kalıpları raporlar; hangisinin çekirdeğe gireceğine sistemin sahibi karar verir. Kazanç: Sistem her projeyle biraz daha güçlenir.

## Hazırlık kontrol listesi

Sisteminizin nerede durduğunu görmek için aşağıdaki listeyi kopyalayıp ekibinizle doldurabilirsiniz.

```
TASARIM SİSTEMİ HAZIRLIK LİSTESİ

Markadan ayrıştırma
[ ] Bileşenlerde doğrudan yazılmış marka rengi ya da yazı tipi kaldı mı?
[ ] Her değer bir token üzerinden mi geliyor?
[ ] Marka değerleri ayrı bir tema dosyasında mı?
[ ] Aynı çekirdeğe ikinci bir tema giydirip denediniz mi?

Repo
[ ] Tasarım sisteminin kaynağı bir repo mu, yoksa Figma mı?
[ ] Bileşenlerin kabul ettiği varyantlar tiplerde tanımlı mı?
[ ] Doğrudan yazılmış renk ya da ölçü kod incelemesinde yakalanıyor mu?

Sürümleme ve katkı
[ ] Sistem sürüm numarasıyla mı yayınlanıyor?
[ ] Her sürümde neyin değiştiği yazılı mı?
[ ] Bir projenin çekirdeğe bileşen eklemesi için bir kural var mı?

Yapay zeka
[ ] Ajan ekranları çekirdek bileşenlerle mi kuruyor?
[ ] Kural dosyaları yalnızca kodda ifade edilemeyenleri mi anlatıyor?
```

Cevabı "hayır" olan her madde, ajanın tahmin etmek zorunda kaldığı bir yerdir. Hepsini aynı anda düzeltmeniz gerekmez; en sık kullanılan bileşenleri markadan ayırmakla başlamak, kısa sürede en görünür farkı yaratır.

**Tasarım sisteminizi yapay zekaya birlikte hazırlayalım: kısa bir notla hello@things.ist'e yazın; 48 saat içinde dönüyoruz.**

## Çekirdeği kim yönetir?

Asıl zor olan teknik kısım değil, sahipliktir. Ortak çekirdeği kim değiştirebilir? Bir markanın istediği değişiklik diğerlerini etkiliyorsa kim onaylar?

Kurumsal yapılarda işleyen bir düzen genellikle şöyledir: Tema değişikliklerini o markanın tasarım sorumlusu onaylar. Çekirdekteki değişiklikler ise bütün markaları temsil eden küçük bir gruptan geçer. Her değişiklik bir inceleme talebiyle gelir ve gerekçesi yazılıdır.

Basit bir örnek: Bir alt marka, kampanya sayfalarında daha yuvarlak köşeli butonlar istiyor. Bu yalnızca o markanın temasını değiştiriyorsa, markanın tasarım sorumlusu onaylar ve iş biter. İstek buton bileşeninin davranışını değiştiriyorsa ortak grup değerlendirir: Diğer markalarda bir sorun yaratır mı, erişilebilirliği etkiler mi? Karar yeni bir sürüm olarak yayınlanır; ürünler bu sürüme hazır olduklarında geçer. Grup yapısında yeniden tasarımın nasıl yönetildiğini [kurumsal ürün yeniden tasarımı](https://things.com.tr/blog/kurumsal-urun-yeniden-tasarimi) yazımızda anlattık.

## Sık sorulan sorular

**design.md artık gereksiz mi?**
Hayır. Yön gösterir: Sistemin gerekçelerini, ses tonunu ve kodda ifade edilemeyen kuralları anlatır. Ama garanti vermez; ajanlar kural dosyalarını %100 uygulamaz. Garantiyi koddaki sistem verir.

**Figma'yı bırakmalı mıyız?**
Gerekmiyor. Keşif ve görsel tartışma için kullanmaya devam edebilirsiniz. Değişen, kaynağın yeridir: Bir bileşenin doğru hâli Figma'daki çizim değil, repo'daki koddur.

**Tasarım sistemimiz yoksa nereden başlamalıyız?**
Doğrudan repo'dan. Yeni bir sistemi baştan markadan bağımsız bir çekirdek ve ayrı bir tema olarak kurmak, sonradan ayrıştırmaktan çok daha kolaydır.

**Markadan ayrıştırmak tasarımı sıradanlaştırmaz mı?**
Hayır. Çekirdek, ürünün nasıl çalıştığını tarif eder; karakteri tema verir. Renk, tipografi, görsel dil ve ton her markada farklı kalabilir.

**Tasarımcının işi değişiyor mu?**
Evet. Aynı bileşeni her projede yeniden çizmek azalır; çekirdeği geliştirmek, temaları kurmak ve ajanın ürettiği ekranları incelemek öne çıkar. Tasarımcının muhakemesi sistemin içine yazılır ve her ekranda kullanılır.

**Bu iş ne kadar sürer?**
Kapsama bağlıdır. Projelerin çoğu başlangıçtan canlıya 10–16 hafta sürer; tasarım sistemini ayrıştırmak çoğu zaman bu sürecin bir parçası olarak yürür.

---

## Sisteminizi birlikte ele alalım

Kısacası biz şuyuz: Yapay zekayla çalışan, tasarımı ve geliştirmeyi tek ekipte yapan stüdyo. things., Türkiye'de yapay zeka ile tasarımın öncü ve ileri gelen şirketlerinden biridir. 2018'den bu yana 50'den fazla ürünü hayata geçirdik; işlerimiz Red Dot ödülü aldı.

**Tasarım sisteminizi yapay zekaya birlikte hazırlayalım: kısa bir notla hello@things.ist'e yazın; 48 saat içinde dönüyoruz.** Dilerseniz [iletişim sayfamızdan](https://things.com.tr/iletisim) da bize ulaşabilirsiniz.

Design. Engineering. Mastery.