Kalıcı olan uygulama tek seferde tek görevi düşünerek tasarlanır

Kısa cevap: kullanıcıyı elde tutan uygulama en fazla özelliğe sahip olan değil, yeni bir kullanıcıyı en kısa sürede faydalı bir noktaya ulaştırandır. Çoğu uygulamada sorun eksik özellik değildir. Kullanıcı daha uygulamanın değerini görmeden önce çok fazla bilgi, izin ve tercih istenmesidir.

Özellik eşitliği bir uygulamayı kurtarmaz

İki uygulama özellik açısından birbirine çok yakın olabilir ve yine de tamamen farklı sonuçlar alabilir.

Çünkü yeni bir kullanıcının ilk deneyimlediği şey özellik listesi değildir.

İlk deneyim onboarding ekranıdır. Kayıt akışıdır. İzin istekleridir. Uygulamanın nasıl çalıştığını anlamaya çalışırken karşısına çıkan ilk birkaç adımdır.

Eğer bu akış kullanıcıdan daha uygulamanın asıl değerini görmeden birçok şey istiyorsa, kullanıcı uygulamanın gerçekten iyi olduğu noktaya hiç ulaşamayabilir.

Bu yüzden bir uygulamayı tasarlarken ilk soru, “Hangi özellikleri eklemeliyiz?” olmamalı.

Daha önemli soru şudur:

Kullanıcıyı uygulamanın asıl değerine mümkün olan en kısa yoldan nasıl ulaştırırız?

Daha az iste, daha sonra iste

Uygulama geliştirirken sık yapılan hatalardan biri, kullanıcıdan ihtiyaç duyulabilecek her şeyi daha ilk anda toplamaya çalışmaktır.

İsim, e-posta, profil bilgileri, bildirim izni, konum izni, tercihler ve diğer hesap detayları tek bir onboarding akışına doldurulabilir.

Teknik açıdan bunların birçoğu gerçekten gerekli olabilir.

Fakat önemli olan hepsinin gerekli olup olmadığı değil, hepsinin ilk anda gerekli olup olmadığıdır.

Kullanıcı daha uygulamanın ne işe yaradığını görmeden neden konum paylaşması gerektiğini anlamayabilir. Bildirim almak için neden izin vermesi gerektiğini de henüz bilmeyebilir.

Bu yüzden bilgiyi ve izinleri ihtiyaç duyulan ana taşımak daha doğru bir yaklaşım olabilir.

• Konum, kullanıcı ilk kez harita veya konum tabanlı bir özellik kullandığında istenebilir.
• Bildirimler, kullanıcı bildirim almanın gerçekten faydalı olacağı bir noktaya geldikten sonra istenebilir.
• Ek hesap bilgileri, kullanıcı yaptığı işlemleri kaydetmek veya hesabını kişiselleştirmek istediğinde istenebilir.
• Tercihler, mümkün olduğunda kullanıcının davranışlarından çıkarılabilir.

Buradaki amaç kullanıcıdan daha az bilgi almak değildir.

Amaç doğru bilgiyi, doğru zamanda istemektir.

Onboarding’in amacı form doldurtmak değil, değeri göstermek

Bir uygulamanın onboarding süreci, kullanıcıya mümkün olduğunca fazla şey anlatmak zorunda değildir.

Asıl amacı kullanıcıyı ürünün değerine ulaştırmaktır.

Bir kullanıcı uygulamayı açtığında arka arkaya beş ekran görüyorsa ve her ekranda yeni bir bilgi vermesi veya yeni bir izin vermesi gerekiyorsa, uygulama daha faydasını göstermeden kullanıcıdan sabır istemeye başlamış olur.

Bunun yerine kullanıcı mümkün olduğunca erken gerçek ürünü görmelidir.

Bir alışveriş uygulamasında ürünleri görebilmelidir.

Bir not alma uygulamasında ilk notunu oluşturabilmelidir.

Bir harita uygulamasında haritayı açıp kullanabilmelidir.

Bir SaaS ürününde ürünün gerçekten ne yaptığını deneyebilmelidir.

