Wireframe Case Study'de Nasıl Sunulur?

Wireframe, birçok UX case study’de “tasarıma geçmeden önce yaptığım ekranlar” gibi gösterilir. Birkaç gri kutu, birkaç akış ekranı, belki yanına kısa bir açıklama. Sonra final UI ekranlarına geçilir.

Bu yaklaşım wireframe’in asıl değerini kaçırır.

Wireframe, sadece düşük çözünürlüklü ekran değildir. İyi kullanıldığında, tasarımcının yapı, akış, öncelik, bilgi hiyerarşisi ve kullanıcı karar anları hakkında nasıl düşündüğünü gösterir.

Portfolyo açısından wireframe’in değeri şurada değildir:

Bakın, final ekrana geçmeden önce wireframe de çizdim.

Daha güçlü değer şuradadır:

Bu aşamada problemi çözmek için farklı yapı seçeneklerini denedim, öncelikleri netleştirdim ve final tasarıma gitmeden önce kararları test ettim.

Bu fark küçük görünür ama case study’nin kalitesini ciddi şekilde değiştirir.

Wireframe nedir?

Wireframe, bir ekranın veya akışın görsel stil detaylarına girmeden önceki yapısal taslağıdır. Renk, tipografi, ikon seti, illüstrasyon veya marka dili ikinci plandadır. Ana odak şudur:

• Ekranda hangi bilgiler yer alacak?
• Bu bilgiler hangi sırayla sunulacak?
• Kullanıcı hangi adımı önce görecek?
• Birincil aksiyon ne olacak?
• İkincil aksiyonlar nasıl konumlanacak?
• Kullanıcı karar vermek için hangi bilgiye ihtiyaç duyacak?
• Akışta hangi adımlar sadeleştirilecek veya ayrılacak?

Bu yüzden wireframe’i sadece görsel taslak olarak anlatmak eksik kalır. Wireframe, karar alanıdır.

Portfolyoda wireframe ne zaman işe yarar?

Wireframe, özellikle tasarım kararının sadece final ekrandan anlaşılamadığı durumlarda güçlüdür.

1. Bilgi hiyerarşisini nasıl kurduğunu göstermek istiyorsan

Birçok UX problemi “ekranda ne var?” sorusundan çok “ne önce görülmeli?” sorusuyla ilgilidir.

Örneğin bir finansal işlem ekranında kullanıcı için en önemli bilgi işlem tutarı, maliyet, vade, risk açıklaması veya sonraki adım olabilir. Bunların hepsi aynı anda gösterildiğinde ekran kalabalıklaşabilir. Yanlış sırayla gösterildiğinde kullanıcı karar veremez.

Wireframe bu hiyerarşi kararını anlatmak için iyi bir yerdir.

Zayıf anlatım:

Wireframe aşamasında ekran yapısını oluşturdum.

Daha güçlü anlatım:

Wireframe aşamasında ilk kararım, kullanıcıya işlem sonucunu en üstte göstermek oldu. Araştırma bulgularında kullanıcıların ilerlemeden önce “bu işlem bana neye mal olacak?” sorusunu netleştirmek istediğini görmüştük. Bu yüzden detayları aşağıya aldım, karar için gerekli bilgiyi üst alanda topladım.

Burada wireframe, layout görseli değil, kullanıcı ihtiyacına verilen yapısal cevaptır.

2. Akış alternatiflerini değerlendirdiysen

Wireframe, final tasarıma geçmeden önce farklı akış seçeneklerini denediğini göstermek için çok uygundur.

Örneğin:

• Tek adımlı form mu, çok adımlı form mu?
• Bilgiyi karar öncesinde mi göstermek gerekir, onay ekranında mı?
• Kullanıcıyı hızlı ilerletmek mi daha iyi, yoksa açıklama eklemek mi?
• Opsiyonları kart yapısında mı göstermek gerekir, tablo yapısında mı?

Bu kararları sadece final ekranla anlatmak zor olabilir. Wireframe alternatifleri, düşünme sürecini görünür kılar.

Örnek anlatım:

İlk wireframe alternatifinde tüm bilgileri tek ekranda topladım. Bu yaklaşım hızlı görünüyordu ama karar için gerekli açıklamalar ekrana fazla yük bindiriyordu. İkinci alternatifte süreci iki adıma böldüm: önce seçim, sonra karar öncesi kontrol. Bu yapı, testte kullanıcıların daha rahat ilerlemesini sağladı.

Bu açıklama okuyucuya sadece ne tasarladığını değil, neden öyle tasarladığını gösterir.

3. Final tasarımın neden öyle göründüğünü açıklamak istiyorsan

