Terk oranını azaltan "kaydet ve devam et" çok adımlı sihirbaz desenleri

Neden çok adımlı sihirbazlar kaydet-ve-devam-et'e ihtiyaç duyar

Çok adımlı bir sihirbaz uzun bir formu daha küçük adımlara böler: profil bilgileri, faturalama, tercihleri ve inceleme gibi. Görev uzun, veri karmaşıksa veya kişiler net bir sıra izlemek zorundaysa bu faydalıdır. İyi yapılırsa tek sayfaya göre daha hafif hissedilir.

Yine de insanlar yarıda bırakır çünkü hayat araya girer. Gerekli bir belge yanlarında olmayabilir, yöneticiden onay bekleyebilirler, bağlantı kopabilir veya telefondan bilgisayara geçebilirler. Bazıları da sihirbazın riskli olduğunu düşünür: bir hata veya sayfa yenilemesi her şeyi silebilir.

Kaydet-ve-devam-et durumu değiştirir. Kullanıcılar korkmadan ara verebilir, daha sonra geri dönebilir ve doğru adımdan kaldıkları yerden devam edebilirler. Takımlar da fayda görür: daha az terkedilmiş gönderim, daha net destek konuşmaları ("taslağını açıp devam et"), ve kullanıcıların nerede takıldığını görme imkanı.

İlerlemenin (cihazlar arası bile) kaybolmayacağına dair sözü tutmak için çoğu sihirbazın birkaç temel şeye ihtiyacı vardır:

• Kullanıcı yazarken taslakları otomatik kaydetmek ya da en azından bir sonraki adıma geçince kaydetmek.
• Sonraki adımlardaki alanlara takılmadan kısmi tamamlamaya izin vermek.
• Taslağı tekrar bulmayı kolaylaştırmak (hesap alanı, e‑posta hatırlatıcısı veya devam tokeni).
• Ne eksik olduğunu utanmadan, açıkça göstermek.

Taslaklar ve durumlar sade dille

Kaydet-ve-devam-et sihirbazını tasarlamak, onu iki farklı şey olarak ele almakla kolaylaşır: taslak ve gönderilmiş kayıt.

Taslak geçici ve değiştirilebilir. Gönderilmiş kayıt resmi olur ve daha sıkı kurallara uymalıdır.

"Durum" o kaydın şu anda ne olduğunu gösteren etikettir. Yaygın durumlar: draft, submitted, approved, rejected ve archived. Sadece iki duruma ihtiyacınız varsa draft ve submitted ile başlayın. Bu ayrımı net tutmak raporlama, izinler ve destek işlerini basitleştirir.

Her adımda neyi saklayacağınız, daha sonra gerçekten neye ihtiyacınız olduğuna bağlıdır. Sadece o adım için kullanıcı girdilerini ve kim olduğunu, en son ne zaman güncellendiği gibi temel meta verileri saklayın. "Belki gerekebilir" diye hassas ekstra verileri saklamaktan kaçının (örneğin tam kart verisi, henüz istemediğiniz belgeler veya daha sonra kullanıcıya karışık gelebilecek dahili notlar).

İlerlemenin takibi sıkıcı ve açık olmalı. Çoğu durum iki alanla çözülür:

• current_step (kullanıcının kaldığında nerede açılacağı)
• completed_steps (zaten hangi adımların tamamlandığı)

Bazı ekipler completed_stepsi adım kimliklerinin listesi olarak saklar. Diğerleri basit bir sayıyı tercih eder.

Pratik bir zihinsel model:

• Taslak verisi: şimdiye kadar verilen cevaplar (tamamlanmamış olabilir)
• Durum: draft vs submitted
• İlerleme: current step ve tamamlanan adımlar
• Sahiplik: kullanıcı veya hesap ID'si
• Zaman damgaları: created_at, updated_at, submitted_at

Taslağı ne zaman oluşturmalısınız?

