Kullanıcı neden geri gelecek?
Bir işletmenin telefonda iyi görünmesi gerektiği açıktır; bunun mutlaka ayrı bir mobil uygulama anlamına gelmesi ise başka bir konudur. İlk karar sorusu, müşterinin hangi işi tekrar tekrar yapacağıdır. Tek seferlik bir hizmet teklifi istemekle her hafta sipariş oluşturmak aynı kullanım alışkanlığını gerektirmez. Ürüne başlamadan önce bu görevi tek cümleyle yazın.
Örneğin “Müşteri önceki siparişini bulup miktarını değiştirerek yeniden verecek” somut bir ihtiyaçtır. “Markamızın uygulaması olsun” ise hangi ekranın gerekli olduğunu söylemez. Tekrar kullanım nedeni açıklanamıyorsa önce mobil web deneyimini iyileştirip davranışı gözlemlemek daha anlaşılır bir başlangıç sağlayabilir.
İlk iki soru: erişim ve cihaz ihtiyacı
İnsanlar hizmete çoğunlukla arama, sosyal medya bağlantısı veya doğrudan paylaşılan adres üzerinden mi ulaşıyor? Kurulum gerektirmeyen bir web sayfası bu ilk temasta pratik olabilir. Mevcut kullanıcıların tekrar giriş yapması ve kişisel işlerini sürdürmesi gerekiyorsa bunun hangi adımda sorun yarattığını ayrıca ölçün.
İkinci soru cihazla ilgili: Kamera, konum, çevrimdışı çalışma veya bildirim gibi gereksinimleriniz var mı? Bir özellik adını listelemek yerine kullanım senaryosunu anlatın. “Depoda bağlantı kesilse de sayım kaydı tutulacak” gibi bir tarif, geliştirme seçeneklerini değerlendirmeyi kolaylaştırır. Her özelliğin web ve uygulama tarafındaki desteği aynı değildir; hedef cihazlarda küçük bir denemeyle doğrulayın.
Üçüncü soru: ilk sürümde hangi işi tamamlayacaksınız?
İlk sürümün kapsamını ekran sayısıyla değil, tamamlanan görevle tanımlayın. Müşteri sipariş verecekse ürün seçimi, miktar, teslim bilgisi ve sonucu görme akışı bir bütündür. Gösterişli bir açılış ekranı bu akışın çalıştığını kanıtlamaz. Yönetim tarafında siparişin kimin önüne düşeceğini de aynı kapsamda düşünün.
Bir geliştirme görüşmesine giderken örnek kullanıcı, başlangıç koşulu ve beklenen sonucu içeren kısa bir senaryo hazırlayın. Bize ait Mobiluygulama.app üzerinden işletmeye özel mobil uygulama geliştirme kapsamını değerlendirirken bu senaryoyu kullanabilirsiniz. Teklifleri yalnızca süre veya ekran adedi üzerinden karşılaştırmak, teslimin önemli farklarını saklayabilir.
Dördüncü ve beşinci soru: bakım ve sahiplik
Ürün yayımlandıktan sonra içerik değişikliğini, hata bildirimini ve yeni sürüm ihtiyacını kimin yöneteceğini belirleyin. Bakım bedelinin hangi işleri kapsadığı açık olsun. Yeni bir özellik talebiyle mevcut işlevin hatasını düzeltmek aynı iş kalemi değildir. Teslimden sonraki iletişim kanalı ve önceliklendirme yöntemi de konuşulmalıdır.
Alan adı, mağaza hesapları, kaynak kod ve hizmet hesaplarının sahipliğini başlangıçta netleştirin. Ürünü başka ekibe devretmeniz gerekirse hangi dosyaları ve bilgileri alabileceğinizi sorun. Bir uygulamayı kullanabilmekle onu sürdürebilecek erişimlere sahip olmak aynı şey değildir. İşletmeden bir kişinin temel yönetim görevlerini uygulamalı olarak yapması teslimin parçası olabilir.
Kararı küçük bir pilotla sınayın
İlk denemeyi en çok tekrarlanan tek görevle yapın. Kullanıcı görevi yardım almadan bitirebiliyor mu, hangi adımda geri dönüyor, ekip tarafında sonuç doğru kayda ulaşıyor mu? Bunları gözlemleyin. Beğenilen bir tasarımı kullanılabilirliğin tek kanıtı saymayın.
Pilot sonunda kapsamı büyütmek kadar sadeleştirmek de geçerli bir karardır. İlk temasınız sosyal medyadan geliyorsa bağlantıdan talebe giden yolu uygulama kararından ayrı değerlendirin. İyi çalışan ilk temas ile tekrar kullanılan ürün birbirini tamamlar; ikisinin de kendi amacı net olmalıdır.