대학을 갓졸업하고 새로 들어온 친구들에게 OJT겸해서 프로젝트를 맡겨놓고 관찰하고 있자면... 아래와 같은 질문을 가장 많이 받게 된다.
"다음에는 뭐할까요?"
입사 면접때 보면, 다양한 방법론을 경험한 적이 있다고 자랑스럽게 얘기하던 그들이다.
"Ethonography도 해봤구요, Affinity Diagram도 잘 활용하구요, User Diary도 해봤어요..."
근 데 다음 단계가 무엇인지, 무엇을 해야하는지 잘 모르겠단다. 방법론이 중요하지 않다는 얘기가 아니라, 디자인 프로세스에 대한 이해가 탄탄해야 다양한 방법론을 필요에 따라서 활용할 수 있다는 것이다. 다양한 방법론에 대한 내용은 UX Factory의 방법론 관련 포스팅을 참조하길.
기본적인 서비스의 구현단계를 기준으로 본다면, 조직의 function을 기준으로 "기획->디자인->개발" 로 간단하게 정의할 수 있다. "기획"단계는 어떠한 서비스를 만들것인가에 대한 고민을 하는 부분인데, 크게 상위기획과 상세기획으로 나누어진다. 서비스의 컨셉이나 전략에서부터 UX조직이 참여하여 서비스를 디자인해나가는 프로세스는 참으로 행복한 케이스이지만, 현실적으로는 기획 function조직에서 어느 정도 완성된 기획안을 Input으로해서 UX조직의 업무프로세스가 시작되곤 한다.
사용자를 어떻게 정의하느냐, 사용자그룹간의 우선순위를 어떻게 두느냐에 따라서 서비스의 컨셉 혹은 운영전략들이 바뀔 수도 있으나, 안타깝게도 이러한 부분은 서비스의 기획 초기에 참여하지 않았다면 발언권조차 얻기 힘든 Waterfall 방식의 조직간 협업체계에서는 UX조직이 건드리기 어렵다. (현실적으로 어렵기 때문에 안해도 된다는 얘기는 아니다. 이러한 이슈는 다음번에 심도깊게 다뤄보기로 하자. ^^;)
UX조직에 막 입사한 주니어를 대상으로 UX조직의 업무프로세스를 설명해본다면 아래와 같다.
1. 서비스 정의
- 산출물: 한 문장으로 표현한 서비스 컨셉
본래 서비스 개발 프로세스로 본다면, 시장조사나 사용자조사 등을 통해서 경쟁사 대비 포지셔닝맵이나 최상위 전략을 수립하는 단계가 필요하다. 하지만 대부분의 경우 최상위 전략은 마케팅조직이나 기획조직에서 진행하기 때문에 UX조직의 업무프로세스에는 포함되지 않는 경우가 많다.
많은 경우, 서비스의 컨셉을 장황하게 "이것도 하고, 저것도 하고..."식으로 정의하는 경우가 많은데, 이러한 기획문서를 깔끔하게 정리하는 단계가 필요하다. 사용자를 위한 서비스를 만드는 초석이되는 단계로 아주 간결하고 명확한 서비스 컨셉이 필요하다. "경쟁사를 이길만한 서비스", "세계 최초 XXX 서비스"류의 서비스 컨셉은 지양하는 것이 좋다. 사용자입장에서 명확한 효용가치를 기술할 수 있는 컨셉을 정의하는 것이 좋으며, 한 문장으로 컨셉을 적어보기를 강력히 권한다. ('~하고', '~하는' 뭐 이런식의 만연체를 써가면서 여러문장을 한문장으로 만들어서 컨셉을 만들지 말자... 제발 -_-;;) 한 문장으로 간결하게 정의가 되지 않는다면 서비스의 방향성이 명확하지 않거나, 방향성이 없다고 봐야한다.
예) 교통정보 검색서비스: 지리정보를 근간으로 자가운전자가 운전시에 필요한 교통 정보를 제공
2. 사용자 정의
- 산출물: 사용자그룹 정의와 사용자그룹간 우선순위
- 활용가능 방법론: User Profile, Persona, User Research, Literature Review
이전 단계에서 정의한 서비스컨셉이 효용가치를 제공하는 사용자를 정의하는 단계이다. 기존에 해당서비스나 유사서비스에 대한 사용자관련 데이터가 있다면 이를 활용할 수 있다. Persona나 User Profile에 대한 자료가 있다면 금상첨화! 서비스의 효용가치를 소비할 사용자그룹을 선택하면 된다.
데이터가 전혀 없다면, 사용자조사를 진행할 수도 있다. 사용자조사를 통해서 사용자유형을 만들어내면 된다. 하지만 시간과 비용이 허락하지 않는다면(많은 경우가 그렇지만...) 경쟁사의 서비스나 유사서비스를 둘러볼 수 있다. 이른 바 Bench marking 혹은 Competitor Analysis. 주의할 점은 타 서비스의 기능이나 기능들의 조합, 컨텐츠등을 통해서 서비스의 방향성과 대상으로 하는 사용자에 대해서 이해하는 것이 주된 목적이라는 점이다. 절대 타사 서비스의 기능을 배끼기 위한 것이 아니다.
또 학술자료나 통계 데이터등을 통해서도 예상 사용자들을 추론해볼 수 있다. 이게 바로 Literature Review. 요즘에는 인터넷으로 왠만한 자료를 모두 찾을 수 있다. ^^; ACM Digital Library과 같은 전문정보 라이브러리를 사용하는 것도 방법이다.
이렇게 사용자에 대한 자료가 수집되었으면, 사용자그룹을 정의한다. 이때 주의할 점은 사용자그룹의 특성을 대표할 수 있을만한 "이름"을 부여하는 것이다. 지식인 서비스와 같은 "질문&답변 서비스"를 예로 들자면 아래와 같다.
예) 질문 & 답변 서비스
1) 질문자: 자신이 궁금한 내용을 질문하는 사용자유형
2) 답변자: 질문에 대해서 자신이 가지고 있는 지식이나 레퍼런스를 사용해서 답변하는 사용자유형
3) 정보전달자: 자신이 직접답변을 할 수 있는 능력은 없으나, 검색능력이 있어 관련된 정보를 스크랩하여 답변하는 사용자유형
4) 정보소비자: 질문이나 답변을 하지 않고 단지 질문&답변을 소비하는 사용자유형
물론 위의 사용자정의를 좀 더 세분화할 수도 있다. 예) 일상생활관련 질문자, 학술관련 질문자 등. 얼마나 세분화할 것인가 혹은 사용자유형간의 레벨을 어느 수준으로 맞출 것인가는 해당 서비스에 따라서 적절하게 조정하는 것이 필요하다.
Persona나 User Profile을 가지고 있다면, 이미 충분히 구체적으로 정의된 사용자유형이 있으므로 이를 그대로 혹은 약간 수정해서 사용할 수 있다.
주의! - 절대로 "20대 남자 대학생"과 같은 Demographic 정보를 근거로 사용자유형을 나누지 않도록 한다. 사용자의 니즈 혹은 서비스 사용목적에 따라서 유형을 정의하는 것이 필요하다.
주의! - 서비스 컨셉을 정의하고 "대충 이런 사용자가 있을 것이다"라는 식으로 사용자를 정의하는 것은 매우 위험하다. 왜 이렇게 사용자를 정의했는지 구체적인 근거가 필요하다. 아무런 자료를 찾기 어렵다면, 경쟁사의 서비스를 심도깊게 들여다보면서 어떠한 사용자들의 니즈들이 있는지 들여다보는 것이 필요하다. 이러한 니즈들을 조합하면 사용자그룹을 몇 개 도출해낼 수 있다.
사용자유형이 정의되었다면, 서비스를 활성화하기 위해서 혹은 서비스 제공자 입장에서 사용자유형간의 우선순위를 정의한다. 총 합이 100%가 되도록 각각 %를 부여하는 것도 좋은 방법이다.
3. 사용자 니즈 정의
- 산출물: 사용자 요구사항 목록
- 활용가능 방법론: User Profile, Persona, User Research, Literature Review
솔직히 "2. 사용자 정의"단계와 구분이 모호하다. 니즈를 먼저 도출하고 사용자 정의를 한 다음에 이를 토대로 니즈를 재정리할 수도 있다. 사용자유형간의 우선순위에 따라서 요구사항의 우선순위가 자연스럽게 결정된다.
요구사항목록에는 크게 "누구의 요구사항인가?", "요구사항이 무엇인가?", "얼마나 중요한가?"의 내용이 담긴다.
4. 기능 정의
- 산출물: Feature List
위에서 정리한 요구사항을 해결하기 위한 해결방안을 고민한다. 이것을 정리하면 기능 목록이 도출된다. 때로는 하나의 기능이 두 가지 이상의 요구사항을 만족시킬 수도 있고, 두 가지 이상의 기능이 조합되어야만 한 가지 요구사항을 만족시킬 수도 있다.
기능 목록을 정의할 때 가장 중요한 것은 "있으면 좋을 것 같은 기능 (Nice-to-have feature)"를 최대한 배제하는 것이다. 최소한의 기능으로 요구사항을 만족시킬 수 있도록 한다. 일단 필요할 것 같은 기능을 모두 기술한 뒤에 기능간의 포함관계를 고려해서 삭제해도 좋은 기능을 차례차례 삭제해내가는 것도 좋은 방법이다.
기능목록에는 크게 "어떠한 요구사항을 위한 기능인가?", "기능이 무엇인가?", "얼마나 중요한가?"의 내용이 담긴다.
주의! - 기능 목록이라고 해서 Function만 담기는 것은 아니다. Content나 Relationship이 담길 수도 있다. 요구사항을 해결할 수 있는 모든 형태의 무엇인가라고 생각하면 된다. 광의의 의미에서 "요구사항을 해결할 수 있는 정보"라고 말할 수도 있다.
주의! - 이 단계까지 도달하기 전에 절대 서비스의 Feature에 대해서 고민하지 말자! 미리 부터 "이러한 기능을 넣어야지"라고 생각하는 순간, 서비스는 이미 그 기능을 추가하기 위한 방향으로 왜곡되기 시작한다. Feature는 사용자의 니즈를 해결하기 위한 하나의 해결방법 중의 하나일 뿐이다. 얼마든지 다른 Feaure로 동일한 니즈를 해결할 수 있다는 것을 잊지 말자.
팁! - 유관부서에서는 가능한 많은 기능을 넣고자 하거나, 이해관계에 따라서 특정 기능을 고집하는 경우가 있다. 이럴 때는 "해당 기능을 다음 단계 개발 범위로 정의"하는 것을 제안해볼 수도 있다. 그 말의 의미는 현실적으로 Spec Out하자는 얘기지만, 회의석상에서는 상대의 감정을 상하지 않게하면서 기능을 제거할 수 있는 유용한 방법이다.
5. 정보구조 정의
- 산출물: Information Architecture, Sitepath Diagram
정의된 기능을 토대로 정보구조를 그린다. SNS서비스와 같이 사용자간의 관계 혹은 인터랙션이 중요한 서비스는 Sitepath Diagram을 그리는 것도 좋다. Sitepath Diagram으로 서비스가 온전하게 운영될 수 있는 사용자유형간의 관계를 정의해볼 수 있다. 정보구조를 그릴 때 가장 중요한 점은 서비스를 전체적으로 조망하면서 각 기능간의 관계를 명확하게 정의하거나 기능간의 계층 구조를 구체화하는 것이 중요하다.
* Sitepath Diagram: 쉽게 얘기하자면, 사용자간의 Action을 하나의 그림으로 표현해보는 것. UML이나 Flow Chart와도 유사한 개념인데, 핵심은 다양한 사용자군간의 인터랙션이 하나의 그림에 표현이 되어야 한다는 것이다. 이 개념은 Information Achitecture: Blueprint for web에 잘 설명되어 있다.
주의! - 사이트맵은 정보구조의 한 종류이다. 사이트맵은 기능간 계층구조를 보여줄 수는 있지만 기능간 관계는 보여주지 못한다. 이 단계에서 만들어야하는 산출물은 사이트맵이 아니라 정보구조이다. 혼동하지 말자. MindManager와 같은 드로잉 툴을 사용할 수도 있다.
6. 기초 화면설계
- 산출물: Wireframe
정보구조를 토대로 사용자에게 보여져야할 페이지를 산정한다. 그리고 각 페이지에서 보여져야할 요소들을 정보구조에서 도출하도록 한다. 정보구조가 페이지로 투영되는 과정이라고 보는 것이 좋다. 정보구조에서 각 정보의 단위들이 모두 개별 페이지로 보여지는 것은 아니다. 2개 이상의 정보가 하나의 페이지에서 보여지기도 하고, 하나의 정보가 여러 페이지에서 보여지기도 한다. Rich Interaction을 활용하여 구현할 계획을 가지고 있더라도 일단 필요한 페이지를 정의한 뒤에 페이지를 통합하거나 분리하는 작업을 진행하는 것이 바람직하다.
페이지들이 정의되었으면, 정보가 어떻게 표현되어야할지 UI 단위(Widget, Component, Pattern이라고 부르기도 한다)를 정의한다. 가령 "검색결과"라는 페이지를 구성하려면, "검색창과 버튼", "검색결과 목록", "관련 정보"와 같은 UI단위가 필요하다. UI단위를 정의했으면 사용자의 Task Flow를 고려하여 페이지에 배치한다. 이때, "4. 기능정의"단계에서 정의했던 우선순위를 참고하여 UI단위의 상대적인 크기나 위치를 고려해야 한다.
7. 인터랙션 디자인
- 산출물: Interaction Design Document, Prototype
- 활용가능 레퍼런스: Design Patterns, Rich Interaction Design Patterns
정의된 화면과 화면에 배치되어 있는 UI단위들을 가지고 인터랙션을 정의한다. "A라는 버튼을 클릭하면 데이터 1이 서버로 전송되면서, B라는 버튼으로 전환된다"와 같이 정의할 수도 있고, 각 세부 단계별로 화면설계화면을 문서화할 수도 있다. UI단위간의 인터랙션뿐만 아니라 사용자유형간의 인터랙션도 함께 고민할 필요가 있다.
Rich Interaction을 활용하였다면, 에러가 발생하지 않고 서비스제공자 입장에서 원하는 방식으로 한 번에 Task를 성공하는 Happy Path 뿐만 아니라, 방법과 경로는 다르지만 Task를 성공할 수 있는 Alternative Path나 에러가 발생하는 Error Path도 꼭 함께 정의해야 한다.
* 일단은 여기까지가 가장 보편적인 UX조직의 업무프로세스이다. 이후 단계는 각 조직의 특성이나 프로젝트의 특성에 따라서 유관부서와 협업이 가능하다.
8. 시각 디자인
- 산출물: Graphic Files (디자인팀)
일반적으로는 시각 디자인을 담당하는 부서 혹은 담당자(흔히 말하는 디자이너)가 이 단계에서부터 업무를 시작한다. 하지만 서비스가 가지는 미디어의 특성이나 서비스의 속성에 따라서 UX조직이 보다 유기적으로 참여할 수도 있다. 이러한 프로젝트의 예를 들어본다면,
1) 새로운 컨셉의 미디어 서비스: IPTV, iPhone 어플리케이션과 같이 미디어의 일관된 UI나 Interaction Style을 가져야하는 경우, UX조직이 디자인팀을 가이드하는 형태로 참여가 가능하다.
2) 정보기반의 서비스: 정보제공의 목적이 매우 명확한 경우, 정보를 어떻게 배치할지 몇글자, 몇줄 보여줄지까지 UX조직에서 정의하는 형태로 업무진행이 가능하다. 하지만 아이콘이 적절한가 텍스트 링크가 적절한가 혹은 아이콘의 시각적 메타포가 어떠해야한다는 것을 제안할 수 있지만, 아이콘 버튼의 색상이나 스타일을 정의하는 것은 월권이 될 수도 있다. 물론 가독성의 위해서 색상가이드를 전달하는 것은 가능하다.
9. 개발
- 산출물: Product (개발팀)
개발방식에 대한 의견 정도를 개진할 수 있다.
10. QA
- 활용가능 레퍼런스: Interaction Path
"7. 인터랙션 디자인"단계에서 정교하게 정의한 Happy Path, Alternative path, Error Path가 있다면 이를 QA팀에 전달해서 이들의 업무에 도움을 줄 수 있다.
* 아래의 단계에서부터는 주니어들이 쉽게 간과하기 쉬운 단계이다. 서비스가 오픈했다고 해서 모든 프로젝트가 완전히 끝난 것은 아니다. 새로 입사한 인력들에게 항상 강조하는 것은 "서비스가 문닫기 전까지는 프로젝트는 끝나지 않는다"는 점이다. 물론 서비스의 오너쉽이 UX조직에 없는 경우도 있지만, 사용자입장에서 서비스를 지속적으로 개선해가기 위해서는 서비스에 대한 애정과 끊임없는 관심이 필요하다.
11. 서비스 오픈
- 활용가능 방법론: Web Analytics / User Research
서비스가 오픈하면, 서비스에 대한 사용자의 반응을 알아보는 것이 중요하다. 우리는 A가 중요하다고 생각했으나 정작 사용자들은 B를 중요하다고 생각할 수도 있고, Solution 1이 가장 이해하기 쉬운 방법이라고 생각했으나 사용자는 여전히 어려워할 수도 있다.
서비스가 오픈하고 일정 수준의 안정화 작업이 진행된 다음에는 사용자조사를 진행할 수 있다. 실제로 서비스를 어떻게 사용하는지 관찰해볼 수 있다. 또 사용자들은 눈에 보이지 않는 것(구체화되지 않은 것)에 대해서는 의견을 개진하기 어려워하지만 일단 서비스가 오픈되고 나면 다양한 의견을 내는 것이 사용자이다.
애플은 사용자조사를 하지 않는 조직으로 유명하다. 하지만 이것은 서비스컨셉단계에서 "사용자들이 무엇을 원하는지"에 대한 사용자조사를 하지 않는다는 얘기이다. 애플은 서비스 개발단계에서 프로토타이핑을 통해서 사용자의 의견을 수렴하는 조사는 많이 진행하기로 또 유명하다. (평소에 사용자에 대한 관찰을 통해서 그들이 무엇을 원할지를 생각해내고 검증하는 형태로 사용자조사를 진행하는 조직이라고 볼 수 있다.)
온라인 서비스라면, 로그데이터분석을 쉽게 활용해볼 수 있다. 서버에 남는 기본적인 로그 뿐만 아니라 자바스크립트 태그를 활용한 데이터누적 방식도 고려해볼 수 있다. 사용자조사가 심도깊은 정성조사라면 로그데이터분석은 쉽게 일반화가 가능한 정량조사이다.
* 팁! - Google Analytics는 여전히 무료다. 이 서비스의 기본 기능만 충분히 사용해도 로그데이터에서 뽑아내고 싶은 데이터는 상당부분 도출이 가능하다. 예산이 충분하다면 다양한 유료 솔루션도 고려해봄직하다.
12. 서비스 개선
- 산출물: Revision History Document
서비스의 사용률에는 다양한 요소들이 영향을 끼친다. 때로는 경쟁 서비스가 망해서 우리의 서비스로 사용자들이 몰릴 수도 있고, 시기적인 이벤트(발렌타인, 입학식 등)나 천재지변(지진, 태풍 등)으로 인해서 사용률이 급증/급감할 수도 있다. 이후 분석을 위해서 이러한 이벤트들을 꾸준이 메모해두는 습관이 필요하다. 특히 이러한 이벤트 캘린더는 로그데이터분석할 때 상당히 유용하다. 갑자기 트래픽의 큰 변동이 생겼는데, 로그데이터 자체는 외부적인 요인을 설명해주지 못하기 때문이다.
또, 서비스는 지속적으로 개선되기 마련인데, 경우에 따라서는 개선한 UI를 개선하기 위해서 이전의 UI로 돌아가는 "웃기는 리뉴얼"이 진행되기도 한다. 따라서 개선이 될 때마다, "왜 개선을 하게 되었는가? 문제가 무엇인가?", "해결방안은 무엇인가?", "의사결정자는 누구인가?"를 문서로 남길 필요가 있다. 또, 개선될 때마다 스크린샷을 만들어서 아카이브를 만들어 둘 필요도 있다.
위에서 언급한 프로세스는 가장 기본이 되는 프로세스라고 생각한다. 물론, 조직의 특성에 따라서 적용하기에 어려운 것이 있을 수도 있다. 하지만 바람직한 서비스, 착한 서비스, 많은 사용자들이 사랑하는 서비스를 만들기 위해서라면, 해 볼 필요가 있지 않을까 싶다. 그리고 위의 프로세스는 Walterfall 모델이 아니며, 각 단계들이 Iterative하게 진행되는 것이 특징이다. 본래 디자인 프로세스가 각 단계별로 지속적인 Iteration을 가지는 것이 특징이며, 최근 개발 프로세스도 빠르게 진행하되 잦은 Iteration을 갖는 것이 패러다임이라고 할 수 있다.
마지막으로 주니어들에게 하고 싶은 얘기는...
"항상 내가 어떤 단계의 업무를 하고 있으며, 현재 내가 만들고 있는 산출물이 다음 단계에 어떻게 사용될 지 생각하라는 것"
절대 현재 단계만 보고 "명품"을 만들겠다는 각오로 모든 정력을 소비하지 않기를 바란다.