Alvin Gyumin Choi

에이치디정션 DesignOps

소속: 에이치디정션 HD Junction

제품 개발 조직이 커지고 이해관계자가 늘면서 Product Discovery·Design 과정에서 갈등과 비효율이 드러났습니다.
이 단계에서 겪는 실무자의 불편함과 생산성 저하를 해소하기 위해 UX Team에서 문제를 조사하고 구성원의 공감대를 형성했습니다. 이후 다른 팀과의 협업을 통해 문제를 해결하는 DesignOps 프로젝트를 시도했습니다.


진행 과정

문제의식으로 시작

  • Product Owner의 퍼포먼스와 퀄리티가 떨어지고 있다는 조직 내 인식
  • Product Owner는 UX Designer보다 2~3배 많았지만, Product Owner의 업무에서 병목 발생
  • Product Owner에게 도움이 필요한 문제가 있는지, 각 직무 간 소통이 효과적으로 이루어지고 있는지 확인할 필요가 있다고 판단

조직의 공동 과제로 다루기 위해 UX Team 내부·외부의 동료들과 공감대 형성

  • 점심 식사, 커피챗 등 자연스럽고 반복적인 스몰톡으로 동료들이 겪는 문제와 익숙해진 불편을 수집하고, 동료들의 문제에 공감한다는 태도를 지속
  • 일정 초대에 장문의 메시지를 덧붙여 해결하려는 문제와 DesignOps 활동의 목적을 미리 공유하고, DesignOps 활동이 문제 해결에 도움이 될 수 있음을 설명

인터뷰와 설문조사로 문제 발견, 이미 알려진 문제와 교차 검증

  • 직무 전문성을 발휘하기 어려운 기획 방식과 협업 구조
    • 만들어야 할 기능이 리더들에 의해 미리 정해져 있음
    • 사용자 행동보다 기능과 페이지를 중심으로 기획해 유저 플로우가 자연스럽게 연결되지 않음
    • Product Owner가 상세한 와이어프레임을 작성한 뒤 메이커와 다른 이해관계자가 검토하는 순차적 방식
    • 개발 완료 이후 비즈니스 이해관계자가 요구사항과 맞지 않는다며 태스크가 번복되는 사례 발생
  • 기획 산출물의 활용 방식
    • 구성원은 업무에 필요한 정보를 얻기 위해 기획서를 확인
    • 기획서만으로 사용자가 제품을 이용하는 흐름을 연상하는 데 한계가 있으며 메이커가 아닌 이해관계자의 경우 이 현상이 두드러짐
    • Frontend Engineer는 개발 과정에서 와이어프레임보다 디자인을 주로 참고
    • Backend Engineer는 UI가 기능을 이해하는 데 도움이 된다고 답했지만, 디자인보다 와이어프레임을 선호하지는 않음
    • 다시 말해, 소통에 필요한 수준을 넘어 와이어프레임의 완성도를 높이는 데 많은 시간을 사용
  • 도구와 정보 관리
    • 기획과 디자인 과정에서 여러 도구를 함께 사용해 같은 정보를 반복해서 이전·관리
    • 메이커가 매번 다른 Product Owner와 협업하는 구조 특성상, Product Owner마다 다른 기획 문서 양식이 필요한 정보를 찾기 어렵게 만듦

조사 결과를 바탕으로 목표 수립

  • 산출물의 완성도보다 사용자 흐름, 정책, 의사결정에 필요한 정보를 효과적으로 전달하는 일을 우선
  • 프로젝트 시작 전 문제와 근거를 충분히 검토하고, 실무자가 의사결정에 참여하는 구조 마련
  • Product Owner의 업무에서 효용이 낮거나 다른 직무가 처리할 수 있는 작업을 제거·대체·위임해 병목 해소
  • 파편화된 도구를 통합·대체해 기획과 디자인 자산을 쉽게 공유하고, 도구 사이에서 정보를 반복해서 옮기는 작업 축소
  • 결과물의 양식을 통일해 필요한 정보를 찾고 결정하는 비용 절감
  • 이번 시도가 일회성 개선에 그치지 않고 동료들이 직접 문제를 해결하도록 DesignOps 문화 정착

진행 과제와 결과 (협업·위임으로 병렬 진행, 완료는 ✅ 표시)

필수 과제

  1. 직무 만족도 설문조사 (NN Group의 DesignOps 프레임워크 활용)
    • HR·SRE 팀과 설문조사 문항 설계 완료
    • 퇴사로 인해 실행은 하지 못함
  2. 프로젝트 선정 방식과 소통 구조 개편 ✅
    • 고위 리더뿐만 아니라 Product Owner, UX Designer 등의 실무자도 이른 시점의 의사결정에 합류
    • 실무자가 구체적인 해결책을 결정하도록 위임 (어떤 기능을 만들어야 하는지 → 어떤 문제를 해결해야 하는지)
  3. 제품 기획 방식과 역할 개편 ✅
    • 아이디어 탐색 단계부터 메이커와 이해관계자가 자주 대화하며 함께 구체화
    • 와이어프레임을 소통에 필요한 수준으로 간소화해 산출물보다 의사결정에 집중
    • UX Designer가 완성된 기획을 전달받는 대신 초기부터 사용자 경험을 함께 설계하도록 역할 조정
  4. 기획 문서 플랫폼 검토 및 마이그레이션 (Axure → Figma·Confluence) ✅
    • 정형화된 와이어프레임 도구에서 탈피
    • 기획과 디자인 자산을 더 쉽게 공유할 수 있도록 개선
  5. 디자인 플랫폼 검토 및 마이그레이션 (Sketch·Zeplin·Abstract → Figma) ✅
    • 도구 사이에서 정보를 반복해서 옮기는 작업 축소
  6. 서비스·매뉴얼 용어 통일 및 사전 작성 ✅
    • 이해관계자 간 의사소통 오류를 줄이고, 매뉴얼 제작 과정에서 표현을 매번 찾거나 새로 결정하는 비용을 절약

선택 과제 (구성원이 해보고 싶은 일)

  1. Design System 브랜딩 (Principle, UX Writing)
  2. Design System 문서 마이그레이션 및 고도화 (React Styleguidist → Docz)
  3. UX Writing 도구 제작 (Figma Plugin, Lint)

성과와 한계

  • 동료들이 각 과제의 문제 해결에 자발적으로 참여하면서 서로 다른 직무가 개별적으로 겪던 불편과 갈등을 조직의 공동 문제로 인식하고 해결하게 됨
  • 퇴사로 인해 성과를 장기간 측정하지 못해 즉각적인 변화와 산출물만 확인, 일부 과제는 완료하지 못함

담당 역할

  • 문제 인식 조사, 개인·팀 단위 소통 추진 및 공감대 형성
  • 과제 분할 및 위임, 진행 상황 확인 및 지원
  • 직무 만족도 설문조사 설계
  • 제품 개발 프로세스 개편 참여

돌아가기