프론트엔드 개발자가 디자이너와 개발자 사이의 격차를 해소하는 데 도움이 되는 방법

게시 됨: 2022-03-10

빠른 요약 ↬ 개발자는 일반적으로 웹사이트나 모든 종류의 웹 제품이 출시되기 전에 지문을 가장 늦게 남기는 것으로 알려져 있습니다. 분명히 많은 책임이 수반되며 작업의 품질은 프로젝트를 탁월하게 만들거나 배수로를 떨어뜨릴 수 있습니다. 이 기사는 프론트엔드 개발자가 디자이너와 개발자 사이의 격차를 더 잘 메우기 위해 할 수 있는 일에 대한 제안을 제공합니다.

지난 9년 동안 내가 함께 일했던 거의 모든 디자이너는 단순히 올바르게 구현되지 않은 레이아웃 측면뿐만 아니라 간격, 글꼴 크기, 시각 및 레이아웃 측면을 수정하기 위해 개발자에게 피드백을 제공하는 데 며칠을 보내는 경우가 자주 발생하는 것에 대해 불만을 표명했습니다. . 이것은 종종 디자이너와 개발자 사이의 신뢰를 약화시키고 두 분야 사이에 나쁜 분위기와 함께 의욕없는 디자이너를 유발합니다.

많은 경우 개발자들은 디자인 팀이 생각해 낸 세부 사항에 대해 세심한 주의를 기울일 때 지나치게 기술적이고 무지하다는 나쁜 평판을 여전히 가지고 있는 것 같습니다. Andy Budd의 기사에 따르면 "[...] 많은 개발자가 디자인에 대해 같은 입장에 있습니다. 그들은 단지 그것을 깨닫지 못할 뿐입니다." 그러나 실제로(Paul Boag가 지적한 것처럼) "개발자는 항상 디자인 결정을 내려야 합니다."

이 기사에서는 프론트엔드 개발자가 창의적인 상대와 작업할 때 좌절을 피하고 생산성을 높일 수 있는 실용적인 조언을 제공합니다.

디자이너의 눈으로 바라보기

잠시 동안 당신이 디자이너이고 웹사이트를 위한 디자인을 만들기 위해 몇 달은 아니더라도 지난 몇 주를 보냈다고 상상해 봅시다. 당신과 당신의 팀원은 클라이언트 프레젠테이션뿐만 아니라 여러 내부 수정을 거쳤고 공백, 글꼴 스타일 및 크기와 같은 시각적 세부 사항을 미세 조정하기 위해 많은 노력을 기울였습니다. (물론 다양한 화면 크기에 대한 반응형 시대입니다.) 디자인은 클라이언트의 승인을 받고 개발자에게 전달되었습니다. 마음이 편안해지고 행복해집니다.

몇 주 후 개발자로부터 다음과 같은 이메일을 받게 됩니다.

“스테이징 사이트가 설정되었습니다. 여기 링크가 있습니다. QA 부탁드려도 될까요?”

설레는 마음으로 스테이징 링크를 열고 일부 페이지를 스크롤한 후 사이트가 약간 이상해 보이는 것을 알 수 있습니다. 간격은 디자인이 제안한 것과 가깝지 않으며 레이아웃에서 잘못된 글꼴과 색상, 잘못된 상호 작용 및 호버 상태와 같은 몇 가지 꼬임을 알 수 있습니다. 당신의 흥분은 서서히 사라지기 시작하고 좌절감으로 변합니다. “어떻게 그런 일이 일어날 수 있었습니까?”라고 자문하지 않을 수 없습니다.

점프 후 더! 아래에서 계속 읽기 ↓

이유 찾기

아마도 디자이너와 개발자 간의 의사 소통에 불행한 오해가 많았을 것입니다. 그럼에도 불구하고 당신은 계속해서 스스로에게 묻습니다.

디자인 인계는 어떻게 되었습니까? PDF, Photoshop 또는 Sketch 파일이 이메일을 통해 일부 의견과 함께 공유되었을 뿐이었습니까? 아니면 가능한 디자인 시스템, 타이포그래피, 반응 동작, 상호 작용 및 애니메이션과 같은 다양한 측면이 논의된 실제 전달 회의가 있었습니까?
특정 인터랙션을 시각화하는 데 도움이 되는 인터랙티브 또는 모션 프로토타입이 존재했습니까?
정의된 우선 순위 수준과 함께 중요한 측면 목록이 생성되었습니까?
디자이너 와 개발자가 같은 방에서 함께 얼마나 많은 대화가 이루어졌습니까?

