Çevik Tasarım Odaklı Düşünme: Dijital Ürün Tasarımı için Karma Bir Yöntem
Çevik ve tasarım odaklı düşünme çerçevesine sahip karmaşık bir tasarım projesini nasıl planlayabiliriz?
Yazan: Gunes Sayin, Proje Yöneticisi
Editör: Deniz Yazıcıoğlu, İletişim ve Araştırma Asistanı
Dijital bir tasarım projesinde gizli bir ürün sahibi misiniz?
Tasarım odaklı düşünme ve çevik yaklaşımların nasıl birleştirilebileceğini merak ediyor musunuz?
Çeşitli tasarım ekiplerini ve teknik ekipleri yönetmenin yeni yollarını mı araştırıyorsunuz?
Bu durumda, ATÖLYE’nin, 500 binden fazla kullanıcı için bu yıl başlatılacak olan yeni bir finans uygulaması tasarlama yolculuğundan bazı yeni fikirler edinebilirsiniz.
Proje nasıl ortaya çıktı?
Stratejik tasarım stüdyosu şapkasıyla ilk defa bir banka ile birlikte KOBİ stratejisi üzerine çalıştık. Üst yönetim ile yaptığımız strateji belirleme toplantılarında globalde bankanın gittigi yöne bakarak Türkiye’de neler yapılmasi gerektiğini masaya yatırdık. Bunun üzerine KOBİ ve Kurumsal bankacılık kullanıcılarının fonksiyonel ve tasarımsal ihtiyaçlarının bireysel bankacılıktan çok farklı olduğunu 2017’de 4 aylık bir tasarım araştırması projesinde keşfettik.
Kullanıcı segmentlerini belirledik ve mevcut fonksiyon setini genişleterek yeni platformu, baştan sona tüm günlük bankacılık ihtiyaçlarını destekleyen bir sağ kol olarak konumlandırdık. Bunun için 4 yeni fonksiyon alanı belirledik. Bu fonksiyonlardan en öncelikli iki tanesini de kapsama dahil ederek yazılım tasarımı fazına 2018’de başladık. Bu makalede 2018'de yapılan bu yazılım tasarımı projesinden bahsedeceğiz.
ATÖLYE’nin bu projedeki misyonu; tasarım odaklı düşünme yaklaşımını uygulayarak, yeni akışlar ve uygulama mimarisinden kullanıcı arayüzü tasarımları ve animasyonlarına, Kurumsal ve KOBİ bankacılığı müşterileri için yepyeni bir dijital bankacılık deneyimi sunmaktı.
Başvurduğumuz kaynaklar arasında IDEO’nun tasarım odaklı düşünme kitleri (IDEOU, 2019), The Sprint Book (Knapp, 2016), Medium üzerindeki araştırma makaleleri — özellikle çevik alışkanlıklar/tasarım faaliyetlerinin farklı uygulamaları hakkında -ve IBM’in Tasarım Odaklı Düşünme makaleleri (Roach, 2016) yer almaktaydı. Bu makalede, proje özelinde bir yöntemi nasıl birleştirip yeniden oluşturduğumuzu açıklıyoruz.
Projemiz hem uygulamadaki tüm süreçlerin yeniden yapılandırılmasını hem de birçok özelliğin ilk kez dijitalleştirilmesini içerdiğinden, proje boyunca banka bünyesine uygunluk, hukuk, bilgi güvenliği, nakit yönetimi-kredi departmanları ve benzeri gibi birçok iç paydaşı dâhil ederek ilerledik. Daha iyi zaman yönetimi yapma amacıyla da, mevcut tasarım odaklı düşünme ve çevik yaklaşımlarını basitleştirdik ve tasarım odaklı düşünme adımlarının ayrıntılı bir versiyonunu oluşturduk.
Müşterimiz, bizden özellik setlerini on ay içinde teslim etmemizi bekliyordu. Bu yüzden her bir özellik seti için 1–2 ay ayırdık. Bunları, uzun tasarım serileri (design sprint) olarak tasarladık ve “çevik tasarım döngüleri” olarak adlandırdık.
Bu döngüler, aşağıdaki adımların tümünü içermektedir: Problem tanımı, hızlı masaüstü araştırması, fikir geliştirme, paydaş onaylarının alınması için sahada prototiplendirme ve test yapma ve kullanıcı arayüzü ve animasyon tasarımlarının sonlandırılması. Döngünün adımlarına da müşterimiz ile birlikte karar verdik.
Hem biz hem de müşterimiz, döngü içinde belirtilen tüm son teslim tarihlerine riayet edememiş olsa da, her bir set için önceden ayarlanmış süreler, uyulması gereken gerçekçi bir son teslim tarihi ve de son teslim süresine uyulmasında başarılı bir zaman yönetimi aracı olarak görev aldı.
Adımları tanımlama
1. Adım — Problem Tanımı, Hızlı Masaüstü Araştırması, Fikir Geliştirme
Bu aşamada, aşağıdaki faaliyetleri birleştirdik:
• Müşteri ile işbirliği yaptığımız “olduğu gibi” (as is) sürecinin analizi
• Bire bir görüşmelerle kullanıcı ihtiyaçlarını anlama
• “Olduğu gibi” kullanıcı yolculuğunu oluşturma ve sorunların, fikre dönüştürme oturumlarında girdi olarak kullanılmasının önemini vurgulama.
• Kritik referanslar ve ilham veren çözümlere yönelik küresel ve yerel düzeyde karşılaştırmalar için masaüstü araştırması.
• “Önerilen” (to be) süreci için tasarım, Bilgi Teknolojileri ve İş ekipleriyle fikir alışverişinde bulunmak.
2. Adım — Görüş Birliği ve Özet
Bu bir bankacılık uygulaması olduğundan ve tüm süreçleri yeniden tasarladığımız için, “Önerilen” süreci hakkında diğer iç ekiplerden geri bildirim almamız gerekiyordu. Uygunluk departmanının her bir yeni süreci ve ilgili ürün başlığını onaylaması gerektiğinden, bankanın iç ekiplerinden gelen geri bildirimlerin önemi büyüktü. Bu sırada; tasarım özeti, kullanıcı deneyimi tasarımcısına teslim edilmek üzere hazırlandı.
3. Adım — Taslak
Taslak tasarımlar, özellik setinin karmaşıklığına bağlı olarak her 4–8 günde bir değişmek zorundaydı. Bununla birlikte, bu aşama için bir zaman dilimi belirlemek, önceliklere bağlı kalarak ve bazı detayları kullanıcı arayüzü aşamasına bırakarak Asgari Uygunlukta Ürün (MVP) perspektifinde düşünmemize yardımcı oldu.
4. Adım — Değerlendirme
Taslak prototiplerini sahaya getirmeden önce, Bilgi Teknolojileri, Uygunluk ve diğer ilgili birimlerle yapılan oturumları değerlendirdik ve gerektiği durumlarda taslaklar revize edildi.
Tasarımların Invision ile paylaşılması, çok sayıda paydaşın prototipler ile ilgili yorum yapmasına yardımcı oldu. Invision üzerindeki tasarım çıktılarına ilişkin geri bildirimleri değerlendirme, toplama ve sonuçlandırma süreçlerinden müşterinin proje ekibi sorumluydu.
5. Adım — İlk Kullanıcı Testi
Kolay kullanım testleri, 1–2 gün boyunca sahada gerçekleştirildi. Bu, kullanması kolay çözümlere ilişkin birçok değerli fikri duyduğumuz en önemli geri bildirim aşamasıydı. Taslaklar bu geri bildirimler doğrultusunda revize edildi.
6. Adım — Son Değerlendirme ve Revizyonlar
Bankadaki paydaşlar, taslakları son bir kez değerlendirdiler ve biz de taslakları buna uygun olarak değerlendirdik.
7. Adım — İkinci Kullanıcı Testi
Taslakların son sürümü ilk kolay kullanım testinden farklıysa, yeni taslaklar ile ikinci bir kolay kullanım testi gerçekleştirdik.
8. Adım — Kullanıcı Hikâyesi ve Kullanıcı Arayüzü Tasarımı
Kullanıcı hikâyesi yazıldı ve kullanıcı arayüzü tasarımcılarına atandı. Kullanıcı arayüz tasarımı tamamlandığında ve tüm paydaşlar tarafından onaylandığında, kullanıcı hikayesini güncelledik ve kullanıcı arayüzü elemanları Zeplin’deki yazılım geliştirme ekibine teslim edildi.
Zorluklar
Bu karmaşık bankacılık uygulaması için tasarım odaklı düşünme ve çevik yaklaşımları birlikte uygulanırken, ortaya çıkan sorunlara kendi çözümlerimizi getirmek zorundaydık.
1. Ürün Sahibi Belirsizliği:
Çok sayıda paydaş var, ancak hiç kimse “Ürün Sahibi” değil.
İpucu: Ürünün sahibi gibi davranarak hizmetkâr-lider zihniyeti ile karar almanın merkezi olarak görev aldık.
“Ürün Sahibi” nedir?: Bir Ürün Sahibi’nin görevi, bir ürünün vizyonunu oluşturmaktır. İş stratejisi ve ürün yönetimi ile ilgili bilgi ve becerilerini teknik ürün sahibi ile birleştirerek, bu görev, bir ürünün hedefini belirlemede çok önemli bir rol oynamakta ve organizasyonun bu hedefe ulaşmasına yardımcı olmaktadır.
Çözüm
Müşterimiz, bu proje özelinde özel bir Ürün Sahibi görevlendiremedi çünkü çevik (agile) dönüşüm bankada yeni yeni gerçekleştiriliyordu ve Ürün Sahipleri, henüz kurum içerisinde görevlendirilmemişti. Projede görevlendirilen proje yöneticileri ise 5 kişiydi ve hiç kimsenin karar alma konusunda bir üstünlüğü yoktu. Bilgi Teknolojileri, paydaşlar, kullanıcılar ve tasarım ekibi arasındaki tüm iletişim akışının merkezinde olduğumuzdan dolayı “Gizli Ürün Sahibi” olmanın avantajlarına sahiptik. Stratejik bir tasarım ortağı olarak, tasarım prensiplerini kullanıcılar ve müşteri ile birlikte oluşturduk. Daha sonra bu prensipleri Asgari Uygunlukta Ürün (MVP) projesi boyunca uyguladık.
2. Tasarım ve Bilgi Teknolojileri Ekibi Ayrımı
Tasarım ve Bilgi Teknolojileri üyeleri aynı lokasyonda değildi ve bazı ekip üyeleri yarı zamanlı olarak çalışıyordu.
İpucu: Çevik (Agile) yaklaşımına göre düzenli toplantılar hayati öneme sahip. Deneyimlerimize göre stil kılavuzunun %50-%70’i tamamlanana kadar tasarım ve bilgi teknolojileri ekipleri düzenli olarak toplantı yapıyor olmalı.
Çözüm
• Stil kılavuzunun %70'i tamamlanana kadar, her hafta 6 saatlik toplantılar yaptık. Bu toplantılar projenin geri kalanı için büyük bir yatırım oldu. Yazılım geliştirme ve tasarım ekipleri, kullanıcı odaklılık amacıyla fikir geliştirme aşamasına kadar erken bir aşamadan başlayarak tasarımlar ile ilgili işbirliğinde bulundu.
• Taslaklar yazılım geliştirme ve tasarım ekipleri tarafından birlikte oluşturulduktan sonra, animasyon geri bildirimleri için Slack, kullanıcı arayüzü üzerinden gönderilebilir geri bildirimler için Zeplin ve taslak ile devam eden kullanıcı arayüzü geri bildirimleri için Invision gibi dijital araçlardan faydalandık.
3. Tasarım Araştırması Koordinasyonu
Kullanıcılar, test günü geldiğinde sürekli olarak iptal ediyorlardı.
İpucu: Komünitemizden yararlandık.
Kullanıcı araştırma görüşmelerinin son dakika iptal edilmelerini, alanında titizlikle kürasyonu yapılmış bir komüniteye sahip olmamız ile bertaraf ettik. Çok disiplinli komünitemiz, tasarım araştırması için gerekli sayıdaki insan havuzunu oluşturdu.
4. Bir Tasarım Sistemi İhtiyacı
Waterfall (Şelale) yerine Agile (Çevik) bir yöntem ile tasarım yapmak, tasarımlar üzerinde çok fazla revizyon yapılması anlamına gelmektedir.
İpucu: Sketch üzerinde bir kitaplık dosyası oluşturduk ve buna Abstract üzerinden erişim sağladık.
Tasarım projelerinde çevik bir yöntem uygulamak, her bir tasarım için birçok revizyon yapıldığı anlamına gelmektedir. Örneğin, kart veya liste bileşenleri, gölge veya yazı tipi boyutu kuralları süreç ilerlerken değişebilir. Bir Sketch dosyasını kitaplık olarak kullanmak ve buna Abstract üzerinden erişmek bize çok zaman kazandırdı. Abstract’ı kullanarak, her bir tasarımcı kitaplık dosyasını aynı anda açıp düzenleyebilme olanağına sahipti.
Sonuç
Bu proje için mevcut tasarım odaklı düşünme ve çevik yaklaşımlarının basitleştirilmesi, zaman, görev ve müşteri yönetimi açısından yardımcı oldu. Kullanıcı odaklılığı sağlamak ve işletme, tasarım ve Bilgi Teknolojileri birimleri arasında verimli bir uyumu korumak için dijital tasarım proje planlarının yoğun bir şekilde yüz yüze etkileşimi içermesi gerektiğini doğruladık.
Sketch üzerindeki tüm bankacılık arayüzleri için tasarım odaklı düşünme yöntemlerini ve bir tasarım sistemini uygulamak hızlı bir süreç değildir. Ancak; Slack, Sketch, Abstract ve Invision gibi dijital araçların kullanımı ve kombinasyonu, verimli proje yönetimi ve tüm iç paydaşların üzerinde mutabık kaldığı bir son ürünü ortaya çıkarmak için kilit bir öneme sahiptir.
Tüm süreci modüler bir şekilde yönetmek, yazılım geliştirme ekibinin sürece daha ilk aşamadan dâhil olarak çalışmaya başlamasını sağladı ve verimliliği arttırdı. Proje 2019'da yayına girecek ve UX — UI anlamında daha fazla bilgiyi de sizlerle paylaşıyor olacağız.
Üstlendiğimiz her projede, kullanıcı ihtiyaçlarına sadık kalıyoruz ve insan odaklılığı akılda tutarak tasarım zorluklarına çözümler üretiyoruz. Bu, uzun vadeli çözümler yaratmadaki en önemli değerlerden biridir.
Ne düşünüyorsunuz? Neyi doğru yaptık? Neyi geliştirebiliriz?
Tasarım ekipleri için başka çok fonksiyonlu (kullanıcı arayüzü tasarımı, animasyon, prototiplendirme) araçlar, tek noktada hizmet sunumları var mı?
Bunu daha farklı nasıl yapardınız? Geri bildiriminizi duymak isteriz.
