Stil Kılavuzları, Tasarım Sistemleri ve Bileşen Kütüphaneleri Hakkında Bildiğim Her Şey

9 min readAug 27, 2022

Bu yazı Lee Robinson tarafından yazılan Everything I Know About Style Guides, Design Systems, and Component Libraries adlı makalenin Türkçe çevirisini içermektedir. Bu bağlantı aracılığıyla yazarın diğer makalelerini inceleyebilirsiniz.

Geçen yılın büyük bir kısmında, front-end teknolojileri ve tasarım üzerine çok fazla araştırma yaptım. İş yerimdeki yeni rolüme başladığımda, yeni bir bileşen kütüphanesi ihtiyacı olduğunu fark ettim ve bir tane oluşturmaya karar verdim. O zamandan bu yana, stil kılavuzları, tasarım sistemleri, bileşen kütüphaneleri ve bunların nasıl best practice olarak geliştirilebileceği konusunda çok fazla şey öğrendim. Bu yazı, geçen yıl öğrendiğim her şeye derinlemesine bir dalış olacak.

Neden Umursamalısın?

Her web sitesi basit başlar. Belki birkaç belirgin parçadan oluşan, mütevazi amaçları olan bir sayfadır.

Sonrasında, yavaşça ölçeklenmeye başlar.

Daha fazla sayfa ve yeni özellikler eklenmeye başlanır. Sitenin belirli bölümlerine ayrılmış birden fazla ekip bile olabilir. Mobil geliştirme de yapılıyor olunabilir.

Sitenin bir bölümünde kullanılan butonların geri kalan yerlerdeki butonlardan biraz daha farklı olduğunu fark etmeye başlarsınız. Bir takımın geliştirmeye karar verdiği bir özelliği, başka bir takım (farkında olmadan) çoktan tamamlamıştır. İletişim kopuklukları olur. Tutarlılık kaybolmuştur.

Bu önlenebilir bir sorun mu? Kesinlikle. Yine de, neden tekrar tekrar bu yaşanmaya devam eder? Tasarım ve geliştirme sürecinizi önceden düşümedikçe, projeniz ölçeklendikçe bu tarz sorunlarla karşılaşmaya başlayacaksınız.

Bu sorunların gerçekleşmesini önlemek veya ürünlerinizdeki mevcut tutarlılık eksikliğini düzeltmek için üç şeye ihtiyacınız var:

Stil Kılavızu (Style Guide)
Bileşen Kütüphanesi (Component Library)
Tasarım Sistemi (Design System)

Bahsettiğim şeylerin ne anlama geldiği hakkında bir fikriniz yoksa merak etmeyin. Bu yazının sonunda, neredeyse bir yıllık sürede edindiğim deneme ve hata, araştırma ve geliştirme sürecini tüketmiş olacaksınız.

Stil Kılavuzu Nedir?

Bir stil kılavuzu, markanızın nasıl görüntülenmesi gerektiğini dair bir dizi kuraldır. Bu hem görsel (tasarım ve imge) hem de yazılı (ses ve ton) içerikleri kapsamaktadır.

Bir stil kılavuzunun amacı, birden fazla kişinin çalıştığı projelerde bir stabilizasyon yakalayarak ortaya temiz bir ürün çıkarmaktır. Neredeyse bütün büyük markaların bir stil kılavuzu vardır, ancak bazıları halka açık değildir.

Bileşen Kütüphanesi Nedir?

Bir bileşen kütüphanesi, kullandığınız stil kılavuzunun uygulamaya konmuş halidir. Geliştiricilerin, markanızı yansıtan uygulamalar oluşturmak için tüketebilecekleri, paylaşılan bir UI bileşeni kümesidir.

Bazı önemli avantajları:

Bir bileşen kütüphanesine sahip olmak, tüketiciler için daha az “özel” (custom) kod yazmak anlamına gelmektedir.
Üretilen bileşenlerin merkezi bir lokasyondan çıkması sebebiyle bütün bileşenlerin erişilebilirlik gereksinimlerini karşılamasını sağlayabilirsiniz.
Birden fazla kişinin geliştirme yapması sebebiyle hata düzeltmeleri (bug-fix) ve iyileştirmeler olması ve bu sayede daha kararlı ve sağlam bir ortamda çalışabilmek.
Kodun daha az tekrarlanması yeni ürünleri daha hızlı göndermenizi ve eski kodu (legacy code) daha hızlı yeniden yazmanızı sağlar.

