figma2025년 3월 26일

디자이너와 개발자를 직장에서 (새 탭에서 열림)

디자이너와 개발자의 직장 만족도는 조직 내 디자인의 위상, 하이브리드 근무 정책, 리더십, 협업과 커뮤니케이션에 크게 좌우된다. 설문 응답자의 41%는 전년보다 직장 만족도가 높아졌으며, 명확한 근무 제도와 자율성, 디자인·개발 간 긴밀한 협업이 긍정적인 업무 경험을 만든다. 특히 디자인을 단순한 지원 기능이 아니라 전략적 파트너로 대우하는 조직일수록 구성원의 만족도가 높아진다는 것이 글의 결론이다. ## 조사 개요와 전반적인 만족도 - Figma는 디자이너와 개발자 943명을 대상으로 제품 개발 방식과 업무 경험을 조사했다. - 응답자의 41%가 전년보다 직장 만족도가 높아졌다고 답했다. - 글은 업무 만족도에 영향을 주는 다섯 가지 요인을 소개하며, 조직·관리자·개인이 각각 어떤 환경을 만들어야 하는지 설명한다. - 제공된 본문에는 네 번째 요인까지 수록되어 있으며, 다섯 번째 요인의 내용은 포함되어 있지 않다. ## 디자인의 조직 내 위상 - 디자인을 단순히 요청받은 결과물을 제공하는 서비스 조직이 아니라 전략적 파트너로 인정하면 디자이너의 만족도가 높아진다. - 디자인이 전략 수립에 참여하면 고객 중심성을 강화하고, 디자이너가 제품과 사업에 실질적인 영향을 미칠 수 있다. - 디자이너는 탐색과 실행 사이의 균형을 보여 주어야 한다. - Wise는 다음과 같은 “현재·다음·미래” 원칙을 제시한다. - 현재 제공할 결과물에 70%의 시간 사용 - 다음 단계의 과제에 20% 사용 - 장기적인 미래 탐색에 10% 사용 - 탐색 단계가 지나치게 길어지면 실행력이 부족하다는 인상을 줄 수 있으므로, 창의적인 발견과 구체적인 납품 일정을 함께 관리해야 한다. ## 하이브리드 근무 정책 - 응답자의 97%는 적어도 일부 기간 원격으로 근무하며, 절반 이상은 대부분 또는 완전히 원격으로 일한다. - 어디서 일하는지가 업무 자체만큼 직장 만족도에 중요한 요소가 됐다. - 모든 조직에 동일한 하이브리드 정책을 적용하는 방식은 효과적이지 않을 수 있다. - 출근 요일과 장소가 불명확하면 특정 요일에만 사무실이 붐비고 좌석이나 회의실이 부족해지는 문제가 발생한다. - 완전 원격, 완전 출근, 유연한 하이브리드 중 어떤 방식을 선택하든 다음 사항을 명확히 해야 한다. - 출근이 필요한 상황 - 협업을 위한 공통 시간대 - 사무실 이용 방식 - 성과를 평가하는 기준 ## 리더의 자율성 부여와 지원 - 관리자는 팀의 실제 업무 상황을 파악하고 필요한 지원과 의사결정을 제공해야 한다. - 좋은 리더는 구성원마다 필요한 지원 방식이 다르다는 점을 이해한다. - 근무 시간이나 장소를 일률적으로 통제하기보다 결과물의 품질과 영향력을 중심으로 평가하는 접근이 효과적이다. - 리더는 팀이 최선의 결과를 내도록 지원하는 동시에, 좋은 성과가 적절히 인정되고 보상되도록 해야 한다. - 자율성을 주되 목표와 기대 수준은 분명히 제시해야 한다. ## 디자인·개발 협업과 커뮤니케이션 - 직장 만족도가 높은 디자이너 중 69%는 개발자와의 협업이 효과적이거나 매우 효과적이라고 평가했다. - 만족도가 높은 개발자일수록 디자이너와 더 자주 협업하는 경향이 있다. - 디자이너의 84%는 개발자와 최소 주 1회 협업한다. - 화이트보드와 협업형 디자인 도구는 여러 사람이 동시에 아이디어를 공유하고 작업할 수 있게 해 협업을 촉진한다. - 그러나 개발자의 91%, 디자이너의 92%는 협업 프로세스에 여전히 개선의 여지가 있다고 답했다. - 협업 불일치의 원인으로 개발자 중 47%는 디자이너가 엔지니어링의 제약과 관점을 충분히 이해하지 못하는 점을 지적했다. - 따라서 효과적인 협업을 위해서는 단순한 도구 도입을 넘어 다음이 필요하다. - 초기 단계부터 디자이너와 개발자가 함께 논의하기 - 기술적 제약과 사용자 요구를 상호 공유하기 - 정기적인 피드백과 의사결정 과정 마련하기 - 결과물보다 문제 정의와 목표를 먼저 합의하기 조직은 디자인을 전략적 의사결정에 참여시키고, 근무 방식과 성과 기준을 명확히 하며, 디자이너와 개발자가 자주 협업할 수 있는 환경을 만들어야 한다. 개인과 팀 차원에서는 탐색과 실행의 균형을 유지하고, 도구뿐 아니라 서로의 업무 맥락과 제약을 이해하는 데 집중하는 것이 실용적인 개선책이다.

whiteboardingfigmacollaborative-designmultiplayer-collaboration+1

figma2020년 6월 17일

개발자와 더 가까워지는 방법 | (새 탭에서 열림)

