UX Ekibi Kime Raporlamalı? Merkezî, Dağınık ve Matris Yapılar

UX ekibinin kime raporladığı tartışması genelde üç isimle kapanır: merkezî, dağınık, matris. Oysa şema, tasarımcının işini belirleyen şeyin kendisi değil. Asıl mesele, sprint planında kapsam kesilirken kimin ne dediği ve tasarımcının o odada oturup oturmadığı.

Modeller kısaca

• Merkezî: tüm tasarımcılar tek bir UX yöneticisine bağlı, projelere dışarıdan girip çıkarlar.
• Dağınık: her ürün ekibinin kendi tasarımcısı var, bağlı olduğu kişi ürün yöneticisi.
• Matris: tasarımcı ürün ekibinde oturur, mesleki olarak UX yöneticisine bağlıdır.

Üç tanımın ortak yanı, hiçbirinin tasarımcının haftalık önceliğini kimin belirlediğini açıkça söylememesi. Fark tam orada çıkıyor.

Merkezî yapı: uzmanlık var, yetki yok

Merkezî yapının klasik savunması bilgi birikimidir: araştırma yöntemi, tasarım dili ve geçmiş bulgular tek yerde toplanır, yeni gelen sıfırdan başlamaz. Bu kısmı doğru. Karşılığında tasarımcı, çalıştığı ürünün takvimine dahil olmayan bir dış kaynağa dönüşür.

Sprint ortasında kapsam kesildiğinde çoğu zaman haber bile edilmez, çünkü teslim edeli iki hafta olmuştur ve artık başka bir ekiptedir. Bu soruna sık önerilen çözüm daha iyi dokümantasyon. Şüpheliyim. Doküman, kararın alındığı toplantıya çağrılmamanın telafisi değil.

Dağınık yapı: yakınlık var, tutarlılık yok

Tasarımcı ürün ekibinin içinde oturduğunda ürün bilgisi birikir, kararlar erken alınır, kimse kimseyi ikna etmek için bütçe toplantısı beklemez. Bedeli tutarlılıkta ödenir.

Sekiz ürün ekibiniz varsa ve tutarlılığı ekiplerin birbiriyle konuşmasına bırakıyorsanız, canlı tutmanız gereken ikili ilişki sayısı 8×7/2, yani 28. Ekip sayısı arttıkça bu sayı karesel büyür; haftalık senkron toplantısı da çözmez, sadece herkesin takvimini doldurur.

Tek gerçek çözüm ortak bir referans. Ortak referansı yazılı yönergeye bağlamam: kurumsal wiki'de duran "buton kullanım ilkeleri" sayfasına kimse ikinci kez bakmıyor. Paylaşılan şey kod olmalı. Sürüm numarası olan, projeye bağımlılık olarak eklenen bir bileşen kütüphanesi. Yönergeye uymamak bedava, kütüphaneyi ezmek için fazladan CSS yazmak gerekir.

Matris: iki yönetici, tek takvim

Matris, iki modelin iyi yanlarını birleştirme iddiasıyla anlatılır. Pratikte birleştirdiği şey iki takvimdir. Tasarımcının bu haftaki işini ürün yöneticisi belirler, performans değerlendirmesini UX yöneticisi yazar. İkisi çatıştığında kazananı org şeması belirlemez, bütçeyi tutan taraf belirler.

Yine de çalışır, bir koşulla: mesleki bağın gerçek bir karşılığı olmalı. Tasarım incelemesi, işe alma kararı, kariyer görüşmesi. Bunlar UX yöneticisinde değilse elinizdeki yapı matris değil, üstüne matris yazılmış dağınık modeldir.

Seçim ölçütü ekip sayısı değil

"Küçükken merkezî başla, büyüyünce matrise geç" tavsiyesi şirket büyüklüğünü tek değişken sayıyor. Daha işe yarar bir ölçüt var: ürün kararlarının gerçekte nerede alındığına bakın.

Kapsamı ekip liderleri kendi içinde kesiyorsa, tasarımcıyı o odanın dışında tutan her yapı geç kalır; dağınık ya da düzgün kurulmuş bir matris işinizi görür. Kararlar yukarıda tek noktada toplanıyorsa merkezî ekip zaten o noktaya daha yakın oturur ve orada kalması daha doğru. Olgunluk düzeyi, ekip sayısı, sektör; bunların hepsi bu sorunun yanında ikincil.

Model değiştirmeden önce cevaplanacak soru şu: son üç ayda iptal edilen ya da yarıda kesilen tasarım işlerini kim kesti, hangi toplantıda? O toplantının katılımcı listesi, yeni şemayı sizden daha iyi biliyor.