Temmuz başında bir spor salonu zincirinin mobil uygulamasını yayına aldık. İlk hafta 4.200 indirme geldi; pazarlama ekibi haklı olarak sevindi. Sonra Firebase panelini açtık ve tablo değişti: kullanıcıların yüzde 58'i kayıt ekranını bile görmeden uygulamayı kapatmıştı. Uygulamanın kendisinde bir sorun yoktu. Sorun, kullanıcıyı uygulamaya taşıyan o ilk 30 saniyedeydi.
Açık konuşayım: 2010'dan beri teslim ettiğimiz projelerde en çok emek verilen ekranlar hep ana akışlardı — ders programı, ödeme, harita. Onboarding ise çoğu zaman son haftaya sıkıştırılan, "üç ekran slayt koyarız, geçeriz" denilen bir bölümdü. O yaz yaşadığımız tecrübe bize bunun ne kadar pahalı bir ihmal olduğunu gösterdi. Kullanıcı edinme maliyeti indirme başına 18 TL'yi bulmuşken, her silinen uygulama doğrudan çöpe atılmış reklam bütçesi demekti.
Kullanıcı Daha Parola Belirlemeden Neden Vazgeçer?
İnsanlar bir uygulamayı indirdiklerinde kafalarında tek bir soru vardır: "Bu bana ne kazandıracak?" Bu sorunun cevabını geciktiren her ekran, vazgeçme ihtimalini büyütür. Spor salonu uygulamasında ilk açılışta kullanıcıyı beş ekranlık bir tanıtım turu karşılıyordu; ardından telefon numarası, SMS doğrulaması, parola, ad-soyad ve doğum tarihi isteniyordu. Kullanıcı, tek bir ders saatini görmeden yedi adım geçmek zorundaydı.
Biz akışı tersine çevirdik. Uygulama artık ilk açılışta doğrudan en yakın şubenin haftalık ders programını gösteriyor; kayıt, ancak kullanıcı bir derse yer ayırtmak istediğinde devreye giriyor. Tasarım ekibimizle geliştiricilerimiz bu kararı birlikte aldı, çünkü "önce içerik, sonra kayıt" yaklaşımı backend tarafında anonim oturum yönetimi gerektiriyordu. Tasarımcının çizdiği akış, geliştiricinin mimarisiyle örtüşmezse kâğıt üzerinde kalır; bunu yıllar içinde defalarca gördük.
Bu değişikliğin bir yan etkisi daha oldu ve bunu başta öngörmemiştik: kayıt olan kullanıcının niteliği arttı. Önceden kayıt formunu dolduran kullanıcıların önemli bir kısmı uygulamayı bir daha açmıyordu; formu "mecbur kaldığı için" doldurmuştu. Yeni akışta kayıt olan kişi, zaten bir derse yer ayırtmak isteyen kişiydi — yani niyetli kullanıcı. Pazarlama ekibinin baktığı "kayıtlı kullanıcı" sayısı ilk iki hafta neredeyse hiç artmadı ve müşteri tarafında kısa bir panik yaşandı; ama otuz günlük geri dönüş oranı tablosu gelince tartışma kapandı.
Sonuç mu? Ağustos ortasında kayıt tamamlama oranı yüzde 42'den yüzde 71'e çıktı.
Beş Ekranlık Tanıtım Turu Kimi Mutlu Ediyor?
Cevap genellikle şu: müşterinin pazarlama departmanını. Kullanıcıyı değil.
Tanıtım turları — o kaydırmalı, illüstrasyonlu, "Hoş geldiniz!" ekranları — çoğu projede uygulamanın kendini anlatamadığının itirafıdır. Arayüz yeterince açıksa, kullanıcının üç ekran boyunca ne yapacağının anlatılmasına gerek kalmaz. Biz bu turları tamamen reddetmiyoruz; ama bir kural koyduk: tur, ancak uygulamanın değer önerisi ekran görüntüsüyle anlatılamıyorsa var olabilir ve asla üç ekranı geçemez. Ayrıca "Atla" düğmesi ilk ekrandan itibaren, başparmağın rahat ulaştığı yerde durur. Kullanıcıyı rehin almak, onu ikna etmek değildir.
Bir de şu var: tanıtım ekranlarındaki metinler genellikle şirketin kendisini anlatır. "Türkiye'nin en büyük spor zinciri" cümlesi kullanıcının derdine dokunmaz. "Yarın sabahki derse 10 saniyede yer ayırt" cümlesi dokunur. Metin yazımı da onboarding tasarımının parçasıdır ve bizde bu metinleri tasarımcıyla birlikte, gerçek ekran üzerinde yazarız — Word dosyasında değil.
İzin İsteklerinin Sıralaması Bir Tasarım Kararıdır
İlk 30 saniyenin en riskli anlarından biri, sistem izin pencereleridir. Bildirim, konum, kamera... Uygulama daha kendini kanıtlamadan art arda üç sistem penceresi açarsanız, kullanıcının refleksi "Reddet"e basmak olur. iOS'ta bildirim iznini bir kez kaçırdığınızda, kullanıcıyı ayarlara yönlendirmekten başka çareniz kalmaz — ve kimse ayarlara gitmez.
Bizim uyguladığımız yöntem, izni bağlama bağlamak. Konum iznini uygulama açılır açılmaz değil, kullanıcı "en yakın şubeyi göster" dediğinde istiyoruz. Bildirim iznini, kullanıcı ilk dersine yer ayırttıktan hemen sonra, "Ders başlamadan 1 saat önce hatırlatalım mı?" sorusuyla birlikte soruyoruz. Aynı izin penceresi, doğru anda sorulduğunda bambaşka bir kabul oranı üretiyor: spor salonu projesinde bildirim izni kabulü bu değişiklikle yüzde 31'den yüzde 78'e çıktı. Tek satır yeni özellik yazmadan.
Bu da tasarımcı-geliştirici işbirliğinin klasik örneği aslında. Tasarımcı "izni şurada soralım" der, geliştirici sistem kısıtlarını bilir (iOS'ta ön-izin ekranı denen ara katmanı o önerir), ikisi birlikte akışı kurar. Bu konuşma yapılmadığında izin pencereleri uygulamanın açılışına yığılır, çünkü teknik olarak en kolay yer orasıdır.
Boş Ekran, Onboarding'in Unutulan Yarısı
Kayıt biter, kullanıcı içeri girer ve... bomboş bir ekranla karşılaşır. Henüz ders geçmişi yok, favori antrenörü yok, istatistiği yok. Bu boş anlar, teknik olarak onboarding bittikten sonra gelse de kullanıcının zihninde hâlâ "bu uygulama bana ne veriyor?" sorusu açıktır.
Boş ekranları birer yönlendirme fırsatı olarak tasarlıyoruz. "Henüz dersin yok" yazan gri bir ekran yerine, o hafta en çok doluluk alan üç dersi öneren, tek dokunuşla yer ayırtmaya götüren bir ekran koyduk. Küçük bir dokunuş gibi görünüyor ama ilk hafta içinde ikinci kez ders ayırtan kullanıcı oranını gözle görülür biçimde yukarı çekti. (İtiraf edeyim, bu fikir tasarım toplantısında değil, geliştiricilerimizden birinin "burası çok ölü duruyor" demesiyle çıktı.)
Bir uygulamanın ilk 30 saniyesi, o uygulamaya harcanan aylarca emeğin vitrini. Vitrin karanlıksa, içerideki ürünün kalitesinin önemi kalmıyor. Kendi uygulamanızın ilk açılış verilerine bakıp "bir şeyler yanlış ama ne?" diyorsanız, bize yazın; akışınıza birlikte bakalım.
Ölçmediğiniz Onboarding'i İyileştiremezsiniz
Son bir not: bu yazıdaki bütün oranları verebiliyorum, çünkü her adımı ayrı bir olay olarak ölçüyoruz. Hangi ekranda kaç kullanıcı düştü, "Atla"ya kaç kişi bastı, izin penceresinde kabul oranı ne — bunlar yayın öncesinde analitik planına yazılır. Onboarding'i sezgiyle tasarlarsınız, ama sezginizi ancak veriyle test edersiniz.
Ölçüm planını kurarken kullandığımız pratik bir çerçeve var. Onboarding'i tek bir dönüşüm oranı olarak değil, bir merdiven olarak düşünüyoruz: uygulamayı açtı, ilk anlamlı içeriği gördü, ilk etkileşimini yaptı, ilk değerini aldı (bizim projede bu, ders rezervasyonuydu) ve ertesi gün geri geldi. Her basamak ayrı ölçülür, çünkü toplam oran size sorunun var olduğunu söyler ama nerede olduğunu söylemez. Spor salonu projesinde toplam oran kötüydü; basamaklara bakınca sorunun neredeyse tamamının SMS doğrulama adımında yığıldığını gördük. Operatör kaynaklı gecikmeler yüzünden doğrulama kodu bazı kullanıcılara iki dakika sonra ulaşıyordu ve iki dakika, mobilde bir ömürdür.
Bu keşif de tasarımla geliştirmenin kesiştiği yere düştü: tasarım tarafı bekleme ekranına geri sayım ve "kodu tekrar gönder" seçeneği ekledi, geliştirme tarafı ikinci bir SMS sağlayıcısını yedek olarak devreye aldı. İki küçük değişiklik, tek başına en büyük sızıntıyı kapattı.
Spor salonu projesinde ilk sürümdeki akış da bize gayet mantıklı görünüyordu. Veri, mantıklı görünenle çalışan arasındaki farkı gösterdi. Bir sonraki projenizde onboarding'e son haftayı değil, ilk haftayı ayırın; farkı ilk sürümden itibaren görürsünüz.