Akış anonimse veya devam edilebilir link istiyorsanız, sihirbaz açılır açılmaz oluşturun ki üzerine kaydetmek için bir ID'niz olsun. Kullanıcı oturum açmışsa ve daha az boş taslak istiyorsanız, ilk gerçek “İleri” veya “Kaydet” eyleminde oluşturun.

Taslaklar için işe yarayan backend veri modelleri

İyi bir taslak modeli iki işi iyi yapar: kısmi girdiyi bozulmadan kaydetmek ve son gönderimi öngörülebilir kılmak. Veri modeli dağınıksa, UI ne kadar iyi olursa olsun sihirbaz güvensiz hissedecektir.

Seçenek A: tek kayıt üzerinde evrilme (status ve current_step ile)

Bu en basit yaklaşımdır. Her şeyi tek bir tabloda (veya ana varlıkta) saklar, status (draft/submitted) ve current_step (1–6) gibi alanlar eklersiniz. Her kaydetme aynı kaydı günceller.

Form bir "şey"e (bir başvuru, bir sipariş, bir profil) temizce eşlendiğinde en iyi çalışır.

Seçenek B: Taslak ve Final kayıtları ayrı

Burada dağınık, kısmi veri için bir Draft tablosu ve temiz, doğrulanmış veri için bir Final tablosu tutarsınız. Gönderim sırasında Draft'tan Final oluşturur, sonra Draft'ı kilitler veya arşivlersiniz.

Bu desen, nihai verinin katı olması gerektiği (faturalama, uyum, raporlama) ama taslağın esnek olabileceği durumlarda öne çıkar. Ayrıca "taslağı sil" işlemini daha güvenli yapar çünkü gönderilmiş kayıtlara dokunmaz.

Seçenek C: anlık görüntüler veya event'ler (denetlenebilir)

Kim neyi ne zaman değiştirdiğini bilmeniz gerekiyorsa geçmişi saklayın. İki yaygın yol:

• Anlık görüntüler (snapshots): her kaydetmede taslak verinin tam kopyasını saklayın (geri yüklemesi basit).
• Event'ler: küçük "değişiklik" kayıtları saklayın (daha kompakt, ama okunması zor).

Onaylar, anlaşmazlıklar veya düzenlemeye tabi veriler varsa bunu kullanın.

Tekrarlanabilir bölümler (satır öğeleri veya ekler gibi) genelde taslaklarda sorun çıkarır. Bunları taslağa bağlı alt tablolar olarak modelleyin (ve daha sonra final kayda bağlayın). Örneğin onboarding sihirbazında birçok "takım üyesi" veya "belge" olabilir. Her öğeyi bağımsız saklayın. Sorgulama, sıralama veya öğe başına doğrulama ihtiyacınız yoksa dizi olarak tek alana sıkıştırmaktan kaçının.

Kullanıcıyı bunaltmayan kısmi doğrulama

Kısmi doğrulama, sihirbazın yardımcı hissetmesi ile engel hissettirmesi arasındaki farktır. İnsanların yeterince yaptıklarında ilerlemelerine izin verin, ama açıkça bozuk girişin taslağa karışmasına da izin vermeyin.

Çoğu sihirbazın ihtiyacı olanlar:

• Adım düzeyinde doğrulama: mevcut adımın ihtiyaçlarını denetler.
• Son doğrulama: gönderimde tüm adımları kontrol eder.

Eksik ile hatalıyı ayırın. Taslakta eksik alanlar kabul edilebilir. Hatalı girişler engellenmeli veya açıkça işaretlenmelidir, çünkü sonradan kafa karışıklığı yaratır.

Örnek: boş telefon numarası taslakta kabul edilebilir. İçinde harf olan bir telefon numarası ise reddedilmeli veya açıkça işaretlenmelidir.

Hemen neyi doğrulayalım, neyi sonra:

• Hemen doğrulayın: biçim ve temel ayrıştırma (e‑posta şekli, tarih biçimi, sayı aralıkları, bu adımda gerekli alanlar).
• Sonra doğrulayın: diğer adımlara bağlı iş kuralları (kredi limiti şirket büyüklüğüne bağlıdır, gönderim seçenekleri adresle bağlıdır, benzersiz kullanıcı adı kontrolleri).
• Asenkron doğrulama: dış sistem çağrısı gerektiren kontroller (vergi kimlik doğrulama, ödeme yöntemi yetkilendirme).

Hatalar spesifik ve yerel olmalı. "Devam etmek için hataları düzeltin" demek yerine alanı işaret edin, neyin yanlış olduğunu açıklayın ve nasıl düzelteceklerini söyleyin. Bir adım uyarılar içeriyorsa (hata değilse), kullanıcıya devam izni verin ama belirgin bir "dikkat gerektirir" rozeti gösterin.

Pratik bir desen: sunucudan şu yapıda yapılandırılmış bir yanıt döndürün:

• Engelleyici hatalar (ilerlemek için düzeltilmeli)
• Uyarılar (ilerlenebilir ama vurgulanmalı)
• Alan yolları (UI doğru alana odaklansın diye)
• Kısa bir özet mesajı (adımın üstünde gösterilecek)

Adım adım: kaydet-ve-devam-et akışı nasıl uygulanır

İyi bir kaydet-ve-devam-et sihirbazı ilk ekrandan itibaren çalışır. 3. adıma kadar kayıt oluşturmayı beklemeyin. Kullanıcı anlamlı bir şey girdiği anda, güncelleyebileceğiniz bir taslağınız olmasını istersiniz.

Kopyalayabileceğiniz pratik akış

