Wireframe Nedir? Web Sitesi Taslağı Neden Tasarımdan Önce Gelir?

Wireframe, bir web sayfasının renk ve görsel içermeyen iskelet çizimidir. Biz Talha Aslan ve ekibi olarak her projede tasarıma bu taslakla başlıyoruz. Bu rehberde düşük ve yüksek sadakatli wireframe farkını, hangi sayfalar için çizmeniz gerektiğini, müşteri onayını ve tasarıma geçişi adım adım anlatıyoruz.

Bir binanın mimari çizimini düşünün. Duvar rengini seçmeden önce odaların yerini ve kapıların açılış yönünü belirlersiniz. Wireframe de web sitesi için aynı görevi görür. Örneğin bir hizmet sayfasında başlığın, kısa açıklamanın, fiyat isteme düğmesinin ve güven unsurlarının hangi sırayla geleceğini bu çizim gösterir.

Üstelik wireframe ekip içinde ortak bir dil kurar. Tasarımcı, yazılımcı, metin yazarı ve işletme sahibi aynı kâğıda bakarak konuşur. Böylece "logo biraz daha büyük olsun" gibi erken ve dağınık yorumlar yerine "bu bölüm ziyaretçiye ne söylüyor?" sorusu öne çıkar. Kısacası wireframe, tartışmayı doğru yere taşıyan bir araçtır.

Wireframe neden görsel tasarımdan önce gelir?

Sıralamanın sebebi basit: yapıyı değiştirmek, bitmiş bir tasarımı değiştirmekten çok daha ucuzdur. Gri kutulardan oluşan bir taslakta bir bölümü yukarı taşımak birkaç dakika sürer. Oysa renkleri, görselleri ve animasyonları oturmuş bir tasarımda aynı değişiklik çoğu zaman bütün ekranı yeniden düzenlemeyi gerektirir.

Ayrıca görsel tasarım dikkati dağıtır. İnsanlar renkli bir ekran gördüğünde önce beğeniye dair yorum yapar. Ancak sayfanın asıl işi, ziyaretçiyi bir karara götürmektir. Gri bir taslak bu tartışmayı sadeleştirir; herkes içeriğin sırasına ve mesajın açıklığına bakar.

Nielsen Norman Group'un düşük ve yüksek sadakatli prototipler üzerine yazısı da benzer bir noktaya dikkat çekiyor: kaba bir taslağı tasarımcılar daha kolay değiştirir, paydaşlar da tasarımın henüz bitmediğini fark eder. Bu yüzden biz web tasarım projelerimizde renk paletini açmadan önce sayfa iskeletini onaylatıyoruz.

Düşük ve yüksek sadakatli wireframe arasındaki fark nedir?

Sadakat (fidelity), taslağın bitmiş ürüne ne kadar benzediğini anlatan bir ölçüdür. Düşük sadakatli wireframe için kâğıt ya da basit kutular yeterlidir; metni çizgiyle, görseli çarpı işaretli kutuyla gösterirsiniz. Yüksek sadakatli wireframe ise gerçek ölçülere, gerçek metne ve tıklanabilir bağlantılara yaklaşır.

İki tür birbirinin rakibi değildir; projenin farklı anlarında işe yarar. İlk toplantıda düşük sadakatli taslak hızlı fikir üretmenizi sağlar. Yapı netleştikten sonra yüksek sadakatli versiyon ölçüleri, boşlukları ve etkileşimleri sınamanıza imkân tanır.

• Düşük sadakat: Kâğıt, beyaz tahta ya da basit kutular. Amaç bölümlerin sırası ve kaba oranlar.
• Orta sadakat: Dijital araçta hizalı kutular, gerçek başlıklar, ızgara (grid) düzeni.
• Yüksek sadakat: Gerçek metin, gerçek ölçüler, tıklanabilir akış. Renk ve marka öğeleri hâlâ sınırlı.

Pratikte biz çoğu kurumsal sitede düşük sadakatten başlayıp orta sadakatte onay alıyoruz. Yüksek sadakate ise form akışı, filtreleme ya da ödeme adımı gibi karmaşık etkileşimler olduğunda geçiyoruz.

