DesignOps'a Başlarken: Nereden Başlanır, Ne Ölçülür
DesignOps, tasarımcının tasarım dışında harcadığı zamanı geri alma işidir: araç dağınıklığı, tekrar eden elle işler, bir kararın üründe görünmesine kadar geçen bekleme. Standart başlangıç tarifi anket yapmak, herkesle birebir görüşmek ve tüm süreçleri belgelemek şeklinde anlatılır. Bu tarif otuz kişilik bir tasarım organizasyonunda mantıklı, altı kişilik bir ekipte zaman kaybı.
Önce şu soru: gerçekten gerekiyor mu
DesignOps'un ayrı bir rol olarak anlamlı hale geldiği eşik, koordinasyonun işin kendisini geçtiği andır. Tasarımcı gününün yarısını dosya arayarak, aynı bileşeni üçüncü kez çizerek ya da “bu ekran canlıda hangi hâlde” diye sorarak geçiriyorsa sorun görünür olmuştur. Bunun altındaki ekiplerde sorun genelde süreç değil kapasite olur, ve kapasite sorununa süreç eklemek durumu ağırlaştırır.
Tasarım ekibinin verimsizliği çoğu zaman tasarım ekibinin içinde de doğmaz. Kararların onay için haftalarca beklemesi bir DesignOps sorunu gibi görünür, oysa karar verecek kişinin belli olmaması yönetim sorunudur. Yanlış yerde çözüm aramak, yeni bir tören katmanı üretir.
Araştırma turu tuzağı
Anket, birebir görüşmeler, süreç envanteri: bunların toplamı rahatlıkla üç haftayı bulur ve sonunda elinizde bir sunum olur. Ekip o üç hafta boyunca aynı sıkıntıyla çalışmaya devam eder, ilk izlenim de “DesignOps toplantı demek” olur.
Alternatif daha az zarif ama daha hızlı işliyor. Ekibin en çok şikâyet ettiği tek işi al, bir hafta içinde ortadan kaldır, sonucu göster. Güvenilirlik böyle birikir. Envanter çıkarmak için hâlâ vaktiniz olur, üstelik o zaman neyi aradığınızı bilerek çıkarırsınız.
Ölçüm: hangi sayı bir şey söyler
Sık önerilen ölçütlerden biri çalışan devir oranı. Sekiz kişilik bir ekipte tek bir ayrılık yüzde 12,5 eder; ikinci ayrılık yüzde 25. Bu büyüklükte devir oranı, gürültüyü sinyalden ayıramaz, üstelik aylarca geriden gelir. Bir DesignOps girişiminin işe yarayıp yaramadığını ondan öğrenemezsiniz.
Ölçmeye değer olanlar daha sıkıcı ve daha yakın: bir tasarım kararının verildiği tarih ile canlıda göründüğü tarih arasındaki gün sayısı, aynı işlevin kaç ayrı yerde yeniden çizildiği, bir tasarımcının haftada kaç saatini onay beklemekle geçirdiği. Üçü de takvimden ve depodan okunur, ankete gerek kalmaz.
Tasarım sistemi dosyada değil, kodda yaşar
Tasarım sisteminin başarısı genellikle farkındalıkla ölçülüyor: ekip sistemi biliyor mu, kullanıyor mu, memnun mu? Bu soruların cevabı iyi çıkarken üründe on farklı buton varyantının durması gayet mümkün. Gerçek gösterge kodda: ekranların kaçı ortak kütüphaneden geliyor, kaç tane yerel kopya var, bir renk değişikliği kaç dosyaya dokunmayı gerektiriyor. Bunlar depoda aranıp sayılabilen şeyler (farkındalık anketini ölçüm saymıyorum).
Buradaki asıl mesele maliyet. Figma'da bir bileşeni değiştirmek beş dakika, o değişikliğin otuz ekranda karşılığını üretmek iki gün olabiliyor. Tasarım tarafının bu farkı bilmeden yaptığı “küçük” talepler, geliştirme tarafında DesignOps'un çözmeye çalıştığı darboğazın kendisini üretir. İki tarafın aynı numaraya bakması, çoğu süreç iyileştirmesinden daha etkili.
Ne zaman durmak gerekir
DesignOps kendi kendini besleyen bir işe dönüşebilir: şablonlar, ritüeller, ölçüm panoları, panoları güncelleyen toplantılar. Sağlaması kolay. Her yeni sürecin karşısına, kaldırdığı elle işi yaz. Karşılığı boş kalan süreç, çözdüğünden fazlasını götürüyordur.