Çok Adımlı Kullanıcı Onboarding İçin Web Uygulaması Nasıl Kurulur

Çok Adımlı Bir Onboarding Akışının Yapması Gerekenler

Çok adımlı onboarding akışı, yeni bir kullanıcının “kayıt oldu” durumundan “ürünü kullanmaya hazır” duruma gelmesine yardımcı olan yönlendirilmiş ekran dizisidir. Her şeyi tek seferde sormak yerine, kurulumu tek oturumda veya zaman içinde tamamlanabilecek daha küçük adımlara bölersiniz.

Kurulum tek bir formdan daha fazlaysa—özellikle seçimler, önkoşullar veya uyumluluk kontrolleri içeriyorsa—çok adımlı onboarding gerekir. Ürününüz bağlam (sektör, rol, tercihler), doğrulama (e-posta/telefon/kimlik) veya ilk yapılandırma (workspace, faturalama, entegrasyonlar) gerektiriyorsa, adım bazlı akış her şeyi anlaşılır tutar ve hataları azaltır.

Zaten gördüğünüz yaygın onboarding akışları

Çok adımlı onboarding, doğal olarak aşamalı gerçekleşen görevleri desteklediği için her yerde karşınıza çıkar, örneğin:

• Hesap kurulumu: workspace oluşturma, ekip davet etme, plan seçimi
• Profil tamamlama: isim, rol, hedefler, tercihler
• Doğrulama: e-posta/telefon onayı, KYC/kimlik kontrolleri, 2FA kurulumu
• Eğitim ve ilk kullanım rehberi: ürün turu, örnek proje oluşturma, “ilk yapılacaklar” kontrol listesi

“Başarı” nasıl görünmeli

İyi bir onboarding akışı “tamamlanmış ekranlar” değildir; kullanıcıların hızlıca değere ulaşmasıdır. Başarıyı ürününüzle uyumlu ölçütlerle tanımlayın:

• Aktivasyon: uzun vadeli tutunmayı öngören ana aksiyonun tamamlanması (ör. ilk proje oluşturma, veri kaynağı bağlama)
• Tamamlama oranı: kullanıcıların gerekli adımları (ve ilgiliyse opsiyonel adımları) tamamlayan yüzdesi
• Değer süresi: yeni bir kullanıcının ilk anlamlı sonuca ulaşma süresi

Akış ayrıca devam ve süreklilik desteklemelidir: kullanıcılar ayrılıp dönebilirken ilerlemeyi kaybetmemeli ve bir sonraki mantıklı adıma yönlendirilmeli.

Tasarımda göz önünde bulundurulması gereken tipik riskler

Çok adımlı onboarding beklenen şekillerde başarısız olur:

• Terk etme (drop-offs): çok fazla adım, belirsiz faydalar veya hassas bilgileri çok erken isteme
• Kafa karıştıran adımlar: belirsiz etiketler (“Setup”), gizli gereksinimler veya tutarsız gezinme
• Veri kaybı: yenileme/geri butonu sorunları, oturum zaman aşımı, kısmi kaydetmelerin işlenmemesi

Amacınız onboarding’i bir sınav gibi değil, yönlendirilmiş bir yol gibi hissettirmektir: her adım için net amaç, güvenilir ilerleme takibi ve kullanıcıya bıraktığı yerden kolayca devam etme imkanı sunun.

Hedefleri, Kullanıcıları ve “Bitti” Kriterlerini Tanımlayın

Ekran çizmeye veya kod yazmaya başlamadan önce onboarding’in neyi başarmaya çalıştığını—ve kimin için—belirleyin. Çok adımlı bir akış ancak doğru kişileri doğru son duruma minimum kafa karışıklığıyla götürdüğünde “iyi” sayılır.

Ana kullanıcı tiplerinizi tanımlayın

Farklı kullanıcılar farklı bağlam, izin ve aciliyetle gelir. Birincil giriş personelarınızı ve onlar hakkında önceden bilinenleri adlandırarak başlayın:

• Yeni kullanıcı (self-serve kayıt): genellikle hesap oluşturma, e-posta doğrulama, temel profil ve ilk değer aksiyonlarını gerektirir.
• Davetli kullanıcı: genellikle bir organizasyona zaten aittir ve org oluşturmayı atlamalıdır; şartları kabul etme, şifre belirleme ve rol onayı gerekebilir.
• Yönetici tarafından oluşturulan hesap: ön doldurulmuş alanlar ve zorunlu güvenlik adımları (MFA, ilk girişte şifre sıfırlama) olabilir.

