Tasarım ekibine Design Ops fonksiyonu kazandırmak

Design Ops neyi çözer, neyi çözmez?

Design Ops, tasarım ekibinin işini yapmasını kolaylaştıran sistemlerin, süreçlerin ve araçların yönetimidir. Tasarım kararlarının kendisi tasarımcının işidir; Design Ops bu kararların daha az sürtünmeyle, daha tutarlı ve daha hızlı alınmasını ve hayata geçirilmesini sağlayan zemini hazırlar.

Tipik sorunlar bellidir: tasarım dosyaları dağınıktır, sürümler karışır, her tasarımcı kendi yöntemiyle çalışır, geliştirmeye devir her seferinde yeniden anlatılır, tasarım sistemi bakımsız kalır, yeni gelen biri ekibin çalışma biçimini öğrenmekte zorlanır. Bunlar tasarım kalitesi sorunu gibi görünür ama çoğu zaman operasyon sorunudur.

Design Ops tasarım stratejisinin yerine geçmez, tasarım yönetiminin de yerini almaz. Ürün yönünü belirlemez; ekibin kapasitesini, ortak altyapısını ve çalışma ritmini yönetir. Bu sınırı en baştan netleştirmek, fonksiyonun kendi değerini kanıtlayabilmesi için önemlidir.

İlk adım: mevcut durumu teşhis edin

Fonksiyonu kurmadan önce sorunu ölçün; yoksa çözümü kime ve neye göre uyarlayacağınızı bilemezsiniz. Teşhis şu kaynaklardan beslenir: tasarımcılarla yapılan görüşmeler, gerçek iş akışının gözlemi ve ekibin mevcut çıktıları.

Görüşmelerde şunları sorun: Bir tasarım işi başladığında ilk ne yaparsınız? Geliştirmeye devrederken ne sıklıkla geri dönüş alırsınız? En çok zaman kaybettiğiniz anlar nelerdir? Gözlemde ise bir işin brifinden yayına kadar izlediği yolu çıkarın: kim, hangi araçta, hangi çıktıyı kime veriyor?

Çıktı olarak bir sürtünme haritası hazırlayın: sorunlar, etkilenen kişiler, sıklık ve tahmini etki. Bu harita hem önceliklendirmeye hem de yönetime sunulacak gerekçeye temel olur. İlk hedef her şeyi düzeltmek değil, en çok zaman kaybettiren birkaç noktayı seçmektir.

Araç zinciri ve tasarım altyapısı

Araç zinciri, tasarımın fikirden yayına uzanan yolundaki araçların birbirine bağlanmış halidir. Bir ekip genellikle şu katmanlarla karşılaşır: tasarım aracı, prototip ve geri bildirim aracı, proje ve iş takip aracı, tasarım sistemi ve bileşen kütüphanesi, geliştirmeye devir ortamı, araştırma ve içgörü deposu.

Design Ops'un işi yeni araç eklemek değil, mevcut araçların neden orada olduğunu, kimin neyi nerede bulacağını ve bilginin araçlar arasında nasıl aktığını yönetmektir. Pratik adımlar: dosya ve proje yapısı için tek bir adlandırma ve klasör standardı belirlemek, erişim ve lisans yönetimini merkezileştirmek, şablonlar sunmak, yeni araç taleplerini gerekçeli bir değerlendirme akışından geçirmek.

Araç seçerken ekibin işine bakın, popülerliğe değil. Bir aracın ekibe sağladığı faydayı, öğrenme eğrisini ve geliştirme tarafıyla uyumunu birlikte değerlendirin.

Süreç, ritim ve ritüeller

Süreç, işin hangi adımlardan geçtiğini; ritim, bunların hangi sıklıkla gerçekleştiğini; ritüeller ise ekibin düzenli bir araya geldiği alışkanlık haline gelmiş toplantıları ifade eder. Ekibin büyüklüğü arttıkça bunlar yazılı hale gelmediğinde herkes farklı çalışır.

