Design Talks: InVision의 Aarron Walter와의 더 나은 디자이너 및 개발자 협업

전 세계에서 디자인에 종사하는 선구자 및 최고의 사람들의 통찰력을 공유하는 데 전념하는 Design Talks 시리즈에 오신 것을 환영합니다. 우리는 다양한 맥락, 다양한 목표, 다양한 접근 방식을 통해 디자인 작업을 하는 전문가들을 인터뷰합니다. 이 시리즈에서 우리는 모든 독자들에게 지적이고 창의적인 영감을 제공하기를 희망합니다.

디자이너는 종종 개발자와 작업하는 데 어려움을 겪으며 그 반대의 경우도 마찬가지입니다. 양측의 팀은 서로에게서 엄청난 양을 배울 수 있지만 저항의 층이 남아 있습니다. 이번 주 게스트는 InVision의 디자인 교육 담당 부사장인 Aarron Walter입니다. 우리는 디자이너와 개발자의 협업에 대해 이야기할 것입니다.

Aarron은 15년 간의 제품 팀 운영 경험과 디자인 교육을 통해 기업이 디자인 모범 사례를 제정할 수 있도록 지원합니다. 그는 MailChimp에서 UX 프랙티스를 설립하고 수천 명의 사용자에서 천만 명 이상의 사용자로 제품을 성장시키는 데 도움을 주었습니다.

그의 디자인 지도는 백악관, 미 국무부, 수십 개의 주요 기업, 신생 기업 및 벤처 자본가 기업을 도왔습니다. 그는 A Book Apart에서 가장 많이 팔린 책 Designing for Emotion의 저자입니다. Twitter에서 @aarron이 디자인에 대한 생각을 공유하는 것을 볼 수 있으며 Aarronwalter.com에서 Aarron에 대해 자세히 알아볼 수 있습니다.

On The Design Better 팟캐스트 진행자 Aarron Walter와 Eli Woolery는 문제 해결 방법과 경력 경로에 대한 이야기를 공유하는 디자인 리더와 영향력 있는 사람들을 인터뷰합니다. 게스트로는 David Kelley(IDEO 공동 설립자이자 Stanford d.school 설립자), Julie Zhuo(Facebook의 제품 및 디자인 부사장), Jake Knapp(Sprint의 베스트셀러 작가) 등이 있습니다.

안녕하세요, Aarron, Toptal 디자인 블로그에 오신 것을 환영합니다. 화성의 개발자와 금성의 디자이너입니까?

내 경험에 따르면 디자이너와 개발자는 생각보다 공통점이 더 많을 수 있지만 사물에 대해 생각하는 방식에는 분명히 몇 가지 뚜렷한 차이점이 있습니다. 디자이너는 디자인 시스템에 대해 생각하는 것을 좋아하고 개발자는 유지 관리하기 쉬운 모듈식 코드에 대해 생각합니다. 그러나 우리가 그것에 대해 가는 방식은 약간 다를 수 있습니다.

개발자는 작업을 더 작은 조각으로 나누는 방법을 찾았고 디자이너는 전체를 "전체 케이크"로 생각하고 전체 케이크를 먹는 방법을 생각하는 경향이 있습니다.

이것은 그들이 머리를 맞대기 시작하는 지점입니다. 엔지니어는 코드를 작은 단계로 제공하고 Agile 방법론의 일부로 매우 빠르게 무언가를 만들 수 있기를 원합니다. 디자이너는 일관된 경험을 제공하기를 원하며 전체적인 방식으로 큰 발전을 이루고자 하는 경향이 있습니다. 이것이 이 두 그룹의 논쟁점이 될 수 있습니다.

디자이너가 개발자를 우리의 관점으로 조금 더 끌어들이기 위해 무엇을 할 수 있습니까? 디자이너는 제공되는 모든 작은 기능이 경험에 관한 것임을 어떻게 개발자에게 이해시키나요?

여기에서 양측이 구부릴 수 있는 기회가 있습니다. 디자이너는 때때로 개발자에게 모든 것을 기다렸다가 구축한 다음 이 아름답고 완전한 경험을 제공해야 한다고 확신시키려고 합니다.

그러나 생성 주기가 너무 길면 제품이 죽을 위험이 있습니다. 사람들은 흥미를 잃기 시작합니다. 그들은 이렇게 말할 수 있습니다. “이것이 실제로 비즈니스에 가치를 창출합니까? 우리는 이 일에 엄청난 시간과 에너지와 자원을 소비하고 있는데 왜 그렇게 오래 걸리나요?” 디자이너는 비즈니스 주기에 대해 더 많이 생각할 필요가 있습니다.

Apple에서 전화(문제가 있는 하드웨어)를 배송하면 잠재적으로 수십억 달러의 비용이 들 수 있지만 소프트웨어가 배송되고 문제가 있는 경우 패치하고 수정한 다음 다시 배송할 수 있습니다. 이러한 방식으로 프로세스에 접근하면 개발 작업 주기에 더 우아하게 다시 연결할 수 있습니다.

