Marka & Deneyim

Marka kimliğini Figma'da yaşayan bir token sistemine, ürün ekibinin kullandığı bir komponent kütüphanesine ve uzun ömürlü bir dokümantasyona çeviriyoruz.

Bu neden önemli

Bir ürün küçükken tutarlılık ücretsizdir. Tek tasarımcı, tek geliştirici; aynı butonu herkes aklında aynı tutar. Ama ekip büyüdükçe bu sessiz anlaşma çöker. Her yeni sayfa biraz farklı bir gri, biraz farklı bir köşe yarıçapı, biraz farklı bir boşluk getirir. Tek tek bakıldığında hiçbiri yanlış değildir; bir araya geldiklerinde ürün dağınık görünür.

Asıl maliyet görsel değil, hızdır. Tasarım kararları her sprint yeniden alınıyorsa, ekip aynı problemi defalarca çözer. Tasarımcı aynı kartı dördüncü kez çizer, geliştirici beşinci kez kodlar, ürün yöneticisi “neden iki sayfa farklı görünüyor?” sorusuna takılır. Her görev tek başına küçüktür; bu yüzden de bedeli fark edilmez. Sektör araştırmaları, ürün ekiplerinin önemli bir zaman diliminin zaten çözülmüş kararları tekrar tartışmaya gittiğini ortaya koyuyor.

Eylemsizliğin bedeli birikimlidir ve faturası gecikmeli gelir. Tutarsız arayüz erişilebilirlik açıkları üretir, QA süresini uzatır, yeni geliştiricinin işe alışma süresini büyütür ve marka algısını zayıflatır. Aynı işi iki kez yapmak bütçeyi sessizce tüketir. Çeyrekte dört özellik çıkaran bir ekibi düşünün: her özellik, kod tabanının bir yerinde zaten var olan bir tarih seçiciyi, bir tabloyu ve bir form alanı setini yeniden kuruyorsa, aynı üç komponenti yılda on altı kez ödüyorsunuz demektir. Bu yeniden yapımların hiçbiri bir bütçe kalemi olarak görünmez; israfın hayatta kalmasının nedeni de tam budur.

Design system bu dağılmayı tersine çevirir: kararları bir kez verir, her yerde uygular. Buton bir kez tasarlanır, yüz ekranda aynı davranır. Yeni geliştirici ilk ayında değil ilk haftasında üretmeye başlar, çünkü yapı taşları zaten isimlendirilmiş, dokümante edilmiş ve güvenilirdir. beynart için design system bir Figma dosyası değil; üretim koduna bağlı, versiyonlanmış, dokümante edilmiş bir altyapıdır.

Ne teslim ediyoruz

Design system bir dosya teslimi değil, yaşayan bir altyapıdır. Dört katmanda çalışır ve her katman bir öncekinin üzerine kurulur. Her birini ayrı ayrı değil, birlikte teslim ederiz; çünkü token’sız komponent, dokümantasyonsuz token, yönetişimsiz dokümantasyon altı ayda dağılır. Bu katmanların hepsi tek bir amaca hizmet eder: bir tasarım kararının yalnızca bir kez verilmesi ve sonra her yüzeyde otomatik olarak yaşaması. Renk tonunu değiştirdiğinizde web, mobil ve e-posta aynı anda güncellenir; bir butonu erişilebilir kıldığınızda yüz ekran birden erişilebilir olur. İşin bileşik kazancı buradadır.

• Token katmanı. Renk, tipografi, boşluk, gölge ve motion için anlamsal token’lar. “mavi-500” değil “accent-primary”; “16px” değil “space-3”. Anlamsal isimlendirme, açık/koyu tema geçişini ve ileride bir marka revizyonunu tek bir katmanda mümkün kılar. Token’lar tek kaynaktan üretilir ve web, mobil, e-posta ve baskı için aynı JSON’dan beslenir; tasarım aracı ile kod hep aynı değeri görür.
• Komponent kütüphanesi. Figma’da master komponent, production’da React veya Astro karşılığı. Buton, form alanı, kart, modal, navigasyon, hero, footer — her biri varyant ve state ile (varsayılan, hover, devre dışı, hata, yükleme) dokümante. Her komponent erişilebilir doğar: klavye, ekran okuyucu ve odak yönetimi üretildiği anda test edilir. Amaç kopyala-yapıştır değil, içe aktarılan tek doğru komponenttir.
• Dokümantasyon sitesi. Storybook veya Zeroheight üzerinde kullanım örnekleri, do/don’t kuralları, erişilebilirlik notları, canlı kod parçaları ve marka tonu rehberi. Dokümantasyon sistemin kullanıcı arayüzüdür; iyi yazılmazsa sistem benimsenmez, ekip eski alışkanlığına döner.
• Yönetişim ve adoption kit. Sistem nasıl büyür: kim katkı yapar, değişiklik nasıl önerilir, sürüm nasıl numaralanır, eskimiş komponent nasıl emekliye ayrılır. Mevcut sayfaları yeni sisteme taşımak için bir göç planı, tasarımcı ve geliştirici eğitimi, ve benimseme ölçümü. Yönetişim olmadan sistem ilk yıl içinde yeniden çatallaşır.