Başlangıç için işe yarayan ritüeller: düzenli tasarım eleştirisi (bir işi erken aşamada ekibe göstermek), tasarım-geliştirme devri öncesi ortak inceleme, ekip genelinde çalışma paylaşımı, tasarım sistemine katkı ve talep görüşmeleri, geriye dönük değerlendirme.

Bir ritüel ekibe bilgi sağlamıyorsa kaldırın. Design Ops'un sınavı, ritüelleri artırmak değil, tasarımcıların toplantıda geçirdiği süreyi gerçek faydaya göre ayarlamaktır. Yeni bir ritüeli önce küçük bir ekipte deneyin, geri bildirim alın, sonra yaygınlaştırın.

Tasarım sistemi ve kaynak yönetimi operasyonu

Tasarım sistemi bir kez yapılıp biten bir ürün değildir; bakım gerektiren yaşayan bir kaynaktır. Design Ops burada sistemin kendisini tasarlamaz, yönetimini üstlenir: katkı alma ve onaylama akışı, sürüm ve değişiklik duyuruları, belgelendirme, eski bileşenlerin emekliye ayrılması, tasarım ve kod tarafının eşleşmesinin kontrolü.

Kaynak yönetimi ise ekibin insan ve zaman kapasitesidir. İş dağılımı, tasarımcıların hangi projelerde çalıştığı, dış kaynak ya da freelance ihtiyaçları, işe alım sürecinde tasarım becerisi değerlendirmesi ve yeni gelenin uyum süreci bu başlığın içindedir.

Bu alanda iyi bir başlangıç, bir kapasite görünürlüğü sağlamaktır: hangi iş kimde, ne kadarı belirsiz, neler bekliyor. Kapasite görünür olmadan önceliklendirme tartışması hep hissiyatla yürür.

Ölçüm, olgunluk ve kurumsallaşma

Design Ops'un değeri doğrudan görünmez; çünkü iyi çalıştığında sorunlar çıkmaz. Bu yüzden başlangıçta hangi göstergelerle başarıyı izleyeceğinizi belirleyin. Örnekler: tasarım-geliştirme devrinde geri dönüş sıklığı, yeni bir tasarımcının ekibe uyum süresi, tasarım sistemi bileşenlerinin ürünlerde kullanım düzeyi, tasarımcıların araçlarla ilgili memnuniyeti, brifin yayına ulaşma süresi.

Her göstergeyi önce mevcut durumda ölçün; fonksiyon kurulduktan sonraki değişim ancak böyle anlam taşır. Olgunluk için basit bir yaklaşım yeterlidir: dağınık çalışan ekipten, bireysel yöntemleri paylaşan ekibe, ortak standartlı ekibe ve nihayet kendini sürekli iyileştiren ekibe doğru ilerleyen bir skala.

Kurumsallaşma, fonksiyonun bir kişinin kişisel çabası olmaktan çıkıp belgelenmiş uygulamalara dönüşmesidir. Rol tanımı, sorumluluklar, karar hakları ve bütçe gibi başlıklar yöneticiyle açıkça yazılmalıdır.

Mindset'te Design Ops

Mindset'in Design Ops: Tasarım Operasyonları Fonksiyonu Kurma programı, fonksiyonun kapsamından başlayıp mevcut durum teşhisi, araç zinciri, süreç ve ritüeller, tasarım sistemi operasyonu ve ölçüm ile kurumsallaşma başlıklarını ele alır. Tasarım ekibi büyüyen ya da ürün sayısı arttıkça dağınıklıkla karşılaşan şirketlerde tasarım yöneticileri, tasarım lideri adayları ve ürün organizasyonunda operasyonel sorumluluk üstlenenler için uygundur.

Modül sırası kurulum mantığını izler: önce teşhis, sonra altyapı, sonra süreç, en sonda ölçüm; böylece ölçülemeyen bir şeyi kurmadan önce nerede durduğunuzu görürsünüz. Kurumsal ekipler kendi tasarım organizasyonlarındaki sürtünme noktalarını teşhis modülüne taşıyıp programı çalışma zemini olarak kullanabilir.