Wireframe, mockup ve prototip aynı şey mi?

Hayır, üçü tasarım sürecinin farklı aşamalarıdır ve farklı soruları cevaplar. Wireframe "ne nerede duruyor?" sorusunu yanıtlar. Mockup (görsel maket) "sayfa nasıl görünecek?" sorusuna cevap verir. Prototip ise "kullanıcı tıkladığında ne olacak?" sorusunu sınar. Aşağıdaki tablo farkları özetliyor.

Dolayısıyla "bize bir taslak gönderin" dendiğinde neyin istendiğini baştan konuşmak gerekir. Müşteri renkli bir ekran beklerken gri bir wireframe görürse hayal kırıklığı yaşayabilir. Bu nedenle biz ilk toplantıda hangi aşamada ne teslim edeceğimizi yazılı olarak paylaşıyoruz.

Hangi sayfalar için wireframe hazırlamalısınız?

Her sayfa için ayrı wireframe çizmeniz gerekmez. Asıl hedef, tekrar eden şablonları ve kritik karar sayfalarını belirlemektir. Bir kurumsal sitede onlarca sayfa olabilir; ancak bunların çoğu birkaç ortak şablonu paylaşır.

1. Ana sayfa: Markanın ilk izlenimi ve diğer bölümlere dağıtım noktası.
2. Hizmet ya da ürün detay şablonu: Satışa en yakın sayfa; her hizmet aynı iskeleti kullanır.
3. Kategori ya da liste sayfası: Filtre, sıralama ve kart düzenine burada karar verirsiniz.
4. İletişim ve teklif formu: Alanların sırası ve hata mesajlarının yeri.
5. Blog listesi ve yazı şablonu: Okunabilirlik ve iç bağlantıların yeri.
6. Hakkımızda: Güven unsurlarının nasıl dizileceği.

Örnek senaryo: on iki hizmeti olan bir mühendislik firması düşünün. On iki ayrı çizim yerine tek bir hizmet şablonu çizersiniz. Ardından en uzun ve en kısa içerikli iki hizmeti bu şablona yerleştirip test edersiniz. Böylece şablonun hem kalabalık hem sade içerikle çalıştığını görürsünüz.

Wireframe çizmeden önce hangi bilgileri toplamalısınız?

İyi bir taslak boş bir sayfadan doğmaz. Kalemi elinize almadan önce sitenin kime hitap ettiğini, ziyaretçinin hangi soruyla geldiğini ve sayfadan ne yapmasını beklediğinizi bilmeniz gerekir. Bu bilgileri genellikle proje başındaki brief belgesinde toplarsınız.

• Hedef kitle ve ziyaretçinin en sık sorduğu üç soru.
• Her sayfanın tek bir ana hedefi (teklif isteme, arama, form doldurma).
• Mevcut içerik envanteri: hangi metinler, görseller ve belgeler hazır?
• Site haritası ve menü yapısı.
• Arama verisi: insanlar bu hizmeti hangi kelimelerle arıyor?
• Teknik kısıtlar: tercih ettiğiniz altyapı, çoklu dil ihtiyacı, entegrasyonlar.

Brief belgesinin nasıl hazırlanacağını web projesinde brief hazırlama rehberimizde ayrıntılı anlattık. Menü ve sayfa hiyerarşisi için ise bilgi mimarisi yazımız iyi bir başlangıç noktası olur. Wireframe bu iki çalışmanın üzerine oturur; yani onların yerini tutmaz.

İçerik önceliğini wireframe üzerinde nasıl belirlersiniz?

İçerik önceliği, ziyaretçinin bir sayfada önce neyi görmesi gerektiğine verdiğiniz karardır. Bunun için her bölümü bir soruyla eşleştirin. Ziyaretçi sayfaya geldiğinde ilk olarak "doğru yerde miyim?" diye sorar. Ardından "bu bana ne kazandırır?" ve "neden size güveneyim?" soruları gelir. En son da "şimdi ne yapmalıyım?" sorusu belirir.

Pratik bir yöntem olarak bölümleri kâğıt kartlara yazın ve masada sıralayın. Her kartın üzerine o bölümün cevapladığı soruyu ekleyin. Cevabı olmayan kart büyük olasılıkla gereksizdir. Öte yandan aynı soruyu cevaplayan iki kart varsa birini birleştirmeniz gerekir.