Her tip için kısıtlamaları (ör. “şirket adını düzenleyemez”), gerekli verileri (ör. “bir workspace seçmeli”) ve potansiyel kestirmeleri (ör. “SSO ile zaten doğrulanmış”) listeleyin.

“Bitti”nin nasıl görünmesi gerektiğini tanımlayın

Onboarding bitiş durumunuz açık ve ölçülebilir olmalıdır. “Bitti” tüm ekranların tamamlanması değil; iş olarak hazır bir durumdur, örneğin:

• Profil minimum tamamlanmaya ulaştı
• Organizasyon/workspace yapılandırıldı
• Faturalama ayarlandı (veya açıkça ertelendi)
• Kullanıcı ilk anlamlı eylemi gerçekleştirdi (ör. bir proje oluşturdu)

Tamamlama kriterlerini backend’in değerlendirebileceği bir kontrol listesi olarak yazın; belirsiz hedefler yerine kesin kurallar koyun.

Gerekli vs opsiyonel adımlar, bağımlılıklar ve atlama kuralları

Hangi adımların gerekli, hangilerinin opsiyonel olduğunu haritalayın. Ardından bağımlılıkları belgeleyin (“teammates davet edemezsiniz workspace yoksa”).

Son olarak atlama kurallarını kesinlikle tanımlayın: hangi kullanıcı tipi hangi koşullarda hangi adımı atlayabilir (ör. “SSO ile doğrulanmışsa e-posta doğrulamasını atla”) ve atlanan adımların daha sonra ayarlardan yeniden ziyaret edilip edilemeyeceğini belirtin.

Akış Haritasını Tasarlayın: Adımlar, Dallanma ve Giriş Noktaları

Ekranları veya API’leri oluşturmadan önce onboarding’i bir akış haritası olarak çizin: her adımı, kullanıcıların nerelere gidebileceğini ve daha sonra nasıl geri dönebileceklerini gösteren küçük bir diyagram.

1) Somut bir adım listesiyle başlayın

Adımları kısa, eylem odaklı isimlerle yazın (fiiller yardımcı olur): “Şifre oluştur”, “E-postayı onayla”, “Şirket bilgilerini ekle”, “Takım davet et”, “Faturalamayı bağla”, “Bitir”. İlk taslağı basit tutun, sonra gerekli alanlar ve bağımlılıklar (ör. faturalama plan seçilmeden yapılamaz) gibi detayları ekleyin.

Yardımcı bir kontrol: her adım bir soruyu yanıtlamalı—ya “Siz kimsiniz?” ya “Neye ihtiyacınız var?” ya “Ürün nasıl yapılandırılmalı?” Eğer bir adım üçünü de yapmaya çalışıyorsa, bölün.

2) Doğrusal mi yoksa koşullu dallanma mı olacağına karar verin

Çoğu ürün, deneyim gerçekten farklı olduğunda yalnızca koşullu dallanma içeren çoğunlukla doğrusal bir iskeletten fayda sağlar. Tipik dallanma kuralları:

• Rol: admin vs üye
• Plan: ücretsiz vs ücretli
• Bölge: KDV gereksinimleri, gizlilik onayları
• Kullanım amacı: kişisel vs kurumsal

Bunları akış haritasında “if/then” notları olarak belgeleyin (ör. “Eğer region = EU → VAT adımını göster”). Bu, akışı anlaşılır tutar ve labirent inşa etmekten kaçınır.

3) Giriş noktalarını tanımlayın (onboarding nasıl başlar)

Kullanıcının akışa hangi yerlerden girebileceğini listeleyin:

• Kayıttan sonraki ilk giriş
• Davet linki kabulü
• Ayarlardan “Kurulumu tamamla” hatırlatıcısı (/settings/onboarding)

Her giriş kullanıcısını doğru sonraki adımda karşılayın, her zaman adım birde değil.

4) Yeniden giriş (resume) planlayın

Kullanıcıların yarıda ayrılacağını varsayın. Döndüklerinde ne olacağını kararlaştırın:

