Onboarding tasarımı nasıl yapılır?

Kısaca

NN/g'den Alita Kendrick onboarding'i, uygulamanın normal arayüzünden ayrı duran ve kullanıcıyı uygulamaya alıştıran akışlar diye tanımlar. Kurulum da öğretme de bu işin içindedir. Yeni bir özellik çıktığında mevcut kullanıcı da onboarding görebilir.

Kendrick'in önerisi şaşırtıcı gelebilir: mümkünse onboarding yapmayın. Çünkü onboarding kullanıcıdan dikkat ve emek ister, insan hafızası da sınırlıdır. Bence o emeği önce arayüzü kolaylaştırmaya harcamak gerekir.

Audit'lerde en sık şunu görüyorum: ekip karışık bir ekranı düzeltmek yerine önüne bir tanıtım turu koyar. Tur biter, ekran aynı kalır. Kendrick'e göre talimat, kötü tasarımı yamamak için kullanılmamalıdır.

Ne zaman kullanılır

Kendrick'e göre çoğu mobil uygulamanın onboarding'e ihtiyacı yoktur, çünkü kullanıcı uygulamayı kullanarak öğrenir. Onboarding'in işe yarayabildiği durumları şöyle sayar:

• Uygulama başlamak için bilgi istiyorsa. Hesap açmak ya da bir bankacılık uygulamasında kimliği doğrulamak buna örnektir.
• Ürün kullanıcının durumuna dayanıyorsa. Bir diyet uygulaması işe başlamadan önce şu anki kilonuzu sorar.
• Ana özellik yeni ya da alışılmadıksa. Kendrick'in örneği telefonla çek yatırmadır. Bu özellik ilk sunulduğunda ATM'de para yatırmaya bir alternatifti.

Şu durumlarda onboarding eklemeden önce durun:

• Ekranı henüz kullanıcıyla denemediyseniz. Kendrick uygulamayı önce onboarding olmadan test etmenizi ister. Akışı ancak test gerçek bir sorun gösterirse eklersiniz. Testi nasıl kurduğumu kullanılabilirlik testi rehberinde anlattım.
• Anlatacağınız şey herkesin bildiği bir öğeyse. NN/g'den Page Laubheimer, ayarlar için kullanılan dişli ikonu gibi bariz şeyleri anlatmamanızı söyler.
• Asıl amaç yeni özellikleri pazarlamaksa. Kendrick ilk açılışta özellik tanıtımından kaçınmanızı önerir. Ona göre tanıtım ekranlarının yeri uygulama mağazası sayfasıdır. Uygulama içinde özelliği, işe yaradığı anda gösterin.

Onboarding türleri

Laubheimer yardımı ikiye ayırır. "Push" yardım, uygulama açılırken ya da rastgele bir anda, bağlamından kopuk gelir. "Pull" yardım ise uygulama kullanıcının ona ihtiyaç duyduğu anı yakaladığında çıkar. Aşağıdaki türler bu iki uç arasında durur.

Tanıtım turu

Uygulama ilk açıldığında art arda gelen kartlardır. NN/g bu biçime "deck-of-cards", yani deste tutorial der. Her kart bir özelliği anlatır, sonunda kullanıcı uygulamaya geçer.

Kendrick'in NN/g çalışmasında katılımcıların bir grubu bu turları okudu, öbür grup atladı. Turu okuyanlar görevlerde daha başarılı olmadı. Görevleri daha zor bile buldular.

Laubheimer bunu "aktif kullanıcı paradoksu" ile açıklar: kullanıcı hemen işe başlamak ister ve turu atlar. Bağlamından kopuk gösterilen bilgi de gerektiği anda hatırlanmaz.

Tur yine de bazen yerindedir. Laubheimer'in araştırmasında tanıtım akışları, artırılmış gerçeklik gibi yeni bir etkileşim biçimine alıştırmada işe yaradı. Bence alışılmadık bir etkileşimi önceden göstermek orada anlamlı.

Kullanırken öğretme

İpucu, kullanıcı bir özelliğe geldiği anda ve o özelliğin yanında çıkar. Laubheimer buna bağlamsal yardım der. Üzerine gelince açılan ipucu balonları ve coach mark denen işaretler bu gruptadır.

NN/g'den Aurora Harley coach mark için açık kurallar koyar. Her ipucu tek bir etkileşimi anlatmalı ve ipuçları tek tek, işe yaradıkları anda gelmelidir. Art arda açılan ipucu zincirinden kaçınmanızı da ister.