통신 과 핸드오버 는 매우 중요한 두 가지 핵심 포인트이므로 각각에 대해 자세히 살펴보겠습니다.

커뮤니케이션이 핵심

디자이너와 개발자는 서로 이야기하십시오. 많은 이야기 . 프로젝트는 초기에 자주할수록 좋습니다. 가능하면 프로젝트 초기에(그리고 정기적으로) 진행 중인 설계 작업을 함께 검토하여 지속적으로 타당성을 평가하고 학제 간 의견을 얻습니다. 디자이너와 개발자는 자연스럽게 같은 부품의 다른 측면에 초점을 맞추므로 다른 각도와 관점에서 사물을 봅니다 .

초기에 체크인하면 개발자가 프로젝트에 익숙해질 수 있으므로 기술 용어에 대한 조사 및 계획을 미리 시작하고 기능을 최적화할 수 있는 방법에 대한 아이디어를 가져올 수 있습니다. 빈번한 체크인은 또한 개인 및 사회적 수준에서 팀을 하나로 묶고 효과적으로 의사 소통하기 위해 서로 접근하는 방법을 배웁니다.

설계에서 개발로의 인계

조직이 진정으로 민첩한 워크플로를 따르지 않는 한 디자인 구성 요소 및 자산(디자인 팀에서 개발자에게)의 초기 인계는 프로젝트의 어느 시점에서 발생할 수 있습니다. 이 양도는 철저하게 이루어지면 양측 간의 지식과 합의의 견고한 기초가 될 수 있습니다. 따라서 서두르지 말고 추가 시간을 계획하는 것이 중요합니다.

많은 질문을 하고 모든 요구 사항, 페이지, 구성 요소, 기능, 상호 작용, 애니메이션 등을 통해 이야기하고 메모하세요. 불명확한 경우 설명을 요청하십시오 . 예를 들어 외부 또는 계약 기반 팀과 작업할 때 디자이너와 개발자 모두 나중에 참조할 수 있도록 상호 합의 문서로 작성한 메모에 서명할 수 있습니다.

평면 및 정적 디자인 구성 요소는 웹 사이트의 그래픽 및 레이아웃 측면을 표시하는 데 적합하지만 상호 작용 및 애니메이션에 대한 적절한 표현이 분명히 부족합니다. 복잡한 애니메이션의 프로토타입이나 작업 데모를 요청하면 관련된 모든 사람을 위해 구축해야 하는 것이 무엇인지에 대한 명확한 비전을 얻을 수 있습니다.

요즘에는 디자이너가 다양한 수준의 충실도에서 흐름과 상호 작용을 모형화하는 데 사용할 수 있는 광범위한 프로토타이핑 도구가 있습니다. Javier Cuello는 포괄적인 기사 중 하나에서 프로젝트에 적합한 프로토타이핑 도구를 선택하는 방법을 설명합니다.

모든 프로젝트는 고유하고 요구 사항도 고유합니다. 이러한 요구 사항으로 인해 개념화된 모든 기능을 항상 구축할 수 있는 것은 아닙니다. 종종 무언가를 구축하는 데 사용할 수 있는 시간과 리소스가 제한 요소가 될 수 있습니다. 또한 제약 조건은 실행 가능성, 접근성, 성능, 사용성 및 브라우저 간 지원과 같은 기술적 요구 사항 , 예산 및 라이선스 비용과 같은 경제적 요구 사항 또는 개발자의 기술 수준 및 가용성과 같은 개인적 제약 조건에서 비롯될 수 있습니다.

그렇다면 이러한 제약으로 인해 디자이너와 개발자 간에 충돌이 발생하면 어떻게 될까요?

타협점 찾기 및 공유 지식 구축

프로젝트를 제시간에 성공적으로 배송하고 정의된 모든 요구 사항을 충족하려면 두 분야 간의 절충안을 찾는 것이 대부분 불가피합니다. 개발자는 특정 상황에서 변경이 필요하거나 구축할 수 없는 이유를 설명할 때 비기술적 용어로 디자이너에게 말하는 방법을 배워야 합니다.