• Son tamamlanmamış adıma devam et
• Kısmi alanları koru (taslak) vs çıkarken temizle
• Akış daha sonra değişirse “eski” adımları nasıl ele alacağınızı belirleyin

Haritanız güvenilir bir “devam et” yolunu göstermeli ki deneyim kırılgan değil güvenilir olsun.

Düşük Sürtünmeli Onboarding için UX Kalıpları

İyi onboarding bir rehber gibi hissettirmelidir, sınav gibi değil. Amaç karar yorgunluğunu azaltmak, beklentileri netleştirmek ve bir şeyler ters gittiğinde kullanıcının hızla toparlanmasını sağlamaktır.

İşi yapan kalıbı seçin

Bir wizard adımların sırayla tamamlanması gerektiğinde en iyi sonucu verir (ör. kimlik → fatura → izinler). Bir checklist adımların herhangi bir sırada yapılabildiği onboarding için uygundur (ör. “Logo ekle”, “Takım davet et”, “Takvim bağlantısı”). Yönlendirilmiş görevler (ürün içinde yerleştirilmiş ipuçları) ise öğrenmenin form doldurmaktan ziyade yaparak gerçekleştiği durumlarda iyidir.

Emin değilseniz, checklist + her göreve derin linklerle başlayın; sadece gerçekten gerekli adımları engelleyin.

Baskı hissettirmeden ilerlemeyi gösterin

İlerleme geribildirimi “Ne kadar kaldı?” sorusunu yanıtlamalı. Şunlardan birini kullanın:

• Adım sayısı (ör. Adım 2 / 5) doğrusal wizard’lar için
• Kilometre taşları (ör. Hesap → Takım → Entegrasyonlar) gruplanmış görevler için
• Yüzde yalnızca dürüst ve stabil ise (sıçramalardan kaçının)

Ayrıca daha uzun akışlar için “Kaydet ve sonra bitir” ipucu ekleyin.

Etiketler, mikro-metin ve dostça varsayılanlar

Basit etiketler kullanın (“İşletme adı”, “Kuruluş kimliği” demeyin). Neden sorduğunuzu açıklayan mikro-metin ekleyin (“Faturaları kişiselleştirmek için bunu kullanıyoruz”). Mümkünse mevcut verilerle ön-doldurun ve güvenli varsayılanlar seçin.

Hata durumları ve toparlanma

Hataları bir yol olarak tasarlayın: alanı vurgulayın, ne yapılacağını açıklayın, kullanıcı girdisini koruyun ve ilk hatalı alana odak verin. Sunucu hataları için yeniden deneme seçeneği gösterin ve ilerlemeyi koruyun ki kullanıcı tamamlanan adımları tekrar etmek zorunda kalmasın.

Mobil ve erişilebilirlik ilk günden düşünülmeli

Dokunma hedeflerini büyük tutun, çok sütunlu formlardan kaçının ve birincil eylemleri sabit görünür tutun. Tam klavye navigasyonu, görünür odak durumları, etiketlenmiş girdiler ve ekran okuyucular için erişilebilir ilerleme metni (yalnızca görsel çubuk değil) sağlayın.

Veri Modeli: Kullanıcılar, Adımlar, İlerleme ve Sürümler

Akıcı bir çok adımlı onboarding, üç soruya güvenilir şekilde cevap verebilen bir veri modeline dayanır: kullanıcı bir sonraki olarak ne görmeli, zaten ne sağladı, ve hangi akış tanımını takip ediyorlar.

Temel varlıklar (ne depolanmalı)

Küçük bir tablo/collection setiyle başlayın ve gerektiğinde büyütün:

• User: mevcut kullanıcı kaydı.
• OnboardingFlow: adlandırılmış bir akış (ör. “Default onboarding”, “Enterprise onboarding”).
• Step: tek bir adım tanımı (başlık, tür, sıra, gerekli alanlar, yardımcı metin). Adımlar belirli bir akış sürümüne ait olmalı.
• StepResponse: kullanıcının bir adım için kaydettiği veriler (cevaplar) ve doğrulama durumu.
• Completion (veya OnboardingProgress): bir kullanıcıyı bir akış sürümüne bağlayan ve genel durumu izleyen özet kayıt.

Bu ayrım “konfigürasyon”u (Flow/Step) “kullanıcı verisinden” (StepResponse/Progress) net şekilde ayırır.

Sürümler: yarıda olan kullanıcıları kırmayın

