SaaS UX tasarımı nasıl yapılır?

Kısaca

SaaS ürününde satış, kullanıcı ürünü kullanmaya başladıktan sonra da sürer. Kullanıcı her ay ya da her yıl yeniden öder, yani her dönem yeniden karar verir. Bu yüzden SaaS tasarımında en çok kayıttan yenilemeye uzanan akışa bakarım.

SaaS audit'lerinde altı yere odaklanırım: aktivasyon, onboarding, deneme süresi, plan ve faturalama ekranları, roller ve izinler, boş durumlar. Hepsinin ortak sorusu aynı: kullanıcı ürünün işine yaradığını ne zaman görüyor?

B2B ve B2C SaaS arasındaki fark büyüktür. Kurumsal bir üründe satın alan kişi ile her gün kullanan kişi çoğu zaman farklıdır. Bu farkı B2B ve B2C UX farkı yazımda ayrıca anlattım.

Aktivasyon ve ilk değere ulaşma süresi (time to value)

Aktivasyon, yeni bir kullanıcının ürünün vaat ettiği işi ilk kez yaptığı andır. Bir ön muhasebe uygulamasında bu an, ilk faturanın müşteriye gitmesidir. Bir proje aracında ise ilk görevin bir ekip arkadaşına atanması olabilir.

İlk değere ulaşma süresi (time to value), kayıttan bu ana kadar geçen süredir. Ben bunu iki birimle ölçerim: dakika ve adım sayısı. Dakika ürünün hızını, adım sayısı tasarımın yükünü gösterir.

1. KayıtHesap açılır.
2. KurulumGereken en az bilgi girilir.
3. İlk değerÜrün işini ilk kez yapar.
4. Tekrar kullanımKullanıcı ertesi gün döner.
5. ÖdemeDeneme biter, plan seçilir.

Şekil: Aktivasyon akışı. İlk değere ulaşma süresi, ilk kutudan üçüncü kutuya kadar geçen süredir.

Bu kavramların herkesin kabul ettiği tek bir tanımı yok. Değer anını her ürün kendisi seçer. Benim kuralım şu: değer anı, kullanıcının ekrana bakıp "bu işe yarıyor" diyebileceği bir olaydır.

Değer anını seçerken iki soru sorarım. Bu olay kullanıcının asıl işi mi, yoksa yalnızca bir hazırlık mı? Bu olayı yaşayan kullanıcılar ürüne geri dönüyor mu?

Hazırlık adımları değer değildir. Logo yüklemek ya da tercih anketi doldurmak ürünü kurar ama kullanıcıya bir şey kazandırmaz. Ben bu adımlara engel diyorum, çünkü kullanıcı ile ilk değer arasında dururlar.

Ölçmek için büyük bir analitik kurulumu gerekmez. Kendiniz yeni bir hesap açın, kronometreyi başlatın ve değer anına kadar her ekranı ve her beklemeyi not edin. İlk haftalarda bu liste size veri panelinden daha çok şey söyler.

SaaS onboarding: önce iş, sonra tur

SaaS onboarding'in tek işi, kullanıcıyı ilk değere götürmektir. Ürünü anlatmak, bu işe yardım ettiği ölçüde değerlidir.

NN/g'den Page Laubheimer, 2023 tarihli yazısında açılıştaki öğreticilerin gereğinden çok kullanıldığını anlatır. Bu öğreticiler kullanıcının işini böler ve bilgiyi bağlamından kopuk verir. Kullanıcı onları çoğu zaman atlar, izlese bile çabuk unutur.

Laubheimer bunu aktif kullanıcı paradoksuyla açıklar. Kullanıcı ürünü hemen kullanmak ister ve ileride işine yarayacak olsa bile önden öğrenmeye direnir. Önerdiği yol, yardımın ihtiyaç anında görünmesidir: ipucu, yönlendirme işareti ya da adım adım sihirbaz.

SaaS onboarding'de uyguladığım sıra şöyle:

1. Kayıtta yalnızca hesabı açmaya yeten bilgiyi isteyin. Vergi numarası ilk faturada gerekiyorsa, ilk faturada sorun.
2. Kullanıcıyı boş bir panele değil, değer anına giden ilk adıma bırakın.
3. Ürün turunu zorunlu yapmayın. Laubheimer da yardımın kolay kapatılmasını ve sonra kolay bulunmasını önerir.
4. Ekip daveti, entegrasyonlar ve tercihler ilk değerden sonra gelsin.

Ekran kalıplarını ve örneklerini onboarding kalıbı sayfasında ayrıca anlattım. Aşağıdaki simülatörde, adımları ilk değerden önce ya da sonra istemenin huniyi nasıl değiştirdiğini görebilirsiniz.

Aktivasyon hunisi

9adım6engelİlk değere kadar 9 adım var. Bunlardan 6 tanesi engel.

Huni

1. Yol Hesap aç: e-posta ve şifre
2. EngelSonra E-postanı doğrula
3. EngelSonra Sizi tanıyalım: 4 soruluk anket
4. EngelSonra Şirket ve vergi bilgileri
5. EngelSonra Kart bilgisi
6. EngelSonra Ürün turu: 6 ekran
7. EngelSonra Ekip arkadaşını davet et
8. Yol İlk müşteriyi ekle
9. Yol İlk faturayı gönder
10. İlk değer: fatura müşteriye ulaştı

Kurgusal bir ön muhasebe uygulaması. Adımlar ve sayılar gerçek bir üründen alınmadı, hiçbir dönüşüm oranını göstermiyor. Çubukların daralması yalnızca sırayı gösteren bir çizimdir. Bir kutunun işaretini kaldırınca o adım silinmez, ilk değerden sonraya taşınır.

Simülatörde hiçbir adım silinmiyor, yalnızca yeri değişiyor. Gerçek ürünlerde de bu adımların çoğu gereklidir. Sorun genelde sıradadır.

Karmaşık ürünlerde ayarlar için Jakob Nielsen'in kademeli gösterim (progressive disclosure) önerisini kullanırım. Nielsen, sık kullanılan seçeneklerin ilk ekranda durmasını, ileri seçeneklerin ise ancak istenince açılmasını önerir. 2006 tarihli yazısına göre iki seviyeden fazlasında kullanıcılar çoğu zaman kaybolur.

NN/g'den Kate Kaplan'ın 2020 tarihli karmaşık uygulama rehberi de aynı yönde. İleri seçenekler, yalnızca o anki işle ilgili olduklarında görünmelidir. Böylece ekran sadeleşir ama ürünün gücü azalmaz.

Deneme süresi tasarımı

Deneme süresi, kullanıcının ödemeden önce değer anına ulaşması için verilen zamandır. Kullanıcı bu sürede değer görmezse, deneme bitince ödemesi için bir nedeni kalmaz. Bu yüzden deneme süresinin uzunluğundan önce denemenin ilk gününe bakarım.

Deneme ekranlarında kontrol ettiğim şeyler:

• Kalan süre görünüyor mu? Panelde sakin bir yerde "Denemeniz cuma günü bitiyor" yazmalı. Her ekranda yanıp sönen bir uyarı gerekmez.
• İlk ödeme önceden söyleniyor mu? Kart bilgisi alınıyorsa, ilk ödemenin tarihi ve tutarı kart formunun hemen yanında yazmalı.
• Deneme bitince ne oluyor? Hesap kilitleniyor mu, veriler siliniyor mu, ücretsiz plana mı geçiliyor? Kullanıcı bunu bitişten önce bilmeli.
• İptal, kayıt kadar kolay mı? Kayıt iki tıkla olurken iptal için destek ekibine e-posta istemek, kullanıcıyı bir abonelik tuzağına sokar.

Son madde bir güven meselesidir. Bu tür tuzakları dark pattern rehberinde örnekleriyle anlattım.

Kart bilgisini denemenin başında istemek bir iş kararıdır, tasarımcı tek başına vermez. Tasarım tarafında benim tek şartım var. Kart formu, kullanıcıya ne zaman ve ne kadar ödeyeceğini açıkça söylemeli.