개발자는 "죄송합니다. 이것을 만들 수 없습니다."라고 말하는 대신 디자이너가 이해할 수 있는 설명을 제공해야 하며 가장 좋은 경우 알려진 제약 조건 내에서 작동 하는 대체 솔루션에 대한 제안을 준비해야 합니다 . 통계, 연구 또는 기사로 주장을 뒷받침하면 주장을 강조하는 데 도움이 될 수 있습니다. 또한 타이밍이 문제인 경우 시간이 많이 소요되는 일부 구현을 프로젝트의 나중 단계로 이동할 수 있습니까?

항상 가능한 것은 아니지만 디자이너와 개발자가 나란히 앉으면 피드백 루프가 단축되고 손상된 솔루션을 더 쉽게 해결할 수 있습니다. DevTools가 열린 상태에서 코딩 및 최적화를 통해 적응 및 프로토타이핑을 직접 수행할 수 있습니다.

동료 디자이너에게 브라우저에서 DevTools를 사용하는 방법을 보여주어 그들이 기본 정보를 변경하고 브라우저의 작은 변경 사항(예: 패딩, 여백, 글꼴 크기, 클래스 이름)을 즉석에서 미리 볼 수 있도록 합니다.

프로젝트와 팀 구조가 허용하는 경우 가능한 한 빨리 브라우저에서 빌드하고 프로토타입을 작성하면 관련된 모든 사람이 반응 동작을 더 잘 이해할 수 있고 프로젝트 초기 단계에서 버그와 오류를 제거하는 데 도움 이 될 수 있습니다.

디자이너와 개발자가 함께 작업하는 시간이 길수록 더 나은 디자이너는 개발자가 빌드하는 것이 더 쉽고 어려운 것이 무엇인지 이해하게 될 것입니다. 시간이 지나면 결국 과거에 양측 모두에게 효과가 있었던 솔루션을 참조할 수 있습니다.

"저희는 그 솔루션을 사용하여 프로젝트 A에서 타협점을 찾았습니다. 이 프로젝트에도 사용할 수 있나요?"

이것은 또한 개발자가 디자이너가 어떤 세부 사항에 대해 매우 구체적이고 어떤 시각적 측면이 중요한지 더 잘 이해할 수 있도록 도와줍니다.

디자이너는 프론트엔드가 자신의 디자인처럼 보일 것으로 기대합니다.

디자인 파일 대. 브라우저 비교

디자이너가 좌절하지 않도록 하는 유용한 기술은 넘겨받은 디자인 파일과 현재 개발 상태를 간단하게 좌우 비교하는 것입니다. 사소하게 들릴지 모르지만 개발자는 내부에서 작동해야 하는 많은 일을 처리해야 하므로 일부 시각적 세부 정보를 놓쳤을 수 있습니다. 눈에 띄는 불일치가 보이면 간단히 수정하십시오.

다음과 같이 생각하십시오. 구현의 모든 세부 사항이 설계된 대로 정확하게 표시되므로 귀하와 설계자 모두 귀중한 시간과 골칫거리를 절약 하고 신뢰를 얻을 수 있습니다. 모든 사람이 세부 사항에 대해 동일한 수준의 주의를 기울이는 것은 아니지만 시각적 차이를 인지하도록 눈을 훈련하려면 Can't Unsee의 빠른 라운드가 좋은 도움이 될 수 있습니다.

