Tasarım Sohbetleri: InVision'dan Aaron Walter ile Daha İyi Tasarımcı ve Geliştirici İşbirliği

Dünyanın dört bir yanından tasarımla uğraşan düşünce liderlerinin ve üst düzey kişilerin görüşlerini paylaşmaya adanmış Tasarım Sohbetleri serimize hoş geldiniz. Tasarımla farklı bağlamlarda, farklı amaçlarla ve farklı yaklaşımlarla çalışan uzmanlarla görüşüyoruz. Bu seride, tüm okuyucularımıza entelektüel ve yaratıcı ilham vermeyi umuyoruz.

Tasarımcılar genellikle geliştiricilerle çalışmakta zorlanır ve bunun tersi de geçerlidir. Her iki taraftaki takımlar birbirlerinden çok şey öğrenebilirler, ancak direnç katmanları devam ediyor. Bu haftanın konuğu InVision Tasarım Eğitimi Başkan Yardımcısı Aaron Walter ve tasarımcı ve geliştirici işbirliği hakkında konuşacağız.

Aaron, şirketlerin en iyi tasarım uygulamalarını hayata geçirmelerine yardımcı olmak için ürün ekipleri çalıştırma ve tasarım öğretme konusundaki 15 yıllık deneyiminden yararlanıyor. MailChimp'te UX uygulamasını kurdu ve ürünün birkaç bin kullanıcıdan 10 milyonun üzerine çıkmasına yardımcı oldu.

Tasarım rehberliği Beyaz Saray'a, ABD Dışişleri Bakanlığı'na ve düzinelerce büyük şirkete, girişime ve risk sermayedarı firmasına yardımcı oldu. A Book Apart'tan en çok satan Designing for Emotion kitabının yazarıdır. @aarron'u Twitter'da tasarım üzerine düşüncelerini paylaşırken bulacaksınız ve aarronwalter.com adresinde Aarron hakkında daha fazla bilgi edinebilirsiniz.

Design Better Podcast'inde, Aaron Walter ve Eli Woolery, sorunları nasıl çözdüklerine ve kariyer yollarına dair hikayelerini paylaşan tasarım liderleri ve etkileyici kişilerle röportaj yapıyor. Davetliler arasında David Kelley (IDEO kurucu ortağı ve Stanford d.school kurucusu), Julie Zhuo (Facebook Ürün ve Tasarım Başkan Yardımcısı) ve Jake Knapp (Sprint'in en çok satan yazarı) yer alıyor.

Merhaba Aaron, sizi Toptal Design Blog'da görmek bir zevk. Geliştiriciler Mars'tan ve tasarımcılar Venüs'ten mi?

Tecrübelerime göre, tasarımcılar ve geliştiriciler muhtemelen fark ettiklerinden daha fazla ortak noktaya sahiptir, ancak şeyler hakkında düşünme şeklimizde kesinlikle bazı belirgin farklılıklar vardır. Tasarımcılar, tasarım sistemleri hakkında düşünmeyi severler ve geliştiriciler, bakımı kolay modüler kodu düşünürler. Ancak bu konuda izleyeceğimiz yol biraz farklı olabilir.

Geliştiriciler işlerini daha küçük parçalara ayırmanın yollarını bulmuşlar ve tasarımcılar her şeyi "bütün pasta" olarak düşünmeye eğilimlidirler ve pastanın tamamını nasıl yeriz.

Bu, kafa patlatmaya başladıkları bir noktadır. Mühendisler, Çevik metodolojinin bir parçası olarak kodu küçük adımlarla gönderebilmek ve çok hızlı bir şekilde bir şeyler yapabilmek istiyor. Tasarımcılar, bütünsel bir şekilde ileriye doğru büyük bir adım atmak isteme eğilimindedir - tutarlı bir deneyim sunmak isterler. Bu, bu iki grup için bir çekişme noktası olabilir.