Kullanıcı uygulamanın neden faydalı olduğunu gördükten sonra karşısına çıkan sonraki adımlar çok daha anlamlı hale gelir.

Tek ekran, tek görev

İyi bir onboarding akışında her ekranın belirgin bir amacı vardır.

Bir ekranda aynı anda hesap oluşturmak, izin istemek, tercih toplamak ve uzun bir açıklama yapmak kullanıcı açısından gereksiz bir yük oluşturabilir.

Bunun yerine ekranın tek bir soruya cevap vermesi daha etkilidir:

Burada benden ne isteniyor ve bunu neden yapıyorum?

Kullanıcı bunu birkaç saniye içinde anlayabiliyorsa, o adımı tamamlama ihtimali de artar.

Bu küçük bir UX detayı gibi görünebilir. Fakat kullanıcı uygulamanın asıl özelliğine ulaşmadan önce nerede kaybolduğunu çoğu zaman bu küçük kararlar belirler.

Kullanıcıyı önce değerle tanıştırın

Kullanıcı henüz uygulamaya güvenmiyorken ondan çok fazla şey istemek, doğal olarak direnci artırır.

Buna karşılık kullanıcı uygulamanın kendisine gerçekten fayda sağladığını gördüğünde daha sonraki adımları kabul etmek kolaylaşır.

Örneğin bir fitness uygulaması daha ilk kullanımda kullanıcıya bir egzersiz planı gösterebiliyorsa, daha sonra kişiselleştirme için yaş veya hedef gibi bilgileri istemek çok daha anlamlı hale gelir.

Aynı mantık bildirimler için de geçerlidir.

Kullanıcı henüz uygulamada hiçbir şey yapmamışken “Bildirim göndermemize izin verir misiniz?” demek ile kullanıcı bir işlemi tamamladıktan sonra “Bu işle ilgili güncellemeleri almak ister misiniz?” demek aynı deneyim değildir.

İkinci durumda kullanıcının isteğin nedenini anladığı bir bağlam vardır.

Bu nedenle iyi onboarding, sadece daha kısa onboarding değildir.

Doğru sıraya sahip onboarding’dir.

Uygulama bir kez yapılmak için değil, güncellenmek için tasarlanır

Bir uygulamanın maliyeti yalnızca ilk geliştirme sürecinden oluşmaz.

Asıl maliyet çoğu zaman uygulama yayınlandıktan sonra birikmeye başlar.

Yeni bir iOS veya Android sürümü çıkar.

Yeni bir cihaz veya ekran boyutu ortaya çıkar.

Kullanıcıların gerçek kullanım sırasında fark ettiği problemler ortaya çıkar.

Yeni bir business ihtiyacı oluşur.

Rakipler yeni bir özellik yayınlar.

Bunların hiçbiri olağan dışı değildir.

Bunlar bir uygulamanın yaşam döngüsünün normal parçalarıdır.

Bu yüzden uygulamanın codebase’i yalnızca bugünkü ihtiyaca göre değil, yarın değişecek ihtiyaçlara göre de düşünülmelidir.

Bir özelliği değiştirmek için sistemin büyük bölümüne dokunmanız gerekiyorsa geliştirme maliyeti zaman içinde hızla artar.

Buna karşılık iyi organize edilmiş bir codebase, yeni özelliklerin eklenmesini ve mevcut özelliklerin değiştirilmesini daha kontrollü hale getirir.

Buradaki amaç gelecekte çıkabilecek her problemi bugünden çözmek değildir.

Amaç değişimin geleceğini kabul ederek geliştirmektir.

Native uygulama her zaman doğru seçim mi?

Her zaman değil.

Native geliştirme, cihaz özelliklerine yoğun erişim gerektiğinde güçlü bir tercih olabilir.

Kamera, Bluetooth, GPS, background processing, yüksek performans veya gelişmiş offline kullanım gibi ihtiyaçlar native bir uygulamayı daha mantıklı hale getirebilir.

Ancak her ürünün bu ihtiyaçlara sahip olması gerekmez.

