Yazılım bitti, ekranlar beklediğimiz gibi değil: prototip aşaması nasıl yürütülür?

Teslim gününde "biz bunu böyle düşünmemiştik" cümlesinin arkasında genellikle kötü bir tasarımcı yoktur, hiç yapılmamış bir tasarım aşaması vardır. Doğru sıra şu: önce kullanıcının işi baştan sona nasıl yapacağı kararlaştırılır, sonra o akış tıklanabilir bir prototibe dönüşür, prototip işi gerçekten yapan birkaç kişiyle denenir, değişiklikler tasarım dosyasında yapılır ve ancak ondan sonra kod yazılır. Prototipte bir ekranı değiştirmek yarım saatlik iştir. Aynı değişikliği canlıya çıkmış bir üründe yapmak veri modeline, testlere, belgeye ve çoğu zaman mevcut kayıtlara dokunmayı gerektirir.

Tasarım aşaması, ekran güzelleştirme aşaması değildir

Çoğu işletme tasarımı renk ve font seçimi sanır, bu yüzden de "bize tasarım lazım değil, fonksiyon lazım" der. Oysa bu aşamada verilen kararların çoğu görsel değil, işlevseldir: sipariş oluştururken müşteri seçimi zorunlu mu, iskonto satır bazında mı toplamda mı uygulanıyor, onaya düşen kayıt onaylanana kadar düzenlenebilir mi, bir kullanıcı kendi oluşturduğu kaydı silebilir mi.

Bu sorular şartnamede genelde tek cümleyle geçer, ekranda ise bir yere oturmak zorundadır. Tasarım aşamasının asıl faydası buradadır: cevaplanmamış soruları koda girmeden önce görünür yapar. Yazılım şartnamesinin nasıl yazılacağını ayrıca anlattık, ama en iyi şartname bile ekrana düşene kadar soyut kalır.

Ekrandan önce akış çıkarın

Tasarıma ekran listesiyle başlamak yaygın bir hata. Ekran listesi size kaç sayfa yapılacağını söyler, kullanıcının işini bitirip bitiremeyeceğini söylemez.

Pratik yol, her ana iş için tek satırlık bir akış yazmak: "Depo sorumlusu gelen irsaliyeyi açar, kalemleri sayar, eksik olanı not düşer, kaydı kapatır, muhasebeye düşer." Bu cümleyi yazdığınız anda cevaplanacak şeyler ortaya çıkar. Eksik kalem olduğunda kayıt kapanabiliyor mu? Muhasebe reddederse kayıt kime geri döner? Sayım yarıda kalırsa ne oluyor?

Akışı çıkarırken mutlu senaryonun yanına üç durumu da yazın: veri hiç yokken ekran ne gösteriyor, işlem başarısız olduğunda kullanıcı ne görüyor, yetkisi olmayan biri o sayfaya geldiğinde ne oluyor. Bu üçü tasarımda atlandığında koda "sonra bakarız" diye girer ve genellikle kullanıcının karşısına "Bir hata oluştu" olarak çıkar. Hata mesajlarının nasıl tasarlandığı başlı başına bir konu.

Hangi sadakat seviyesi yeterli?

Prototip denince akla tek bir şey geliyor ama sadakat tek eksenli değil. Nielsen Norman Group'tan Kara Pernice'in düşük ve yüksek sadakatli prototipleri karşılaştıran yazısı üç ayrı boyuttan söz ediyor: etkileşim (bağlantılar gerçekten çalışıyor mu), görsellik (yerleşim ve hiyerarşi gerçek üründeki gibi mi) ve içerik (gerçek metin ve veri mi, yoksa yer tutucu mu). Bir prototip bu boyutların birinde yüksek, diğerinde düşük olabilir.

Seçim, neyi öğrenmek istediğinize bağlı. Akışın mantığını tartışıyorsanız kağıda çizilmiş kutular yeter ve hızlı değişir. Bir menü yapısının ya da uzun bir formun gerçekten kullanılabilir olup olmadığını ölçecekseniz tıklanabilir ve gerçek metinli bir prototip gerekir, çünkü kullanıcı yer tutucu metinle gerçek ürünü aynı okumaz.

Aynı yazı yüksek sadakatin iki riskini de sayıyor: cilalı görünen bir prototip karar vericilere ürün hazırmış hissi verir ve erken yayın baskısı yaratır, tasarımcı da emek verdiği ekrana bağlanıp değiştirmeye direnir. Prototibin üstüne "bu bir taslaktır" yazmak bunu tam olarak çözmez ama yardımcı olur.

Prototip, teklifi ve tarihi de netleştirir