Yaklaşımımız

Her ürün aynı olgunluk seviyesinde değildir. Bir startup’a kurumsal yönetişim modeli dayatmak da, beş ürünlü bir gruba gevşek bir stil rehberi vermek de hatadır. Bu yüzden işe bir olgunluk modeliyle başlar, sistemi tam da bulunduğunuz seviyeye göre kurarız:

• Seviye 0 — dağınık. Ortak bir dil yok; her ekran tek tek tasarlanır. Önce envanter ve hızlı kazanımlara odaklanırız.
• Seviye 1 — stil rehberi. Renk ve tipografi yazılı, ama kodda zorunlu değil. Token’ları kodda yaşayan değişkenlere çeviririz.
• Seviye 2 — komponent kütüphanesi. Yeniden kullanılan komponentler var ama dokümantasyon ve yönetişim eksik. Boşlukları kapatırız.
• Seviye 3 — yönetilen sistem. Sürümleme, katkı süreci ve benimseme ölçümü yerinde. Hedef sürdürülebilirliktir.
• Seviye 4 — ürün dili. Sistem ekipler arası varsayılan haline gelir; yeni özellik geliştirmenin maliyeti düşer. Odak optimizasyon ve ölçeklemeye kayar.

Karar çerçevemiz sade: bir komponenti sisteme almadan önce üç kez kullanıldığını görmek isteriz. Erken soyutlama, yanlış soyutlamadır. Aynı kart üç ekranda tekrar ettiğinde kalıp gerçektir; o zaman onu sisteme taşırız. Bu “üç vuruş” kuralı sistemi teoriden değil, gerçek ihtiyaçtan doğmaya zorlar. İkinci ilkemiz token-önce çalışmaktır: komponent kurmadan önce token katmanını sağlamlaştırırız, çünkü token değişmezse komponent de değişmez. Taban sağlam olunca üstündeki her şey ucuzlaşır.

Design system’leri sessizce öldüren tuzaklara da baştan dikkat ederiz. En yaygını “mezarlık kütüphane”dir — kimsenin kullanmadığı şık bir komponent seti; çünkü dokümantasyon veya göç yolu olmadan çıkmıştır ve ekipler eski kodu kopyalamaya devam eder. İkincisi aşırı bağımlılıktır: tek bir ekran hakkında çok şey bilen, bir sonrakinde yeniden kullanılamayan komponent. Üçüncüsü yönetişim kaymasıdır; iki ekip aynı butonu çatallar ve tek doğru kaynak sessizce ikiye döner. Üçüne karşı da ilk günden tasarlarız: dokümantasyon komponentle birlikte çıkar, komponentler sunumsal ve prop-güdümlü kalır, hafif bir katkı süreci kaynağı tek tutar.

Benimsemeyi ölçmek sistemin bir parçasıdır, sonradan eklenen bir şey değil. Küçük bir sinyal setini izleriz — yeni ekranların ne kadarı tamamen sistem komponentlerinden kuruluyor, ayda kaç tane tek-seferlik komponent üretiliyor, yeni geliştirici ilk ekranını ne kadar sürede çıkarıyor. Bu sayılar sistemin yaşadığını mı yoksa sessizce atlandığını mı söyler ve değeri, bütçeyi yöneten kişiler için görünür kılar.

Süreç

• Hafta 1–2 — Denetim. Mevcut tasarım varlıklarının envanteri, tutarsızlık raporu ve prensip atölyesi. Çıktı: arayüz envanteri + tutarsızlık haritası + öncelik listesi.
• Hafta 3–5 — Token ve temel set. Renk, tipografi, boşluk ve gölge için anlamsal token’lar, açık/koyu tema kararları ve temel komponent setinin tasarım + kod implementasyonu. Çıktı: token kaynağı + çalışan temel komponentler + birim testleri.
• Hafta 6–7 — Genişleme ve dokümantasyon. Genişletilmiş komponentler (form, tablo, modal, sayfa şablonları) ve dokümantasyon sitesi. Çıktı: tam komponent kütüphanesi + yayında dokümantasyon.
• Hafta 8 — Pilot ve devir. Bir landing page veya ürün ekranı yeni sistemle baştan kurulur; öğrenmeler kütüphaneye geri yansır. Yönetişim modeli devreye alınır. Çıktı: pilot ekran + katkı rehberi + ekip eğitimi.

