Farklı Dünyaların Kesişim Noktası: Design Handoff

Malum, canı istedikçe kariyer değiştiren bir insanım. Yıllar içinde farklı işler yapmama rağmen ya yazılımcılarla beraber ya da onlar için çalıştım. Şimdiyse olmaktan korktuğum yerdeyim, onların karşısında! Tam karşısında olmasam da ilk defa dirsek dirseğe çalışıp bu kadar çok noktada tartışmamız gerekiyor. Bir tasarımcı olarak yeni yeni alışmaya başladığım bir süreçten bahsetmek istiyorum: Design Handoff!

 

En baştan başlayalım, nedir bu “Handoff”?

“Design Handoff” terimini “Tasarım Aktarımı” olarak çevirebiliriz. Hazırlanan bir tasarımın kodlanmaya hazır bir şekilde yazılımcılara iletilmesi sürecidir. Bir bayrak yarışı gibi düşünürseniz, bayrağın tasarımcıdan yazılımcıya geçeceği noktadır.

Bu sadece “Al bakalım bu tasarım hadi kodla şimdi” diyebileceğiniz bir süreç değil elbette. Öncesinde, sırasında ve sonrasında hem tasarımcıya hem de yazılımcıya bolca sorumluluk yükleyen bir süreç.

Kabaca bu süreci 3 adıma bölebiliriz: Aktarım öncesi, aktarım ve sonrası. Tasarım aktarımı öncesindeki en önemli nokta, doğru iletişim akışını sağlamak. Hem müşteri hem yazılımcı hem de proje ya da ürün yöneticisiyle doğru bir iletişim akışı sağlamalı ve kilit noktalarda el sıkışılmalı ki, sonrasında işi tekrar yapmak gibi büyük ve maliyetli sorunlar ortaya çıkmasın.

Aktarılan tasarımın müşteri tarafından da onaylanmış ve tüm parçalarıyla bitmiş bir tasarım olması önemli. Tasarım, akış ve beklentilerinizin yanı sıra prototip sunmanız da yazılımcının işini kolaylaştırır.

Aktarım sonrasında da iletişim tekrar ön plana geliyor. Hem yazılımcıya ihtiyacı olan ya da tam olarak kafasında oturmayan noktaların olup olmadığını sormak hem de kodlanan ekranlardaki uyumsuzlukları iletirken yapıcı bir şekilde yaklaşmak, sağlıklı iletişim akışını kırmamanızı sağlar.

Böyle süreci kısaca özetledikten sonra, gelelim bu adımlarda kullanabileceğiniz araçlara.

 

Hangi araçlar kullanılabilir?

Bu süreçler için ihtiyacınıza yönelik araçlar epey fazla. Gerek tasarım araçları olsun, gerek prototip araçları gerekse sadece tasarımı aktarmak için birçok araç var. Bunların hangisinin sizin için daha doğru olduğunu biraz deneyimle öğrenebilirsiniz. Herkesin kullandığı ve bayıldığı program sizin süreçleriniz için gerekli veriyi sağlamayabilir. Kullanılan birkaç araçtan bahsedeyim şimdi de.

Zeplin: Piyasadaki en bilinen tasarım aktarma araçlardan biridir. Yapılan tasarımı Zeplin’e ekran ekran yükleyerek yazılımcıya iletebilirsiniz. Figma, Sketch, Photoshop ve Adobe XD gibi tasarım programlarıyla entegre çalışıyor. Bunların yanı sıra Jira, Slack ve Trello gibi iletişim araçlarıyla da entegrasyonu var. CSS, Swift, Android ve React Native için çıktı alabileceğiniz bir bölüm var. Zeplin’i sadece müşteriler için kullanıyoruz biz. Yeni ekranları oradan kontrol ediyorlar ve böylece benim tasarım sürecindeki dağınıklığımı da görmemiş oluyorlar 🙂

Avocode: Zeplin’den çok farklı olmayan Avocode da kod ve görsel çıktısı sunabilen bir handoff aracı. Kendini Zeplin’den ayıran en önemli özelliği, Linux uygulaması olması.

InVision: Sektördeki en popüler prototipleme araçlarından biri. Sketch ve Photoshop dışında birçok araçla da entegrasyonu var. Daha çok prototipleme için kullanılsa da handoff için de yazılımcıları mutlu ediyor.

