Uygulama Onboarding Ekranı Nasıl Tasarlanır? Kaydı Artıran Akış

Bir uygulamayı indiren kişi, ilk açılışta birkaç ekran içinde kalıp kalmayacağına karar verir. Bu kararın verildiği yer çoğu zaman onboarding ekranıdır. Bu rehberde Talha Aslan ve ekibi olarak karşılama ekranlarını, kayıt adımını ve izin isteklerini kayıt oranını artıracak biçimde nasıl kurduğumuzu, mağaza kurallarıyla birlikte adım adım anlatıyoruz.

Terim İngilizceden gelir; Türkçede "uygulamaya alıştırma" ya da "ilk kullanım akışı" diye karşılayabilirsiniz. Apple, İnsan Arayüzü Yönergeleri onboarding bölümünde ideal durumu şöyle tarif eder: insanlar uygulamayı yalnızca deneyimleyerek anlayabilmeli; onboarding gerekiyorsa da akış hızlı, keyifli ve isteğe bağlı olmalı. Dolayısıyla amaç ekran sayısını artırmak değil, kullanıcıyı en kısa yoldan işe yarar bir sonuca götürmektir.

Kayıt oranı açısından mesele basittir. Kullanıcı neden hesap açması gerektiğini anlamadan form görürse çıkar. Ancak uygulamanın ona ne kazandırdığını gördükten sonra aynı formu çok daha makul bulur. Bu nedenle onboarding ekranı, kayıt formunun önünde duran bir ikna katmanı gibi çalışır.

Onboarding ile kayıt akışı aynı şey mi?

Hayır, ikisi iç içe geçse de farklı işler görür. Kayıt akışı hesabı oluşturur; onboarding ise kullanıcının uygulamadan ilk faydayı almasını sağlar. Ürün ekipleri bu ilk fayda anını genellikle "aktivasyon" diye adlandırır. Örneğin bir bütçe uygulamasında aktivasyon ilk harcamayı girmek, bir randevu uygulamasında ise ilk randevuyu almaktır.

Bu ayrım tasarımı doğrudan değiştirir. Kayıt akışını onboarding sanan ekipler, ilk açılışta e-posta, şifre, telefon ve doğum tarihi isteyen uzun bir form kurar. Oysa kullanıcı o noktada henüz hiçbir değer görmemiştir. Öte yandan onboarding'i aktivasyona giden yol olarak düşündüğünüzde, kaydı bu yolun en mantıklı noktasına yerleştirirsiniz.

Pratikte üç parçayı ayrı ayrı planlamanızı öneriyoruz:

• Tanıtım: uygulamanın ne işe yaradığını tek cümleyle anlatan karşılama.
• Aktivasyon: kullanıcının ilk gerçek işi yaptığı an.
• Hesap: verinin kaydedilmesi, eşitlenmesi ya da paylaşılması gerektiğinde devreye giren kayıt.

Ayrıca kullanıcıların ilk günlerde uygulamayı neden sildiğini merak ediyorsanız, mobil uygulama kullanıcılarının ilk 7 günde neden sildiğini anlattığımız yazıya göz atabilirsiniz; orada elde tutma tarafını ayrıca ele aldık.

Hangi onboarding türleri var, hangisi size uyar?

Tek bir doğru kalıp yoktur; uygulamanın karmaşıklığına göre seçim yaparsınız. Sahada en sık gördüğümüz dört yaklaşım şunlardır:

• Tanıtım slaytları: üç dört kaydırmalı ekranda faydaları anlatır. Kurması kolaydır, ama kullanıcı çoğu zaman metni okumadan geçer.
• Etkileşimli öğretim: kullanıcı gerçek arayüzde güvenli bir deneme yapar. Apple da yönergelerinde etkileşim yoluyla öğretmeyi öne çıkarır.
• Bağlamsal ipuçları: tek bir akış yerine, ilgili özellik ilk kez açıldığında küçük bir ipucu gösterir.
• Kişiselleştirme soruları: ilgi alanı ya da hedef sorup ilk ekranı buna göre doldurur.