Erişilebilirlik bu fazların hepsine gömülüdür, sona bırakılan bir kontrol değildir: kontrast, odak yönetimi ve klavye davranışı komponent üretildiği anda test edilir.

Sekiz haftalık süre bir başlangıç çizgisidir, bir bitiş değil. Design system kendi yol haritası olan bir üründür — kullanıcıları (tasarımcı ve geliştirici ekibiniz), sürümleri ve bir backlog’u vardır. Devirden sonra genellikle hafif bir ritimle dahil kalırız: aylık bir ofis saati, çeyreklik bir benimseme sağlık kontrolü ve ilk bir-iki büyük sürüm yükseltmesinde destek. Hedef, sistemi ekibinizin güvenle sahiplendiği, bize ihtiyaç duymadan katkı yaptığı ve biten bir proje değil bir altyapı olarak gördüğü noktaya getirmektir. Getiri lansmanda değil, ikinci yılda görünür olur; aynı temel üzerine kurulan üçüncü ve dördüncü ürün, birincisinin maliyetinin küçük bir kesrine mal olduğunda.

Bir örnek

Orta ölçekli bir omnichannel perakende markası, web mağazasını ve mobil uygulamasını iki ayrı ekiple yönetiyordu. Aynı “sepete ekle” butonu iki üründe farklı renk ve davranışla çıkıyor, kampanya dönemlerinde tutarsızlık görünür hale geliyordu. Denetimde 40’tan fazla farklı buton varyasyonu bulduk.

8 haftalık kurulumda token mimarisi ve 18 temel komponentle başladık. İlk fazda yeni özelliklerin yalnızca yeni komponentleri kullanmasını zorunlu kıldık, mevcut ekranları ise kademeli taşıdık. En zor kısım kod değil, yönetişimdi. Tek bir paylaşılan buton tanımı ve “yeni varyant çatallanmaz, önerilir” şeklinde hafif bir kural kurduk; 40 varyasyonun sessizce 41’e dönüşmesini engelleyen şey buydu. İlk ay içinde iki ekip, paralel yeniden yapım yerine birbirinin komponent taleplerini aynı kanalda gözden geçirir hale geldi.

Üç ay sonra ekip, yeni bir kampanya landing page’ini eskiden gün alan sürede değil birkaç saatte ayağa kaldırabilir hale geldi; tasarım ile kod arasındaki “neden farklı görünüyor?” düzeltmeleri belirgin biçimde azaldı ve ölçülen marka tutarlılık skoru 62’den 87’ye çıktı. Müşteriyi en çok şaşırtan sayı işe alıştırmaydı: yeni bir ön yüz geliştiricisi ilk haftasında üretim ekranı çıkardı, çünkü komponentler dokümante ve güvenilirdi. Abartılı bir dönüşüm değil — ölçülebilir, sürdürülen bir hız kazancı.

Sık sorulan sorular

Design system büyük ekipler için değil mi? Küçük ürünümüz için erken mi? Hayır. Küçük ürün için sistem hafif olur — birkaç token, birkaç komponent, kısa bir dokümantasyon. Erken kurulan hafif bir sistem, sonradan kurulan ağır bir migrasyondan her zaman ucuzdur. Mesele ölçek değil tekrardır: bir kalıbı üçüncü kez gördüğünüzde sistem zamanıdır.

Mevcut kod tabanımızı baştan yazmamız gerekecek mi? Gerekmez. Kademeli geçiş ilkesiyle çalışırız. Yeni özellikler sistemi kullanır, mevcut ekranlar öncelik sırasına göre taşınır. Büyük bir “yeniden yazım” projesi değil, kontrollü bir geçiştir.

Design system yaratıcılığı kısıtlamaz mı? Tersine. Çözülmüş problemleri standartlaştırmak, tasarımcının enerjisini gerçek probleme — kullanıcı deneyimine ve marka ifadesine — ayırmasını sağlar. Sistem butonun nasıl görüneceğini söyler; sayfanın nasıl hissettireceğini değil.

Hangi tasarım aracı veya teknoloji yığınıyla çalışıyorsunuz? Sistem araç-bağımsız tasarlanır. Token’lar tek kaynaktan üretilir ve hem Figma’ya hem de kod tabanınıza akar. Mevcut yığınınızın (React, Astro, mobil) üzerine kurarız; sizi belirli bir araca kilitlemeyiz.

Marka ve deneyim pillar’ı altında design system’inizi nasıl kuracağımızı ve ekibinize nasıl devredeceğimizi konuşmak için bize ulaşın.

Tek seferlik kampanya yerine, aylık ritimle çalışan bir editöryal program kuruyoruz. Konu seçimi, redaksiyon standardı ve dağıtım planı — hep birlikte.

Bu neden önemli