Akışları sürümlemeyi erken kararlaştırın. Çoğu ürün için cevap evettir.

Adımları düzenlediğinizde (yeniden adlandırma, yeniden sıralama, zorunlu alan ekleme), yarıda olan kullanıcıların aniden doğrulamaya takılmasını veya yerlerini kaybetmesini istemezsiniz. Basit yaklaşım:

• Flow id ve version (veya değişmez flow_version_id) tutar.
• İlerleme her zaman belirli bir flow_version_idye işaret eder.
• Yeni kullanıcılar en son sürümü alır; mevcut kullanıcılar kasıtlı olarak göç ettirilene kadar kendi sürümlerinde devam eder.

Kısmi ilerleme ve zaman damgaları

İlerlemeyi kaydederken otomatik kaydetme (yazarken kaydetme) veya Netice düğmesiyle kaydetme arasında seçim yapın. Birçok ekip her ikisini birleştirir: taslakları otomatik kaydeder, ancak bir adımı “tamamlandı” olarak işaretlemek yalnızca Next ile olur.

Raporlama ve sorun giderme için started_at, completed_at ve last_seen_at (ve adım başına saved_at) gibi zaman damgalarını izleyin.

İş Akışı Mantığı: Durum ve Geçişler

Çok adımlı onboarding en kolay şekilde kullanıcı oturumunu bir “durum” (geçerli adım + durum) olarak ele alındığında anlaşılır; yalnızca belirli geçişlere izin verilir.

Akışı izin verilen geçişlerle modelleyin

Frontend’in herhangi bir URL’ye atlamasına izin vermek yerine, adım başına küçük bir durum seti tanımlayın (ör. not_started → in_progress → completed) ve net geçişler belirleyin (ör. start_step, save_draft, submit_step, go_back, reset_step).

Bu size öngörülebilir davranış sağlar:

• Zorunlu adımlar, akış kuralları izin vermedikçe atlanamaz.
• “Onboardinge devam etme” sadece son bilinen durumu yüklemektir.
• Dallanma açıkça tanımlanır: bir geçiş saklı cevaplara göre farklı sonraki adıma götürebilir.

Adım tamamlama kuralları (doğrulama + sunucu kontrolleri)

Bir adım ancak iki koşul sağlandığında “tamamlandı” sayılmalıdır:

1. İstemci doğrulaması başarılı (zorunlu alanlar, format vb.).
2. Sunucu kontrolleri başarılı (iş kuralları ve dış doğrulamalar), ör. “bu e-posta zaten kullanılmıyor”, “vergi kimliği ülkeye uygun”, veya “şirket adı kabul edilebilir”.

Sunucunun kararını adım ile birlikte saklayın; böylece UI adımı bitmiş sanarken backend farklı düşünmez.

Erken cevaplar değiştiğinde geçersizleştirme işlemi

Kolay gözden kaçan bir uç durum: kullanıcı daha önceki bir adımı düzenler ve sonraki adımlar bozulur. Örnek: “Ülke” değişikliği “Vergi bilgilerini” veya “Mevcut planları” geçersiz kılabilir.

Bunu bağımlılıkları izleyip her gönderimden sonra aşağı doğru adımları yeniden değerlendirerek ele alın. Yaygın sonuçlar:

• Etkilenen adımları needs_review olarak işaretleyin (veya in_progress olarak geri alın).
• Artık geçerli olmayan alanları temizleyin.
• Yeni dal koşuluna göre sonraki adımı yeniden hesaplayın.

Geri navigasyon ve yeniden doğrulama

“Geri” desteklenmeli, ancak güvenli olmalı:

• Önceki adımlara veri kaybetmeden gidin.
• Kullanıcı daha sonra ileri adımlara döndüğünde, mevcut cevaplar ve geçerli sunucu kuralları ile doğrulamayı yeniden çalıştırın.

Bu, deneyimi esnek tutar ve oturum durumunun tutarlı kalmasını sağlar.

Sunucu API Tasarımı: Adım Tabanlı Onboarding için

Backend API, kullanıcının onboarding’de nerede olduğunu, ne girdiğini ve ne yapabileceğini doğrulayan “gerçek kaynak”tır. İyi bir API frontend’i basit tutar: mevcut adımı render eder, verileri güvenle gönderir ve yenileme/bağlantı sorunlarından sonra toparlanmayı sağlar.

