Figma ile Web Arayüz Tasarımı Nasıl Yapılır? Adım Adım Tasarım Süreci

Figma ile web arayüz tasarımı, bir sitenin ekranlarını kod yazılmadan önce aynı dosyada planlamak, çizmek, test etmek ve geliştiriciye eksiksiz teslim etmek demektir. Bu yazıda kendi projelerimde izlediğim sırayı anlatıyorum: brief, site haritası, wireframe, tasarım sistemi, auto layout ile responsive yapı, prototip ve Dev Mode ile teslim.

Amacım bir araç kılavuzu yazmak değil. Figma'nın resmi yardım sayfalarındaki doğru terimleri kullanarak, bir işletme sitesinin arayüzünü baştan sona nasıl kurduğumu adım adım göstermek istiyorum. Böylece ister kendiniz tasarlayın, ister bir tasarımcıyla çalışın, sürecin hangi noktasında olduğunuzu net görebilirsiniz.

Figma ile web arayüz tasarımı nasıl yapılır?

Figma ile web arayüz tasarımı yedi adımda ilerler: hedefleri netleştiren bir brief, sayfaları listeleyen site haritası, gri tonlu wireframe, variables ve components ile kurulan tasarım sistemi, auto layout ile responsive ekranlar, tıklanabilir prototip ve Dev Mode üzerinden geliştiriciye teslim. Her adım bir sonrakinin girdisini üretir.

Sırayı atlamak ilk bakışta cazip gelir. Örneğin birçok ekip doğrudan renkli ana sayfa çizmeye başlar, ardından içerik sığmayınca her şeyi baştan düzenler. Ben bu yüzden ilk iki adımı Figma dışında, düz bir belgede bitiriyorum. Figma'yı açtığımda ne çizeceğimi zaten biliyorum.

Aşağıdaki bölümler bu yedi adımı sırayla açıyor. Her bölümde hangi Figma özelliğini neden kullandığımı ve hangi çıktıyla bir sonraki aşamaya geçtiğimi yazdım. Ayrıca sonda tüm süreci tek tabloda topladım.

Figma'yı açmadan önce brief neden şart?

Brief, tasarımın neyi başarması gerektiğini yazılı hale getiren kısa bir belgedir. İyi bir brief olmadan Figma'da geçirdiğiniz her saat, zevke dayalı tartışmaya dönüşür. Çünkü "güzel olmuş mu" sorusunun ölçüsü yoktur, ama "teklif formuna ulaşan ziyaretçi arttı mı" sorusunun ölçüsü vardır.

Ben brief'i şu başlıklarla dolduruyorum:

• Sitenin tek cümlelik görevi ve ana dönüşüm eylemi (teklif, randevu, satın alma, arama).
• Hedef kitle, onların sorduğu ilk üç soru ve karar vermelerini engelleyen itirazlar.
• Mevcut marka varlıkları: logo, renkler, yazı tipleri, fotoğraf arşivi.
• Beğenilen ve beğenilmeyen üç örnek site, gerekçeleriyle birlikte.
• Teknik sınırlar: seçtiğiniz CMS, çoklu dil ihtiyacı, entegrasyonlar.

Hedef kitle kısmını geçiştirmemenizi öneririm. Bunun için hedef kitle analizi rehberimdeki soruları kullanabilirsiniz. Dönüşüm eylemini belirlemek için de dönüşüm hedefi yazımı işinizi kolaylaştırır. Brief onaylanmadan wireframe'e geçmiyorum; bu kural revizyon sayısını belirgin şekilde düşürüyor.

Site haritasını ve sayfa envanterini nasıl çıkarırsınız?

Site haritası, sitedeki tüm sayfaları ve aralarındaki hiyerarşiyi gösteren bir ağaçtır. Tasarım açısından en önemli işlevi, kaç farklı sayfa şablonu çizeceğinizi ortaya koymasıdır. On beş sayfalık bir site genellikle dört beş şablondan oluşur: ana sayfa, hizmet detay, liste, içerik ve iletişim gibi.