Figma: Sıra geldi benim göz bebeğime! Son kullanıcıya 2016 yılında sunulan bu taze uygulama, bu süreçte tasarımcıların ve yazılımcıların ihtiyaçlarını ve sorunlarını göz önünde bulundurarak kendini çok geliştirdi. Hem tasarımı yapıp hem bunlarla prototipleri hazırlayıp sonunda da yazılımcıların istediği bilgileri sunan çıktıları bulabileceğiniz Figma, tam bir “All-in-one” uygulama. Tarayıcı desteği olması sayesinde de her bilgisayarda rahatlıkla kullanılıyor. Plugin desteği sayesinde de birçok araçla entegrasyonu var. Ayrıca içeride çalışırken ihtiyaç duyulabilecek çeşitli ek problemlere de eklentilerle çözüm sunuyor.

Adobe XD: Adından da anlaşılacağı gibi Adobe tarafından kullanıma sunulan bu tasarım aracı da Figma gibi tasarım, prototip ve handoff süreçlerinde kullanılabiliyor.

 

Farklı dünyaların insanlarıyız!

Tasarımcılar ve yazılımcılar farklı düşünce yapılarına sahip insanlardır. Bunu baştan kabul etmek lazım. Yazılarla ve çizimlerle dolu bir defter sayfasına baktığında biri görselleri ve yazıları nasıl yan yana yerleştireceğini, H1 H2 değerlerini, animasyon eklenmesi gerekirse lazım olan kodları düşünür. Diğeriyse sayır arası boşlukları, sayfanın çizgilerinin kalınlıklarını ve yazının kalınlığı ve yapısı ile uyumunu, görsellerin orantılı ve akışkan bir şekilde yerleşimini ve sayfadaki renkleri düşünür.

Bunu kabul ettikten sonra doğru bir iletişim noktası bulabiliriz. Bu işlerle uzaktan yakından ilişkiniz varsa “Frontendci ev ikonuma baca eklemiş!” diye yakınan tasarımcı ya da “Bu şekilde kodlanabilir bu, öyle istediği gibi akamaz” diyen yazılımcı görmüşsünüzdür. Eskiden bu tarz şeylere güler geçerdim ama başıma gelince ne hissettiklerini çok iyi anladım. Arada sırada içimden “Ben hayallerimi, umutlarımı ve penguenlerin üşümemesi için planlarımı iletmiyorum, olması gereken tasarımı iletiyorum!” diye çemkirsem de, gördüğüm farklılıkları elimden geldiğince sakin ve açık bir şekilde iletiyorum. Olması gereken de bu sonuçta. “Taslaklarınız yeterince taslak değil” diye bir tasarımcıdan revizyon duymuş biri olarak, neyi nasıl anlattığımızın önemli olduğunu bilmemiz gerekiyor.

 

Her şeyin başı iletişim

İstediğiniz kadar mükemmel bir tasarım hazırlamış olun, onu doğru anlatamadıktan sonra canlıda görmek bile istemeyeceğiniz bir halde karşınıza çıkacaktır.

Eski bir firmamda yöneticilerden birinden bir hata bilgisi geldi, “Mobilde filtre çalışmıyor” diyordu. Hepimiz hem bilgisayarda mobil boyutlarda hem de telefonlarımızda denedik ve herhangi bir sıkıntı yoktu. Aradık taradık yok, çıkmıyor herhangi bir sorun. En son kendisinden ekran görüntüsü istedik. Meğerse o ekran boyutunda, en alttaki buton sığmadığı ve dolayısıyla ona basamadığı için işlem yapamıyormuş. Doğru geri bildirim “Şu telefondan bu tarayıcıdan, ürün filtreleme kısmında alttaki düğme görüntülenemiyor” olabilirdi mesela. Böylece yazılımcı da tam olarak nerede ne araması gerektiğini bilir, ilk örnekle saatlerini harcayacağına kodun ilgili kısmında 10 dakikada çözümü canlıya almış olurdu.

