프론트엔드 개발자가 디자이너의 작업을 강화하는 방법

이 기사는 주로 사용자 인터페이스 구현을 즐기지만 함께 작업하는 디자이너와 기대치를 맞추는 데 어려움을 겪고 있는 친애하는 프론트엔드 개발자를 대상으로 합니다. 아마도 당신을 "UI 개발자" 또는 "UX 엔지니어"라고 부를 것입니다. 당신이 가지고 다니는 제목에 관계없이 당신의 직업(그리고 내 직업)은 디자인 파일에 생명을 불어넣는 것 이상으로 구성됩니다. 우리는 또한 디자인과 개발 워크플로 사이의 간격을 메울 책임이 있습니다. 그러나 그 다리를 건너면서 우리는 여러 가지 어려움에 직면하게 됩니다.

오늘 저는 지난 몇 년 동안 디자이너와 보다 효율적으로 협업하는 데 도움이 된 실용적인 팁을 공유하고자 합니다.

저는 UI 개발자로서 디자이너가 웹이 작동하는 방식을 배우는 여정에서 디자이너를 도울 뿐만 아니라 현실을 알고 언어를 배우는 것이 우리의 일이라고 믿습니다.

UX 디자이너의 배경 이해하기

대부분의 UX 디자이너(웹 디자이너 또는 제품 디자이너라고도 함)는 Photoshop 및 Illustrator와 같은 도구를 통해 디자인 세계에 첫 발을 내디뎠습니다. 아마도 그들은 그래픽 디자이너 였을 것입니다. 그들의 주요 목표는 로고와 브랜드 아이덴티티를 만들고 잡지의 레이아웃을 디자인하는 것이었습니다. 그들은 또한 광고판 인쇄, 배너 디자인 및 인포그래픽 제작과 같은 마케팅 디자이너 일 수도 있습니다.

즉, 대부분의 UX 디자이너는 초기에 인쇄를 위해 디자인했는데, 이는 현재의 매체인 화면과는 완전히 다른 패러다임입니다. 그것이 그들의 첫 번째 큰 도전이었습니다. 인쇄를 다룰 때 디자이너는 픽셀 정렬에 신경을 썼지만 고정된 영역(종이)에 신경을 썼습니다. 그들은 동적 레이아웃(화면)과 씨름할 필요가 없었습니다. 텍스트 나누기 또는 상호 작용 상태에 대해 생각하는 것도 단순히 그들의 작업의 일부가 아니었습니다. 또한 디자이너는 성능 제약 없이 색상, 이미지 및 타이포그래피에 대해 완전한 자유를 누렸습니다.

다행스럽게도 독학 UX 디자이너 커뮤니티에서 개발 기본 사항을 가르치고 디자이너가 코딩을 배워야 하는지 여부를 논의하고 개발자에게 가장 잘 전달하는 방법을 이해하기 위한 많은 노력이 있었습니다. 개발 측면에서도 마찬가지였습니다(자세한 내용은 잠시 후). 그러나 여전히 두 분야 사이에 마찰이 일어나고 있습니다.

한편으로 디자이너들은 구현이 자신의 디자인과 일치하지 않을 때마다 불평하거나 명확한 설명 없이 개발자가 거부할 때 오해를 받는다고 불평합니다. 반면에 개발자는 사실이 아닐 수 있지만 디자이너가 기술적인 것을 알고 있다고 당연하게 여길 수 있습니다. 나는 우리 모두가 그보다 더 잘할 수 있다고 믿습니다.

새로운 사고 방식 수용

우리가 구축하고 있는 웹사이트와 앱은 다양한 화면 크기에 표시됩니다. 각 사람은 여러 장치에서 사용합니다. 우리의 공통 목표는 여정 전반에 걸쳐 친숙한 경험을 만드는 것입니다.