İçerik üretmek kolaydır; tutarlı, otorite kuran içerik üretmek zordur. Çoğu marka iki uçta sıkışır: ya pazarlama ekibi panik halinde son dakika sosyal post hazırlar, ya da pahalı bir ajans ayda bir blog yazısı teslim eder. İkisi de marka sesini bir yapıya dönüştürmez. Sonuç kahramanlık dönemleridir — bir ay üç yazı çıkar, sonra üç ay sessizlik. Her parça farklı bir sesle, farklı bir kaliteyle, farklı bir kişiden çıkar; okuyucu için sonuç sesini bulamamış dağınık bir markadır.

Bu dağınıklığın bir maliyeti var ve faturası gecikmeli gelir. Arama motorları düzenli ve otoriter yayını ödüllendirir; düzensiz yayın görünürlük kaybettirir. Satış ekibi paylaşacak içerik bulamaz, işe alımda aday markanın ne savunduğunu anlayamaz. En görünmez ama en büyük kalem fırsat maliyetidir: alanınızdaki otorite boşluğunu siz doldurmazsanız rakibiniz doldurur, ve geri kazanmak yıllar alır.

Editöryal program içeriği rastgele üretimden bir sisteme taşır. İçerik kararlarını ritim ve standart altına alır: hangi konuyu, ne sıklıkta, hangi formatta, hangi kanalda, hangi sesle. Amaç daha çok içerik değil; her parçanın bir öncekini güçlendirdiği, birikimli bir otorite inşasıdır. beynart bu programı kurduğunda ekibiniz hem hıza hem de kaliteye sahip olur.

Asıl mesele bu birikimdir. Tek bir harika yazı bir sıçramadır — birkaç haftada sönen bir trafik artışı. Birbirine bağlı bir kütüphane ise bir yıllık gelir gibidir: her parça aramada görünür kalmaya, satış ekibine paylaşacak bir şey vermeye ve bir sonraki parçanın maliyetini düşürmeye devam eder, çünkü araştırma ve ses zaten vardır. Düzensiz yayınlayan markalar bu bileşik eşiğe hiç ulaşamaz; tekrar tekrar sıfırdan başlamanın bedelini öder ve sayıların neden durağan kaldığını merak ederler.

Ne teslim ediyoruz

Editöryal program dört bileşenden oluşur ve her biri diğerini besler. Tek başına bir “içerik takvimi” sistem değildir; sistem, üretimin neden, ne ve nasıl sorularına birlikte cevap vermesidir. Strateji takvimi yönlendirir, takvim üretim hattını besler, hat ölçülebilir çıktı üretir ve ölçüm de stratejiyi yeniden ayarlar. Bu döngü kapandığında içerik artık tek tek gönderilerden değil, her çeyrek kendini düzelten bir motordan ibaret olur.

• İçerik stratejisi belgesi. Marka sesinin yazılı tanımı, üç pillar tema, hedef segment-konu eşleşmesi, anahtar kelime portföyü ve her segment için “neden bizi okumalı?” sorusunun cevabı. Strateji üretimden önce gelen karar katmanıdır; o olmadan takvim sadece boş kutular listesidir.
• Editöryal takvim ve formatlar. Aylık 12–20 parça için konu listesi, format (uzun yazı, kısa rehber, video, görsel post), sahip ve teslim tarihi. Takvim haftalık değil aylık planlanır ve üretim kapasitenize göre kalibre edilir; abartılı bir ritim üç ayda çöker, mütevazı ama tutturulan bir ritim otorite kurar.
• Stil kılavuzu ve redaksiyon süreci. Yazım kuralları, marka tabu listesi, iki aşamalı redaksiyon (içerik + tonal) ve kalite checklist. Süreç, içeriğin “birinin boş zamanına” bağlı olmaktan çıkıp tekrarlanabilir bir hatta dönüşmesini sağlar; her adımın bir sahibi ve bir kalite kapısı vardır.
• Dağıtım ve ölçüm planı. Her parçanın hangi kanalda, ne zaman, hangi mesajla yayına gireceği — tek üretim, çok kanal mantığıyla. Aylık performans raporu (görüntülenme, okuma süresi, dönüşüm, organik büyüme) takvimi her çeyrek yeniden önceliklendirmenin temelidir.

Yaklaşımımız

İçeriği bir kampanya değil, bir varlık olarak ele alırız. Kampanya biter; varlık birikir. Bu yüzden her parçayı tekil bir gönderi olarak değil, bir otorite kütüphanesine eklenen bir taş olarak planlarız.

Omurga olarak hub-and-spoke modelini kullanırız. Her tema için bir kapsamlı “hub” içeriği (alanı tüketen, kalıcı, derin bir rehber) ve onu besleyen birden çok “spoke” içeriği (spesifik, aramaya yönelik, hub’a bağlanan) üretilir. Bu yapı hem okuyucu için bir yolculuk, hem arama motoru için net bir konu otoritesi kurar — dağınık tekil yazılar yerine birbirini güçlendiren içerik kümeleri.