Sosyal bilimlerde deney ve araştırma yapacaksanız, öncelikle “Operational Definition” kavramıyla yüzleşmeniz gerekir.  İşlemsel Tanım olarak dilimize çevirebiliriz. Soyut bir kavramı somut bir yoldan tanımlamak amacıyla yöntemsel bir işlemin kullanılması; kavramların, araştırmada nesnel olarak ölçülebilir değişkenler olarak ifade edilmesi şeklinde tanımlanır.* Örneğin “kaygı” doğrudan ölçülebilir bir değişken olmadığı için, kalp atışı, bir testte alınan puan vb. şekillerde tanımlanır. Bir başka örnek olarak “Müziğin insan psikolojisine etkisi” diye bir tanım herkese farklı şeyi ifade eder. Müzik diyerek neyi tanımlıyor, psikoloji olarak neyi tanımlıyor, değişimi neyle ölçüyor asıl önemli olan noktalar. Bu araştırmanın tanımı yaklaşık bir paragraf ve 3-4 cümle sürecektir emin olun. Ben yaptım oradan biliyorum! Bu şekilde bir tanım hazırlamanın sonucu olarak neyi araştırdığımı net bir şekilde ifade edebildiğim için herkes net bir şekilde anlar ve araştırmanın sonuçları da daha net bir şekilde kendini gösterir.

Tasarımcı, yazılımcı, ürün yöneticisi ve müşteri tarafındaki ilgili kişiler bambaşka insanlar ve olaylara mesleki olarak farklı yaklaşımları olan kişiler. Akıcı ve sorunsuz bir iletişim için olabildiğince çok veri içeren bir şekilde iletişim kurmamız önemli. Bu sebepten “Operational Definition” kavramını gerekirse bir süre hep beraber çalışın. Ortak noktaya ulaşabilirseniz süreçler de akıcı bir şekilde devam eder.

 

Peki, gerçek dünya nasıl?

Açık konuşayım, bu yazdığım kadar mükemmel handoff süreçlerim olduğunu hâlâ düşünmüyorum. Birçok farklı projeye ve farklı işlere baktığım için süreçte dağılıp atladığım şeyler oluyor. “Happy flow” dediğimiz, her şeyin mükemmel işlediği akışın dışında bir hata ekranını benden ilk seferde alıyorlarsa kendilerini şanslı hissediyorlar mesela :).

Teknik ekiple bunları çözebileceğimize olan güvenin sebebi, sanırım iletişim noktalarımızı düzgün ve olabildiğince rahat olacağımız şekilde kurabilmiş olmamız. Bir işi ya da ekranı teslim ettikten sonraki Slack mesajlarımız genelde şu şekilde devam ediyor:

• Gizem bu düğmenin basıldığındaki hali yok
• Ayyy, unuttum, pardon, 3 dakika….
• (7 dakika sonra) Component sayfasında ilgili bölümün en altına ekledim
• Denk yu!

 

• Gizem yaa, burada mail adresi yoksa ne olacak?
• :face_palm: 4 dakika…
• (15 dakika sonra) Yanına hata durumunu ekledim.
• Eyv bro!

Elimden geldiği kadar tasarımların yanında küçük notlarla süreci daha detaylı anlatmaya çalışıyorum. Öte yandan bir ürün sattığımız için her ne kadar tasarımlar değişse de akış çok değişmiyor. Ben de bir yazılımcıyla bir proje tasarladıktan sonra bunlara dikkat etmemeye başlıyorum. Bunun sonucu olarak da arada yazılımcı değişiyorsa akışı anlamamasına sebep oluyor ve tekrar uğraşıyoruz.

 

Handoff handoff dediğin nedir ki gülüm!

Hadi yine açık konuşayım, oradaki 3-4 dakikalar genelde “Bunu yarın versem olur mu?” “Çok mu acilmiş?” gibi sorularla daha sonra bakacağım bir Linear görevine dönüşüyor. Çoğu iş de maalesef ki “acil” olduğu için bazen de “Ya Tolga, şu sayfadaki hata mesajı aynı yazı biçimi ve aynı boşluklarla çıkacak, oradan alırsın sen yaa, bi tanesin sen!” noktasına varmıyor değil…

İşin özüne gelirsek, doğru bir iletişim yapısı kurduğunuzda, aslında işin %70’i bitmiş oluyor. Düzgün bir iletişim akışı sizin sadece handoff süreçlerinizde değil, hangi departmanla ne işi yaparsanız yapın hayat kurtarıcınız olacaktır. Bu anlattıklarımı sadece tasarımcılara yazılmış olarak saymayın. Aynı şey sizin için de geçerli sevgili Frontend Developer arkadaşlar! :).

Buraya kadar bayılmadıysanız size bir de “Design tokens” anlatmak isterdim. O da başka bir yazıya kalsın!

 

* Psikoloji Sözlüğü, S. Budak