개발자로서 디자이너가 픽셀 정렬에 대해 까다롭다고 생각할 때 그 이유를 이해해야 합니다. 우리는 그것이 충실도와 일관성을 넘어서는 것임을 인식해야 합니다. 그것은 함께 작동하는 모든 부분의 합에 관한 것입니다. 응집력입니다. 우리는 그것을 포용하고 그것을 달성하기 위해 최선을 다해야 합니다. 디자인 원칙의 기초를 배우는 것은 좋은 출발점입니다 . 올바른 색상 선택의 중요성, 계층 구조가 작동하는 방식 및 공백이 중요한 이유를 이해합니다.

참고 : "개발자를 위한 디자인"이라는 온라인 과정과 "리팩토링 UI"라는 책이 있습니다. 둘 다 시작하기에 좋습니다. 이를 통해 세부 사항에 대한 날카로운 눈으로 사용자 인터페이스를 구현할 수 있고 디자이너와 의사 소통할 때 상당한 영향력을 얻을 수 있습니다.

디자이너의 인지도 확대

디자이너도 당신만큼 웹을 알고 있다는 사실을 당연하게 여길 수 있습니다. 글쎄, 그들은 그렇지 않을 수도 있습니다. 사실, 그들은 할 필요가 없습니다! 웹의 현재 상태를 최신 상태로 유지하는 것은 개발자로서 우리의 책임입니다.

저는 이 스펙트럼의 두 가지 측면에서 작업했습니다. 브라우저 호환성을 고려하지 않고 무엇이든 구축할 수 있다고 생각하는 디자이너(복잡한 필터, 새로운 스크롤 동작 또는 사용자 정의 양식 입력 등). 그러다가 '웹의 낮은 한계'를 전제로 하고 스스로 구현이 불가능하다고 생각하는 디자이너가 있습니다. 우리 는 그들에게 웹 디자인의 진정한 가능성을 보여주고 그들의 기술을 제한하지 않도록 해야 합니다.

코딩 방법이 아니라 코딩을 가르쳐라

이것은 모순되는 것처럼 보이지만 저를 참고하십시오. 코딩 방법을 아는 것은 개발자 작업의 핵심입니다. 우리는 매일 새로운 것들이 쏟아져 나오는 빠르게 변화하는 업계에서 일하고 있습니다. 디자이너에게 코딩 방법을 배우도록 요구하는 것은 위선적인 요청일 것입니다. 그러나 우리는 그들이 코드를 이해 하도록 도울 수 있습니다.

함께 작업하는 디자이너 옆에 15분 동안 앉아서 요소의 사양이 올바른지 여부와 변경 방법을 스스로 확인할 수 있는 방법을 가르칩니다. 나는 Firefox Page Inspector가 이 점에서 매우 사용자 친화적이라는 것을 알았습니다.

요즘에는 레이아웃을 시각화하고 CSS 애니메이션을 디버그하고 타이포그래피를 조정하는 것이 즐겁습니다. 그들이 탐색할 수 있도록 Codepen과 같이 바로 사용할 수 있는 코드 놀이터를 보여주세요. 레이아웃 패러다임이 어떻게 작동하는지 이해하기 위해 모든 CSS 사양을 알 필요는 없습니다. 그러나 일상 업무에 힘을 실어주기 위해 요소가 어떻게 생성되고 작동하는지 알아야 합니다.

개발 프로세스에 디자이너 포함

스탠드업 미팅에 디자이너를 초대하여 QA 프로세스에 참여하고 구현에서 시각적 세부 사항을 수정하는 동안 함께 앉으십시오. 이를 통해 웹의 제약 조건을 이해하고 기능을 구현하는 데 시간이 걸리는 이유를 곧 알게 될 것입니다.

디자이너에게 디자인 프로세스에 귀하를 포함하도록 요청하십시오.