Önceliklendirmede sade bir karar çerçevesi kullanırız: her olası konu üç eksende puanlanır — aranma niyeti (insanlar bunu gerçekten arıyor mu?), otorite uyumu (bunu söylemeye gerçekten yetkili miyiz?) ve iş yakınlığı (konu satın alma kararına ne kadar yakın?). Üçünde de güçlü olan konular önce gelir. Bu çerçeve “yazması eğlenceli ama kimseye fayda etmeyen” içeriği planın dışında tutar. Ritim ilkemiz nettir: az ama sürekli, çoktan ama düzensizden iyidir — ayda iki güçlü, sürdürülen parça, ayda sekiz tutarsız parçadan daha fazla otorite kurar.

Editöryal programları batıran kalıplara karşı da tasarım yaparız. Birincisi “kurucu dar boğazı”dır: her parça tek bir yoğun kişiyi bekler ve o kişi seyahate çıktığı ilk anda ritim ölür. Bunu röportaj temelli üretimle çözeriz — uzman otuz dakika konuşur, bir editör yazar, kalite kapısı insanda kalır. İkincisi “gösteriş yayını”dır: satın alma kararına giden bir yolu olmayan konularla görüntülenme peşinde koşmak. İş yakınlığı ekseni tam da bunu yakalamak için vardır. Üçüncüsü bakımsız kütüphanenin yavaş ölümüdür; eski yazılar bayatlar ve güveni sessizce aşındırır. Bu yüzden her çeyrek yalnızca yeni eklemekle kalmaz, en değerli parçaları tazelemeye de zaman ayırırız.

Ölçüm üzerine bir not, çünkü bir sonraki neyin yazılacağını belirler. Gösteriş panolarından kaçınır, kısa bir listeyi izleriz: hub kümelerine gelen organik trafik, içeriğin dokunduğu anlaşmalardaki destekli dönüşüm, uzun yazılarda okuma derinliği ve satış görüşmelerinde bir parçanın paylaşıldığı oran. Bu sinyaller hangi temaların daha çok spoke hak ettiğini, hangilerinin emekliye ayrılması gerektiğini söyler — takvimi sabit bir plandan bir geri besleme döngüsüne çevirir.

Süreç

• Hafta 1 — Keşif. Marka, segment ve mevcut içerik audit’i; rakip içerik landscape analizi. Çıktı: ses dökümanı + içerik denetimi + boşluk analizi.
• Hafta 2 — Strateji. Tema haritası, hub-and-spoke yapısı ve ilk 90 günlük takvim taslağı. Çıktı: editöryal strateji + içerik takvimi.
• Hafta 3 — Hat kurulumu. Stil kılavuzu, redaksiyon iş akışı ve tooling kurulumu (Notion veya Airtable). Çıktı: stil kılavuzu + çalışan üretim hattı.
• Hafta 4 — İlk üretim ve devir. İlk batch parçalarının üretimi, ekip eğitimi ve aylık ritmin başlatılması. Çıktı: yayınlanmış ilk içerikler + kanal dağıtım planı.
• Sürekli — Ölçüm. Her çeyrek performans izlenir, takvim yeniden önceliklendirilir. Çıktı: çeyreklik içerik raporu + güncellenmiş takvim.

Dağıtım kendi disiplinini hak eder, çünkü kimsenin görmediği bir parça hiç var olmamış gibidir. Her hub’ı daha küçük varlıklara böldüğümüz bir kaynak olarak ele alırız: uzun bir rehber bir e-bülten sayısına, üç-dört sosyal gönderiye, satış ekibinin takip e-postaları için kısa bir cevaba ve iç kullanım için bir özet sayfaya dönüşür. Bu “tek üretim, çok kanal” yaklaşımı getirinin çoğunun saklandığı yerdir — pahalı kısım yazmaktır ve tek parçadan dört kanal çıkarmak, makul bir bütçeyi güçlü bir bütçeye çeviren şeydir. Ekibin asla sessizliğe yayın yapmaması için sade bir tanıtım kontrol listesi de dokümante ederiz.

Bir örnek

Bir B2B yazılım şirketi ayda altı blog yazısı yayınlıyordu ama trafik durgundu. İnceleme, yazıların birbirinden kopuk ve aramaya yönelik olmadığını gösterdi — her biri ayrı bir adada duruyordu. Ritmi ayda dört parçaya düşürdük ama bunları üç tema etrafında hub-and-spoke yapısına bağladık.

Yapı, konuların nasıl seçildiğini değiştirdi. Başlık listesi üzerine beyin fırtınası yapmak yerine ekip fikirleri aranma niyeti, otorite uyumu ve iş yakınlığı üzerinden puanladı; bu, kimse tek kelime yazmadan önce “ilginç ama anlamsız” bir düzine yazıyı sessizce eledi. Sonra her hub spoke’lara bölündü ve e-bülten ile sosyalde yeniden dağıtıldı; böylece tek bir derin rehber, beş ayrı parçanın işini gördü.

