Successfully reported this slideshow.
Your SlideShare is downloading. ×

당신이 UX Design Project에 참여할 때 알아야 할 것들

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 43 Ad

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Advertisement

Similar to 당신이 UX Design Project에 참여할 때 알아야 할 것들 (20)

Recently uploaded (20)

Advertisement

당신이 UX Design Project에 참여할 때 알아야 할 것들

  1. 1. “당신이 UX프로젝트에 참여할 때 알아야 할 것” Fasoo.com Vital Day 2015.09.22 Dong sik Yang
  2. 2. 반갑습니다. 열정적으로 UX 기획 중인 간지나는 파수인들
  3. 3. 이상과 현실 UX = 프로젝트의 구성요소 중 하나 그냥 당연한 것 UX = 혁신가의 특별한 소양 특별한 것
  4. 4. Product CEO 의 통찰 사용자의 시각 개발자의 니즈 마케팅 전략 시장의 기회 유지보수의 용이성 타협이 아니라 더 좋은 결론을 위한 조화 프로젝트 관리자의 방향 투자자의 압박
  5. 5. 오늘의 목표 “다양한 입장을 가진 사람들이 협업 할 이슈가 너무나도 많이 발생하는 UX 디자인 프로젝트를 성공적으로 수행하기 위해서 우리가 알아야 할 것은 무엇일까?”
  6. 6. 질문 시간 1. 프로젝트가 뭐라고 생각하십니까? 2. 프로젝트와 프로세스의 차이점을 설명하실 수 있으신가요?
  7. 7. 프로젝트의 기본 속성 1. 시작과 끝이 있어요. 2. 고유한 결과물을 생성합니다. 3. 점진적으로 구체화 됩니다.
  8. 8. 이런 건 프로젝트 이런 건 프로세스 프로젝트 & 프로세스
  9. 9. UX 프로젝트란? “디자인을 통해 특정한 경험을 사용 자에게 제공하는 제품 및 서비스 혹 은 그에 준하는 대상을 구축하는 프 로젝트”
  10. 10. UX 프로젝트의 범위 사용자 경험 (UX) MAP 실제의 디지털의 개인적인 사회적인 모델 하우스 인테리어 문 손잡이 모바일폰 문자 입력 회사 주최 마라톤 대회 참가 신발 포장 디자인 문서 DRM 해제 하기 페이스북에 좋아요 누르기 고객 센터와 화상 채팅 구글에서 타겟 키워드 광고 보기 위키에서 정보 검색 프렌즈팝 하트요청하 기 심야식당 방문
  11. 11. UX 프로젝트의 범위 사용자 경험 (UX) MAP 실제의 디지털의 개인적인 사회적인 모델 하우스 인테리어 문 손잡이 모바일폰 문자 입력 회사 주최 마라톤 대회 참가 신발 포장 디자인 문서 DRM 해제 하기 페이스북에 좋아요 누르기 고객 센터와 화상 채팅 구글에서 타겟 키워드 광고 보기 위키에서 정보 검색 프렌즈팝 하트요청하 기 심야식당 방문 오늘 논의할 UX 디자인의 범위
  12. 12. UX 프로젝트의 특성 1. 다양한 입장이 상충되고 갈등을 유발하는 경우가 많습니다. 2. 구체화를 위해 무지하게 많은 반 복이 필연적입니다. 3. 결과를 예측하기가 힘듭니다. 4. 성과를 측정하기가 다른 프로젝 트에 비해 상대적으로 힘듭니다.
  13. 13. 프로젝트를 진단해 봅시다. 자기 입장만 내세우고 다른 사람 말을 들을 생각을 안 하는 기획자, 개발자 혹 은 디자이너 혹은 PM 혹은 CEO, 혹은 영업 담당자를 본 적 있다. 매일 바뀌는 개발 요구 사항에 빡친 적 있다. 아무리 일해도 구체화 되지 않는 제품 형상에 좌절한 적이 있다. 컨펌은 안 해주고 알아서 잘해오길 기대하는 관리자. 어떻게 알아서 잘해야 하는 지 물어봐도 그건 니가 할 일이지 같은 말만 들어본 적 있다. 내가 작업하는 일이 전체 프로젝트 과정에서 어떤 비중을 차지하고 어떤 기여를 하는 지 일하면서도 잘 모르는 당혹스러움을 느껴본 적이 있다. 의사 결정은 미뤄지고 회의를 빙자한 넋두리 시간만 많아지는 걸 경험해 본 적 있다. 일하다 보니 점점 희미해지고 무의미해지는 것 같은 프로젝트 초기 목표 (난 누군가 또 여긴 어딘가…) 심지어 그 목표도 없이 달린 적도 있다.
  14. 14. 귀 닫고 말만 하기 자기 입장만 내세우고 다른 사람 말을 들을 생각을 안 하는 기획자, 개발자 혹은 디자이너 혹은 PM 혹은 CEO, 혹은 영업 담당자를 본 적 있다.
  15. 15. 매일 매일 바뀌는 요구사항 매일 바뀌는 개발 요구 사항에 빡친 적 있다.
  16. 16. 구체화 되지 않는 제품 형상 아무리 일해도 구체화 되지 않는 제품 형상에 좌절한 적이 있다.
  17. 17. 결정할 줄 모르는 관리자 컨펌은 안 해주고 알아서 잘해오길 기대하는 관리자. 어떻게 알아서 잘해야 하는 지 물어봐도 그건 니가 할 일이지 같은 말만 들어본 적 있다.
  18. 18. 난 누군가 또 여긴 어딘가 내가 작업하는 일이 전체 프 로젝트 과정에서 어떤 비중을 차지하고 어떤 기여를 하는 지 일하면서도 잘 모르는 당 혹스러움을 느껴본 적이 있다.
  19. 19. 회의 시간은 넋두리 시간 의사 결정은 미뤄지고 회의를 빙자한 넋두리만 많아지는 걸 경험해 본 적 있다.
  20. 20. 애초부터 글러 먹은 프로젝트 목표 일하다 보니 점점 희미해지고 무의미해지 는 것 같은 프로젝트 초기 목표 (난 누군가 또 여긴 어딘가…) 심지어 그 목표도 없이 달린 적도 있다.
  21. 21. UX 프로젝트를 성공시키는 가장 좋은 방법 “성공과 실패에 대한 통찰력을 가지고 있고 중요한 현안을 파악하여 빠르게 의사 결정 내려주고 프로젝트 볼륨을 예측해서 일정과 투입 리소스 계획 현실적으로 수립하고 팀 원들을 고무해서 스팀팩 맞은 것처럼 일하 게 만드는 의사소통 완전 잘하는 유능한 인 재를 채용해서 프로젝트 전권을 줘라.”
  22. 22. 유형 / 속성별 구분 커뮤니케이션 사이트 컨텐츠 사이트 과제 기반 어플리케이션 UX 프로젝트 : 제품
  23. 23. 플랫폼 별 구분 UX 프로젝트 : 제품 모바일 (폰, 태블릿) 데스크탑 (PC, POS, 각종 콘솔) 브라우저 (IE, 크롬, 파폭, 오페라, 사파 리…etc) OS (윈도우, OSX, iOS, 안 드로이드, 리눅스) 모바일앱 (Native App.) PC 어플리케이션 모바일웹 웹 어플리케이션 & 웹사이트
  24. 24. UX 프로젝트 : 지식 사용자 조사 컨텐츠 전략 정보 구조 인터랙션 설계 비주얼 디자인 사용성 측정 6가지 핵심 사용자 경험 분야 (지식 영역)
  25. 25. 프로젝트 매니저 정보 설계자 인터랙션 디자이너 비즈니스 애널리스트 브랜드 전략가 카피 라이터 비주얼 디자이너 프론트 엔드 개발자 백엔드 개발자 UX 프로젝트 : 사람들
  26. 26. UX 프로젝트 : 사람들 역할 커뮤니케이션 사이트 컨텐츠 사이트 과제기반 어플리케이션 정보 설계자 중 최상 중~상 인터랙션 디자이너 중 중~상 최상 사용자 조사 전문가 중 상 상 브랜드 전략가 최상 상 하 비즈니스 애널리스트 하 중~상 최상 컨텐츠 전략가 상 최상 하 카피라이터 최상 상 하 비주얼 디자이너 최상 상 중 프론트 엔드 개발자 상 상 상 백엔드 개발자 중 상 최상 프로젝트 매니저 동일 유형 / 속성별로 본 역할 별 참여도 및 중요도
  27. 27. 정보 설계자 제품의 정보/컨텐츠/기능의 구조를 설계하는 전문가
  28. 28. 인터랙션 디자이너 제품의 상호작용의 흐름을 설계하는 UI/UX 전문가
  29. 29. 사용자 조사 전문가 사용자의 니즈와 행동 패턴을 조사하고 분석하는 전문가
  30. 30. 비즈니스 애널리스트 (또는 프로덕트 매니저) 요구사항을 수집하고 우선 순위를 정의하는 전문가
  31. 31. 브랜드 전략가 기업과 기업에서 생산되는 제품 브랜드의 가 치 관리 담당자
  32. 32. 컨텐츠 전략가 제품에서 제공되는 각종 컨텐츠의 생산 및 관리 전략 수립 담당자
  33. 33. 카피 라이터 텍스트로 유발되는 감성적 경험 담당자
  34. 34. 비주얼 디자이너 시각적인 요소를 통한 감성 경험 전문가
  35. 35. 프론트 엔드 개발자 (퍼블리셔) 인간과 시스템의 실질적 연결고리
  36. 36. 백엔드 개발자 디지털 플랫폼에서 제품을 현실화하는 전문가
  37. 37. 그리고 프로젝트 매니저 프로젝트의 슈퍼 리더 혹은 경영자의 대리인
  38. 38. 그리고 현업의 현실 어쨌든 누군가는 해야하는데 나는 모르겠고…
  39. 39. UX 프로젝트 : 진행 과업 프로젝트 시작하기 프로젝트 목표와 접근 방법론 수립 비즈니스 요구사항 정의 사용자 (고객) 리서치 사용자 모델링 요구사항을 디자인으로 변경하기 UX 프로젝트 기획 산출물 만들기 산출물 단계에서 검증 & 테스트 하기 디자인에서 개발로 전환 프로젝트 팀원들 이론적인 프로젝트 단계 & 과업
  40. 40. UX 프로젝트 : 흐름 파수의 프로젝트 흐름
  41. 41. UX 프로젝트 : 접근 방법론 폭포수 방식 & 애자일(반복형) 방식
  42. 42. 마무리 1. UX 프로젝트(UI가 있는 제품 개 발 프로젝트)의 속성을 이해하자. 2. 반복을 회피하기 보다 의미 있는 반복이 되도록 노력해보자. 3. 함께 일하는 사람들이 뭐 하는 사 람들인지 이해 해보자. 4. 공부를 하자.
  43. 43. Q & A