당신은 그들이 "예쁘게 만드는 것"보다 훨씬 더 많은 일을 한다는 것을 알게 될 것입니다. 연구 프로세스와 사용자 테스트가 수행되는 방법에 대해 자세히 알아볼 것입니다. 그들이 당신에게 보여주는 각 디자인 제안에 대해 이전에 몇 가지 다른 연구가 삭제되었음을 알게 될 것입니다. 디자이너가 변경을 요청할 때 그 이유를 물어 보면 결정에 대해 자세히 알아볼 수 있습니다. 궁극적으로, 왜 그들이 여백과 정렬에 대해 까다롭게 여기는지 이해하기 시작할 것이고, 바라건대 곧 당신도 그렇게 될 것입니다!

프론트엔드 개발을 디자인 프로세스의 핵심 부분으로, 디자인을 개발 프로세스의 핵심 부분으로 취급하는 것이 중요하다고 생각합니다. 모든 사람이 설계 및 개발 주기에 참여할 수 있는 기회를 갖는 사고방식을 옹호하는 것은 우리 모두가 서로의 도전을 더 잘 이해하고 훌륭한 경험을 만드는 데 도움이 될 것입니다.

우리는 다른 도구를 사용할 수 있지만 같은 언어로 말해야 합니다

이제 서로의 작업 흐름을 조금 더 잘 이해하기 시작했으므로 다음 단계인 동일한 언어로 말하는 것입니다.

코드 편집기 너머 보기

주변 환경에 주의를 기울이기 시작하면 문제를 해결할 준비가 더 잘 될 것입니다. 비즈니스에 대해 더 잘 알고 디자이너의 말에 기꺼이 귀를 기울이십시오. 그러면 프로젝트에 더 많은 기여를 하는 팀원이 됩니다. 우리의 전문 지식 이외의 분야에서 협력하는 것이 의미 있는 대화와 상호 신뢰를 만드는 열쇠입니다.

UI 시스템을 계약으로 사용하기

디자이너에게 디자인 시스템을 공유하도록 요청하십시오(사용하지 않는 경우 시작하기에 너무 늦은 때는 없습니다). 그러면 사용된 색상을 직접 선택하거나 여백을 파악하거나 텍스트 스타일을 추측하는 수고를 덜 수 있습니다. UI 시스템에 최대한 익숙해지도록 하십시오.

구성 요소 기반 개념에 이미 익숙할 수 있습니다. 그러나 일부 디자이너는 이를 귀하와 같은 방식으로 인식하지 못할 수 있습니다. 구성 요소가 사용자 인터페이스를 보다 효율적으로 구축하는 데 어떻게 도움이 되는지 보여줍니다. 그 사고방식을 전파하고 유사하지만 같지 않은 이름에도 작별을 고하십시오: 헤더 대 영웅, 가격 정보 대 가격 선택기 . 사용자 인터페이스('컴포넌트'라고도 함)의 일부가 빌드되면 동일한 이름을 사용하여 디자인과 코드 파일 모두에 반영할 수 있습니다. 그런 다음 누군가가 "제안 초대 위젯을 조정해야 합니다." 라고 말하면 모든 사람이 정확히 무엇에 대해 이야기하는지 알 수 있습니다.

진실의 진정한 근원을 인정함

사용자 인터페이스가 디자인 파일에서 먼저 생성된다는 사실에도 불구하고 진정한 소스는 개발 측면에 있습니다. 결국 사람들이 실제로 보는 것이겠죠? 디자인이 업데이트되면, 특히 많은 사람들이 참여하는 프로젝트에서 개발 상태에 대한 부수적인 메모를 남기는 것이 좋습니다. 이 트릭은 의사 소통을 원활하게 유지하는 데 도움이되므로 아무도 (당신을 포함하여) 궁금해하지 않습니다 : " 이것은 라이브 버전과 다릅니다. 버그입니까 아니면 아직 구현되지 않은 것입니까? "

부채 관리

따라서 기술 부채 에 대해 모두 알고 있습니다. 과거에 마감 시간을 맞추기 위해 취했던 지름길 때문에 새로운 것을 구현하는 비용이 높을 때 발생합니다. 디자인 측면에서도 동일한 일이 발생할 수 있으며 우리는 이것을 디자인 부채 라고 부릅니다.