Altı ayda 96 bağlı parça yayınlandı; toplam çıktı önceki dağınık döneme göre daha az kopuk, daha bağlıydı. Organik trafik anlamlı biçimde büyüdü, demo talebinin önemli bir kısmı içerik kanalından geldi ve satış ekibi ilk kez “bu konuyu soran müşteriye gönderecek bir yazımız var” diyebilir hale geldi. Editöryal süreç tamamen client ekibine devredildikten sonra da ritim 12 ay süreyle korundu — asıl sınav budur: yalnızca ajans odadayken yürüyen bir program aslında kurulmamış demektir. Mucizevi bir sıçrama değil — sürdürülen, ölçülebilir bir büyüme.

Sık sorulan sorular

Ekibimizde içerik yazacak kişi yok. Yine de işe yarar mı? Evet. Editöryal program tam da bunun için var: üretimi tek bir kişinin boş zamanına bağlı olmaktan çıkarır. Üretim hattını sizin kapasitenize göre kurarız — kimi zaman sizin uzmanlarınızla röportaj temelli, kimi zaman tam dış kaynaklı.

Ne zaman sonuç görürüz? İçerik birikimli bir varlıktır; ilk somut işaretler genellikle birkaç ay içinde görünür, asıl bileşik etki çeyrekler boyunca oluşur. Hızlı bir kampanya arıyorsanız bu doğru araç değildir; kalıcı otorite arıyorsanız doğru araçtır.

Yapay zeka ile içerik üretmiyor musunuz? Araçları üretim hattının verimli adımlarında kullanırız, ama otorite uzmanlıktan gelir. Bir konuyu söylemeye yetkili değilseniz hiçbir araç bunu telafi etmez. Editöryal kalite kapısı her zaman insandadır.

Mevcut blogumuzu çöpe mi atacağız? Hayır. Keşif fazında mevcut içeriği denetler, değer üreten parçaları yeni yapıya bağlar veya güncelleriz. Var olan otoriteyi yıkmak yerine üzerine inşa ederiz.

Marka ve deneyim pillar’ı altında editöryal programınızı nasıl kuracağımızı konuşmak için bize ulaşın.

Markanın hareket dilini yazılı bir sistem haline getiriyoruz. Timing curve'ler, duration token'ları, decay kuralları ve prefers-reduced-motion uyumu — bir kez yazılır, her ekipte aynı şekilde uygulanır.

Bu neden önemli

Marka kimliği çoğu şirkette donmuş karelerde tasarlanır — logo, renk, tipografi, bir grafik dili. Ama ürün hareket eder. Sayfa açılır, modal yukarı kayar, buton bastığınızda geri biler. Ve bu hareketin kuralı çoğu zaman yoktur; o anda klavyenin başında kim varsa onun hissine kalmıştır. Bir ekranda 200ms ease-in-out, başka bir ekranda 600ms cubic-bezier, mobil uygulamada hiçbir kural yok. Marka grafikte tutarlı, harekette dağınıktır.

Bu görünmez bir tutarsızlıktır ama hissedilir. Kullanıcı bir geçişin neden “ucuz” hissettirdiğini söyleyemez; sadece güveni biraz azalır. Ekip içinde ise her hareket bir tartışmaya dönüşür: “burada ne kadar yavaşlatalım, bu yay çok mu sert?” Bu tartışmalar her sprint tekrar eder, çünkü yazılı bir referans yoktur. Daha ciddi bir maliyet de erişilebilirliktedir: kuralsız hareket, vestibüler rahatsızlığı olan kullanıcılar için tetikleyici olabilir ve prefers-reduced-motion desteklenmediğinde bu bir WCAG ihlalidir.

Motion marka sistemi, marka kimliğini zamana yayan kuralları yazılı hale getirir. beynart’ta motion bir efekt değil, bir marka token’ıdır; web, iOS, Android ve video ekibinin aynı kaynağı kullandığı bir kontrattır. Bir kez yazılır, her ekipte aynı şekilde uygulanır.

Tutarlılığın ne kazandırdığını somutlamakta fayda var. Her durum değişikliğini aynı easing eğrisi yönettiğinde, ürün birbirinden kopuk ekranlar dizisi gibi değil, tek ve sürekli bir yüzey gibi hissettirmeye başlar. Geçişler dikkat için yarışmayı bırakır ve işe yarar bir görev üstlenir: kullanıcıya bir panelin nereden geldiğini söyler, dokunuşun algılandığını doğrular, bir gezinme sırasında onu yönelmiş tutar. Süsleyen hareketle anlatan hareket arasındaki fark budur — ve bu, ancak kurallar bir düzine kişinin sezgisinde değil tek bir yerde yaşadığında ortaya çıkar.