엔지니어를 제품 디자인 과정에 일찍 참여시키면 기술적 제약과 예외 상황을 빠르게 파악해 더 나은 해결책을 만들 수 있다. 디자이너는 완성된 시안을 전달하기보다 초기 아이디어 단계부터 엔지니어와 함께 가설을 검토하고 대안을 탐색해야 한다. 이를 위해 빠른 목업, 공동 브레인스토밍, 핵심 질문 정의가 효과적인 협업 방식으로 제시된다. ## 기술 지식이 아이디어를 구체화한다 - 디자인 초기의 아이디어 구상 단계에서 엔지니어와 긴밀히 협업하면 구현상의 제약을 빠르게 이해할 수 있다. - 엔지니어는 기술적 지식을 바탕으로 다음을 파악하는 데 도움을 준다. - 예상하지 못한 예외 상황 - API나 시스템 구조에서 발생할 수 있는 제약 - 구현 난이도와 선택지별 트레이드오프 - 초기부터 제약 조건을 알면 나중에 구현이 불가능한 시안을 수정하는 대신, 현실적이면서도 더 사려 깊은 해결책을 설계할 수 있다. - 완성된 결과물을 평가받는 방식이 아니라, 문제를 함께 정의하고 아이디어를 발전시키는 파트너로 엔지니어를 참여시켜야 한다. ## 지속적으로 협업할 엔지니어를 정한다 - Coda의 Packs Tables 기능을 개발할 때 전체 엔지니어링 팀과 별개로, 디자이너와 전 과정에서 협력할 엔지니어 파트너를 두었다. - Packs Tables는 Spotify, Google Calendar, Gmail 등 외부 앱의 데이터를 Coda 문서로 가져오는 기능이다. - 여러 앱의 API를 지원해야 하므로 특정 앱에만 맞는 해결책이 아니라 다양한 서비스에서 작동하는 구조를 고민해야 했다. - 한 명의 엔지니어와 지속적으로 협업하면 아이디어를 즉시 검토하고, 기술적 질문과 디자인 방향을 함께 조정할 수 있다. ## 빠르고 불완전한 ‘스트로맨 목업’을 만든다 - 스트로맨 목업은 완성된 디자인이 아니라 토론과 질문을 유도하기 위한 시각적 초안이다. - 다음 원칙을 따른다. - 빠르게 만든다. 초기 아이디어에는 오해나 잘못된 가정이 포함될 수 있으므로 많은 시간을 투자하지 않는다. - 해결책보다 질문을 더 많이 담는다. - 하나의 방향으로 좁히기보다 다양한 가능성을 보여준다. - 먼저 “모든 것이 쉽게 작동한다면 어떻게 보이고 동작할까?”를 가정해 초안을 만든다. - 엔지니어와 검토할 때 다음 질문을 적극적으로 던진다. - 가장 큰 오해나 잘못된 가정은 무엇인가? - 아직 고려하지 못한 요소는 무엇인가? - 흥미로운 방향은 무엇인가? - 구현하기 어려운 방향은 무엇이며, 그 어려움의 대가는 무엇인가? - 어려운 방향을 무조건 배제하는 것이 아니라, 난이도와 트레이드오프를 이해하는 것이 목적이다. ## 함께 아이디어를 시각화한다 - 초기 단계에는 자신의 목업만 검토하지 말고 엔지니어와 함께 새로운 아이디어를 브레인스토밍해야 한다. - 디자이너의 시각화 능력은 자신의 아이디어뿐 아니라 팀원의 질문과 가설을 구체화하는 데도 활용할 수 있다. - Coda에서는 컴포넌트가 준비된 와이어프레임 키트를 사용했으며, 새로운 요소가 아니라면 하이파이 형태로도 빠르게 탐색했다. - 원격 환경에서는 다음과 같은 방식으로도 협업할 수 있다. - 펜과 종이를 카메라로 공유하기 - iPad 화면 공유하기 - 온라인 화이트보드 사용하기 - Packs Tables 개발 과정에서는 화이트보드에 UI를 그리며 질문과 잠재적 문제를 구체화했다. - 이 단계의 목표는 최종 UI를 확정하는 것이 아니라, 아이디어와 문제에 대해 서로 같은 이해를 갖는 것이다. ## 핵심 질문을 먼저 정의한다 - 핵심 질문은 이후 발생하는 세부적인 의사결정의 기준이 되는 원칙이다. - 질문을 먼저 정리하면 다음과 같은 효과가 있다. - 문제를 올바른 순서로 해결할 수 있다. - 초기부터 특정 해결책을 두고 논쟁하는 일을 줄일 수 있다. - 설계 결정을 더 빠르게 내릴 수 있다. - 예를 들어 행사에 맞춤 냅킨을 사용할지 결정하려면 먼저 예산, 시간, 인력, 행사 분위기 같은 상위 조건을 정해야 한다. - Packs Tables에서는 브레인스토밍 중 핵심 질문을 만들고 이를 Coda 문서에 기록했다. - 이후 해당 기능에 참여하는 모든 엔지니어와 질문 및 가능한 선택지를 함께 검토해 공통된 판단 기준을 마련했다. 엔지니어를 마지막 검수 단계에만 참여시키지 말고, 초기 가설과 아이디어를 함께 탐색하는 파트너로 초대하는 것이 좋다. 빠른 목업을 만들고, 화이트보드로 대안을 시각화하며, 핵심 질문을 문서화하면 기술적 제약을 창의성을 제한하는 요소가 아니라 더 나은 디자인을 만드는 정보로 활용할 수 있다.

whiteboardingproduct-designcollaborationwireframing+2