다음과 같이 생각할 수 있습니다. UX 및 UI 불일치가 높을수록 부채(기술 및 디자인)가 높아집니다. 가장 일반적인 불일치 중 하나는 동일한 작업을 나타내는 다른 요소가 있다는 것입니다. 이것이 나쁜 디자인이 일반적으로 나쁜 코드에 반영되는 이유 입니다. 설계 부채를 심각하게 다루는 것은 디자이너와 개발자 모두에게 달려 있습니다.

접근성이 좋다는 것이 못생겼다는 의미는 아닙니다.

개발자이자 디자이너인 우리 모두가 마침내 우리 작업에 접근성을 도입하기 시작했다는 것을 알게 되어 정말 기쁩니다. 그러나 우리 중 많은 사람들은 여전히 ​​접근 가능한 제품을 디자인하는 것이 어렵거나 우리의 기술과 창의성을 제한한다고 생각합니다.

우리가 우리 자신만을 위한 제품을 만드는 것이 아님을 상기시켜 드리겠습니다. 우리는 당신과 다른 방식으로 제품을 사용하는 사람들을 포함하여 모든 사람들이 사용할 수 있는 제품을 만들고 있습니다. 현재 사용자 흐름을 명확하고 일관성 있게 유지하면서 개별 요소에 더 쉽게 액세스할 수 있는 방법을 고려하십시오.

예를 들어, 디자이너가 향상된 선택 입력을 만드는 것이 필요하다고 정말로 믿는다면, 그들의 편에 서서 다양한 능력을 가진 광범위한 사람들이 사용할 수 있도록 접근 가능한 방식으로 디자인하고 구현하기 위해 함께 노력하십시오.

디자이너에게 소중한 피드백 제공

디자인을 진행하다 보면 질문이 나오는 것은 피할 수 없습니다. 하지만 그렇다고 해서 디자이너의 실수나 야심찬 아이디어에 대해 불평을 시작할 이유는 아닙니다. 디자이너는 당신을 정신적으로 이끌기 위해 거기 있는 것이 아니라, 당신이 일을 하는 데 필요한 것이 무엇인지 항상 직관적으로 알지 못합니다. 사실, 과거에는 이것에 대해서도 몰랐기 때문에 인내심을 갖고 학습 방법으로 협업을 수용하십시오.

피드백은 빠를수록 좋습니다.

피드백의 타이밍이 중요합니다. 피드백 워크플로는 프로젝트 구조에 따라 크게 달라지므로 만능 솔루션은 없습니다. 그러나 가능하면 초기 단계에서 시작하여 주기적인 피드백 워크플로를 목표로 해야 한다고 생각합니다. 이러한 열린 협업의 사고방식을 갖는 것은 나중에 예상치 못한 큰 반복의 가능성을 줄이는 방법입니다. 나중에 디자이너에게 첫 번째 피드백을 제공할수록 필요한 경우 새로운 접근 방식을 탐색하는 데 드는 비용이 더 높아진다는 점을 명심하십시오.

추상적인 아이디어를 간단한 용어로 설명하기

성능은 디자이너의 이전 직업의 관심사가 아니라고 말한 것을 기억하십니까? 웹에 최적화된 SVG를 만드는 방법을 모른다고 놀라지 마십시오. 다양한 글꼴을 로드해야 하는 디자인에 직면했을 때 요청 수를 최소화하고 가변 글꼴을 활용해야 하는 이유를 설명하십시오. 로딩 속도가 빨라지는 것 외에도 보다 일관된 사용자 경험을 제공합니다. 디자이너가 배우고 싶어하지 않는 한 설명할 때 너무 많은 기술 용어를 사용하지 마십시오. 의사소통 능력을 향상시키고 생각을 정리할 수 있는 기회라고 볼 수 있습니다.

가정이 결정으로 이어지지 않도록 하십시오