Genelde ihtiyaç duyacağınız temel endpoint'ler

En azından bu işlemleri tasarlayın:

• Geçerli adımı ve ilerlemeyi al
  • GET /api/onboarding → geçerli adım anahtarı, tamamlanma %'si ve adımı render etmek için gereken kaydedilmiş taslak değerleri döner.
• Adım verisini kaydet (taslak veya son)
  • PUT /api/onboarding/steps/{stepKey} ile { "data": {…}, "mode": "draft" | "submit" }
• İleri / geri hareket (eğer kaydetmeden sonraki adımı çıkaramıyorsanız opsiyonel)
  • POST /api/onboarding/steps/{stepKey}/next
  • POST /api/onboarding/steps/{stepKey}/previous
• Onboardingi tamamla
  • POST /api/onboarding/complete (sunucu gerekli tüm adımların karşılandığını doğrular)

Yanıtları tutarlı tutun. Örneğin kaydettikten sonra güncellenmiş ilerlemeyi ve sunucunun karar verdiği sonraki adımı döndürün:

{ "currentStep": "profile", "nextStep": "team", "progress": 0.4 }

İdempotentlik: çift gönderimlerden ilerlemeyi koruyun

Kullanıcılar çift tıklayacak, kötü bağlantıda yeniden deneycek veya frontend zaman aşımından sonra isteği yeniden gönderebilir. “Kaydet” işlemini güvenli hale getirin:

• PUT/POST istekleri için Idempotency-Key başlığı kabul edin ve (userId, endpoint, key) ile dedupe edin.
• PUT /steps/{stepKey}'i o adımın depolanmış yükünün tam üzerine yazması şeklinde ele alın (veya kısmi birleştirme kurallarını netleştirin).
• İsteğe bağlı olarak eskiden daha yeni verinin üzerine yazmayı engelleyen version (veya etag) ekleyin.

Açık hatalar ve alan-düzey doğrulama

UI'nin alanların yanına yerleştirebileceği eyleme geçirilebilir mesajlar döndürün:

{
  "error": "VALIDATION_ERROR",
  "message": "Lütfen işaretli alanları düzeltin.",
  "fields": {
    "companyName": "Şirket adı zorunlu",
    "teamSize": "Sayı olmalı"
  }
}

Ayrıca frontend’in doğru tepki verebilmesi için 403 (izin yok) ile 409 (çakışma / yanlış adım) ve 422 (doğrulama) ayrımını yapın.

Kimlik doğrulama ve yetkilendirme

Kullanıcı ve yönetici kapasitelerini ayırın:

• Kullanıcı endpoint'leri oturum gerektirir ve yalnızca çağıranın onboarding durumuna erişmelidir.
• Yönetici endpoint'leri (ör. GET /api/admin/onboarding/users/{userId} veya müdahaleler) rol-kontrolüne tabi olmalı ve denetlenmelidir.

Bu sınır, yetki sızıntılarını önlerken destek ve operasyonun takılan kullanıcılara yardım etmesine izin verir.

Frontend Uygulaması: Yönlendirme, Devam ve Güvenilirlik

Frontend’in görevi, ağ sorunlarında bile onboarding’in akıcı hissettirmesini sağlamaktır. Bu, öngörülebilir yönlendirme, güvenilir “devam” davranışı ve verilerin kaydediliyor olduğuna dair net geribildirim demektir.

Yönlendirme: adım başına bir URL vs tek sayfa

Her adım için bir URL (örn. /onboarding/profile, /onboarding/billing) genellikle en basit yaklaşımdır. Tarayıcı geri/ileri desteği, e-posta derin linkleri ve yenileme sonrası bağlam kaybetmeme gibi avantajlar sağlar.

Çok kısa akışlar için tek sayfa dahili durum kullanılabilir, ancak yenileme, çökme ve “bağlantıyı kopyala devam et” senaryolarında riskleri artırır. Bu yaklaşımı seçerseniz güçlü kalıcılık ve dikkatli geçmiş yönetimi gerekir.

İlerleme kalıcılığı: sunucu gerçek kaynak olmalı

Adım tamamlama ve en son kaydedilmiş verileri sunucuda saklayın, sadece localstorage’da değil. Sayfa yüklendiğinde mevcut onboarding durumunu (geçerli adım, tamamlanan adımlar ve taslak değerleri) çekip buradan render edin.