Basit bir uygulamada tanıtım slaytlarına hiç gerek kalmayabilir. Örneğin tek işlevli bir not uygulaması, kullanıcıyı doğrudan boş not ekranına alıp küçük bir ipucuyla yetinebilir. Buna karşılık çok özellikli bir saha yönetim uygulamasında bağlamsal ipuçları çok daha iyi çalışır. Çünkü kullanıcı her özelliği aynı gün kullanmaz.

Apple'ın önerisi de bu yöndedir: tek bir uzun akış yerine bağlama özel ipuçlarından oluşan bir koleksiyon düşünmenizi ve talimatı ilgili arayüz bölgesinin yanında göstermenizi önerir. Kısacası tür seçimini estetik tercih değil, uygulamanın karmaşıklığı belirlemeli.

Onboarding ekranı kaç sayfa olmalı?

Apple ya da Google bunun için sabit bir sayı koymaz. Apple yalnızca akışın kısa olmasını, kullanıcıdan çok şey ezberlemesini beklememesini ister ve çok fazla şey öğretmeye çalışmanın kullanıcıyı bunaltacağını belirtir. Dolayısıyla sayıyı kuraldan değil, anlatmanız gereken mesaj sayısından türetirsiniz.

Saha tecrübemize dayalı başlangıç önerimiz, tanıtım için en fazla üç ekrandır; bu bir garanti değil, test etmeye değer bir başlangıç noktasıdır. Her ekran tek bir fikir taşımalı. İlk ekran uygulamanın ana faydasını, ikinci ekran nasıl çalıştığını, üçüncü ekran ise kullanıcıyı ilk işe çağıran eylemi anlatabilir.

Ekran sayısını azaltmak için şu soruyu sorun: bu bilgiyi kullanıcı ilgili özelliğe geldiğinde öğrenebilir mi? Cevap evetse o ekranı akıştan çıkarıp bağlamsal ipucuna dönüştürün. Üstelik her ekranın altına bir ilerleme göstergesi koyun. Böylece kullanıcı kaç adım kaldığını bilir ve sabrını buna göre ayarlar.

Örnek senaryo: bir spor salonu uygulaması ilk sürümde yedi tanıtım ekranı gösteriyor olsun. Ekip ekranları tek tek inceler ve dördünün aslında ayarlar menüsünde anlatılabilecek bilgiler olduğunu fark eder. Kalan üç ekranla yeniden test eder, tamamlama adımlarını analitikte karşılaştırır.

Atla düğmesi koymalı mısınız?

Evet, tanıtım ve öğretici ekranlarda atla düğmesi neredeyse her zaman doğru tercihtir. Apple, ayrı bir öğreticiyi isteğe bağlı yapmayı önerir. Ayrıca kullanıcı ilk açılışta öğreticiyi atlarsa sonraki açılışlarda tekrar göstermemenizi, ama yardım, hesap ya da ayarlar bölümünden kolayca bulunabilir tutmanızı ister.

Atla düğmesi özellikle iki kullanıcı grubunu korur. Birincisi uygulamayı daha önce kullanmış ve telefonunu değiştirmiş kişilerdir. İkincisi reklamdan gelip ne istediğini zaten bilen kullanıcılardır. Bu kişileri slaytlara zorlamak, onları ilk dakikada sinirlendirmek demektir.

Düğmenin yeri ve metni de önemlidir. "Atla" yerine "Hemen başla" gibi kullanıcının kazancını anlatan bir ifadeyi kullanıcılar çoğu zaman daha kolay kavrar. Düğmeyi ekranın köşesine çok küçük yerleştirmek ise kullanıcıyı kandırmaya çalışan karanlık desen gibi durur. Öte yandan atla düğmesini kayıt ya da yasal onay gibi zorunlu adımları atlatmak için kullanmayın. Zorunlu bir adım varsa onu açıkça zorunlu olarak gösterin ve nedenini tek cümleyle yazın.

