Wireframe Nedir, UX Testlerinde Ne Kadar İşe Yarar?

Wireframe, bir arayüzün rengi ve yazı tipi konuşulmadan önce neyin nerede duracağını gösteren iskelettir. Değeri hızından gelir: yanlış kurulmuş bir akışı, o akış koda dönüşmeden yakalarsınız. Ama "wireframe çizelim" demek tek başına bir yöntem değil. Hangi soruyu sorduğunuza göre çizeceğiniz şey de, testten alacağınız cevap da değişiyor.

Wireframe hangi soruyu cevaplar, hangisini cevaplamaz

Cevapladığı soru dar: kullanıcı bu ekrana geldiğinde ne görüyor, sonra nereye gidiyor, hangi bilgi hangisinin önünde duruyor. Cevaplamadığı soru ise testte en sık sorulan soru, yani "bu tasarım iyi mi". Renk, tipografi, mikro etkileşim ve içeriğin gerçek uzunluğu taslakta yok; dolayısıyla o sorunun cevabı da yok.

Bu ayrımı baştan yapmazsanız oturum kayar. Kutuların üstüne "buton" yazan bir ekranı gösterip "ne düşünüyorsunuz" diye sorduğunuzda insanlar çizimin kendisi hakkında konuşur. Görev verdiğinizde akış hakkında konuşurlar. Aradaki fark, wireframe'in işe yarayıp yaramaması arasındaki farktır.

Lo-fi ile hi-fi arasındaki seçim, aslında geri bildirim seçimi

Yaygın anlatım şöyle: lo-fi hızlıdır, hi-fi gerçeğe yakındır, süreç ilerledikçe birinden diğerine geçersiniz. Doğru, ama eksik. Ayrıntı arttıkça katılımcının yorumu da yukarı kayıyor; ekran ne kadar bitmiş görünürse yapı o kadar az sorgulanıyor. Yarım çizilmiş bir ekranda "burada ne olmalı" diye soran kullanıcı, cilalı bir ekranda aynı eksikliği tasarımcının bilinçli kararı sayıp susuyor.

Ekip içi ilk turu genelde kağıtla ya da Balsamiq'le çözerim; Figma'yı ancak ekran müşteriye veya geliştiriciye gidecekse açarım. Sebep estetik değil. Kağıttaki bir kutuyu silmenin bedeli yok, hizalanmış bir bileşeni silmenin bedeli var, ve o bedel farkı ekibin yanlış akışı savunma isteğini besliyor.

"Ucuz ve hızlı" iddiasının sınırı

Wireframe'in en çok tekrarlanan faydası maliyet: hatayı erken yakalar, geliştirmeden tasarruf ettirir. Düşük ayrıntılı taslaklar için doğru. Tıklanabilir, gerçek metin taşıyan, durum geçişleri kurulmuş bir hi-fi taslak içinse aynı şeyi söylemek zor. O iş arayüz tasarımının kendisi kadar zaman alıyor ve kodda karşılığı olmadığı için tek kullanımlık kalıyor.

Burada gözden kaçan bir çelişki var. Hi-fi taslaklar çoğu anlatımda "hataların son aşamada saptanmasını sağlar" diye övülüyor. Oysa wireframe'in bütün gerekçesi hatayı erken yakalamaktı. Son aşamaya kalan hata zaten pahalı hatadır; onu bulmak için bir de prototip üretmişseniz tasarrufun bir bölümünü yolda harcamışsınız demektir. Hi-fi'yi doğrulama aracı değil, kararı verilmiş bir akışı aktarma aracı saymak daha dürüst.

Bilgi mimarisi wireframe'de çözülmez

Menü hiyerarşisi, kategori adları, neyin neyin altına gireceği: bunlar taslak çizilmeden önce cevaplanmış olmalı. Wireframe bu kararları görselleştirir, sınamaz. Beş kişilik bir oturumda katılımcının "Ayarlar"ı bulması size o menünün doğru kurgulandığını söylemez, yalnızca o etiketin o ekranda görünür olduğunu söyler. Adlandırma ve gruplama için kart gruplama ya da ağaç testi hem daha doğru cevap verir hem de daha ucuza mal olur.

Geliştiriciye giden taslak

Wireframe'in az konuşulan işlevi, tasarımla uygulama arasındaki belirsizliği eritmek. Bir kutunun üstünde "liste" yazıyorsa geliştirici için hâlâ cevapsız sorular var: liste boşken ekran nasıl duruyor, kaç kayıttan sonra sayfalanıyor, veri gelmezse ne görünüyor. Bu durumları ek ekran olarak çizmek, sonradan açılacak biletlerin çoğunu baştan kapatır. Boş durumu çizilmemiş her liste, er geç ortası bomboş bir ekran olarak canlıya çıkıyor.

Araç seçimi

Figma, Sketch, Adobe XD, Balsamiq: hepsi aynı işi farklı sürtünmeyle yapar. Aracın kendisi sonucu belirlemiyor, taslağın ne kadar kolay çöpe atılabildiği belirliyor. Bir wireframe'e üzülmeden veda edemiyorsanız, muhtemelen wireframe aşamasını çoktan geçmişsinizdir.