Plan ve faturalama ekranları

Plan ekranı, kullanıcının "hangisi bana uyuyor" sorusuna cevap aradığı yerdir. Burada en sık gördüğüm hata, her planın uzun bir özellik listesiyle verilmesidir. Kullanıcı farkı bulmak için satırları tek tek karşılaştırmak zorunda kalır.

NN/g'den Kate Moran ve Taylor Dykes, 2024 tarihli karşılaştırma tablosu yazısında şu önerileri verir:

• Tabloyu en fazla beş seçenek için kullanın. Daha fazla seçenek varsa filtre ekleyin.
• Bütün seçeneklerde aynı olan satırları gizleme imkânı verin, böylece yalnızca farklar kalsın.
• Uzun tablolarda sütun başlıklarını sabitleyin. Kullanıcı hangi sütunun hangi seçeneğe ait olduğunu aklında tutamaz.
• Mobilde aynı anda ikiden fazla seçenek göstermenin zor olduğunu hesaba katın.

Ben buna fiyatın yazılışını eklerim. Fiyatın aylık mı yıllık mı, KDV dahil mi hariç mi olduğu rakamın hemen yanında yazmalı. B2B alıcı faturayı muhasebeye götüreceği için bu bilgiyi ilk bakışta arar.

Faturalama ekranı

Faturalama ekranına az girilir ama girildiğinde genelde bir sorun vardır. Kart reddedilmiştir ya da muhasebe geçen ayın faturasını istemiştir. Bu yüzden ekran, aranan bilgiyi ilk bakışta vermelidir.

İyi bir faturalama ekranında şunlar hemen görünür:

• Şu anki plan ve kullanıcı sayısı.
• Bir sonraki ödemenin tarihi ve tutarı.
• Kayıtlı ödeme yöntemi ve onu değiştirme yolu.
• Geçmiş faturalar, indirilebilir halde.
• Planı yükseltme, düşürme ve iptal etme yolu.

Plan değişikliğinde kullanıcıya önce sonucu gösterin. Bugün ne kadar çekileceğini ve sonraki ödemenin ne olacağını söyleyen bir önizleme, sürpriz faturayı önler. Arkasından gelecek destek talebi de açılmaz.

Ödeme başarısız olduğunda mesaj nedeni ve çözümü söylemeli. "İşlem başarısız" yerine "Kartınızın son kullanma tarihi geçmiş. Yeni kart ekleyin." yazan mesaj, kullanıcıyı doğru butona götürür.

Ödeme reddedildiğinde hesabı hemen kilitlemeyin. Kullanıcıya kartını güncellemesi için birkaç gün tanıyın ve bu süreyi ekranda açıkça yazın. Ekip, cuma akşamı bir kart sorunu yüzünden bütün verisine erişimini kaybetmemeli.

Roller ve izinler

Ekiplerin kullandığı SaaS ürünlerinde herkes her şeyi görmez. Faturayı ve ayarları yönetici düzenler, ekip üyesi kendi işini yapar. Roller bu ayrımı kurar, ama kötü tasarlanınca kullanıcıyı açıklamasız bir duvarın önünde bırakır.

NN/g'den Amy Schade, 2016 tarihli kişiselleştirme yazısında bazı intranet ekiplerinden söz eder. Bu ekipler kullanıcıları o kadar çok gruba bölmüştür ki grupların bakımı imkânsız hale gelmiştir. Aynı yazı, ihtiyaçlar zamanla değiştiği için kişiselleştirilen bölümlerin düzenli gözden geçirilmesini önerir.

Ben aynı dersi rollere uygularım ve rol sayısını az tutarım. Çoğu ürün için başlangıçta sahip, yönetici ve üye rolleri yeter. Özel bir rol, ihtiyacı gerçekten doğduğunda eklenir.