Tasarım Sistemi Nedir?

Bir tasarım sistemi, belirli standartlara erişmeye çalışan, bir takım kuralların ve prensiplerin bütünüdür. Bu durum, stil kılavuzu ve bileşen kütüphanesi arasındaki evlilik olarak adlandırılabilir. En bilinen tasarım sistemlerinden birisi Google tarafından geliştirilen Material Design adlı kütüphanedir.

Bir tasarım sisteminin içermesi gerekenler:

İçerik (Content) — Düşünülerek geliştirilmiş ürün deneyimleri tasarlayabilecek bir tasarım dili.
Tasarım (Design) — Tasarım sisteminin içerdiği görsel öğeler.
Bileşenler (Components) — Yeni ürünler ve özellikler geliştirmek için kullanılan yapı taşları.
Desenler (Patterns) — Anlamlı bir ürün deneyimi yaratmak için kullanılan özgün parçalar.

Nereden Başlamalısınız?

Geliştirdiğiniz ürünün durumuna bağlı olarak, farklı başlangıç noktalarına sahip olabilirsiniz. Ayrıntıya girmeden önce belirleyeceğimiz ana hatlar bu şekilde olmalı:

Hâlihazırda var olan tasarım sistemlerinin bir envanterini çıkarın.
Tasarım kuralları oluşturup bir stil kılavızu oluşturun.
Tasarımda kullanacağınız öğeleri tanımlayın.
Bir ikon paketi oluşturun veya tanımlayın.
Uygun dil ve kütüphaneleri seçin.
Monorepo ve single package arasında bir seçim yapın.
CSS/Sass ve CSS-in-JS arasında bir seçim yapın.
Bir bileşen kütüphanesi oluşturun.
Dokümantasyon oluşturacağınız platformunu seçin.
Tasarım sistemi için bir dokümantasyon hazırlayın.

Tasarım Sistemini Oluşturmak

Sahip olduğunuz tasarım sisteminin bir envanterini oluşturun.

Eğer sıfırdan başlamıyorsanız, arayüzünüzde kullanılan bütün tasarım desenlerini tanımlamalı ve tutarsızlıkları belgelemeniz gerekecektir. Kullanıcı ürününü kullandığı süre boyunca, uygulamanın herhangi bir bölümünde mutlak olarak aynı kullanıcı deneyimini yaşamalıdır.

Takımınız ve sizin tercih ettiğiniz etkileşim desenlerini oluşturmaya ve gözden geçirmeye başlayın. Bu, stil kılavuzunuzun ne ihtiyacı olduğu konusunda size bir fikir sağlayacaktır.

Tasarım ilkeleri oluşturun ve bir stil kılavuzu oluşturmaya başlayın.

Edindiğiniz bulguları bir stil kılavuzuna dönüştürmeye başlamak için bu araçları kullanabilirsiniz:

Benim önerim bu araçların arasından Figma olurdu, fakat bu size, takımınıza ve firmanıza göre değişebilir. Bu bağlantı aracılığıyla Figma ile ilgili bilgi edinebilirsiniz.

Tasarımda kullanacağınız öğeleri tanımlayın.

Tasarım öğeleri, tasarım sistemlerinde kullanılan görsel öğelerin en küçük birimleridir ve isimlerini sahip oldukları görsel nitelikten alırlar. UI geliştirme için ölçeklenebilir ve tutarlı bir görsel sistem oluşturmak için bu değerleri sabit ve elle kodlayarak kullanmak yerine (hex kodları ya da boyut için verilmiş piksel değerleri) isimlendirerek kullanıyoruz.

Bu durum aşağıdaki örnekleri kapsıyor:

