Showing Posts From

사이의

디자이너와 개발자 사이의 기획자, 중재자가 되는 법

디자이너와 개발자 사이의 기획자, 중재자가 되는 법

오늘도 통역 중 오전 10시. 화면 정의 회의. 왼쪽엔 디자이너 수진님. 오른쪽엔 개발자 민수님. 나는 가운데. 수진님: "이 버튼은 사용자가 누를 때 약간 바운스되면서 피드백이..." 민수님: "그거 애니메이션 라이브러리 새로 써야 하는데요." 시작도 안 했는데 벌써 삐걱. 나: "일단 스펙부터 정리할게요." 피그마 켜고 화면 공유. 지라 티켓 열고. 노션에 정리 시작. 5년 차 되니까 안다. 이런 상황에서 누가 옳고 그른 게 아니라는 걸. 둘 다 각자의 영역에서 최선을 고민하는 거다. 문제는 언어가 다르다는 것.디자이너의 언어 수진님은 사용자 경험을 생각한다. "이 화면에서 저 화면으로 넘어갈 때, 자연스러운 트랜지션이 있어야 사용자가 맥락을 이해해요." 맞는 말이다. 인터랙션은 중요하다. 하지만 개발자 입장에선 '자연스러운 트랜지션'이 뭔지 모른다. 300ms? 500ms? fade? slide? 라이브러리는? CSS로 가능한지? 이럴 때 내가 하는 것.레퍼런스 찾기 "인스타그램 스토리 넘기는 느낌이요? 아니면 토스 화면 전환?"수치로 변환 "300ms 정도면 될까요? 민수님, 이 정도면 네이티브로 가능하죠?"우선순위 정리 "이번 스프린트엔 기본 전환만. 다음에 고도화."디자이너의 비전을 개발 가능한 스펙으로 바꾸는 작업. 통역이다. 정확히. 수진님: "아, 그렇게 말하면 되는구나." 나: "네. 다음엔 바로 이렇게 얘기해주세요." 회의록에 적는다.화면 전환: slide 애니메이션, 300ms, ease-in-out 레퍼런스: 토스 메인 화면 전환 우선순위: P1 (이번 스프린트)개발자의 언어 민수님은 기술 구현을 생각한다. "이 기능 API 새로 만들어야 하는데, 2주 걸려요." 디자이너는 당황한다. 화면 하나 추가인데 왜 2주? 이럴 때도 통역. 나: "수진님, 이 화면에 실시간 업데이트 필요하잖아요. 그러려면 웹소켓 연결이 필요해서 백엔드 작업이 커요." 수진님: "아... 그럼 일단 새로고침 버튼으로 시작하면 안 돼요?" 민수님: "그건 하루면 됩니다." 해결. 개발자가 '안 된다'고 할 때, 진짜 물리적으로 불가능한 게 아니다. 시간/리소스/기술 부채를 고려한 판단이다. 이걸 디자이너에게 설명하려면:기술 용어를 풀어서 "API는 서버랑 대화하는 거예요. 지금은 대화 통로가 없어서 새로 만들어야 해요."대안 제시 "실시간은 나중에. 일단 수동 새로고침으로 MVP 만들죠."트레이드오프 설명 "이거 지금 하면 다른 기능 2개는 밀려요."디자이너: "그럼 우선순위 조정해야겠네요." 나: "네. 대표님께 공유드릴게요." 지라 티켓에 적는다.[Backend] 실시간 업데이트 API 구축: 10 story points, Sprint+2 [Frontend] 수동 새로고침 버튼: 2 story points, 현재 Sprint 의존성: 백엔드 완료 후 프론트 고도화 가능중재의 기술 사실 이 일이 제일 어렵다. 둘 다 프로페셔널이다. 각자 영역에서 최선을 추구한다. 하지만 목표가 다르면 충돌한다. 디자이너: 최고의 사용자 경험 개발자: 안정적이고 유지보수 가능한 코드 둘 다 맞다. 그래서 더 어렵다. 지난주 실제 상황. 수진님: "이 페이지, 사용자별로 맞춤 레이아웃 보여주면 좋겠어요." 민수님: "그거 개인화 알고리즘 개발해야 해요. 3개월 프로젝트인데요." 둘 다 나를 본다. 나: "좋아요. 일단 목표부터 정리하죠." 화이트보드에 쓴다.문제: 사용자가 원하는 콘텐츠 찾기 어려움 목표: 콘텐츠 발견율 30% 증가 제약: 현재 스프린트 2주나: "개인화가 목표인가요, 콘텐츠 발견이 목표인가요?" 수진님: "콘텐츠 발견이요." 나: "그럼 대안이 있어요. 카테고리 필터 강화하면?" 민수님: "그건 이번 스프린트에 가능해요." 수진님: "음... 일단 그걸로 데이터 보고 개인화는 다음 분기에?" 나: "좋아요. 민수님 개발하시고, 수진님은 필터 UI 디자인. 2주 후 릴리즈하고 데이터 보죠." 중재의 핵심은 이거다.목표로 돌아가기 무엇을 해결하려는가? 방법은 여러 개다.제약 인정하기 시간, 인력, 기술. 현실을 본다.대안 제시하기 한 방법이 안 되면 다른 방법. 항상 플랜 B.단계 나누기 지금 할 것, 나중 할 것. MVP 사고.컨플루언스에 정리한다. 콘텐츠 발견율 개선 방안Phase 1: 카테고리 필터 강화 (2주) Phase 2: 데이터 수집 및 분석 (4주) Phase 3: 개인화 알고리즘 검토 (분기 단위)두 사람 다 고개 끄덕인다. 언어 배우기 5년 전엔 이게 안 됐다. 디자이너가 "인터랙션"이라고 하면 무슨 소린지 몰랐다. 개발자가 "API"라고 하면 긴장했다. 지금은 안다. 둘 다 배웠으니까. 디자인 배우는 법:피그마 직접 써본다. 기초 기능은 안다. UI/UX 기초 책 읽는다. "Don't Make Me Think" 같은 거. 디자인 시스템 공부한다. Atomic Design, 8pt grid. 레퍼런스 많이 본다. 좋은 앱 쓸 때 화면 캡처.개발 배우는 법:기술 용어 정리한다. API, DB, 서버, 클라이언트. 개발자 회의 듣는다. 모르면 나중에 물어본다. 간단한 코드 읽어본다. HTML, CSS 정도는. SQL 배운다. 데이터 직접 뽑을 수 있으면 협업 빨라진다.완벽하게 알 필요 없다. 디자이너처럼 디자인할 순 없다. 개발자처럼 코딩할 순 없다. 하지만 그들의 언어를 이해하면 된다. 통역하려면 양쪽 언어를 알아야 한다. 요즘은 수진님이 "이거 API 호출 몇 번이에요?"라고 물어본다. 민수님은 "사용자 플로우상 여기서 막히는데요?"라고 말한다. 서로 언어를 배우고 있다. 내가 계속 통역해줘서. 좋은 신호다. 회의록이 답이다 중재의 증거는 문서다. 말로만 하면 나중에 "그런 적 없는데요?"가 나온다. 그래서 나는 회의 때마다 적는다. 컨플루언스에 템플릿 만들어뒀다. 화면 정의 회의록일시: 2024.01.15 10:00 참석: 수진(디자인), 민수(개발), 나(기획) 안건: 홈 화면 개편결정 사항화면 전환 애니메이션: slide, 300ms 실시간 업데이트: Phase 2로 연기 카테고리 필터: 이번 스프린트액션 아이템 수진: 필터 UI 디자인 (01.17까지) 민수: 필터 API 개발 (01.22까지) 나: 대표님 보고 (01.16)이슈/리스크실시간 업데이트 딜레이로 사용자 피드백 우려 대안: 수동 새로고침 버튼 명확히 노출이렇게 적어두면:누가 뭘 하기로 했는지 명확 나중에 왜 이렇게 결정했는지 추적 가능 대표님한테 보고할 때 근거 자료말싸움 날 때 회의록 꺼내면 끝난다. "여기 보세요. 그때 이렇게 합의했어요." 문서는 기획자의 무기다. 감정 관리 사실 제일 어려운 건 이거다. 디자이너도 사람. 개발자도 사람. 나도 사람. 수진님이 열심히 만든 디자인, 민수님이 "이거 구현 힘든데요"라고 하면 기분 상한다. 민수님이 고민해서 짠 코드, 수진님이 "근데 이거 왜 이렇게 느려요?"라고 하면 짜증난다. 나는 그 사이에서 감정까지 조율한다. 수진님한테: "민수님이 안 된다는 게 아니라, 시간이 더 필요하다는 거예요. 기술적으로 복잡해서." 민수님한테: "수진님이 완벽주의라서 그래요. 사용자 경험 진짜 중요하게 생각하시거든요. 최대한 맞춰드리면 나중에 QA 때 편해요." 양쪽 다 이해시킨다. 그리고 내 감정도 관리한다. "왜 나만 힘들지?" 생각하면 끝이다. 중재는 원래 힘들다. 양쪽 다 만족시킬 순 없다. 목표는 최선의 타협. 완벽한 디자인도, 완벽한 코드도 아니다. 주어진 시간에 최선의 결과. 그걸 받아들이면 조금 편하다. 신뢰 쌓기 중재가 되려면 신뢰가 필요하다. 수진님과 민수님이 나를 믿어야 내 말을 듣는다. 신뢰는 어떻게 쌓나?약속 지키기 "내일까지 정리해드릴게요." 하면 정말 한다.양쪽 이해하기 디자이너 편도, 개발자 편도 아니다. 프로덕트 편.솔직하기 "이거 제가 잘 모르겠어요. 같이 알아봐요." 괜찮다.인정하기 "수진님 디자인 정말 좋았어요." "민수님 코드 리뷰 감사합니다." 진심으로.실수 인정하기 "제가 스펙을 명확히 안 적어서 혼선 있었어요. 죄송해요." 당당하게.시간 걸린다. 1년 정도? 지금은 수진님도 민수님도 내가 중간에서 정리하면 따라온다. 내가 "이게 최선"이라고 하면 믿는다. 그 신뢰가 있어서 중재가 가능하다. 실패 사례 잘될 때만 있는 건 아니다. 지난달에 망한 적 있다. 새 기능 기획. 디자이너는 복잡한 인터랙션 원했고, 개발자는 단순하게 하자고 했다. 나는 디자이너 편을 들었다. "사용자 경험이 중요하니까." 결과: 개발 일정 2주 초과. 버그 투성이. 결국 롤백. 민수님이 그랬다. "진짜님, 그때 제 말 들으셨어야죠." 맞다. 내가 기술적 제약을 무시했다. 교훈:한쪽 편 들면 안 된다. 기술 제약은 진짜 제약이다. 개발자가 "힘들다"고 하면 정말 힘든 거다.다음부터는 양쪽 의견 다 듣고 천천히 결정한다. 실패도 배움이다. 도구 활용 중재를 돕는 도구들. Figma: 디자이너랑 같은 화면 본다. Jira: 개발자랑 같은 일정 본다. Confluence: 모두가 같은 문서 본다. Slack: 비동기 소통. Zoom: 얼굴 보며 회의. 특히 Figma는 중요하다. "이 버튼이요"가 아니라 Figma 링크 공유하면 오해가 없다. "이 티켓이요"가 아니라 Jira 티켓 번호 말하면 명확하다. 도구는 언어를 통일시킨다. 그리고 Notion. 나만의 중재 가이드를 정리해뒀다. 디자이너-개발자 중재 체크리스트 목표 명확히 하기 제약 조건 확인하기 대안 3개 준비하기 우선순위 정하기 단계 나누기 회의록 작성하기 액션 아이템 할당하기회의 전에 이거 보면 덜 헤맨다. 지금도 배우는 중 5년 차지만 아직도 어렵다. 어제도 회의에서 막혔다. 수진님: "이 화면 구조 바꿔야 해요." 민수님: "지금 바꾸면 DB 마이그레이션이..." 나: "음... 일단... 데이터 보고...?" 명확한 답이 안 나왔다. 결국 CTO님께 여쭤봤다. 아직 모르는 게 많다. 하지만 계속 배운다. 디자인 강의 듣는다. 개발 세미나 간다. PM 커뮤니티에서 물어본다. "중재 잘하는 법" 같은 글 찾아 읽는다. 다른 기획자들은 어떻게 하는지. 그리고 매번 회고한다. "오늘 회의는 왜 잘 됐지?" "저번엔 왜 안 됐지?" 반복하면 조금씩 는다. 보람 힘들지만 보람도 있다. 지난주 릴리즈. 수진님 디자인에 민수님 개발. 내가 중간에서 조율했다. 출시 후 사용자 반응 좋았다. 리뷰 평점 4.7. 수진님: "우리 잘했네요!" 민수님: "다음엔 더 잘할 수 있을 것 같아요." 둘이 하이파이브. 나도 기분 좋다. 이게 중재의 보람이다. 혼자서는 못 만드는 걸 함께 만든다. 그 사이에 내가 있다. 다리 역할. 보이진 않지만 없으면 안 되는.오늘도 회의 3개. 내일도 통역 중이다. 피곤하지만 할 만하다.