Bir uygulamayı ilk açtığınızda ne yapacağınızı anlamak kolay mı? Size uzun bir tanıtım gösteriliyor, hemen hesap açmanız isteniyor veya henüz ihtiyacını bilmediğiniz izinler soruluyor olabilir. Bu ilk karşılaşma, ürünün nasıl algılandığını etkiler. Onboarding, kullanıcının uygulamayı tanımasını ve ilk anlamlı göreve ulaşmasını destekleyen başlangıç deneyimidir.
Onboarding yalnız art arda gösterilen hoş geldiniz ekranları değildir. İlk değerli bilginin ne zaman sunulduğu, kayıt gerekip gerekmediği, yardımın nerede verildiği ve kullanıcının hangi seçime sahip olduğu bu deneyimin parçalarıdır. İyi bir başlangıç, ürünün bütün özelliklerini anlatmaya çalışmaktan önce kullanıcının neden burada olduğunu düşünür. Bu yazıda mobil uygulama için bu kararları somutlaştırıyorum.
İlk değer anını tanımlamak
Kullanıcı uygulamanızı neden indirdi? Bir etkinliği bulmak, duygu durumunu kaydetmek veya uygun bir randevu görmek isteyebilir. İlk değer anı, bu ihtiyaca dair anlamlı bir sonuç gördüğü noktadır. Sonuç her zaman büyük bir işlem olmak zorunda değildir. Uygun seçenekleri görebilmek veya ilk kaydı oluşturabilmek de değerli olabilir.
MoodVerse çalışmamda duygu girişi, uygulamanın somut görevlerinden biridir. Bu tür bir ürünün ilk kullanımını düşünürken kullanıcıya yalnız genel tanıtım göstermek yerine ne yapabileceğini anlatan gerçek ekranlar değerlendirilebilir. Buradaki soru, ilk görev için hangi bilginin gerekli olduğudur. Her ürünün ilk değer noktası kendi amacı ve kullanıcıları üzerinden seçilmelidir.
Tanıtım ekranı gerçekten gerekli mi?
Bazı uygulamaların amacı arayüzden kolayca anlaşılabilir. Bazılarında ise yeni bir çalışma biçimi, özel bir görev veya alışılmadık bir kavram bulunur. Tanıtım ihtiyacı bu farktan doğar. Sırf başka uygulamalarda var diye aynı sayıda başlangıç ekranı eklemek, kullanıcının ihtiyacına cevap vermeyebilir. Her ekranın açıklayacağı önemli bir soru bulunmalıdır.
Tanıtımda bütün özellikleri sıralamak yerine başlangıç için gerekli bilgi seçilebilir. Kullanıcı bir özelliğe geldiğinde bağlam içinde açıklama göstermek başka bir seçenektir. Böylece henüz kullanmayacağı bilgileri en başta hatırlamak zorunda kalmaz. Ancak sonradan verilen yardımın bulunabilir olması gerekir. Ekran sayısını azaltmak tek başına iyi onboarding anlamına gelmez.
Kayıt hangi aşamada istenmeli?
Hesap ihtiyacı ürünün işlevine bağlıdır. Kişisel verinin korunması, işlem geçmişinin saklanması veya bir hizmetin sunulması için kimlik gerekebilir. Başka bir üründe kullanıcı bazı içerikleri hesap açmadan inceleyebilir. Bu nedenle kayıt zamanını belirlemek, yalnız daha az adım istemekle çözülemez. Teknik ve iş gereksinimleri birlikte konuşulmalıdır.
Temsili bir etkinlik uygulamasında herkesin programı görmesi mümkün olabilir; bilet satın alma aşamasında ise ek bilgiler istenebilir. Bir kişisel takip uygulamasında veri saklama tercihleri daha erken gündeme gelebilir. Kullanıcıdan istenen her alanın gerekçesi bulunmalıdır. Gereksiz bilgiyi başlangıç formuna eklemek, ürünün ilk görevini daha ağır hâle getirebilir.
İzinleri kullanım bağlamına yerleştirmek
Bildirim, kamera veya konum gibi izinler, ilgili özelliklerin çalışmasıyla bağlantılı olabilir. Kullanıcı henüz bu özelliği görmeden izin istediğinizde nedenini anlamayabilir. Tasarımda izin ihtiyacının bağlamı açıklanabilir: hangi görev için isteniyor ve izin verilmezse hangi seçenek mevcut? Gerçek sistem davranışı geliştirme ekibiyle netleştirilmelidir.
Örneğin yakındaki etkinlikleri bulma işlevi konumla ilişkilidir. Kullanıcı bu göreve geldiğinde açıklama sunulabilir. Alternatif olarak bölgeyi elle seçmek mümkünse bu yol görünür olabilir. Tasarım, kullanıcıyı bütün izinleri tek seferde kabul etmeye zorlayan belirsiz bir başlangıçtan daha anlaşılır seçenekler üretebilir. Uygulamanın gerçek gereksinimleri bu seçenekleri belirler.
Metinler kısa ama açıklayıcı olmalı
“Devam” düğmesi her adımda yeterli olmayabilir. Kullanıcı devam ettiğinde hesabı mı oluşacak, verisi mi kaydedilecek veya tanıtım mı kapanacak? Önemli işlemlerde etiket, sonucun ne olduğunu tarif etmelidir. Başlık, açıklama ve düğme birlikte okunduğunda adımın görevi anlaşılabilir. Kısa metin, belirsiz metin anlamına gelmemelidir.
Başlangıç deneyiminde marka tonu da önemlidir. Samimi bir ifade, bilgi eksikliğini gidermiyorsa yalnız süs görevi görür. Teknik bir ürünün her cümlesi ise jargonla kurulmak zorunda değildir. Kullanıcının bilmesi gereken şey sade biçimde anlatılabilir. Metin hazırlığı, ekran tasarımının sonunda rastgele doldurulacak bir boşluk olarak görülmemelidir.
Atlama ve geri dönme seçenekleri
Bir kullanıcı ürünü zaten tanıyor olabilir veya açıklamayı daha sonra okumak isteyebilir. Uygun yerlerde tanıtımı atlama seçeneği düşünülebilir. Fakat zorunlu güvenlik, hesap veya işlem adımlarıyla isteğe bağlı tanıtımlar aynı şey değildir. Tasarımın hangi adımın neden gerekli olduğunu ayırması gerekir. Her ekranı atlanabilir yapmak da her ekranı zorunlu yapmak da otomatik çözüm değildir.
Atlanan bilginin daha sonra nerede bulunacağı önemlidir. Yardım, ayarlar veya ilgili özellik içinde açıklama sunulabilir. Kullanıcı uygulamayı yeniden açtığında bütün tanıtımın tekrar gösterilip gösterilmeyeceği de belirlenmelidir. Başlangıç akışı, ilk açılışın yanında yarıda bırakılmış ve geri dönülmüş durumları düşünmelidir.
İlerleme hissi nasıl kurulur?
Birden fazla adım gerekiyorsa kullanıcı nerede olduğunu anlayabilmelidir. Adım isimleri veya uygun bir ilerleme göstergesi yardımcı olabilir. Ancak göstergenin gerçek akışa uyması gerekir. Son adımdan sonra yeni formlar açılması, kullanıcının beklentisini değiştirebilir. Tasarım, işlem sınırlarını ve gerekli bilgileri başlangıçta görünür kılabilir.
Kısa bir akışta büyük bir ilerleme bileşeni gereksiz olabilir. Daha karmaşık bir kayıt sürecinde ise bölümleme ve geri dönüş seçenekleri yararlı olabilir. Hangi alanların korunduğu ve hangilerinin yeniden doldurulacağı belirlenmelidir. Akışın yalnız güzel ekranlar olarak değil, veri ve işlem davranışıyla birlikte düşünülmesi gerekir.
Boş ekran ilk kullanımı tamamlar
Kullanıcı tanıtımı bitirmiş olabilir ama henüz kaydı, listesi veya içeriği bulunmayabilir. Bu boş durum, onboarding’in devamı gibi düşünülebilir. Ekran yalnız boş görünmek yerine ilk öğenin nasıl oluşturulacağını açıklayabilir. Gerekiyorsa bir örnek gösterilebilir; ancak örneğin gerçek kişisel veri olmadığı belli olmalıdır.
Temsili bir alışkanlık uygulamasında boş listeye “ilk alışkanlığını oluştur” çağrısı ve kısa açıklama eklenebilir. Bir katalog uygulamasında ise ilk keşif seçenekleri sunulabilir. Kullanıcının bir sonraki adımı aramak zorunda kalmaması değerlidir. Boş durumun metni ve eylemi, ürünün asıl görevine bağlanmalıdır.
İlk kullanım için temsili bir akış
Bir randevu uygulamasını düşünelim. Kullanıcı uygulamayı açar ve hangi hizmetleri bulabileceğini görür. İlgili hizmeti seçer, uygun zamanları inceler, ardından rezervasyon için gereken bilgileri girer. İşlem sonunda tarih ve yer açık biçimde gösterilir. Bu akışta başlangıç tanıtımı, kullanıcının temel sorusunu geciktirmeden göreve bağlanabilir.
Aynı akışın alternatifleri de incelenmelidir. Uygun zaman bulunamazsa ne gösterilecek? Kullanıcı kayıt adımında vazgeçerse seçtiği hizmet korunacak mı? Bağlantı kesilirse rezervasyonun oluşup oluşmadığını nasıl anlayacak? Bu durumlar, başlangıç deneyiminin gerçek kullanımda devam edebilmesi için tasarım kapsamına alınabilir.
Gereksiz bir başlangıç adımını bulmak
Temsili bir içerik uygulaması, ilk açılışta beş ilgi alanı seçimi ve uzun profil bilgisi istiyor olsun. Kullanıcı ise yalnız programı görmek için gelmiştir. Önce her alanın neden gerekli olduğunu yazın. İlk görev için kullanılmayan bilgiler daha sonraki bağlama taşınabilir mi? Bu soru, başlangıcı yalnız estetik olarak yenilemekten farklı bir çözüm alanı açar.
Bir adımı kaldırmadan önce teknik ve ticari bağımlılıkları kontrol edin. Bazı bilgiler gerçekten gerekli olabilir. Bu durumda alanın nedeni açıklanabilir veya giriş daha anlaşılır biçimde bölünebilir. Tasarım kararını yalnız ekran sayısını azaltma hedefiyle vermek yerine işlevlerle birlikte değerlendirin. Kullanıcının gördüğü akış, ürünün gerçek gereksinimlerine dayanmalıdır.
Yeni taslakta ilk görev ve sonuç daha erken görünür olabilir. Ancak kayıt, yardım ve geri dönme durumları yine tanımlanır. Kullanıcı uygulamayı kapatıp açtığında nereden devam edeceğini bilmelidir. Onboarding’in kalitesi, sadece ilk birkaç güzel ekranla değil bu devam durumlarıyla da değerlendirilir.
Tanıtımı atlayan kullanıcıya tekrar gösterilir mi? İhtiyaca göre belirlenir. Yardım alanından erişim veya ilgili özellikte kısa açıklama sunulabilir. Her açılışta aynı tanıtımı zorunlu tekrarlamak gerekmeyebilir. Davranış, kullanıcı seçimi ve teknik durumlarla birlikte tanımlanır.
İlk ekranda bütün avantajları anlatmalı mıyım? Başlangıç görevi için gerekli bilgiler önceliklendirilir. Özelliklerin tamamı başka alanlarda açıklanabilir. Kullanıcının henüz denemediği işlevleri uzun metinle sıralamak yerine ilgili görevle bağ kurmak düşünülebilir. Amaç ürünü anlamaya ve kullanmaya yardımcı olmaktır.
Mevcut verimiz yoksa nasıl başlanır? Ürün amacı ve bilinen kullanıcı görevleri üzerinden taslak çıkarılabilir. Varsayımlar açıkça yazılır. Sonra gerçekçi görev denemeleriyle belirgin sorunlar gözlenebilir. Bu çalışma, ölçülmemiş ticari sonuçlara dair iddia oluşturmadan ilk deneyimin geliştirilmesini destekler.
Tasarım çalışmasına hangi bilgilerle başlanır?
Ürünün temel amacı, hedef kullanıcıları ve ilk tamamlanmasını istediğiniz görev başlangıç bilgisidir. Mevcut uygulama varsa ekranlar ve kullanıcı geri bildirimleri eklenebilir. Hangi bilgilerin veya izinlerin zorunlu olduğu teknik ekiple belirlenmelidir. Ticari beklentiler de konuşulur; ancak bütün veriyi ilk ekranda toplamak her hedef için doğru yöntem olmayabilir.
Bu bilgilerle bir akış haritası ve ilk ekran düzenleri hazırlanabilir. Önce görev sırası değerlendirilir, ardından görsel yön geliştirilir. Prototipte temel yollar ve önemli alternatifler gösterilebilir. Geliştiriciye teslimde hangi ekranın hangi durumda açıldığı ve hangi verinin korunacağı açıklanır. Böylece tasarım, yalnız tanıtım görsellerinden daha kapsamlı bir başlangıç deneyimine dönüşür.
Performansı nasıl değerlendirebilirsiniz?
İlk görevin tamamlanması, adımlar arasındaki geçişler ve belirgin terk noktaları incelenebilir. Fakat bütün uygulamalar için tek bir metrik yeterli değildir. Kullanıcının amacı ve akışın gereksinimleri sonucu etkiler. Sadece tanıtımı hızlı bitirmesi, ürünü anladığını göstermeyebilir. Kısa görev denemeleri ve geri bildirimler sayısal veriyi tamamlayabilir.
Bir değişiklikten sonra sonuçları karşılaştırırken tarih aralığı ve koşullar kaydedilmelidir. Kullanıcı kitlesi veya kampanya değişmişse etkiyi yalnız yeni ekranlara bağlamak zor olabilir. Tasarımda gözlenen sorun, yapılan değişiklik ve verideki hareket ayrı ayrı yazılabilir. Bu yaklaşım, öğrenilenleri daha güvenilir biçimde bir sonraki sürüme taşır.
Sık sorulan onboarding soruları
Üç hoş geldiniz ekranı yeterli midir? Ekran sayısı görevin sonucudur. Bir uygulama tanıtıma ihtiyaç duymayabilir; başka bir ürün belirli bir kavramı açıklamak isteyebilir. Önce hangi bilginin gerçekten gerekli olduğunu belirleyin. Sayıyı bu karardan sonra konuşmak daha anlamlıdır.
Mevcut onboarding akışı yenilenebilir mi? Evet. Önce adımların görevi ve gerekli bilgiler incelenebilir. Teknik olarak korunması gereken işlemlerle sadeleştirilebilecek tanıtım alanları ayrılır. Böylece değişikliklerin hangi geliştirme işlerini gerektirdiği görünür olur.
Tasarım hizmeti uygulamanın kodunu da kapsar mı? Mobil UI/UX tasarımıyla geliştirme ayrı teslimlerdir. Akış, ekran ve prototip çalışmaları kapsamlandırılır; kodlama ve servis bağlantıları ayrıca planlanır. Bu ayrım, onboarding taslağının hangi aşamada kullanılacağını netleştirir.
İlk açılışı ilk göreve bağlamak
Onboarding’in değeri, kullanıcıyı gerçek bir ihtiyaçla buluşturmasında ortaya çıkar. Tanıtım, kayıt, izin ve boş ekranlar bu hedefe göre planlandığında başlangıç daha anlaşılır olabilir. Uygulamanızı yenilerken ilk olarak bütün özellikleri nasıl anlatacağınızı değil, kullanıcının ilk değerli adımı nasıl atacağını düşünün.
Mobil uygulama tasarımı hizmetimde ilk kullanım akışını ekranlar ve durumlarla birlikte ele alıyorum. Mevcut başlangıç ekranlarınızı ve uygulamanın ana görevini benimle paylaşabilirsiniz. Böylece tasarım kapsamını gerçek kullanım ihtiyacına göre belirleyebiliriz.
Kaynak ve örnek
- Onur Demircan: MoodVerse uygulama tasarımı
- Randevu ve etkinlik senaryoları temsili; akış önerileri özgün tasarım analizidir.
Kapak görseli: Apple / Human Interface Guidelines, Onboarding. Görselin orijinal kaynağı.