Konu Başlıkları
Yükleniyor...

Wireframing: Neyi Çözer, Neyi Çözmez

Wireframe Ne Zaman İşe Yarar, Ne Zaman Yavaşlatır

Wireframe, bir arayüzün iskeletini renksiz ve içeriksiz haliyle ortaya koyar. Ucuzluğu buradan gelir: bir kutuyu silmek, kodlanmış bir bileşeni silmekten çok daha az acıtır. Ama yakaladığı hata sınıfı sanıldığından dar, bazı problemler ancak gerçek veri ekrana geldiğinde görünür. Ayrımı doğru yapmayan ekip, wireframe aşamasında geçirdiği haftayı sonradan geri alamaz.

Wireframe neyi çözer

İki şeyi iyi çözer: sayfadaki elemanların hiyerarşisini ve bir kullanıcının işi bitirmek için kaç adım attığını. İkisi de renk, tipografi ya da nihai metin olmadan tartışılabilir. Üçüncü faydası teknik değil, siyasi: "buraya bir slider koyalım" tartışmasını hiçbir şey kodlanmadan bitirir.

Çözmediği şey estetik yargı. Gri kutulara bakıp "bu tasarım soğuk" diyen paydaş yanılıyor, ama tartışmayı da kaybetmiş sayılmaz. Wireframe'i sunarken neyin henüz karara bağlanmadığını açıkça söylemek, sonraki üç toplantıyı kısaltır.

Sadakat düzeyi tercih değil, yöntemin kendisi

Wireframe'in yalın olması estetik bir seçim değil, işlevsel bir zorunluluk. Detay arttıkça geri bildirim detaya kayar: gerçek fotoğraf koyarsan fotoğrafı tartışırlar, gerçek metin koyarsan metni. İskeleti tartıştırmak istiyorsan iskeletten fazlasını gösterme.

İlk turu kâğıtta yap, araca sonra geç. Figma'da çizdiğin her kutu görünmez bir yatırıma dönüşür, iki gün sonra o düzeni çöpe atmaya karşı isteksizlik yaratır. Kâğıttaki bir ekranı buruşturmak bedava.

Kırılım sayısı maliyeti çarpar

"Mobil uyumluluğu wireframe aşamasında düşünün" tavsiyesi doğru, ama bedeli genelde söylenmez. Bir ekranı masaüstü, tablet ve mobil için ayrı çizersen çizim sayın üçe katlanır. Yirmi ekranlık bir üründe bu, yirmi çizim yerine altmış çizim demektir; altmış çizimlik bir set hızlı olmaktan çıktığı anda wireframe olmayı bırakır, bakımı olan bir tasarım dosyasına döner. Yöntemin bütün savunması ucuzluğuydu.

İşleyen yol şu: bütün ekranları tek kırılımda çiz, sadece düzeni gerçekten değişen ekranları ikinci kırılımda tekrarla. Bir liste sayfasının mobilde tek sütuna inmesi çizim gerektirmez, herkes zihninde canlandırabilir. Filtre paneli, çok sütunlu tablo ve çok adımlı form ise mobilde başka bir şeye dönüşür. O üçünü ayrıca çiz, gerisini bırak.

Wireframe'in göremediği hatalar

Erken hata tespiti bu yöntemin en çok tekrarlanan vaadi ve kısmen doğru. Yakaladığı hatalar yapısal olanlar: eksik ekran, yanlış sıralanmış adım, hiçbir yere bağlanmayan buton. Kalanlar çizimin doğası gereği görünmez, çünkü çizimler daima ideal veriyle yapılır.

  • Taşan içerik: gerçek başlıklar üç satıra çıktığında bozulan kart düzeni, wireframe'de her zaman iki satır görünür.
  • Boş durumlar: sıfır kayıtlı liste, sonuç dönmeyen arama, ilk kez giren kullanıcı.
  • Bekleme: veri geç geldiğinde ekranda ne olduğu statik bir çizimde yoktur, oysa algılanan hızın tamamı orada belirlenir.
  • Hata halleri: doğrulama mesajı nereye yazılacak, form gönderilemezse kullanıcı ne görecek.

Bu dördü wireframe'e eklenebilir. Eklenmediğinde ortadan kalkmazlar, sadece kararı geliştirme sırasında yazılımcının o anki insafına bırakılır. Ekranların yanına birer varyant olarak koymak, bütün süreçte alınacak en ucuz sigortadır.

Araçlar

Araç seçimi sanıldığı kadar belirleyici değil. Ekibin ortak kullanabildiği ve dosyayı açmak için lisans beklemediği her araç iş görür.

  • Balsamiq: elle çizilmiş görünümü sayesinde "bu bitmiş tasarım değil" mesajını kendiliğinden verir.
  • Figma: aynı dosyada birden fazla kişinin çalışması ve wireframe'den yüksek sadakatli tasarıma aynı yerde geçilmesi gerektiğinde.
  • Adobe XD, Sketch: ekibin zaten yerleşik olduğu ortamlar; sırf wireframe için bunlara geçmek gereksiz.
  • UXPin: tasarım sistemi kuruluysa ve bileşenler tekrar kullanılacaksa anlamlı.

Derinleşmek için