İlk ekranda görünen alan özellikle önemlidir; çünkü ziyaretçi kaydırmadan önce sayfada kalıp kalmayacağına karar verir. Bu alanı nasıl kurguladığımızı above the fold rehberimizde anlattık. Ancak ilk ekrana her şeyi sıkıştırmaya çalışmayın. Wireframe, önceliği boyut, konum ve boşlukla göstermenize izin verir; renk olmadan bile ziyaretçi hiyerarşiyi seçebilmelidir.

Wireframe'de gerçek metin mi, yer tutucu metin mi kullanmalısınız?

Mümkün olduğunca gerçek metin kullanın. Yer tutucu metin (lorem ipsum) kutuyu doldurur, ancak içeriğin gerçek uzunluğunu ve tonunu gizler. Örneğin iki kelimelik bir başlık için çizilen alan, sonradan gelen yedi kelimelik başlığı taşıyamaz ve tasarım dağılır.

Gerçek metin henüz hazır değilse en azından gerçekçi taslak başlıklar yazın. "Hizmet başlığı buraya" yerine "Endüstriyel çatı yalıtımı, 48 saatte keşif" gibi örnek bir cümle koyun. Böylece başlığın uzunluğunu, satır kırılmasını ve düğme metnini erken aşamada sınamış olursunuz.

Ayrıca düğme ve form etiketlerini wireframe'e mutlaka gerçek haliyle yazın. "Gönder" ile "Teklifimi hazırlayın" arasındaki fark küçük gibi durur, ama ziyaretçinin ne beklediğini değiştirir. Bu mikro metinlerin nasıl yazılacağını UX writing yazımızda örneklerle ele aldık. Kısacası metin, wireframe'in süsü değil, iskeletinin parçasıdır.

Mobil wireframe'i neden ayrı düşünmelisiniz?

Çünkü mobil ekranda bölümler yan yana değil, alt alta akar ve bu sıra önceliği yeniden tanımlar. Masaüstünde sağ sütunda duran bir güven kutusu, mobilde sayfanın en altına düşebilir. Eğer bunu wireframe aşamasında görmezseniz, mobil ziyaretçi en önemli bilgiyi hiç görmeyebilir.

Google, mobil öncelikli dizine ekleme belgesinde mobil ve masaüstü sürümlerin aynı ana içeriği ve aynı anlamlı başlıkları taşımasını öneriyor. Akordeon ya da sekme kullanmanız sorun değildir; önemli olan içeriğin eşdeğer kalmasıdır. Dolayısıyla mobil wireframe'de bir bölümü "yer yok" diye silmek yerine onu katlanabilir bir alana taşımayı düşünün.

Biz mobil taslağı masaüstünün küçük kopyası olarak değil, ayrı bir okuma sırası olarak çiziyoruz. Bu yaklaşımın mantığını mobil öncelikli tasarım yazımızda anlattık. Ayrıca başparmakla erişilen alanları, sabit düğmeleri ve menü açılışını mobil wireframe üzerinde ayrıca işaretliyoruz.

Erişilebilirliği wireframe aşamasında nasıl ele alırsınız?

Erişilebilirliği en ucuz noktada, yani taslakta ele alırsınız. Renk kontrastı gibi konular görsel tasarım aşamasına aittir. Ancak başlık hiyerarşisi, sayfa bölgeleri ve klavyeyle gezinme sırası doğrudan wireframe'in konusudur.

W3C'nin sayfa yapısı eğitiminde belirtildiği gibi, başlıklar bölümleri etiketler ve bölümlerin birbiriyle ilişkisini yansıtacak biçimde iç içe dizilmelidir. Sayfa bölgeleri (üst bilgi, ana içerik, alt bilgi) ise ekran okuyucu kullanıcılarının içeriğe hızla atlamasını sağlar.

• Her kutunun yanına başlık seviyesini yazın (H1, H2, H3).
• Sayfada tek bir H1 olduğunu kontrol edin.
• Klavye odağının hangi sırayla ilerleyeceğini numaralarla gösterin.
• Görsellerin bilgi mi taşıdığını, yoksa süs mü olduğunu not edin.
• Form alanlarının etiketlerini kutunun içine değil, dışına yazın.

