LC Waikiki Mobil Uygulamasını Nasıl Tasarladık? — B.10: Ödeme b.1

Uygulamanın tasarım sürecinin sonuna epeyce yaklaştık dostlar. Sonrası için ise lcwaikiki.com web sitesi için yaptığımız bütünleşik kanallar (omnichannel) ve yeniden tasarım (redesign) çalışmaları için ayrıca bir seri yazmayı düşünüyorum. Bu projeden öğrendiğimiz şeylerle orada bir sürü yenilikler yaptık.

Mobil uygulama hikayesinin son adımı olan ödeme kısmı belki de yaptığımız en radikal tasarım olduğundan ve anlatılacak çok şey olduğunu düşündüğümden iki bölümde anlatacağım. Hem böylece seri 10 bölüm olmuş olur.

Her zamanki gibi önce reklamlar 🙂 Öncesinde sekiz bölüm olduğu için bu kez direkt olarak etiket sayfası ekliyorum. Tüm bölümler orada 🙂

Ödeme sayfası bir satın alma akışının son adımıdır. Kullanıcının müşteriye dönüştüğü bir dönüştürücü de (transformator) diyebiliriz. Fakat sadece “parasını alıp ürününü göndermek” olarak düşünmek bana pek doğru gelmiyor. Aslında ödeme (checkout) sayfası kullanıcının o ana kadar yaşadığı tüm deneyimin oluşturduğu güven hissinin karşılığını almak diyebiliriz.

Kullanıcının “sana güvendim” demesinin en somut karşılığıdır. Bence.

Bu romantik düşünceler yüzünden bu kısmı bir “kasa önü” olmaktan ziyade başka şekilde ele almalıydık.

Kompakt, Basit ve Kolay

Sanıyorum ki bu üç kelimeden artık gına gelmiştir. (Diğer bölümleri okuduysanız kesin gelmiştir. Bana geldi 🙂 ) O yüzden bu konuya girmiyorum. Anlatmak istediğim şey aslında bu sayfa özelinde tasarımdan ziyade tasarım öncesindeki yaklaşımımız.

Biri bakabilir mi acaba buraya?

Uygulamayı tasarlarken, yukarıda bahsettiğim üç temel yaklaşımın yanında uzun vade için düşündüğümüz başka bir yaklaşım da şuydu; muhatap oluşturma.

Bir e-ticaret sitesinin ya da uygulamasının en büyük eksikliği ürünü fiziksel olarak hissedememek ve etrafta sorularınızı yanıtlayacak bir muhatap olmamasıdır. Daha önceki bölümlerde Bu muhatap yaratma ile ilgili başka sayfalarda da çalışmalarımız olduğundan bahsetmiştim.

Kısaca yeniden özetlemek gerekirse, bir sanal asistan ya da canlı sohbet özelliğinden ziyade uygulamanın genelini bir muhatap haline getirmeyi planlıyorduk. Aslında uygulamanın en temel özelliğini satış görevlisi olmak diye düşünebilirsiniz. İstediğiniz tüm sorulara cevap verebilen, istediğiniz ürünü size getiren, ürününüzü size nasıl taslım edeceğini soran ve en sonunda da ödemeyi alan bir satış görevlisi. Kişiye özel bir görevli. Yaklaşım bu olduğunda yaşatılacak deneyim de biraz daha kişilik sahibi olacağını düşündük. Uzun vadede bu konuyla ilgili planlamamız hazır.

Bize yeni bir ödeme sayfası lazım!

Aslında bu sayfayı biz mobil uygulama projesinden çok önce tasarlamıştık. Web sitemizin ödeme akışını değiştirmek istiyorduk. Bize yeni bir ödeme sayfası gerekiyordu. Eskisinin epeyce sorunları vardı.

Toplamda üç ay süren bir tasarım sürecine sahip sadece ödeme sayfası. Sayfa diyorum çünkü ilk dakikadan itibaren bu adımların tek bir sayfada olmasını istiyorduk ve sonunda ulaştığımız noktada bunu başardık.

Web sitesi için 3 farklı konsept hazırlandı önce. İlk ikisi görece daha klasikleşmiş akışlara sahipken, bir tanesi tamamen radikal değişikliklerin olduğu bir varyasyondu. Genellikle radikal değişimler kullanıcılara itici gelse de yaptığımız ilk testlerde kullanıcılar bu radikal tasarımı çok sevdiler.

Aslında yaptığımız şey şuydu; tüm ödeme sürecini bir “soru cevap akışına” dönüştürdük. Aslında onlara bir uygulama değil, bir kasiyer sunduk. Sanırım bu yüzden kullanıcılar diğerlerine nazaran bu radikal varyasyonu daha çok sevdiler. Biz de doğru yolda olduğumuzu net şekilde anlamış olduk böylece.

O testlerden gelen sonuçlara göre konseptin üzerinde değişikliklere gittik.

Hangi adımdayım?

Konsept testlerinden çıkan sonuç şuydu; hangi adımda olduğumuzu net olarak anlamıyoruz? Ödemenin tamamlanmasına ne kadar var kestiremiyoruz?

Bu bilinmezlik durumu insan beyni için inanılmaz derecede rahatsızlık veren bir şey. İnsanlar yaşadığı sürecin ne zaman biteceğini bilmek isterler. Herhangi bir durum için geçerlidir bu. Bu yüzden ilerlemeyi (progress) çok daha fazla ön plana çıkartmamız gerekiyordu. Bunu not ettik.

Yine başka bir olumsuz yorum da her ne kadar pasif olsa da insanlar “siparişi tamamla” butonuna dokunmak istiyorlardı. Boşuna bir etkileşim çabası…

Ortaya çıkan bu iki sorunu aşağıda gördüğünüz gibi çözdük. Adına da “progress button” dedik.

Bu haliyle siparişi tamamla butonumuz aynı zamanda ödeme adımlarındaki ilerlemeyi de gösteren bir ilerleme çubuğuna (progress bar) dönüştü. Şu an butonumuz hem kullanıcıya nerede olduğunu ve ne zaman biteceğini belli ederken, aynı zamanda da sonuca ulaşmasını sağlayan kapıyı da aralamasını sağlayan bir objeye dönüştü. Şahsen çok akıllıca bir çözüm bulduğumuzu düşünüyorum. İlk konseptte ilerleme çubuğu son haline kıyasla daha küçük bir haldeydi ve gerçekten de dikkat çekmiyordu. Onu düşününce bu son hali gerçekten içimize sinen, inovatif bir çözüm oldu.


Ödeme sayfası tasarımının ilk bölümünü burada sonlandırıyorum. 5 dakikalık bir okuma oldu. Uzatırsam tamamının okunma oranı düşecektir. Acı; ama kullanıcı verileri bu yönde. İnsanlar 3–5 dakikalık okumaları tamamen okunmaya daha teşne oluyorlar.

Bir sonraki bölümde ödeme sayfasının genel tasarımından, oyunlaştırma öğelerinden bahsedeceğim.

Okuma için teşekkürler.

Yazan /

selcukavc@gmail.com

Kafa kağıdımda doğum tarihim 1 haziran olsa da, annemin verdiği bilgilere dayanarak söylüyorum ki Mayıs ayının 29.günü, beş buçuk kilo ağırlığında, Sakarya ilinin şirin mi şirin Karasu ilçesinde dünyaya gelmişim.

Yorumla