Tasarım sistemi ile site mimarisi çoğu organizasyonda ayrı ekiplerin, ayrı araçlarla yönettiği iki bağımsız katman olarak var olur. Tasarım ekibi bileşen kütüphanesini yönetir; içerik veya ürün ekibi sayfaların nasıl organize edileceğine karar verir. İkisi arasında resmi bir bağlantı kurulmadığı sürece her iki taraf kendi dilinde konuşur, kendi kararlarını bağımsız verir. Bir süre sonra bileşenler sayfa gereksinimlerine uymaz; sayfalar bileşenlerin kısıtlarını gözetmeden tasarlanır ve her yeni özellik bu çatlağı biraz daha büyütür.
Bu kopukluk küçük projelerde görünmez kalır. Tek bir geliştirici hem mimariyi hem de UI bileşenlerini yönetiyorsa zaten içgüdüsel olarak ikisini hizalar. Ekip büyüdükçe ve sorumluluklar ayrıştıkça bu içgüdüsel hizalama kaybolur; çünkü artık iki farklı kişi iki farklı perspektiften çalışmaktadır ve aralarında ortak bir referans noktası yoktur.
Tasarım sistemi ile site mimarisini birbirine bağlamak bir araç seçimi sorunu değildir. Hangi Figma kütüphanesinin veya hangi bileşen sisteminin kullanıldığından önce, iki disiplinin ortak kavramlarla konuşması ve kararlarının birbirini etkilediğini kabul etmesi gerekir. Bu kabulün pratikte ne anlama geldiği, hangi yapısal bağlantı noktalarının kurulması gerektiği ve bu hizalamanın nasıl sürdürüleceği, bu yazının konusudur.
Konuya sayfa tiplerinden girmek doğru bir başlangıç noktasıdır. Sayfa tipi hem mimari hem de tasarım sistemi için ortak bir dil unsuru olabilir; bu hizalamanın neden işe yaradığını ve nasıl kurulduğunu anlamak için iyi bir giriş noktasıdır.
Sayfa tipi, tasarım sistemi ile mimarinin buluştuğu ortak zemini oluşturur
Site mimarisinde sayfa tipi, belirli bir işlevi olan, tekrarlanan yapısal kalıbı ifade eder. Ürün sayfası, kategori sayfası, makale sayfası, landing page — her biri farklı içerik modelini, farklı navigasyon davranışını ve farklı bileşen setini gerektirir. Tasarım sisteminde ise sayfa düzeyinde şablonlar veya template'ler bu işlevi üstlenir; belirli bileşenlerin belirli bir düzende bir araya geldiği yapısal çerçeveler.
İki tarafın "sayfa tipi" kavramını aynı biçimde tanımlaması, ortak dilin ilk adımıdır. Mimari dokümanda "ürün sayfası" denen şey, tasarım sisteminde "PDP template" olarak adlandırılıyorsa, her yeni geliştirme tartışmasında iki ad arasında çeviri yapılır. Bu çeviri küçük bir sürtünme gibi görünür; ama on iki sayfa tipi ve yirmi kişilik bir ekipte bu sürtünme her toplantıya, her PR açıklamasına ve her tasarım revizyonuna işler.
Ortak terminoloji yerleştiğinde iki taraf arasındaki bağlantı otomatik olarak güçlenir. "Kategori sayfasına yeni bir filtre bileşeni ekliyoruz" cümlesi artık her iki tarafın aynı sayfayı kastettiğini garantiler. Kategori sayfasının yapısal gereksinimleri bileşen kararlarını doğrudan şekillendirir; filtre bileşeni kaç seçeneği gösterebilir, açılır panel mi kullanılacak sidebar mı — bu kararlar sayfanın mimarisinden bağımsız değildir.
Bileşen kararları sayfa mimarisini sessizce kısıtlar
Bir bileşen tasarımı görünürde yalnızca görsel bir karardır. Ama bileşenin API'si — hangi prop'ları kabul ettiği, hangi varyantları desteklediği, ne kadar içerik taşıyabileceği — sayfanın mimarisini fiilen sınırlar. Hero bileşeni yalnızca tek bir CTA düğmesini destekliyorsa, landing page'in iki farklı aksiyonu olan bir versiyonunu tasarlamak ya bileşeni kırmayı ya da yeni bir bileşen eklemeyi gerektirir. Her iki durumda da mimari bir karar, bileşen seviyesinde verilmiş bir kararla çatışır.
Bu çatışmanın önüne geçmek için bileşen kararları sayfa gereksinimlerinden beslenmeli; sayfa gereksinimleri ise bileşen kısıtlarını gözetmelidir. Bu iki yönlü bilgi akışı, iki ekibin düzenli iletişimini zorunlu kılar. Landing page yapısal gereksinimleri bileşen kütüphanesine girdi vermeli; bileşen kütüphanesi de yeni bir sayfa tipi tasarlanmadan önce danışılan bir referans olmalıdır.
Pratikte bu iletişim çoğunlukla geriye doğru akar: bileşen önce tasarlanır, sonra sayfada kullanılmaya çalışılır ve kısıtlamalarla karşılaşılır. Doğru akış bunun tersidir: sayfa tipinin hangi içerik kombinasyonlarına ihtiyaç duyduğu önce netleştirilir, ardından bu gereksinimlere yanıt verecek bileşen tasarlanır. Sıranın bu şekilde kurulması hem yeniden çalışmayı azaltır hem de bileşen kütüphanesinin gerçek kullanım senaryolarına dayanmasını sağlar.
Navigasyon bileşenleri mimari kararların en doğrudan yansımasıdır
Tasarım sistemindeki hiçbir bileşen, navigasyon bileşenleri kadar doğrudan mimari kararlarla bağlantılı değildir. Header navigasyonu kaç öğeyi barındırabileceğini belirler; bu karar menüde kaç öğe olacağını doğrudan sınırlar. Mobil navigasyon bileşeninin yapısı, hangi hiyerarşi derinliğinin destekleneceğini belirler. Breadcrumb bileşeni kaç katmanı gösterebileceğini kısıtlar; bu da URL derinliğine dolaylı bir sınır koyar.
Bu bağımlılık ters yönde de çalışır. Mimari siteye iki düzey derinlikte bir kategori hiyerarşisi öngörüyorsa, navigasyon bileşeninin bu iki düzeyi destekleyecek biçimde tasarlanması gerekir. Bileşen yalnızca tek düzey destekliyorsa mimari ya değişmek zorunda kalır ya da bileşen güncellenmek. Bu kararı önceden netleştirmek yerine uygulama aşamasında keşfetmek, her iki tarafı da yavaşlatır.
Mega menü gibi karmaşık navigasyon bileşenlerinde bu bağımlılık daha da belirginleşir. Mega menünün kaç sütun göstereceği, her sütunda kaç bağlantı yer alacağı, görsel öğe taşıyıp taşımayacağı — bunların tamamı hem tasarım hem de mimari karar gerektiren noktalardır. Bu noktaların ikisi bir arada düşünülmeden alınan her karar, diğer tarafta bir kısıtlamaya dönüşür.
İçerik modeli bileşen yapısını şekillendirir
Site mimarisi bağlamında içerik modeli, bir sayfanın hangi içerik alanlarını barındıracağını tanımlar. Başlık, özet, kapak görseli, yazar, tarih, kategori, etiketler — bunların her biri hem veri modeli hem de görsel temsil gerektirir. Tasarım sistemindeki bileşenler bu alanları görsel olarak karşılayan yapılardır.
İçerik modeli değiştiğinde bileşenler de değişmek zorunda kalır. Bir blog yazısına "okuma süresi" alanı eklendiğinde, makale kartı bileşeninin bu bilgiyi nereye yerleştireceğini bilmesi gerekir. Bu bilgi yoksa bileşen ya alanı yok sayar ya da tutarsız biçimlerde gösterir. Bilgi mimarisi perspektifinden bakıldığında, içerik modelinin bileşen tasarımının girdisi olması gerekir; çıktısı değil. Önce hangi bilginin gösterileceği, sonra nasıl gösterileceği belirlenir.
Bu sıra ters işlendiğinde — önce bileşen tasarlanır, sonra ne gösterileceği kararlaştırılır — bileşen gerçek içerik gereksinimleriyle uyumsuz hale gelir. Kısa başlıklar için tasarlanmış bir kart bileşeni, uzun başlıklarla kırılır. İki satır özet için tasarlanmış alan, beş satırlık özetleri keser. Her sapma kullanıcı deneyimini zedeler ve bu sorunların büyük çoğunluğu, içerik modeliyle bileşen tasarımının eş zamanlı geliştirilmesiyle önlenebilirdi.
Tasarım tokeni hiyerarşisi mimari kararlarla örtüşmelidir
Modern tasarım sistemleri token hiyerarşisi üzerine kuruludur: global tokenler renk, tipografi ve boşluk değerlerini tanımlar; semantic tokenler bu değerleri anlamsal bağlamlara bağlar; bileşen tokenler ise belirli bileşenlerin özelliklerini kontrol eder. Bu hiyerarşi, görsel tutarlılığı merkezden yönetmeyi mümkün kılar.
Mimari açıdan ilginç olan, bu token hiyerarşisinin sayfa tipi farklılıklarını yansıtıp yansıtmadığıdır. Landing page başlığı ile blog makale başlığı tipografik olarak farklı olabilir; bu fark semantic token düzeyinde tanımlanabilir. Kategori sayfası arka planı ile ürün sayfası arka planı renk tokenı düzeyinde ayrıştırılabilir. Token hiyerarşisinin sayfa tipi mantığıyla hizalanması, sayfa bazlı görsel varyasyonları merkezi sistemden yönetmeyi kolaylaştırır.
Sayfa düzeni ve grid sistemi bu hizalamanın en somut örneğidir. Grid bileşeni kaç sütunlu olacak, sütun aralıkları ne kadar, kenar boşlukları hangi breakpoint'te nasıl değişecek — bu kararlar hem layout token'larında hem de sayfa tipinin mimari gereksinimlerinde birlikte yaşamalıdır. Birisi değiştiğinde diğerinin güncellenmesi gerektiği açık olmalıdır; bu güncellemelerin hangi süreçle yapılacağı önceden tanımlanmış olmalıdır.
Bileşen envanteri ile sayfa haritası birlikte tutulmalıdır
Tasarım sisteminin olgunlaştığını gösteren işaretlerden biri, hangi bileşenin hangi sayfa tipinde kullanıldığının dokümante edilmiş olmasıdır. Bu envanter, "bu bileşeni değiştirirsek hangi sayfalar etkilenir?" sorusuna hızlı yanıt vermeyi sağlar. Böyle bir envanter yoksa, her bileşen değişikliği tüm sayfaların tek tek kontrol edilmesini gerektirir; bu hem yavaş hem de hata yapma ihtimali yüksek bir süreçtir.
Site haritası planlaması bu envanterin diğer yüzüdür: hangi sayfanın hangi bileşen setini kullandığı. İki liste — bileşen envanteri ve sayfa haritası — birlikte tutulduğunda bağımlılıklar görünür hale gelir. Yeni bir sayfa tipi eklendiğinde hangi bileşenlere ihtiyaç duyulduğu sorusu, tasarım sistemine danışılarak yanıtlanabilir. Mevcut bileşenlerden hangisi doğrudan kullanılabilir, hangisi uyarlanmalı, hangisi sıfırdan oluşturulmalı — bu karar açık bir envanterle çok daha hızlı alınır.
Envanteri canlı tutmak disiplin gerektirir. Her yeni sayfa eklenmesinde veya her bileşen güncellemesinde envanterin güncellenmesi, ek bir adım olarak görülür ve atlanır. Bu atlamayı önlemenin en etkili yolu, envanter güncellemesini geliştirme sürecinin bir parçası yapmaktır: bileşen PR'ı açılmadan önce hangi sayfa tiplerini etkilediği belirtilmiş olmalı; yeni sayfa tipi deploy edilmeden önce hangi bileşenleri kullandığı dokümante edilmiş olmalıdır.
Sistemlerin birbirinden kopması zaman içinde kaçınılmaz hale gelir; yeniden bağlama mekanizması gerekir
İki sistem ne kadar iyi hizalanırsa hizalansın, zaman içinde birbirinden uzaklaşır. Tasarım sistemi bir yönde evrilir; site mimarisi başka bir yönde. Yeni bir sayfa tipi bileşen sistemini güncellemeden eklenir; bir bileşen varyantı sayfa gereksinimlerinden habersiz biçimde kaldırılır. Bu kayma kaçınılmazdır; sorun kaymanın kendisi değil, kaymanın fark edilmeme biçimidir.
Yeniden bağlama mekanizması, bu kaymayı periyodik olarak tespit eden ve düzelten bir süreçtir. Üç ila altı ayda bir yapılan bir uyumluluk denetimi şunları karşılaştırır: tasarım sistemindeki aktif bileşenler ile sayfaların gerçekte kullandığı bileşenler; sayfa tiplerinin içerik model gereksinimleri ile bileşenlerin desteklediği içerik alanları; navigasyon bileşenlerinin kısıtları ile mimarinin öngördüğü hiyerarşi derinliği.
Bu denetimin yapılması için her iki tarafın ortak bir toplantıda buluşması yeterlidir. Tasarım sistemi ekibi son üç ayda ne değiştirdi; mimari ekibi son üç ayda ne ekledi — bu iki listeyi karşılaştırmak, kopmaları erken aşamada görmek için yeterlidir. Kopma küçükken düzeltmek büyük bir mühendislik çalışması gerektirmez; büyüdükten sonra düzeltmek ise çoğunlukla yeniden tasarım anlamına gelir.
Tasarım sistemi ile site mimarisi arasındaki bağ, kurulduktan sonra kendiliğinden korunmaz. Ortak terminoloji, paylaşılan envanter, bileşen kararlarında mimari girdisi ve periyodik uyumluluk denetimi — bunların her biri bu bağı canlı tutan yapısal kararlardır. Bu kararlar alınmadan sürdürülen iki bağımsız sistem, zamanla birbirine yabancılaşır ve her yabancılaşma adımı geliştirme maliyetine eklenir.
İki disiplini birleştiren bir mimari dil kurmak, her ikisini de daha öngörülür ve sürdürülebilir kılar. Bileşen tasarımcısının sayfa mimarisini bilmesi, mimar'ın bileşen kısıtlarını gözetmesi — bu karşılıklı farkındalık, ayrı araçlarla çalışan iki ekibin aynı yönde ilerlemesini sağlar.