Son olarak atlayan kullanıcıyı analitikte ayrı bir olay olarak işaretleyin. Bu sayede atlayanlar ile akışı tamamlayanların ilk hafta davranışını karşılaştırabilirsiniz.

Değeri kayıttan önce nasıl gösterirsiniz?

En etkili yöntem, kullanıcıya hesap açmadan önce uygulamanın asıl işini kısa bir süre yaptırmaktır. Apple da yönergelerinde değerlendirme ve satın alma isteklerini, kullanıcı uygulamayı deneyimledikten sonra göstermeyi önerir. Aynı mantık kayıt için de geçerlidir.

Örnek senaryo: bir yemek tarifi uygulaması düşünün. Kötü kurguda ilk ekran "Hesap oluşturun" der. İyi kurguda kullanıcı önce tarifleri gezer, birini açar, malzeme listesini görür. Tarifi kaydetmek istediğinde uygulama "Tariflerinizi tüm cihazlarınızda saklamak için hesap açın" diye sorar. Bu noktada kayıt bir engel değil, kullanıcının zaten istediği bir işin parçası olur.

Değeri göstermenin başka yolları da var:

• Örnek veriyle dolu bir ekran göstermek; boş bir panel yerine dolu bir görünüm sunmak.
• Kişiselleştirme sorusunun cevabına göre ilk içeriği anında hazırlamak.
• Ücretli özelliğin kısa bir önizlemesini, kilitli de olsa göstermek.

Bu kurguyu sonradan eklemek, baştan planlamaktan daha pahalıdır. Bu yüzden mobil uygulama geliştirme projelerinde ekibimiz akışı ilk tel kafes (wireframe) aşamasında çizer; uygulamanızı biz geliştirir, mağazaya da biz çıkarırız.

Kayıt ertelenebilir mi, misafir modu ne zaman doğru?

Çoğu uygulamada evet, ertelenebilir; hatta bazı durumlarda ertelemek zorunludur. Apple'ın App Store İnceleme Yönergeleri 5.1.1(v) maddesi, uygulamanızda önemli hesap tabanlı özellikler yoksa insanların giriş yapmadan kullanabilmesine izin vermenizi ister. Ayrıca uygulamanın, temel işleviyle doğrudan ilgili değilse ya da yasa gerektirmiyorsa kişisel bilgi girmeden çalışması gerekir.

Bu nedenle kaydı erteleyip ertelemeyeceğinizi şu soruyla netleştirin: hesap olmadan kullanıcı uygulamanın ana faydasını alabiliyor mu? Bir mesajlaşma ya da bankacılık uygulamasında hesap işin kendisidir. Buna karşılık bir hesap makinesi, tarif ya da rehber uygulamasında hesap yalnızca kaydetme ve eşitleme için gerekir.

Misafir modu kurduğunuzda iki konuyu baştan planlayın:

1. Veri taşıma: misafirken oluşturulan içerik, hesap açıldığında kaybolmamalı.
2. Doğru tetikleyici: kayıt isteği, kullanıcı kaydetme, paylaşma ya da cihaz değiştirme gibi hesap gerektiren bir işe dokunduğunda çıkmalı.
3. Açık sınır: misafir modda hangi özelliklerin kapalı olduğunu kullanıcıya dürüstçe söyleyin.

Yönergelerin güncel metnini yayın öncesinde mutlaka kontrol edin; maddeler zaman içinde güncellenebilir.

Apple ile giriş zorunlu mu?

Her uygulama için değil. App Store İnceleme Yönergeleri 4.8 maddesine göre, ana hesabı kurmak ya da doğrulamak için Google, Facebook gibi üçüncü taraf ya da sosyal giriş hizmeti kullanan uygulamalar, eşdeğer seçenek olarak başka bir giriş hizmeti de sunmalıdır. Bu ikinci hizmetin veri toplamayı ad ve e-posta adresiyle sınırlaması, kullanıcının e-postasını gizli tutmasına izin vermesi ve uygulamadaki etkileşimleri onay olmadan reklam amacıyla toplamaması gerekir.