Harley bir uyarı daha yapar: kullanıcı ipucunu arayüzün tıklanabilir bir parçası sanabilir. Bu yüzden ipucunun görünüşü uygulamanın kendi öğelerinden ayrışmalıdır.

Boş durumla başlatma

Yeni bir hesapta liste, pano ya da favoriler boştur. NN/g'den Kate Kaplan bu alanın bomboş bırakılmamasını ister. Bomboş bir ekran, sistemin çalışıp çalışmadığı konusunda kafa karıştırır.

Kaplan'a göre iyi bir boş durum önce sistemin durumunu söyler. Sonra o alana neyin geleceğini öğretir ve alanı dolduracak işe doğrudan bir bağlantı verir.

Kaplan bu yaklaşımın, ilk açılışta zorla gösterilen turlardan genelde daha başarılı olduğunu yazar. Boş durum, yardımı kullanıcı o alana geldiğinde verir. Yani bir pull yardımdır.

Yap ve yapma

Aşağıdaki maddelerin çoğu NN/g'nin onboarding, coach mark ve boş durum yazılarından geliyor. Bazıları da audit'lerde tekrar tekrar gördüğüm hatalardan.

Canlı örnek: aynı uygulama, üç onboarding

Kumbara adında uydurma bir harcama uygulaması düşünün. Aşağıda aynı uygulama üç farklı onboarding'le açılıyor. Bir tür seçin, sonra İleri ve Atla ile akışı deneyin.

Üçünü de denedikten sonra kendinize şunu sorun: bütçe sınırını nereden koyacağınızı hangisinde hatırlıyorsunuz? Tanıtım turunda bu bilgi siz uygulamayı görmeden geldi. Boş durumda ise tam o kutunun içindeydi.

Demoda Atla'nın her türde başka bir şey yaptığına da dikkat edin. Turda atladığınız bilgi bir daha gelmez. İpucunda yardım bağlantısı kalır. Boş durumda ise atlanacak bir şey yoktur.

Mobil ve masaüstü farkı

Telefonda ekran küçüktür, kullanıcının dikkati de sık sık bölünür. Harley'ye göre mobil kullanıcının zamanı kısıtlıdır. Bu yüzden talimat okumaya web kullanıcısından da az isteklidir.

Bu yüzden telefonda kısa tutarım. İpucu tek cümle olur ve işaret ettiği öğeyi kapatmaz. Ekranın geri kalanı için mobil uygulama tasarımı rehberine bakabilirsiniz.

Masaüstünde ekran geniştir ve uygulamalar çoğu zaman daha karmaşıktır. Kaplan'ın boş durum yazısı da karmaşık uygulamalar üzerinedir. Pano, uyarı paneli ve favoriler ilk gün boştur ve her biri kendi boş durumuyla öğretebilir.

Laubheimer, masaüstü tasarım araçlarından iki örnek gösterir. Birinde ipucu yalnızca kullanıcının o anki işiyle ilgiliyse çıkar. Ötekinde ayrıntı ancak kullanıcı isterse açılır. Laubheimer buna aşamalı açıklama (progressive disclosure) der.

Masaüstünde fare olduğu için ipucunu üzerine gelince göstermek cazip gelir. Ben bunu tek yol yapmam. Dokunmatik ekranda da klavyede de üzerine gelme yoktur.

Erişilebilirlik notu

Onboarding çoğu zaman bir katman ya da pencere olarak açılır. Erişilebilirlik denetiminde bu katmanlarda en çok odak ve duyuru sorunları görürüm. Önce şu WCAG 2.2 ölçütlerine bakarım.

• 2.4.3 Odak sırası (A düzeyi). W3C'ye göre modal bir pencere açıkken odak pencerenin içindedir ve dışarıdaki içerik odak almaz. Pencere kapanınca odak onu açan öğeye ya da hemen sonrasındakine döner.
• 2.2.2 Duraklat, durdur, gizle (A düzeyi). Kendiliğinden başlayan, beş saniyeden uzun süren ve başka içerikle birlikte görünen hareketi kullanıcı durdurabilmelidir. Kendiliğinden kayan tur kartları bu koşulları taşıyorsa ölçüte takılır.
• 4.1.3 Durum mesajları (AA düzeyi). "Adım 2 / 3" ya da "İpuçları kapandı" gibi mesajlar, odak taşınmadan ekran okuyucuya iletilebilmelidir.

Demodaki adım bilgisi bu yüzden bir aria-live bölgesinde duyuruluyor. Atla'ya basınca odak kaybolmuyor, Baştan butonuna geçiyor. Tür seçen butonlar da aria-pressed ile seçili olduklarını söylüyor.