설계자는 초기에 설계 프로세스에 엔지니어를 참여시켜 두 그룹 간의 격차를 해소하여 다운스트림뿐만 아니라 초기 아이디어 단계에 포함된 느낌을 받을 수도 있습니다. 디자이너는 "우리가 이 기발한 아이디어를 생각해 냈으니 우리를 위해 만들어 보세요!"라고 말할 수 있습니다. 그리고 그것은 개발자들이 자신이 관념화 과정의 일부가 아니라고 느끼게 만듭니다. 그들은 단지 손이고 다른 누군가는 두뇌입니다.

디자이너와 개발자 사이의 가장 역기능적인 관계는 뚜렷한 분업이 있을 때 발생합니다. 혼합이 시작되고 해당 팀이 함께 작업할수록 더 좋습니다. 결과적으로 디자이너와 개발자가 효과적으로 협력하는 데 정말 중요한 여러 관점과 공유 소유권이 있습니다.

서로의 공간을 더 잘 이해하기 위해…

팀이 서로의 공간을 더 잘 이해하기 위해 무엇을 할 수 있습니까? 디자이너가 개발에 익숙해져야 합니까? 그 반대도 마찬가지입니까?

첫째, 디자이너와 개발자는 고객과 더 많은 대화를 나누고 문제 영역에 대해 함께 배울 수 있습니다. 그들은 아침에 커피를 마시며 서너 명의 고객과 이야기할 수 있었습니다. 모두가 매우 빠르게 배우고 우려 사항이 무엇인지에 대한 공통된 이해에 도달할 수 있습니다.

둘째, 작업 프로세스의 측면에서 디자이너와 개발자가 서로의 언어에 대해 유창하지는 않지만 어느 정도 이해하는 것이 중요합니다. 디자이너가 코딩 방법을 알아야 한다거나 개발자가 타이포그래피를 마스터해야 한다는 의미는 아니지만 적어도 공유된 이해는 있습니다.

디자이너가 개발자가 이해할 수 있는 언어로 구성할 수 있다면("이런 일이 작동하지 않고 비즈니스에 좋지 않습니다.") 개발자는 빠르게 문제를 이해하게 될 것입니다. 이것은 디자이너에게 자연스럽게 오는 것이 아니지만 질적 으로 뿐만 아니라 양적 으로도 작업의 가치를 더 잘 전달할 필요가 있습니다. 영업 팀, 마케팅 팀, 엔지니어링, 제품, 경영진, 그 모든 사람들은 숫자로 말하고 양적 으로 말하고 있습니다.

그렇긴 하지만, 저는 디자인이 매우 가치 있는 무언가를 가져다준다고 믿습니다. 셀 수 없는 것들이 있다는 것입니다. 고객 경험, 기쁨, 제품에 대한 사랑은 매우 가치가 있으며 수량화하기 어렵습니다.

품질 구성 요소가 수량화할 수 있는 ROI를 가져올 것이라는 선을 따라 수량화할 수 있습니다.

예, 설계를 통해 고객 지원 비용을 절감하고 고객 이탈을 줄이고 온보딩 속도를 높일 수 있습니다. 이러한 메트릭을 통해 목표를 설정하면 디자인에서 비즈니스 목표에 맞게 노력을 조정하는 데 도움이 됩니다. 디자이너가 더 많이 할 수 있을수록 더 많이 이해될 것입니다. 그 디자인이 회사에서 경쟁 우위로 더 많이 평가될수록 더 많은 투자에 대한 가능성이 커질 것입니다.

디자이너와 개발자 협업의 함정…

디자이너와 개발자가 함께 작업하는 가장 큰 함정은 무엇입니까?

가장 큰 함정 중 하나는 언어를 공유하지 않고, 목표를 공유하지 않고, 비율이 매우 불균형하다는 것입니다. 때로는 한 명의 디자이너와 75명의 엔지니어로 구성된 다기능 팀이 있습니다. 미친 소리 같지만 꽤 흔한 일입니다.

이러한 상황의 대부분은 좋지 않습니다. 그 고독한 디자이너는 외국인입니다. 그들은 문화에 완전히 적응하지 못한 낯선 땅에서 이방인이고… 그들의 가치 체계는 모든 동료의 가치 체계와 다릅니다.

그런 환경에서 UX 기능에 대한 사례를 만드는 것은 디자이너에게 매우 어려운 일입니다. "더 매력적인 경험을 만들 것이기 ​​때문에 이 애니메이션을 제품에 포함해야 합니다..."라고 말하는 75명의 엔지니어가 있을 때: "250개가 더 있습니다. 코드 줄과 2일의 추가 작업. 정말 그럴만한 가치가 있습니까?” 그리고 아마 아닐 것입니다. 그들에게 그것은 "설탕"처럼 보일 것입니다. 그러나 UX 디자이너에 대한 애니메이션화된 마이크로 인터랙션은 실제로 고객 경험을 형성합니다. 그것들이 전부는 아니지만 중요합니다.