Final UI ekranları çoğu zaman görsel olarak güçlü olabilir. Fakat okuyucu, o ekranın arkasındaki kararları anlamayabilir.

Wireframe bölümü, final tasarıma giden yolu açıklar.

Örneğin:

Final ekrandaki üst özet alanı, wireframe aşamasında test ettiğimiz üç hiyerarşi seçeneğinden çıktı. Kullanıcılar karar vermeden önce toplam maliyet ve sonraki adımı aynı yerde görmek istediği için bu alanı ekranın en görünür noktasına taşıdık.

Bu cümle final tasarımın tesadüfi olmadığını gösterir.

Wireframe ne zaman zayıf görünür?

Wireframe kullanmak her zaman case study’yi güçlendirmez. Bazen gereksiz bir ara adım gibi durabilir.

1. Sadece “low-fidelity ekran” olarak gösteriliyorsa

Wireframe’i yalnızca gri kutularla gösterip hiçbir karar açıklamıyorsan, okuyucu için değeri düşer.

Şu ifade yetersizdir:

Aşağıda wireframe çalışmalarım yer alıyor.

Bunun yerine şunu yazmak daha güçlüdür:

Wireframe aşamasında üç karar üzerinde çalıştım: bilgiyi hangi sırayla göstereceğim, kullanıcıyı kaç adımdan geçireceğim ve karar öncesinde hangi güven sinyallerini ekleyeceğim.

Bu cümle okuyucunun neye bakması gerektiğini söyler.

2. Wireframe ile final tasarım arasında bağ yoksa

Wireframe gösteriliyor ama final ekranda bu kararların nasıl devam ettiği anlatılmıyorsa, bölüm kopuk görünür.

Güçlü bir case study’de wireframe şu bölümlere bağlanmalıdır:

• Research finding
• User need
• Information architecture
• Task flow
• Prototype
• Usability test
• Final design

Wireframe bu zincirde bir ara karar noktasıdır.

3. Çok fazla wireframe gösteriliyorsa

Portfolyoda bütün çalışma dosyasını göstermek cazip olabilir. Fakat her ekranı eklemek, okuyucunun ana kararı görmesini zorlaştırır.

Daha iyi yaklaşım:

• 2 veya 3 kritik ekran seç.
• Her ekranın hangi soruya cevap verdiğini yaz.
• Alternatif varsa neden birini seçtiğini açıkla.
• Final tasarıma nasıl bağlandığını göster.

Case study’de wireframe arşivi değil, düşünme süreci gösterilir.

Wireframe case study’de nasıl anlatılır?

Aşağıdaki yapı çoğu case study için yeterlidir.

1. Wireframe aşamasındaki amacı yaz

Önce neden wireframe yaptığını açıkla.

Örnek:

Final tasarıma geçmeden önce akıştaki iki temel soruyu netleştirmek istedim: kullanıcı karar için gerekli bilgiyi hangi anda görmeli ve onay adımı ne kadar açıklayıcı olmalı?

Bu cümle yöntemi amaca bağlar.

2. Hangi kararları test ettiğini belirt

Wireframe bölümünde “ekran çizdim” demek yerine, karar alanlarını yaz.

Örneğin:

• Bilgi hiyerarşisi
• Form yapısı
• Adım sayısı
• Birincil aksiyon
• Geri dönüş yolu
• Hata durumu
• Karşılaştırma yapısı
• Onay ve güven mesajları

Bu listeyi yazıya çevirebilirsin:

Wireframe aşamasında özellikle bilgi hiyerarşisi, adım sayısı ve onay öncesi güven mesajları üzerine çalıştım.

3. Alternatifleri kısa anlat

Her alternatif için uzun açıklama yazmak zorunda değilsin. Fakat neden elediğini veya neden seçtiğini belirtmek değerlidir.

Örnek:

İlk alternatifte tüm bilgileri tek ekranda topladım. Bu yapı kısa görünüyordu ama karar öncesinde fazla bilişsel yük oluşturuyordu. İkinci alternatifte bilgiyi seçim ve kontrol olarak iki adıma ayırdım. Bu yapı, kullanıcının önce karar vermesini, sonra detayları kontrol etmesini kolaylaştırdı.

Bu anlatım wireframe’in karar üretme işlevini gösterir.

4. Wireframe’i kullanıcı ihtiyacına bağla

Wireframe açıklamasında şu bağlantıyı kur:

Bu yapı, kullanıcı ihtiyacına nasıl cevap verdi?

Örnek:

Kullanıcılar işlem sonucunu anlamadan ilerlemek istemiyordu. Bu yüzden wireframe’de onay ekranını sadece son kontrol noktası olarak değil, karar öncesi güven alanı olarak kurguladım.

