Ana içeriğe geç

Tasarım Sistemlerini Anlamlandırmak

DataCamp’te daha ölçeklenebilir bir tasarım yaklaşımı üzerinde çalışıyoruz. Bu yazıda tasarım sistemleri hakkında daha fazlasını ve kendi sistemimizi nasıl anlamlandırmaya çalıştığımızı okuyun!
Kristof For Goran
Kristof For Goran

Ücretsiz Hesabınızı Oluşturun

Alıştırma and program your progress.

Google ile devam edinDevam ederek, Kullanım Koşullarımızı ve Gizlilik Politikamızı kabul etmiş ve verilerinizin ABD'de saklandığını onaylamış olursunuz.

DataCamp’te misyonumuz veri bilimi eğitimini herkes için demokratikleştirmek ve dünya çapında 2 milyondan fazla öğrenciyle hızlı ilerleme kaydediyoruz. Bu büyüme hızında çalışmak, şirketteki herkesin ciddi çaba göstermesini gerektiriyor ve beraberinde heyecan verici yeni zorluklar getiriyor.

Tasarım ekibi için bu, sayfa bazlı tasarımdan daha ölçeklenebilir bir tasarım biçimine geçmek anlamına geliyor. Mevcut bileşenleri yeniden kullanmak, geliştirme süresini azaltmak, kullanılabilirliği iyileştirmek ve erişilebilirliği artırmak her geçen gün daha önemli hale geliyor.

Bu yazı, bir tasarım sistemini nasıl anlamlandırmaya başladığımızı anlatıyor.

Tasarım sistemi nedir?

Tasarım sistemi, bir tasarım çözümünü dağıtmak ve yeniden üretmek için gereken tüm bileşenleri bir araya getirir. Bu, dijital ürün tasarımına özgü ya da yeni bir şey değildir — tarih boyunca pek çok örneği bulunur.

Örneğin, ilk Çin imparatorluğunda okçular yoldaşlarının oklarını kullanamıyordu. Her ok belirli bir yay için özel olarak tasarlanmıştı; bu yüzden başka oklar basitçe uymuyordu. İlk Çin imparatoru Ying Zheng, okların tasarımını standartlaştırdı ve bunun askeri fetihleri üzerinde büyük etkisi oldu.

50’lerde, NYC Ulaşım Sistemi’nin her istasyonunun kendi tabelaları vardı. Her istasyonun kendine özgü yönlendirme biçimi olması büyük bir kafa karışıklığı yaratıyordu. Sonuç olarak, birçok kişi sistemi kullanmaya çekiniyordu çünkü nasıl çalıştığını anlayamıyorlardı. Massimo Vignelli ve Bob Noorda, tabelaların nasıl yapılacağını ve istasyonlarda nasıl konumlandırılacağını belgeleyen NYC Transit Authority — Graphics Standards Manual’ı oluşturdu. Zaman içinde bu sistem az çok aynı kaldı ve bugün hâlâ aktif olarak kullanılıyor.

Neden bir tasarım sistemimiz olmalı?

Her sayfa izole biçimde tasarlandığında, pek çok bileşenin yinelenenleri ya da benzer alternatifleri oluşur. Bu, dijital bir ürünü kullanıcıların anlamasını ve mühendisliğin bakımını zorlaştırır. DataCamp’te ürün genelinde 20’den fazla farklı buton keşfettik; her birinin kendine has tuhaflıkları vardı (farklı hover durumları, tutarsız devre dışı durumlar vb.). Bir ürün hızla büyürken tüm bu bileşenleri takip etmek zordur ve bakımı neredeyse imkânsız hâle gelir. İşte tam bu noktada bir tasarım sistemi devreye girer.

Dijital bir ürün için tasarım sistemi, bir sorunu çözen ve kullanıcı için tutarlı bir deneyimle sonuçlanan bir arayüz oluşturmak amacıyla kullanılabilecek kullanıcı arayüzü bileşenlerini tanımlar.

İyi uygulanan bir tasarım sistemi, şu alanlarda zincirleme bir etki yaratır…

  • Yanlış iletişimi azaltır
  • Uygulama süresini azaltır
  • Bakım işini azaltır
  • Hataları azaltır
  • Destek taleplerini azaltır
  • Kaliteyi artırır
  • Verimliliği artırır
  • Dayanıklılığı artırır
  • Öğrenilebilirliği artırır
  • Kullanılabilirliği artırır
  • Erişilebilirliği artırır
  • Yeniliği artırır
  • Odağı artırır
  • Satışları artırır

Kolay değil…