Tasarımcılar, geliştiricileri biraz bizim bakış açımıza getirmek için ne yapabilir? Tasarımcılar, geliştiricilerin, gönderilen her küçük özelliğin aynı zamanda deneyimle ilgili olduğunu anlamalarını nasıl sağlar?

Burada iki tarafın da eğilmesi için bir fırsat var. Tasarımcılar bazen bir geliştiriciyi bekleyip her şeyi inşa etmemiz ve ardından bu güzel, eksiksiz deneyim olarak kapıdan çıkarmamız gerektiğine ikna etmeye çalışıyorlar.

Ancak oluşturma döngüsü çok uzunsa, ürünler öldürülme riski taşır. İnsanlar ilgisini kaybetmeye başlar. Şöyle diyebilirler: “Bu gerçekten işletme için değer yaratıyor mu? Bu şeye tonlarca zaman, enerji ve kaynak harcıyoruz, neden bu kadar uzun sürüyor?” Tasarımcıların iş döngüsü hakkında daha fazla düşünmesi gerekiyor.

Apple bir telefonu (sorunlu bir donanım) gönderirse, bu onlara potansiyel olarak milyarlarca dolara mal olabilir, ancak yazılım gönderilirse ve bir sorun varsa, onu yamalayabilir, düzeltebilir ve yeniden gönderebiliriz. Sürece bu şekilde yaklaşmak, geliştirme iş döngüsüne daha zarif bir şekilde bağlanmamızı sağlar.

Tasarımcılar ayrıca mühendisleri tasarım sürecine erken dahil ederek iki grup arasındaki boşluğu kapatmaya çalışabilirler, böylece sadece aşağı yönde değil, erken fikir aşamasına dahil edilmiş hissedebilirler. Tasarımcılar şöyle diyebilir: “Bu parlak fikri biz bulduk, gidin bizim için yapın!” ve bu, geliştiricilere fikir oluşturma sürecinin bir parçası olmadıklarını hissettirir. Onlar sadece eller ve bir başkası beyin.

Tasarımcılar ve geliştiriciler arasındaki en işlevsiz ilişki, belirgin bir iş bölümü olduğunda ortaya çıkar. Ne kadar çok karışmaya başlarsa ve bu ekipler birlikte çalışırsa o kadar iyidir. Sonuç olarak, tasarımcılar ve geliştiricilerin birlikte etkili bir şekilde çalışması için gerçekten önemli olan birden fazla bakış açısı ve paylaşılan sahiplik olacaktır.

Birbirinizin Mekânını Daha İyi Anlamak Üzerine…

Takımlar birbirlerinin alanını daha iyi anlamak için ne yapabilir? Tasarımcılar kendilerini geliştirme ile tanıştırmalı mı ve tam tersi mi?

İlk olarak, tasarımcılar ve geliştiriciler müşterilerle daha fazla konuşabilir ve problem alanı hakkında birlikte bilgi edinebilir. Sabahları kahve içerken üç ila dört müşteriyle konuşabiliyorlardı; herkes çok çabuk öğrenebilir ve endişelerin ne olduğu konusunda ortak bir anlayışa varabilir.

İkincisi, çalışma süreci açısından, tasarımcılar ve geliştiriciler için -belki akıcılık değil- ama birbirlerinin dilini biraz anlamaları önemlidir. Bir tasarımcının kodlamayı bilmesi veya geliştiricilerin tipografide ustalaşması gerektiğini söylemiyorum, ama en azından ortak bir anlayış var.

Tasarımcılar, şeyleri geliştiricilerin anlayacağı bir dilde çerçeveleyebilselerdi – “şu falanca işe yaramaz ve bu iş için kötü” – o zaman geliştiriciler sorunu anlamak için çabucak gelirlerdi. Bu, tasarımcılara doğal olarak gelen bir şey değil, ancak çalışmalarının değerini yalnızca niteliksel olarak değil, niceliksel olarak iletmede daha iyi olmaları gerekiyor. Satış ekibi, pazarlama ekibi, mühendislik, ürün, yöneticiler, tüm bu insanlar sayılarla konuşuyorlar, nicel olarak konuşuyorlar.

