Mekanikler Çiçek! 🌸 Fakat Sadece Tasarım Sistemi Oluşturmak Yetmez!
Bir önceki yazıda DesignOps süreçlerini nasıl çalıştıramadığımıza dair uzun bir içerik hazırlamıştım. Eğer o yazıyı okumadıysan önce bir oraya uğramanı tavisye ederim. Bu defa ise, teorik seviyede bir süreç nasıl çalıştırılır bunun üzerine bir şeyler söyleyeceğim.
Önsöz
Tüm komponentlerimizi atomik olarak ayırdık. Güzelce kategorize ettik. En ince ayrıntısına kadar düşündük ve çiçek gibi bir kütüphane oluşturduk. Projelerimizi yarattık, kütüphanelerimizi içeriye çağırdık. Artık çalışmaya hazırız!
Gerçekten hazır mıyız? 🤔
Komponentleri dışarıdan çağırdığımız zaman pixel-perfect çıktı üretebiliriz. Peki ya;
- Tasarım sisteminiz gerçekten hazır mı?
- Dokümantasyon konusunda ne yapacaksınız?
- Domain, Kanal, IP, Ürün, Hizmet Ayrıştırması yapıldı mı?
- Atomik elementlerden proje isimlendirmelerine kadar nasıl bir yol izlediniz? Sayfa düzeni ve akışları doğru mu?
- Yayına alınan veya rafa kaldırılan işlerin akıbeti ne durumda?
- Sürüm kontrolü problemini çözdünüz mü?
- Yeni bir tasarımcı ekibe dahil olduğunda, sisteminiz bu tasarımcının oryantasyon sürecine destek olacak şekilde mi oluşturuldu?
- Yeni bir domain, kanal veya geliştirme söz konusu olduğunda, sisteminiz buna uyum sağlayabiliyor mu?
- Tutarlılık ve devamlılık sağlanabiliyor mu?
- Kabartma tozu pastayı ne kadar kabartır?
- Krema nasıl böyle güzel kokar?
- Babam böyle pasta yapmayı nereden öğrendi?
Bu soruların kocaman cevaplara ihtiyacı var. Zira ister tek kişilik dev kadro olun isterseniz de gerçekten dev bir kadroya sahip olun, sadece komponentleri bir kütüphaneye toplayıp, projelerinize dahil ederek sürdürülebilir bir yapı kurmanız imkansız.
Bu içerikte, tasarım ekiplerinin sistemli çalışmakla ilgili düştüğü bu yanılgıyı biraz irdelecek, ardından da neden sadece tasarım sisteminin yetmeyeceğini ve neye ihtiyacımız olduğuna değineceğim.
Giriş — Önce Biraz Nostalji 🍿
Komponent bazlı çalışma sistemleri sanıldığı kadar eski değil. Sembol sistemi, ilk defa Sketch’e geldiğinde (O zamanlar Doğan Online altındaki Nesine’de çalışmaktaydım) şaşırmış ve heyecanlanmıştık.
O zaman birlikte çalıştığım liderim Serkan Urhan ile oturup, uzun süre komponent sisteminin çalışma mantığını çözmeye çalışmıştık ve yeni dünya düzeninin ansızın gelmesiyle birlikte, elimizdeki çöp yığını haline gelmiş tasarım dosyalarını nasıl toparlayacağımızı konuştuğumuzu hatırlıyorum.
Yıl 2016'ydı! Ve dünya, bir günde değişti!
Yıllar içerisinde birçok gelişme, hız kesmeden yaşanmaya devam etti. Her yeni ihtiyaç için yepyeni gelişmeler; yepyeni trendlere ayak uydurduk. Semboller, komponentler, pluginler, kütüphaneler, tasarım kültürü, dokümantasyon, stil kütüphaneleri, tasarım sistemleri, kırılan ve yeni oluşan alt meslek ve unvanlar, eş zamanlı çalışma, bulut tabanlı çalışma ve daha nicesi.
Son zamanlarda ise yeni bir ihtiyaç ve beraberinde yeni söylem ortaya çıktı. Girişimler, teknolojiler, ihtiyaçlar ve ürünler geliştikçe tasarım ekiplerinin de daha proaktif ve daha sistemli çalışması gerekliliği!
Özetle
Ve tüm bu sürecin doğurduğu yeni trend (Ebubekir Sıddık Bebek) DesignOps oldu.
Gelişme — Sistemli Çalışmaya Olan İhtiyaç ⚙️
Yukarıda bir takım sorular sordum ve bu soruların hangi tarihsel süreç içerisinde hayatımıza girdiğini anlattım. Şimdi, bu ihtiyacın çözümüne neden-sonuç ilişkisi kapsamında odaklanalım istiyorum.
Öncelikle akşam ziyafeti için bir malzeme listesine ihtiyacımız var. Bu liste bol bol soru barındırmalı her bir sorunun cevabı çalışma sistemini oluşturmalı.
Sistem’in Çalıştırılması 🔥
Şimdi kısaca bu soruları soralım ve sisteme entegre edelim!
Soru 01 — Tasarım sisteminiz gerçekten hazır mı?
Projenin tasarım sistemi hazır mı? Değil mi?
Son zamanlarda Linkedin’de tasarımcılar arasında bir tartışma başladı ve büyüdü. Kimisi sistemli çalışmanın önemini vurgularken kimisi gereksiz olduğu yönünde fikir beyan etti.
Farklı fikirler ortaya atılabilir elbette ama muhtaç olduğunuz kudret damarlarınızda akan asil kanda mevcut aslında. Yani eğer birden fazla kişinin çalıştığı bir ekibin parçasıysan, tasarım çıktılarını belirli bir sistem ile üretmen kaçınılmaz. Mükemmel olmak zorunda değil, (hangisi mükemmel ki?) fakat bir başlangıca ihtiyacın var. İlk etapta bir sistem bile olması gerekmiyor. (UI kit bile işini görür)
Ancak element, grup ve frame isimlerinden başlayarak en tepede bir tasarım sistemi birlikte çalışmak ve “Empowered” bir takım olabilmek için çok önemli.
Tasarım sistemini oluşturabilmenin birkaç faydasını sıralamak gerekirse:
- Kalabalık ekiplerin birlikte ve uyumlu şekilde çalışabilmeleri için önemlidir.
- Çıktıların yönetilebilir ve sürdürülebilir olmasını sağlar.
- Proje transferi ve handoff süreçlerini kolaylaştırır.
- Onboarding süreçleri kolaylaşır. Projelere dahil olan farklı kişilerin rahat anlamasına ve çalışmasına olanak tanır.
- Odanı derli toplu tutman, hanımından ya da beyinden azar yememeni sağlar.
- Kısacası önemlidir.
Bu sebeptendir ki, atomik tasarım prensiplerine uygun şekilde oluşturulmuş bir tasarım sistemine ihtiyacın olacak. (mükemmel olmasa bile!)
Soru 02 — Dokümantasyon konusunda ne yapacaksınız?
Kutsal Kural Kitabın Hazır mı?
Değilse şimdiden yazmaya başla. Çünkü anayasanın ilk 4 maddesinin tartışmaya açılmaması bir yana senin sürekli gelişen, değişen ve yaşayan bir kural seti bütüne ihtiyacın var. En atomik elementten sayfa düzenine kadar bir dokümantasyon oluşturmak, sistemli çalışmanın en önemli yapı taşlarından birisi.
Tasarım sisteminin zaten hazır olduğunu varsayarsak, şimdi sıra bunu dokümante etmekte. Bunun için izleyebileceğin birkaç yol var.
1- Yazılım geliştiricilerine iyi davranın: Onlara sürekli bir şeyler ısmarla. 🍻☕️ Çünkü ihtiyacın olduğunda dokümantasyon için onlardan yardım alman gerekebilir.
Ancak bu elbette maliyetli bir yol. İnsanları bunun önemi için ikna etmeli, çoğunlukla kısıtlı ve yok denecek kadar az kaynağın buna kanalize olmasını sağlamalısın. Muhtemelen önce dinleyecek sonra hak verecek ancak asla aksiyon için hevesli olmayacaklardır. İşin zor ancak başarabilirsen çok şanslısın.
2- Design System Araçlarına göz atabilirsin: Dokümantasyon için özelleştirilen dikey ürünlere yönelebilirsin. Maliyeti çok düşük ve çoğunlukla kullanımı basit olan bu ürünler, tasarım sistemlerini kolayca dokümante etmek için imkan tanır. Çoğu tasarım sistemlerini parçalara ayırarak cloud base ortamlara ekleyebilmeni ve share etmene olanak tanır.
Bunlar için birkaç örnek vermek gerekirse;
3- İş başa düştüyse, kolları şimdiden sıvamaya başla: Çünkü her iki yoldan da verim alamadığın durumda, bu tarz dokümantasyon süreçlerini kendin ve manuel üretmek durumunda kalabilirsin. Bunun birçok sebebi olabilir. Kaynak yetersizliği. Knowhow eksikliği. “Banane lan ben mi kurtacağım bu şirketi” bakış açısı gibi.
Her neyse. Sistemin dokümantasyonunu yaratman gereken durumlarda kullanabileceğin birkaç araç şu şekilde:
Şirketin Jira kullanıyorsa beraberinde gelen Confluence tam da bu iş için tasarlanmış müthiş araç.
Ya da daha interaktif bir üretim süreci için Framer’ı deneyebilirsin.
Özet: Ürettiğin şey kendi çalıp, kendi oynamasın!
Bu tarz dokümantasyonların en büyük problemi paydaşların sürece dahil edilmemesi ve yaratılan çalışmanın içselleştirilmemesi. Bu yüzden genellikle ürettiğin çıktı, ekip içerisinde heyecan yaratsa da, dış paydaşlar için pek bir şey ifade etmiyor. Sen bir butonun tüm özelliklerini en derine kadar bu dokümantasyon içerisinde anlatsan da geliştirici yine gelip sana sormayı tercih edecektir.
Bu yüzden üreteceğin çıktıyı temas halinde olduğun paydaşlar ile birlikte üretmeyi teklif et. Buna verebilecek en iyi örnek ise şu sıralar çokça popüler (popüler çünkü ben beğeniyorum, o yüzden popüler 😉) olan Atlassian Design.
Atlassian Design içerisinde biraz gezdiğinizde demek istediğim şeyi hızlıca anlayabilirsin. Çünkü kullanılan her atomik elementin development süreçlerindeki karşılığı net bir şekilde anlatılmış. Bu sebeple, yaratacağın dokümatasyonun bu kalitede olması gerekli. Hem faydalılık hem de çıktı kalitesi için olmazsa olmaz.
Soru 03 — Domain, Kanal, IP, Ürün, Hizmet Ayrıştırması yapıldı mı?
Şirket olarak ürün ya da hizmet mi sağlıyorsunuz? Hizmet ve/veya ürünleriniz, kanal, domain, ip, proje olarak ayrıştırılabiliyor mu?
Demek istediğim şu: Getir temelde bir mobil uygulama. Ancak Getir’in içerisinde yer alan her bir hizmet aslında farklı bir domain olarak konumlandırılmakta.
Yani Getir “özünde” bir mobil uygulama olduğu için tüm tasarım ekibi, bütün uygulamayla ilgilenmiyor. İlgilenemez de zaten. İlgilenmemeli. Domain ve kanal bazlı bir ayrıma/ayrışmaya gidilmeli.
Bir başka örneklem üzerinden gidersek: TurkNet temel hedefi internet hizmeti sağlamak olan bir servis sağlayıcısı ve fakat detayda birçok ürün, kanal ve alt hizmeti bünyesinde barındırıyor bu sebeple, ilk yaptığımız şey bunları belirleyip her domaini ve kanalı ayrıştırmak oldu.
Şimdi gelelim sistem üzerindeki etkisine.
TurkNet içerisinde sadece Product Design ekibinin ilgilendiği 10 farklı domain var iskelet yapısı şu şekilde:
İster taş tablete üzerinde çıktı üretin, ister cloud base bir uygulama üzerinde. İster 1 adet ürününüz olsun ister 100, sistemin ilk adımı; ürün, hizmet, kanal ya da adı her ne ise, bunun ayrımını kullandığın araç üzerinde kurgulamalısın.
Soru 04 — Atomik elementlerden proje isimlendirmelerine kadar nasıl bir yol izlediniz? Sayfa düzeni ve akışları doğru mu?
Tertipli çalışmanın verdiği dayanılmaz hafiflik!
Elbette burada konu sadece tertipli çalışıyor olmak değil. Bir bütünün parçası olarak düşünerek hareket etmeliyiz ve tüm süreci kurgulamalıyız. Gitmek istediğimiz nokta bir üretim bandı olmalı ve her üretim bandının belirli standartları olmalı.
Bu sebeple kendine şu soruları sor:
- Çıktılar, projeler, frameler, objeler nasıl isimlendirilecek? Türkçe mi? Yoksa İngilizce mi?
- İsimlendirmeler hangi kural seti ile verilecek?
- Peki ya numaralandırma? Ne mi gerek var? 😊
- Ekranların sıralaması nasıl olmalı? Akışa göre mi? Belirli bir senaryoya göre mi?
- Çıktılarınızın responsive ya da farklı boyutları nerede ve nasıl konumlandırılacak?
Elbette bu soruların net bir cevabı yok. Hatta sorular çoğaltılabilir. Fakat bunlar sadece soru olarak kalmamalı, aynı zamanda cevapları çalışma sistemine uyarlamalısın.
Bu sorulara sırayla cevap vermek gerekirse izlediğim yol şu şekilde:
- Sayfa ve proje, frame ve obje isimlendirmelerini İngilizce olarak set ediyorum. Bugün değil ama yarın ekibinizde veya geliştiricileriniz arasında global ya da expat çalışanlar olabilir, olacaktır. Eliniz ağrımayacaktır. Yapın. 🤓
- Tüm çıktıları bakan kişinin belirli bir korelasyon kurabileceği ve ihtiva ettikleri içeriğe göre isimlendiriyorum.
Örneğin o ekran AMEX kredi kartları ile ödeme yapıldığını anlatıyorsa: ismini de bakan kişinin rahatça okuyup anlayacağı şekilde veriyorum.
- Hem domainleri hem projeleri hem de çıktıları belirli bir kural setine göre numaralandırmak önemli.
Bu metot tüm paydaşların aynı dili konuşması adına çok önemli. Çıktılarının da aynı şekilde numaralandırmsı belirli bir akış ve sıraya sokmak için iyi bir yol.
Burada özellikle dikkat edilmesi gereken bir konu var. Çıktıları numaralandırken detaycı olmaktan kaçınmalısın. Yani çıktılara asla 19.04.01 gibi ip benzeri bir numaralar vermemelisin (Userspots’a selam olsun! 😇) Kırılım olarak her zaman ve maksimum 0.0 şeklinde bir düzenle ilerlemek çok daha yönetilebilir ve anlaşılabilir.
- Burada ekranları senaryo ve bağlama göre kategorize edip basit numaralandırma yoluna gidebilirsin.
Örneğin kredi kartı ile ödemeyi ilgilendiren tüm ekranlarım tek bir yerde toplanırken Papara ile ödemeyi bir başka section (alan) içerisinde toplanmalı.
- Ve gelelim son sorunun cevabına. Çıktıların tüm boyutlarını aynı yerde tutmaya özen göster. (Burada farklı yollarda izlenebilir elbette)
Örneğin üzerinde çalıştığın bir projen var ve projenin desktop versiyonlarını bir dosyada ve responsive hallerini ise düzenli olması adına başka bir dosyada çalışabilirsin.
Ancak hem paydaşlarla iş geliştirme süreçlerini kolay yönetebilmek hem de çıktıları üretirken tutarlılığı sağlamak adına tüm boyutları aynı yerde konumlandırman önemli.
Soru 05 —Yayına alınan veya rafa kaldırılan işlerin akıbeti ne durumda?
“Ben revize yapmam!” diyenlerden misin? Türk iş kültürüne selam olsun. 😎
Son birkaç yılda çalıştığım ya da destek verdiğim kurumsal şirketlerde duyduğum iki ilginç söylem var.
“Kök Neden Tespiti”
“Etki Analizi”
Bu iki söylemi sık duyuyorsan geçmiş olsun. 😵💫 Çalıştığın firmada işler o kadarda planlı programlı yürümüyor demektir. Dolayısıyla bu aşamada da gardını alman ve çalışma sistemini buna göre kurgulaman gerek.
Çalışma hayatın boyunca, yayına giren ya da uzun zamanlar üzerinde çalıştıktan sonra “etki analizi” doğru yapılmadığı için daha sonra muhakkak “kök neden testpiti” yapmak gerektiğine dair cümleler duyarak rafa kaldırılan işler birbirini takip etmeye ve birikmeye başlayacak.
Özellikle proje iptallerini engellemek adına ne yapılması gerektiği konusu bu yazının odak noktası olmadığı için bu kısmı geçelim ve bu problemin sistem içerisinde nasıl eğitebileceği üzerine duralım.
Tam bu noktada yine bir ayrıma gitmemiz gerekiyor. Projeleri domain bazlı ayırmıştık. Peki depolarken ne yapmalıyız? Biz ne mi yapıyoruz? Şöyle yapıyoruz.👇
Burada gördüğün şey şu aslında:
- 2️⃣ 02 — Domain ayrıştırması yapıldı ve her domaine bir numara set edildi. (Tüm paydaşlar 02 numaraları işlerin bu domaine ait işler olduğunu biliyor, bilmeli)
- 🖼️ Domain’e uygun bir thumbnail oluşturulur.
- 🟦 Devam eden işler ayrıştırılır.
- ✅ Tamamlanan işler ayrıştırılır.
- ☠️ Rafa kaldırılan (ölen) işler ayrıştırılır.
- 🥶 Ötelenen işler ayrıştırılır.
- ⌛️ Çeşitli sebeplerle bloklanan işler ayrıştırılır.
- 🏴☠️ İnsiyatif alınarak yapılan özel işler ayrıştırılır.
- 👑 Production yani yayında olan en güncel ekranların toplandığı proje dosyası oluşturulur ve güncel tutulur.
Çok detay gibi görünüyor değil mi? Evet öyle. 👊
Soru 05 — Sürüm kontrolü problemini çözdünüz mü?
Burası gerçekten çokomelli.
Gelelim en can alıcı bölüme. Eğer ciddi bir organizasyonun içerisindeysen sürüm kontrolü yapman gerekiyor. Ve fakat burada bahsi geçen sürüm kontrolü Figma, Sketch ya da benzer uygulamalarda yer alan Version History özelliği değil.
Burada bizim izlediğimiz yol tam olarak şu: Tüm geliştirmeleri farklı projeler üzerinde çalışıyoruz. Proje yayına alınana kadar içerisinde yer alan ve alacak olan hiçbir atomik elementi tasarım sistemine dahil etmiyoruz.
Geliştirme yayına alındıktan sonra geliştirme içerisinde yer alan atomik elementleri tasarım sistemine aktarıyor ve geriye dönük proje içerisindeki ilgili alanları sisteme aktarıp ardından da buradan tekrar ve geriye dönük besleyerek son haline getiriyoruz.
Ardından da proje içerisinde yer alan tüm çıktıları en güncel çıktıları topluyor tek ve eşsiz bir dosya olan 👑 02 — All Currently Pages isimli çalışmaya taşıyoruz. Buraya dikkat. 👑 02 — All Currently Pages sadece production’a çıkan işlerin toplandığı en güncel çıktıları barındıran dosya.
👑 02 — All Currently Pages’e aktardıktan sonra geliştirme artık v1.0 olarak konumlandırıldı. Projenin bir sonraki fazı ise v2.0 ve bu tekrar çalışma yapıldığında yukarıdaki süreç başa dönüyor. Günün sonunda ise çıkan tablo şu şekilde:
Cümleyi toparlayayım: Bir proje her zaman kendi dosyası içerisinde tüm boyutlarıyla çalışılır. Proje her defasında versiyonlara ayrılır ve en son hali 👑 02 — All Currently Pages’e aktarılır. Proje içerisinde oluşturulan atomik elementler en sonunda sisteme aktarılır ve daha sonraki sürüm sistemden beslenir.
Bu meşakkatli yöntem eminim bir sonraki Figma Config’de çözülecek problemlerden biri. Yazılım geliştirme dünyasında yer alan sürüm ciddiyetinin bizim dünyamıza da gelmesi kaçınılmaz. O zamana kadar sürüm kontrolü çözmeniz gereken önemli bir konu.
Soru 06 — Yeni bir tasarımcı ekibe dahil olduğunda, sisteminiz bu tasarımcının oryantasyon sürecine destek olacak şekilde mi oluşturuldu?
Hımm gerek var mı? Yeni gelen ekip arkadaşımıza “buddy” atıyoruz o her şeyi anlatıyor!
Burası için şöyle güzel bir örnek verelim. 👇
Çok büyük firmalar özellikle de pendemi sonrası büyük bir problem olmaya başlayan uzun ve gereksiz toplantı sorununu aşmak için çeşitli yollara başvuruyor.
Peki biz bu durumun neresinde konumlanıyoruz?
Elbette her yeni gelen çalışana destek olan biri assign edilebilir ve edilmeli. Bunda bir problem yok ancak bu süreci üretim bandının bir parçası haline getirip, çalışma sistemine entegre edebilirsin. Yukarıda anlatılan her şeyi yeni ekip arkadaşının kendi kendine öğrenmesini sağlayabilirsin.
Bunun için yapman gereken tek şey yukarıdaki süreci özetleyen basit bir dokümantasyon oluşturmak. Neye mi benzeyecek?
Burada şöyle bir yol izlemek önemli. Bu yarattığın basit dokümantasyonu sistemin içerisine entegre etmeli ve oluşturduğun her projeye otomatik olarak eklenmesini sağlamalısın. Böylelikle ister yeni ekip arkadaşınla istersen de diğer paydaşların birçok sorusunu rahatlıkla cevaplayabilirsin.
İşte bu kadar! 👊
Sonuç — Diğer Sorular ve İmparator Penguenlerin Yükselişi 🐧
Ne kadar uzadı değil mi? Kısa olacağını söylememiştim zaten. 😑 Bu yazıda bahsettiklerim aslında buzdağının kısacık bir özeti gibi. Bu süreçler aylar hatta yıllar alacaktır. Ve asla mükemmel olmayacaktır. (Getir’de çalışırken bu sürecin 2 ayda tamamlanıp tamamlanmayacağı sorulmuştu. Ahhh, ah! Ahir zaman! 🤓)
Üzerine çokça konuşulabilecek, tartışılabilecek, geliştirilebilecek bir konu bu. Ve kesinlikle taşa yazılı kurallar bütünü değiller. Bu sistemli çalışma anlatısı senin çalışma biçimine, ekibinin yapısına ve iş yapış şekline göre çok hantal ya da masalsı kaçabilir.
Fakat tek bir doğru varsa o da, o ya da bu şekilde bir sisteme ihtiyacın/ız olduğu. Aksi halde sadece maaş almak için çalışan biri veya vasat çıktılar üreten bir ekip olmaktan öteye geçemezsiniz.
Tutarlılığı ve sürdürülebilirliği sağlamak, sürekli gelişim yolları aramak ve en önemlisi de işinizi ciddiye almak için hemen aksiyon almaya başla.
Yukarıda yazılanlar ilgini çektiyse ve fakat yetmediyse aşağıdaki DesignOps Handbook isimli ücretsiz e-book’a göz atmanı tavsiye ederim!
Bonus:
- Kabartma tozu pastayı ne kadar kabartır?
- Krema nasıl böyle güzel kokar?
- Babam böyle pasta yapmayı nereden öğrendi?