Ben site haritasını FigJam'de ya da doğrudan Figma'daki ayrı bir sayfada kutularla çiziyorum. Her kutunun yanına o sayfanın hedef arama ifadesini ve ana eylemini not ediyorum. Böylece tasarım ile SEO planı baştan aynı masada buluşuyor. Arama ifadelerini sayfalara dağıtmak için anahtar kelime haritalama yöntemini kullanıyorum.

Büyük bir katalog ya da çok kategorili bir site planlıyorsanız hiyerarşi derinliği daha kritik hale gelir. O durumda büyük sitelerde kategori yapısı yazımdaki kuralları tasarıma başlamadan uygulayın. Aksi halde menü ve filtre bileşenlerini sonradan yeniden çizmek zorunda kalırsınız.

Bu adımın çıktısı iki listedir: sayfa listesi ve şablon listesi. Şablon listesi, Figma dosyanızdaki çalışma sırasını da belirler.

Ayrıca her şablonun hangi durumlarda farklı göründüğünü de bu aşamada not ediyorum. Örneğin boş bir arama sonucu, stokta olmayan ürün ya da gönderilmiş form ekranı ayrı birer tasarım ihtiyacıdır. Bu durumları erkenden listelerseniz, geliştirme sırasında "bu ekran nasıl görünecek" sorusu hiç gelmez. Dolayısıyla site haritası sadece bir menü planı değil, tasarımın kapsamını belirleyen bir sözleşme gibi çalışır.

Wireframe aşamasında Figma'da neye odaklanmalısınız?

Wireframe, renksiz ve süssüz bir iskelettir; içerik bloklarının sırasını ve önceliğini gösterir. Bu aşamada renk, fotoğraf ve yazı tipi tartışması yapmıyorum. Sadece şu sorulara cevap arıyorum: ziyaretçi ekranı açtığında ilk neyi görmeli, hangi sırayla ikna olmalı ve eylem düğmesi nerede durmalı?

Figma'da wireframe için gri tonlar, tek bir yazı tipi ve basit kutular yeterli. Ancak gerçek metne yakın içerik kullanmanızı öneririm. Lorem ipsum ile çizilen bir hizmet sayfası, gerçek metin gelince neredeyse her zaman taşar. Ben müşteriden kaba bir metin taslağı alıyorum ya da başlıkları kendim yazıyorum.

Wireframe'i önce mobil genişlikte çiziyorum. Çünkü dar ekranda sığmayan blok, masaüstünde de gereksizdir. Bu yaklaşımın mantığını mobil öncelikli tasarım yazımda ayrıntılı anlattım.

Wireframe'i tıklanabilir hale getirmek de mümkün; üç dört ekranı basit bağlantılarla birbirine bağlarsanız müşteri akışı daha iyi anlar. Ancak bu aşamada animasyon ve ayrıntılı etkileşim eklemiyorum, çünkü amaç yalnızca sırayı doğrulamak.

Bu aşamanın sonunda müşteriyle kısa bir onay toplantısı yapıyorum. Blok sırası burada kesinleşirse, görsel tasarım aşamasında yalnızca görünüm üzerine konuşuyoruz. Yapı tartışması ise bir daha açılmıyor.

Figma dosyasını nasıl düzenlemelisiniz?

Dosya düzeni, projenin ikinci ayında ne kadar hızlı çalışacağınızı belirler. Figma'nın geliştirici teslimi için yayımladığı dosya hazırlama önerileri de aynı noktaya vurgu yapar: sayfaları açıklayıcı adlandırın, katmanlara anlamlı isimler verin, ilgili ekranları section içinde toplayın.

Benim standart sayfa yapım şöyle:

1. Kapak: proje adı, durum ve son güncelleme notu.
2. Brief ve site haritası: onaylı kararların kısa özeti.
3. Wireframe: mobil ve masaüstü iskeletler.
4. Tasarım sistemi: renk, tipografi, boşluk ve bileşenler.
5. Ekranlar: şablon başına bir section, her section içinde kırılım noktaları.
6. Prototip: bağlantılı akışlar.
7. Arşiv: reddedilen alternatifler.