Bu notlar yazılımcıya doğrudan rehber olur. Erişilebilirlik ilkelerinin tamamı için WCAG standartları yazımızı inceleyebilirsiniz.

Wireframe, SEO yapısını nasıl etkiler?

Wireframe, arama motorunun okuyacağı yapının ilk taslağıdır. Başlıkların sırasına, iç bağlantıların yerine ve içerik bloklarının uzunluğuna bu aşamada karar verirsiniz. Sonradan güzel bir tasarımın içine SEO eklemeye çalışmak, çoğu zaman yapıyı zorlamak anlamına gelir.

Örneğin bir hizmet sayfasında arama yapan kişinin cevap aradığı soruları bir sıkça sorulan sorular bölümünde toplamak istiyorsanız, bu bölümün yeri wireframe'de olmalıdır. Aynı şekilde ilgili hizmetlere vereceğiniz iç bağlantıların bir kart dizisi mi, yoksa metin içi bağlantı mı olacağı da bu aşamanın kararıdır.

Bununla birlikte SEO kaygısı, sayfayı metin yığınına çevirmemelidir. Biz wireframe üzerinde her bölüm için tahmini kelime aralığı yazıyoruz. Böylece içerik ekibi ne kadar metin üreteceğini bilir; tasarımcı da o metne uygun alanı ayırır. Sonuç olarak arama görünürlüğü ve okunabilirlik aynı plan üzerinde dengeye kavuşur.

Adım adım wireframe hazırlama süreci

Aşağıdaki sıra, bizim kurumsal sitelerde izlediğimiz temel akıştır. Proje büyüdükçe adımlar uzar, ama sıra pek değişmez.

1. Hedefi yazın: Sayfanın tek bir ana amacını bir cümleyle not edin.
2. İçerik envanterini çıkarın: Sayfaya girecek her parçayı listeleyin.
3. Kaba eskiz çizin: Kâğıtta üç farklı düzen deneyin; en az beş dakika, en fazla yarım saat.
4. Bir düzen seçin: Hedefe en kısa yoldan götüren düzeni tercih edin.
5. Dijitale aktarın: Izgara üzerinde kutuları hizalayın, gerçek başlıkları yazın.
6. Mobil sırayı çizin: Aynı içeriği tek sütunda yeniden dizin.
7. Notları ekleyin: Başlık seviyeleri, etkileşimler ve içerik uzunlukları.
8. İç gözden geçirme yapın: Ekipten biri taslağı açıklama olmadan okusun.
9. Müşteriye sunun: Kararları ve gerekçeleri birlikte anlatın.

Dijital aşamada hangi aracı kullandığınız ikinci plandadır. Biz çoğunlukla Figma kullanıyoruz; adımları Figma ile arayüz tasarımı rehberimizde paylaştık.

Müşteri onayına wireframe'i nasıl sunmalısınız?

Sunumu dosya göndermekle sınırlamayın. Gri kutulardan oluşan bir ekranı açıklamasız alan bir işletme sahibi, çoğu zaman "bu mu tasarım?" diye sorar. Bu nedenle wireframe'i kısa bir görüşmede, ekranı paylaşarak ve her bölümün neden orada olduğunu anlatarak sunun.

Sunuma "bu bir iskelettir, renk ve görsel sonra gelecek" cümlesiyle başlayın. Ardından sayfayı ziyaretçinin gözünden okuyun: önce ne görür, sonra neyi merak eder, nerede karar verir? Bu anlatım müşterinin yorumunu yapıya yönlendirir.

Onayı yazılı alın ve neyin onaylandığını açıkça belirtin. Örneğin "ana sayfa bölüm sırası ve hizmet şablonu onaylandı; metinler taslaktır" gibi bir not yeterlidir. Böylece görsel tasarım aşamasında "aslında bu bölüm hiç olmasın" gibi yapısal geri dönüşler azalır. Revizyon sürecini sağlıklı yönetmek için onay maddesini sözleşmedeki revizyon hakkıyla ilişkilendirmek de işe yarar.

