MVP Tasarımı: İlk Sürümde Neyi Tasarlamalı, Neyi Bırakmalı?

"Önce MVP'yi çıkaralım" cümlesi ürün ekiplerinde iki farklı anlama gelebilir. Bazıları için MVP, öğrenmek için tasarlanmış dar ama sağlam bir ilk sürümdür. Bazıları için ise "şimdilik idare etsin" diye aceleyle hazırlanmış her şeydir. İkinci yorum, ürün fikri hakkında yanlış sonuçlara yol açar: kullanıcılar ürünü bıraktığında bunun fikirden mi, yoksa yarım kalmış bir kayıt akışından mı kaynaklandığını ayırt edemezsiniz. Bu yazı ilk sürümde neyin tasarlanması, neyin bilinçli olarak bırakılması gerektiğini somut ölçütlerle ele alıyor.

Önce en riskli varsayımı yazın

MVP'nin kapsamı özellik listesinden değil, yanıtlamak istediğiniz sorudan çıkar. GOV.UK Service Manual alfa aşamasını anlatırken bunun özünü tek cümlede verir: alfanın kritik bir parçası en riskli varsayımlarınızı belirleyip test etmektir 3. Aynı rehber, bu aşamada yalnız fikirleri test etmeye yetecek kadar karmaşık şeyler yapılmasını önerir 3. Keşif aşaması için de araştırma bunu gösteriyorsa o noktada durmanın bir başarısızlık olmadığını, aksine zaman ve para kazandırdığını belirtir 4.

Varsayımları yazmanın pratik bir yolu şudur:

1. Kullanıcı varsayımları: "Küçük işletme sahipleri faturalarını telefondan kesmek istiyor."
2. Değer varsayımları: "Faturayı iki dakikadan kısa sürede kesebilmek, mevcut yöntemlerini bırakmalarına yeter."
3. Kullanılabilirlik varsayımları: "Kullanıcılar vergi oranı ve müşteri bilgisini yardım almadan girebilir."
4. Teknik ve iş varsayımları: "Gerekli entegrasyonlar ilk sürümde kurulabilir, ürün sürdürülebilir bir gelir modeliyle çalışır."

Ardından her varsayım için iki soruyu yanıtlayın: yanlış çıkarsa ürün ne kadar etkilenir ve şu an elimizde ne kadar kanıt var? Etkisi yüksek, kanıtı az olan varsayım en riskli olandır. MVP'nin ana akışı bu varsayımı sınayacak şekilde seçilir.

Kapsamı daraltmak: MoSCoW

MoSCoW, Agile Business Consortium'un yaygınlaştırdığı bir önceliklendirme yöntemidir ve gereksinimleri dört gruba ayırır 1:

Kaynağa göre Must Have kısaltması "Minimum Usable SubseT", yani asgari kullanılabilir alt küme anlamına da gelir; Must Have kalemleri emeğin genellikle yüzde 60'ını aşmamalı, Could Have kalemleri ise yaklaşık yüzde 20'sini oluşturmalıdır 1. Bu pay, takvim sıkıştığında bırakılabilecek bir esneklik alanı bırakır. Yöntemin en değerli kısmı genellikle "Won't Have this time" listesidir: neyin yapılmayacağı yazılı olduğunda, aynı tartışma her hafta yeniden açılmaz.

Beklenen ile fark yaratanı ayırmak: Kano

Noriaki Kano ve arkadaşlarının 1984'te yayımladıkları çalışma, kaliteyi tek boyutlu bir ölçek yerine iki boyutlu ele alır ve ürün özelliklerini çekici, olmazsa olmaz ve tek boyutlu kalite olarak sınıflandırır 2. Bu ayrım MVP kararlarında şöyle kullanılabilir:

• Olmazsa olmaz özellikler: Varlıkları fark edilmez, yoklukları ise ciddi memnuniyetsizlik yaratır. Şifre sıfırlama, girilen verinin kaybolmaması, anlaşılır hata mesajları bu gruptadır. MVP'den çıkarılamazlar.
• Tek boyutlu özellikler: Ne kadar iyi yapılırsa memnuniyet o kadar artar; hız ve adım sayısı gibi. MVP'de "yeterli" seviyede tutulup sonra iyileştirilebilir.
• Çekici özellikler: Beklenmez, varsa memnuniyet yaratır, yoksa şikâyet doğurmaz. İlk sürümde genellikle bırakılabilir; ama ürünün farkı tam da bu özellikse en riskli varsayım odur ve MVP'ye girmelidir.

Kano sınıflandırması bir tahmin olarak değil, kullanıcılardan toplanan veriyle yapılmalıdır; orijinal çalışmada sınıflandırma tüketici anketleriyle doğrulanmıştır 2.

İlk sürümde de iyi yapılması gerekenler

Kapsam daraldığında bazı alanlar "sonra hallederiz" listesine kayar. Aşağıdaki tablo hangi alanların ertelenebileceğini, hangilerinin ertelenmemesi gerektiğini özetler:

