MVP, bir ürün fikrini gerçek kullanımla sınamak için seçilmiş ilk kapsamdır. Küçük olması, kullanıcının başladığı işi tamamlayamaması anlamına gelmez. Öncelik, tek bir faydayı baştan sona sunmaktır.
Sınayacağınız soruyu yazın
“İnsanlar uygulamamı sever mi?” yerine daha gözlenebilir bir soru seçin: “Kullanıcılar sesle günlük kaydı oluşturup daha sonra bu kayda dönüyor mu?” Bu soru, kayıt ve yeniden açma akışlarını gerekli kılar; sosyal takip veya rozet sistemi hakkında henüz bir şey söylemez.
Başarıyı hangi davranışla değerlendireceğinizi geliştirmeden önce belirleyin. Sayısal hedefi elde veri yokken sektör standardı gibi sunmayın; ilk kullanımdan sonra yeniden değerlendireceğiniz bir varsayım olarak kaydedin.
Özellikleri üç gruba ayırın
- Temel değer: kullanıcının işini bitiren adımlar.
- Güvenilir kullanım: hata, iptal, boş durum ve yeniden deneme.
- Sonraki genişleme: ana varsayımı sınamak için gerekmeyen işlevler.
Bir günlük örneğinde kayıt oluşturma, kaydetme ve listeleme ilk gruptadır. Mikrofon izni verilmediğinde yazıyla devam etmek ikinci gruptadır. Arkadaşlarla paylaşma üçüncü grupta kalabilir. Bu örnek bir kapsam önerisidir; her ürünün önceliği farklıdır.
Taslak kaybı küçük bir ayrıntı değildir
Nurena’nın yapım hikâyesinde analiz öncesinde metnin yerel taslak olarak saklanmasını anlatıyoruz. Bu davranış yeni bir pazarlama özelliğinden çok, kullanıcının başladığı işi korur. MVP’de hangi durumları kesebileceğinizi tartışırken benzer kayıp risklerini görünür kılın.
Kabul kriterini ekrandan davranışa çevirin
“Günlük ekranı tamamlandı” yerine “kullanıcı kayıt ekler, uygulamayı kapatır ve yeniden açtığında kaydını görür” yazın. Bağlantı yoksa ne gösterileceği ve başarısız işlemden sonra neyin korunacağı da belirtilebilir. Böylece tasarım, geliştirme ve test aynı sonucu değerlendirir.
İkinci sürümü ilk sürümden önce doldurmayın
Ertelenen fikirleri ayrı listede tutun. İlk kullanıcıların nerede durduğuna ve hangi işi yapamadığına bakın. Yeni özellik eklemek yerine mevcut akışın anlaşılmasını iyileştirmek daha uygun olabilir.
Ürün tasarımı yaklaşımımız bu kararları akış ve prototiple görünür kılar. Geliştirme bütçesi için mobil uygulama kapsam rehberini de okuyabilirsiniz.
Seçtiğiniz kapsamı ekibe aktarın
Öncelikler netleştiğinde yazılım projesi brief’i şablonuna aktarın. Şablon; kapsam dışı işleri, açık soruları ve kabul kriterlerini aynı belgede toplar.