Tasarım Odaklı Yazılım: Kodlamadan Önce Neden Tasarımı Konuşturmalıyız?

Modern web projelerinde başarının ölçüsü sadece çalışan bir uygulama çıkarmak değil; doğru problemi, doğru kullanıcıya, doğru deneyimle sunabilmek. İşte bu yüzden, iyi bir frontend kodundan önce iyi bir tasarım konuşmak zorundayız.

Benim için bir proje; fikir aşamasından canlıya çıkışa, ölçümlemeden iterasyona kadar uçtan uca yönetilen yaşayan bir organizma. Kod, bu organizmanın dili. Ama bu dili belirleyen şey, tasarımın kurduğu mimari.

Proje Kod Değil, Bir Ekosistemdir

Bir projeye sadece “kaç sayfa, kaç komponent, kaç API?” diye bakarsanız, o proje daha en baştan eksik doğar. Çünkü:

• Kullanıcı akışı net değilse, component mimarisi de net olamaz.

• Görsel hiyerarşi oturmadan state yönetimi üzerine konuşmak, yanlış problemi çözmek demektir.

• UX kararları alınmadan performans optimizasyonu yapmak, körlemesine koşmaya benzer.

Ben projelere daima şu soruyla başlıyorum:

“Kullanıcı bu interface ile hangi problemi, hangi bağlamda, hangi beklentiyle çözecek?”

Bu soruya alınan yanıtlar, aslında Vue/Nuxt tarafında kuracağımız mimariyi, routing yapısını, component ağacını ve hatta store stratejisini doğrudan etkiliyor.

Tasarım Süreci: Yazılım Mimarisi İçin Blueprint

Tasarım aşaması, benim için “önceden hazırlanmış bir görsel” değil, yazılım mimarisine dönüşecek bir blueprint.

Bu aşamada özellikle şunlara odaklanıyorum:

• Kullanıcı akışları (user flows)

• Bilgi mimarisi (information architecture)

• Komponent bazlı UI tasarımı (design system yaklaşımı)

• Responsive davranışlar ve breakpoint mantığı

• Edge case’ler (boş state, loading state, error state vs.)

Örneğin, bir dashboard tasarlarken sadece kartların görünümüyle ilgilenmem. Aynı zamanda:

• Hangi kartın tekrar kullanılabilir bir component olacağını,

• Hangi datanın props, hangisinin store’dan geleceğini,

• Hangi alanların ileride “feature flag” ile yönetilebilir olması gerektiğini

daha tasarım aşamasında zihnimde kurgularım.

Bu sayede tasarım bittiğinde aslında Vue/Nuxt tarafında kullanacağım component yapısı zihnimde hazır hale gelir.

Prototipleme ve AI Araçları: Hızlı Düşün, Akıllı Test Et

İlk fikir ile üretim kodu arasında, test edilebilir bir ara katman gerekiyor: prototipler.

Figma gibi klasik araçların yanında, artık AI destekli araçlar da (Stitch, Uizard vb.) işimi ciddi anlamda hızlandırıyor:

• Wireframe’den hızlıca high-fidelity prototipe geçebilmek

• Tasarım varyasyonlarını saniyeler içinde deneyebilmek

• Kullanıcı akışlarını animasyonlu prototiplerle test etmek

• Müşteriye “bitmişe yakın” bir deneyim gösterip, baştan alignment almak

Bu ne sağlıyor?

• Gereksiz revizyonları azaltıyor.

• Geliştirme aşamasında “Bu buton burada mı olacaktı?” sorusunu yok ediyor.

• Geliştirici ekibin (veya tek başına çalışan biri olarak benim) kod yazarken zihnini sadece teknik çözüme odaklamasını sağlıyor.

• Kısacası, prototipleme ve AI araçları, tasarım sürecini sadece estetik bir adım olmaktan çıkarıp, ürün stratejisinin hızlandırıcısı haline getiriyor.

Tasarımdan Koda: Hiyerarşiyi Korumak

Tasarımda kurulan görsel ve içerik hiyerarşisini koda taşımak, frontend’in en kritik sorumluluğu.

Vue.js/Nuxt.js ile çalışırken özellikle şu prensiplere dikkat ediyorum:

• Component bazlı hiyerarşi: Tasarımdaki her tekrar eden pattern, kodda potansiyel bir component adayıdır.