Katman adlarında "Frame 427" gibi otomatik isimleri bırakmıyorum. Örneğin bir kart için "card/service" ya da "hero/title" gibi adlar kullanıyorum. Geliştirici Dev Mode'da bu isimleri görür, dolayısıyla kod tarafındaki sınıf adlarına yakın isimler seçmek iletişimi hızlandırır. Arşiv sayfası da önemli; eski versiyonları silmek yerine oraya taşımak, "ilk halini geri getirelim" talebinde hayat kurtarır.

Tasarım sistemi nereden başlar: renk, tipografi ve boşluk?

Tasarım sistemi, bir arayüzü oluşturan tüm tekrar eden kararların tek yerde toplanmasıdır. Küçük bir kurumsal site için bile kuruyorum, çünkü sistem olmadan her yeni sayfa yeni bir gri tonu ve yeni bir boşluk değeri doğuruyor.

İlk olarak renk paletini çıkarıyorum. Marka renklerini ana renk olarak alıyorum, ardından her biri için açık ve koyu tonlar üretiyorum. Metin, arka plan, kenarlık ve durum renkleri (başarı, uyarı, hata) için ayrı roller tanımlıyorum. Renk kodlarını karşılaştırmak ve tonları denemek için HTML renk kodları aracımı kullanabilirsiniz.

Tipografide bir ölçek belirliyorum: gövde metni, küçük metin ve dört beş başlık seviyesi. Web için gövde metnini okunaklı bir boyutta tutuyor, satır yüksekliğini de rahat bir aralıkta bırakıyorum. Boşluk için ise 4 ya da 8'in katlarından oluşan bir dizi seçiyorum. Böylece padding ve gap değerleri rastgele sayılar yerine tek bir sisteme dayanıyor.

Bu kararların hepsini tek bir "Tasarım sistemi" sayfasında topluyorum. Yeni katılan bir tasarımcı ya da geliştirici, sayfaya bakarak projenin kurallarını on dakikada öğrenebilmeli.

Variables mı styles mı: hangisini ne zaman kullanırsınız?

Figma'da tasarım kararlarını saklamanın iki yolu var ve ikisi birbirinin yerine geçmiyor. Figma'nın variables ve styles farkı sayfasına göre styles birden fazla değeri bir arada tutar ve hepsini aynı anda uygular. Variables ise tek bir değer tutar ama bu değer bağlama göre değişebilir.

Variables dört türde gelir: color, number, string ve boolean. Bunları collection içinde gruplarsınız. Her collection birden fazla mode barındırabilir; örneğin açık ve koyu tema ya da mobil ve masaüstü. Bir çerçeveyi koyu moda aldığınızda, variable bağlı tüm katmanlar koyu mod değerini gösterir.

Benim pratiğim şöyle: ham değerleri variables olarak tanımlıyorum, metin ve efekt kombinasyonlarını styles olarak kaydediyorum. Figma'nın aynı sayfasında belirttiği gibi gradyanlar variable olamıyor, bu nedenle onlar kesin olarak style kalıyor.

Component ve variant yapısını nasıl kurarsınız?

Component, bir kez tasarlayıp her yerde kopyası (instance) kullanılan arayüz parçasıdır. Ana component'i değiştirdiğinizde Figma tüm kopyaları da günceller. Düğme, form alanı, kart, menü ve alt bilgi ilk component listemde yer alır.

Variant ise aynı component'in farklı hallerini tek bir component set içinde toplar. Figma'nın variant rehberi bunu özellik ve değer mantığıyla açıklar: bir düğmenin size, state ya da color özellikleri olabilir; state için default, hover, pressed ve disabled gibi değerler tanımlarsınız.

Variant kurarken dikkat ettiğim noktalar:

• Özellik adlarını "Property 2" gibi varsayılan halde bırakmıyorum; "boyut", "durum" gibi anlamlı adlar veriyorum.
• Farklı ikonları variant olarak gruplamıyorum; Figma da variant'ı aynı ikonun farklı boyutları için öneriyor.
• Variant'ları satır ve sütunlara diziyorum, böylece eksik kombinasyonu bir bakışta fark ediyorum.
• Her component'e kısa bir açıklama yazıyorum: ne zaman kullanılacağı ve erişilebilirlik notu.

Düğmeler özellikle dikkat ister, çünkü sitenin satış işini onlar yapar. Metin, renk ve konum kararları için CTA butonu örnekleri yazımı referans alabilirsiniz.

Auto layout ile responsive tasarımı nasıl kurarsınız?

Auto layout, bir çerçevedeki nesneleri kurala göre dizen ve içerik değiştikçe çerçeveyi otomatik yeniden boyutlandıran Figma özelliğidir. CSS'teki flexbox mantığına çok yakındır. Figma'nın auto layout rehberi dört akış tanımlar: vertical, horizontal, wrap ve grid.

Responsive davranışı üç boyutlandırma ayarı belirler. Hug contents, çerçeveyi içeriğini saracak en küçük boyutta tutar. Fill container, nesneyi üst çerçevedeki boş alanı dolduracak şekilde genişletir. Fixed ise boyutu sabitler. Bunlara ek olarak min ve max genişlik ile yükseklik tanımlayabilirsiniz.

Pratikte şöyle kuruyorum: sayfa çerçevesi fixed genişlikte, içerik kapsayıcısı fill container ve bir max width değeriyle sınırlı. Kartlar bir horizontal akışta, wrap açık halde duruyor. Çerçeveyi daralttığımda kartlar kendiliğinden alt satıra iniyor. Böylece aynı bileşeni masaüstü ve mobil ekranda ayrı ayrı çizmek zorunda kalmıyorum.

Padding ve gap değerlerini number variables'a bağlıyorum. Bir de "ignore auto layout" seçeneği var; eski adıyla absolute position. Bunu yalnızca rozet ya da köşe etiketi gibi akış dışında kalması gereken öğelerde kullanıyorum. Fazla kullanırsanız responsive davranışı kendi elinizle bozarsınız.

Figma ile web arayüz tasarımında kırılım noktalarını nasıl seçersiniz?

Kırılım noktası, düzenin değiştiği ekran genişliğidir. Figma'da her kırılım noktası için ayrı bir çerçeve açıyorum ama bileşenler aynı kalıyor; sadece düzen kuralları değişiyor. Genelde üç çerçeve yeterli: mobil, tablet ve masaüstü.

Genişlik değerlerini cihaz listesine göre değil, içeriğe göre seçmenizi öneririm. Örneğin üç sütunlu kart ızgarası hangi genişlikte sıkışıyorsa, orası doğal bir kırılım noktasıdır. Ardından geliştiricinin kullandığı CSS çatısındaki değerlerle karşılaştırıp gerekirse uyumlu hale getiriyorum.

Burada variables'ın mode özelliği işe yarıyor. Boşluk ve yazı boyutu değerleri için "mobil" ve "masaüstü" adlı iki mode tanımlarsanız, çerçevenin modunu değiştirmek tüm değerleri tek hamlede günceller. Böylece başlık boyutlarını her ekranda elle düzeltmek yerine sistem üzerinden yönetirsiniz.

Her kırılım noktasında şu kontrolleri yapıyorum: menü daralınca ne oluyor, tablo taşıyor mu, form alanları tam genişliğe geçiyor mu, düğmeler başparmakla rahat basılacak büyüklükte mi? Mobil kontrolün mantığını mobil öncelikli tasarım rehberinde daha geniş anlattım.

Ana sayfadan iç sayfalara nasıl ilerlemelisiniz?

