Prototip Onayından Geliştirmeye Geçiş: Hangi Kararlar Artık Değişmez?

Prototip onayı geldiğinde tasarım ekibi işi teslim ettiğini, geliştirme ekibi ise başlamaya hazır olduğunu düşünür. Sorun, iki tarafın onayın neyi kapsadığı konusunda aynı şeyi anlamamış olabilmesidir. Üçüncü iki haftalık sürümde gelen "bu form aslında iki adımlıydı" cümlesi, çoğu zaman geliştirmenin hatası değil, geçiş anında kilitlenmemiş bir kararın sonucudur.

Bu yazıda tasarım ve geliştirme ekiplerinin onaylı prototip üzerinde hangi kararları birlikte kilitlediğini, hangilerinin bilerek esnek bırakıldığını ve onaydan sonra gelen değişiklik taleplerinin nasıl ele alınabileceğini somut örneklerle anlatıyoruz. Örnekler varsayımsal senaryolardır; belirli bir müşteri projesini yansıtmaz.

01Prototip onayı neyi kesinleştirir?

Onay, prototipteki her pikselin değişmeyeceği anlamına gelmez. Daha doğru tanım şudur: prototip onayı, geliştirme ekibinin tahmin yürütmeden iş planlayabileceği referansı oluşturur. Bu referansın içinde üç farklı esneklik düzeyi vardır.

Bu üçlü ayrımı onay toplantısında yazılı hale getirmek, sonraki tartışmaların büyük kısmını önler. Çalışma sürecimizde tasarım adımı onaylı prototiple kapanır; geliştirme ise iki haftalık sürümlerle ilerler. Dolayısıyla onaylanan şey, sürümlere bölünecek işin ortak haritasıdır.

02Tasarım ve geliştirme birlikte hangi kararları kilitler?

Aşağıdaki beş karar, geçiş toplantısında iki ekibin birlikte gözden geçirdiği çekirdek listedir. Her biri için bir randevu uygulaması senaryosu kullanıyoruz.

1. Ekran envanteri ve ana akışlar. Kaç ekran var, hangisinden hangisine geçiliyor? Senaryoda 14 ekran ve üç ana akış listelenir. Listede olmayan ekran, kapsam dışı sayılır ve ayrıca değerlendirilir.
2. Kullanıcı rolleri ve yetkiler. Müşteri, personel ve yönetici ne görür, ne yapabilir? Rol eklemek sonradan en pahalı değişikliklerden biridir; çünkü yetkilendirme mantığı veri modeline ve testlere dokunur.
3. Veri alanları ve doğrulama kuralları. Hangi alan zorunlu, telefon numarası hangi biçimde alınır, randevu iptali için son süre nedir? Bu kurallar prototipte görünmüyorsa, geliştirme sırasında tahmin edilir ve sonra düzeltilir.
4. Entegrasyon sınırları. Randevu verisi CRM'e tek yönlü mü aktarılır, yoksa çift yönlü mü senkronize edilir? Yön, sıklık ve hata durumunda ne olacağı kararlaştırılmadan sürüm planı yapılamaz.
5. Tasarım sistemi ve bileşen durumları. Renk, yazı tipi ve bileşen kütüphanesi kilitlenir. Unutulan kısım ise çoğunlukla bileşenlerin durumlarıdır: boş liste, yükleniyor, hata, yetkisiz erişim. Bu durumlar prototipte yoksa, geliştirici kendi yorumunu ekler ve tasarım tutarsızlaşır.

Küçük bir kural işe yarar: bir karar hem tasarımı hem veri modelini hem de test senaryolarını etkiliyorsa, onay sonrası kilitli sayılmalıdır.

03Ölçülebilir çıtalar: performans, erişilebilirlik, platform ve güvenlik

Prototip yalnızca görünümü değil, kalite çıtalarını da sabitlemek için iyi bir andır. "Hızlı olsun" bir hedef değildir; ölçülebilir bir eşik gerekir.

• Performans: web.dev Core Web Vitals sayfası, iyi bir deneyim için en büyük içerik boyanmasının (LCP) 2,5 saniye veya altında, etkileşim gecikmesinin (INP) 200 milisaniyenin altında, düzen kaymasının (CLS) 0,1 veya altında olmasını önerir. Bu eşikleri hedef olarak yazmak, tasarımdaki büyük görsellerin ve ağır animasyonların maliyetini erkenden görünür kılar.
• Erişilebilirlik: Klavyeyle gezinme, form etiketleri, yeterli renk kontrastı ve ekran okuyucu uyumu tasarım kararıdır; sonradan yamanması zordur. MDN erişilebilirlik belgeleri bu konularda genel bir başlangıç noktasıdır.
• Platform kuralları: Mobil uygulamada dokunma hedeflerinin boyutu ve gezinme kalıpları platforma göre değişir. Apple Human Interface Guidelines iOS tarafı için bu kuralları tanımlar; prototipte küçük kalan bir buton mağaza incelemesinde ve kullanımda sorun çıkarabilir.
• Güvenlik gereksinimleri: Oturum yönetimi, yetkilendirme ve girdi doğrulama gibi konular prototip aşamasında ekran kararlarına bağlanır. OWASP Application Security Verification Standard, bu gereksinimleri başlıklar halinde düzenlemek için kaynak olarak kullanılabilir.