• Atomic yaklaşım: Button, input, badge gibi atomlar; card, modal, list gibi moleküller; page layout’lara kadar giden ölçeklenebilir bir yapı.

• Layout mantığı: Nuxt layout’ları ile tasarımdaki ana iskeleti (header, sidebar, content, footer) korumak.

Bu hiyerarşiyi korumanın en güvenilir yollarından biri de BEM gibi naming metodolojileridir.

Neden BEM Hala Kritik?

BEM (Block, Element, Modifier) kullanmamın sebepleri:

• Tasarımdaki hiyerarşi doğrudan class isimlerine yansır.

• Takımda biri bile tasarımdan HTML çıktısına baksa, yapıyı anlayabilir.

• Komponent izolasyonu artar, stil çakışmaları azalır.

• Refactor süreçlerinde neyin nerede kullanıldığını okumak çok daha kolaydır.

Örnek bir kart component yapısı:

Block: card

Element: card__title, card__subtitle, card__actions

Modifier: card--highlighted, card--compact

Bu yapı, tasarım dosyasındaki layer isimleri ve hiyerarşiyle birebir örtüşürse, geliştirme süreci de çok daha tutarlı olur.

Tipografi Standartları: Görsel Dil, Kodun Ritmi

Tipografi, tasarımın omurgasıdır. Rastgele font-size ve line-height kullanmak, hem görsel bütünlüğü hem de erişilebilirliği bozar.

Bu yüzden projelerde:

Global bir tipografi skala (örneğin: 12 / 14 / 16 / 18 / 24 / 32 / 40)

Vue komponentlerinde reusable typography bileşenleri (<BaseHeading>, <BaseText> gibi)

Nuxt’te layout ve page seviyesinde tutarlı heading kullanımı (h1 sadece sayfa başlığı, h2 ana bölüm, h3 alt bölüm vb.)

gibi standartlar belirliyorum.

Tipografi standartları, hem tasarımcıyla “aynı dili konuşmayı” hem de kod tarafında stil karmaşasını önlemeyi sağlıyor.

Tasarım Sadece Güzel Olmak Değil: Erişilebilir Olmak

UI’ın “güzel” olması, UX’in iyi olduğu anlamına gelmiyor. Hele ki erişilebilirlik göz ardı ediliyorsa, o tasarım aslında eksik.

WCAG standartları burada yalnızca kurallar bütünü değil, ürünün etik çerçevesi gibi. Tasarımı ve kodu kurgularken şu noktalara özellikle dikkat ediyorum:

• Kontrast oranları: Metin ve arka plan arasında minimum 4.5:1 kontrast oranını hedeflemek.

• Klavye ile gezilebilirlik: Menüler, modal’lar, form alanları sadece mouse değil, klavye ile de kullanılabilir olmalı.

• Doğru HTML semantiği: button yerine div kullanmak gibi hatalar, ekran okuyucular için büyük engel.

• ARIA etiketleri: Özellikle custom komponentlerde, ekran okuyuculara doğru bağlamı vermek için.

• Animasyon ve hareket: Hareket hassasiyeti olan kullanıcılar düşünülerek, yoğun animasyonların alternatifini sunmak.

Erişilebilirlik, projeye sonradan yamalanacak bir “feature” değil, tasarımın ilk çizgisinden itibaren var olması gereken bir yaklaşım.

Sonuç: Daha Az Hata, Daha Yüksek Deneyim

Tasarım odaklı yazılım yaklaşımı, aslında şunu sağlıyor:

• Geliştirme sürecinde çıkan sürprizleri azaltıyor.

• Revizyon maliyetini aşağı çekiyor.

• Ekipler arası iletişimi (müşteri – tasarım – yazılım) netleştiriyor.

• Özellikle frontend tarafında, mimari kararları çok daha sağlam bir zemine oturtuyor.

• En önemlisi; kullanıcıya, gerçekten düşünülmüş ve denenmiş bir deneyim sunuyor.

Benim çalışma biçimimde, proje; sadece kod yazdığım bir iş değil, tasarımdan bilgi mimarisine, prototipten Vue/Nuxt mimarisine, testten canlıya almaya kadar her aşamasında aktif rol aldığım bütünsel bir süreç.

Son cümleyi net kurayım:

Kod, tasarımın ardından gelir. Tasarımı konuşturmadan yazılan her satır, yarın çöpe gitme riski taşır; iyi tasarımla beslenen her satır ise ürünü kullanıcı deneyiminin zirvesine taşır.