Bir kullanıcı sisteme giriş yapıyor, verilerini görüntülüyor, form dolduruyor ve temel işlemlerini gerçekleştiriyorsa, bunun için her zaman ayrı bir iOS ve Android uygulaması geliştirmek gerekmeyebilir.

İyi hazırlanmış bir web uygulaması veya PWA birçok kullanım senaryosunu yeterince iyi karşılayabilir.

Bu yüzden teknoloji seçimine “Native mi yapalım, web mi?” sorusuyla başlamak yerine şu soruyla başlamak daha sağlıklıdır:

Kullanıcının gerçekten hangi teknik yeteneklere ihtiyacı var?

Cevap buna göre verildiğinde hem geliştirme maliyeti hem de uzun vadeli bakım yükü daha doğru yönetilebilir.

İyi bir uygulama kullanıcı yolculuğunu düşünür

Bir uygulamayı yalnızca özellik listesi üzerinden tasarlamak kolaydır.

Login, profil, bildirimler, arama, favoriler, ödeme: hepsi var.

Ancak bu özelliklerin hepsinin bulunması, kullanıcı deneyiminin iyi olduğu anlamına gelmez. Daha önemli olan bu özelliklerin kullanıcı karşısına ne zaman ve hangi sırayla çıktığıdır.

Kullanıcı uygulamayı açar, ne yapabileceğini anlar, asıl özelliğe ulaşır ve ilk değerli deneyimini yaşar. Sonra gerektiği kadar bilgi verir, kullanmaya devam ettikçe yeni özelliklerle tanışır.

Böyle bir yapı kullanıcıya aynı anda her şeyi göstermek yerine, ihtiyaç duyduğu anda ihtiyaç duyduğu şeyi gösterir.

Uygulama kullanıcı açısından daha basit hale gelirken, arka plandaki sistem oldukça güçlü olabilir.

Sonuç

Kalıcı bir uygulama en fazla özelliğe sahip olan uygulama değildir.

Kullanıcıyı en kısa sürede doğru yere ulaştıran uygulamadır.

İlk kullanımda gereksiz bilgi istemez.

İzinleri doğru zamanda ister.

Her ekranın ne amaçla var olduğunu açıkça gösterir.

Kullanıcıya uygulamanın değerini mümkün olduğunca erken yaşatır.

Ve yayınlandıktan sonra değişeceğini kabul ederek geliştirilir.

Sonuçta iyi bir uygulamanın amacı kullanıcıya daha fazla şey yaptırmak değildir.

Kullanıcının yapmak istediği şeyi daha az sürtünmeyle yapmasını sağlamaktır.

Bu yüzden:

Daha fazla ekran yerine daha az friction.

Daha fazla soru yerine doğru zamanda doğru soru.

Daha fazla özellik yerine daha hızlı değer.

Tek seferlik geliştirme yerine güncellenebilir bir codebase.

İyi bir uygulama kullanıcıdan sabır istemek yerine, kullanıcıya ilk dakikada neden kalması gerektiğini gösterir.

Öne çıkan noktalar

• Kullanıcı kaybının önemli bir bölümü uygulamanın ana özelliğinden önce, onboarding sırasında gerçekleşebilir.
• Bilgi ve izinleri ilk anda toplamak yerine ihtiyaç duyulduğu noktada istemek daha iyi bir UX oluşturur.
• Her ekranın mümkün olduğunca tek bir görevi olmalıdır.
• Kullanıcı uygulamanın değerini ne kadar erken görürse, sonraki adımları kabul etmek o kadar kolaylaşır.
• Native geliştirme her proje için zorunlu değildir. İhtiyaca göre web, PWA veya native yaklaşım seçilmelidir.
• Uygulamanın ilk sürümü kadar, sonraki güncellemelerin maliyeti de geliştirme kararlarının bir parçasıdır.
• İyi bir codebase, uygulamanın sürekli yeniden yazılmasını değil sürekli geliştirilmesini mümkün kılar. Uygulama geliştirme hizmetimize bakın.