30 saniyelik özet
Wireframe, yani tel çerçeve, bir ekranın içerik düzenini, bilgi önceliklerini ve temel eylemlerini gösteren taslaktır. Kullanıcının hangi bilgiyi göreceğini, ne yapabileceğini ve farklı durumlarda nasıl yönlendirileceğini tartışmaya açar. İş analisti için değeri, sözlü gereksinimlerde saklı kalan varsayımları görünür hale getirmesidir. Bir tablo çizmek kolaydır; hangi sütunun kullanıcının kararını değiştirdiğini açıklamak daha fazla düşünme gerektirir. İyi bir wireframe, ekibin üzerinde konuşabileceği bir öneridir. Kullanıcı ihtiyacının doğrulandığına veya tasarımın tamamlandığına tek başına kanıt oluşturmaz.
Neden önemli?
“Riskli müşterileri gösteren bir ekran istiyoruz” talebi açık görünebilir. Ancak satış yöneticisi yaklaşan yenilemeleri, destek yöneticisi çözülemeyen sorunları, müşteri başarı uzmanı ise kullanım düşüşünü görmek isteyebilir. Hepsi aynı ekranı tarif ederken farklı kararlar vermeyi amaçlıyor olabilir.
Wireframe bu farkları somutlaştırır. Risk puanı üstte, gerekçesi ayrıntı ekranında yer alıyorsa kullanıcı puanı görür ama nedenini anlamak için ek adım atar. Aksiyon sahibi hiç gösterilmiyorsa sorun fark edilir, fakat sorumluluk belirsiz kalır. Bunlar görsel tercihlerden önce iş akışı ve bilgi ihtiyacı kararlarıdır.
Yönetici açısından asıl kazanç, geliştirme kararının dayandığı varsayımları inceleyebilmektir. Hangi kullanıcı görevinin desteklendiği, hangi veriye ihtiyaç duyulduğu ve hangi belirsizliğin sürdüğü görünür olur. Bununla birlikte bir taslağın toplantıda beğenilmesi, kullanım sırasında işe yarayacağını göstermez. Taslak üzerinde uzlaşma ile kullanıcı davranışından elde edilen kanıtı ayrı değerlendirmek gerekir.
Terim nedir?
Wireframe, ekranın yapısını anlatır: başlıklar, içerik alanları, gezinme seçenekleri, veri grupları ve eylemler arasındaki ilişkiyi gösterir. Bilgi mimarisi, içeriğin kullanıcı tarafından bulunabilecek ve anlaşılabilecek biçimde düzenlenmesidir. Taslak bu düzenin bir bölümünü somutlaştırır; bütün ürünün bilgi mimarisinin yerine geçmez.
Düşük ayrıntı düzeyinde basit kutular ve kısa etiketler yeterli olabilir. Daha fazla ayrıntı gerektiğinde alan adları, açıklama metinleri, örnek içerikler ve durum notları eklenir. Ayrıntı düzeyi, çözülmek istenen soruya göre seçilmelidir. “Kullanıcı doğru aksiyonu bulabiliyor mu?” sorusu için anlamlı düğme etiketleri gerekir. Marka renginin tonu ise bu soruyu yanıtlamayabilir.
Wireframe ile prototip aynı şey değildir. Prototip, bir çözümün belirli davranışlarını veya özelliklerini sınamak için hazırlanan temsildir. Ekran taslakları birbirine bağlanarak etkileşimli bir prototip oluşturulabilir. Tek bir statik çizim ise veri kaydetme, ekranlar arasında geçiş veya hata sonrası toparlanma davranışını göstermez.
Bir başka sınır da görsel sadelikle ilgilidir. Renk ve süsleme ertelenebilir; okunabilirlik, açık etiketler ve anlaşılır bilgi sırası ertelenmemelidir. Bunlar kullanıcının görevi yapmasını etkiler. İş analisti tasarımcıyla birlikte hangi gereksinimin hangi ekran öğesine karşılık geldiğini açıklamalı, çözülmemiş davranışları notlarla işaretlemelidir.
Gerçek vaka: Merck geliştirici portalının yönünü sınamak
Thoughtbot’un Merck için yürüttüğü tasarım çalışması, geliştiricilerin bilgi ve kod paylaşabileceği bir portal fikrini ele alıyor. Ekip önce hedefi tartıştı: Öncelik geliştiriciler arasında paylaşımı kolaylaştırmak mı, yöneticilere tasarrufu göstermek mi olmalıydı?
Kaynağa göre ekranlar, önceki akış çizimlerinden yararlanılarak beyaz tahtada wireframe olarak hazırlandı. Ardından bu taslaklardan bir prototip oluşturuldu ve kullanıcı görüşmeleriyle birlikte test edildi. Görüşmeler, geliştiricilerin zaten kişisel ağları üzerinden bilgi paylaştığını ortaya koydu. Kullanıcıların portala hangi içerikleri ekleyebilecekleri konusunda belirsizlik yaşadığı ve katkıda bulunmanın beklenenden daha zor olduğu görüldü.
Thoughtbot, test edilen çözümün mevcut haliyle geliştirilmeye yeterince ikna edici bulunmadığını ve sorunları ele almak için yeni bir çalışma üzerinde anlaşıldığını belirtiyor. Bu, ekibin kendi yayımladığı vaka anlatımıdır.
Buradaki ders, wireframe çizmenin tek başına doğrulama sağlamadığıdır. Taslakların prototipe dönüştürülmesi ve kullanıcılarla sınanması, başlangıç varsayımlarını değerlendirmeyi mümkün kılmıştır. Ekran düzenini onaylamakla çözümün kullanıcı için değerini doğrulamak farklı kararlardır.
Varsayımsal örnek: Riskli müşteri hesapları ekranı
Bir kurumsal yazılım şirketinin müşteri başarı ekibi, yenileme öncesinde riskli hesapları değerlendirmek istiyor. Analist ekranı çizmeden önce görevi netleştirir: Kullanıcı bir hesabın neden riskli olduğunu anlayacak, mevcut aksiyonu görecek ve gerekiyorsa sorumlu atayacaktır.
İlk wireframe, hesap listesi ile seçilen hesabın ayrıntısını yan yana gösterir. Listede hesap adı, yenileme tarihi, risk gerekçesi ve aksiyon sahibi bulunur. Ayrıntıda kullanım eğilimi, açık destek sorunları ve önceki aksiyonlar yer alır. Risk göstergesinin nasıl hesaplandığı henüz kararlaştırılmadıysa, bu alan doğrulanmış bir sonuç gibi sunulmaz; açık karar olarak işaretlenir.
Taslak gerçekçi fakat kurgusal içerikle incelenir. Kullanıcıya “Şu düğmeye basın” denmez. “Yenilemesi yaklaşan bu hesap için bir sonraki adımı belirleyin” görevi verilir. Böylece kullanıcıyı tasarımın beklediği yola yönlendirmeden, hangi bilgileri aradığı gözlenebilir.
Kullanıcı risk etiketini görüyor fakat kanıtı bulamıyorsa gerekçe daha görünür hale getirilir. Yeni grafik eklemeden önce eksik bilgi veya anlaşılmayan etiket araştırılır. Veri güncellenmemişse son güncelleme zamanı gösterilir. Aksiyon atama yetkisi bulunmayan rol için sorumlu bilgisi görünür kalabilir, ancak düzenleme davranışı ayrıca tanımlanır.
İnceleme sonunda yalnızca yeni çizim kaydedilmez. Hangi gözlemin hangi değişikliğe yol açtığı ve hangi sorunun açık kaldığı da yazılır. Böylece sonraki toplantıda kararlar kişisel tercihlere dayanarak yeniden tartışılmaz.
Yaygın üç hata
- Taslağı görsel beğeni üzerinden değerlendirmek
“Daha modern olsun” yorumu kullanıcı görevi hakkında bilgi vermez. İncelemeyi somut sorulara yöneltin: Kullanıcı doğru hesabı bulabiliyor mu, riski anlayabiliyor mu, sonraki aksiyonu seçebiliyor mu? Görsel tercihleri bu görevleri etkiledikleri ölçüde tartışın.
- Yalnızca dolu ve sorunsuz ekranı çizmek
Veri yokken, yükleme sürerken veya erişim kısıtlıyken ekranın davranışı değişir. Bu durumlar için gerekli mesajları ve seçenekleri tanımlayın. Boş liste, uygun kayıt bulunmamasıyla verinin henüz yüklenmemesi arasında ayrım yapmalıdır. Kullanıcıya aynı mesajı göstermek farklı sorunları gizler.
- Wireframe onayını geliştirme için eksiksiz şartname saymak
Bir düğmenin görünmesi, ne zaman etkin olacağını veya işlem başarısız olduğunda ne olacağını açıklamaz. Taslağı iş kuralları ve kabul kriterleriyle ilişkilendirin. Kabul kriterleri, çözümün kabul edilebilir sayılması için gözlenebilir koşulları belirtir. Eksik davranışı geliştirme ekibinin tahminine bırakmayın.
Mini uygulama / şablon
Bir ekran seçin ve çizime başlamadan önce aşağıdaki alanları doldurun. İlk taslağın kapsamını kullanıcının tek bir anlamlı göreviyle sınırlamak, incelemeyi kolaylaştırır.
- Ekranın adı
- —
- Hedef kullanıcı ve rolü
- —
- Kullanıcının tamamlayacağı görev
- —
- Vereceği karar
- —
- Karar için gerekli bilgiler
- —
- Birincil eylem ve beklenen sonuç
- —
- Bilginin kaynağı ve güncelliği
- —
- Boş, yükleniyor ve hata durumları
- —
- Yetkiye göre değişen davranışlar
- —
- İlgili gereksinimler ve iş kuralları
- —
- Sınanacak varsayım
- —
- İncelemede verilecek görev
- —
- Gözlenecek davranış
- —
- Açık sorular ve karar sahipleri
- —
İncelemeden sonra gözlemi yorumdan ayırın. “Kullanıcı risk gerekçesini bulmak için ayrıntıyı açtı” bir gözlemdir. “Gerekçe listede de gösterilmeli” ise değerlendirilecek çözüm önerisidir. Bu ayrım, tek bir davranıştan aceleyle tasarım kararı üretmeyi önler.
Son olarak taslağın sürümünü ve karar gerekçesini kaydedin. Geliştirme sırasında değişiklik istendiğinde yalnızca çizimi güncellemeyin; ilişkili davranış tanımlarını da kontrol edin. Ekran ile gereksinim birbirinden koparsa, güncel görünen taslak eski iş kurallarını uygulayan bir ürüne dönüşebilir.
İlgili terimler
Requirements Elicitation, Voice of Customer, Use Case, User Story, Acceptance Criteria, Functional Requirement, Business Rule, Prototype ve MVP, User Acceptance Testing, Data Mapping ve Data Dictionary