Wireframe geri bildirimini nasıl toplarsınız?

Geri bildirimi "beğendiniz mi?" sorusuyla değil, göreve dayalı sorularla toplayın. Örneğin müşteriye ya da birkaç hedef kullanıcıya "fiyat teklifi almak isteseniz nereye tıklardınız?" diye sorun. Cevap tereddütlüyse yapı açık değildir.

• Yorumları bölüm bazında toplayın; tek bir uzun e-posta yerine her kutuya ayrı not.
• Yapısal yorumları (sıra, eksik bölüm) görsel yorumlardan (renk, yazı tipi) ayırın.
• Görsel yorumları bir sonraki aşama için ayrı bir listeye kaydedin.
• Çelişen yorumları karar vericiyle tek toplantıda netleştirin.

Nielsen Norman Group'un aynı yazısında belirtildiği gibi, kaba bir taslağı test eden katılımcılar olumsuz görüş bildirmekte daha rahat davranabilir. Bu da wireframe testini değerli kılar; çünkü sorunları en ucuz anda yakalarsınız. Daha kapsamlı bir kullanıcı deneyimi değerlendirmesi için UX audit rehberimize göz atabilirsiniz.

Wireframe'den görsel tasarıma geçiş nasıl olmalı?

Geçiş, onaylanan iskeleti bozmadan üzerine marka katmanını giydirmektir. Görsel tasarımcı renk, yazı tipi, görsel ve boşluk sistemini eklerken bölüm sırasını ve hiyerarşiyi korumalıdır. Yapıyı değiştirme ihtiyacı doğarsa bu, sessizce değil, gerekçesiyle konuşulmalıdır.

Biz geçişte önce bir stil temeli hazırlıyoruz: renk paleti, başlık ölçüleri, düğme biçimleri ve ızgara. Ardından onaylanan wireframe'leri sırayla bu temele aktarıyoruz. Önce en kritik şablonu, yani çoğu zaman hizmet sayfasını tasarlıyoruz. Bu sayfa onaylanınca diğer şablonlar çok daha hızlı ilerliyor.

Ayrıca wireframe'deki notların kaybolmamasına dikkat edin. Başlık seviyelerini, klavye sırasını ve içerik uzunluklarını görsel tasarım dosyasına da taşıyın. Aksi halde yazılım aşamasında bu kararları yeniden tartışırsınız. Kısacası wireframe bir çöp kâğıdı değil, projenin sonuna kadar başvurulan bir referanstır.

Tek sayfalık bir landing page için de wireframe gerekir mi?

Evet, hatta tek sayfalık bir kampanya sayfasında wireframe daha da önemlidir. Bu tür sayfalar genellikle reklamdan gelen ziyaretçiyi tek bir eyleme yönlendirir. Ziyaretçi ya formu doldurur ya da sayfadan çıkar; arada başka bir menü ya da yan yol yoktur.

Bu yüzden landing page wireframe'inde bölüm sırası doğrudan sonuca etki eder. Önce reklamdaki vaadi tekrar eden bir başlık, ardından faydalar, sonra güven unsurları ve en son form gelir. Ancak bu sıra her sektörde aynı değildir. Örneğin yüksek bütçeli bir B2B hizmetinde ziyaretçi formdan önce süreç ve referans bilgisini görmek ister.

Örnek senaryo: bir yazılım firması deneme sürümü için reklam veriyor. Wireframe aşamasında formu sayfanın hem başına hem sonuna koymayı, aradaki bölümleri ise sık sorulan itirazlara göre dizmeyi planlarsınız. B2B tarafındaki ayrıntılar için B2B landing page rehberimize bakabilirsiniz. Kısacası sayfa kısa olsa bile iskelet kararları aynı özeni ister.

Wireframe için hangi araçları kullanabilirsiniz?

Aracın kendisi, taslağın kalitesini belirlemez. İlk fikirler için kâğıt, kalem ve yapışkan notlar çoğu zaman en hızlı seçenektir. Beyaz tahta ise ekip toplantılarında herkesin aynı anda çizmesine imkân verir. Dijital aşamada ise ızgara, bileşen ve yorum özelliği sunan bir arayüz tasarım aracı işinizi kolaylaştırır.