Bununla birlikte, tasarımın çok değerli bir şey getirdiğine inanıyorum, sayılan ve sayılamayan bazı şeyler var. Müşteri deneyimi, sevinç, ürüne duyulan sevgi çok değerli ve bunu ölçmek zor.

Ancak, kalite bileşeninin ölçülebilir bir yatırım getirisi getireceğine göre, ölçülebilir olabilir.

Evet, tasarımla müşteri destek maliyetlerini azaltabiliriz, müşteri kaybını azaltabiliriz, işe başlama hızını artırabiliriz. Hedeflerinizi belirlemek için böyle metriklere sahip olmak, tasarımın çabalarını iş hedefleriyle uyumlu hale getirmesine yardımcı olur. Tasarımcılar bunu ne kadar çok yaparsa, o kadar çok anlaşılırlar. Tasarıma şirkette rekabet avantajı olarak ne kadar değer verilirse, daha ağır yatırım potansiyeli o kadar büyüyecektir.

Tasarımcı ve Geliştirici İşbirliğinin Tuzakları Üzerine…

Birlikte çalışan tasarımcıların ve geliştiricilerin karşılaştığı en büyük tuzaklardan bazıları nelerdir?

En büyük tuzaklardan biri ortak bir dile sahip olmamak, ortak hedeflere sahip olmamak ve oranların çok orantısız olmasıdır. Bazen bir tasarımcı ve 75 mühendisten oluşan çapraz işlevli ekipler vardır. Bu çılgınca geliyor, ama oldukça yaygın.

Bu durumların büyük çoğunluğu iyi değil. Bu yalnız tasarımcı bir gurbetçi. Kültüre hiçbir zaman tam olarak uymadıkları garip bir ülkede bir yabancıdırlar… ve onların değer sistemleri tüm meslektaşlarının değer sistemlerinden farklıdır.

Bu ortamda, bir UX özelliği için bir örnek oluşturmak bir tasarımcı için son derece zordur: "Bu animasyonu üründe kullanmalıyız çünkü daha çekici bir deneyim yaratacak..." diyen 75 mühendis varken: "Bu 250 tane daha var. kod satırları ve fazladan iki günlük çalışma. Gerçekten buna değer mi?” Ve muhtemelen değil. Onlara göre, "dondurma" gibi görünecek. Ancak bir UX tasarımcısına yönelik bu hareketli mikro etkileşimler, müşteri deneyimini gerçekten şekillendiriyor. Tek şey değiller, ama önemliler.

Tasarımcılar ve geliştiriciler arasında bu eşit olmayan oranlar olduğunda, gerçekten sorunlu hale gelir. Ancak, çözümler var. Slack gibi şirketler bu sorunu “eşleştirilmiş tasarım” ile çözüyor. Bir takımda bir tasarımcıya 10 mühendis ve başka bir takımda aynı oran varsa, bu yalnız tasarımcılar haftada yaklaşık sekiz saat birlikte çalışarak birbirlerine çözümler sunarlar: “İşte bu sorunu nasıl çözüyorum, bunu yapar mı? sana mantıklı geliyor mu Bunu yapmanın daha iyi bir yolu var mı?” Birbirlerinin çözülmelerine ve kendilerini bir adada gibi hissetmemelerine yardımcı olabilirler.

UX'in Önemini Aktaran Tasarımcılar Üzerine…

Tasarımcılar, HCD'yi gerçekten anlamayan geliştiricilerle insan merkezli tasarımın önemini nasıl vurgulayabilir? Örneğin, tasarımcılar özellik eklemenin mutlaka müşteriye hizmet etmediğini, ürünü kullanma deneyiminin özelliklerinden daha önemli olduğunu nasıl ifade ediyor?