Sistem hazır olduğunda görsel tasarıma geçiyorum. Sıra her zaman aynı: önce en çok trafik alacak ve en çok bileşen içeren şablon, sonra geri kalanlar. Çoğu projede bu ana sayfa ya da ana hizmet sayfasıdır.

İlk şablonu bitirirken yeni bir bileşen ihtiyacı doğarsa, onu hemen tasarım sistemi sayfasına taşıyorum. Ekran içinde "tek seferlik" parçalar biriktirmiyorum. Çünkü ikinci şablonda aynı parçaya yeniden ihtiyaç duyulduğunda, ekranlardan kopyalamak tutarsızlık demektir.

Görsel tasarım aşamasında fotoğraf seçimine de özen gösteriyorum. Stok fotoğraf yerine müşterinin gerçek ekibini, ürününü ya da tesisini kullanmak güveni artırır. Fotoğrafların yerleşimini ve oranlarını Figma'da belirliyor, çekim listesini buna göre hazırlıyorum.

Formlar ayrı bir dikkat ister. Bir teklif ya da randevu formunun kaç alan içerdiği, hata mesajlarının nerede çıktığı ve gönderim sonrası ekranın ne söylediği, sitenin kazandırdığı müşteri sayısını doğrudan etkiler. Bu konuda form tasarımı yazımdaki kuralları uyguluyorum. Her şablonu bitirdiğimde müşteriye kısa bir video kaydıyla sunuyorum; yazılı yorumlar daha net geliyor.

Erişilebilirlik kontrolleri: kontrast, dokunma alanı ve metin

Erişilebilirliği tasarım bittikten sonra değil, bileşen kurulurken kontrol etmek çok daha ucuzdur. Web için ortak dil WCAG'dir. WCAG 2.2 kontrast kriteri normal metin için en az 4.5:1, büyük metin için en az 3:1 oran ister.

WCAG 2.2 ile gelen hedef boyutu kriteri (2.5.8) de dokunma alanları için en az 24x24 CSS pikselini ya da yeterli aralığı şart koşar. Ben düğme ve ikon bağlantılarını bundan daha cömert boyutta tasarlıyorum, özellikle mobil menüde.

Figma'da yaptığım erişilebilirlik kontrolleri:

• Renk rollerini tanımlarken her metin ve arka plan çiftinin kontrastını ölçüyorum.
• Hover, focus ve disabled durumlarını variant olarak çiziyorum; özellikle klavye odağını her zaman belirgin çiziyorum.
• Hata mesajını yalnızca kırmızı renkle değil, metin ve ikonla da gösteriyorum.
• Başlık hiyerarşisini katman adlarına yazıyorum ki geliştirici doğru etiketi seçsin.

Bu kontroller aynı zamanda SEO'yu da destekler. Okunabilir metin ve net başlık yapısı hem kullanıcının hem arama motorunun işini kolaylaştırır. İki tarafın dengesini UX ve SEO dengesi yazımda ele aldım.

Prototipi nasıl bağlarsınız ve neyi göstermeli?

Prototip, statik ekranları tıklanabilir bir akışa dönüştürür. Figma'da Prototype sekmesinden bir nesneye etkileşim eklersiniz. Her etkileşimin bir tetikleyicisi (trigger) ve bir eylemi (action) vardır.

Figma'nın prototip tetikleyicileri sayfasına göre en sık kullanılanlar On click (mobilde On tap), While hovering, Mouse enter, Mouse leave ve After delay'dir. After delay için süreyi milisaniye olarak girersiniz. Önemli bir kısıt da var: aynı nesnede On click ile While hovering birlikte çalışmaz; bunun yerine Mouse enter ve Mouse leave kullanmanız gerekir.

Eylem tarafında en çok Navigate to (başka çerçeveye git) eylemini seçiyorum. Ayrıca açılır pencere için overlay ve harici bağlantı eylemlerini de sık kullanıyorum. Smart animate ise aynı ada sahip katmanları çerçeveler arasında eşleştirip geçişi yumuşatır. Bu yüzden katman adlarını tutarlı tutmak animasyonda da işe yarar.