Ne teslim ediyoruz

Motion sistemi dört katmanda çalışır: ham token’lar, bunların komponentlere uygulanma kuralları, erişilebilirlik kontratı ve hareketli mecraya (video) taşınması. Hepsini birlikte teslim ederiz; çünkü token’sız kural keyfîdir, kuralsız token kullanılmaz. Amaç motion’ı bir sanat eserine değil, bir karar tablosuna dönüştürmektir: bir geliştirici “bu modal ne kadar sürede açılsın?” diye sorduğunda cevabı tartışmaz, dokümantasyondan okur. Bu, hızı düşürmez; tam tersine, kararın zaten verilmiş olması her ekranı hızlandırır.

• Motion token kütüphanesi. Duration (xs/sm/md/lg/xl), easing curve (enter, exit, bounce, decay) ve delay sabitleri. Tek kaynaktan üretilen JSON çıktısı; web, mobil ve After Effects ekibi aynı dosyadan beslenir. Hız ve eğri artık “his” değil, paylaşılan bir değerdir.
• Komponent motion kuralları. Buton, modal, tooltip, sayfa geçişi, hero girişi, scroll reveal — her biri için “ne zaman hangi token”. Figma Smart Animate ve kod örnekleriyle, “ne kadar” değil “neden bu kadar” sorusuna cevap verecek şekilde dokümante.
• Erişilebilirlik kontratı. prefers-reduced-motion davranışı zorunlu; her hareketin azaltılmış varyantı önceden tanımlı. Sona bırakılan bir kontrol değil, sistemin doğduğu andan itibaren parçası. WCAG 2.3.3 uyumu testlerle doğrulanır.
• Video ve marka filmi rehberi. TV, sosyal medya ve ürün demosu için tempo, geçiş ve lower-third standartları. Motion logo’nun web’deki davranışıyla birebir tutarlı; ürün arayüzünde gördüğünüz ivme, reklam filminde de aynı hisseder.

Yaklaşımımız

Motion’a “süsleme” gözüyle bakmayız. İyi hareket görünmezdir; işini yaptığında kullanıcı onu fark etmez, sadece arayüzün “akıcı” olduğunu hisseder. Bu yüzden her hareketi üç soruya cevap verecek şekilde tasarlarız: ne anlatıyor (nesne nereden geldi, nereye gidiyor?), ne kadar sürüyor (kullanıcının dikkatini bekletmeden mi, bir durum değişikliğini vurgulayarak mı?) ve azaltılmış halde ne oluyor (hareket kapalıyken arayüz hâlâ anlaşılır mı?).

Hız konusunda ilkemiz nettir: hızlı varsayılan, yavaş istisna. Çoğu mikro-etkileşim (hover, focus, buton) insanın dikkat eşiğinin altında, 150–250ms aralığında kalmalıdır. Daha uzun süreler yalnızca bir hikâye anlatıldığında — sayfa geçişi, ilk yükleme, önemli bir durum değişikliği — gerekçelendirilir. Bir diğer ilkemiz token-öncedir: ham duration ve eğri token’larını sabitlemeden komponent kuralı yazmayız, çünkü değerler değişkenleşirse sistem ilk ayda dağılır.

Olgunluk açısından çoğu ekip üç seviyeden birindedir. Seviye 0 — kuralsız, her hareket keyfî. Seviye 1 — duration token’ları var ama eğri ve reduced-motion tutarsız. Seviye 2 — token + komponent kuralı + erişilebilirlik kontratı tek kaynakta. Sizi bulunduğunuz seviyeden bir üste taşıyacak en küçük adımı önceliklendiririz; sıfırdan büyük bir sistem dayatmayız.

Ölçüm sistemi dürüst tutar. Motion’ı aşırı mühendislemek kolaydır; bu yüzden kısa bir sinyal setini izleriz: kod tabanında kaç farklı duration değeri olduğunu (az olması daha sağlıklıdır), her interaktif komponentin tanımlı bir reduced-motion varyantı olup olmadığını ve hafif kullanıcı testlerinden gelen algılanan hız skorlarını. İlk sayı, token’ların gerçekten kullanılıp kullanılmadığını söyler; ikincisi sert bir erişilebilirlik kapısıdır; üçüncüsü ise kullanıcı için önemli olandır, çünkü yavaş bir arayüz ile hızlı bir arayüz tam aynı kare hızında çalışabilir — fark, zamanlama ve eğridedir.

Süreç

