Split & Batch
Payment.
Bir borcu birçok kişiye göndermek neden hâlâ tek tek?
Toplu para transferini, herkese ayrı ayrı uğraşmadan tek akışta yapılabilir hale getirmeye çalıştığım konsept bir vaka çalışması. İşe yeni bir özellik hayal ederek değil, var olan bir bankacılık akışını gözlemleyerek başladım.
Çözüme atlamadan, soruyu sordum
Bir hafta boyunca arkadaşlarımla öğle yemeği yedik ve hesabı çoğu zaman ben ödedim. Hafta sonu herkesin payını geri göndermek istediğimde, aynı uygulamada aynı işlemi beş kez baştan yapmam gerektiğini fark ettim: aynı menü, aynı alanlar, aynı onay — sadece isim ve tutar değişiyordu.
İnsanlar bunu zaten böyle yapıyor da, uygulama neden hâlâ tek seferde tek kişiye gönderiyormuş gibi davranıyor?
Yani "toplu gönderim özelliği nasıl eklenir" diye değil, "mevcut akış bu çok-alıcılı durumu neden hiç görmüyor" diye baktım. Tasarıma oradan girdim.
Üstelik o dönemde kullandığım uygulamalarda çok-alıcılı / toplu gönderim yoktu; yeni bir özellik hayal etmiyordum, var olan tek-kişilik akışın görmediği bir durumu tasarlıyordum. Benzer özellikler uygulamalara sonradan geldi.
Gördüklerim ve oradan çıkardıklarım
Sıfırdan tasarlayarak değil, var olanı kullanarak başladım. İş Bankası'nın Para Aktar → Başka Hesaba TL Aktar akışını adım adım inceledim; iyi çalışan yanlarını da beni yoran yanlarını da not aldım.
Süreç tek ekranda ilerliyordu; bu bana akışı dağıtmadan tutmanın mümkün olduğunu gösterdi → toplu transferi de olabildiğince az ekrana sığdırmaya karar verdim. Alan isimleri ve yönlendirmeler sade, tanıdıktı → bankacılık dilini yeniden icat etmek yerine tanıdık kalmayı seçtim.
İşlemler kategorize değildi, aradığımı bulmak zordu → akışın girişini "ne yapmak istiyorum"u en baştan netleştirecek şekilde kurdum. Gönderim tarihini seçemiyordum → tarihi her alıcı için ayarlanabilir bir alana çevirdim. En çok da şu yordu: yarım kalan bir alıcı tanımı kayboluyor, kişiyi baştan eklemek gerekiyordu → alıcıyı işlemden bağımsız, kalıcı bir kayıt olarak ele almaya karar verdim.
Hepsini tek bir karara bağladım: akışı sıfırdan kurma — tanıdık olanı koru, ama çok-alıcılı durumu akışın asıl konusu yap.
En zor karar: grup nedir?
En çok zorlandığım yer, küçük görünen bir aksaklığın altındaki soruydu.
Bir alıcı eklemeye başlayıp işlemi tamamlamazsan, o tanım kayboluyordu — kişiyi en baştan girmen gerekiyordu. Yüzeyde sıradan bir pürüz. Ama altına indiğimde sebebin daha derin olduğunu gördüm: uygulama, alıcıyı ve grubu işlemin bir parçası gibi tutuyordu. İşleme bağlı olduğu için, işlem tamamlanmayınca onunla birlikte yok oluyordu.
Grubu tek bir transfer için topladığın geçici bir liste olarak bırakmak — kurması kolay, var olan mantığa yakın. Ama gözlemlediğim sinir bozukluğunu aynen geri getiriyordu.
Grubu kendi başına var olan; kaydedilen, düzenlenen, silinen, tekrar kullanılan kalıcı bir nesne yapmak. Daha zordu: yaşam döngüsünü ve üye ilişkilerini düşünmem gerekiyordu.
Grubu kalıcı kıldım. Artık grup, bir ödeme için topladığın geçici bir liste değil; bir kez kurup tekrar tekrar kullandığın, düzenlediğin, sakladığın bir nesne. İşlem grubu kullanıyor; grup işleme bağlı yaşamadığı için de onunla birlikte kaybolmuyor.
Karmaşığı sadeye: önce hepsine, sonra teki
Grup yerli yerinde — peki ya içindeki kişiler birbirinden farklıysa? En kalabalık an buydu: her alıcıya ayrı tutar, açıklama, hatta gönderim yöntemi girilebilmeli; ama bu, çözmeye çalıştığım "beş kez form doldurma"yı geri getirebilirdi.
Bunu tek bir paternle sadeleştirdim: önce hepsine, sonra teki.
Kişi kişi doldurmak yerine, işlem detaylarını —tutar, tarih, açıklama— bir kez belirleyip grubun tamamına tek hamlede atıyorsun. Beş kişi de anında aynı değeri alıyor; çoğu durumda iş zaten burada tamamlanıyor.
Biri farklıysa —diyelim bir arkadaşının payı daha az— yalnızca o kişiye dokunup onun değerini değiştiriyorsun. Diğer dördü olduğu gibi kalıyor.
Böylece en sık durum (herkese aynı) tek dokunuşa iniyor; farklılık ise istendiğinde, akışı kalabalıklaştırmadan ulaşılabilir kalıyor.
Düşünceyi yürüyen bir arayüze çevirdim
Kararlar ancak yürüyen bir akışta gerçek oluyor. Hepsini uçtan uca tek bir yolda birleştirdim: bireysel mi toplu mu seçiminden başlayıp grubu seçmeye, herkese tek hamlede atamaya, gereken kişiyi ayrıştırmaya, özette görüp onaylamaya kadar.
Akışın girişine "Bireysel / Toplu Gönderi" ayrımını en başa koydum — gözlemimdeki karar buydu: çok-alıcılı durum gömülü bir ihtimal değil, ilk adımda görünen bir seçim.
Görsel dilde gösterişten kaçındım. Bankacılık alışkanlığını bozmamak için sınırlı bir mavi–siyah ölçeği ve tek bir tipografi (Open Sans) kullandım; renk yalnızca eylemi işaret ettiği yerde güçleniyor — Devam, Onay, Tüm Alıcılara Uygula.
Bunu bir bitiş olarak görmüyorum. Arayüzler tasarlandı, akış uçtan uca duruyor; sıradaki adım kurguyu gerçek insanlarla sınamak — onun için testi çoktan tasarladım.
Bu beni nereye getirdi
Bu proje bana şunu tekrar gösterdi: çoğu zaman asıl iş yeni bir özellik icat etmek değil, var olan akışın görmediği durumu fark etmek. Buradaki her karar tek bir gözlemden çıktı — bir borcu beş kişiye tek tek göndermenin neden bu kadar yorucu olduğundan.
Tasarımı doğrulanmış saymıyorum. Bunun yerine nasıl doğrulayacağımı tasarladım: üç senaryolu bir kullanılabilirlik testi protokolü.
Katılımcıya test edilenin kendisi değil arayüz olduğunu anlatıyorum.
Sesli düşünmesini isteyip sessizce gözlüyorum — yeni bir grubu tanımlayabiliyor, tanımlı alıcıları ekleyebiliyor, toplu transferi zorlanmadan tamamlayabiliyor mu?
Teşekkür edip kayıtları gözden geçiriyorum.
Sıradaki adım net: bu protokolü gerçek insanlarla uygulamak ve "önce hepsine, sonra teki" paterninin beklediğim kadar sade hissettirip hissettirmediğini görmek. Çıkan bulgular büyük olasılıkla bazı kararlarımı değiştirecek — testi tam da bunun için yapıyorum.
Benzer bir karmaşıklığı sade bir akışa çevirmem gereken bir işin varsa, konuşmak isterim.