Pratikte ekipler bu şartı çoğunlukla Apple ile Giriş seçeneğini ekleyerek karşılar. Yönerge ise belirli bir ürünü değil, bu üç özelliği şart koşar. Yönerge, ek bir giriş hizmetinin gerekmediği durumları da listeler:

• Uygulama yalnızca şirketinizin kendi hesap ve giriş sistemini kullanıyorsa.
• Uygulama, mevcut bir eğitim ya da kurumsal hesapla giriş gerektiren bir eğitim, kurumsal veya iş uygulamasıysa.
• Uygulama, devlet ya da sektör destekli bir vatandaş kimlik sistemi veya elektronik kimlik kullanıyorsa.
• Belirli bir üçüncü taraf hizmetin istemcisi olan uygulamada, kullanıcı içeriğine erişmek için o hesaba doğrudan giriş yapıyorsa.

Onboarding açısından önemli olan şudur: Google ile giriş düğmesi koyduysanız, eşdeğer seçenek de aynı ekranda ve benzer görünürlükte durmalı. Apple ile girişi ikinci sayfaya gizlemek hem yönergeye hem de kullanıcı deneyimine ters düşer.

Hangi giriş yöntemlerini sunmalısınız?

Hedef kitlenize uyan ve en az adım gerektiren iki üç yöntemi seçin. Fazla seçenek kullanıcıyı karar vermeye zorlar; ancak tek seçenek de bir kısmını dışarıda bırakır. Genelde şu yöntemler arasında seçim yaparsınız:

• E-posta ve şifre: tanıdık bir yöntemdir, ama şifre oluşturma adımı sürtünme yaratır.
• E-postaya ya da telefona tek kullanımlık kod: şifre derdini kaldırır, ancak kullanıcının uygulamadan çıkıp mesajı açması gerekir.
• Google ile giriş ve Apple ile giriş: tek dokunuşla hesap açar.
• Geçiş anahtarı (passkey): şifre yerine cihazın biyometrik kilidini kullanır.

Android tarafında Google, Credential Manager adlı Jetpack API'sini önerir; bu API geçiş anahtarlarını, şifreleri ve Google ile giriş gibi birleşik giriş yöntemlerini tek arayüzde toplar. Böylece Android kullanıcıları kayıtlı bilgilerini tek bir sistem penceresinden seçebilir.

Formu kısa tutmayı da unutmayın. Apple'ın yönergeleri ad ve e-posta gibi temel iletişim bilgilerini isteyebileceğinizi, ama bunun isteğe bağlı olması ve özelliklerin bu bilgiye koşullanmaması gerektiğini belirtir. Yani doğum tarihi, cinsiyet ya da telefon numarasını gerçekten gerekmedikçe ilk kayıtta istemeyin.

Onboarding ekranında izinleri ne zaman istemelisiniz?

Kural basit: izni, kullanıcı o izne ihtiyaç duyan özelliğe dokunduğunda isteyin. Android geliştirici belgelerindeki çalışma zamanı izinleri rehberi de ilk ilke olarak bunu söyler: izni bağlamında, kullanıcı ilgili özellikle etkileşime girmeye başladığında isteyin.

Apple'ın yaklaşımı da benzer, ama bir ayrıntı ekler. Uygulamanız çalışabilmek için mutlaka özel bir veriye ya da kaynağa ihtiyaç duyuyorsa, izin isteğini onboarding akışına koymayı düşünebilirsiniz. Böylece neden gerektiğini ve kullanıcıya ne kazandıracağını anlatma fırsatı bulursunuz. Aksi halde istek, kullanıcının ilgili işleve ilk eriştiği anda gelmelidir.

