DesignOps Ne Zaman Gerekir, Ne Zaman Fazladan Katman

DesignOps genelde süreç kaosunu çözen bir çatı olarak anlatılır. Oysa çoğu ekipte yaşanan şey süreç eksikliği değil, kararı kimin vereceğinin belli olmaması; buna iş akışı şeması yazarak çözüm bulunmuyor. DesignOps'un gerçek karşılığı daha dar bir yerde duruyor: tasarımcının üzerindeki idari yükü başka birine devretmek ve o devrin hesabını tutmak.

Süreç mi eksik, sahip mi?

Bir tasarım ekibinde işler tıkandığında ilk refleks akışı belgelemek olur. Belge çıkar, kimse okumaz, tıkanıklık yerinde kalır. Çünkü asıl soru çoğunlukla "bu adımdan sonra ne olacak" değil, "bu ekranı onaylama yetkisi kimde" sorusudur.

Ayrımı görmek kolay. Aynı iş iki kez farklı sırayla yapılıyorsa süreç eksiktir. Aynı iş, sırası belliyken haftalarca bekliyorsa süreç değil karar sahibi eksiktir. İkincisine DesignOps kurmak, bekleyen işin üstüne bir de takip toplantısı eklemek demek.

Ayrı bir rol ne zaman kendini ödüyor

Lisans yönetimi, dosya düzeni, varlık arşivi, araç kurulumu: bunlar gerçek işler ve birinin zamanını yiyor. Soru bu işlerin var olup olmadığı değil, ayrı bir kişiyi besleyecek kadar olup olmadığı.

Hesap basit. Diyelim her tasarımcı haftada 2 saatini bu tür idari işe veriyor. Tam zamanlı bir DesignOps rolü haftada 40 saat tutuyor. 40 / 2 = 20; yani o rolün kendini salt zaman tasarrufundan ödemesi için yirmi kişilik bir tasarım ekibi gerekiyor. Altı kişilik bir ekipte toplam yük haftada 12 saat, bu da tam bir pozisyon değil, mevcut birinin takviminde ayrılmış bir dilim.

Hesabın kırıldığı tek yer, idari yükün tasarımcıyı sadece yavaşlatmakla kalmayıp yanlış karar verdirdiği durumlar: eski bir dosyanın üstüne çalışmak, güncelliğini yitirmiş bir bileşeni kopyalamak. O zaman kaybedilen 2 saat değil, yeniden yapılan iş oluyor ve eşik aşağı iner. Ama bunu varsayılan kabul etmek yerine ölçmek gerekir, yoksa her ekip kendini yirmi kişilikmiş gibi davranmaya ikna eder.

Standart dokümanda mı duruyor, üründe mi

Standartlaştırma DesignOps anlatısının en çok tekrarlanan kısmı, en az denetlenen kısmı da o. Bir kütüphane dosyası, bir stil rehberi ve bir dokümantasyon sayfası olması, ürünün o standarda uyduğu anlamına gelmiyor.

Bunu anlamanın kısa bir yolu var: kütüphanedeki bir bileşenin dolgu değerini ya da rengini değiştir, sonra üründe kaç yerin kırıldığına bak. Birkaç yer kırılıyorsa standart gerçekten bağlı. Hiçbir yer kırılmıyorsa o bileşen üründe kopyalanarak çoğaltılmış, standart da yalnızca dokümanda duruyor. Aynı test kodda da işler: bir tasarım token'ını değiştirip derlemenin ne kadar yerinden ses geldiğine bakmak, on sayfalık uyum raporundan daha çok şey söyler.

Bu kontrolü yapmayan ekiplerde "tasarım sistemimiz var" cümlesi genelde "tasarım sistemi dosyamız var" demektir. İkisi arasındaki fark, DesignOps yatırımının işe yarayıp yaramadığını belirleyen farktır.

Standardın zarar verdiği yer

Tekrarlanabilirlik üretim aşamasında iyidir. Keşif aşamasında maliyeti var. Bir akışın üç farklı kurgusunu denemek, tanımı gereği standart dışıdır; her denemeyi onay zincirinden geçirmeye kalkarsan deneme sayısı düşer ve ekip ilk akla geleni savunmaya başlar.

Pratik ayrım, işin geri alınabilirliğinde. Atılan adım kolay geri alınıyorsa (bir eskiz, bir prototip, bir kullanılabilirlik oturumu) süreci hafif tut, kimseye sormadan yapılsın. Geri alınması pahalıysa (yayına giden bir bileşen, veri modelini etkileyen bir karar) oraya kontrol koy. Çoğu DesignOps kurulumu bu ikisini aynı şablona sokar, sonuçta pahalı kararlar hızlı, ucuz denemeler yavaş akar.

Dokümantasyon çürür

Belgelenen süreçlerin bakım maliyeti genelde hiç konuşulmuyor. Altı ay güncellenmeyen bir onboarding dokümanı yeni gelen kişiyi hızlandırmıyor, yanlış yere gönderiyor; eski araç adı, kapanmış bir kanal, taşınmış bir klasör. Yanlış belge, belge olmamasından daha yavaş çalışır, çünkü güvenilir sanılıyor.

İşleyen çözüm, dokümanı kullanıldığı yere yaklaştırmak. Bileşen açıklaması bileşenin yanında, kurulum adımları depo içinde, karar gerekçesi o kararın alındığı biletin içinde dursun. Ayrı bir bilgi tabanı kurmak cazip görünür ama ayrı duran her sayfa, güncellenmeyi ayrıca hatırlanması gereken bir yer demek.

DesignOps'a değer kazandıran şey, tasarımın organizasyon içinde yaygınlaşması gibi geniş iddialar değil. Ölçülebilir iki şey: tasarımcı başına haftada kaç saat idari işten kurtuluyor, ve kütüphanedeki değişiklik üründe gerçekten karşılık buluyor mu. Bu ikisi yoksa kurulan şey tasarım operasyonu değil, tasarımın üstüne eklenmiş bir yönetim katmanıdır.