Bu şunları sağlar:

• Yenileme güvenliği
• Cihazlar arası devam
• Yöneticiler akışı değiştirdiğinde tutarlılık

Optimizmli UI (Optimistic UI) kullanıcıları kafa karıştırmadan

Optimizmli UI sürtünmeyi azaltabilir, ama sınırları olmalı:

• Birincil buton yakınında belirgin Kaydediliyor… / Kaydedildi / Hata durumu gösterin.
• Bir istek sürerken gönderme butonunu devre dışı bırakın.
• Otomatik kaydetme varsa değişiklikleri debounce edin ve hataları gösterin (“Kaydedilemedi. Tekrar dene”).

Nazikçe devam etme teklif edin

Kullanıcı döndüğünde onları direk adım birine atmayın. Şöyle bir öneri sunun: “%%60 tamamladınız—bıraktığınız yerden devam etmek ister misiniz?” iki eylemle:

• Devam et (son gerekli adıma götürür)
• Daha sonra bitir (uygulamaya götürür; /onboarding bağlantısını persistent bir banner ile gösterir)

Bu küçük dokunuş bırakmayı azaltır ve aynı zamanda kullanıcıların her şeyi hemen bitirmek zorunda olmadığını kabul eder.

Doğrulama Stratejisi ve Kısmi Veri İşleme

Doğrulama, onboarding’in ya pürüzsüz ya da sinir bozucu hissettirdiği yerdir. Amaç hataları erken yakalamak, kullanıcıyı hareket halinde tutmak ve eksik/veri şüpheli olduğunda sistemi korumaktır.

Tarayıcıda doğrulama (hızlı geribildirim)

Ağ isteği göndermeden önce istemci tarafı doğrulamasıyla bariz hataları önleyin. Bu churn’i azaltır ve her adımı daha yanıtlı gösterir.

Tipik kontroller: zorunlu alanlar, uzunluk limitleri, temel format (email/telefon) ve alanlar arası basit kurallar (şifre onayı). Mesajlar spesifik olsun (“Geçerli bir iş e-postası girin”) ve hemen alan yanında gösterilsin.

Sunucu tarafı doğrulama (doğruluk ve güvenlik)

Sunucu doğrulaması kaynak otoritedir. UI mükemmel doğrulasa bile kullanıcılar bunu atlayabilir.

Sunucu doğrulaması şunları zorunlu kılmalıdır:

• Yetkilendirme (kullanıcı yalnızca kendi onboardingiyle etkileşimde bulunabilir)
• İzin verilen değerler (enum, ülke kodu, belge türleri)
• Veri bütünlüğü (benzersiz kısıtlar, foreign key’ler)
• Güvenlik kontrolleri (rate limit, girdi temizleme)

Alan-düzey yapılandırılmış hatalar döndürün ki frontend tam olarak hangi alanın düzeltilmesi gerektiğini vurgulasın.

Asenkron kontrolleri destekleyin

Bazı doğrulamalar dışsal veya gecikmeli sinyallere bağlıdır: e-posta benzersizliği, davet kodları, dolandırıcılık sinyalleri veya belge doğrulama. Bunları pending, verified, rejected gibi durumlarla yönetin ve UI’da açıkça gösterin. Bir kontrol bekliyorsa, kullanıcıyı mümkünse devam ettirin ve hangi adımın kilitli kalacağı veya ne zaman bildirim gelecek açıklayın.

Kısmi hataları nasıl ele alacağınızı kararlaştırın

Çok adımlı onboarding’da kısmi veri normaldir. Adım başına karar verin:

• Taslağı kaydet: kısmi girdileri depolayın ve kullanıcı başka yere gidebilsin; adımı “in progress” olarak işaretleyin.
• İlerlemenin engellenmesi: bir sonraki adıma geçmeden önce minimum alan setini zorunlu kılın.

Pratik yaklaşım: “her zaman taslağı kaydet, yalnızca adım tamamlanırken engelle”—bu, oturum devamını desteklerken veri kalitesini de korur.

Analitik: Tamamlama Ölçümü ve Terk Noktalarını Bulma

