UX Tasarımda Soft Skills: Hangisi Gerçekten Soft Skill?
UX ilanlarında araç listesinin hemen altına eklenen bir soft skills bölümü var: iletişim, empati, problem çözme, ekip çalışması, tasarım prensiplerine hâkimiyet. Liste neredeyse her yerde aynı sırayla tekrarlanıyor. Peki içindeki maddeler gerçekten aynı cinsten mi?
Soft skill dediğimiz şeyin sınırı nerede?
Tanım kâğıt üstünde net: teknik olmayan, kişiler arası yetkinlikler. Listeye uygulayınca sorun çıkıyor. İletişim kişiler arası, tamam. Empati de öyle. Peki "tasarım prensiplerini anlamak" o listede ne arıyor? Görsel hiyerarşi, bilgi mimarisi, sezgisel arayüz kuralları; bunların hepsi okunarak öğrenilen, seviyesi sınanabilen alan bilgisi. Soft skill sayılmalarının tek sebebi Figma menüsü ezberlemekten farklı olmaları.
Ayrım işe yarıyor, çünkü ikisi bambaşka yollarla gelişiyor. Görsel hiyerarşiyi bir hafta sonu okuyup kavrarsın. Toplantıda seni üçüncü kez yarıda kesen yazılımcıyla nasıl konuşacağını okuyarak kavrayamazsın. İkisini aynı kutuya koyduğunda ikincisi için de "iyi bir kaynak önerir misin" sorusu geliyor, verilecek bir cevap olmuyor.
İletişim: en çok yazılan, en az tarif edilen madde
Her ilanda geçiyor, hiçbirinde ne kastedildiği yazmıyor. UX tarafında iletişimin somut karşılığı birbirinden ayrı üç iş: kullanıcıdan ham veri toplamak, o veriyi geliştiricinin uygulayabileceği bir dile çevirmek, aynı veriyi bütçeyi onaylayacak kişiye anlatmak.
Ortadaki en çok tökezlenen yer. Araştırma bulgusuyla geliştirme talebi arasındaki mesafeyi kapatamayan tasarımcı, bir süre sonra kimsenin açmadığı raporlar yazmaya başlıyor. Birinci ve üçüncü iş için kişilik yardım ediyor; ikincisi tamamen çeviri işi ve pratikle düzeliyor.
Problem çözmek mi, problemi doğru yazmak mı?
Kaynaklar problem çözmeyi beyin fırtınası ve iterasyonla anlatmayı seviyor. Asıl darboğaz daha önce, problemin cümleye döküldüğü anda. "Kullanıcılar sepette takılıyor" ile "kargo ücreti ödeme adımına kadar görünmüyor" aynı gözlemin iki yazımı, ama ikincisi çözümü zaten yarı yarıya söylüyor.
Bir problem tanımının işe yarayıp yaramadığını anlamanın kestirme yolu var:
- Cümlede çözüm ismi geçiyor mu? Geçiyorsa o problem değil, karara dönüşmüş bir tercih.
- Doğru ya da yanlış çıktığını gösterecek bir ölçüt yazabiliyor musun?
- Aynı cümleyi geliştiriciye okuduğunda "peki tam olarak ne olacak" diye soruyor mu?
Kullanıcı görüşmesi gerçekten pratik isteyen kısım
Görüşme, listedeki maddeler arasında ilerlemesi en net ölçülebilen beceri. "Bu ekranı beğendiniz mi" diye soran biriyle "bu ekranda en son ne yaptınız" diye soran biri arasındaki fark, on görüşmeden sonra elde kalan veriye bakınca ortaya çıkıyor. Birincisi nezaket topluyor, ikincisi davranış.
Peki kişi doğru soruyu sorduğu hâlde cevap yüzeysel kalıyorsa? O zaman sorun sorunun kendisinde değil, sessizliğe dayanma süresinde. Görüşmeyi bozan alışkanlık çoğunlukla ilk üç saniyelik boşluğu doldurma isteği oluyor.
Hikâye anlatıcılığı gerçekten şart mı?
Bu madde listelerde hep var ama sağlaması nadiren yapılıyor. İnsanların hikâyeyi tablodan iyi hatırladığı doğru; buradan "her bulguyu anlatıya çevir" sonucu çıkmıyor. Anlatım, karar verecek kişinin veriyle arası iyi değilse işe yarıyor. Karşındaki funnel raporunu senden hızlı okuyorsa storyboard'un onu yavaşlatıyor (persona şablonlarının çoğunu bu yüzden süs buluyorum).
Faydası kesin olan yer kullanıcı yolculuğu. Yolculuk zaten zaman içinde ilerleyen bir dizi olay, yani hikâye biçimine doğal olarak oturuyor. Statik bir arayüz kararını hikâyeye çevirmeye çalışmak ise genelde süsleme.
Peki bunlar nasıl gelişiyor?
Kurs değil, geri bildirim döngüsü. Görüşmelerini kaydet ve bir hafta sonra kendini dinle; yönlendirici sorularını orada duyarsın, o an fark edemezsin. Sunumlarında hangi slaytta soru geldiğini not et, o slayt anlaşılmamış demektir. Yazdığın problem tanımlarını iki ay sonra geri dön oku, kaçının çözümle birlikte doğduğunu görürsün.
Bu üçünün ortak yanı, sonucun sende değil karşı tarafta ölçülmesi. Soft skill'in alan bilgisinden asıl farkı da bu: sınavını sen veremiyorsun.