Blog
Mobil Uygulama Fikrinizi Koda Para Harcamadan Test Etmenin 7 Adımı
Uygulama fikrinizi geliştirmeye geçmeden önce nasıl sınarsınız? Kullanıcı görüşmesinden prototipe, açılış sayfasından MVP kapsamına yedi pratik adım.
Bize gelen uygulama fikirlerinin çoğu kötü değil. Sorun şu ki bir kısmı, biraz daha sınanması gerekirken doğrudan geliştirme aşamasına geçmiş oluyor. Aylar ve ciddi bir bütçe harcandıktan sonra uygulama mağazaya çıkıyor ve beklenen ilgi gelmiyor.
Kod yazarak para kazanan bir firmanın “biraz bekleyin” demesi garip gelebilir. Ama tutmayan bir uygulama ne size ne bize ikinci bir iş getirir. Kötü bir fikri elemenin en ucuz zamanı, tek satır kod yazılmadan önceki zaman. Bunun için bildiğimiz en pratik yol yedi adımdan oluşuyor.
1. Problemi tek cümleyle yazın
“Şu kişi, şu durumda, şu yüzden zorlanıyor.” Bu cümleyi kuramıyorsanız elinizde henüz bir uygulama fikri yok, bir çözüm hayali var. “Spor okulu velileri, antrenman saati değiştiğinde bunu zamanında öğrenemiyor” iyi bir başlangıç. “Sporla ilgili sosyal bir platform” değil.
2. Problemi gerçekten yaşayanlarla konuşun
En değerli ve en çok atlanan adım bu. Hedeflediğiniz kişilerden sekiz on tanesiyle yüz yüze ya da telefonda konuşun. Arkadaşlarınız ve aileniz sayılmaz; size iyi davranmak için “harika fikir” derler.
Konuşmada kişinin gelecekte ne yapacağını değil, geçmişte ne yaptığını sorun. “Böyle bir uygulama olsa kullanır mısınız?” sorusunun cevabı neredeyse her zaman “evet” ve neredeyse hiçbir şey ifade etmiyor. Şöyle bir konuşma çok daha fazlasını anlatır:
— Antrenman saati değiştiğinde bunu nereden öğreniyorsunuz?
— Velilerin WhatsApp grubundan.
— En son ne zaman sorun oldu?
— Geçen ay. Mesaj diğerlerinin arasında kaybolmuş, çocuğu boş salona götürdük.
— O gün ne yaptınız?
— Antrenörü aradım, sonra gruba sesli mesaj attım. Biraz da söylendim açıkçası.
Bu kısa diyalogdan üç şey çıkıyor. Sorun gerçek ve can sıkıyor. Kullanıcının bugünkü çözümü WhatsApp, yani asıl rakibiniz başka bir uygulama değil, o grup. Üçüncüsü belki en önemlisi: sorunun çözümü koca bir uygulama olmayabilir; sabitlenmiş bir duyuru ya da otomatik bir SMS de işi görebilir. Bunu öğrenmenin maliyeti birkaç çay.
3. Rakip uygulamaların yorumlarını okuyun
App Store ve Google Play'de benzer uygulamalara bir ile üç yıldız arasında verilmiş yorumlar, karşılanmamış ihtiyaçların bedava bir listesi. İnsanlar neye kızıyor, neyi bulamıyor, hangi özellik için para ödemeye razı olduklarını nasıl ima ediyorlar? Beş yıldızlı yorumlar da boşa değil. Önemsiz sandığınız bir ayrıntının kullanıcı için asıl değer olduğunu orada görebilirsiniz.
“Hiç rakibimiz yok” cümlesine şüpheyle yaklaşın. Ya o ihtiyaç için talep yok ya da rakibi yanlış yerde arıyorsunuz. Excel dosyası, kâğıt defter ve WhatsApp grubu da rakiptir.
4. Tıklanabilir bir prototip hazırlayın
Figma gibi bir tasarım aracıyla, gerçek uygulama gibi tıklanabilen ama arkasında hiç kod olmayan bir prototip hazırlamak günler sürer, aylar değil. İkinci adımda konuştuğunuz kişilerden beş altısının bunu kendi telefonlarında denemesini sağlayın. Hiçbir şey açıklamadan “bir randevu almayı dener misiniz?” deyin ve izleyin. Nerede duraksadıklarını, hangi butonu aradıklarını not edin.
Prototipin bir faydası daha var: müşteriyle geliştirici arasındaki yanlış anlaşılmaları erkenden ortaya çıkarıyor. Kelimelerle anlatılan bir özellik herkesin kafasında farklı canlanır, ekranda görülen özellik tartışmayı bitirir. Bu yüzden tasarım ve prototip aşamasını geliştirmeden önce ayrı bir aşama olarak tamamlamayı öneriyoruz.
5. Tek bir sayfayla ilgiyi ölçün
Uygulamanın ne yaptığını üç cümleyle anlatan, prototipten alınmış birkaç ekran görüntüsü ve bir “erken erişim listesine katıl” formu içeren tek bir sayfa hazırlayın. Hedef kitlenize küçük bir reklam bütçesiyle gösterin ya da o kitlenin bulunduğu topluluklarda paylaşın.
Buradaki sinyallerin gücü farklı. Beğeni ve paylaşım neredeyse hiçbir şey söylemez. E-posta ya da telefon numarası bırakmak zayıf ama gerçek bir sinyaldir. Ön ödeme ya da kapora almak en güçlüsü; insanlar ancak gerçekten istedikleri şeye para verir. Formla kişisel veri topladığınız için bir aydınlatma metni gerektiğini de atlamayın.
6. Gelir modelini şimdiden netleştirin
“Önce kullanıcı toplayalım, parayı sonra düşünürüz” yaklaşımı yatırım almış girişimler için bile riskli; uygulamayı kendi bütçesiyle yaptıran bir işletme için bedeli daha da ağır oluyor. Kim, ne için ve nasıl ödeyecek? Bireysel kullanıcı mı, işletme mi, reklamveren mi?
Uygulama kullanıcıya ücretsiz, işletmeye ücretliyse asıl müşteriniz işletmedir ve ikinci adımı onlarla da yapmanız gerekir. Dijital abonelik satacaksanız mağazaların uygulama içi satın alma kurallarını ve komisyonunu hesaba katın. İşe yarayan bir test sorusu var: bu problemi çözmek için bugün birileri para harcıyor mu? Harcıyorsa bir pazar var demektir.
7. MVP kapsamını küçültün, sonra bir kez daha küçültün
İlk sürümde olmasını istediğiniz her özelliği bir listeye yazın. Sonra her birine şu soruyu sorun: bu özellik olmadan birinci adımdaki problem çözülür mü? Çözülüyorsa o özellik ikinci sürüme gider.
Spor okulu örneğine dönersek, ilk sürüm için veliye antrenman programını göstermek, değişiklikte bildirim göndermek ve antrenörün programı güncelleyebileceği sade bir panel yeterli. Aidat ödemesi, gelişim raporları, mesajlaşma, rozetler bekleyebilir. Bazı işleri ilk aylarda perde arkasında elle yapmak da tamamen meşru; her şeyin ilk günden otomatik olması gerekmiyor.
Bazen bu elemenin sonunda ilk sürümün mağaza uygulaması bile olması gerekmediği ortaya çıkıyor ve mobil uyumlu bir web uygulaması fikri sınamaya yetiyor. Mobil uygulama geliştirme sürecinde ilk toplantılarımızın önemli kısmı zaten bu listeyi budamakla geçiyor. Bir mobil yazılım projesinin en verimli saatleri bizce bunlar.
Sık gördüğümüz hatalar
- Fikir çalınır korkusuyla kimseyle konuşmamak. Fikirler nadiren çalınır; çalınsa bile asıl zor olan uygulamaktır.
- Logoya, isme ve sosyal medya hesaplarına problemden önce zaman harcamak.
- “Rakipte var” diye her özelliği ilk sürüme koymak.
- Bütçenin tamamını geliştirmeye ayırıp tanıtıma ve yayın sonrası bakıma pay bırakmamak.
- Görüşme notlarını değil, kendi sezgisini veri saymak.
Girişim projelerinin fırsatlarına ve zorluklarına daha geniş bir çerçeveden bakmak isterseniz startup proje geliştirme üzerine yazdıklarımıza da göz atabilirsiniz.
Bu yedi adımın sonunda elinizde görüşme notları, denenmiş bir prototip ve budanmış bir özellik listesi olur. Geliştirme konuşmasına bunlarla gelin; teklif de takvim de tahmin yerine hesap üzerine kurulsun.