1. Sihirbaz açıldığında veya ilk gerçek eylemde bir taslak oluşturun. Minimumu saklayın: sahibi (kullanıcı ID'si veya e‑posta), status = draft ve adım 1 alanları (tamamlanmamış olsa bile).
2. Her adım sonrası kaydedin ve uzun adımlar için otomatik kaydet ekleyin. "İleri"de adım payload'ını kalıcı hale getirin. Uzun sayfalar için blur veya kısa bir duraklamada otomatik kaydet yapın ki yenileme ilerlemeyi silmesin.
3. Devam edildiğinde mevcut taslağı yükleyin. Taslağı ID (ve sahip) ile çekin ve UI'yi doldurun ki kullanıcı kaldığı yerden devam etsin.
4. Geri, ileri ve atlamayı güvenli yönetin. Son tamamlanan adımı ve izin verilen yolları saklayın. Eğer adım 4 adım 2'ye bağlıysa, gerekli girdiler olmadan adımı atlatmaya izin vermeyin.
5. Tek bir gönderim eylemiyle tamamlayın. Tüm adımlar çapraz doğrulamasından geçirin, kaydı kilitleyin ve sonra status = submitted ayarlayın.

Kullanıcıyı cezalandırmayan doğrulama

Taslak sırasında sadece mevcut adım için gerekli olanları doğrulayın. Kısmi veriyi "eksik" veya "gözden geçirilmeli" gibi bayraklarla kaydedin; her şeyi sert hata saymayın.

Devam edilebilir bağlantılar: nasıl çalışır ve ne zaman kullanılmalı

Devam edilebilir link, tek kullanımlık (veya kısa ömürlü) bir token taşıyan bir URL'dir. Birisi açtığında uygulama tokenin işaret ettiği taslağı bulur, hâlâ geçerli olduğunu doğrular ve kullanıcıyı doğru adıma gönderir. Bu, özellikle kişiler cihaz değiştirirken deneyimi zahmetsiz kılabilir.

Tipik akış: taslak oluştur -› taslağa bağlı token oluştur -› tokenin hash'lenmiş kopyasını sakla -› linki göster veya gönder -› tokeni kullanarak devam et -› tokeni döndür veya geçersiz kıl.

Token kuralları (güvenilir olması için)

Birkaç kuralı baştan kararlaştırın ki destek daha sonra tahmin yürütmesin:

• Ömür: akışın ne kadar sürdüğüne göre saatler veya günler.
• Döndürme: her başarılı devam sonrası yeni bir token vermek (iyi bir varsayılan) veya bir tokeni submit'e kadar tutmak.
• Adım hedefleme: linkin doğru ekranda açması için son tamamlanan adımı saklayın.
• Teslimat: kullanıcıların telefondan masaüstüne geçebilmesi için hem "linki kopyala" hem de "e‑posta ile gönder" destekleyin.

Pratik örnek: bir kişi telefonunda başlar, "Bana bir devam linki gönder" der ve sonra evde dizüstüne devam eder. Her devamlama sonrası tokeni döndürürseniz, eski link tek kullanımlık olur ve kazara paylaşım riski azalır.

Taslaklar ne zaman gönderilmiş veya süresi dolmuş sayılır

Açık olun.

• Eğer taslak zaten gönderilmişse, salt okunur bir onay ekranı açın ve yeni bir taslak başlatma seçeneği sunun.
• Eğer taslağın süresi dolmuşsa, ne olduğunu tek cümlede söyleyin ve "Yeniden başla" gibi net bir eylem verin.

Yeni bir taslakı sessizce oluşturmaktan kaçının. Kullanıcılar orijinal verinin hâlâ orada olduğunu varsayabilir.

Taslaklar ve devam tokenleri için güvenlik ve gizlilik

Kaydet-ve-devam-et ancak kullanıcılar ona güvenirse işe yarar.

Kişisel veya iş verilerini asla URL'de taşımayın. Link sadece kendi başına anlamsız, rastgele bir token taşımalı.

Devam tokenlerini parola gibi muamele edin. Yeterince rastgele oluşturun, yapıştırılabilecek kadar kısa tutun ve veritabanında yalnızca hashlenmiş halini saklayın. Hashleme, loglar veya yedekler sızsa zararın sınırlanmasına yardımcı olur.

Tekrar kullanılabilir tokenler kullanışlı ama daha risklidir. Tek kullanımlık tokenler daha güvenlidir ama kullanıcı aynı e‑postadaki eski linke iki kez tıklarsa can sıkıcı olabilir. Orta yol olarak kısa ömürlü yeniden kullanılabilir token ve kolayca "yeni link gönder" seçeneği önerilir.

Çoğu ürün için mantıklı varsayılanlar:

• Token hash'i, oluşturulma zamanı, son kullanma zamanı ve son kullanma zamanını saklayın
• Tokenleri otomatik sonlandırın ve eski taslakları periyodik silin
• Devam sonrası tokenleri döndürün (taslak aynı kalsa bile)
• Devam denemelerini (başarılı ve başarısız) loglayın

Erişim kontrolü, kullanıcıların oturum açmasını gerektirip gerektirmediğinize bağlıdır.

Sihirbaz oturum açmış kullanıcılar içindeyse, token isteğe bağlı olmalıdır. Devam etme hesap oturumunu da gerektirebilir ve taslak o kullanıcıya (veya org'a) ait olmalıdır. Bu, "iletilmiş link" problemlerini önler.

Eğer anonim devamı destekliyorsanız, taslakta ne sakladığınızı sınırlandırın. Tam ödeme bilgileri, hükümet kimlikleri veya açığa çıkarsa zararlı olabilecek hiçbir şeyi saklamayın. Hassas taslak alanlarını dinlenirken şifrelemeyi düşünün ve devam ederken sadece maskelenmiş bir özet gösterin.

Ayrıca kötüye kullanım koruması ekleyin. Token kontrolleri ve devam uç noktalarını hız sınırlayın; tekrar eden başarısızlıklarda tokenleri kilitleyin.

Terk oranını azaltan UI desenleri

Kaydet-ve-devam-et en sık backend değil, UI tarafında başarısız olur. İnsanlar kaybolduklarını, sonraki adımı bilmediklerini veya çalışmalarını kaybedeceklerinden endişelendiklerini hissettiklerinde ayrılırlar.

Nerede olduklarını net gösterin. "Şirket bilgileri" veya "Ödeme yöntemi" gibi kullanıcıların tanıyacağı adım isimleriyle bir ilerleme göstergesi kullanın; dahili etiketler kullanmayın. Görünür tutun ve tamamlanan adımları cezalandırmadan gözden geçirmeye izin verin.

Kaydetmenin gerçek olduğunu hissettirin ama gürültü yapmayın. Ana eylemin yakınında küçük bir "Kaydedildi" durumu ve "2 dakika önce kaydedildi" zaman damgası güven oluşturur. Kaydetme başarısız olursa bunu açıkça söyleyin ve ne yapılacağını anlatın.

Kolay bir çıkış verin. "Kaydet ve daha sonra bitir" normal bir seçenek olmalı. Kullanıcı sekmeyi kapatırsa, nerede olduklarını hatırlayın ve döndüklerinde basit bir devam ekranı gösterin.

Mobilde terk daha sık artar; bu yüzden adımları küçük ekrana göre tasarlayın. Kısa adımları tercih edin, büyük dokunma hedefleri kullanın ve alan tipine uygun klavyeyi çağırın (e‑posta, sayı, tarih).

Hızlı bir UI kontrol listesi:

• Kullanıcıların tanıyacağı adım başlıkları kullanın ve tutarlı tutun
• Ana buton yakınında kaydedildi durumunu ve son kaydetme zamanını gösterin
• "Daha sonra bitir" seçeneğini "İleri" yanında sunun, menü içinde gizlemeyin
• Her adımı tek bir karara odaklayın
• Kullanıcıların hataları satır içinde düzeltmesine izin verin, tüm adımı engellemeyin

Yaygın hatalar ve nasıl önlenir

Sihirbazı final sınavı gibi ele almak terkleri hızla artırır. Eğer adım 1'i adım 6 eksik diye engellerseniz insanlar bırakır. Kaydet-ve-devam-et sihirbazı affedici hissetmeli: kullanıcıların ilerlemesine izin verin ve sık kaydedin.

Doğrulama hataları

Erken aşamada aşırı doğrulama yaygın bir tuzaktır. Adım düzeyi kontroller yapın ve katı gönderim düzeyi denetimlerini finalde saklayın.

Koruyucu önlemler gerektiriyorsa, engellemek yerine yumuşak uyarılar kullanın ("Daha sonra bitirebilirsiniz") ve sonunda nelerin gerekli olacağını vurgulayın.

Veri ve iş akışı hataları

Birçok ekip taslağı çok geç oluşturur. Taslağı yalnızca 3. adımda oluşturuyorsanız, erken veriler kırılgandır: yenileme, sekme çökmesi veya oturum zaman aşımı her şeyi silebilir. Kararlı bir kimliğiniz (oturum veya e‑posta) olduğunda taslağı hemen oluşturun ve her adım geçişinde kaydedin.

Ayrıca sahipliği net tanımlayın. Taslağı kimlerin yeniden açıp düzenleyebileceğini karar verin: sadece orijinal kullanıcı mı, aynı org içindeki herkes mi, yoksa davetli bir ekip arkadaşı mı. Bu kuralı UI'da görünür kılın.

Planlanması gereken diğer tuzaklar:

• Çift gönderimler: final submit'i idempotent yapın (aynı istek iki kez gelirse iki kayıt yaratmasın)
• Adım sırası değişiklikleri: bir wizard_version saklayın ve eskiden kalan taslakları yeni adımlara eşlemeye çalışın
• Eski verilerle devam etme: final submit'te kritik alanları yeniden doğrulayın (ör. plan fiyatı)
• Unutulmuş temizlik: eski taslakları ve tokenleri süresinde silin
• Denetim izi yok: durum değişikliklerini loglayın ki destek takımı yardımcı olabilsin

Yayına almadan önce hızlı kontrol listesi

Yayın öncesi terkleri ve destek taleplerini azaltan temel maddeleri kontrol edin.

Fonksiyonel kontroller

• Devam etme cihazlar ve tarayıcılar arası çalışıyor mu?
• Her adım, tüm sihirbaz tamamlanmamış olsa bile kaydedilebiliyor mu?
• Taslaklar yenileme, zaman aşımı ve sekme kapanmalarını atlatıyor mu?
• Net bir son inceleme adımı var mı?
• İnsanların nerede ayrıldığını görebiliyor musunuz (adım tamamlama oranı, adım başına geçen süre, yaygın doğrulama hataları)?

Güvenlik kontrolleri

Devam edilebilir linkler geçici anahtarlardır. Gizli tutun, zaman sınırı koyun ve yalnızca kasıtlı paylaşımda görünür olsun.

Pratik bir kural: eğer biri e‑postayı yanlış kişiye iletirse, o kişi hassas taslak verisini görememeli. Kısa son kullanma süresi kullanın ve yüksek riskli adımlar için yeniden kimlik doğrulaması talep edin.

Gerçekçi örnek: yeni müşteri onboarding'i (6 adım)

6 adımlı bir B2B onboarding sihirbazı hayal edin: şirket bilgileri, iletişimler, faturalama, uyum belgeleri, ürün kurulum ve son inceleme. Amaç her şeyi tek oturtta bitirmeye zorlamadan çalışan bir hesap elde etmek.

Zor kısım adım 4 (uyum belgeleri). Bazı müşterilerin dosyaları hazır olmaz. Bazıları bir yöneticinin onayını bekler. Bu yüzden sihirbaz her adım sonrası taslak kaydeder ve Draft, Waiting for documents, Waiting for approval veya Submitted gibi açık durumlar tutar.

Yaygın bir terk anı: kullanıcı 3. adımı (faturalama) bitirir ve ayrılır. Geri döndüğünde boş bir form görmez. "Onboard etmeye devam et" ekranında 3/6 tamamlandı, eksik olan (belgeler) ve adım 4'ten devam et butonu görünür. İşte kaydet-ve-devam-et'in özü: ayrılmayı normal karşılamak, başarısızlık gibi göstermemektir.

Eğer kullanıcı e‑posta davetinden başladıysa veya cihaz değiştirmesi gerekiyorsa, bir devam linki onları gerekli kontrollerden sonra tam taslağa ve adıma götürebilir (oturum açma, tek kullanımlık kod veya her ikisi).

Takım tarafında destek ve satış, admin görünümünde taslak ilerlemesini görebilir: her müşterinin hangi adımda kaldığı, taslağın ne kadar süredir beklediği ve gönderimi neyin engellediği.

Sonraki adımlar: iteratif gönderin ve bakımını kolay tutun

Küçük başlayın. Zaten terk oranı olan bir sihirbazı (checkout, onboarding, başvuru) seçin ve önce taslak ekleyin. Genelde basit bir "Kaydet" artı adım değişiminde otomatik kaydetme, yeniden tasarım yapmaktan daha hızlı terkleri azaltır.

Önce ölçün, sonra değişiklik yapıp tekrar ölçün. Adım‑adım tamamlama, bitirme süresi ve kaç kişinin ayrıldıktan sonra geri gelip devam ettiği gibi metrikleri izleyin. Destek ticket'larını ve iki adım arasında sürekli gidip gelen veya doğrulamada sürekli hata alan kullanıcıları da takip edin.

Sihirbazın değişeceğini varsayın. Yeni adımlar eklenir, sorular yeniden adlandırılır ve kurallar katılaşır. Eski taslakları bozmamak için sakladığınız veriye wizard_version ekleyin ve eski taslakların açılabilmesi için küçük göç kuralları yazın.

Eğer tüm yığını elle kodlamak istemiyorsanız, AppMaster (appmaster.io) bir seçenek olabilir. Veritabanında bir Draft varlığı modelleyebilir, adım‑adım mantığı bir Business Process olarak kurabilir ve aynı akışı web ile native mobilde kod yazmadan yayınlayabilirsiniz.