Bunu yapmanın birkaç etkili yolu vardır. Çoğu tasarımcı, geliştiricilere doğrudan şunları söyleyerek muhtemelen etkisiz bir şekilde yaptı: "Hey, daha fazla özellik eklemek daha iyi bir deneyim sağlamaz. İnsanlar bunu istediklerini söylüyorlar, ancak bu aslında ürünü daha karmaşık hale getiriyor” ve geliştiricilerin yanıt vermesi muhtemel: “Haklı olduğunu düşünmüyorum, bu bir fikir. Bunu müşterilerimizden duyuyoruz, bu yüzden onları takip etmeliyiz.”

En iyisi, onunla kafa kafaya değil, yan bir şekilde yapmak ve “Sorun alanını birlikte daha iyi anlayalım” demek. Yarın bizim için öğle yemeği aldım ve size ürünümüzü kullanan beş müşterimizi göstermeyi ayarladım.

Bir müşterinin ürünü gerçekten kullandığını gördüklerinde koltuklarında kıpırdanan mühendisler gördüm ve şunu fark ettim: "Kullanımı oldukça zor bir şey yaptık ve insanlar bundan hüsrana uğruyor." Mühendisler de tıpkı tasarımcılar gibi harika işler yapmak isterler. Çoğu zaman, çalışmalarının sonucunu görme fırsatı bulamıyorlar.

Muhtemelen Jeff Gothelf'in “çıktılara değil, sonuçlara” odaklanmamız gerektiğine dair vaazını duymuşsunuzdur. Bu, bir çıktının "beş özellik daha gönderdik" ve bir sonuç: "kullanmayı %10 oranında azalttık" olduğu şeklindeki düşüncemizi yeniden çerçevelemenin başka bir yoludur.

Tasarımcı ve Geliştirici İşbirliğinin Geleceği Üzerine…

Birçok şirketle konuşuyorsunuz ve birlikte çalışan birçok tasarım ve geliştirici ekibi görüyorsunuz. Araçlar, ortamlar ve metodolojiler değişiyor. Tasarımcı/geliştirici ilişkisini gelecekte neler bekliyor?

Gelişen acı su var - tuzlu su ve tatlı su bir araya geldiğinde - mühendislik ve tasarım araçlarının bir birleşimi var. Tasarımla ilgili her şeyin burada olduğu ve mühendislikle ilgili her şeyin orada olduğu bir devir gibi hissettiren bir süreç yerine, birbirine karışmaya başlarlar.

Bu ölçüde, tasarımcıların Jira'da çok zaman harcadıklarını, kullanıcı hikayeleri üzerinde düşündüklerini ve mühendislik zihniyetiyle de düşünmeye başladıklarını görüyoruz. Ve tam tersi, mühendislerin bir tasarım sisteminin özelliklerini ve dökümünü gördükleri InVision Inspect gibi araçları kullandıklarını ve bunların nasıl birbirine uyduğunun bileşenlerini anladığını görüyoruz. Bu araçlar ve disiplinlerin harmanlanması sayesinde ortak bir anlayış gelişiyor.

İster geliştirici ister tasarımcı olun, ana iş ortağınızın bakış açısını anlamaya başlayabilirsiniz. Bu, tasarımcı olarak uzman bir kodlayıcı olmanız gerektiği anlamına gelmez. Ancak Git'in nasıl kullanılacağını ve biraz HTML ve CSS'nin nasıl yazılacağını, belki de biraz JavaScript'in nasıl yazılacağını biraz biliyorsa, bu bir tasarımcıyı öldürmez. Bu aslında tasarımcıların işlerin nasıl inşa edildiğini anlamalarına yardımcı olacak ve daha iyi tasarımcı ve geliştirici işbirliğini teşvik edecek.

Toptal Tasarım Blogunda daha fazla okuma:

• Geliştiriciler için Tasarıma Nasıl Yaklaşılır?
• Tasarım Sohbetleri: UX Araştırmacısı Caitria O'Neill ile Eylemde Araştırma
• Tasarım Sohbetleri: Pamela Pavliscak ile Duygusal Zeki Tasarım
• Tasarım Sohbetleri: Nick Disabato ile Değere Dayalı Tasarımın Peşinde
• UX Designer'dan UX Danışmanına Nasıl Geçiş Yapılır?