Örnek senaryo: bir kurye takip uygulaması konumu ilk ekranda değil, kullanıcı "Siparişimi haritada göster" düğmesine bastığında ister. Aynı uygulama kamera iznini yalnızca fatura fotoğrafı yükleme anında sorar.

Bildirim izni bu konunun en hassas parçasıdır. Ne zaman ve hangi ön açıklamayla istemeniz gerektiğini push bildirim izninin ne zaman istenmesi gerektiğini anlattığımız yazıda ayrıntılı ele aldık; burada tekrarlamıyoruz.

Kullanıcı izni reddederse akış nasıl devam etmeli?

Akış durmamalı. Android belgeleri, bir izin reddedildiğinde uygulamanın kullanıcıyı engellemeden, gerekirse ilgili özelliği kapatarak çalışmaya devam etmesini ister. Tam ekran bir uyarıyla kullanıcının uygulamayı kullanmasını tamamen engellemeyi açıkça yanlış örnek olarak gösterir.

Apple'ın 5.1.1(iv) maddesi de aynı yöndedir: uygulamalar kullanıcının izin ayarlarına saygı göstermeli, kullanıcıyı gereksiz veri erişimine kandırmaya ya da zorlamaya çalışmamalıdır. Yönerge, konum paylaşmayı reddeden kullanıcıya adresi elle girme seçeneği sunmayı örnek verir.

Reddedilen izin için şu sırayı öneriyoruz:

1. Özelliği kapatın ama uygulamanın geri kalanını açık tutun.
2. Mümkünse alternatif yol sunun; örneğin konum yerine elle adres ya da posta kodu.
3. Kullanıcı aynı özelliğe yeniden dokunduğunda kısa bir açıklama gösterin ve "Şimdi değil" seçeneği bırakın.
4. Kullanıcıyı ayarlara yönlendirerek fikrini değiştirmeye zorlamayın.

Ayrıca Android'de kullanıcı aynı izni bir kurulum süresince birden fazla kez reddederse sistem izin penceresini artık göstermez; bu durum kalıcı ret anlamına gelir. Dolayısıyla izni rastgele anlarda tekrar tekrar istemek, sonunda hiç soramayacağınız bir duruma yol açar.

Kötü ve iyi onboarding ekranı akışı arasındaki fark nedir?

Farkı en net gösteren şey, aynı adımların iki farklı sırayla nasıl sonuç verdiğidir. Aşağıdaki tablo, ekibimizin akış incelemelerinde kullandığı karşılaştırmanın sade bir özetidir:

Tablodaki yasal metin satırı da Apple'ın önerisine dayanır: lisans ve sözleşme ayrıntılarını onboarding içinde göstermekten kaçının, mecbursanız deneyimi bölmeyecek dengeli bir biçimde yerleştirin.

Kişiselleştirme soruları akışı uzatır mı?

Uzatır, ama cevaplar ilk ekranı gerçekten değiştiriyorsa bu uzunluğa değer. Sorun, cevabı hiçbir yerde kullanılmayan sorulardır. Kullanıcı "Hedefiniz ne?" sorusuna cevap verip ardından herkesin gördüğü genel bir ana sayfaya düşerse, vaktini boşa harcadığını düşünür.

Apple, gerekli olmayan kurulum ve özelleştirme adımlarını ertelemenizi ve makul varsayılan ayarlar sunmanızı önerir. Böylece kullanıcıların çoğu ek ayar yapmadan uygulamayla hemen etkileşime girebilir. Bu nedenle kişiselleştirmeyi şu ölçütlerle sınırlayın:

• Soru sayısı az olsun; her soru tek dokunuşla cevaplanabilsin.
• Her sorunun yanında "Şimdilik geç" seçeneği bulunsun.
• Cevap, bir sonraki ekranda görünür bir fark yaratsın.
• Kullanıcı aynı tercihleri sonradan ayarlardan değiştirebilsin.