Tıklanabilir bir prototip sadece kullanıcı için değil, sözleşme için de işe yarar. Aynı işe gelen tekliflerin kat kat farklı çıkmasının en büyük sebebi, firmaların aynı cümleden farklı kapsam anlamasıdır. Elinizde 20 ekranlık bir prototip varsa taraflar aynı şeye bakar.

Bu, tahminin de dayanağını değiştirir. "Stok modülü" ifadesine verilen süre tahmindir; "şu altı ekran, şu dört durum, şu iki entegrasyon" ifadesine verilen süre hesaptır. Yazılımda tahmin ve teslim tarihi yazısındaki belirsizlik aralığı, prototip varken belirgin biçimde daralır. Sabit fiyatlı çalışmayı düşünüyorsanız prototip neredeyse zorunludur, çünkü sabit fiyat sözleşmesinde riski taşıyan taraf kapsamın net olmasına mecburdur.

Zaman kısıtınız varsa işin tamamını değil, en riskli akışı prototipleyin. Jake Knapp'ın Google Ventures'ta geliştirdiği tasarım sprinti tam olarak bunu yapar: beş gün içinde problemi haritalamak, çözüm eskizleri çıkarmak, birini seçmek, cuma gününe yetişecek kadar bir prototip yapmak ve aynı hafta kullanıcıyla test etmek. Her proje için gerekli değil, ama "hangi yaklaşımı seçeceğimize karar veremiyoruz" durumunda aylarca süren tartışmayı bir haftaya indirir.

Beş kullanıcı yeter, ama tek seferde değil

Kullanıcı testi pahalı ve uzun bir araştırma süreci gibi düşünülüyor, oysa değil. Jakob Nielsen'in 2000 yılında yayımladığı ve hâlâ en çok atıf alan yazısı şu dağılımı veriyor: tek kullanıcı kullanılabilirlik sorunlarının ortalama yüzde 31'ini ortaya çıkarıyor, beş kullanıcı yüzde 85'ini, tamamını görmek için en az 15 kullanıcı gerekiyor.

Yazının asıl önerisi rakamdan daha değerli: 15 kişilik bütçeniz varsa bunu tek seferde harcamayın, beşer kişilik üç tura bölün. Her turda bulduğunuz sorunları düzeltip bir sonraki turda yeni tasarımı test edersiniz. İlk turda görünen bariz sorunlar ortadan kalkınca, altlarında kalan daha derin sorunlar görünür hale gelir.

Test etmek için laboratuvar da gerekmiyor. Beş kişiye prototipi açıp "şu işi yapar mısınız" demek ve sessizce izlemek yeterli. Zor olan kısım izlerken müdahale etmemek. Kullanıcı takıldığında "oraya değil, şuraya tıklayın" dediğiniz an o testten öğrenebileceğiniz şeyi kaybedersiniz.

Kurum içi yazılımda "kullanıcı" kimdir?

Şirket içi bir sistem yaptırırken tasarım toplantılarına genelde müdürler girer. Sistemi günde sekiz saat kullanacak kişi ise o toplantıda yoktur.

Bu fark sonucu belirler. Müdür raporu ve özeti kullanır, operasyon personeli aynı ekrana günde yüzlerce kez girer. İkisinin ihtiyacı aynı değildir: biri için net bir pano önemlidir, diğeri için klavyeden çıkmadan kayıt açabilmek önemlidir. Prototibi iki grupla ayrı ayrı deneyin, ve operasyon tarafını ikinci sıraya koymayın. Devreye alma sonrası benimsenmeyi belirleyen şey çoğunlukla bu ikinci gruptur.

Prototip ürün değildir, görünümü aksini söylese bile

Yapay zeka destekli araçlar artık bir açıklamadan çalışır görünen ekranlar üretebiliyor. Bu, prototip aşamasını gerçekten hızlandırıyor: eskiden iki günde çizilen akış birkaç saatte tıklanabilir hale geliyor.

Risk, çıkan şeyin "neredeyse bitmiş ürün" sanılması. Üretilen ekranlar yetkilendirme, çoklu kullanıcı, hata durumları, performans, erişilebilirlik ve veri bütünlüğü açısından hiçbir şey vaat etmez; bunlar prototipin işi de değildir zaten. Kararı veren kişiye bu sınırı baştan söylemek, sonradan "hani ekranlar hazırdı" tartışmasını önler.

Bu kodun bir kısmını gerçekten kullanacaksanız, normal kod inceleme sürecinden muaf tutmayın. Yapay zeka ile yazılan kodu gözden geçirme kuralları burada da geçerli.

Tasarım sistemi ikinci ekrandan sonra başlar

Tek bir ekran için tasarım sistemine gerek yok. Yirmi ekrana çıktığınızda, aynı düğmenin üç farklı yeşili, aynı tablonun dört farklı satır yüksekliği olur ve her yeni ekran sıfırdan tartışılır.