Renkler (metin (text), arka planlar (backgrounds), kenarlıklar (borders)
Fontlar
Tipografi boyutları
Boşluk değerleri
Gölgeler

Örnek olarak, Vercel’s Design System’in tasarım sistemine bakabilirsiniz.

--geist-foreground: #000;
--geist-background: #fff;
--accents-1: #fafafa;
--accents-2: #eaeaea;
--accents-3: #999999;
--accents-4: #888888;
--accents-5: #666666;
--accents-6: #444444;
--accents-7: #333333;
--accents-8: #111111;
--geist-success: #0070f3;
--geist-error: #ee0000;
--geist-warning: #f5a623;
--dropdown-box-shadow: 0 4px 4px 0 rgba(0, 0, 0, 0.02);
--dropdown-triangle-stroke: #fff;
--scroller-start: var(--geist-background);
--scroller-end: rgba(255, 255, 255, 0);
--shadow-small: 0 5px 10px rgba(0, 0, 0, 0.12);
--shadow-medium: 0 8px 30px rgba(0, 0, 0, 0.12);
--shadow-large: 0 30px 60px rgba(0, 0, 0, 0.12);
--portal-opacity: 0.25;

Yukarıdaki örneği tasarımcılar ve geliştiriciler arasında kullanılan ortak bir dil olarak görebiliriz.

Bir ikon seti oluşturun veya tanımlayın.

Eğer elinizde hali hazırda bir ikon seti varsa, ihtiyacınız olan bu ikonlardan hangilerini elinizde tutacağınıza karar vermektir. Şirketinizin boyutuna ve önceliklerine göre kendi ikon setinizi oluşturmak mantıklı olmayabilir. Bu noktada açık kaynak olarak geliştirilen bir ikon kütüphanesi kullanmak daha iyi olacaktır.

Eğer kendi ikon setinizi oluşturacak veya açık kaynak olarak geliştirilen bir seti kullanacaksanız, tüketim kalıplarınızı tanımlayıp, bunu bir standart haline getirmelisiniz. Oluşturduğunuz ikon setinin son kullanıcısı kim olacak? Tasarımcılar, geliştiriciler ya da pazarlama ekibi?

SVG’leri kullanarak, ikon kütüphanenizi oluşturmak için bu yolu izleyebilirsiniz:

Tasarımcılar ham SVG’ler oluşturur veya sağlar.
SVGO kullanarak SVG’ler optimize edilir ve sıkıştırılır.
SVGR kullanarak, geliştiriciler için otomatik olarak React bileşenleri oluşturulur.
JPEG ve PNG dosyalarının farklı boyut ve çözünürlükte versiyonları oluşturulur.
SVG dosyaları derlenerek mobil kullanım için font dosyaları haline getirilir.

Güncel diller/kütüphaneler seçin.

Hangi diller veya kütüphaneler güncel olarak geliştirilmeye devam ediliyor? Projenizin mimarisini düzgün bir şekilde oluşturabilmek için bunu önceden düşünmek önemli.

Eğer uygulamanızda script tag'leri yerine ES Modules kullanılıyorsa, bileşen kütüphanenizi tek bir dağıtılabilir dosyaya paketleyecek şekilde yapılandırmanız gerekir. Örneğin, bir Vanilla JavaScript uygulamasının bir HTML dosyasında böyle bir şeye ihtiyacı olacaktır.

<script src="/js/component-library.min.js"></script>

Bunu gerçekleştirebilmek için Webpack ya da Rollup gibi araçlar kullanabilirsiniz. Ben Webpack kullanmanızı tavsiye ederim. Eğer TypeScript kullanacaksanız TSDX’e de bakmanızı tavsiye ederim.

Monorepo vs. tekil paketler arasında karar kılın.

Bir Monorepo, birden fazla kütüphaneyi tek bir repo üzerinden geliştirmenize ve yayınlamanıza olanak sağlar. Bu yöntem birçok gerçek problemi çözse de, başka problemler de yaratır. Sebep olduğu artı ve eksileri anlamak önemlidir.

Bu adımlar içn bir Monorepo kullanabilirsiniz…

Bir pakete dahil edilen bileşenlerin kapsamını azaltarak küçük dosya boyutlara sahip paketler elde etmek.
Tek bir repo üzerinden yönetilen paylaşımlı geliştirmeler, syntax yazım kuralları, test ve yayınlama süreçleri vs. kendini tekrarlayan kodlar içeren birden fazla repo’ya sahipseniz.
Semantik versiyonlama kullanılarak geliştirilen paketler için daha detaylı bir kontrol mekanizmasına ihtiyacınız varsa.

Bu adımlar içinse kullanmayabilirsiniz…

Altyapısal gereksinimler ve ek düzenlemeler.
Tüketicilerin tek bir bileşen kütüphanesi yerine çeşitli paketlerden içe aktarım yapmaları gerekmekteyse.
Güncel teknolojiler. Fakat en son çıkan teknolojileri kullanmak bazen daha önce görülmemiş veya henüz bir çözümü olmayan sorunlar ortaya çıkarabilir.

Bazı sorular, şirketiniz için hangi çözümün doğru olduğunu tanımlamaya konusunda yardımcı olacaktır.

NPM’de yayınlanmış olan birden fazla repo’nuz var mı?
Geliştirme, test ortamı ve syntax yazım kurallarını içeren komplex bir altyapınız mı var? Bu altyapı birçok farklı yerde kendini tekrarlıyor mu?
Kaç adet repo’nuz var? (Ya da önümüzdeki yıl kaç tane repo’ya sahip olmayı planlıyorsunuz?)
Takımınız ne kadar büyük? Bileşen kütüphanesi kaç kişi tarafından kullanılacak?
Açık kaynak olarak mı geliştireceksiniz? Problemleri çözmeleri için sektördeki diğer açık kaynak geliştirmecilerle birlikte çalışabilir misiniz?
Gelecekte birden fazla paket ile geliştirme yapma ihtiyacınız olacak mı? (örn. ikon paketleri, codemods, etc)

Küçük ölçekli şirketler için, Monorepo kullanmanın gereksiz olduğu fikrindeyim ve doğru yer ve zamanda kullanılması gerektiğini düşünüyorum. Daha önce, hem dahili hem de harici uygulamaları kapsayan ve 10 farklı paketi yönetmek için kullanılan bir projede (ortalama 150 geliştirici ile geliştirilen) monorepo kullanmıştım.

Not: Monorepo kullanmak mı istiyorsunuz? Bu yazıma göz atabilirsiniz.

CSS/Sass ve CSS-in-JS arasında karar kılın.

CSS-in-JS, stilleri paketleme ve NPM aracılığıyla dağıtmak için en kolay çözümdür. Optimal bir performans elde etmek için, düşük işleyiş süresi (near-zero runtime) kullanan paketler kullanmayı göz önünde bulundurabilirsiniz. Stitches buna güzel bir örnek.

Eğer bileşen kütüphaneniz için ham HTML ve CSS dosya çıktılarılarına ihtiyacınız varsa [Sass] (https://sass-lang.com/) kullanabilirsiniz. Buna güzel bir örnek IBM’in geliştirdiği Carbon Design System olabilir. Tasarım öğelerinizi kullanabilmek için CSS değişkenleri kullanabilirsiniz.

<button class="bx--btn bx--btn--primary" type="button">Button</button>

Eğer React kullanıyorsanız, React Uygulamamı Nasıl Stilize Etmeliyim? adlı yazımı inceleyebilirsiniz.

Bir bileşen kütüphanesi oluşturun.

Gerekli teknik gereksinimleri belirleyip, bir stil kılavuzu oluşturduğunuzda artık bir bileşen kütüphanesi inşa etmeye başlayabilirsiniz. Benim tavsiyem React ile Storybook kullanmanız yönünde olacaktır.

Bileşen kütüphanesi oluşturmak stil kılavuzunu koda dökmekten çok daha fazlasıdır.

Kullanıcıların bileşenler ile nasıl etkileşime geçeceğini düşünmelisiniz. Ne tür bir API kullanmak isterlerdi? Nasıl daha temiz ve kendi kendini açıklayabilen bir sistem oluşturulabilir? Örnek olarak butonları ele alalım. birincil, ikincil vb. gibi farklı buton varyasyonlarına sahipsiniz.

Bunları farklı bileşenler olarak mı tasarlardınız?

<PrimaryButton>Hello World!</PrimaryButton>
<SecondaryButton>Hello World!</SecondaryButton>

ya da bir prop aracılığıyla mi ayrıştırmayı tercih ederdiniz?

<Button>Hello World!</Button>
<Button variant="secondary">Hello World!</Button>

İkincil olarak, bu prop’u nasıl isimlendirirdiniz?? variant? type?

<button> elemanı için type elementinin rezerve edilmiş bir öznitelik (attribute) olduğunu göz önünde bulundurur muydunuz? Bileşen kütüphanenizi oluştururken bu ve bunun gibi kararlar vermeniz gerekebilir.

Göz önünde bulundurmak isteyebileceğiniz bazı diğer noktalar:

Kullanıcıların CSS özelliklerini React bileşenlerine props olarak mı göndermesine izin verirdiniz, yoksa istenen stilleri elde etmek için bileşenleri genişletmeleri/sarmaları mı gerekirdi? Cevap ilk seçenekse, styled-system’a göz atabilirsiniz.
Yükleme durumunu (loading state) direkt olarak bileşenler içerisinde mi geliştirirdiniz, yoksa bunun için bir jenerik bileşen mi kullanırdınız? (spinner, skeleton?)
Görsel bileşenleri nasıl test ederdiniz? Snapshot testing? Visual diff testing?
Tüketiciler bileşen kütüphanenizi hangi şekilde entegre edecekler? Bir stil sıfırlama (global style reset) aracı kullanılacak mı? Herhangi bir Babel plugini eklemeleri gerekecek mi?
Conventional Commits’dan yararlanarak otomatik bir şekilde changelog oluşturulacak mı?
Bileşenler mobil ve web arayüzlerini destekleyecek mi? Kodunuzu platformlar arasında paylaşımlı hale getirmek için React Native Web kullanmayı düşünebilirsiniz.

Bir dokümantasyon platformu belirleyin.

Dizayn sisteminizi bir platforma dönüştürmelisiniz. Bunu ilk kez yapacaksanız Storybook Docs kullanmanızı tavsiye ederim.

Bu kombinasyon ile Docz, Styleguidist ve Docusaurus gibi platformlardan edineceğiniz çıktının aynısını elde edebilirsiniz.

Bileşen örneklerinden kod parçalarını kolay bir şekilde kopyalayabilmek.
defaultProps ve prop-types’ı baz alarak otomatik olarak bir prop tablosu oluşturabilmek.
Bileşenin tüm permütasyonlarını kolayca görebilmek.
MDX kullanarak dokümantasyon yazabilmek.

Tasarım sisteminizin markanızla eşleşmesi ve bileşen kütüphanenizi beslemesi konusunda ısrar ediyorsanız, [MDX] (https://mdxjs.com/) teknolojisini kullanmanızı öneririm. Bu şekilde React bileşenlerini Markdown dosyaları içerisine gömebilirsiniz. Şu anda okuduğunuz blog’un yayınlandığı web sayfası bu şekilde geliştirilmektedir.

Gerçekten özelleştirilmiş çözümler kullandığınızda, dokümantasyonlarınız üzerinde daha fazla kontrol sahibi olabilirsiniz. Atomize React bu konuda göze çarpan örneklerden birisidir.

Tasarım Sistemi için dokümantasyon yazın.

Dokümantasyonunuzu yazacağınız platformu seçtikten sonra, sıra onu yazmaya geldi. Bu maddeleri ekleyebilirsiniz:

Bileşen kütüphanesinin nasıl kurulacağını anlatan bir rehber.
Tüm bileşenlerin prop şeması ve type bilgileri.
Bileşenlerin kopyalanabilir kod snippet’leri içeren örnekleri.
Kullanılan teknolojiler ve uygulamada kullanılan genel mantığın anlatılması.

Bunları eklemeyi de göz önünde bulundurabilirsiniz:

“Getting Started” (Buradan Başlayın) bölümü içeren bir öğretici. (tutorial)
Aralarından seçim yapabileceğiniz kullanıcı arayüzü şablonları.
Tema hakkında bilgi.
Bileşenler ile etkileşime girebileceğiniz bir canlı kod yazma ortamı.

Sonuç

Geçtiğimiz yıl boyunca tasarım sistemleri hakkında düşünerek çok zaman geçirdim. Sıfırdan bir bileşen kütüphanesi oluştururken geçirdiğim zaman, front-end ve tasarım geliştirme süreçlerine olan bakış açımı bir hayli değiştirdi. Aşağıda bu süreç boyunca bana ilham veren bazı tasarım sistemlerini bulabilirsiniz.