디자인 사양에 대한 몇 가지 질문은 코드에서 손을 더럽힐 때만 나타납니다. 속도를 높이기 위해 가정에 따라 결정을 내리고 싶은 유혹을 느낄 수 있습니다. 제발, 하지마. 가정을 결정으로 바꿀 때마다 디자인 팀이 UI 구현에 대해 신뢰하는 위험을 감수해야 합니다. 의심스러울 때마다 손을 내밀어 의심을 명확히 하십시오 . 이것은 당신이 그들이 하는 만큼 최종 결과에 대해 관심을 갖고 있다는 것을 보여줄 것입니다.

스스로 해결 방법을 수행하지 마십시오

너무 어려운 설계를 구현하라는 요청을 받았을 때 "불가능" 이라고 말하지 말고 스스로 저렴한 대안 버전을 구현하기 시작하십시오. 이는 설계가 예상대로 구현되지 않은 것을 볼 때 설계 팀과 즉시 마찰을 일으킵니다. 그들은 화를 내거나 아무 말도 하지 않고 패배감이나 좌절감을 느낄 수도 있습니다. 그것이 불가능한 이유를 간단한 용어로 설명하고 대안적인 접근 방식을 제안한다면 이 모든 것을 피할 수 있습니다. 독단적인 행동을 피하고 새로운 솔루션에 대해 열린 마음으로 협력하십시오 .

그들에게 Graceful Degradation 및 Progressive Enhancement 기술에 대해 알리고 이상적인 솔루션과 대체 솔루션을 함께 구축하십시오. 예를 들어 flexbox에서 CSS Grid로 레이아웃을 향상할 수 있습니다. 이를 통해 기능의 핵심 목적을 존중하는 동시에 웹 기술을 최대한 활용할 수 있습니다.

애니메이션에 관해서는 현실이 되자. 마음 속 깊은 곳에서는 디자이너가 제작하는 것만큼이나 다음 와우 애니메이션을 구현하는 것에 흥분하고 있습니다. 우리와 그들 사이의 차이점은 우리가 웹의 제약을 더 잘 알고 있다는 것입니다. 그러나 그것이 당신의 능력을 제한하게 두지 마십시오! 웹은 빠르게 발전하므로 이를 우리에게 유리하게 사용해야 합니다.

다음에 프로토타입에 생명을 불어넣어 달라는 요청을 받았을 때 미리 거부하거나 혼자서 모든 작업을 수행하지 않도록 하십시오. 자신을 밀어붙일 수 있는 기회로 여기십시오. 애니메이션은 웹 개발에서 가장 까다로운 부분 중 하나이므로 디자이너와 직접 또는 개인 동기화 링크를 공유하여 각 키프레임을 수정해야 합니다.

이상적인 상태를 넘어 생각하기 — 함께

여기 문제가 있습니다. 그것은 당신에 관한 것이 아닙니다. 디자이너의 과제 중 하나는 사용자를 진정으로 이해하고 제품 관리자에게 판매할 수 있는 가장 매력적인 방식으로 디자인을 제시하는 것입니다. 때때로 그들은 이상적인 상태를 넘어서는 것을 잊어버리고 개발자들도 그것을 잊어버립니다.

이러한 격차가 발생하지 않도록 하려면 디자이너와 시나리오 요구 사항을 일치시키십시오.

• 최악의 시나리오
  최악의 가능성이 발생하는 시나리오. 이를 통해 디자이너는 고정된 콘텐츠를 거부하고 유동적으로 사용할 수 있습니다. 제목이 60자를 초과하거나 목록이 너무 길면 어떻게 됩니까? 반대의 경우도 마찬가지입니다. 빈 시나리오입니다. 목록이 비어 있을 때 사용자는 어떻게 해야 합니까?
• 상호작용 상태
  브라우저는 마우스를 가리키고 클릭하는 것 이상입니다. 기본, 호버, 포커스, 활성, 비활성화, 오류 등의 여러 상태가 있으며 그 중 일부는 동시에 발생할 수 있습니다. 그들에게 적절한 주의를 기울이도록 합시다.