Bir tasarım sistemi oluşturmak, sürdürmek ve uygulanmasını sağlamak; sürecin bir parçası olan herkes için ciddi bir disiplin ve sürekli çaba gerektirir. Bu yalnızca tasarım değildir; mühendislik ve ürün yönetimi de önemli paydaşlardır. Herkes şu zorlu soruları sorabilmelidir: “Bunu neden yapıyoruz?”, “Bu bileşeni başka bir yerde tekrar kullanabilir miyiz?”, “Zaten buna benzer bir şeyimiz var mı?”, “Bu özel bileşen, harcadığımız emeğe kıyasla yeterli fayda sağlıyor mu?”.

DataCamp’te Tasarım Sistemi 101

1. Bileşen Envanteri Oluşturun

Amaç: Herkesin bir bileşenin varlığını ve durumunu bilmesini sağlamak.

DataCamp’te işe başladığımda, renkler, ikonlar, yazı tipleri ve bazı temel bileşenleri içeren bir Sketch dosyası vardı. Tam olmaktan uzaktı ama iyi bir başlangıç noktasıydı. Front-end mühendisliği de projeler arasında kullandıkları bir bileşen koleksiyonuna sahipti.

Birlikte, üretimde kullanılan bileşenlere dayanarak Airtable’da bir envanter oluşturduk. Bu, tasarım ekibine nelerin zaten var olduğu hakkında fikir verdi ve bilmeden yeni bileşenler yaratmamızı önledi. Ayrıca kaç tane benzer bileşenimiz olduğuna ve durumun gerçekte ne kadar kötü olduğuna dair içgörü sağladı.

2. İsimlendirme Kuralları Kullanın

Amaç: Tasarım ve Mühendislik arasında yanlış iletişimi önlemek.

Bileşenleri karşılaştırmaya başladığımızda, Tasarım ve Mühendisliğin aynı dili konuşmadığını fark ettik. Örneğin, tasarım tarafından tanımlanan ‘birincil renk’, koddaki ‘ikincil renk’ti. Bu tür durumlar, ekipler ölçeklenmeye başladığında yanlış iletişime yol açar; kafa karışıklığı ve hayal kırıklığı yaratır. Farklı ekiplerde aynı dili kullandığımızdan emin olduk.

3. Tasarım İş Akışını Optimize Etmek

Amaç: İş kaybını önlemek ve şeffaf bir iş akışına sahip olmak.

Bir tasarım ekibi olarak birlikte çalışmak kendi zorluklarını getirir. Tasarımları Dropbox’ta saklardık; ancak ekibimiz büyümeye başladığında iş kaybetme riski ve değişiklikleri takip etme çabası dramatik biçimde arttı.

Tasarım ekibimiz bir iş akışı değişikliğine oldukça açıktı ve Abstract kullanmaya başladık. Bu sayede tasarımlarımızı düzgün biçimde versiyonlayabildik, şeffaf bir iş akışı oluşturduk ve tasarım yaparken daha fazla güven kazandık.

4. Daha İyi Dokümantasyon + Oryantasyon

Amaç: Daha hızlı çalışan oryantasyonu ve iletişim yükünü önlemek.

Sürecimizi ve tasarım sistemimizi Slite kullanarak belgelemeye başladık. Bir şeyi birden fazla kez açıklamamız gerekiyorsa, bu belgelenmeli ve ekiple paylaşılmalıdır. Bu, iletişim yükünü büyük ölçüde azaltır ve bilgilerin kaybolmasını önler.

5. Tasarım İncelemeleri

Amaç: Tasarım ve Mühendislik arasında beklentileri belirlemek.

Tasarım incelemelerinin iki yönlü gerçekleşmesi önemlidir. Tasarımcılar front-end’i inceleyebilmelidir; ancak front-end de tasarımı inceleyebilmelidir. Tasarımcıların havalı ve yeni bir şeyler yaratma dürtüsü vardır. Mühendisler şu zorlu soruları sorabilmelidir: “Neden özel bir şey inşa ediyoruz?”, “Bu bileşeni yeniden kullanamaz mıyız?”, “Bu bileşeni daha iyi yapabilir miyiz?”, “Bu bileşen ekstra geliştirme çabasına değer mi?”. Burada amaç, kararları gerekçelendirmek ve sürece dahil olan herkes için beklentileri belirlemektir.

Sonuç

Tasarım sistemimizi yeni yeni bir araya getirmeye başladık ve ürünümüz boyunca bulduğumuz tüm yinelenen bileşenleri hâlâ anlamlandırmaya çalışıyoruz. Önümüzde uzun bir yol var; ancak dokunduğumuz her bileşenle müşterilerimiz için daha iyi, daha tutarlı ve öğrenmesi daha kolay bir ürün oluşturuyoruz.

Diğer kuruluşların bir tasarım sistemini nasıl anlamlandırdığını merak ediyoruz. Deneyiminizi paylaşmak isterseniz bana e‑posta gönderin.

DataCamp’te ekibimize katılacak yetenekli kişiler arıyoruz. İlginizi çekti mi? Açık pozisyonlarımıza göz atın.

Konular

İlgili