• Hafta 1 — Envanter. Web, mobil, sosyal video ve sunum varlıklarındaki duration ve curve dağılımının haritalanması. Çıktı: mevcut hareket envanteri + tutarsızlık raporu.
• Hafta 2 — Token tasarımı. Token sisteminin tasarımı; tasarım ve geliştirme ekipleriyle prensip atölyesi. Çıktı: motion token kaynağı + uzlaşılmış ilkeler.
• Hafta 3 — Implementasyon. Komponent motion kurallarının uygulanması (Framer Motion, Lottie ve native eşdeğerleri) ve reduced-motion testleri. Çıktı: çalışan motion komponentleri + erişilebilirlik testleri.
• Hafta 4 — Dokümantasyon ve devir. Dokümantasyon sitesi, ekip eğitimi ve tek pilot ürün ekranının yeni sistemle yeniden çıkarılması. Çıktı: motion dokümantasyonu + pilot ekran + eğitim.

Mühendislik gerçeği üzerine bir not: motion implementasyonda yaşar ya da ölür. Figma’daki kusursuz bir spec, web ekibi onu tahmin edilmiş bir cubic-bezier ile yaklaşık geçtiğinde ve iOS ekibi varsayılan bir yay seçtiğinde hiçbir şey ifade etmez. Bu yüzden teslimat yalnızca sayıları değil, kullanıma hazır kodu da içerir — web için dışa aktarılmış easing fonksiyonları, native için eşdeğer yay parametreleri ve her animasyonlu komponent için commit edilmiş bir reduced-motion fallback’i. Token’ları ekibin zaten kullandığı şeye bağlarız; böylece sistemi uygulamak ek bir iş değil, en az direnç gösteren yol olur. Kolay yol ile doğru yol aynı yol olduğunda, tutarlılık disipline bağlı olmaktan çıkar.

Bir örnek

Bir fintech ürünü, iOS uygulaması ile web app’ini iki ekiple geliştiriyordu. Aynı “onay” akışı iki platformda farklı hız ve eğriyle çalışıyor, kullanıcı testlerinde web tarafı “ağır”, iOS tarafı “telaşlı” olarak tarif ediliyordu. Envanterde ana akışlarda 30’dan fazla farklı duration değeri vardı.

Motion sistemini tek kaynak haline getirip beş duration ve dört eğri token’ına indirdik, her komponent için “hangi token, neden” kuralını yazdık ve prefers-reduced-motion varyantlarını zorunlu kıldık. Asıl zor konuşma indirgemenin kendisiydi: her ekibin favori bir zamanlaması vardı ve 30 değeri beşe düşürmek, bazı ekranların bağlı olduğu bir eğriden vazgeçmesi anlamına geliyordu. Kararı zevke değil algılanan hız testine dayandırdık; bu, bir tercih tartışmasını bir kanıt sorusuna çevirdi.

Birkaç ay sonra ekipler arası “burada ne kadar yavaşlatalım” tartışmaları belirgin biçimde azaldı; iOS ve web app’teki ana akışların algılanan hız skoru (kullanıcı testi, 5’lik skala) 3,2’den 4,4’e çıktı ve reduced-motion ihlal raporu sıfıra indi. Web tarafı “ağır”, iOS tarafı “telaşlı” hissettirmeyi bıraktı — bir şey daha hızlı hareket ettiği için değil, ikisi de artık aynı kurallarla hareket ettiği için. Dramatik değil — tutarlı ve ölçülebilir.

Sık sorulan sorular

Motion sistemi sadece büyük ürünler için bir lüks değil mi? Hayır. Kuralsızlığın maliyeti her ölçekte gerçektir: küçük bir üründe bile her hareketin tartışılması zaman yakar ve prefers-reduced-motion eksikliği bir erişilebilirlik açığıdır. Sistem ölçeğe göre hafifler; beş token ve bir avuç kural bile bir ürünü kuralsızlıktan kurtarır.

Belirli bir animasyon kütüphanesine bağımlı mı kalırız? Hayır. Token’lar araç-bağımsız üretilir; aynı JSON Framer Motion, Lottie, CSS veya native’e akar. Sizi bir kütüphaneye kilitlemeyiz, mevcut yığınınızın üzerine kurarız.

Reduced-motion her şeyi kapatmak anlamına mı geliyor? Hayır. Hareketi yok etmek değil, güvenli hale getirmek hedeftir. Büyük yer değiştirme ve paralaks gibi tetikleyici hareketler azaltılır; bir durumu anlatan ince geçişler (örneğin opaklık) korunabilir. Her komponent için azaltılmış varyantı önceden tanımlarız.

Marka filmi ve ürün arayüzü neden aynı sistemde? Çünkü kullanıcı ikisini ayırmaz. Reklam filminde gördüğü ivmeyle ürün arayüzünde hissettiği ivme uyuşmazsa marka iki ayrı kişilik gibi görünür. Tek motion dili, mecradan bağımsız tutarlı bir marka karakteri kurar.

Marka ve deneyim pillar’ı altında motion sisteminizi nasıl kuracağımızı konuşmak için bize ulaşın.