Seçim yaparken üç soruya bakın. Birincisi, ekibiniz bu aracı zaten kullanıyor mu? İkincisi, müşteri taslağı ek bir program kurmadan açabiliyor mu? Üçüncüsü, araç tıklanabilir bağlantı eklemenize izin veriyor mu? Bu üç soruya "evet" diyen her araç iş görür.

Öte yandan araç değiştirmek için projenin ortasını beklemeyin. Taslağı bir araçta başlatıp başka bir araçta bitirmek, notların ve yorumların kaybolmasına yol açar. Bu yüzden biz aracı projenin başında seçiyor ve sonuna kadar aynı dosyada çalışıyoruz.

E-ticaret sitesinde wireframe neden daha kritik?

E-ticaret sitesinde ziyaretçi birkaç ekran boyunca adım adım ilerler: kategori, ürün, sepet ve ödeme. Bu adımların her biri ayrı bir karar anıdır. Dolayısıyla bir adımdaki yapısal sorun, sonraki adımların hepsini etkiler.

Örnek senaryo: bir ev tekstili mağazası ürün sayfasında beden tablosunu sekmenin içine saklıyor. Masaüstünde sorun yok gibi duruyor; ancak mobil ziyaretçi tabloyu bulamadan sepete ekleme düğmesine geliyor. Wireframe aşamasında mobil sırayı çizseydiniz, bu tabloyu düğmenin hemen üstüne taşımayı baştan konuşurdunuz.

• Ürün kartında hangi bilgilerin (fiyat, stok, kargo) görüneceğini netleştirin.
• Filtrelerin mobilde nasıl açılacağını ayrı bir taslakta gösterin.
• Sepet ve ödeme adımlarını tek tek çizin; adım sayısını görünür kılın.
• Hata durumlarını (stok bitti, kart reddi) ayrıca planlayın.

Bu adımlar, ödeme akışındaki sürprizleri azaltır ve yazılım ekibine net bir yol haritası verir.

Wireframe'i yazılım ekibine nasıl teslim edersiniz?

Teslim, yalnız bir dosya bağlantısı göndermek değildir. Yazılımcı, taslağa bakarak her bölümün davranışını anlamalıdır. Bu nedenle wireframe'in yanına kısa bir açıklama belgesi ekleyin ya da notları doğrudan taslağın üzerine yazın.

Notlarda şu bilgilere yer verin: hangi alanın dinamik içerikten geldiği, hangi bölümün yönetim panelinden düzenleneceği, hangi bağlantının nereye gittiği ve form gönderildiğinde ne olacağı. Ayrıca mobilde gizlenen ya da katlanan bölümleri açıkça işaretleyin.

Biz teslimden sonra kısa bir ortak toplantı yapıyoruz. Yazılımcı taslağı kendi cümleleriyle anlatıyor, biz de eksik ya da yanlış anlaşılan noktaları orada düzeltiyoruz. Bu sayede geliştirme sırasında gelen soru sayısı belirgin şekilde düşüyor; üstelik tasarımcı ile yazılımcı aynı kararı iki kez tartışmak zorunda kalmıyor.

Wireframe aşamasında en sık gördüğümüz hatalar

Sahada karşılaştığımız hataları genellikle birkaç başlık altında topluyoruz. Bunları önceden bilmek, aynı tuzağa düşmemenizi sağlar.

• Taslağı çok erken renklendirmek: Tartışma yapıdan beğeniye kayar.
• Yalnız masaüstü çizmek: Mobil okuma sırası sonradan sürpriz yaratır.
• Lorem ipsum ile yetinmek: Gerçek metin geldiğinde alanlar yetmez.
• Her sayfayı ayrı çizmek: Şablon mantığı oluşmaz, tutarlılık kaybolur.
• Onayı sözlü almak: Neyin onaylandığı sonradan tartışma konusu olur.
• Boş durumları unutmak: Arama sonucu yokken ya da form hatası varken ekranın ne göstereceğini kimse düşünmez.

