사람이 반이고, 소통이 전부니까

디자이너의 대화법

소통의 중요성

사이드 프로젝트나 창업, 동아리 같은 IT 분야의 대외 활동에서는 "참신한 아이디어와 빠른 실행력"이 핵심 성공 요인으로 여겨진다. 하지만 실제 현장에서는 실행 속도는 물론, 실행 자체도 어려운 경우가 많다. 대부분의 앱이 출시까지 가지 못하고 흐지부지 사라진다. 내가 경험한 프로젝트들에서도 실행을 가능하게 했던 힘은 아이디어나 속도보다 팀원 간의 소통이었다. 아이디어는 설득되지 않으면 팀에서 의미를 잃고, 실행력도 역할과 기대가 명확하지 않으면 쉽게 무너진다.

학생 창업팀에서 기획안을 논의할 때도 문제는 아이디어의 퀄리티가 아니라 서로의 생각을 얼마나 정확히 이해했느냐에 있었다. 무엇보다도, 아이디어의 퀄리티는 애초에 혼자서 최고점을 달성할 수 있는 성질의 것이 아니다. 팀원들과 끊임없이 의견을 주고받으며 서로 다른 관점을 더할 때 비로소 완성도를 높일 수 있다.

---

대화하는 디자이너

UX 디자이너는 팀에서 가장 활발하게 소통하는 역할이다. 넓게 보면 디자인 자체가 결국 시각으로 이루어진 하나의 소통 방식이며, UI도 결국 사용자와 기능을 연결하는 수단일 뿐이다. 대화라는 좁은 의미로 보더라도, 디자이너는 기획자, 개발자, 마케터의 요구를 조율하고 이를 사용자 경험으로 풀어내야 한다. 기획자나 마케터도 서비스 기획과 운영 과정에서 외부 이해관계자와 소통하지만, 디자이너는 팀 내부에서 구현 과정 전반에 걸쳐 가장 밀도 있게 의견을 주고받는다. 무엇을 보여주고 어떻게 작동할지를 함께 결정하고 설득하는 과정, 그것이 디자인의 본질이다. 그리고 이 대화는 말로만 이루어지지 않는다.

글로 할까? 그림으로 할까?

아이디어가 모호할수록 말로 설명하는 데 한계가 있다. 같은 말을 듣고도 사람마다 떠올리는 그림이 다르기 때문이다. 그래서 디자이너는 생각을 시각화해 소통해야 한다. 간단한 스케치나 와이어프레임, 프로토타입은 말로는 전달하기 어려운 내용을 빠르게 공유할 수 있는 도구이다. 서로의 상상이 엇갈리던 복잡한 구조도, 인터랙션을 러프하게 연결해 보여주는 순간 쉽게 이해된다. 디자이너에게 시각적 커뮤니케이션은 설계 도구이자 협업 도구다.

IT 프로젝트의 단계별 흐름에 따라, 디자이너가 활용할 수 있는 커뮤니케이션 도구들을 소개한다.

디자이너의 커뮤니케이션 도구

* 본 글에 예시로 첨부된 작업물은 저의 개인 또는 팀 저작물로 무단 저장 및 게시(재배포, 2차 가공 등 모든 사용)를 금지합니다.

첫 번째, 기획 및 정의 단계

6 Pager : 새로운 아이디어를 A4 한 장 분량으로 제안하는 문서로, 아마존에서 시작된 소통 도구이다. PPT처럼 부수적인 작업을 줄이고, 효율적인 논의를 통해 사업 방향과 목표를 정리할 수 있다. 다양한 양식이 있지만 보통 (1) 문제 정의, (2) 해결책 제안, (3) 이행 계획, (4) 예상 결과를 포함한다.

� 아마존 6 Pager의 Notion 템플릿

PRD (Product Requirements Document) : 제품 개발을 위한 요구사항을 정리한 문서로, 주요 기능 목록과 기술적 고려사항 등이 포함되어 프로젝트의 제약 조건을 설정할 수 있다. 디자이너와 개발자는 PRD를 참고하여 작업 범위와 우선순위를 명확히 한다.

� Notion의 다양한 PRD 템플릿 공유 링크

1 Pager, 6 Pager, PRD는 주로 서비스 기획자 또는 프로젝트 오너(PO)와 리더(PL)가 작성한다. 이후로는 디자이너가 직접 제작하는 시각적 커뮤니케이션 도구로 볼 수 있다.

기능 명세서 : 각 기능의 작동 방식을 세부적으로 정리한 표 형식의 문서로, 팀의 상황에 따라 기획자, 디자이너, 개발자 등 다양한 팀원이 작성한다. 입력값(input), 출력값(output), 상태 변화(status) 등을 포함하며, 인터페이스의 구성 요소와 사용자의 행동, 작동 결과를 구체적으로 정의한다. 구현 과정에서 팀원들 간의 혼선을 줄이는 데 가장 중요한 역할을 하며, 개발자와 디자이너 간의 소통 도구로 활용된다.