• 로딩 상태
  로컬에서 물건을 빌드할 때 mock을 사용하고 실제로 로드하는 데 시간이 걸린다는 사실을 잊어버릴 수 있습니다. 디자이너에게도 그 가능성에 대해 알리고 사람들이 로드하는 데 그렇게 오래 걸리지 않는다는 것을 인식하게 하는 방법을 보여주십시오.

이러한 모든 시나리오를 고려하면 개발 단계에서 왔다 갔다 하는 시간을 많이 절약할 수 있습니다.

참고 : Scott Hurff의 훌륭한 기사에서 액세스 가능한 제품에 한 걸음 더 다가갈 수 있는 잘못된 사용자 인터페이스를 수정하는 방법이 있습니다.

변경 요청 수용

개발자는 자신의 코드에서 누군가가 버그를 발견하는 것에 대해 그다지 기뻐하지 않는 것으로 알려져 있습니다. 특히 디자이너가 보고한 디자인 버그일 때 그렇습니다. 주변에 많은 밈이 있지만 이러한 디자인 버그가 무심코 무시되었을 때 이러한 버그가 경험의 품질과 관계를 악화시킬 수 있다는 점을 반영한 적이 있습니까? 그것은 거의 잠드는 것처럼 천천히 일어납니다. 조금씩, 그리고 나서 한번에. 디자이너는 무관심과 분노가 쌓이고 아무 말도 하지 않을 때까지 " 아주 작은 세부 사항일 뿐입니다 "라고 말하기 시작할 수 있습니다. 피해는 이미 발생했습니다.

이 상황은 두 가지입니다. 동료와 직장 모두입니다. 그런 일이 일어나지 않도록하십시오. 당신의 반응에 어떤 영향을 미치는지 알아보세요. 디자이너가 '까다롭다'는 것은 불편할 수도 있지만, 세심함과 열정에 대한 엔지니어의 얕은 해석일 수도 있습니다. 누군가가 당신의 구현이 (아직) 완벽하지 않다고 말할 때, 당신의 자존심을 제쳐두고 최종 결과를 개선하기 위해 그들의 노력을 어떻게 인식하는지 보여주십시오.

간헐적으로 기록에서 벗어남

우리 모두에게는 전달해야 할 작업과 완료해야 할 로드맵이 있습니다. 그러나 최고의 작업 중 일부는 기록에서 벗어납니다. TO DO 보드에 로그인되지 않으며 괜찮습니다. 당신과 교감하고 있는 디자이너를 찾으면 그들의 작업 공간으로 몰래 들어가서 함께 새로운 실험을 탐구하십시오. 당신은 거기에서 무엇을 얻을 수 있습니다!

결론

당신이 디자인 팀으로부터 기꺼이 배우려고 할 때, 당신은 또한 다른 사고 방식을 배우고 있는 것입니다. 새로운 경험을 만드는 눈을 가다듬는 동시에 경험을 통해 다른 영역과의 협업에 대한 사고방식을 발전시킬 것입니다. 공유가 우리를 더 낫게 만드는 것이기 때문에 도움을 주고 배우기 위해 열려 있습니다.

이 기사는 많은 훌륭한 사람들의 피드백 없이는 불가능했을 것입니다. 디자이너와 개발자 간의 오해에 대해 균형 잡힌 관점을 공유할 수 있도록 도와준 디자이너 Jasmine Meijer와 Margarida Botelho에게 감사드립니다.

SmashingMag 관련 읽기 :

• Mason Gentry 의 "개발자를 위한 디자인"
• Rachel Andrew 의 "공동 작업: 디자이너와 개발자가 의사 소통하여 더 나은 프로젝트를 만드는 방법"
• Stefan Kaltenegger 의 "프론트엔드 개발자가 디자이너와 개발자 간의 격차를 해소하는 데 도움이 되는 방법"
• "웹 디자이너와 개발자는 어떤 팟캐스트를 들어야 할까요?" 리키 온스만