Editor's Notes

  • 안녕하세요 ED 팀에서 UI 기획 및 설계를 담당하고 있는 양동식입니다. 반갑습니다.
    사실 이번 바이탈 데이가 제 첫 강의는 아니고 2년 전에 UI 프로토타이핑 기법에 대한 강의를 진행한 적이 있었습니다. 뭐 개발자든 기획자든 만들고자 하는 제품의 스펙을 말로만 두루뭉실하게 설명하지 말고 일단 종이든 PPT든 스케치해서 구체화 해야 일이 진행된다...  뭐 이런 내용의 강의였구요. 그 구체화 하는 기법이나 팁에 대해서 간단히 소개 드렸던 기억이 납니다. 뭐 여기에 그때 강의를 들으셨던 분이 계신 지는 모르겠네요.

  • 사실 애매하게 UX가 뭐다 혹은 디자인이 뭐다 하는 원론적이고 졸린 얘기를 또 할 수도 있었는데요. 현실적으로 모든 임직원이 디자인 중심 혹은 사용자 중심 사고방식을 가지고 제품 기획이나 프로그래밍이나 영업이나 마케팅이나 기타 업무를 수행하길 기대하는 건…. 좀 너무 이상적인 얘기가 아닌가 하는 생각이 들었습니다. 저도 거의 4~5년 파수에 몸 담아 보니까 예전보다 사고 방식이 좀 유연하게 바뀐 것 같아요.

    뭔 뜬금없는 얘긴가 하면 예전에 저는 뭔가 사용자 경험을 제공하는 제품을 만드는 조직… 저희 회사도 어느 정도는 해당되겠죠? 그런 조직에 있는 사람들은 최소한 UX가 뭐고 사용자 중심 디자인은 뭐고 그러한 제품을 만들기 위해 사용자를 이해하고 디자인 원칙을 어느 정도는 알아야 하고 해서 조직 자체가 사용자 중심 제품 개발을 할 수 있는 구조로 변화되어야 한다는 생각을 가지고 있었고… 현실적으로 그렇지 않은 상황에 쓸데없이 좌절하곤 했는데… 사실 이게 좀 이상론이더라구요. 스티브 잡스가 성공한 혁신가이긴 하지만 성공하려면 조직의 모두가 스티브 잡스가 되어야만 하는 건 아니거든요. 심지어 스티브 잡스가 200명이나 있을 필요도 없구요. 오히려 조직에 혁신가가 너무 많으면 안 좋을 수도 있어요. 마찬가지로 프로젝트 수행하는 모든 사람이 ux를 최우선으로 하는 사고방식을 견지하는게 더 위험할 수도 있습니다.

  • 일단 일반 사용자가 사용하는 제품을 만들 때도 무조건 사용자 중심, 디자인 중심 관점만 고려할 것이 아니라 실질적으로 해당 제품을 구매하는 구매 담당자나 CEO의 직관, 개발 공정의 이슈나 기술적인 한계, 일정의 문제, 투입 비용의 이슈, 시장의 환경과 기회, 그리고 비즈니스 모델의 합리성… 정말 생각해야 할 것이 많습니다. 제품을 성공시키는데 있어서 사용자 경험만 중요한 게 아니라는 거죠.

    여기서 짚어 볼 것은 하나의 입장이 절대적으로 옳다고 우기는 것이 아니라 이런 다양한 입장을 조정해서 최적의 결과를 끌어내는 과정이 좋은 프로젝트라는 겁니다. 결국 프로젝트 리더는 이런 다양한 입장을 인식하고 조율하고 직관을 토대로 최적의 판단을 할 수 있는 소양이 있어야 되더라구요.
  • 여기서 오늘 강의의 목표가 나옵니다. 오늘 강의는 ‘좋은 제품...그러니까 사용자 중심 디자인으로 구현해서 UX가 쩌는 제품… 뭐 이런 게 저나 UX를 업으로 하는 사람들에게는 좋은 제품의 기준이겠죠? 아무튼 이런 어떻게 보면 일방적인 기준만 만족하는 제품을 만들기 위해 여러분들 UX 디자인을 공부하세요! 라는 내용이 결코 아닙니다. UX가 개 좋으면 뭐합니까. 안 팔리거나 일정 내에 출시가 안되거나 시장 상황에 뒤떨어지거나… 우린 돈 버는 사람이지 예술 하는 사람이 아니잖아요.
    “다양한 입장을 가진 사람들이 협업 할 이슈가 너무나도 많이 발생하는 UX 디자인 프로젝트를 성공적으로 수행하기 위해서 우리가 알아야 할 것은 무엇일까?” 하는 의문을 가진 분들에게 이 정도는 알아야 하지 않을까 하고 이런 류의 프로젝트를 많이 수행해보았던 저의 경험을 공유하고자 하는 게 이번 강의의 목표에요.
  • 그럼 우선 강의에 들어가기 앞서서 질문 하나 할께요.
    프로젝트가 뭐라고 생각하십니까?
    그럼 프로젝트와 프로세스의 차이점을 설명하실 수 있으신가요?
  • 좋은 답변 잘 들었습니다. 프로젝트라는 단어를 안 쓰는 사람은 월급쟁이 중에 단 한 명도 없을 것 같지만 의외로 명확하게 정의하라고 하면 잘 못하는 경우가 많아요. 저도 PMP 자격증 공부도 하고 에이전시에서 6~7년을 PM으로 일했는데도 잘 모르겠어요. 하지만 핵심적인 특성을 간단히 정의하자면

    한시적입니다. 시작과 끝이 있어요. 반면에 프로세스 혹은 운영이라고 불리우는 업무는 끝이 없습니다. 조립 라인에서 자동차를 만드는 건 운영이지만 신차를 연구소에서 설계하는 과정은 프로젝트죠.
    고유한 결과물을 생성합니다. 이른바 산출물이라고 부르는 겁니다. 파수의 경우 최종적인 산출물은 당연히 ‘제품’이겠죠? 최종 산출물이 완성되면 프로젝트는 끝이 납니다.
    점진적으로 구체화 됩니다. 프로젝트 초기부터 마지막에 종료 도장 꽝 찍을 때의 그림을 예측하는 사람은 거의 없습니다. 이걸 잘 예측하면 예지력있는 뛰어난 리더거나 점쟁이겠죠. 여튼 프로젝트는 뭔가 결과를 구체화하는 일련의 과정입니다. 반대로 운영, 프로세스는 처음부터 구체적이고 앞으로도 구체적이고 스펙이 그대로 유지됩니다. 이게 변경되면 신규 프로젝트가 생기는거죠.
  • 더 알기 쉽게 예를 들면 ……

    이렇게 지금까지 존재하지 않았던 새로운 차를 설계하고 목업을 만들고 컨셉을 고민하고 구현타당성과 기술을 리서치하고 하는 과정은 프로젝트고
    개발이 완료되어 생산 계획이 수립된 차량을 양산하는 건 프로세스죠.

    해본 적이 없는 일 (프로젝트) 되풀이하는 일 (프로세스)
    목적은 새로운 것의 창조 또는 커다란 변화 (프로젝트) 목적은 업무의 반복을 통한 가치 창출 (프로세스)
    프로젝트의 목표와 계획이 리더에 의해 변경 가능 (프로젝트) 프로세스는 상당한 계획과 투자에 의해 변경.. 프로세스를 변경하는 것이 곳 프로젝트 (프로세스)
    지도력이 매우 중요 (프로젝트) 지도력 불필요 (프로세스)
    프로젝트는 변화를 창조  (프로젝트) 프로세스는 변화에 저항  (프로세스)

    입니다. 특별히 프로세스를 더 자세히 설명하고자 하는게 아니라 프로젝트를 더 쉽게 이해하기 위해 설명드린 거구요. 프로젝트 매니지먼트에 대한 자세한 내용은 다른 좋은 책들을 읽어보시길 바랍니다. UX나 UX 디자인, 혹은 사용자 중심 디자인과 같은 개념이나 이론들도 웹 서핑을 하시거나 좋은 책을 읽어보시길 바랍니다. 이런 부분은 제가 신입사원 교육이나 예전 바이탈 데이, FMT 등에서 주구장창 언급했던 내용이라 오늘은 스킵할께요. 이런 원론적인 부분에 대해서 관심 있으신 분은 나중에 제 자리로 찾아오시거나 메일 주시면 답변 드리겠습니다.
  • 자 그럼 우린 일단 프로젝트가 뭐고 UX 디자인이 뭔지 알고 있습니다. 잘 몰라도 안다고 칩시다. 그렇다면 UX 프로젝트는 대체 뭐냐.

    제 나름대로 간단히 요약하자면 ‘특정한 사용자 경험을 사용자에게 제공하는 제품 및 서비스 혹은 그에 준하는 대상을 구축하는 프로젝트’라고 정의해 보겠습니다.

    “아니 뭔가 만드는 프로젝트인데 그 산출물이 뭔가 사용자가 경험할 수 있는 껀덕지가 있다는 거 아니냐…” 라고 생각하신 분… 네~ 정확합니다. 괜히 어렵게 이해하지 마시고 우리가 사랑하는 파수의 예를 들면 UI가 있는 제품을 새롭게 만들거나 개선하는 프로젝트가  대표적인 UX 프로젝트구요. (그런데 익스텐션 개발 정도 빼곤 UI가 없는 경우가 거의 없으니....) 6층의 라운지 인테리어 공사도 UX 프로젝트구요. 제품 발표회 때 이벤트 진행하는 것도 UX 디자인 프로젝트고 회사 홈페이지 개선 프로젝트도 UX 디자인 프로젝트죠.
    그럼 일반적으로 우리가 아는 ‘프로젝트와 이 강의에서 얘기하는 UX 프로젝트는 대체 뭔 차이가 있는가’에 대해서 얘기해 볼께요. 제가 오늘 얘기하고 싶은 주제도 결국 ‘일반적인 프로젝트와 다른 UX 프로젝트만의 특성을 이해하고 협업을 잘하자.’이기 때문에 특성을 잘 알아야하겠죠?
  • 그럼 일반적으로 우리가 아는 ‘프로젝트와 이 강의에서 얘기하는 UX 디자인 프로젝트는 대체 뭔 차이가 있는가’에 대해서 얘기해 볼께요. 제가 오늘 얘기하고 싶은 주제도 결국 ‘일반적인 프로젝트와 다른 UX 디자인 프로젝트만의 특성을 이해하고 협업을 잘하자.’이기 때문에 특성을 잘 알아야하겠죠?
    우선 UX 디자인 프로젝트 특성을 얘기하기에 앞서서 UX 디자인에 대해 어느 정도 아시는 분은 인지하시고 계시겠지만 UX 디자인의 범위는 정말 엄청나게 넓습니다. 경험처럼 애매하고 포괄적인 단어가 어디있겠습니까? 아까 제가 예시를 든 파수의 UX 디자인도 디지털 디자인부터 인테리어 디자인, 프로모션 디자인까지 범위가 너무 광범위 하잖아요.
    간단히 이 표를 보시면 UX 디자인의 범위가 얼마나 넓은지 알 수 있을 겁니다.
  • 일단 오늘 얘기하는 UX 디자인의 범위는 이 Map에서 디지털 디자인의 사용자 경험에 포커스를 맞추도록 할께요. 파수로 치면 제품 UI 설계/디자인 영역이라고 이해하면 빠를 겁니다.
  • 자… 이렇게 편의 상 범위를 줄여 봤구요. 그렇다면 이런 UX 프로젝트가 일반적인 프로젝트와 다른 점은 과연 무엇인가 알아봅시다.
    1. 대부분의 프로젝트가 그렇지만 UX 디자인 프로젝트의 경우 정말 다양한 입장이 상충되고 갈등을 유발하는 경우가 많습니다. 특히 다른 프로젝트에는 관계도 없지만 UX 디자인 프로젝트에서만 투입되는 일반인이 보기에 뭘 하는 지 감도 안 잡히는 직군들이 특별히 많아요. 이건 뒷 장에서 설명하겠습니다.
    2. 구체화를 위해 무지하게 많은 반복이 필연적입니다. 다음 항목에서 설명하겠지만 간단한 프로젝트 목표를 다른 것도 아닌 UX로 구체화하는데 굉장히 많은 시간이 소요될 수 밖에 없습니다. 사실 UX 자체가 구체적이지가 않거든요.
    3. 결과를 예측하기가 힘듭니다. 대부분의 프로젝트가 마찬가지지만 변수가 많은 작업을 하는 만큼 결과물의 형상을 예견하기가 힘들죠. 화장실 변기를 교체하는 프로젝트를 수행한다면 목표 달성한 이후의 모습을 간단하게 예측 가능하지만 새로운 컨셉의 MMORPG 게임을 만들자는 프로젝트가 시작된다면 끝을 예측하기가 너무 힘들죠.
    4. 정량화 된 성과를 측정하기가 다른 프로젝트에 비해 상대적으로 힘듭니다. 경험이라는 게 결국 사람의 마음의 영역인데 우리가 좋은 산출물을 만들어냈다는 것을 정량적으로 측정할 수 있는 직접 팩터가 존재하지 않아요. 그런 서비스가 수익을 내거나 트래픽이 오르거나 하는 측정 가능한 척도를 만족했다 하더라도 UX 디자인이 원인 중의 하나라고 유추하는 수준일 수 밖에 없죠.
    만약 여러분이 UX 디자인 프로젝트에 참여하게 된다면 이러한 프로젝트의 특성을 미리 염두에 두고 프로젝트에 임하는 것이 좋을 겁니다. 이 내용만 봐도 알 수 있죠. 다양한 직군의 완전히 다른 이해관계의 사람들이 예상조차 잘 되지 않는 목표를 위해 끊임없이 소통을 빙자한 전쟁을 치루는 생지옥이 바로 UX 디자인 프로젝트라는 걸 말이죠!
  • 이 4가지의 UX 디자인 프로젝트 속성을 보면 그 동안 이런 저런 개발 프로젝트 하면서 우리가 빡쳤던 상황들의 근본 원인을 알 수 있습니다. 다음 체크 리스트들에 해당하는 항목이 과반수를 넘는다면 여러분은 슬프게도 극히 정상입니다. 하나도 없는 경우는… 저도 당혹스럽네요. 그런 분이 있으세요?
    사실 이런 상황을 부정적으로만 보면 이건 프로젝트에 참가하는 나 말고 다른 누군가가 엄청 무능하거나 주변에 월급 도둑만 있거나 회사가 문제거나 갑이 문제거나 팀장이 문제거나 PM이 문제거나 나 빼고 온 세상이 문제거나… 여튼 굉장히 우울한 재앙 같은 상황이긴 하지만 약간만 관점을 바꿔서 생각해보면 그냥 UX 디자인 프로젝트의 일반적인 속성이 좀 안 좋은 형태로 발현된 상황입니다. 재앙이긴 한데 충분히 예상 가능한 범위의 재앙이랄까요? 뭐 그렇다고 ‘회사 일은 원래 다 그래.’라는 뻔한 소리를 하려고 하는 건 아니구요. 오해하진 마세요.
  • 일단 첫째 항목 보겠습니다. 다양한 속성과 이해관계를 가진 사람들은 결국 갈등이 일어 날 수 밖에 없습니다. 이건 필연적인거고 운명이에요. 죽을 둥 살 둥 사랑하던 연인도 싸우고 욕하고 헤어지기도 하는데 별로 친하지도 않고 관심도 없지만 그저 같은 프로젝트 수행 한다는 이유로 회의 때 만나는 사람들과 갈등이 안 생기면 이상하죠.

    아무튼 이러한 갈등을 최소화 하려면 자신과 협업하는 다른 작업자의 직군과 역할 및 그들의 이해관계에 대해서는 좀 알고 이해하도록 노력합시다. 분쟁 조정자 역할을 PM이 수행하겠지만 내 할 일만 하면 되겠지 하는 마인드도 좀 문제가 있어요.
  • 두 번째 항목 봅시다. 개발 요구 사항을 반복적으로 구체화 하는 과정을 거치다 보면 요구 사항이 바뀌는 건 일상적일 수 밖에 없습니다. 최초부터 완벽한 스펙을 딱 정의해서 일을 진행한다면 사실 그건 프로젝트가 아니라 프로세스입니다. 이런 프로젝트의 본질적 속성에 일일이 분노하고 비합리적이라고 하늘을 우러러 포효해봐야 소용없어요.

    문제는 이렇게 애매모호한 프로젝트의 현실을 고려해서 반복작업으로 제품의 형상을 구체화 하는 일정이나 투입 리소스를 미리 고려 해야 하는데 그게 안되는게 가장 큰 문제입니다.
    보통 프로젝트 일정 산정 할 때는 일단 윗 선에 컨펌을 받아야 하니까 한 방에 뚝딱 하고 요건이 결정되어 다음 단계로 휘리릭 넘어가는 비현실적인 상황을 상정하고 프로젝트를 진행하니까 늘 문제가 됩니다. 매번 이렇게 일하면 뭔가 나사 빠진 제품이 나오거나 아니면 과부하 걸린 개발자가 도주를 하거나 하겠죠. 이건 반복을 기반으로 한 구체화 과정을 삽질이나 실패, 뻘 짓으로 생각하는 임직원들의 사고방식이 문제입니다. 이게 바뀌어야 되요.
  • 세 번째 항목은 구체화 되지 않는 최종 산출물에 대한 얘기인데… UX 디자인 프로젝트가 점진적 구체화의 특성을 강하게 가지고 있다고 아까 말씀 드렸는데요. 사실 반복은 엄청 하는 데 구체화가 안 되는 병목 현상이 발생한다면 그 원인은 그 반복 작업들이 유의미한 시도가 아니었거나 충분히 선택할만한 유의미한 시도가 있었음에도 불구하고 의사 결정 주체가 결정을 못했다는 얘기에요.

    무의미한 반복을 해서 쓸데없는 산출물만 늘렸다는 건 작업자들의 업무 방식의 문제일 수도 있고 의지 문제일 수도 있고 작업자들의 역량 문제일 수도 있구요... 충분히 선택자가 제공이 되었는데도 의사 결정이 안 되는 건 관리자의 책임과 권한 문제일 수도 있고 그냥 통찰력이나 판단력이 부족해서 일 수도 있죠.
  • 네 번째 항목은 세 번째 항목과 좀 연관되는 문제인데 사실 프로젝트 리더나 기획 주체도 자신들이 어떤 걸 만들고자 하는 지 프로젝트 초반에는 모르는 경우가 대부분입니다. 잡스도 ‘우왕… 우리 아이팟으로 MP3 시장 먹었으니 터치 기술과 와이파이 기술 붙여서 핸드폰도 만들어보자! 조너선 아이브가 간지나게 디자인하면 잘 팔릴꺼야!’라는 목표만 있었지 그 결과물이 아이폰이 될 줄은 프로젝트 초반에는 몰랐을 겁니다.
    좋은 UX 디자인 프로젝트라도 초기에는 대략적인 제품 컨셉이나 목표만 어느 정도 명확하게 정의되어 있는 수준이지 그걸 달성하기 위해 구체적으로 어떤 제품을 어떻게 만들어야 하는 지 명확한 청사진이 완성된 상태로 일하는 경우는 거의 없어요. 물론 성공에 대한 확실한 근거가 있는 청사진을 그리고 팀원들에게 목표에 대한 확신을 심어 줄 수 있는 통찰력이 있는 리더를 만난다면 이런 고민을 안 해도 되겠죠. 하지만 이건 너무 환상적인 이야기니까 논외로 치고 최소한 이런 상황이라면 관리자가 권위 의식에 매몰되어 팀원들을 일방적으로 몰기 보다는 나도 뭐가 맞는 지 잘 모르겠으니 우리 더 많은 Case를 탐색해보자 하고 팀원을 설득해야겠죠. 물론 같이 열심히 해보자는 리더를 무능력하다고 비웃는 팀원이 있다면 그건 그거 대로 문제겠네요.
  • 다섯 번째 항목은 공황 상태에 빠진 팀원들에 대한 얘기인데 프로젝트 팀원들이 자신의 프로젝트 내에서 R&R이나 해야 할 일의 맥락을 파악 못하는 건 결국 소통의 부재가 나은 재앙입니다. 평소에 서로 대화 좀 하세요. 서로 완성된 산출물만 주거니 받거니하며 일하던 과거 폭포수 형태의 모델에서 점차적으로 애자일과 같은 스피디한 반복형 모델이 프로젝트 방법론의 대세가 되어가고 있는 상황에서 아무리 프로젝트 최말단 작업자라도도 그냥 멍 때리고 일이 주어지길 수동적으로 기다리면 프로젝트가 잘 안돌아갑니다. 프로젝트 상황에 대한 긴밀한 공유가 그만큼 중요하기 때문에 칸반과 같은 애자일 방법론이 요즘 유행을 타는 거라고 생각 합니다.

    제가 예전에 UI 프로토타이핑을 소개 할 때 UI 프로토타이핑의 가장 큰 목적 중의 하나가 UI에 대해서 다른 이해관계를 가지거나 스펙 자체를 잘 이해 못하거나 UI가 뭔지 개념자체가 없는 팀원이나 이해관계자들에게 빨리 실제 제품과 유사한 프로토타입을 뚝딱 만들어서 리뷰 함으로써 ‘프로젝트가 잘 돌아가고 있고 여러분들이 하고 있는 일이 이 프로토타입을 구체화 하는 겁니다’라는 걸 가시적으로 보여주는 것...이라고 설명 드렸었어요.
    커뮤니케이션 산출물을 만드는 건 결국 제품을 구체화 하는 과정이기도 하지만 서로 못 싸워서 안달이 나 있는 타 부서 사람들을 설득하고 으쌰 으쌰 시키거나 뭘해야 할 지 몰라서 멍 때리는 팀원들에게 동기 부여를 하기 위한 목적도 있다는 사실을 명심하시기 바랍니다.
  • 여섯 번째 항목은 의사 결정 지연에 대한 얘긴데… 의사 결정이 미뤄지는 건 관리자에게 권한이 없거나 관리자가 현재 의사 결정하는 걸 두려워하거나 아예 통찰력이 없거나… 여러 가지 원인이 있습니다. 정치적인 이슈도 있을 수 있겠죠. 프로젝트 관리자라면 이 중에서 어떤 문제 때문에 의사 결정이 미뤄지는 건지 생각해 보고 팀원들은 의사 결정권자의 좋은 의사 결정을 돕기 위해 최대한 다양하고 유의미한 시도를 했는 지 생각해 봐야겠죠. 여러분 알아 두셔야 할게 의사 결정을 미루는 건 잘못된 의사결정을 하는 것보다 더 큰 문제점을 유발할 수 있어요.
  • 그리고 모든 게 애매하고 고통스러운 조난 상황이라도 등대 빛이 보이면 항해는 할 수 있는 것처럼 반복 작업으로 인해 고통스러운 상황이라도 프로젝트 목표가 명확하고 모두에게 동기 부여를 할 수 있는 형태로 정의되어 있다면 일단 프로젝트를 끌고 갈 수는 있어요. 문제는 목적조차 애매한 프로젝트라면 첫 단추부터 잘못 끼워진 거라 사상 최악의 재앙이 일어날 수 있다는 사실을 숙지하세요. 초기 준비 단계에 이건 아닌가보다 하고 엎어버리면 그나마 나은데 이렇게 시작부터 망한 상태로 프로젝트 종반까지 가면 정말 팀을 넘어 회사의 존망이 갈리는 위기가 닥칠 수도 있습니다.

    예를 들어 앞서 언급한 아이폰의 사례에는 ‘아이폰’이라는 최종 산출물의 형상을 최초 목표 수립시에는 아무도 예상 못했을꺼에요. 하지만 잡스가 수립한 프로젝트 목표에 대해서는 프로젝트 구성원들이 확신을 가지고 프로젝트에 몰입을 했기 때문에 아이폰이 탄생했죠.… 하지만 이런 성공한 프로젝트와 다르게 망한 프로젝트들은 프로젝트 목표라는 첫 단추부터 모호하고 형 이상학적이고 정치적이었던 경우가 거의 대부분입니다.

    기억 하실 지 모르지만 티맥스 소프트의 티맥스 윈도우 프로젝트 혹시 아시는 분 계시나요? 이 프로젝트는 명확하고 측정 가능하고 설득력 있는 프로젝트 목표가 아니라 그저 ‘IT 강국 대한민국에도 운영체제 소프트웨어 하나 쯤은 있어야 하지 않겠어?’ 라는 어정쩡한 프로젝트 목표를 가지고 수많은 개발자를 갈아 넣은 결과 회사 하나가 공중 분해 되고 수많은 투자자들의 자금이 허공으로 증발하는 초유의 대 실패를 맛보게 되었죠.
  • 지금까지 UX 디자인 프로젝트의 특성과 그 특성에 대해 제대로 숙지하고 대응하지 않으면 발생하는 재앙을 체크 리스트 형태로 짚어 봤어요. 이런 재앙을 모두 미연에 방지하고 UX 디자인 프로젝트를 성공시키는데 제일 좋은 방법은 바로 이겁니다.
    하지만 제가 지금 CEO나 인사채용 담당자 대상 강의를 하는 게 아니라 그냥 직장 생활하다가 UX 디자인 프로젝트에 참여하게 되는 개발자, 기획자, 디자이너, 마케터, 영업 담당자, QA 담당자 등등에게 강의를 하는 것이기 때문에 저 방법은 사실 알아봤자 별로 소용이 없구요. 저런 사람을 찾으리라는 보장도 솔직히 없어요. 우리는 프로젝트 팀원 혹은 프로젝트 관리자 정도의 레벨로 일할 때 프로젝트 성공에 기여하고 최소한 민폐 안 끼치고 제 할 일 하기 위해 무엇을 하고 무엇을 공부해야 하는 가에 포커스를 맞추는 게 맞을 것 같습니다. 나중에 혹시 여러분이 CEO가 되면 저런 인재를 찾아서 채용한 다음 본인 프로젝트에 꼭 투입하시길 바랍니다.
    프로젝트에서 1인분 이상을 하려고 한다면 프로젝트 현 상황을 파악하는 통찰력도 있어야 하고 프로젝트 관리에 대한 제반 지식도 있어야 할 것 같고 디자인이나 개발 등 의사 소통을 위한 기본적인 상식들도 있어야 할 것 같고 원활한 협업을 위한 커뮤니케이션 스킬도 필요하고 능동적이고 긍정적인 마인드도 필요하고… 무엇보다 자신이 담당한 업무를 수행할 역량도 필요하고… 아무튼 다 필요할 것 같지만 이런 부분에 대해 다루는 건 오늘 강의의 영역을 벗어난 것 같고 각자 팀의 멘토에게 여쭤보거나 책을 읽거나 하시면서 알아서 학습하시길 바랍니다.
  • 일단 지금까지 UX 디자인 프로젝트의 특성과 발생할 수 있는 문제점과 원인들에 대해 대략적으로 말씀 드렸어요. 이제부터는 UX 프로젝트를 통해 만들고자 하는 것… 그러니까 프로젝트의 결과이자 목표겠죠? 그 산출물의 속성과 UX 프로젝트에 필요한 다양한 역량과 그 역량을 수행하는 다양한 사람들에 대한 소개.. 그리고 마지막으로 UX 프로젝트가 진행되어 가는 과정과 세부적인 과업들에 대해 대략적으로 소개하겠습니다. 사실 한 항목 한 항목이 하루 꼬박 잡아먹는 주제라서 수박 겉 핧기 식으로 넘어가는 것을 이해해 주시기 바랍니다.

    우선 일반적으로 UX 디자인 프로젝트로 만들어지는 결과물… 제품이라고 하면 이해가 쉬울 것 같은데 이런 것에 대해 예를 들어 보겠습니다. 아까 우리가 이번 강의에서 다룰 UX 디자인의 범위를 디지털 디자인 영역으로 한정 짓는다고 했죠? 범위를 엄청 줄였는데도 UX 디자인 프로젝트로 만들 수 있는 건 이렇게 다양합니다. 이게 우리가 UX 디자인 프로젝트를 이해해야 하는 이유기도 하죠.
    우선 UX 디자인 프로젝트 결과로 만들어지는 제품의 유형 별 속성 별 구분을 알아보겠습니다. 우리가 만들고자 하는 제품의 러프한 속성을 알고 시작한다는 게 프로젝트 진행하는데 있어서 얼마나 중요한 건지 프로젝트 진행해본 경험이 있는 분들은 정말 잘 아실 겁니다. 일단 이 속성별로 사용자의 정의도 틀리고 작업자 세팅 방향성도 틀려지고 프로젝트 진행 방법론도 틀려지고 성과 측정 방법도 틀려지고 수익모델도 틀려지고… 하지만 역으로 말하면 프로젝트 목표에 따라 산출물 유형만 어느 정도 정해져도 일단 프로젝트 시작을 할 수 있다는 얘기가 되죠. 저는 다양한 속성이 있지만 일단 이해하기 쉽게 파수의 입장에서 만들어 낼 수 있는 3가지 유형만 간단히 정의해 봤어요.

    1.     커뮤니케이션 사이트
    -      브랜드 사이트 : 기업 대표 홈페이지, 대표 상품 사이트
         마케팅 캠페인 사이트 : 바이럴 마케팅 플랫폼, 이벤트 페이지, 트래픽 생성용 페이지

    2.     컨텐츠 사이트
    -      검색 포털, 위키, 웹진, 뉴스 사이트
    -      도서관, 자료실
    -      유튜브
         인트라넷, 고객지원센터

    3.     과제 기반의 어플리케이션
    -      정보를 일정한 형식으로 생성하는 애플리케이션 (MS Office, 포토샵)
    -      핵심 적인 업무 절차를 지원하는 도구 또는 프로그램 (영화 티켓 예매 서비스, 고객 지원 내역 확인 등)
    -      개인 데이터에 접근하고 관리하는 웹사이트
    -      상거래 사이트 (쇼핑몰, 소셜커머스)
    -      SNS

  • 다음은 플랫폼 별 구분입니다. 요즘 N Screen이다 웹표준이다 Seamless Experience다 해서 크로스 플랫폼이 대세 중의 대세가 되어가고 있고 앞으로도 이런 물리적인 경계를 넘어선 사용자 경험 통합이 가속화 될 것으로 예상은 되지만… 현실적으로 엄연히 플랫폼의 구분은 존재하고 플랫폼에 따라 설계, 디자인, 개발 환경 등등 영향 받는 요소가 많습니다.

    플랫폼의 속성을 이해하는 것도 굉장히 중요합니다. 이게 귀찮다면 MS나 구글이 플랫폼을 천하통일해서 하나만 신경쓰면 되는 개발환경이 되길 기도하시길 바랍니다. 프로젝트에 따라 이 4분면에 해당하는 작업을 다하거나 한가지만 하거나를 정해야 합니다.

  • UX 프로젝트는 일반적인 프로젝트와는 다르게 UX 프로젝트에 특화된 지식 영역이 필요합니다. 사용자, 인간에 대한 지식은 기본일테고 컨텐츠나 정보구조, 인간과 시스템의 상호작용을 의미하는 인터랙션, 감성 디자인 영역이나 정량적인 데이터를 통해 의사결정하는 분야까지 대충이라도 알아야 할 부분이 좀 많아보입니다.

    해당 지식 영역은 전문가의 영입으로 해결하거나 학습을 통해서 보완해야 겠지요. ROI를 고려해서 해당 역량을 보유한 인력을 리쿠르팅 할 것인지 외주를 쓸 것인 지 아니면 공부해서 소화할 것인지 프로젝트 관리자 혹은 CEO의 판단이 필요합니다.

    혼자서 이런 업무를 다 처리할 것이 아니라면 사내든 사외든 지식과 역량을 가진 팀원을 모아야겠죠.
  • 자… 일단 프로젝트 목표에 따라서 최종 산출물의 형상과 플랫폼 등이 얼추 정해지면 그 목표를 이루기 위해 사람들을 끌어 모아야 합니다. 마카오 카지노를 털려면 다양한 직군의 도둑놈이 필요하구요. UX 프로젝트를 완수 하려고 해도 다양한 직군 다양한 역량이 필요합니다.
  • 여기서 소개하는 UX 관련 직군들은 일단 UX 프로젝트라면 다 필요한 역할이자 역량이긴 한데요. 약간씩 프로젝트 속성별로 참여도와 중요도가 차이가 납니다.

    예를 들어 우리가 구축하려고 하는게 기업 홈페이지나 이벤트 프로모션 사이트 같은 거라면 다른 직군보다 브랜드 전략가나 비주얼 디자이너의 역할의 중요성이 엄청나지는데요. 파수 랩소디와 같은 과제기반 어플리케이션을 만들고자 한다면 인터랙션 디자이너나 비즈니스 애널리스트, 백엔드 개발자의 역할이 굉장히 커집니다. 이에 따라 유도리 있게 팀세팅을 해야죠.

    그럼 각 UX 직군에 대해 간단히 설명 드릴께요.
  • 많은 정보와 기능을 포함하고 있는 서비스나 어플리케이션은 필수적으로 사용자가 쉽게 인지하고 접근하고 사용할 수 있는 정보 구조(Information Architecture)로 구조화 되어야 합니다. 이해하기 쉽게 말하면 도서관에서 가나다 순이나 도서의 유형 별 카테고리로 일관된 기준에 따라 분류해 놓지 않으면 도서 대여든 정보 열람이든 원하는 과업을 수행 할 수가 없겠죠? 보통 이해하기 쉽게 설명하면 메뉴 구조나 사이트맵을 전문적으로 정의하는 전문가라고 보시면 될 것 같습니다.

    메뉴 카테고리의 속성을 직관적으로 이해할 수 있도록 텍스트 라벨링 작업도 보통 함께 진행하는데 사실 최소한 국내의 경우는 이 업무만 전문적으로 수행하면서 밥 먹고 사는 사람은 없다고 보시면 됩니다. 보통 기획 직군에 속한 사람들이 덤으로 하는 경우가 대부분이죠. 파수의 경우 기능 정의서를 분석하여 제가 초안을 만들고 제품기획팀에 검수를 받는 식으로 메뉴 구조 정의를 진행한 다음 해당 메뉴 구조의 텍스트 리소스 검수를 TW에 요청하는 식으로 일이 진행되죠.

    사실 이 정보 설계는 무조건 사용자 중심으로 사용자가 잘 인식할 수 있는 형태로 진행되어야 한다고 생각하는 게 원론적인데 사실 현업에서는 각 이해관계자의 개입이 빈번하게 일어나는 영역이기도 합니다. 예를 들어 제가 예전에 삼성닷컴의 메뉴 구조 정의 작업을 할 때는 제품 카테고리 정할 때 각 사업부의 어마어마한 정치 싸움에 갈등 조정하느라 정보 구조 확정하는데만 몇 개월을 잡아먹었던 기억이 납니다.
  • 좀 애매한데 디자이너라고 했지만 국내 실정에 따르면 좁은 의미의 UI 기획자라고 보시면 될 것 같습니다. 해외에선 설계 업무나 리서치 담당하는 사람들도 디자이너라고 부르는 경우가 대부분이거든요.

    간단히 설명하면 사용자들의 행위에 따라 시스템이 피드백하는 상호 작용(인터랙션)의 흐름을 설계하거나 사용자의 행위를 역으로 유도하기 위한 상호작용을 설계하는 일을 하는 사람이에요. 파수닷컴에서는 제가 하는 일이기도 하죠. 보통 컨텐츠 위주의 서비스 및 제품은 정보 설계자 롤이 중요하고 뭔가 기능 위주의 제품의 경우 인터랙션 디자이너의 롤이 중요해 집니다. 사용자의 행위에 따라 UI 구성요소가 반응하는 형상 및 규칙을 스토리보드 형태로 작업하는 사람이 인터랙션 디자이너고 그 결과물이 우리가 흔히 화면설계서라고 부르는 산출물이죠.

    인터랙션 디자이너들은 제품의 기능 요구 사항에 대한 이해도와 시스템에 대한 이해도, 플랫폼에 대한 이해도 및 사용자에 대한 이해도가 모두 높아야 하기 때문에 보통 애매한 제품 요구 사항을 디지털 환경에서 구현했을 때 어떻게 구체화 할 것인가에 대한 해답을 1차적으로 제시하는 롤을 많이 수행합니다.
  • 사용자 조사 전문가는 간단히 사용자의 니즈와 행동 패턴을 조사하고 분석하는데 특화된 전문가입니다. 해외에서 UX Researcher 라고 부르는 직군인데요. 연구 설계에 대한 역량과 연구 방법 선택, 조사 진행 및 결과 분석 그리고 리포팅까지 수행해야 하는 직군이에요.

    뭔가 유의미한 데이터를 긁어 모으는 관찰력도 중요하지만 봐도 봐도 이해하기 힘든 인간이라는 동물의 특성상 정성 데이터에 대한 해석 및 분석 역량이 더 중요합니다.

    사실 이 직군의 시초는 제국주의 시절 말이 안 통하는 야만인들을 관찰하던 민속학 연구자들에서 유래 되었기 때문에 사용자 조사 기법 중에 가장 고전적인 관찰 기법을 Ethnography (문화기술지)라고 부릅니다. 보통 외주를 쓰거나 내부 기획자들이 간단히 리서치를 수행하죠. 파수에서는 일부 프로젝트에서 필요하다고 판단될 경우 제가 담당하고 있는 롤이기도 합니다.
  • 쉽게 말하면 현재 파수의 경우 제품 기획팀이 담당하고 있는 롤입니다. 핵심적인 비즈니스 이해관계자들을 파악해 그들의 요구사항을 취합하고 그들과 실제 구현을 담당해야할 개발/기술팀과의 커뮤니케이션에 가교역할을 수행 합니다. (보통 경영자와의 직접 커뮤니케이션도 많이 수행하죠) 커뮤니케이션의 용이함을 위해서 상세 기능 정의서와 유스 케이스와 같은 문서를 작성해서 배포하기도 합니다.

    보통 과제/ 기능 중심 사이트나 어플리케이션에서는 이 역할이 매우 중요한 반면 브랜드나 마케팅 캠페인 프로젝트 같은 경우는 이 역할이 필요가 없습니다. 기능이 많고 프로젝트가 복잡할 수록 명확한 기능 정의와 범위 설정이 중요하기 때문이죠. 이 기능 명세를 실제 구현하기 위한 작업을 수행하는 과정에서 인터랙션 디자이너와 굉장히 밀접하게 일하게 될 것입니다.

    전반적인 프로젝트 범위와 요구사항에 관한 논의를 주관하기 때문에 프로젝트 매니저와 롤이 겹치는 경우가 많습니다. 따라서 좀 작은 프로젝트의 경우 PM이 해당 롤을 겸임 하는 경우가 많습니다. 이 경우는 그냥 파수의 PD와 롤이 백퍼센트 일치하는 군요.
  • 브랜드 전략가는 제품의 고객(잠재 고객까지 포함)에게 좋은 관계를 맺기 위해 회사의 브랜드 아이덴티티 요소를 규정하고 그 요소를 실제 제품에 적용하고 관리하는 롤을 수행하는 전문가입니다. 기업의 브랜드 자산을 결정하는 다양한 요소… 이를 테면 로고나 제품 명, 광고 카피나 광고 모델, 브랜드 컬러나 매장 디자인 등등… 이런 부분이 일관된 전략에 따라 관리 되지 않으면 고객의 인지도나 호감도, 기업 구성원의 로얄티 등에 영향을 주기 때문에 문제가 될 수 있죠.

    보통 UX 디자인 산출물들도 기업 아이덴티티의 연장선에 있기 때문에 해당 기업의 브랜드 전략 가이드라인에 따라 제작되어야 합니다. 파수의 경우에도 제품명을 명명하는 규칙이나 제품에 적용되는 브랜드 컬러라든가 일관된 레이아웃 등이 모두 나름의 브랜드 전략 가이드라인 하에 관리되고 있는 거죠. 어쨌든 프로젝트 내내 관여할 필요는 없지만 누군가 수행하기는 해야 할 롤이라고 말할 수 있겠습니다.
  • 사실 파수 제품들은 컨텐츠 보다는 기능 중심의 어플리케이션 형태를 가지고 있기 때문에 컨텐츠 전략가의 중요성은 그다지 체감되지 않지만 텍스트든 이미지든 동영상이든 다운로드 컨텐츠든 대량의 정보를 제공하거나 열람하거나 구매를 유도하는 서비스/제품의 경우에 컨텐츠 전략가의 중요성은 매우 높아집니다.

    제품에서 제공하는 컨텐츠의 퀄리티를 관리하고 컨텐츠 생산의 가이드라인 정하고 플랫폼의 속성에 맞는 컨텐츠를 가공하는 일련의 작업을 관리하고 직접 컨텐츠를 작성하기도 하는 롤을 수행하는게 바로 컨텐츠 전략가입니다.
  • 고객이나 사용자는 제품이나 제품과 연관된 매체 (브로셔나 홍보사이트 등)에서 텍스트 리소스를 통해서 여러가지 경험을 하게 됩니다. 기능 위주의 어플리케이션에서는 상대적으로 중요성이 덜하지만 브랜드 사이트나 마케팅 캠페인 사이트나 쇼핑몰, 기업 사이트 등등에서는 카피 한 줄이 사용자에게 끼치는 영향력은 대단하죠.

    파수에서는 TW에서 해당 롤을 함께 수행하고 있긴 하지만 TW가 작성하는 리소스들은 사용자의 감성적인 영역에 영향을 주는 전략적인 카피라기 보다는 그냥 업계 표준에 입각한 텍스트 작업 개념으로 업무를 진행하기 때문에 현실적으로 파수 내부에서는 이 롤을 전문적으로 수행하는 사람은 없는 것 같습니다. 만약 텍스트 리소스를 기반으로한 브랜딩의 필요성이 더 부각된다면 해당 역량을 갖춘 사람을 뽑거나 외주를 쓰겠죠.
  • 비주얼 디자이너(그래픽 디자이너)는 여러분들이 흔히 디자이너라고 생각하는 역할을 수행하는 직군입니다. 제품이나 사이트, 어플리케이션 및 매체에서 사용자가 눈으로 보는 요소를 실제 구현하는 직군이죠. 이들은 기업 브랜드 가이드라인에 따라서 혹은 해당 제품의 비주얼 전략 브리프에 따라서 다양한 시각적 요소(컬러, 레이아웃, 형태, 타이포 그래피… 등등)을 정교하게 컨트롤하여 해당 제품의 시각적인 경험을 창출하여 사용자와 제품 간의 감성적인 연결 고리를 만듭니다.

    이 강의를 듣는 분들이 접하거나 참여하게 되는 UX 프로젝트에서 비주얼 요소가 존재하지 않는 경우는 없기 때문에 모든 유형의 프로젝트에서 모습을 보이게 된다고 보시면 되겠습니다. 허나 산출물의 속성에 따라 그 중요도가 좀 차이가 나는데요. 비주얼 컨텐츠 중심의 사이트나 서비스의 경우 프로젝트의 중추적인 역할을 수행하는 경우가 많지만 (특히 이런 경우는 시니어 비주얼 디자이너가 거의 프로젝트 디렉터에 준하는 롤을 맡기도 합니다.) 과제 기반의 어플리케이션 같은 경우는 퍼블리싱을 위한 스타일가이드 작업 정도를 수행하는 게 일반적입니다. (보통 퍼블리셔나 인터랙션 디자이너의 요청에 따라 네비게이션이나 아이콘 같은 요소 작업을 진행하죠.)
  • 프론트 엔드 개발자는 사용자가 웹 브라우저에서 경험하고 수행하는 기능들이 원활히 작동하고 자연스럽게 흐르도록 기술적인 기반을 만드는 사람입니다. 인터페이스를 기반으로 상호 작용하는 다양한 요소를 관장하는데 이를 위해 HTML5, 자바스크립트, CSS 등의 웹기술을 능숙하게 활용합니다.

    하는 일을 보시면 알겠지만 UI 기획자 및 디자이너, 일반 백엔드 개발자까지 연관이 안되는 경우가 없습니다. 비즈니스 애널리스트나 인터랙션 디자이너에게는 UI 구현 요건을 받아야 할테고 비주얼 디자이너에게는 시각적 형상에 대한 가이드를 받아야 하고 역으로 본인이 구현하기 위한 동적인 요소에 필요한 비주얼 소스를 요청할 수도 있어야 겠죠. 프론트엔드 개발자와 백엔드 개발자는 동전의 양면 같은 존재니 이 둘 간의 커뮤니케이션도 너무 중요합니다. 물론 제품에 따라서 백엔드 개발이 그다지 중요하지 않은 경우도 있지만 (예를 들어 서버로 데이터를 보내지 않은 단순한 제품 소개 웹 페이지라거나…) 대부분의 과제 기반 어플리케이션들이 서버 개발/백엔드 개발이 필수적이기 때문에 백엔드 개발자와 협업 없이 일하게 되는 상황은 그다지 발생하지 않는다고 보시면 됩니다. (뭐 eDM 코딩 정도?)

    사실 수 년 전 만해도 플래시 액션 스크립터라는 직군이 따로 존재하기도 했는데 웹표준이 업계 표준이 되면서 이제 사라진 직업군에 등재되게 되었습니다. 웹기술 영역이 변화가 심한 영역이라 위상과 지식 영역의 변화가 굉장히 심한 분야인 것 같습니다.
  • 프론트 엔드 개발자가 클라이언트 영역을 관장한다면 백엔드 개발자는 실제 제품의 백엔드 영역을 관장하는 개발자입니다. 사용자 인터페이스 혹은 개발자들이 부르는 프레젠테이션 로직 영역을 제외한 비즈니스 로직 전체를 통칭해서 백엔드라고 부르는 것 같은데 저도 업계 표준 용어는 잘 모르겠네요. 그냥 흔히 말하는 일반적인 개발자고 퍼블리셔가 컨트롤 하는 영역을 제외한 모든 소스코드 베이스의 개발 산출물을 만들고 작업하고 관리하는 롤을 수행하는 사람이다… 라고 생각하시면 되겠습니다.

    사실 파수에서 제품 개발 프로젝트를 진행하게 되면 가장 많이 만나게 될 핵심적인 인력이죠. 왠지 여기 계시는 분들이 이 직군에 대해서는 저보다 훨씬 많이 알고 계실 것 같아서 설명은 여기까지 하겠습니다. 개발자 분들 앞에서 개발자 정의하자니 좀 부끄럽네요.
  • 프로젝트 매니저는 프로젝트의 관리자이자 리더입니다. 최초 프로젝트 제안이나 인비저닝을 담당한 사람이 팀 세팅 후 프로젝트 매니저를 맡는 경우도 있고 프로젝트 제안팀이나 컨설팅팀이 별도로 존재할 경우 앞 단에서 합의된 프로젝트 목표나 프로젝트 수행계획을 인계 받아서 다른 팀원들과 마찬가지로 프로젝트에 투입되는 경우도 있습니다. 파수에서는 제품기획팀의 PD님들이 권한이 좀 낮은 레벨의 PM 롤을 수행하고 계시는데요. 뭐 시간 나실 때 프로젝트 매니지먼트에 대해서 별도로 공부하시면 아시겠지만 PM도 권한에 따라 다양하게 구분이 됩니다.

    팀 구성 권한 및 팀원에 대한 상벌 권한을 가지고 있는 슈퍼 PM이 있는가 하면 그저 다른 팀원들과 똑같은 정도 수준인데 회의록 적고 이슈 체크하는 수준의 최저 권한의 PM도 있죠. 후자의 경우 진정한 PM은 경영진일 경우가 많습니다. 이건 뭐가 좋고 나쁘고의 문제가 아니라 각 기업의 프로젝트 운영 전략에 기인하는 거라 제가 뭐라고 말하기가 애매하네요. 뛰어난 중간 관리자가 많은 조직은 슈퍼 PM 형태로 프로젝트 조직을 굴리고 카리스마 넘치는 1인 독재 기업 같은 경우는 최소 권한 PM 체제로 프로젝트를 보통 굴리죠. 사실 슈퍼 PM이 된다고 꼭 좋은 게 아니에요. 권한이 많으면 그만큼 책임도 많아지거든요.

    해외 같은 경우는 프로젝트에 한해서 거의 오너 수준의 권한을 부여 받고 성공하면 어마 어마한 인센티브를 받고 실패하면 바로 해고… 뭐 이런 수준으로 일하는 게 일반적이죠. 본인의 역량에 확신이 있으시면 이런 슈퍼 PM으로 향후 진로를 잡아 보시는 건 어떨 지 생각해봅니다.
  • 이런 다양한 직군이 존재하긴 하지만 이런 직함을 달고 있는 담당자가 모두 프로젝트에 투입되는 경우는 최소한 국내 현실에서는 보기 어렵습니다. 특히 외주 계약으로 진행되는 웹 프로젝트 같은 경우는 프로젝트 매니저, 정보 설계자, 인터랙션 디자이너, 컨텐츠 전략가, 브랜드 전략가, 카피 라이터, 비즈니스 애널리스트.. 심지어 QA의 롤까지 한 명이 담당하는 경우도 가끔 있습니다. (사용자 조사 같은 경우는 보통 프로젝트에서 스킵 하는게 일반적이구요.) 보통 이런 경우 웹 기획자라는 애매한 용어로 개발 및 비주얼 디자인 업무를 제외한 모든 일을 하는 사람을 정의 합니다. 이런 식으로 전문 영역 없이 일하게 되면 모든 걸 다 알지만 하나도 제대로 못하는 사람들이 양산되기 쉽죠. 하지만 이런 것도 현실이라는 걸 알아두시면 실무에는 도움이 되실거에요.

    그래도 파수는 최소한 PM 및 비즈니스 애널리스트(PD), UX 디자이너(UI 기획자), 비주얼 디자이너, 퍼블리셔, 개발자, QA 로 구분되는 제품 개발 인력 셋을 가지고 있으니 나름 선진적인 UX 프로젝트를 수행하고 있는 조직이라고 볼 수 있겠습니다.
  • UX 프로젝트에 대해 사전 지식을 숙지한 여러분들은 드디어 프로젝트를 시작하게 됩니다.
    프로젝트 접근 및 수행 방법론에 따라 달라지겠지만 UX 프로젝트에는 다음과 같은 단계 내지는 과업들이 포함됩니다.
    1.  프로젝트 시작하기
    -      당신이 을이라면 프로젝트 수주를 위한 제안서 작성으로
    -      회사 내부에서 수행한다면 프로젝트 수행 계획서 (파수의 경우 인비저닝) 작성 부터
         당신이 갑의 입장에서 외주를 줘야 한다면 RFP (제안 요청서)를 작성

    2. 프로젝트 목표와 접근 방법론 수립
    -      프로젝트 목표의 조건 : 이해하기 쉽다, 분명하다, 측정 가능하다.
    -      목표가 여러가지일 경우 프로젝트 책임자와 팀이 함께 우선 순위를 결정해야 함.
    -      프로젝트 방법론(접근법)의 종류
    -      애자일 (Iterative)
    -      폭포수 (선형적)
    -      절충 (기본적으로 선형적인데 일부 구간에서 반복)
    -      Lean UX (이런 게 있다더라...알아만 두세요.)
         프로젝트 방법론이 프로젝트 참가자에게 중요한 이유

    3. 비즈니스 요구 사항 정의
    -      현재 상황을 이해 (AS-IS 분석)
    -      공인된 휴리스틱 방식으로 빠르게 통찰력 얻기
    -      경영진을 포함한 이해 관계자의 생각 듣기 (인터뷰)
         회의를 설계하기 (이해 관계자를 선별하고, 다뤄야 할 주제와 질문을 정하고, 결정되어야 할 회의 목표를 정하고 회의 이전에 공유해야 할 사항을 공유하고.. 등등)

    4.     사용자 (고객) 리서치
    -      사용자 (고객)을 이해하고 범위를 정의하기 위한 방법
    -      다양한 리서치 방식과 선택 방법
         어떤 방법으로 사용자를 알아갈 것인가?

    5.  사용자 모델링 (페르소나, 멘탈 모델)
    -      사용자를 언제나 회의실에 앉혀 놓고 일하는 방법
         우리 프로젝트는 사용자(고객)과 함께 진행합니다.

    6. 요구 사항을 UX 디자인으로 변경하기
    - 기능을 구체화 / 형상화 (프로토타이핑, 인터랙션 디자이너와 인포메이션 아키텍트의 활약)
    - 요구 사항 선별하기
    이해 관계 조율하기

    7.  UX 프로젝트 기획 산출물 만들기
    - 사이트맵
    - 태스크플로우
    - 와이어프레임
    - 스토리보드
    - 프로토타입
    - 그리고 디자인 산출물들
    8. 산출물 단계에서 검증 & 테스트 하기
    - 테스트가 가능한 목업 만들기
    - 테스트 기법 선정
    - 사용성 테스트 수행
    9.  UX 디자인에서 개발로 전환하기
    - 개발 팀에 요건 전달하는 법
    - 개발의 요구 사항을 다시 산출물에 반영
    - 반복
    - QA
    - 테스트
    - 사용자 피드백 수집 후 반영
    10.  그리고 그 이후.

  • 이론적인 UX 프로젝트의 과업이나 흐름과 현실적으로 파수에서 제품개발 진행할 때의 프로세스는 조금씩 차이가 있지 않나 생각합니다. 아마 모든 기업들이 일반적인 방법론을 연구해서 자사에 최적화된 프로젝트 관리 기법을 도입해서 일하고 있지 않을까 생각합니다. 구글과 삼성, 애플과 MS가 아마 프로젝트를 굴리는 방식이 다 틀리지 않겠습니까?

    제가 몇 년 파수 제품 개발 프로세스에 참여하면서 파수에 최적화된 제품 개발 프로세스가 뭘까 고민하다가 그려본 그림이 바로 이건데요… 아직 스케치 단계라 공유할 단계는 아닌 것 같고 혹시 다음에 기회가 되면 이걸 간단하게 인포그래픽 형태로 만들어서 프로젝트 참여하는 분들에게 책받침으로라도 만들어서 배포하고 싶네요.
  • 앞장에서 UX 프로젝트에서 일반적으로 수행하는 과업에 대해서 훑어보았는데요. 해당 과업들은 선후행 관계에 따라 선형적으로 쭈욱 진행될 수도 있구요. 단계별로 특정 기준을 만족할 때까지 무한 반복이 될 수도 있습니다. 따라서 프로젝트 단계 및 과업이랑 접근 방법론을 조합할 때 실질적인 프로젝트 진행 방식이 정해진다고 보시면 되요.

    현재 파수의 경우는 기본적으로는 폭포수 방식인 것 같은데 상황에 따라 반복이 진행되지만 그 반복을 생산적이라고 보기 보다는 업무를 지연시키는 보틀넥으로 간주하는 좀 그런 분위기가 있는 듯한 느낌적인 느낌이 좀 있습니다. 좀 슬프네요 개인적으로.

    저는 파수가 더 크리에이티브하고 좋은 제품을 만들기 위해서는 생산적인 반복, 무모할 지도 모르지만 좋은 결과를 낼 수 있을 것 같은 도전을 프로젝트 일정이나 리소스에 산정해서 투자하는 분위기가 좀 있으면 좋겠다는 생각을 합니다. 물론 일정이 빤하고 사이트의 요구사항에 맞춰야 하는 프로젝트 같은 경우야 어쩔 수 없겠지만요.
  • 사실 UX 디자인 프로젝트 전반에 대해서 소개만 드리는데도 좀 모자랐던 시간이었던 것 같습니다. 저도 뭐 전문 강사도 아니고 말솜씨도 부족하고 해서 의도대로 내용이 전달 되었는 지도 솔직히 잘 모르겠어요. 하지만 여러분들이 이것 만은 꼭 기억하고 다음 제품 개발 프로젝트를 함께 진행할 수 있으면 참 좋겠다는 생각이 드네요.

    1.     UX 프로젝트(UI가 있는 제품 개발 프로젝트)의 속성을 이해하자.
    -      관리자라면 프로젝트 속성을 파악해서 현실적인 일정 산정과 리소스 배분이 가능
    -      작업자라면 내가 이 타이밍에 어떤 롤을 수행해야 하고 누구하고 얘기해서 협업 해야 하는지 파악 가능
         전반적인 업무 맥락을 알아야 투덜거릴 타이밍인지 일해야 할 타이밍인지 알 수가 있음.

    2.     반복 작업을 꺼려하기 보다는 의미 있는 반복이 되도록 노력해보자.
    -      반복 작업은 최근 소프트웨어 개발 방법의 핵심. 단 빠르게 의견을 취합하고 의사 결정을 하는 것이 필수
         점진적 구체화 속성을 기억할 것

    3.     함께 일하는 사람들이 뭐 하는 사람들인지 이해하고 협업을 해보자.
         프로젝트 TF 구성원을 일 시키는 사람이랑 내가 산출물 던져줘야 하는 사람이라고 이분법적으로 보면서 일하는 경우가 대부분인데 서로 업무와 이해관계를 파악해야 시너지가 납니다.

    4.     공부를 하자.
    -      프로젝트 매니지먼트나 의사 소통 기법, UX 디자인이나 프로그래밍, 웹기술 등 다양한 지식 영역에 대해서 타인과 협업하는데 필요한 영역이라고 판단되는 부분은 각자가 알아서 능동적으로 채워나가자.

×