Yetkisi olmayan kullanıcının ne göreceği de bir tasarım kararıdır. NN/g'den Maria Rosala, 2019 tarihli mobil izin yazısında benzer bir durumu ele alır. Kullanıcı reddettiği bir izne bağlı özelliği açınca, genel bir hata yerine nedeni anlatılmalı ve izni vermenin kolay bir yolu gösterilmelidir.

Rollerde de aynısını yaparım. "Erişim reddedildi" yerine "Faturaları yalnızca yöneticiler görebilir. Hesap yöneticinizden erişim isteyin." yazarım. Yanına da isteği tek tıkla gönderen bir buton koyarım.

Butonu gizlemek mi, pasif göstermek mi? Kullanıcı o işi hiçbir zaman yapmayacaksa gizlerim. Rolü değişince yapabilecekse pasif gösterir, nedenini yanına yazarım.

Boş durumlar

Yeni bir SaaS hesabında ekranların çoğu boştur. Müşteri listesi, raporlar ve bildirimler kullanıcının ilk verisini bekler. Audit'lerde gördüğüm kadarıyla, boş durum çoğu üründe en son tasarlanan ekrandır.

NN/g'den Kate Kaplan, 2021 tarihli yazısında boş durumlar için üç kural verir. Boş ekran sistemin o anki halini bildirmeli, ne yapılacağına dair bir ipucu vermeli ve ana işe doğrudan bir yol açmalıdır.

Kaplan, içerik yüklenirken "kayıt yok" yazmayı da yanıltıcı bulur. Bu mesaj kullanıcının uygulamaya güvenini zedeleyebilir.

Kaplan'ın örneklerinden biri SaaS için özellikle yararlı. Boş ekranda iki yol yan yana durur: kendi verisini eklemek ya da örnek veriyle başlamak. Böylece kullanıcı ürünü gerçek verisini bağlamadan güvenle dener.

Bir boş durum metni şöyle olabilir: "Henüz müşteri eklemediniz. İlk müşterinizi ekleyin ya da Excel listenizi içe aktarın." Bu iki cümle kullanıcıya nerede olduğunu ve ne yapacağını söyler. Altına iki buton yeter.

Müşteri ekleme formunun kendisi için form tasarımı kalıbına bakabilirsiniz.

SaaS tasarımında sık hatalar

Değer anını tanımlamadan onboarding tasarlamak. Varılacak yer belli değilse, akış ürünün bütün özelliklerini sırayla anlatan bir tura döner.

Kayıtta her şeyi istemek. Şirket büyüklüğü ve telefon numarası daha ilk ekranda sorulur. Kullanıcı ürünü görmeden form doldurmaktan yorulur.

Turu zorunlu yapmak. Kullanıcı turu bitirmeden ürünü kullanamıyorsa, tur bir engeldir.

Plan farkını saklamak. Planlar arasındaki farkı bulmak için kırk satır okumak gerekiyorsa, kullanıcı ya en ucuzu seçer ya da sayfadan çıkar.

İptali gizlemek. Gizli iptal kısa vadede birkaç aboneyi tutar, uzun vadede güveni kaybettirir.

Ürünü hep dolu hesapla görmek. Ekip ürünü verisi dolu bir demo hesabıyla görür, yeni kullanıcı ise boş bir hesapla başlar. Kullanılabilirlik testini ve audit'i boş bir hesapla da yapın.

Benim notum

SaaS audit'lerinde ilk işim, yeni bir hesap açıp değer anına kadar geçen adımları saymaktır. Toplam sayıdan çok, bu adımlardan kaçının engel olduğuna bakarım.

Ekipler engelleri genelde iyi niyetle koyar. Finans kart bilgisini, pazarlama anket cevabını ister. Her istek tek başına makuldür, ama hepsi bir araya gelince yeni kullanıcı ilk faturasını göndermeden yorulur.

Benim önerim çoğu zaman ertelemektir. Bilgiyi gerçekten gerektiği anda sorun: vergi numarasını ilk faturada, ekip davetini ilk iş bitince. Ürünün tamamını bu gözle gözden geçirmemi isterseniz, UX Audit Pro 10 akışa kadar bakar.