Erişilebilirlikte başvuru noktası W3C'nin WCAG 2 yönergeleridir; W3C en son sürümün, yani WCAG 2.2'nin kullanılmasını teşvik eder 8. Mobil uygulamalar için temel kontrolleri mobil uygulama erişilebilirliği yazısında, ilk kullanım akışını ise onboarding tasarımı yazısında ayrıntılı ele aldık.

Mağaza kuralları kapsamı etkiler

Mobil bir MVP yalnız kullanıcıya değil, mağaza incelemesine de çıkar ve bazı kurallar kapsamı doğrudan belirler.

Hesap silme. Apple'ın 8 Haziran 2026'da güncellenen App Store inceleme kurallarının 5.1.1(v) maddesine göre, uygulamanız önemli hesap tabanlı özellikler içermiyorsa kullanıcıların giriş yapmadan kullanabilmesine izin vermelisiniz; uygulamanız hesap oluşturmayı destekliyorsa uygulama içinden hesap silme de sunmalısınız 5. Apple'ın bu konudaki destek sayfası, kuralın 30 Haziran 2022'den beri gönderilen uygulamalara uygulandığını, seçeneğin kolay bulunur olması gerektiğini ve yalnız geçici devre dışı bırakma sunmanın yeterli olmadığını belirtir. Silme işlemi bir web sitesinde tamamlanıyorsa o sayfaya doğrudan bağlantı verilmeli, işlem zaman alıyorsa kullanıcı bilgilendirilmelidir 6.

Google Play de uygulama içinden hesap oluşturulabiliyorsa ya da uygulama kullanıcıyı dışarıdaki bir hesap oluşturma akışına yönlendiriyorsa, hem uygulama içi bir silme yolu hem de kullanıcıların silme talep edebileceği bir web bağlantısı ister 7.

Tamamlanmışlık ve asgari işlev. Apple'ın kuralları, incelemeye gönderilen uygulamaların son sürüm olmasını, yer tutucu metin ve geçici içeriğin gönderimden önce temizlenmesini ister. Ayrıca uygulamanın yeniden paketlenmiş bir web sitesinin ötesine geçen özellik, içerik ve arayüz sunmasını bekler 5. Yani "şimdilik boş kalsın" denen sekmeler ve "yakında" yazan ekranlar, MVP'nin mağazadan dönmesine neden olabilir. Mağaza gereksinimlerinin tamamını App Store ve Google Play tasarım gereksinimleri yazısında topladık.

Başarı ölçütünü yayından önce yazın

MVP bir öğrenme aracıysa, neyi öğrenmek istediğinizi yayından önce yazmanız gerekir. Aksi hâlde sonuçlar her zaman yorumlanabilir: kullanım düşükse "henüz pazarlama yapmadık", yüksekse "fikir tuttu" denir. Ölçütü yazarken şu üç unsuru belirleyin:

• Davranış: Hangi eylem, varsayımın doğru olduğunu gösterir? Fatura örneğinde "ilk faturayı kesmek" değil, "ikinci ayda yeniden fatura kesmek" daha güçlü bir işarettir; tek seferlik merak ile gerçek kullanım farklıdır.
• Eşik: Hangi seviyenin altı varsayımı zayıflatır? Bu eşiği ekip kendi bağlamına göre belirler; başka ürünlerden alınmış bir oranı hedef yapmak yanıltıcı olabilir.
• Süre: Ne kadar süre sonra karar verilecek? Haftalık kullanılan bir ürünle yılda bir kullanılan bir ürünün değerlendirme süresi aynı olamaz.

Nicel ölçütü nitel gözlemle tamamlayın. Kullanıcıların ilk görevi tamamlarken nerede zorlandığını görmek için birkaç kısa, moderasyonlu oturum, kullanım verisinin "ne" olduğunu söylediği yerde "neden" sorusuna yanıt verir. Bu oturumlar ürün yayına girmeden, yüksek doğruluklu bir prototiple de yapılabilir; böylece MVP'nin ilk kullanıcıları akıştaki bariz sorunlarla karşılaşmaz.

Neyi bilinçli olarak bırakmalısınız?

Bırakılacak şeyler rastgele değil, gerekçeli olmalıdır. İlk sürümde genellikle güvenle ertelenebilecek kalemler şunlardır: ayarlar ekranındaki ikincil tercihler, kişiselleştirme, gelişmiş filtreler, çoklu dil, raporlama ekranları, ikinci ve üçüncü kullanıcı rolü, nadir kullanılan dışa aktarma biçimleri. Ertelenen her kalemi bir cümlelik gerekçeyle "Won't Have this time" listesine yazmak, sonraki sürüm planlamasını da kolaylaştırır 1.

Bırakılmaması gereken ise kullanıcının güvenini doğrudan etkileyen her şeydir: verinin kaybolmaması, hataların anlaşılması, hesabın kontrol edilebilmesi. Bu alanlarda bir ilk sürüm "küçük" olabilir ama "özensiz" olmamalıdır. Hata ve boş durum metinleri için boş durum ve hata mesajları yazısı iyi bir başlangıçtır.

İlk sürümünüzün kapsamını ekranlara dökmek ve mağaza kurallarıyla uyumlu bir akış kurmak isterseniz mobil uygulama tasarımı hizmetimizin kapsamını inceleyebilirsiniz.