디자이너와 개발자 간의 비율이 고르지 않으면 정말 문제가 됩니다. 그러나 해결책이 있습니다. Slack과 같은 회사는 "페어링 디자인"으로 이 문제를 해결합니다. 한 팀에 1명의 디자이너와 10명의 엔지니어가 있고 다른 팀에는 같은 비율이 있는 경우 솔로 디자이너는 일주일에 약 8시간을 함께 작업하면서 서로에게 솔루션을 제시합니다. “이 문제를 해결하는 방법은 다음과 같습니다. 당신에게 의미가? 이 작업을 수행하는 더 좋은 방법이 있습니까?” 그들은 서로를 도울 수 있고 그들이 섬에 있다는 느낌이 들지 않습니다.

UX의 중요성을 전하는 디자이너에 대하여…

HCD를 제대로 이해하지 못하는 개발자에게 디자이너가 인간 중심 디자인의 중요성을 어떻게 강조할 수 있을까요? 예를 들어, 디자이너는 기능을 추가하는 것이 반드시 고객에게 도움이 되는 것은 아니며 제품 사용 경험이 기능보다 더 중요하다는 것을 어떻게 전달합니까?

몇 가지 효과적인 방법이 있습니다. 대부분의 디자이너는 개발자에게 다음과 같이 직접 말함으로써 비효율적인 방식으로 작업을 수행했을 것입니다. 사람들은 그것을 원한다고 말하지만 실제로는 제품을 더 복잡하게 만들 뿐입니다.”라고 개발자들은 다음과 같이 대답할 가능성이 높습니다. 우리는 고객들로부터 이것을 듣고 있으므로 그들을 따라야 합니다.”

정면으로 맞서지 말고 옆으로 가다가 "문제 영역을 함께 더 잘 이해합시다"라고 말하는 것이 가장 좋습니다. 나는 내일 우리를 위해 점심을 샀고 우리 제품을 사용하는 다섯 명의 고객을 보여주려고 준비했습니다.

저는 엔지니어들이 고객이 실제로 제품을 사용하는 것을 보고 자리에서 꿈틀거리며 "사용하기 꽤 어려운 것을 만들었고 사람들은 그것에 대해 좌절감을 느꼈습니다."라고 깨닫는 것을 보았습니다. 엔지니어는 디자이너와 마찬가지로 훌륭한 작업을 수행하기를 원합니다. 종종 그들은 단순히 작업의 결과를 볼 기회가 없습니다.

당신은 아마도 우리가 "결과가 아니라 결과"에 초점을 맞춰야 한다는 Jeff Golf의 설교를 들어보았을 것입니다. 그것은 우리가 생각을 재구성할 수 있는 또 다른 방법입니다. 결과 는 "5가지 기능을 더 출시했습니다."와 결과 는 "우리는 이탈률을 10% 줄였습니다."입니다.

디자이너와 개발자 협업의 미래에 대해…

많은 회사와 이야기하고 많은 디자인 및 개발자 팀이 함께 일하는 것을 봅니다. 도구, 환경 및 방법론이 변화하고 있습니다. 디자이너/개발자 관계의 미래는 어떻게 될까요?

바닷물과 민물이 섞일 때 기수(brackish water)가 발생하고 엔지니어링 및 설계 도구가 결합됩니다. 디자인의 모든 것이 여기에 있고 엔지니어링의 모든 것이 저쪽에 있는 핸드오프처럼 느껴지는 프로세스 대신, 그들은 함께 혼합되기 시작합니다.

그만큼 디자이너들이 Jira에서 많은 시간을 보내고 사용자 스토리를 생각하며 엔지니어링 사고 방식으로 생각하기 시작하는 것을 볼 수 있습니다. 그 반대의 경우도 엔지니어들은 InVision Inspect와 같은 도구를 사용하여 사양과 설계 시스템의 세부 사항을 확인하고 이 모든 것이 어떻게 조화를 이루는지 구성 요소를 이해하고 있습니다. 이러한 도구와 학문의 혼합으로 인해 공유된 이해가 발전하고 있습니다.

개발자든 디자이너든 핵심 파트너의 관점을 이해하기 시작할 수 있습니다. 디자이너로서 전문 코더여야 한다는 의미는 아닙니다. 그러나 Git을 사용하는 방법과 HTML과 CSS를 작성하는 방법, JavaScript를 조금이라도 안다면 디자이너를 죽이지는 않을 것입니다. 이는 실제로 디자이너가 사물이 어떻게 구축되는지 이해하고 더 나은 디자이너와 개발자 협업을 촉진하는 데 도움이 될 것입니다.

Toptal Design 블로그에 대한 추가 정보:

• 개발자를 위한 디자인 접근 방법
• Design Talks: UX 연구원 Caitria O'Neill과 함께 하는 연구
• Design Talks: Pamela Pavliskak과 함께하는 감성 지능 디자인
• 디자인 토크: Nick Disabato와 함께하는 가치 기반 디자인 추구
• UX 디자이너에서 UX 컨설턴트로 전환하는 방법