Örnek senaryo: bir dil öğrenme uygulaması yalnızca hedef dili ve günlük süreyi sorar. Cevaba göre ilk dersi hemen açar. Seviye tespiti gibi uzun bir adımı ise ilk dersin sonuna bırakır. Kullanıcı böylece ilk dakikada bir şey öğrenmiş olur.

Onboarding metinlerini nasıl yazmalısınız?

Kısa, somut ve kullanıcının kazancını anlatan bir dil seçin. Her ekranda tek bir başlık, en fazla iki kısa cümle ve tek bir ana düğme yeterlidir. "Dünyanın en iyi uygulaması" gibi iddialar yerine "Faturalarınızı tek fotoğrafla kaydedin" gibi somut bir fayda yazın.

Düğme metinleri özellikle önemlidir. "Devam" yerine "Planımı oluştur", "Gönder" yerine "Hesabımı aç" gibi sonucu anlatan fiiller kullanın. Ayrıca hata mesajlarını suçlayıcı değil, yol gösterici yazın: "Geçersiz e-posta" yerine "E-posta adresinde @ işareti eksik görünüyor" demek, kullanıcının sorunu hemen düzeltmesini sağlar.

İzin pencerelerindeki açıklama metinleri ayrı bir dikkat ister. Apple, amaç metinlerinin (purpose string) veriyi nasıl kullandığınızı açık ve eksiksiz anlatmasını şart koşar. Yani "Konumunuza ihtiyacımız var" yetersizdir; "Size en yakın şubeyi göstermek için konumunuzu kullanıyoruz" daha doğru bir örnektir.

Mikro metin yazımının genel ilkelerini UX writing nedir başlıklı yazımızda ele aldık; aynı ilkeler uygulama ekranlarında da geçerlidir.

Ekran tasarımında nelere dikkat etmelisiniz?

Onboarding ekranları tek elle, çoğu zaman hareket halindeyken kullanıcının elinde durur. Bu yüzden ana düğmeyi başparmağın rahat ulaştığı alt bölgeye yerleştirin. Bu bölgenin neden önemli olduğunu thumb zone rehberimizde anlattık.

Görsel tarafta şu noktaları kontrol listesine ekleyin:

• Her ekranda tek bir ana eylem ve görsel olarak geri planda kalan ikincil eylem bulunsun.
• İlerleme göstergesi kaç adım kaldığını açıkça göstersin.
• Metin, sistemin büyük yazı tipi ayarında da taşmadan okunabilsin.
• Açık ve koyu temada renk kontrastı yeterli kalsın.
• Görseller ve animasyonlar ilk açılışı yavaşlatmasın.

Ekipler son maddeyi sık unutur. Apple, büyük indirmelerin onboarding'i engellememesini ve kullanıcının indirme bitmesini beklemeden uygulamayla etkileşime başlayabilmesini önerir. Ayrıca açılış ekranı (splash screen) gerekiyorsa bunu yalnızca bir bakışta anlaşılacak kadar kısa tutmanızı ister. Android tarafında da Android 12 ve sonrasında açılış ekranı, uygulama simgesini gösteren standart bir sistem davranışıdır; ek bir marka ekranı eklemek çoğu zaman gereksiz bekleme yaratır.

Hesap silme yolu onboarding planının neresinde durur?

Kayıt ekranını tasarlarken hesap silme yolunu da aynı anda planlamalısınız. Apple'ın 5.1.1(v) maddesi, hesap oluşturmayı destekleyen uygulamaların uygulama içinden hesap silme de sunmasını şart koşar. Google Play tarafında ise Play Console Yardım'daki hesap silme şartları, uygulama içinde bir silme yolu ve ayrıca hesap silme talebinin yapılabileceği bir web bağlantısı ister.

Play belgesi önemli bir ayrıntıyı da vurgular: uygulamanın bazı özellikleri hesapsız çalışsa bile, deneyimin herhangi bir yerinde hesap oluşturma varsa hesap silme de sunulmalıdır. Dolayısıyla misafir modu olan bir uygulama da bu kuraldan muaf değildir.