두 번째, 서비스 설계 단계

정보 구조도 (IA, Information Architecture) : 서비스의 콘텐츠 조직도로, 사용자에게 제공되는 정보가 어떻게 메뉴에 소속되고 분류되는지를 시각화한다. 표 외에도 사이트맵이나 인포그래픽으로 디자인을 더하여 보여줄 수 있다. UX 디자이너는 이를 통해 네비게이션 구조를 설계한다.

플로우 차트 (Flowchart / User Flow) : 기능 명세와 정보 구조를 고려하여 서비스의 사용 순서를 기호와 도형, 화살표로 나타낸 도식이다. UX 디자이너는 이를 통해 이동 경로, 화면 전환, 조건 분기점을 제시하여 서비스 흐름을 시각적으로 정리한다. 약속된 기호를 사용하여 직관적으로 구성하기 때문에 기획자, 개발자와 서비스 구조를 명확히 이해하고, 사용자의 경로를 파악하는 데 유용하다.

스토리보드 (Storyboard) : 프로덕트가 어떤 맥락에서 등장하고 어떻게 사용자와 연결되는지를 구성한 시나리오이다. 인터페이스 스케치에 집중할 수도 있고, 예시처럼 사용자의 입장에서 컷씬으로 서비스의 핵심 가치까지 표현할 수도 있다. “어떤 화면들이 있고, 어떤 순서로 사용자에게 보여줄까?”가 핵심이다. UX 디자이너는 사용자가 서비스와 인터랙션 하는 상황을 정의하여 주요 과업(Main/Sub Task)을 리스트업 한다. 이를 기준으로 우선순위가 높은 기능(Feature)을 선별해, 디자이너와 개발자가 UI를 구현하는 단위로 활용할 수 있다.

여기까지는 사용자의 여정을 바탕으로, 기능과 구조를 통해 경험을 설계하는 UX 디자인 단계이며, 이후부터는 화면의 구성과 시각적 표현의 완성도를 높이는 UI 디자인 영역이다. 지난 글에서 다룬 것처럼, UX 디자이너의 세부 직군에 따라 이를 수행하는 사람은 다양할 수 있다.

세 번째, 화면 설계 단계

와이어프레임 (Wireframe) : 스토리보드에서 정리된 각 화면의 구조를 단순하게 시각화한 디자인 초안이다. 빠른 아이디어 검토를 위한 스케치 수준의 Lo-fi(Low Fidelity)부터, 인터랙션 아이디어를 반영해 고도화된 프로토타입 형태의 Hi-fi(High Fidelity)까지 다양한 퀄리티로 제작된다. 여러 레이아웃을 자유롭게 실험할 수 있는 초기 UI 설계 도구이다.

화면 정의서 (Screen Specification) : 확정된 와이어프레임을 바탕으로, 각 화면의 구성 요소를 배치하고 요소별 기능과 상태를 상세히 설명한 최종 인터랙션 정의서이다. 기능 명세서, 정보 구조도, 사용자 시나리오가 반영되며, “각 화면에서 무엇이 보이고, 어떻게 작동해야 할까?”가 핵심이다. 이 문서를 기준으로 그래픽 또는 비주얼 디자이너는 최종 화면을 제작하고, 개발자는 UI와 기능을 정확히 구현한다. 팀 작업에서 가장 많이 활용되며, 일관된 결과물을 위한 기준이 된다.

프로토타입 (Prototype) : 화면 정의서와 GUI 디자인을 바탕으로 제작된, 실제 동작을 반영한 시뮬레이션이다. 사용자의 클릭, 입력, 화면 전환 등 주요 인터랙션을 구현해 화면 간 흐름과 기능을 검증할 수 있다. 정적 시안에 머물지 않고 실제 서비스처럼 동작하는 모습을 팀에 공유할 때 활용되며, 사용자 테스트나 클라이언트 리뷰에서도 효과적인 소통 도구가 된다.

네 번째, 구현 및 검수 단계

디자인 가이드라인 (Design System, Style Guide) : 색상, 타이포그래피, 아이콘, 레이아웃 그리드 등의 시각적 기준을 정리한 문서로, 서비스를 구현할 때 디자인 일관성을 유지하기 위한 자산(Asset)이다. 주로 GUI 결과물과 함께 인터페이스 요소를 컴포넌트 단위로 정리하여 UI Hand off 과정에서 전달한다. 위계(Hireachy)에 따라 템플릿처럼 정리해 두면, 다른 디자이너나 개발자가 동일한 기준으로 새로운 UI를 빠르게 구현할 수 있다. 팀의 규모가 커질수록 핵심 소통 도구가 된다.

디자인 QA 체크리스트 (QA Checklist) : 개발된 화면이 디자인 의도와 일치하는지 점검하는 표 형식의 소통 도구이다. 디자이너와 개발자가 협업해 최종 품질을 검수하며, 작은 오류도 놓치지 않도록 효율적으로 관리해야 한다. 실시간 진행 상태, 분류 태그, 우선순위 라벨 등으로 이슈를 정리하고 처리한다. 관리가 체계적이지 않으면 무한 피드백의 굴레에 빠지기 쉬우며, 실제로 가장 많은 시간이 소요된다.

