Bu aralar tasarım sistemi ilk kurulumuna katılırken kafamda çok fazla soru var.
Bununla ilgili olarak geçen hafta UX Collective'te okuduğum bir içerik vardı. Şirketteki tasarım sistemi üyeleri için çevirmiştim; kıyamayıp burada da paylaşayım dedim.
Tasarım sistemleriyle çalışan 10 tasarımcıyla yapılan röportajların özeti olduğunu söylüyorlar.
Soru 1. DS rolünde başarısız olmak için ne yapmak gerekir?
-
Polis olmak
-
Tasarımcı gücünü kullanmak (siyaset konuşması)
-
Bileşenleri birleştirip sonra hiç kullanmamak
-
Takımın ihtiyaçlarını öngörmek yerine sonradan tepki verir gibi çalışmak
-
Kullanıcıların (diğer tasarımcılar veya geliştiriciler) sesini dinlememek ya da araştırmamak
-
DS için yapılmış DS
-
İş için net bir yol haritası ve süreç sürdürmemek
-
Gerçekleştirilemeyecek kadar ideal bir deneyim kurmak
-
Takımla birlikte test etmemek
-
DS'yi bir ürün olarak anlamamak
-
Araçları yapıp insanlara onları nasıl kullanacağını öğretmemek
-
Gerçek çalışma biçiminden kopuk çok fazla teori getirmek
-
Bunu tek başına yapabileceğini düşünmek
-
Teknik ekipten biriyle bilgi alışverişine %100 odaklanmamak
-
Fazla esnek olmayan bileşenler yapmak ve Detaching'e izin vermemek
-
Yardım istememek ve insanlarla bağlantı kurmamak (içeride ya da dışarıda)
-
Hemen yanlarında olmak yerine uzaktan kural dayatmak
Soru 2. DS'nin başarılı olması için hangi soft skill'ler gerekir?
-
İletişim, iletişim, iletişim!!!
-
Kullanıcılarla birlikte olmak; dinlemek, sormak ve araştırmak gerçekten çok önemlidir.
-
Başarısızlığı alçakgönüllülükle kabul edin
-
Sabırlı olun
-
Güvenli bir alan yaratma becerisi
-
Öğretmek
-
Yeniden kullanım yöntemine dair sistematik bir vizyon sunmak
-
Ölçek büyürken de kararlı biçimde tutarlılığı korumak gerekir
-
Karşı tarafı anlamaya çalışırken o kadar da fazla empati kurmanız gerekmez. Kuralları olduğu gibi kabul edin.
-
%95'i hard skill, %5'i ise kurallar ihlal edildiğinde gereken soft skill'dir.
-
İnsanların gelişimini teşvik edin ve paylaşın
-
Özerklik
-
Ürünü (DS'yi) sürekli satmaya devam edin
-
Stratejik düşünün
-
Herkesin katılmasını sağlayın
-
DS etrafında görünürlük yaratın
-
Mümkün olduğunca çok senaryoyu ortaya çıkarmak için mümkün olduğunca çok zaman harcayın
-
Ortak bir dil kullanın.
Soru 3. DS'nin uygulanma biçimi daha merkezi mi olmalı, yoksa daha dağıtık mı?
İki yaklaşım var: insanların nasıl tasarım yaptığını kontrol edip sorumluluğu alan merkezi bir ekip ve herkesin bundan sorumlu olduğu bir model. Hangi tarafın doğru olduğunu insanlara sorduk.
-
Biz fazla merkezi bir takımız, bu yüzden darboğaz oluşuyor. Ama dağıtık model de sahiplenmenin zayıflaması gibi sorunlar yaratabilir.
-
Bizde DS'yi merkezileştirmek için 100'den fazla kişinin yer aldığı bir tasarım ekibi var.
-
İnsanların oluşturduğu alfa kütüphanelerle iş birliği yapıyor ve DS ekibinin backlog'unu oradan oluşturuyoruz.
-
İnsanları gönüllü olarak bileşen oluşturmaları için eğitiyoruz.
-
Merkezileştirip merkezileştirmemek büyük ölçüde politik bir meseledir. Buna karar vermeden önce ne kadar ölçeklenebilir olması gerektiğini net olarak bilmek gerekir.
-
Beklentileri hizalamak ve insanları DS oluşturma sürecine dahil etmek gerekir.
-
İş birliği yapmak istiyorduk ama nasıl yapacağımızı iyi bilmiyorduk, bu yüzden bir süreç oluşturduk. (Culture vs Process)
-
Başlangıçta teslimat için biraz daha az iş birlikçi olunabilir. Olgunlaştıkça daha iş birlikçi hale getirilebilir.
-
Artık bunu merkezsizlik yönünde ilerletmemiz gereken noktaya geldik; insanlara nasıl katkı vereceklerini öğretmemiz gerekiyor.
-
İnsanları eğitmezseniz katkı vermezler.
-
Tasarımcı standartların ötesine geçip daha iyi bir çıktı üretmek istediğinde, aynı anda bunu nasıl standartlaştırabileceğini de birlikte düşünebilmelidir.
-
DS 1-2 kişiyle yapılabilecek bir iş değildir. Bir sistem kurmak olduğu için DS, squad düzeyinde başlamalıdır.
-
Bu, takımın büyüklüğüne göre çok değişir; bazen DS ekibi çekirdek bileşen geliştirmeye odaklanır ve diğer ambassador'lar bunu yayabilir.
-
Sonuçta biz merkezi bir ekibiz ama ambassador'larla iş birlikçi çalışıyoruz. Nihai kararı DS ekibi veriyor.
- DS'yi daha ayrıntılı ve kısıtlayıcı kurallar bütünü olarak mı görüyorsunuz? Yoksa daha geniş kapsamlı, tasarımcıya yeni yerleşimler oluşturma özgürlüğü veren açık bir yapı olarak mı?
Kapalı mı açık mı? Tasarım sistemi işi yapıyorsanız bu soru ilginizi çekecektir. Benim çektiği için insanlara sormaya karar verdim.
-
"Erişilebilirlik" söz konusuysa daha kısıtlayıcı yaklaşın
-
Hep birlikte temel bir yapıdan başladık ama bazı tutarsızlıklar üretmeye başladık. Bu yüzden %100 kapalı olmasak da biraz daha fazla kısıt koymaya karar verdik. Bununla birlikte tasarımcıya bir şey geri verebilmenin yollarını da her zaman arıyoruz
-
Duruma göre değişir; önce riski ölçün, sonra karar verin. Genel olarak daha küçük takım = daha yüksek esneklik
-
Mesele sadece yaratıcı olup yeni bileşenler üretmek değildir. İnsanların ihtiyaçlarına uyacak kadar esnek bileşenlere ihtiyaç vardır
-
DS bir iştir. Ne kadar az bileşen varsa o kadar iyidir.
-
İnsanlar DS'yi kullanmaktan keyif almalıdır. Dışarıdan bakınca üniforma gibi göründüğü için esnekliğe gerek yokmuş sanmak kolaydır (öyle değil)
-
En baştan çok kısıtlayıcı olamazsınız. Yeterince zaman geçtikçe belirli pattern'ler vb. üzerinden evrilmeye başlayabilir.
-
Şirkete yeni katılan tasarımcılar için daha fazla kısıt yararlı olabilir. Kuralları bozmak için önce kurallarla başlamak gerekir.
-
İnsanların kendi tariflerini oluşturabilmesi için yeterli malzeme sağlıyoruz.
-
Takımın olgunluk seviyesine göre değişir. Junior sayısı fazlaysa, daha az belgeyi anlayabildikleri için daha fazla tasarım kılavuzu talep etme eğiliminde olurlar. Bu yüzden daha fazla eğitim gerekir, ama yine de onları kapatmadan özgür çalışabilmeleri için uğraşıyoruz. En büyük zorluk, insanların dokümantasyonu gerçekten okuyup kullanmasını sağlamaktır; bu yüzden bunu Figma gibi tasarımcıya daha yakın araçlara taşıma ihtimali vardır.
-
Erişilebilirlik ve estetik söz konusuysa daha kısıtlayıcı olmalıdır.
-
Token'lar tutarlılığı korumada önemlidir.
-
İyi dokümantasyon, insanları hizalamakla onları özgür bırakmak arasındaki dengeyi kurar.
Soru 5. Branding ve marketing ile bağlantılı DS hakkında ne düşünüyorsunuz?
(Bu alanı çok iyi bilmediğim için çevirmesi biraz zor oldu.)
Tasarım sisteminin sonuçta dijital ürünle ilgili olması gerektiğini anlıyorum, ama ürün en önemli marka platformlarından biri olabileceği için insanların bunu birbirine nasıl bağlayarak düşündüğünü merak ettim.
-
DS ile bağlantılı branding hakkında düşünmenin bir yolu, bunun ters yönde DS'yi nasıl etkilediğini düşünmektir.
-
Marka görünüm ve hissini hizalamak için tasarım sistemini markaya göre şekillendirmeye başladık.
-
DS ölçeklenebilirlik ve marka kimliği içindir, ancak bu ikisi arasındaki bağlantı branding ekibine göre değişir.
-
Since DS is a language, MKT could support with assets for it;
-
Branding ekibi, temel kuralları oluşturmak için en baştan DS'ye dahil olmalıdır.
-
Şirkete göre değişir. DS, markayı güçlendiren bir araç olduğu için hizalama önemlidir. Bu iki alan arasındaki bağ, DS'nin erişilebilirliğini de etkiler.
-
Stratejiyi hizalamak için branding ekibiyle nasıl senkron kalınacağını bulmak önemlidir.
-
They were used to join projects that the company already had a partner to support with branding, so they would come together with these partners to bring the brand inside the DS;
-
Bazen dokümantasyon ve sistem birlikte kullanılabilir, ama çoğunlukla kullanılamaz. DS bir arayüzdür. Marka ekibinin ayrı bir "branding system"i vardır ve daha yaygın olan, kütüphanelerin birbiriyle etkileşim kurmasıdır. İkisi tamamen aynı şey değildir.
Soru 6. DS'nin başarısı nasıl ölçülebilir?
-
Katılımı, benimsenmeyi ve takımın durumunu anlamaya yönelik algı araştırması
-
Bileşen kapsamı (DS ne kadar kullanılıyor vs ne kadar hard-code ediliyor)
-
Adoption
-
Time to market
-
ROI
-
Figma Analytics
-
Geliştirme ekiplerinin tepkisi
-
Erişilebilirlik
-
Bileşenlerin kullanılma sayısı
1 yorum
Vay, çok güzel. Derleme için teşekkürler!