Bu cümle wireframe’i kullanıcı problemine bağlar.

5. Final tasarıma geçişi açıkla

Wireframe bölümünün sonunda final tasarıma köprü kur.

Örnek:

Wireframe testlerinden sonra final tasarımda üç şeyi korudum: üstte özet bilgi, düzenlenebilir kontrol alanı ve işlem sonrası beklenti yönetimi mesajı.

Bu köprü, okuyucunun final ekranları daha bilinçli okumasını sağlar.

İyi bir wireframe bölümü nasıl yazılabilir?

Aşağıdaki örnek yapı kullanılabilir:

Wireframe aşamasında amacım görsel tasarımı netleştirmek değil, karar akışını test etmekti. Kullanıcılar son adıma gelmeden önce işlem sonucunu, maliyeti ve geri dönüş imkanını anlamak istiyordu.

Bu yüzden iki akış alternatifi denedim. İlk alternatif tüm bilgiyi tek ekranda topluyordu. Daha kısa görünmesine rağmen karar için fazla yük oluşturuyordu. İkinci alternatif bilgiyi seçim ve kontrol olarak iki adıma ayırdı. Bu yapı, kullanıcının önce seçimi anlamasını, sonra karar öncesi detayları kontrol etmesini kolaylaştırdı.

Final tasarımda bu ikinci yapıyı temel aldım. Özet bilgiyi üst alana, düzenlenebilir detayları orta bölüme, işlem sonrası beklenti mesajını ise onay alanına taşıdım.

Bu bölümde wireframe sadece görsel değil, karar sürecinin kanıtıdır.

Wireframe görseli nasıl sunulmalı?

Wireframe görselini eklerken okuyucunun neye bakması gerektiğini belirt.

Şunlar işe yarar:

• Kritik alanları işaretle.
• Her wireframe’in altında tek cümlelik karar notu yaz.
• Alternatifleri yan yana gösteriyorsan farklarını netleştir.
• Çok fazla ekran yerine temsil gücü yüksek birkaç ekran seç.
• Final tasarımla bağ kuran alanları vurgula.
• Wireframe’i küçük ve okunamaz bir kolaj haline getirme.

Örnek görsel notu:

Alternatif 2’de karar öncesi kontrol adımını ayrı bir ekrana aldım. Bu yapı, kullanıcının işlem sonucunu onaylamadan önce düzenlenebilir bilgileri daha rahat kontrol etmesini sağladı.

Bu not, görseli case study’ye bağlar.

Wireframe yerine ne gösterebilirsin?

Bazı projelerde wireframe göstermek şart değildir. Wireframe yerine başka bir format daha iyi çalışabilir.

Task flow

Eğer temel karar ekran yapısından çok akış sırasıysa, task flow daha iyi olabilir.

Information architecture diyagramı

Eğer temel problem içerik gruplama, navigation veya kategori yapısıysa, IA diyagramı daha açıklayıcı olabilir.

Prototype akışı

Eğer wireframe aşamasında etkileşim kararları ön plandaysa, prototip akışını göstermek daha anlamlı olabilir.

Karar tablosu

Eğer birkaç alternatif arasında seçim yaptıysan, kısa bir karar tablosu güçlü olabilir.

Örnek:

Alternatif	Avantaj	Risk	Karar
Tek ekran	Daha kısa	Fazla bilişsel yük	Elendi
İki adım	Daha açık	Bir adım fazla	Seçildi

Bu tür bir tablo bazen wireframe görselinden daha iyi anlatır.

Kısa kontrol listesi

Wireframe’i case study’ye eklemeden önce şu soruları sor:

• Wireframe hangi kullanıcı problemine cevap veriyor?
• Hangi bilgi hiyerarşisi kararı burada alındı?
• Alternatif denendi mi? Denendiyse neden biri seçildi?
• Wireframe ile final tasarım arasında net bağ var mı?
• Görselde okuyucunun bakması gereken yer belli mi?
• Bu wireframe’i kaldırırsan case study bir karar kanıtını kaybeder mi?

Son sorunun cevabı hayırsa, wireframe’i ayrı bölüm yapmak yerine kısa bir tasarım karar notu olarak kullanabilirsin.

Sonraki adım

Wireframe’i portfolyona eklemeden önce her ekran için şu cümleyi yaz:

Bu wireframe’de çözmeye çalıştığım karar şuydu…

Sonra ikinci cümleyi ekle:

Bu karar final tasarımda şu şekilde devam etti…

Bu iki cümle netleştiğinde wireframe, portfolyoda sadece ara ekran değil, tasarım düşüncesinin kanıtı haline gelir.