Uygulama isteyen işletmelerin çoğu, aslında daha iyi bir mobil sitenin karşılayacağı nedenlerle ister. Birkaçının gerçek bir gerekçesi vardır ve bu fark, hâlihazırda kayıtlı olan davranışta görünür.
Bu rehber bir uygulamayı maliyetine değer kılan dört koşulu, her birinin kendi trafiğinizde nasıl kontrol edileceğini ve yanıt hayır çıkarsa önce ne yapılacağını anlatıyor.
Kısa cevap
- Kararı sıklık verir: Haftalık kullanım uygulamaya tutunacak bir dal verir; yılda bir ise doğru yanıt tarayıcıydı demektir.
- Önce kendi trafiğinizi okuyun: Telefon oturumları, başlattıkları iş ve bıraktıkları adım zaten analitiğinizde duruyor.
- Önce mobil sayfayı iyileştirin: Maliyeti düşüktür, herkese anında ulaşır ve uygulamanın aşması gereken çıtayı belirler.
- Çevrimdışı tarayıcının yapamadığıdır: Bu ihtiyaç gerçekse uygulamayı haklı çıkarır; kuramsalsa çıkarmaz.
Önce iş sonucunu ve kullanıcıyı belirleyin
Uygulama kararının hedefi, telefonun tarayıcının veremediği bir şeyi verip vermediğidir. Hangi müşteri grubunun hangi işi ne sıklıkla yaptığını yazın; bu üç bilgi kararı çoğu zaman tek başına verir. Bu üç bilgi yoksa karar tartışması fikir alışverişine dönüşür ve genellikle en yüksek sesli görüş kazanır.
Kendi trafiğinizi okuyun. Telefon oturumlarının hangi işi başlattığı ve nerede bırakıldığı, insanların hayalindeki uygulamayı anlattığı bir anketten daha güvenilir bir gerekçedir. Verinin son üç ayını alın; kampanya dönemleri tek başına yanıltıcı bir tablo çizer.
Müşterinin o işi yaparken nerede olduğunu da yazın. Masa başında yapılan bir işlem için kurulum zorunluluğu bir engeldir; ayaküstü, tek elle ya da şebekesiz yapılan bir işlem ise uygulamanın asıl gerekçesidir. Bağlamı gözlemleyin, sormayın; insanlar telefonu nerede kullandıklarını anlatırken genellikle masa başını atlar.
Mobil uygulama ihtiyacı için dört karar alanı
Tekrar kullanım
Aynı müşterinin ne sıklıkla geri döndüğünü sayın. Haftalık bir alışkanlıktır ve uygulamanın tutunacağı bir dal vardır; aylık sınırdadır; yılda bir ise yapmayı düşündüğünüz şeyin yerinin tarayıcı olduğu anlamına gelir.
Zaman duyarlılığı
Müşterinin dakikalar içinde bilmesi gereken şeyi ve bugün ona saatler sonra ulaşan bilgiyi belirleyin. Birini telefon açmaktan kurtaran bir bildirim, bir uygulamanın en net gerekçesidir; ama alttaki bilginin kendisi gecikiyorsa neredeyse hiçbir değeri yoktur.
Cihaz bağlamı
İşin masa başından uzakta, tek elle ya da başka bir işle aynı anda yapılan kısmını tarif edin. Etkileşimin tamamı ofiste bir dizüstünde geçiyorsa kurulması gereken bir web sitesi yapıyorsunuz demektir.
Çevrimdışı ihtiyaç
Müşterinin, işin önemli olduğu ama şebekenin bulunmadığı bir yerde bulunup bulunmadığını kontrol edin. Gerçek çevrimdışı ihtiyaç, tarayıcının karşılayamadığı tek gereksinimdir ve bu listede düzgün yapılması en pahalı olan şeydir.
İlk sürümü bir özellik listesinden farklı planlayın
Uygulama kararını anketle değil kendi verinizle açın. Telefondan gelen oturumların hangi işi başlattığına, nerede bırakıldığına ve müşterinin o sırada nerede olduğuna bakın; gerekçe de kısıt da burada görünür.
Riskleri geliştirmeye başlamadan görünür kılın
- İndirme sayısı başarı sayılır: Lansmandan önce hangi tekrar kullanım rakamının devam kararını vereceğini yazın ve indirmeyi gerekçe olarak kullanmayın. Rakamı lansmandan önce yazın, sonrasında seçilen ölçü savunma olur.
- Aciliyet varsayılır: Bilginin müşteriye bugün kaç saat gecikmeyle ulaştığını ölçün; gecikme yoksa bildirim gerekçesi de yoktur. Gecikme varsa önce o gecikmeyi giderin, bildirim sonradan gelir.
- Uygulama siteyi tekrarlar: Uygulamanın mobil sitenin yapamadığı neyi yaptığını listeleyin ve listede olmayan her şeyi ilk sürümden çıkarın. Listede olmayan her özellik ikinci sürüme kalsın.
- Çevrimdışı ihtiyaç kanıtsızdır: Sahadaki kişilerden bağlantı yüzünden duran her işi bir hafta boyunca kaydetmelerini isteyin. Kayıt tutmak bir hafta sürer ve tahminle yapılan tartışmayı tamamen bitirir.
Uygulanabilir bir yol haritası kurun
- Kendi trafiğinizi okuyun. Son üç ayda telefon oturumlarını ayırın ve hangi işin nerede bırakıldığını bulun.
- Mobil sayfayı düzeltin. O tek işi küçük ekranda düzgün çalışır hale getirin ve tamamlamayı öncesiyle karşılaştırın.
- Yalnızca cihazın çözdüğü durumu sınayın. Şebekesiz çalışma ya da dakikalar içinde haber verme gibi tek bir durumu prototipleyin.
- On müşteriye gösterin. Kararı o tek yeteneğe verdikleri tepkiye dayandırın, genel hevese değil.
Güven, izin ve sorumlu veri kullanımı
Mobil uygulama ihtiyacı için güvenlik gereksinimini yalnızca son teknik teste bırakmayın. Kimlerin hangi kaydı görebildiği, oluşturabildiği, değiştirebildiği, onaylayabildiği ve dışa aktarabildiği rol ve sorumluluk üzerinden tanımlanmalıdır. Hassas kararlar için ek onay, gerekçe veya denetim izi gerekip gerekmediğini iş etkisine göre belirleyin.
Toplanan her veri için amaç, erişim, saklama süresi, düzeltme ve silme yolu yazın. Mobil uygulama ihtiyacı için kullanıcı değeri gerektirmeyen bilgiyi toplamak, ürünü daha akıllı yapmaz; güven ve işletim yükü oluşturur. Ülke, sektör ve veri türüne göre hukuki veya düzenleyici yükümlülükler değişebileceği için uygun uzman değerlendirmesini planlayın.
Tehdit ve hata senaryosunu bir kullanıcı yolculuğuyla birleştirin: hesap ele geçirilmesi, yanlış kişiye görünürlük, kayıp cihaz, yetki değişikliği veya kötüye kullanım bildirimi olduğunda ne olur? Mobil uygulama ihtiyacı ekibi olayın etkisini anlayabilmeli, erişimi sınırlayabilmeli ve gerekli inceleme kanıtını koruyabilmelidir.
Sonraki adım
Mobil uygulama ihtiyacını bir fikir tartışması olmaktan çıkarın. Önce mobil web deneyimini iyileştirip tamamlama oranını ölçün; uygulama gerekçesi, o yeni rakamın üzerine ne kattığıyla sınanmalıdır.
Konuyu genişleten yazı: Üyelik Uygulaması: Erişim, Fayda ve Tutundurma.
30 günlük doğrulama planı: Mobil uygulama ihtiyacı
1-5. günler: mobil ziyaretçinin bugün ne yaptığını okuyun. Son üç ayın trafiğini çekin ve telefon oturumlarını masaüstünden ayırın. Telefon kullanıcılarının en sık başladığı işi ve vazgeçtikleri noktayı bulun. Tekrar kullanımı ve zaman duyarlılığını, insanların hayalindeki uygulamayı anlattığı bir ankette değil, elinizde zaten olan davranışta arayın. Yeni ziyaretçileri geri dönenlerden ayırın; bir uygulamanın kitlesi, zaten hatırlatılmadan geri gelen kişiler arasındadır.
6-15. günler: önce mobil web sayfasını iyileştirin. O tek işi alın ve uygulama olmadan küçük ekranda düzgün çalışır hale getirin. Formu, yüklenme süresini ve iki el gerektiren adımı düzeltin. Tamamlanma oranını öncesi ve sonrasıyla ölçün. Buradaki iyileşme ucuzdur, herkese anında ulaşır ve bir uygulamanın aşması gereken çıtayı belirler. Tamamlanma rakamlarını aynı cihazlarda karşılaştırın; ofisteki yeni bir telefonda ölçülen kazanç, sahip olduğunuz müşteriler hakkında hiçbir şey söylemez.
16-30. günler: yalnızca uygulamanın çözebileceği durumu sınayın. İş gerçekten cihazı gerektiriyorsa (şebekesiz çalışmak veya dakikalar içinde haber vermek gibi) o tek durum için küçük bir prototip yapın ve on gerçek müşterinin önüne koyun. Kararı veren şey, o tek yeteneğe verdikleri tepkidir. Uygulama sahibi olmaya duyulan genel heves değildir. O on müşteriye uygulamayı hangi durumda kaldıracaklarını sorun; bu yanıt, fikre duyulan hevesten çok daha iyi bir tutundurma göstergesidir.
Pratik çalışma sayfası: Mobil uygulama ihtiyacı
Mobil uygulama için dürüst sınav, telefonun tarayıcının veremediği bir şey katıp katmadığıdır. Kendi müşteri etkileşiminizi bu satırlara göre puanlayın ve düşük puanı hayal kırıklığı değil, bilgi olarak değerlendirin.
| Karar alanı | Kaydedilecek bilgi |
|---|---|
| Tekrar kullanım | Aynı müşterinin ne sıklıkla geri döndüğü; bunun haftalık mı, aylık mı, yılda bir mi olduğu |
| Zaman duyarlılığı | Müşterinin dakikalar içinde bilmesi gereken şey ve bugün ona saatler sonra ulaşan bilgi |
| Cihaz bağlamı | İşin masa başından uzakta, tek elle veya başka bir işle aynı anda yapılan kısmı |
| Çevrimdışı ihtiyaç | Müşterinin, işin önemli olduğu ama şebekenin bulunmadığı bir yerde olup olmadığı |
| Ölçüm | Trafiğinizin hâlihazırda telefondan gelen oranı ve bu ziyaretçilerin tamamlayamadığı adımlar |
Dört satırda da düşük puan almak mobilden vazgeçmek için gerekçe değildir. Mobil web deneyimini iyileştirmek için gerekçedir; maliyeti uygulamanın küçük bir bölümüdür ve kimsenin önce bir şey kurmasını gerektirmez.
İlgili rehberler
- Buradan sonrası şu yazıda ele alınıyor: Mobil Uygulama Yönetim Paneli: Özellikler, Roller ve Akışlar.
- Yap ya da satın al seçimini tartıyorsanız şunu okuyun: Uygulama Lansman Kontrol Listesi: Yayın Öncesi ve Sonrası.
Müşteri Yolculuğunuzun Mobil Uygulamaya İhtiyaç Duyduğunu Gösteren 6 İşaret yazısındaki mobil çalışmanın arkasına bütçe konduğunda Mobil Ürününüzü Konuşalım.
Ali Boran Gazel