목업 (Mockup) : 목업은 프로덕트를 실제와 유사한 환경에 합성한 정적 시안으로 시각적 완성도를 공유하는 도구이다. 화면이라면 TV, 스마트폰, 배너 등 실제 디바이스에 합성하고, 제품이라면 3D 렌더링으로 구현해 보여준다. 필요에 따라 스토리보드에 등장했던 사용자 상황을 연출하기도 한다. 클라이언트나 외부 이해관계자에게 최종 이미지를 명확히 전달하여, 프로토타입이 피드백을 위한 도구라면 목업은 프레젠테이션이나 홍보용으로 활용된다.

온라인 커뮤니케이션의 함정

최근 협업은 대부분 온라인으로 이루어지며, 시각적 자료만으로는 디자이너의 의도가 충분히 전달되지 않는 경우가 많다. "Dev 모드에서 픽셀 값 다 확인할 수 있잖아요." 많은 디자이너들이 이렇게 생각한다. 하지만 Dev 모드는 표면적인 수치값일 뿐이고, 만능이 아니다. 디스크립션이 부족하면 결과물은 디자인 의도와 멀어지고, 피드백은 반복된다.

Figma의 Dev 모드 (공식 사이트 이미지 발췌)

자료를 처음 보는 개발자가 프레임을 순서대로 비교하며 사용 맥락을 추측할 필요 없도록, 상태 전환 조건과 시각적 반응을 명확히 정의해야 한다. 설명 글이 없는 Hand off는 늘 추가 질문이 n차로 이어진다. 결국 디스크립션은 팀의 실행력을 높이는 핵심 도구이다.

디스크립션은 대체로 기획자의 역할로 여겨지지만, 기획자의 디스크립션이 곧 정책서라면 디자이너의 디스크립션은 설명서에 가깝다. 인터랙션의 디테일은 디자이너가 가장 잘 알기에, 이를 설명하는 것은 디자이너의 책임이다. 디자인은 기획과 개발 사이에 위치한 만큼, 커뮤니케이션 범위가 곧 팀의 구현 역량이 된다. 각 화면을 실현하는 입장에서 디스크립션은 디자이너에게 필수적이다.

기획자와 디자이너의 디스크립션 차이 (예시)

디자이너의 디스크립션은 화면의 구조적 정렬, 시각적 변화, 모션 타이밍 등 세부적인 표현 방식을 명확히 전달하는 데 중점을 둔다. 개발자가 구현 과정에서 오해하지 않도록 예외 상황, 애니메이션 타이밍, 레이아웃 기준, 그리고 참고한 디자인 정책이나 컴포넌트 코드네임 등을 명확하게 기술해야 한다.

디자인한 Frame을 글로 정리하는 것이 익숙하지 않다면, 처음에는 인터페이스 요소를 딱 집어 댓글처럼 달아두는 주석(annotation)이나 코멘트(comment) 기능을 활용해 보자. Figma, Framer 등 다양한 툴에서 부담 없이 시작할 수 있고, 개발자의 질문과 그에 대한 답변을 쌓아가는 과정만으로도 디스크립션 스킬은 발전한다. 이렇게 쌓인 간단한 설명들이, 다음 프로젝트에서 디스크립션으로 정리할 내용의 기준점이 된다. 개발자의 질문을 미리 대비한 체계적인 디스크립션으로 점차 더 명확하고 일관된 커뮤니케이션이 가능해진다.

---

결국은 사람과 소통하는 일

‘사업은 결국 사람이 반’이라는 말이 있다. 프로젝트도 마찬가지다. 물론 잘 맞는 팀원과 함께할 수 있다면 이상적이겠지만, 현실에서 팀은 다양한 배경과 관점을 가진 사람들로 이루어진다. 원하는 사람만으로 팀을 꾸리기는 어렵고, 결국 중요한 것은 서로 다른 사람들이 같은 방향으로 나아가도록 조율하는 일이다. 그래서 많은 팀과 회사가 소통 능력을 중요하게 여긴다.

사람과의 대화는 실행력을 만들어낸다. 디자이너는 그 대화의 중심에 서 있다. 도구나 기술보다 중요한 것은, 상황에 맞게 소통의 방식을 선택하고 활용하는 능력이다. 스토리보드, 화면 정의서, 프로토타입, 디스크립션 같은 도구는 단순한 결과물이 아니라, 팀을 연결하기 위한 수단이다. 어떤 도구든 맥락 없이 던져서는 의미가 없고, 언제 글로 설명하고 언제 시각적으로 보여줄지, 그 균형을 설계할 줄 알아야 한다. 결국, 상황에 맞는 소통을 설계하고 이끌어가는 디자이너가 좋은 결과를 만든다.