Her şeyi bağlamaya çalışmıyorum. Prototip yalnızca kritik akışları göstermeli: ana sayfadan hizmete, hizmetten forma, formdan teşekkür ekranına. Bu üç dört akış, test için fazlasıyla yeterli.

Prototipi kiminle ve nasıl test edersiniz?

Testin amacı, tasarımın gerçek kullanıcıda nasıl çalıştığını görmektir. Nielsen Norman Group'un uzun süredir savunduğu yaklaşıma göre küçük bir grupla yapılan tekrarlı testler, büyük tek bir testten daha fazla sorun yakalar. Ben de her turda birkaç kişiyle çalışıyorum ve turu gerektiği kadar tekrarlıyorum.

Katılımcıları hedef kitleye yakın seçiyorum. Müşterinin ekibi ya da benim tasarımcı arkadaşlarım iyi test katılımcısı değildir, çünkü ekranı zaten tanıyorlar. Katılımcıya bir görev veriyorum: "Bu firmadan fiyat teklifi isteyin" gibi. Sonra hiç yönlendirmeden izliyorum.

Not aldığım üç şey var:

1. Katılımcı nerede duraksadı ya da geri döndü?
2. Hangi metni okumadan geçti, hangisini iki kez okudu?
3. Görevi tamamladı mı, kaç tıklamada?

Uzaktan test için Figma prototip bağlantısı yeterli; katılımcı tarayıcıda açıyor, ekran paylaşımıyla izliyorum. Bulguları öncelik sırasına dizip tasarım sistemine ya da ilgili şablona geri işliyorum. Test sonucunda en sık yaptığım değişiklik, düğme metnini ve form alan sayısını sadeleştirmek oluyor.

Geliştiriciye teslimde Dev Mode ne sağlar?

Dev Mode, Figma'nın geliştiriciler için hazırladığı inceleme arayüzüdür. Figma'nın Dev Mode rehberine göre bu arayüzü tüm ücretli planlarda açabilirsiniz; Full seat ya da Dev seat gerekir. Geliştirici burada ölçüleri, renkleri, variables adlarını ve otomatik üretilen kodu görür.

Teslimde en çok işe yarayan özellikler:

• Ready for dev durumu: bir frame, component, instance ya da section'ı hazır olarak işaretlersiniz; geliştirici neyin bittiğini tahmin etmek zorunda kalmaz.
• Annotations: ölçü, davranış ve özel notları doğrudan tasarımın üzerine eklersiniz.
• Kod görünümü: CSS, iOS ve Android için otomatik kod; dil ve birim seçilebilir.
• Compare changes: bir ekranın önceki sürümüyle farkını gösterir.
• Figma for VS Code: geliştirici dosyayı kod editöründen çıkmadan inceler.

Code Connect ise ekibin gerçek component kodunu Dev Mode'da göstermesini sağlar; Figma'ya göre bu özellik Organization ve Enterprise planlarında var. Küçük projelerde buna ihtiyaç duymuyorum. Ancak otomatik üretilen CSS'i olduğu gibi kopyalamamanızı öneririm; o kod bir başlangıç noktasıdır, üretim kodu değil.

Görselleri ve ikonları hangi formatta dışa aktarmalısınız?

Figma, dışa aktarma için PNG, JPG, SVG ve PDF formatlarını destekler. Dev Mode ayrıca ikonları otomatik algılayıp indirilebilir varlık olarak listeleyebilir. Yine de hangi varlığın hangi formatta çıkacağını tasarımcı olarak ben belirliyorum.

Genel kuralım şu: ikon ve logo SVG, fotoğraf için JPG ya da geliştiricinin WebP'ye çevireceği yüksek kaliteli bir kaynak, şeffaflık gereken görseller PNG. Her varlığa export ayarını tasarım dosyasında ekliyorum. Böylece geliştirici tek tek sormak zorunda kalmıyor.