Çok adımlı onboarding için analitik iki soruyu yanıtlamalı: “Nerede takılıyorlar?” ve “Hangi değişiklik tamamlama oranını artırır?” Küçük, tutarlı event setleri izleyin ki akış değiştiğinde bile karşılaştırma yapabilesiniz.

Güvenilir event izleme

Her adım için aynı temel eventleri izleyin:

• step_viewed (kullanıcı adımı gördü)
• step_completed (kullanıcı gönderdi ve doğrulamayı geçti)
• step_failed (kullanıcı gönderdi ama doğrulama veya sunucu kontrolleri başarısız oldu)
• flow_completed (kullanıcı final başarı durumuna ulaştı)

Her event’e minimal, stabil bir bağlam ekleyin: user_id, flow_id, flow_version, step_id, step_index ve session_id (tek oturum mu yoksa birden fazla güne yayılmış mı ayırt etmek için). Eğer resume destekleniyorsa step_viewed içinde resume=true/false ekleyin.

Terk ve adım başına süre

Adım başına terk oranını ölçmek için aynı flow_version için step_viewed ile step_completed sayısını karşılaştırın. Zaman ölçmek için zaman damgalarını alın ve hesaplayın:

• step_viewed → step_completed arasındaki süre
• step_viewed → bir sonraki step_viewed arasındaki süre (kullanıcı atlama yaparsa işe yarar)

Zaman metriklerini sürüme göre gruplayın; aksi halde eski ve yeni akışları karıştırmak iyileştirmeleri görünmez kılabilir.

Deney alanları (A/B) ve metrikleri bozmadan test etme

Kopya veya adım sırasını A/B test ediyorsanız, bunu analitik kimliğinin bir parçası olarak ele alın:

• Her event’e experiment_id ve variant_id ekleyin
• Görünen metin değişse bile step_id sabit kalsın
• Yeniden sıralarken step_id aynı kalmalı, pozisyon için step_index kullanın

Paydaşlar için panolar ve dışa aktarımlar

Tamamlama oranı, adım bazlı terk, adım başına medyan süre ve “en çok başarısız olan alanlar”ı gösteren basit bir pano oluşturun. CSV dışa aktarımları ekleyin ki ekipler doğrudan analiz yapıp rapor paylaşabilsin.

Yönetici Araçları: Akış Oluşturucu, Dağıtımlar ve Müdahaleler

Çok adımlı onboarding sistemi zamanla operasyonel kontrol gerektirir: ürün değişiklikleri, destek istisnaları ve güvenli deneylere ihtiyaç olur. Küçük bir iç yönetici alanı mühendisliği darboğaz olmaktan kurtarır.

Akış oluşturucu: yeniden dağıtıma gerek kalmadan adım oluşturun ve düzenleyin

Yetkili personele onboarding akışları ve adımlarını oluşturup düzenlemeyi sağlayan basit bir “akış oluşturucu” verin.

Her adım düzenlenebilir olmalı:

• Başlık ve kısa yardımcı metin
• Adım türü (form, checklist, belge yükleme, zamanlama vb.)
• Zorunlu alanlar ve doğrulama kuralları
• İsteğe bağlı dallanma kuralları (ör. “Kullanıcı Şirket seçerse VAT adımını göster”)

Bir önizleme modu ekleyin; adımı son kullanıcı nasıl göreceğini kontrol etmek kafa karıştırıcı metin, eksik alan veya kırık dallanmayı yakalar.

Sürümleme ve güvenli yayınlama

Canlı bir akışı yerinde düzenlemekten kaçının. Bunun yerine sürümler yayınlayın:

• Taslak: düzenlenebilir, önizlenebilir
• Yayınlanmış: kullanıcıların kullandığı değiştirilemez tanım
• Arşiv: destek ve denetimler için saklanan sürümler

Sürümleri şu şekilde dağıtın:

• Yalnızca yeni kullanıcılara: mevcut kullanıcılar kendi sürümlerinde kalır
• Kademeli yüzde ile: önce %5-10, metrikler iyi görünce artırın
• Hedefleme (opsiyonel): plan, bölge, ortak veya davet kampanyasına göre

Bu riskleri azaltır ve karşılaştırma yapmayı kolaylaştırır.

Destek ve operasyon için müdahaleler (overrides)

Destek ekiplerinin veritabanında manuel düzenleme yapmadan kullanıcıları açığa çıkarması gerekebilir:

• Bir adımı tamamlı olarak işaretleme (sebebiyle birlikte)
• Kullanıcının akışını başa veya belirli bir adıma sıfırlama
• Hatanın ardından kullanıcıyı bir adım geri taşıma
• Davet/sihirli link/doğrulama e-postasını yeniden gönderme

Denetim kayıtları ve izinler

Her yönetici işlemi loglanmalı: kim neyi, ne zaman ve önce/sonra değerleriyle. Erişimi rollerle sınırlandırın (sadece görüntüleme, editör, yayıncı, destek override) ki hassas işlemler kontrollü ve izlenebilir olsun.

Yayından Önce Test, Güvenlik ve İzleme

Birçok durumda şu iki şey gerçekleşecektir: kullanıcılar beklenmedik yollar takip edecek ve bir yerde aksaklık (ağ, doğrulama, izin) olacak. İyi bir lansman kontrol listesi akışın doğru olduğunu kanıtlar, kullanıcı verilerini korur ve gerçeğin planla ayrıştığı noktaları erken haber verir.

UI değil, akış haritasını test edin

Önce iş akışı mantığı (durumlar ve geçişler) için birim testleri yazın. Bu testler her adımın:

• Yalnızca izin verilen önceki adımlardan girilebildiğini
• Belirli cevaba/role/plan’a göre beklenen sonraki adımı ürettiğini
• Kenar durumları (atlar, geri navigasyon, süresi dolmuş oturumlar) doğru ele aldığını doğrulamalı

Ardından API’yi egzersiz eden entegrasyon testleri ekleyin: adım yüklerini kaydetme, ilerlemeyi sürdürme ve geçersiz geçişleri reddetme.

Kritik yollar için uçtan uca testler

E2E testleri en az şunları kapsamalı:

• Başarılı yol (start → completion)
• Yaygın başarısızlıklar: doğrulama hatası, sunucu 500, zaman aşımı/yeniden deneme ve tarayıcı kapandıktan sonra devam

E2E senaryolarını küçük ama anlamlı tutun—çoğu kullanıcıyı ve gelire/aktivasyona en çok etki eden yolları hedefleyin.

Hassas veriyi varsayılan olarak koruyun

En az ayrıcalık ilkesini uygulayın: onboarding yöneticileri otomatik olarak tüm kullanıcı kayıtlarına erişmemeli; servis hesapları yalnızca ihtiyaç duydukları tablolar/endpoint'lerle etkileşim kurmalı.

Gerekli alanları şifreleyin (tokenlar, hassas tanımlayıcılar, düzenlemeye tabi alanlar) ve logları veri sızıntısı riski olarak değerlendirin. Ham form payloadlarını loglamaktan kaçının; adım ID’leri, hata kodları ve zamanlamaları loglayın. Hata ayıklama için payload parçaları loglanacaksa alanları tutarlı şekilde maskeleyin.

Sorunları erken yakalayan izleme

Onboarding’i hem ürün hunisi hem de API olarak instrument edin.

Adım bazlı hataları, kaydetme gecikmesini (p95/p99) ve devam hatalarını takip edin. Bir sürüm sonrası tamamlanma oranında ani düşüşler, tek bir adımda doğrulama hatası artışı veya artan API hata oranları için uyarılar kurun. Bu, destek biletleri birikmeden önce bozuk adımı düzeltmenizi sağlar.

Koder.ai Nerede Yer Alır (Hızlı İnşa Etmek İsterseniz)

Adım tabanlı bir onboarding sistemini sıfırdan kuruyorsanız, zamanınızın çoğu aşağıdaki yapı taşlarına gider: adım yönlendirmesi, kalıcılık, doğrulamalar, ilerleme/durum mantığı ve sürümleme/dağıtım için bir yönetici arayüzü. Koder.ai bu parçaları sohbet tabanlı bir spesifikasyondan tam yığın web uygulamaları üreterek prototipleme ve teslim süresini hızlandırabilir—genellikle React frontend, Go backend ve flow/step/step_response modellerine temizce eşlenen PostgreSQL veri modeli ile.

Koder.ai kaynak kodu dışa aktarma, barındırma/dağıtım ve geri alma anlık görüntüleri (snapshots) desteklediği için onboarding sürümlerini güvenle yinelemenize (ve eğer bir dağıtım tamamlama oranını düşürürse hızla geri almanıza) yardımcı olur.