UX Teslimatları: Hangi Belge Hangi Kitleye

UX teslimatlarının çoğu, üretildiği toplantıdan sonra kimsenin açmadığı dosyalara dönüşür. Sorun belgenin türünde değil, kimin için hazırlandığının belirsiz olmasında. Aşağıda hangi çıktının hangi kitlede işe yaradığı, hangisinin bakım borcu bıraktığı var.

Kitleyi seç, sonra formatı

Belgeyi hazırlamaya başlamadan önce cevaplanacak tek soru var: bunu okuyan kişi hangi kararı verecek? Karar yoksa belge de gerekmiyor demektir.

Yönetim

Yöneticinin ihtiyacı gerekçedir. Kullanılabilirlik testi raporu, üzerinde tıklanabilen bir prototiple birlikte gittiğinde işe yarar: iddia ve iddianın kanıtı yan yana durur. Renk ve tipografi seçimlerini anlatan sunum ise bu masada zaman kaybıdır, çünkü orada verilecek karar "yapalım mı" sorusudur.

Müşteri

Statik wireframe'i müşteri toplantısına götürmem. Teknik olmayan bir izleyici gri kutuları eksik iş olarak okur ve tartışma tasarımın kendisi yerine görselin bitmemişliğine kayar. Aynı akışı düşük çözünürlükte de olsa tıklanabilir hale getirin, konuşma anında içeriğe döner.

Geliştirici

Geliştiriciye lazım olan boş durumlar, hata durumları ve sınır değerlerdir. Mutlu yolu gösteren pixel-perfect ekran, listenin boş geldiği ya da başlığın 200 karakter olduğu durumu anlatmadığı sürece eksiktir. Akış diyagramı ve durum listesi burada mockup'tan daha çok iş görür.

Prototipin görünmeyen maliyeti

"Prototip her kitlede en etkili format" tespiti doğru ama yarım. Etkili olmasının nedeni ürüne en çok benzemesi; ürüne en çok benzeyen belge de ürün değiştiğinde en hızlı yanlışa düşen belgedir.

Wireframe ucuzdur çünkü atılmak üzere üretilir. Prototip bir kez onaylandıktan sonra ekip ona referans vermeye devam eder, oysa iki sprint sonra gerçek arayüzle arasında kimsenin kaydını tutmadığı beş fark birikmiştir. Prototipe yatırım yapacaksanız güncelleme sorumlusunu da baştan belirleyin, yoksa elinizde kalan şey kanıt değil, güvenilir görünen eski bir ekran.

Stil kılavuzu kodla eşleşmiyorsa yalan söylüyor

Tasarım sistemi belgesinde "birincil buton" diye geçen bileşenin kodda karşılığı yoksa, o belge kılavuz değil dilek listesidir. Bileşen adları, aralık ölçekleri ve renk isimleri iki tarafta birebir aynı olmalı; ekip "tasarımda buna ikincil diyoruz ama kodda secondary-alt" noktasına geldiyse kılavuz artık maliyet üretiyor.

Kontrolü basit yapabilirsiniz: kılavuzdaki bileşen listesini kod tabanındaki bileşen dizinine karşı okuyun. İki listede birbirine karşılık gelmeyen her isim, ileride yaşanacak bir tartışmadır.

Agile az belge değil, kısa ömürlü belge demek

Esnek yöntemlere geçen ekipler de belge üretmeyi bırakmıyor, sadece belgenin ömrü kısalıyor. Beyaz tahta fotoğrafı bir sprint yaşar, prototip birkaç ay, stil kılavuzu ürün yaşadığı sürece. Belgeyi hazırlarken hangi kutuda olduğunu bilmek, ne kadar emek harcayacağınızı da belirler.

Pratik kural: bir hafta içinde çöpe gidecek şeye cila çekmeyin, ürün ömrü boyunca kalacak şeyi de toplantı çizimi gibi bırakmayın.

Nereden başlanır

• Ölçülmüş bir bulgunuz varsa test raporu yazın, yoksa yazmayın.
• Tek bir belgeyi tüm paydaşlara uydurmaya çalışmayın; aynı akışın iki farklı sunumu, herkesi memnun etmeyen tek belgeden ucuza gelir.
• Stil kılavuzunu tasarım dosyasında değil, kodun yanında tutun.
• Güncellenmeyecek belgeyi hiç üretmeyin. Yanlış belge, belge olmamasından kötüdür.