Ölçütlerin tamamı WCAG rehberinde. Bir akışı adım adım nasıl denetlediğimi erişilebilirlik denetimi rehberinde anlattım.

Uygulama notu

Aşağıda bir boş durumun ve alana bağlı bir ipucunun sade HTML hali var. Altında da turu bir kez açan, sonra ayarlardan geri getiren küçük bir betik.

<!-- Boş durum: gerçek bir başlık ve alanı dolduracak işe bağlantı. -->
<section class="bos-durum" aria-labelledby="bos-baslik">
  <h2 id="bos-baslik">Henüz harcama yok</h2>
  <p>İlk harcamanızı ekleyin, bu ayın toplamı burada görünsün.</p>
  <a class="btn btn--primary" href="/harcama/yeni">İlk harcamayı ekle</a>
</section>

<!-- İpucu: alanın yanında, alana bağlı. -->
<label for="kategori">Kategori</label>
<select id="kategori" aria-describedby="ipucu-kategori">...</select>
<p id="ipucu-kategori" class="ipucu">Kategoriyi sonra da değiştirebilirsiniz.</p>

<script>
  // Tur bir kez kendiliğinden açılır, ayarlardan her zaman yeniden açılır.
  if (!kullanici.turuGordu) turuAc();
  ayarlar.querySelector('#turu-goster').addEventListener('click', turuAc);
</script>

Boş durumun başlığı gerçek bir başlık etiketi, butonu da gerçek bir bağlantı. Ekran okuyucu kullanıcısı da sayfayı başlıklarla gezerken boş durumu bulur.

İpucu aria-describedby ile alana bağlı. Ekran okuyucu, kullanıcı alana geldiğinde ipucunu da okur. Görsel ipucunun ayrıca bir pencere olmasına gerek kalmaz.

"Turu yeniden göster" seçeneğini ayarlarda ya da yardım menüsünde, kolay bulunan bir yere koyarım. Laubheimer, denediği bir bisiklet uygulamasında turu bitirdikten sonra onu yeniden açmanın yolunu bulamadığını anlatır. Kapatılan yardımın geri gelebilmesi bu yüzden önemli.

Turun görülüp görülmediğini kullanıcının hesabında tutmayı tercih ederim. Tarayıcıda tutulan bilgi, aynı kişiye başka cihazda turu yeniden gösterir. Akışı tasarımdan koda kadar benim kurmamı isterseniz bu iş Tasarla ve Yayınla Sprinti kapsamına girer.

Kontrol listesi

Bir onboarding akışını yayına almadan önce bu listeden geçerim. Kendi uygulamanızın ilk açılışını benim kontrol etmemi isterseniz UX Audit bunları kapsar.

• Uygulamayı önce onboarding olmadan test ettim.
• Her adımın neden orada olduğunu bir cümleyle söyleyebiliyorum.
• İlk açılışta yalnızca başlamak için gereken bilgi isteniyor.
• Bilgi isteyen her adım nedenini söylüyor.
• Atla her adımda görünüyor ve çalışıyor.
• Kapatılan tur ya da ipucu yeniden açılabiliyor.
• İpuçları tek tek ve ilgili öğenin yanında çıkıyor.
• İpucu, arayüzün tıklanabilir bir parçasına benzemiyor.
• Her boş ekran ne olduğunu ve ilk adımı söylüyor.
• Hiçbir kart kendiliğinden kaymıyor.
• Pencere açılınca odak içeri giriyor, kapanınca geri dönüyor.
• Adım değişince ekran okuyucu bunu duyuyor.

Benim notum

Onboarding'e tasarım işinin sonunda bakarım, başında değil. Önce ekranları akışsız test ederim. Kullanıcı nerede takılıyorsa önce orayı düzeltirim.

Düzeltemediğim yer kalırsa orada bir ipucu ya da boş durum kurarım. Tam ekran akışı ise genelde yalnızca hesap açma gibi zorunlu adımlarda kullanırım.

Bir bankacılık uygulamasını düşünün. İlk açılışta kimlik doğrulama istemesi, Kendrick'in saydığı haklı durumlardan biridir. Ama aynı akışa kampanya kartları eklenince kullanıcı asıl işine geç kalır. Ben bu kartları ayırır, ilgili ekranın boş durumuna ya da bir ipucuna taşırım.

Ekran, kullanıcının kafasındaki zihinsel model ile örtüşüyorsa öğretmeye pek gerek kalmaz. Onboarding'i uzatmak zorunda kalıyorsanız, arayüz kendini anlatmıyor demektir. Bunu bir heuristik değerlendirme ile hızlıca görebilirsiniz.