Çözüm renk, boşluk, tipografi ve bileşen kararlarını bir kez verip tekrar kullanmaktır. Bu kararları makine okunur biçimde saklamak için ortak bir format da var: Design Tokens Community Group'un Design Tokens Format Module'ü 28 Ekim 2025'te 2025.10 sürümüyle ilk kararlı halini aldı. Resmî bir W3C standardı değil, bir topluluk raporu, ama tasarım aracı ile kod tabanı arasında renk ve ölçü değerlerini taşımak için çoğu araç bu formatı destekliyor.

Küçük bir projede bunu abartmayın. On ekranlık bir iç uygulama için bileşen kütüphanesi kurmak, asıl işten çalınan zamandır. Ölçüt şu: aynı bileşeni üçüncü kez kopyalayıp yapıştırıyorsanız artık tanımlama vaktidir.

Erişilebilirlik ve kenar durumlar tasarımda kararlaştırılır

Erişilebilirliğin büyük kısmı kod değil, tasarım kararıdır. Metin ile arka plan arasındaki kontrast oranı (WCAG 2.2 AA seviyesinde normal boyutlu metin için 4,5:1), dokunma hedeflerinin boyutu (2.5.8 ölçütünde en az 24x24 CSS pikseli ya da yeterli boşluk), bilginin yalnızca renkle anlatılmaması: hepsi tasarım dosyasında çözülebilecek, koda girdikten sonra düzeltmesi pahalı şeyler. WCAG 2.2 uyumunu ayrı bir yazıda ele aldık.

Aynı mantık kenar durumlar için de geçerli. Ürün adı 90 karakter olduğunda tablo ne yapıyor, listede 50 bin kayıt varken sayfalama nasıl çalışıyor, kullanıcı yarım bıraktığı formdan çıkarken ne oluyor. Bunları tasarımda çizmek dakikalar alır, canlıda fark etmek bir sonraki sürümü bekletir.

Koda geçen asıl çıktı, güzel ekran değildir

Tasarım aşamasının çıktısı sadece prototip dosyası değildir. Geliştiricinin ihtiyacı olan şey şunlardır: her ekranın boş, dolu, yükleniyor, hata ve yetkisiz hallerinin ne olduğu; hangi alanın zorunlu olduğu ve doğrulama kuralları; liste sıralaması ve sayfalama davranışı; mobil ve dar ekranda yerleşimin nasıl değiştiği; kullanılan bileşenlerin ortak tanımı.

Bu liste aynı zamanda kabul ölçütlerinin iskeletidir. Prototip üzerinden yazılmış kabul ölçütleri, kabul testi ve devreye alma aşamasında "şöyle olacaktı" tartışmasını büyük ölçüde bitirir, çünkü iki taraf da aynı ekrana bakıp imza atmıştır.

Ne zaman prototip yapmamalı

Her işin prototibe ihtiyacı yok ve gereksiz tasarım aşaması projeyi yavaşlatır. Mevcut bir ekrana kolon eklemek, bilinen bir kalıbı (giriş ekranı, şifre sıfırlama, standart liste filtresi) uygulamak ya da üç kişinin kullanacağı basit bir iç araç yapmak için tıklanabilir prototip çoğu zaman israf olur. Kabaca eskiz yeterlidir.

Prototip asıl şu durumlarda kendini öder: akış yeni ve kimse nasıl işleyeceğinden emin değilse, aynı iş için birden fazla çözüm tartışılıyorsa, yazılımı yaptıran ile kullanacak olan farklı kişilerse, ya da kapsam üzerinden sabit fiyat konuşulacaksa.

Bu projede yapabilecekleriniz

• Yazılımın desteklediği her ana iş için tek paragraflık akış yazın; her akışın sonuna boş, hata ve yetkisiz durumunu ekleyin.
• En riskli iki akışı seçip tıklanabilir prototip çıkarın, kalanını eskiz seviyesinde bırakın.
• Prototibi işi gerçekten yapan beş kişiyle deneyin; müdürlerle değil, operasyonla başlayın ve izlerken müdahale etmeyin.
• Bulduklarınızı düzeltip ikinci bir beş kişilik tur yapın; tek büyük test yerine iki kısa tur daha fazla şey gösterir.
• Prototip ekranlarından kabul ölçütü listesi çıkarın ve teklif ya da sözleşme ekine koyun.
• Kontrast oranı, dokunma hedefi boyutu ve renge bağımlı olmayan bilgi aktarımını tasarım dosyasında kontrol edin.
• Üçüncü kez kopyaladığınız bileşeni ortak bileşen olarak tanımlayın; bundan öncesi için tasarım sistemi kurmayın.