Operation Valkyrie! Verimlilik ve İşbirliği İçin Figma’ya Geçtik! Geçtikte Ne Oldu? 🤔
Sonda söyleyeceğimi başta söyleyeyim ve rahatlayayım; Hayır problemlerin çoğu çözülmedi, çözülmesi mümkün fakat kolay değil!
Not: Bu yazı “ne harika işler yapıyoruz” üzerine olmayacak. Onlardan çok var. Bu yazı, çuvaldızı kendimize batırdığımız ve iş yapış süreçlerimizde nerede tökezlediğimizle ilgili olacak.
Özet
Son birkaç yıldır hem Linkedin hem de Medium üzerinde çokça gördüğüm Türkçe başlıklardan birkaç örnek vermek gerekirse:
Son zamanlarda bu ve bunun gibi içerikleri görmek mümkün. Eski alışkanlıkların terk edilip yeniye geçiş süreci sürekli oluyor ve olacak ve bu çok tabii bir durum.
Dijital ürün tasarım ekibi olarak, techbase bir firmada yaşam savaşı verirken aynı zamanda çıktı kalitemizi ve iş yapış şeklimizi de geliştirmemiz gerekiyordu. Fakat konu, bir aracı bırakıp başka bir araca geçmekten daha geniş kapsamlıydı ve sorunu doğru anlamak önemliydi.
Bir yıl önce, bu hedefe ulaşmak için yeni bir adım attık ve tasarım araçları konusunda bir değişiklik yaparak Sketch’i, Zeplin’i ve Miro’yu terk edip Figma’ya geçiş yaptık. Bu değişiklik, çalışmalarımızı birleştirip verimliliğimizi artırırken aynı zamanda bize maliyet tasarrufu sağladı. Bu yazıda, Sketch, Zeplin ve Miro’dan Figma’ya geçiş sürecimizi değil, (çünkü çok sıkıcı, afferin bize 🤟) bu sürecin yaşanması gerekliliğini neden-sonuç ilişkisi üzerinden anlatmaya çalışacağım.
Giriş: Çevrimdışı Çalışma Süreçlerine Dair
Eski süreçte; yani bir yıl kadar önce, ürün tasarım ekibi olarak üç farklı araç kullanarak çalışıyorduk: Miro, Sketch ve Zeplin. Miro’yu kullanarak kullanıcı deneyim araştırmalarını yapmaya çalışıyor, Sketch üzerinde tasarım çalışmalarını gerçekleştiriyor ve son olarak Zeplin aracılığıyla yazılım geliştiricilerle ve diğer paydaşlarla işbirliği yapıyorduk. Bu süreç, zaman kaybına ve iletişim sorunlarına yol açıyordu. Ayrıca, bu üç aracın yüksek ücretleri, mevcut düzen için çok anlamsızdı.
Bu çalışma şeklini görselleştirmek isteseydik, sanırım şöyle olurdu:
Gelişme: Ve Figma’nın Keşfi
Keşfettiğimiz bir şey yok aslında. Figma orada duruyordu. Ancak her çalışanın kariyeri boyunca elde ettiği deneyimi yeni firmasına taşımak istemesi gibi sorunlu bir kavram yüzünden, yukarıda yer alan çevrimdışı çalışma alışkanlığı burada da uygulanmaya çalışılıyordu.
Yani pilav normaldi, sorun bizdeydi.
Yasama-Yargı-Yürütme
Ve bir plan oluşturduk. Bu plan her ne kadar bir araç değişikliği gibi görünse de, aslında DesignOps adı verilen ve yeni bir çalışma biçimini hedefleyen bir yol haritasıydı. El sıkışıldı ve plan yürütülmeye başlandı. Neredeyse 7 ay sürecekti ve araç geçişi ile başlayarak TurkNet Design Studio’ya kadar ilerleyen büyük bir yelpazeyi içeriyordu. Ancak işler istenildiği gibi gitmedi. 🥺
Yol haritası özetle şu şekildeydi:
1- Miro, Sketch, Zeplin’e, sorunun bizde değil onlarda olduğu söylenecek ve terk edileceklerdi.
2- Burada yapılan tüm çalışmalar Figma’ya aktarılacaktı.
3- Yeni bir tasarım sistemi oluşturulacak ve Figma içerisinde konumlandırılacaktı.
4- Sadece bir tasarım sistemi değil bir çalışma sistemi oluşturulacak ve kesin olmayan kurallarla taçlandırılacaktı.
5- Diğer tüm paydaşlar bu sisteme uygun şekilde adapte edilecek ve çalışma sistemi, kreatif bir üretim bandına dönüştürülecekti.
6- Sadece ama sadece veri odaklı deneyim süreci başlatılacaktı.
7- “Next TurkNet” için çalışılmasına zemin oluşturulacaktı.
8- TurkNet Tasarım Stüdyosu oluşturulacak ve yayım süreci başlatılacaktı.
Figma’ya geçiş süreci, tasarım ekibimiz için sorunsuz bir şekilde gerçekleşti. İlk olarak, Miro’nun yerini Figma’nın kullanıcı araştırması özellikleri (FigJam) aldı. Bu sayede kullanıcı testlerini, prototipleri ve geri bildirimleri doğrudan Figma üzerinden yönetebildik. Ardından, Sketch’te yapılan tasarımlarımızı Figma’ya aktardık. Figma’nın Sketch entegrasyon özellikleri sayesinde tasarımlarımızın süreci aksatmadan geçişini sağladık. Elbette, yolda bu sürecin içselleştirilmemesi sebebiyle yaşanan kazalar oldu ve fakat bir bir süre sonra geçiş sağlanmış oldu.
Figma’ya geçişin en önemli avantajlarından biri, üç ayrı aracın yerine tek bir platformda tüm tasarım sürecini yönetebilmemiz oldu. Bu, zaman kaybını minimize etti ve iletişimi güçlendirdi. Ayrıca, Sketch, Zeplin ve Miro için ödediğimiz yüksek ücretleri ortadan kaldırdık ve şirket bütçemizde tasarruf sağladık. Figma’nın çevrimiçi olması, herhangi bir yerden ve herhangi bir cihazdan erişilebilir olmamızı sağladı ve uzaktan çalışma ortamımızda büyük bir kolaylık sağladı.
Son olarak, Zeplin’i tamamen bırakarak, geliştiricilerle, proje yöneticileriyle, iş geliştirme uzmanlarıyla yani kısacası tüm paydaşlarla, işbirliğini Figma üzerinden gerçekleştirmeye başladık. Figma’nın paylaşım ve işbirliği özellikleri, geliştiricilerle iletişimi kolaylaştırdı ve tasarımların daha hızlı ve sorunsuz bir şekilde hayata geçmesini sağladı.
Harika! Peki Tüm Problemler Çözüldü mü?
Yukarıda DesignOps başlığı altında paylaştığım görsele dikkat edilecek olursa bu plan, sadece bir araç geçişini kapsamıyordu. Bizim bir devrime ihtiyacımız vardı. Techbase bir firmada yaşam savaşı veren ürün tasarım ekibine başlı başına bir entity yani kimlik kazandırmalı, çalışma kültürünü kökten değiştirmeli, kullanıcı ve kullanılabilirlik testleri lüks değil ihtiyaca dönüştürmeli, her proje ve geliştirme öncesi araştırma süreçleri paydaşlar tarafından şiddetle talep edilmeli ve en önemlisi de, servise göre deneyim değil deneyime göre servis çalışılmalıydı.
Sonuç: Neydik, Ne Olduk?
Evet Figma’ya geçiş yaptık. Evet zamandan ve maliyetten tasarruf ettik. Daha çevik ve daha çevrimiçiyiz. Tasarım sistemi oluşturduk ve projelerimizi oluşturduğumuzda kütüphanelerimizi projelerimize entegre ederek çalışıyoruz. Ancak günün sonunda bütün bu süreci içselleştirmediğimiz, iletişemediğimiz, aynı düşünce yapısına sahip olamadığımız için ve en önemlisi de kültürü değiştirip, ezber bozmaya itikatımız yetmediği için şu an olmaktan korktuğumuz yerdeyiz. Sürecin ilk dört adımını çalıştırabildik. Sonrası ise kocaman bir muamma olarak kaldı. 🫢
Ne Yapmalı, Nasıl Yapmalı?
Süreç içerisinde tökezlediğimiz noktaları konuşmalı, süreci yeniden yapılandırmalı ve içselleştirmeliyiz. Başarılar üzerine değil hatalar üzerine dekonstrüktif bir bakış açısı belirlemeli ve yeni hedefler belirleyerek bu hedefleri tekrar planlamalıyız. Yeni bir üretim bandı oluşturmalı ve paydaşları buna göre eğitmeli. Çıktıları pixel perfect noktaya getirene kadar yeni yöntemler koşmalıyız.
Yeni yol haritası:
1- Yeni bir çalışma sistemi oluşturmalı ve kesin olmayan kurallarla taçlandırılacaktı.
2- Tüm paydaşlar bu sisteme uygun şekilde eğitilmeli ve çalışma sistemi, kreatif bir üretim bandına dönüştürülmeli.
3- Sadece ama sadece veri odaklı deneyim süreci başlatılmalı.
4- “Next TurkNet” için çalışılmasına zemin oluşturulmalı.
5- TurkNet Tasarım Stüdyosu oluşturulmalı ve yayım süreci programlanmalı.
Dipnot: Yukarıda anlatılan masalsı hikayenin arkaplanında daha teknik bir şeyler okumak isterseniz aşağıdaki yazılara da göz atabilirsiniz:
DesignOps. süreçlerini teorik olarak irdelediğimiz diğer yazıya göz atmak istersen hemen aşağıdaki makaleye bakabilirsin.
