UX'te İlk Yıl: Neye Vakit Ayırmalı, Neyi Bırakmalı

UX'e yeni başlayanların çoğu ilk altı ayını portfolyo cilalamaya ve araç öğrenmeye harcıyor. İşi asıl zorlaştıran şeyler başka yerde duruyor: iş tarafının kısıtları, kurum içinde itibar, testin takvime bağlanması. Bunlar araç bilgisiyle değil, doğru sırayla çözülüyor.

Bitmemiş tasarımı göstermeyi öğren

Kusursuz arayüz diye bir şey yok, iterasyona dayanan bir süreç var. Bunun pratikteki sonucu şu: ilk sürümde her ekranı çözmeye çalışırsan ilk geri bildirim ancak sen yorulduktan sonra gelir, ve o noktada değiştirilecek şey çok daha fazladır. Yarım kalmış üç ekranı bugün masaya koymak, bitmiş tek akışı iki hafta sonra koymaktan daha hızlı ilerletir.

Aynı mantık önceliklendirmede de geçerli. Bütün sorunları aynı anda çözmeye kalkan bir ekip, hiçbirini bitirmeden sıradaki toplantıya girer.

İş tarafının kısıtını erken sor

Yeni başlayanın en sık yaptığı hata, kullanıcıyı tek muhatap sanmak. Ürünün ayakta kalma şartları tasarımın sınırlarını çiziyor ve bunlar genelde ilk gün söylenmiyor, sorulması gerekiyor.

Geliri reklamdan gelen bir platformda "reklamları kaldıralım" önerisi masadan düşer. Tartışılabilir olan yerleşim, sıklık ve format. Bu üçü üzerinde konuşan bir tasarımcı ciddiye alınır, reklamın varlığını sorgulayan alınmaz.

• Bu ürün parayı nereden kazanıyor?
• Bu çeyrek hangi sayıya bakılıyor?
• Değiştirmeyi önerdiğim ekran o sayının neresinde duruyor?

Güven, sunumla değil teslimle gelir

UX tavsiyelerinde tuhaf bir çelişki var: bir yandan "roadmap'e müdahil ol, stratejiye katıl" deniyor, öbür yandan "kurumda güven zamanla oluşur" deniyor. İkisi aynı anda doğru olamaz. Stratejiye müdahil olmak, önceden kazanılmış itibarın karşılığıdır, başlangıç noktası değil.

Yeni gelen birinin hazırladığı UX strateji sunumunu, iki günde çıkarılmış küçük bir düzeltmeden daha az ikna edici bulurum. Kimsenin dokunmadığı bir hata mesajını düzeltmek, form doğrulamasını anlaşılır hale getirmek, destek ekibine en çok soru gelen ekranı sadeleştirmek. Bunlar görünür ve ölçülebilir; üç ay sonra roadmap toplantısına çağrılmanın sebebi de bu oluyor.

Testi takvime bağla

"Prototipleri erken test edin" cümlesi kimsenin itiraz etmediği, kimsenin de yapmadığı türden. Sebebi belli: takvimi olmayan iş, acil işin altında kalır.

Beş kişiyle her ay yapılan kısa oturum, yılda bir kez yapılan yirmi kişilik büyük çalışmadan daha çok hata yakalar. Büyük çalışma rapor üretir, aylık oturum alışkanlık üretir. Tarihi sprint planına yaz, katılımcı bulma işini kendine değil sabit bir sürece bağla.

Ekipte kim ne istiyor

Empatiyi kullanıcıya saklamanın anlamı yok. Geliştiriciyle çatışmanın sebebi çoğu zaman estetik tercih değil, senin önerinin ona ne kadar iş açtığı. Mentor arayışı da aynı yerden bakar: sana "güzel olmuş" diyen değil, önerinin nerede uygulanamaz olduğunu söyleyen kişi işe yarar.