Son madde özellikle gözden kaçar. Örneğin bir blog kategorisinde henüz yazı yoksa ya da form gönderimi başarısız olursa ziyaretçi ne görecek? Bu durumların her biri küçük bir wireframe hak eder. Böylece yazılım ekibi tahmin yürütmek yerine hazır bir plana göre çalışır.

Wireframe ne kadar sürer ve kaç tur revizyon gerekir?

Süre, sayfa şablonu sayısına ve karar vericilerin hızına bağlıdır; tek bir sabit süre vermek doğru olmaz. Saha tecrübemize dayalı başlangıç aralığı olarak, küçük bir kurumsal sitede ana şablonların wireframe aşaması birkaç iş günü ile iki hafta arasında sürebilir. Ancak bu bir garanti değildir; içerik hazırlığı geciktikçe süre uzar.

Revizyon turu için de benzer bir mantık geçerlidir. Biz genellikle bir ilk sunum ve bir düzeltme turu planlıyoruz. Yapı hâlâ netleşmiyorsa sorun çoğu zaman taslakta değil, brief aşamasındaki belirsizliktedir. Bu durumda daha fazla çizim yerine hedefleri yeniden konuşmak daha hızlı sonuç verir.

Öte yandan wireframe aşamasını kısaltmak için atlamak cazip görünebilir. Fakat yapı kararlarını bu aşamada vermezseniz, görsel tasarımda ya da yazılımda vermek zorunda kalırsınız. Orada aynı değişikliğin maliyeti çok daha yüksektir. Dolayısıyla birkaç günlük taslak çalışması, sonraki haftaları korur.

Wireframe kontrol listesi: onaya sunmadan önce neye bakmalısınız?

Taslağı müşteriye göndermeden önce aşağıdaki listeyi tek tek işaretleyin. Bir maddeye "hayır" diyorsanız sunumu erteleyin.

• Her sayfanın tek bir ana hedefi yazılı mı?
• İlk ekran "doğru yerde miyim?" sorusunu cevaplıyor mu?
• Ana eylem düğmesi her şablonda tutarlı yerde mi?
• Başlık seviyeleri işaretli ve sayfada tek H1 var mı?
• Mobil okuma sırasını ayrıca çizdiniz mi?
• Gerçek ya da gerçekçi metin kullandınız mı?
• Form alanlarını, hata ve başarı durumlarını gösterdiniz mi?
• Boş durumları (sonuç yok, içerik yok) düşündünüz mü?
• İç bağlantıların ve SSS bölümünün yeri belli mi?
• Her bölüm için tahmini içerik uzunluğunu not ettiniz mi?
• Onaya sunacağınız kapsam yazılı olarak hazır mı?

Bu listeyi projenin başında müşteriyle de paylaşabilirsiniz. Böylece taraflar wireframe'den ne beklediğini baştan bilir ve onay toplantısı çok daha verimli geçer.

Ayrıca listeyi her projede güncelleyin. Örneğin çok dilli bir sitede dil seçicinin yerini, randevu sistemi olan bir sitede takvim adımlarını listeye ekleyin. Böylece kontrol listesi zamanla ekibinizin ortak hafızasına dönüşür ve yeni projelerde aynı soruları baştan düşünmek zorunda kalmazsınız.

Wireframe sürecini sizin siteniz için nasıl yürütüyoruz?

Bizim yaklaşımımızda wireframe, brief ile görsel tasarım arasındaki köprüdür. Önce hedefleri ve içerik envanterini birlikte çıkarıyoruz. Ardından kritik şablonların masaüstü ve mobil iskeletini çiziyor, her bölümün gerekçesini anlatarak onaya sunuyoruz.

Onaylanan yapı üzerine marka kimliğinizi giydiriyor, erişilebilirlik ve arama motoru notlarını yazılım aşamasına kadar taşıyoruz. Yayından önce sayfaların mobilde nasıl göründüğünü mobil uyumluluk testi aracımızla da kontrol ediyoruz.

Sitenizi bu sırayla, yani önce iskelet sonra görünüş mantığıyla kurmak istiyorsanız web tasarım hizmetimizin sayfasından projenizi anlatıp teklif isteyebilirsiniz. Size sayfa şablonlarına, içerik durumuna ve hedeflerinize göre hazırladığımız bir kapsam ve takvim sunuyoruz.