7 Adımda Başarılı Bir Mobil Uygulama Geliştirme Süreci

Süreç yaygın olarak yedi adımda ele alınır: hedefin netleştirilmesi, pazar ve rakip araştırması, akış ve deneyim tasarımı, teknoloji kararı, prototip, geliştirme, test ve mağazaya gönderim.

Adımların sırası önemlidir çünkü her adım bir öncekinin kararlarını miras alır. En pahalı hatalar kod yazılırken değil, hedef ve teknoloji kararı verilirken yapılır — ve genellikle yayından sonra fark edilir. Bu süreci uyguladığımız işlere projeler sayfamızdan bakabilirsiniz.

Uygulamanın hangi sorunu, kimin için çözdüğü tek bir cümleyle yazılamıyorsa geliştirmeye başlamak erkendir. Bu cümle bir slogan değil, bir kısıt: sonraki her özellik talebini bu cümleye karşı sınayacaksınız.

Pratik bir test var. Ekibe "bu uygulama olmasa kullanıcı bu işi nasıl yapardı?" diye sorun. Cevap yoksa, çözülen bir sorun da olmayabilir.

Buradaki amaç rakip listesi çıkarmak değil, mevcut çözümlerin nerede yetersiz kaldığını görmek. En işe yarar kaynak çoğu zaman mağaza yorumlarıdır: insanlar rakip uygulamalarda neye kızıyor, hangi özelliği istiyor, neyi anlamıyor?

Bu aşama aynı zamanda bir "yapmama" kararı üretebilir. Var olan bir uygulamanın yeterince iyi çözdüğü bir sorunu yeniden çözmek, çoğu zaman en pahalı seçenektir.

Kullanıcının bir işi bitirmek için kaç adım attığı, uygulamanın kaderini görsel tasarımdan daha çok belirler. Bu aşamada ekranların nasıl göründüğü değil, birbirine nasıl bağlandığı çalışılır.

Sorulacak sorular somut: Kayıt olmadan ne yapılabiliyor? Kullanıcı bağlantısı koptuğunda ne oluyor? Bir işlem yarıda kalırsa nerede devam ediyor?

Bu karar teknolojiyle değil, uygulamanın ne yaptığıyla başlar.

Native tarafın avantajlı olduğu durum: uygulama cihaz donanımına yakın çalışıyorsa. Kamera, sensörler, arka planda sürekli çalışan işlemler, yoğun animasyon ya da platforma özgü arayüz davranışları gerekiyorsa native geliştirme daha az sürtünme üretir.

Çapraz platformun avantajlı olduğu durum: uygulama ağırlıklı olarak içerik gösteriyor, form dolduruyor, listeliyor ve iki mağazada da aynı deneyimi sunması yeterliyse. Tek kod tabanıyla iki platforma çıkmak, ekip küçükken belirgin bir avantajdır.

Karar verirken bakılacak asıl soru şudur: iki platform arasında farklılaşan bir davranışa ihtiyacınız var mı, yoksa aynı şeyin iki yerde çalışması mı yeterli?

Prototip, bir fikri kod yazmadan test etmenin en ucuz yoludur. Paydaşlara statik ekran göstermek yerine tıklanabilir bir akış göstermek, geri bildirimin niteliğini değiştirir — insanlar ancak deneyimlediklerinde eksik olanı fark eder.

Bu adım atlanabilir. Atlandığında aynı geri bildirim gelir, ama geliştirme aşamasında ve çok daha pahalı biçimde.

Geliştirme aşamasında iki şey belirleyicidir: parçalar ne sıklıkla birleştiriliyor ve test edilebilir bir sürüm ne zaman ortaya çıkıyor.

Uzun süre kimsenin çalışan bir sürüm görmediği projeler, sonunda beklenenden farklı bir ürün teslim etme eğilimindedir. Bu yüzden çalışan bir sürümün erken ve düzenli olarak ortaya çıkması, ilerlemeyi ölçmenin en dürüst yoludur.

Arka uç tarafı da bu aşamada ihmal edilmemeli. Uygulamanın kendisi hafif görünse bile, verinin nerede durduğu ve hangi sistemlerle konuştuğu ölçeklenme sorununu belirler. İhtiyaç gerçekten kuruma özgüyse özel yazılım geliştirme tarafını ayrıca değerlendirmek gerekir.

Test yalnız hata aramak değildir. Üç ayrı soruyu ayrı ayrı sorar:

• İşlev doğru çalışıyor mu?
• Gerçek kullanıcı, yardım almadan hedefe ulaşabiliyor mu?
• Zayıf bağlantıda ve eski cihazda ne oluyor?

Üçüncüsü en sık atlanandır. Geliştirme ekibi genellikle yeni cihazlarda ve hızlı bağlantıda çalışır; kullanıcı kitlesinin önemli bölümü ise ikisine de sahip değildir.

Mağazaya gönderimde her iki platformun kendi inceleme süreci ve içerik kuralları vardır. Bu kurallar zaman zaman güncellenir, bu yüzden gönderim öncesi güncel gereklilikleri kontrol etmek gerekir.

İlk gerçek kullanıcılar test ortamında görülmeyen sorunları ortaya çıkarır: beklenmedik kullanım biçimleri, farklı cihazlar, öngörülmeyen veri durumları.

Bu yüzden ilk sürüm sonrası için düzeltme ve iyileştirme payı baştan ayrılmalıdır. Ayrılmadığında olan şey tanıdıktır: ekip bir sonraki projeye geçer, uygulama olduğu yerde kalır ve altı ay sonra "kimse kullanmıyor" denir.

Dürüst olmak gerekirse her ihtiyaç mobil uygulama gerektirmez.

Kullanıcı sizinle yılda birkaç kez etkileşime giriyorsa, uygulama indirtmek yüksek bir bariyerdir; iyi çalışan bir mobil web deneyimi çoğu zaman daha doğru karardır. Aynı şekilde, uygulamanın tek işlevi mevcut bir web sayfasını göstermekse, mağaza inceleme süreçleri bu çabayı karşılamayabilir.

Uygulama kararı, kullanıcının ürününüzü ne sıklıkla açacağıyla başlar. Sık açılmayan bir uygulama, ne kadar iyi yapılırsa yapılsın telefonda kalmaz.