Bunun onboarding ile ilgisi şudur: kullanıcı kayıt olurken verisinin ne olacağını merak eder. Ayarlar menüsünde açıkça görünen bir hesap silme seçeneği ve kısa bir gizlilik açıklaması güveni artırır. Ayrıca aydınlatma metni ve açık rıza adımlarını onboarding'e nasıl yerleştireceğinizi mobil uygulamada KVKK uyumu yazımızda anlattık. Bu konu hukuki danışmanlık değildir; metinleri hukuk danışmanınızla birlikte hazırlayın.

Onboarding ekranı başarısını hangi metriklerle ölçersiniz?

Ölçmediğiniz akışı iyileştiremezsiniz. Bu yüzden her ekranın görülmesini ve her düğmeye basılmasını ayrı bir olay olarak kaydedin. Önerdiğimiz temel olay seti şöyledir:

1. Onboarding başladı: ilk tanıtım ekranı görüldü.
2. Onboarding atlandı: kullanıcı atla düğmesine bastı.
3. Onboarding tamamlandı: son ekrandaki ana düğmeye basıldı.
4. Kayıt başladı ve kayıt tamamlandı: formun açılışı ve başarılı hesap oluşturma.
5. İzin istendi ve izin sonucu: kabul ya da ret.
6. Aktivasyon: kullanıcının ilk değerli işi yaptığı an.

Bu olaylarla adım adım bir dönüşüm hunisi kurarsınız ve kullanıcının en çok hangi ekranda ayrıldığını görürsünüz. Olay adlandırma ve kurulum ayrıntılarını mobil uygulamada hangi olayların ölçülmesi gerektiğini anlattığımız yazıda bulabilirsiniz.

Oranları hesaplarken, kayıt tamamlayan kullanıcıyı onboarding'e başlayan kullanıcıya bölersiniz. Bu hesabı hızlıca yapmak için dönüşüm oranı hesaplama aracımızı kullanabilirsiniz. Ancak tek bir orana bakmak yanıltıcıdır; kayıt oranı artarken aktivasyon düşüyorsa, akış kullanıcıyı yanlış bir beklentiyle içeri alıyor olabilir.

Onboarding için A/B testini nasıl kurgularsınız?

Her seferinde tek bir değişkeni test edin. Ekran sayısını, kayıt adımının yerini ve düğme metnini aynı anda değiştirirseniz, sonucu hangi değişikliğin yarattığını bilemezsiniz. Bu nedenle test planını önce bir hipotez cümlesiyle yazın.

Örnek hipotez: "Kaydı ilk tarif kaydetme anına taşırsak, ilk gün kayıt oranı düşmeden aktivasyon artar." Bu cümle hem neyi değiştireceğinizi hem de hangi metriğe bakacağınızı söyler. Ardından kullanıcıları rastgele iki gruba ayırır, yalnızca yeni kullanıcılarda test yaparsınız.

Test sırasında şu tuzaklara dikkat edin:

• Erken karar vermeyin; örneklem yeterli büyüklüğe ulaşmadan sonucu okumayın.
• Mağaza sürüm güncellemesi gerektiren değişikliklerde iki sürüm arasındaki diğer farkları not edin.
• Reklam kampanyası değişikliği gibi trafik kaynağını etkileyen olayları test dönemine denk getirmeyin.
• Yalnızca kayıt oranına değil, ilk hafta elde tutmaya da bakın.

Uzaktan yapılandırma ile ekran sırasını ya da metni mağaza güncellemesi olmadan değiştirmek mümkündür. Böylece testleri daha hızlı döndürürsünüz. Yine de yeni bir ekran ya da özellik eklemek çoğu durumda yeni bir sürüm ve mağaza incelemesi gerektirir.

Onboarding ekranı tasarımı için adım adım kontrol listesi