"Can't Unsee"는 두 가지 선택 중 가장 정확한 디자인을 선택해야 하는 게임입니다. — (이미지 크레딧: Can't Unsee) (큰 미리보기)

이것은 우리가 오래전에 하던 "찾기"라는 게임을 그리워하게 합니다. 점수를 매기기 위해 겉보기에 비슷한 두 이미지를 비교하여 불일치를 찾아야 했습니다.

"찾기"에서 플레이어는 두 이미지를 비교하여 오류를 찾아야 합니다. — (이미지 크레딧: Mordillo가 그들을 찾습니다) (큰 미리보기)

그래도 다음과 같이 생각할 수 있습니다.

"디자인에 눈에 띄는 글꼴 크기와 간격 시스템이 없다면 어떻게 될까요?"

글쎄, 좋은 지적! 경험에 따르면 스스로 상황을 근본적으로 변경하고 나중에 디자이너에게 원치 않는 놀라움을 주기보다는 설명을 요청 하여 디자이너와 대화를 시작하는 데 도움이 될 수 있습니다.

기본 활자체 및 디자인 규칙 배우기

올리버 라이헨슈타인(Oliver Reichenstein)이 그의 기사 중 하나에서 말했듯이 웹에 있는 정보의 95%는 문자로 된 언어입니다. 따라서 타이포그래피는 웹 디자인뿐만 아니라 개발에서도 중요한 역할을 합니다. 타이포그래피의 기본 용어와 개념을 이해하면 디자이너와 보다 효과적으로 의사 소통하는 데 도움이 될 수 있으며 개발자로서 더욱 다재다능해질 수 있습니다. 나는 Oliver가 웹에서 타이포그래피의 중요성을 자세히 설명하고 마이크로 및 매크로 타이포그래피 와 같은 용어를 설명하는 기사를 읽는 것이 좋습니다.

"모바일 웹 디자인의 타이포그래피 참조 가이드"에서 Suzanne Scacca는 서체, 글꼴, 크기, 두께, 커닝, 행간 및 자간과 같은 타이포그래피 용어와 현대 웹 디자인에서 타이포그래피의 역할을 철저히 다룹니다.

타이포그래피의 지평을 더 넓히고 싶다면 Matthew Butterick의 책 "Butterick의 Practical Typography"를 읽을 가치가 있습니다. 또한 타이포그래피의 주요 규칙에 대한 요약도 제공합니다.

반응형 웹 디자인에서 특히 유용하다고 생각한 한 가지는 짧은 줄이 긴 줄보다 읽기 쉽기 때문에 평균 줄 길이(줄당 문자 수)가 45~90 자라는 것을 목표로 해야 한다는 것입니다.

줄 길이가 다른 두 텍스트 단락 비교 — 다양한 선 길이 비교(큰 미리보기)

개발자는 디자인을 해야 합니까?

디자이너가 코딩을 배워야 하는지 여부에 대해 많은 논의가 있었고, 여러분도 같은 질문을 스스로에게 던질 수 있습니다. 나는 두 분야 모두에서 뛰어난 사람은 거의 없다고 생각합니다.

Rachel Andrew는 그녀의 기사 "Working Together: How Designers And Developers Can Communicate To Create Better Projects"에서 보다 효과적으로 협업 하기 위해 팀원들의 언어, 기술 및 우선순위에 대해 어느 정도 배워야 한다고 멋지게 설명합니다. 공유 언어와 겹치는 전문 분야를 만들 수 있습니다.

디자인 분야에서 더 많은 지식을 얻을 수 있는 한 가지 방법은 웹 디자인의 두 가지 기본 영역인 기본 레이아웃 원칙과 색상 이론에 대해 이야기하는 Sarah Drasner가 제공하는 "개발자를 위한 디자인"으로 알려진 온라인 과정입니다.

"자신의 분야 밖에서 더 많이 배울수록 실제로 개발자로서 [...] 더 좋습니다."

— 사라 드라스너

비주얼 센터

디자이너들과 협업하면서 수학적 중심과 시각적 중심의 차이점을 배웠습니다. 독자의 주의를 특정 요소로 이끌고 싶을 때 우리 눈의 자연스러운 초점은 페이지의 수학적 중심 바로 위에 있습니다.

예를 들어, 위치 모달이나 모든 종류의 오버레이에 이 개념을 적용할 수 있습니다. 이 기술은 자연스럽게 사용자의 관심 을 끌고 디자인을 보다 균형 있게 보이게 하는 데 도움이 됩니다.

하나는 수학에 정렬된 텍스트를 표시하고 다른 하나는 시각적 중심에 정렬된 텍스트를 표시하는 두 페이지 레이아웃 비교 — (큰 미리보기)

우리 모두 함께해요

촉박한 마감 시간으로 빠르게 진행되고 민첩하지 않은 에이전시 환경에서 개발자는 종종 모바일 및 데스크톱 목업을 기반으로 하는 완전한 기능의 반응형 프론트엔드를 구현하라는 요청을 받습니다. 이것은 필연적으로 개발자가 프로세스 전반에 걸쳐 설계 결정을 내리도록 강요합니다. "헤드라인의 글꼴 크기를 어느 너비로 줄일 것인가?"와 같은 질문 또는 "언제 3열 레이아웃을 단일 열로 전환해야 합니까?" 발생할 수있다.

또한 순간의 열기에 오류 상태, 알림, 로드 상태, 모달 또는 404페이지의 스타일과 같은 세부 정보가 균열을 통해 떨어질 수 있습니다. 그런 상황에서 손가락질을 시작하고 더 일찍이에 대해 생각했어야 하는 사람들을 비난하기 시작하기 쉽습니다 . 이상적으로는 개발자가 그런 상황에 처해서는 안 되지만, 그렇다면 어떻게 될까요?

Ueno의 설립자이자 CEO인 Haraldur Thorleifsson이 2018년 샌프란시스코에서 열린 컨퍼런스에서 연설하는 것을 들었을 때 그는 두 가지 핵심 가치를 제시했습니다.

"여기에는 다른 사람의 문제가 없습니다."

“쓰지 않은 쓰레기는 우리가 줍습니다.”

더 많은 개발자가 먼저 위에서 언급한 누락된 부분을 최대한 잘 모형화한 다음 옆에 앉아 있는 디자이너와 함께 개선하면 어떻게 될까요? 웹사이트는 브라우저에 존재하므로 이를 활용하여 구축하고 개선하는 것이 어떻겠습니까?

누락되거나 잊혀진 부분을 날개로 처리하는 것이 항상 이상적인 것은 아니지만, 저는 과거 경험을 통해 팀 으로서 더 빨리 전진하고 즉석에서 오류를 제거하는 데 항상 도움이 된다는 것을 배웠습니다.

물론 그렇다고 해서 그 과정에서 디자이너를 무시해야 하는 것은 아니다. 즉, 개발자는 문제 해결에 솔선수범하여 중간에 디자이너를 정중하게 만나도록 노력해야 합니다 . 게다가 내가 개발자로서 팀은 단순히 돌보고 책임을 지는 것만으로도 훨씬 더 가치 있는 존재였다.

디자이너와 개발자 간의 신뢰 구축

크리에이티브 팀과 기술 팀 간에 신뢰할 수 있고 긍정적인 관계를 유지하면 생산성과 작업 결과를 크게 높일 수 있습니다. 그렇다면 개발자로서 두 분야 간의 신뢰를 높이기 위해 무엇을 할 수 있습니까? 다음은 몇 가지 제안 사항입니다.

세부 사항에 대한 눈을 보여줍니다 .
디자인된 대로 정확하게 물건을 만드는 것은 디자이너에게 당신이 관심을 갖고 있다는 것을 보여주고 얼굴에 큰 미소를 지을 것입니다.
존경심을 가지고 의사 소통 하십시오.
우리는 모두 최상의 결과를 위해 노력하는 전문적인 환경에 있는 인간입니다. 서로의 규율을 존중하는 것이 모든 의사소통의 기초가 되어야 합니다.
일찍 그리고 정기적으로 체크인하십시오 .
처음부터 개발자를 참여시키면 오류를 조기에 제거하는 데 도움이 될 수 있습니다. 잦은 의사 소통을 통해 팀원들은 언어를 공유하고 서로의 입장을 더 잘 이해할 수 있습니다.
자신을 사용할 수 있도록하십시오 .
디자이너가 개발자와 아이디어를 논의할 수 있는 하루 30분 이상의 선택적인 시간을 갖는 것은 디자이너에게 지원을 받고 있다는 느낌을 줄 수 있습니다. 이것은 또한 개발자가 기술에 익숙하지 않은 사람들이 더 잘 이해할 수 있는 말로 복잡한 기술적인 것을 설명할 기회를 제공합니다.

결과: 윈-윈 상황

효과적인 의사 소통과 적절한 디자인 전달을 통해 QA에 더 적은 시간을 할애해야 하므로 크리에이티브 팀과 개발 팀 모두 실제 구축에 더 많은 시간을 할애하고 골칫거리를 줄일 수 있습니다. 궁극적으로 더 나은 분위기를 조성하고 디자이너와 개발자 간의 신뢰를 구축합니다. 일부 디자인 관련 분야에 관심과 지식을 보이는 프론트엔드 개발자들의 목소리는 디자인 미팅에서 더욱 들릴 것입니다.

디자이너와 개발자 간의 타협점 을 찾는 데 적극적으로 기여하고 개발자로서 문제를 해결하면 전체 프로젝트에 대한 소유권과 참여의 폭을 넓힐 수 있습니다. 오늘날의 호황을 누리고 있는 크리에이티브 산업에서도 기술적인 능력 외에 시각적인 세부 사항에 관심을 갖고 관찰하는 개발자를 찾기가 쉽지 않습니다. 이것은 팀의 격차를 해소하는 데 도움이 될 수 있습니다.