Bu çıtaları onay notuna eklediğinizde test ekibi de neyi ölçeceğini bilir; kabul ölçütü yorumdan çıkıp veriye dayanır.

04Onaydan sonra gelen değişiklik talepleri nasıl ele alınır?

Değişiklik talebi gelmesi olağandır; kullanıcılar çalışan sürümü gördükçe yeni fikirler çıkar. Önemli olan taleplerin tek bir yoldan, kayıt altında işlenmesidir. Aşağıdaki akış sade bir çerçeve sunar.

1. Talebi yazılı alın. Hangi ekran ve hangi akış etkileniyor, neden isteniyor? Sözlü talep, sonraki toplantıda farklı hatırlanır.
2. Düzeyini sınıflandırın. Esneyen mi, kontrollü değişen mi, yeni kapsam mı? Önceki bölümdeki tablo burada kullanılır.
3. Etkiyi tasarım, geliştirme, test ve entegrasyon açısından birlikte değerlendirin. Küçük görünen talep çoğu zaman birden fazla katmana dokunur.
4. Karar verin ve kaydedin. Talep bir sonraki iki haftalık sürüme alınır, ileri bir sürüme ertelenir ya da ayrı kapsam olarak yazılı teklife bağlanır. Teklif kalem kalem hazırlandığı için kapsam artışı da kalem olarak görünür.
5. Prototipi güncelleyin. Kabul edilen her değişiklik prototipe işlenir; aksi halde onaylı prototip zamanla gerçeği yansıtmayan bir belgeye dönüşür.

Örnek 1: "Düğme rengi marka rengine biraz yaklaşsın." Bu, tasarım sistemindeki tek bir değerin değişmesidir. Esneyen düzeye girer ve aynı sürümde çözülür.

Örnek 2: "Ödeme adımına kupon alanı eklensin." Yeni bir alan, doğrulama kuralı, fiyat hesabında değişiklik, hata durumları, bildirim metni ve test senaryoları demektir. Kontrollü değişen düzeye girer; etki analizi yapılır, sürüm planına nasıl sığacağı kararlaştırılır.

Geçiş toplantısı kontrol listesi:

• Ekran envanteri ve ana akışlar imzalı sürümle eşleşiyor mu?
• Roller, yetkiler ve veri alanları yazılı mı?
• Boş, yükleniyor ve hata durumları prototipte var mı?
• Entegrasyon yönü ve hata davranışı netleşti mi?
• Performans, erişilebilirlik ve güvenlik çıtaları kabul ölçütü olarak yazıldı mı?
• Değişiklik talebinin hangi kanaldan ve kimin onayıyla işleneceği belli mi?

05Sık sorulan sorular

Prototip onayından sonra hiç değişiklik yapılamaz mı?

Yapılabilir. Amaç değişikliği yasaklamak değil, görünür ve kayıtlı hale getirmektir. Metin ve ince görsel ayarlar çoğunlukla sürüm içinde çözülür; yeni ekran, rol ya da entegrasyon gibi talepler etki analiziyle değerlendirilir ve gerekirse yazılı kapsam değişikliğine dönüşür.

Prototip her ekranı kapsamalı mı?

Ana akışlar ve kritik durumlar (hata, boş durum, yetkisiz erişim) mutlaka kapsanmalıdır. İkincil ekranlar için tek bir örnek ekran ve davranış kuralı yeterli olabilir; ancak bu ekranların envanterde listelenmesi gerekir. Listede olmayan ekran, kapsam tartışmasının en yaygın kaynağıdır.

Onayı kim vermeli?

İş tarafından karar yetkisi olan kişi, ürün ya da proje sorumlusu ve teknik sorumlu birlikte onay vermelidir. Onayın hangi prototip sürümüne verildiği ve tarihi yazılı kaydedilirse, sonraki sürümlerle karışma riski azalır.

06Sonuç

Prototip onayından geliştirmeye geçiş, iki ekibin aynı belgeye bakarak aynı şeyi anladığını doğruladığı bir andır. Ekran envanteri, roller, veri kuralları, entegrasyon sınırları ve tasarım sistemi birlikte kilitlendiğinde; metinler ve ince ayarlar esnek bırakıldığında; yeni talepler yazılı bir akıştan geçtiğinde geliştirme sürümleri öngörülebilir kalır. Bir projeyi bu çerçevede planlamak isterseniz yazılım geliştirme hizmetimizin kapsamına göz atabilirsiniz.