Ürün Geliştirmede Tasarım Süreci Yönetimi
Dijital bir ürün geliştirirken, hangi takım içerisinde rol alırsanız alın farketmeksizin, iş akış sürecinizi doğru yönettiğiniz taktirde ortaya çıkan sonuçların kaliteli ve daha az yorucu olduğunu gözlemleyeceksiniz. Ben bu yazıda sizlere, biz Socio’da “Tasarım Süreci”mizi nasıl kurguladık ve hali hazırda nasıl yönetiyoruz bunlardan bahsedeceğim.
İhtiyacın veya sorunun belirlenmesi akabinde; yeni bir özellik, geliştirme veya iyileştirme gibi görevlerin tasarım ekibine gelmesiyle başlar sürecimiz. Gerek Product ekibinden, gerek kullanıcılarımız ile sürekli temas halinde olan Customer Success ekibinden, gerekse Tasarım ekibinin kendi içerisinden doğar bu görevler.
Tasarım ekibine atanan herhangi bir görevin (yeni bir özellik, geliştirme veya iyileştirme) JIRA süreçlerine düşmeden önce doğuş hikayesine değinmek isterim. Şayet, sebebi olmayan bir iş; ihtiyaç ve sorun değildir bana kalırsa.
Eğer ihtiyacımız olan şey bir özellik ise, şirket içerisinde ürünü geliştiren ekibin ortaya sunduğu bu geliştirmenin arkasını dolgun sebepler ile doldurması beklendiği haldir. Yani, günün sonunda biz ürünümüze yeni bir özellik ekliyor isek, bunun:
- Bu özellik nedir? Ürüne ne katmasını bekliyoruz?
- Neden bu özelliğe ihtiyaç duyuyoruz?
- Bu özelliği kimler kullanacak? Kimler için tasarlıyoruz?
- Önem sıralaması nedir?
gibi soruları cevaplamasını bekleriz. Bu sorular pek tabii çeşitlendirilebilir veyahut azaltılabilir. Açıkçası yazıyı yazarken, aklıma gelen genel beklentileri paylaşmak istedim.
Eğer ihtiyacımız olan şey, yeni bir özellikten ziyade bir sorun veyahut geliştirme yapılması gereken bir nokta ise bu sefer soruları kullanıcılarımızın (müşterilerimizin) halinden eeennn iyi anlayan, onlar ile sürekli iletişim halinde bulunan Customer ekibi oluyor. Yukarıdaki sorulara benzer soruları bu sefer onlar cevaplayıp geliyorlar üretim ekibi için.
Bir de ne oluyor biliyor musunuz? Bu sefer ellerinde bazı veriler ile gelebiliyorlar. Kullanıcılarımızı izleyebildiğimiz, hareketlerini takip edebildiğimiz, belirli funnel’ları oluşturup gözlemleyebildiğimiz ve daha nice yazmayı unuttuğum veri tipi ile tezlerini destekleyebiliyorlar. Tabi bütün bu verileri sorunun ne olduğunu kanıtlamak daha doğru bir tabirle açıklamak için değil, sorunun çözümünde sorunu daha iyi anlayıp çözüm üretebilmemizi sağlamak için de kullanıyoruz. Bütün bu verileri toplamak için Fullstory adlı aracı kullanıyoruz.
Süreçleri anlatacak olursam, JIRA’da aşamaları nasıl adlandırdıysak öyle başlıklandıracağım. Bu sayede daha anlaşılabilir olacağını tahmin ediyorum.
To-Do Stage (Yapılacak)
Bu süreçte, yukarıda bahsi geçen görev türlerinden birisi tasarım ekibine Product Management ekibi tarafından atanmış oluyor.
Bu aşamada atanan görevin yapılacağını tüm ekip kabul etmiş, görevi anlamış ve genel olarak hakkında bilgi sahibi edilmiş oluyor. Fakat yine de, bahsi geçen görev o an hangi ekibin üretim sürecinde yer alırsa alsın tüm detayları ile, tüm açıklamaları dokümante edilmiş bir şekilde ekibe atanır.
Bunun sebebi görev üzerinde çalışan ekip ya da kişi kim olursa olsun onu yalnız başına bırakmamaktır. Aklına bir soru geldiğinde dönüp tekrar dokümasyona bakabilmesini ve kimseye ihtiyacı olmadan cevabını bulabilmesidir. Görevin daha bu aşamaya gelirken yukarıda bahsettiğimiz soruların cevabından oluşan açıklamalarını, gereksinimlerini istediği her an erişebilmesini sağlamaktır.
Tabii böyle anlatırken, yanlış anlaşılmasın; görevi atayıp ondan sonra kayıplara karışmak söz konusu değil, zaten olmamalıdır da. Üretim ekibinin tamamı remote opsiyonlu çalışan bir şirket olarak Slack ve online görüşmeler için kullandığımız Zoom.us’ı epey aktif ve doğru kullandığımızı belirtmeliyim. Bunun faydasını çok ama çok görüyoruz. Özellikle Slack kanallarının kullandığımız diğer uygulamalar ile de eşlenik olması Slack’i bizim için bütün iletişimi toparlayan bir araç haline getiriyor.
Biz Socio’da, bu süreci en kısa haliyle şu şekilde açıklıyoruz;
Once the product team comes up with the next batch of features, the Product Manager and the Lead Designer works on creating mockups and setting up requirements. Once that is done, they create the detailed task on JIRA and put it in the “To do” stage in the sprint.
In-Progress Stage (Devam Etmekte)
Bu süreçte, bize atanan iş üzerinde çalışıyor oluyoruz. Tabiki bu yazı sadece üstünde çalıştığım bir görevin/işin hakkında olsaydı, burada da anlatılacak çok şey vardı fakat genel olarak üstünden geçeceğim zaman burada çokta anlatılacak bir şey yok.
Bize atanan görevi, bizden beklenenler doğrultusunda, beklenen zaman içerisinde yapmamız gereken süreç olarak tanımlayabiliriz. Yukarıda bahsettiğim gibi, bu süreç üretim süreci olduğu için tabiki kendi içerisinde bir çok detayı kapsıyor olabilir fakat bunlara bir başka yazıda değinmek daha doğru olacaktır.
Biz Socio’da, bu süreci en kısa haliyle şu şekilde açıklıyoruz;
Looking at that task’s initial mockup and requirements, the Lead Designer drags this task to “In Progress” and starts their work by creating the concept design and building alternatives until deciding on a single version to present.
Once this is ready to be presented to the Product Manager, the Lead Designer uploads the designs to Zeplin, shares the link on the task and drags the task to “Ready to test”.
Ready to Test (Test Edilmeye Hazır)
Bu süreçte, tasarım ekibi olarak biz, to-do aşamasında aldığımız görev üzerindeki çalışmalarımızı tamamladıktan sonra Lead Designer’ın ve Product Manager’ın testine sunarız.
Bildiğiniz üzere dijital arabirim tasarımları yaparken birçok farklı noktaya etki ederiz. Bu yüzden, tasarımları yaparken görsel kaygının ötesindeki etkenlerede dikkat ederiz. İşte test aşamasında tasarımlarımızdan beklenen şeylerden birtanesi de bu etkenlerin gereksinimlerini/ihtiyaçlarını/kritik noktalarını karşılıyor olmasıdır. Bu sebeple, bazen tasarımlarınızda atladığınız bir nokta tam da bu süreçte size revize olarak geri döner. Kimi zaman yazılım tarafında kimi zaman kullanıcılarınızın ihtiyaçları tarafında, kimi zamanda görsel tarafta yanlışlar yapabilirsiniz. Mühim olan bunları test aşamasında tespit edip, fixleyebiliyor olmanızda.
Ayrıca, test bazen ekip içerisinde dışarı çıkabilir, çıkmalıdır da. Bazen yaptığınız tasarımların, oluşturduğunuz deneyimin, flowun, logic’in çalışıp çalışmayacağını canlı olarak test etmeniz gerekebilir. Ki bu bana kalırsa, doğru hedef kitle üzerinde yapıldığı zaman size en sağlıklı geri dönüşü verecek yöntemdir. Her zaman buna imkanınız, vaktiniz veyahut bütçeniz olmayabilir ama imkan buldukça gerek çeşitli dijital servisler aracılığı ile, gerek direkt olarak kendi kullanıcılarınız üzerinde yapmanızı tavsiye edebilirim. Yine bu konunun da detayları ayrı bir yazıda ele alınmalıdır.
Biz Socio’da, bu süreci en kısa haliyle şu şekilde açıklıyoruz;
Once the task is in “Ready to Test”, the Product Manager and Lead Designer goes through the entire Zeplin and creates all the feedback. 🚨 We keep all the feedback in Zeplin to streamline the process.
The Product Manager and the Lead Designer works together until all feedback is resolved and the product is ready for the handoff. The Product Manager approves the task as a whole.
Ready to Release (Hazır!)
Ve hazırız!
Bize atanan görevi lâyıkıyla tamamladık, revizeleriyle iyisiyle kötüsüyle bir görev sürecinin daha sonuna geldik. Peki şimdi ne olacak? Her şey bitti mi? Tabiki hayır :)
Bize gelirken nasıl her detayını beklediğimiz, dökümantasyonunu istediğimiz bu işi, yazılım geliştirme ekibine teslim ederken de aynı özenle teslim etmeliyiz.
Tasarım dosyamızın kendi içerisinde ki düzeni bir kenara dursun, teslim sürecinde açıklamamız gereken noktaları bir bir handoff için kullandığımız sistemde belirtmeliyiz.
Biz Socio’da, handoff sürecinde Zeplin kullanıyoruz. Tasarımlar Test aşamasına geldiği andan itibaren Zeplin’de bulunuyorlar. Fakat yazılım geliştirme ekibi ile ancak tamamen hazır olduğunda paylaşılıyorlar. Bu sayede, hem ekranlar üzerinde Zeplin’in harikulade not özelliği ile notlar alabiliyor, tartışabiliyor, feedbackler toplayabiliyoruz; hem de yazılım ekibine teslim ederken görevin tamamını burada dökümante edebiliyoruz.
Ayrıca, şirketteki herkes yapılan işleri görebilsin ve flowlara hakim olabilsin diye işlerimizin tamamının userflow prototiplerini MarvelApp’te de sunuyoruz.
Son olarak, bütün bu servislerin erişim linklerini JIRA’daki ilgili göreve ekleyip handoff sürecini de başarıyla tamamlamış oluyoruz.
Yazdığım Diğer Yazılar
Öncelikle, çok değerli görüşlerinizi ve eleştirilerinizi bekliyorum. İlla ki yazarken atladığım, yazıya hazırlanırken unuttuğum şeyler olabilir. Hata yapabiliyoruz, insanız. :)
Son olarak şunu eklemeliyim, her ne kadar yazının içerisinde aktaramamış olsam da bir alt metin eklemek isterim ki o da:
Tasarımcılarda yanlış yapabilir, tasarımlar’da bug’lı olabilir. Mühim olan bunların er ya da geç farkedilip fix’lenmesidir. Biz bu süreci birebir belki fazlası belki eksiğiyle Socio’da uyguluyoruz, uygulamaya çalışıyoruz. Şimdilik epey memnunuz, tavsiye ederiz.
Ha unutmadan, bu yazı da bana eşlik eden playlisti paylaşmak isterim.
Kalın sağlıcakla!