Yeni bir uygulamada ya da mevcut akışı yenilerken ekibimizin izlediği sıra kabaca şöyledir:

1. Aktivasyonu tanımlayın: kullanıcının ilk değerli işi tam olarak nedir?
2. Hesabın gerçekten ne zaman gerektiğini belirleyin ve kaydı o ana yerleştirin.
3. Tanıtım ekranlarını en fazla üç mesaja indirin, her birine tek fikir verin.
4. Görünür bir atla düğmesi ekleyin ve öğreticiyi ayarlarda bulunabilir tutun.
5. Giriş yöntemlerini seçin; sosyal giriş kullanıyorsanız eşdeğer seçeneği aynı ekrana koyun.
6. İzin listesini çıkarın ve her izni ilgili özelliğin açıldığı ana bağlayın.
7. Her izin reddi için alternatif yolu ve kapanacak özelliği yazın.
8. Amaç metinlerini ve düğme metinlerini sonuç anlatan bir dille yazın.
9. Hesap silme yolunu uygulama içinde ve web bağlantısı olarak hazırlayın.
10. Olay setini kurun, hunideki terk noktalarını haftalık izleyin.

Bu listeyi yayın öncesinde bir kez de gerçek cihazda, yeni kurulumla ve uçak modunda deneyin. Ayrıca büyük yazı tipi ayarı açıkken ekranları tek tek gözden geçirin. Çoğu taşma ve bağlantı sorunu ancak bu testte ortaya çıkar.

İlk sürümde onboarding'e ne kadar yatırım yapmalısınız?

İlk sürümde amaç kusursuz bir akış değil, ölçülebilir ve sade bir akıştır. Bu nedenle ilk sürümde süslü animasyonlar yerine doğru sıraya, ölçüme ve atla düğmesine yatırım yapın. Kullanıcı verisi geldikçe akışı aşama aşama zenginleştirirsiniz.

Hangi özelliklerin ilk sürüme girmesi gerektiğini konuştuğumuz mobil uygulama MVP rehberi bu kararı vermenize yardımcı olur. Onboarding de aynı mantığa tabidir: ilk sürümde aktivasyona hizmet etmeyen her ekranı sonraya bırakın.

Örnek senaryo: bir randevu uygulaması ilk sürümde yalnızca iki tanıtım ekranı, telefonla doğrulama ve bildirim iznini ilk randevu sonrasında isteyen bir akışla çıkar. İki hafta sonra veriye bakar ve en çok terkin doğrulama kodu ekranında olduğunu görür. Böylece ikinci sürümde yalnızca o ekranı iyileştirmeye odaklanır.

Uygulamanızın onboarding akışını kimle kurmalısınız?

Onboarding; tasarım, yazılım, mağaza kuralları ve ölçümün kesiştiği bir alan. Bu yüzden akışı yalnızca görsel bir iş olarak ele alan ekipler, mağaza incelemesinde ya da ölçüm aşamasında sürprizle karşılaşabilir. Örneğin sosyal girişi ekleyip eşdeğer seçeneği unutmak ya da hesap silme yolunu yayından sonra fark etmek sık rastlanan durumlardır.

Talha Aslan ve ekibi olarak uygulama projelerinde onboarding akışını tel kafes aşamasında kurgular, mağaza yönergelerine göre kontrol eder ve olay ölçümüyle birlikte teslim ederiz. Uygulamanızı biz geliştirir, App Store ve Google Play'e biz çıkarırız. Projeniz için kapsamı ve süreyi netleştirmek isterseniz mobil uygulama geliştirme hizmetimizden teklif isteyebilirsiniz.

Kısacası iyi bir onboarding ekranı kullanıcıya önce değer gösterir, sonra hesap ister ve izinleri yalnızca gerektiğinde sorar. Bu üç ilkeyi doğru sırayla uyguladığınızda kayıt oranı ile ilk hafta elde tutma birlikte iyileşir.