Görsel boyutu sayfa hızını doğrudan etkiler. Figma'dan 2x çıkardığınız bir kahraman görseli birkaç megabayt tutabilir. Yayına almadan önce görselleri sıkıştırmak için resim küçültme aracını kullanabilirsiniz. Hızın sıralamaya ve satışa etkisini site hızı ve SEO yazımda anlattım.

Son olarak favicon ve sosyal paylaşım görselini de export listesine ekliyorum. Bu küçük varlıklar çoğu projede son güne kalıyor ve ekip onları aceleyle hazırlıyor. Onları tasarım sistemiyle birlikte hazırlamak marka tutarlılığını koruyor.

Figma ile web arayüz tasarımı sürecinde en sık hangi hataları yaparsınız?

Bu bölümde arayüzün kendisindeki kullanılabilirlik hatalarına girmiyorum; onları arayüz tasarımındaki UX hatalarını anlattığım ayrı yazıda ele aldım. Burada sürece ait hataları topluyorum, çünkü bunlar genellikle projeyi haftalarca uzatıyor.

• Brief olmadan görsel tasarıma başlamak ve yapıyı renkli ekranlar üzerinden tartışmak.
• Bileşen kurmadan ekran çizmek; on sayfa sonra aynı düğmenin yedi farklı hali ortaya çıkıyor.
• Auto layout kullanmamak; metin değişince her ekranı elle düzeltmek gerekiyor.
• Yalnızca masaüstü çizmek ve mobil düzeni geliştiriciye bırakmak.
• Katmanları adlandırmamak; Dev Mode'da "Group 12" gören geliştirici neyin ne olduğunu tahmin ediyor.
• Hover, focus, hata ve boş durum gibi halleri unutmak.
• Prototipi test etmeden onaya sunmak.

Bu listedeki her madde, önceki bölümlerdeki bir adımın atlanmasından doğuyor. Dolayısıyla çözüm yeni bir araç değil, sıraya sadık kalmak. Kendi projelerimde kontrol listesini her aşama sonunda gözden geçiriyorum ve eksik varsa bir sonraki aşamaya geçmiyorum.

Süreç özeti: hangi aşama hangi çıktıyı üretir?

Aşağıdaki tablo, anlattığım adımları çıktı ve onay noktasıyla birlikte özetliyor. Kendi projenizi planlarken bir kontrol listesi olarak kullanabilirsiniz.

Süreler proje ölçeğine göre değişir. Saha tecrübeme dayalı bir başlangıç aralığı olarak söyleyeyim, garanti değil: beş şablonlu bir kurumsal sitede brief ve site haritası birkaç gün, tasarım sistemi ve ekranlar birkaç hafta sürüyor. Test ve teslimi ayrıca planlamanız gerekiyor.

Figma ile web arayüz tasarımını ne zaman dışarıdan almalısınız?

Figma'yı öğrenmek zor değil; ücretsiz planla başlayıp temel özellikleri birkaç günde kavrayabilirsiniz. Asıl zorluk araç değil, karar vermek: hangi blok önce gelmeli, hangi düğme hangi metni taşımalı, hangi bileşen sisteme girmeli. Bu kararlar deneyim ister.

Kendi başınıza ilerleyebileceğiniz durumlar: tek sayfalık bir tanıtım sitesi, mevcut bir şablonun küçük uyarlaması ya da iç ekip için hızlı bir prototip. Profesyonel destek almanızı önerdiğim durumlar ise şunlar: satış getirmesi beklenen bir kurumsal site, çok dilli yapı, e-ticaret akışları ve birden fazla geliştiricinin çalışacağı projeler.

Ben web tasarım hizmetimde bu yazıdaki sırayı birebir uyguluyorum ve Figma dosyasını projenin sonunda size teslim ediyorum. Tasarımın dönüşüm tarafını merak ediyorsanız dönüşüm odaklı web tasarım yazısı iyi bir sonraki adım olur. Projenizi konuşmak isterseniz iletişim sayfasından bana yazabilirsiniz.