Kısa yanıt
Web sitesi veya mobil uygulama kararı, kullanıcının tamamlayacağı göreve dayanmalıdır. İlk temas, tekrar kullanım, cihaz özellikleri, çevrimdışı ihtiyaç ve bakım sorumluluğunu birlikte değerlendirin. Önce tek bir görevle pilot yapın. Ekran sayısı veya kurumsal görünüm, ürün ihtiyacını ve günlük kullanılabilirliği tek başına kanıtlamaz.
Dört adımda uygulama rotası
BAŞLANGIÇ → SONUÇ- 01Görevi yaz
Kullanıcının neyi tamamlayacağını tarif et.
- 02Koşulu belirle
Cihaz, bağlantı ve tekrar kullanımını incele.
- 03Prototipi dene
Tek görevi gerçek kullanıcıyla sına.
- 04Bakımı planla
Yayın sonrası sorumlulukları belirle.
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.
Örnek: servis talebi ile saha iş emri farklı ürünlerdir
Bir müşterinin yılda bir kez servis talebi göndermesiyle teknisyenin her gün iş emri tamamlaması aynı akış değildir. Müşteri için bağlantıyla açılan anlaşılır bir sayfa yeterli olabilir. Teknisyen için gün boyunca kayıt görüntüleme, fotoğraf ekleme ve zayıf bağlantıda çalışma gibi gereksinimler ortaya çıkabilir. Kararı tek bir işletmenin iki farklı kullanıcı rolü için ayrı düşünmek gerekir.
Pilotta teknisyenin bir işi açıp gerekli bilgiyi bulmasını, sonucu kaydetmesini ve bağlantı kesintisinden sonra ne olduğunu inceleyin. “Çevrimdışı destek var” ifadesi bütün veri türlerinin sorunsuz eşitlendiğini anlatmaz. Aynı kaydı iki kişi değiştirirse hangi bilginin korunacağı da tasarımın parçasıdır.
Müşteri tarafında ise kurulum veya üyelik beklentisinin ilk başvuruyu gereksiz uzatıp uzatmadığını değerlendirin. Birinci rol için uygulama düşünülmesi, diğer rolün de aynı ürünü kullanmak zorunda olduğu anlamına gelmez. Ortak veriyle farklı arayüzler mümkün olabilir; seçimi bakım ve geliştirme kapasitesiyle birlikte tartışın.
Bu senaryo açıklama amacıyla hazırlanmıştır; gerçek müşteri sonucu veya ürün testi değildir.
Üçü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.
İlk karar görüşmesinde kullanılacak karşılaştırma
| Gereksinim | Doğrulanacak soru | Pilot kanıtı |
|---|---|---|
| Bağlantıyla ilk erişim | Kullanıcı hizmete hangi kanaldan gelecek? | Görevin ilk açılıştan tamamlanması |
| Tekrarlayan kullanım | Kişi neden ve ne sıklıkla geri dönecek? | Aynı görevin birkaç tekrarında akış |
| Cihazla çalışma | Hangi özellik hangi cihazda gerekli? | Hedef cihazda özelliğin gerçek denemesi |
| Zayıf bağlantı | Veri ne zaman yerel, ne zaman sunucuda? | Kesinti ve tekrar bağlantı senaryosu |
Web teknolojileri de bazı uygulama benzeri özellikler sunabilir; her gereksinimi otomatik olarak yerel uygulama gerekçesi saymayın. Ancak desteğin tarayıcı ve cihaza göre değişebildiğini doğrulayın. Karşılaştırmayı özellik adıyla değil, tamamlanan kullanıcı göreviyle yapın.
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.
Teklifte görünmeyen işleri konuşun
Ürün teklifine yalnızca ekran tasarımı ve geliştirmeyi değil, veri aktarımı, yönetim ekranı, test, yayın hesabı ve bakım kapsamını da ekleyin. Bildirim gönderiliyorsa kimin hangi veriye göre bildirim alacağı; kullanıcı hesabı varsa yetki ve kurtarma akışı açıklansın. Bu ayrıntılar sona bırakıldığında ilk kapsam değişebilir.
Pilot sonunda kullanıcı yardımsız ilerleyemiyorsa daha fazla ekran eklemeden önce temel akışı düzeltin. Öğrenilenleri kısa bir karar notuna dönüştürün; neden belirli yaklaşımın seçildiği gelecekteki ekip tarafından da anlaşılabilsin.
0 / 4 adım kontrol edildi · Bu seçimler yalnızca açık sayfada tutulur.
Sık sorulan sorular
Her işletmenin mobil uygulaması olmalı mı?
Hayır; tekrar kullanım nedeni ve somut görev tanımlanmalıdır. İlk ihtiyacın mobil web ile karşılanması mümkünse önce bunu sınamak anlamlı olabilir. Uygulama kararı marka büyüklüğünden tek başına çıkarılmaz.
PWA bütün mobil uygulamaların yerini alır mı?
Genel bir eşdeğerlik yoktur. Gerekli cihaz özellikleri, tarayıcı desteği, dağıtım ve kullanım koşulları karşılaştırılmalıdır. Hedef cihazda küçük bir teknik pilotla doğrulayın.
Prototipin beğenilmesi yeterli mi?
Görsel beğeni yararlı geri bildirimdir; görevin tamamlanabildiğini kanıtlamaz. Kullanıcının gerekli bilgiyi bulup sonucu kaydedebildiğini ve ekip tarafının da kayda erişebildiğini gözlemleyin.
Yöntem ve kaynak notu
Örnek senaryolar ve karar tabloları, konuyu açıklamak için hazırlanmış çalışma önerileridir. Ölçülmüş müşteri sonucu veya bağımsız ürün testi olarak sunulmaz. Platform ve ürün koşulları değişebileceğinden uygulama öncesinde ilgili resmi belgeyi ve kendi hizmet kapsamınızı kontrol edin.