편리하게 만든것이
모두에게 좋은것은 아니다.
정보의 홍수 속에서 서비스는 무엇을 넣고 무엇을 빼야 하는가?
아침부터 떠들썩 하다.
"내가 뭐라고 그랬어.. 이거 빼야 한다고 했는데 그땐 말을 안듣고 이제서야 빼라고 난리다.. "
뾰루퉁한 표정의 김선임은 커피 한잔을 머금고는 이네 현업 이책임의 험담을 이어 나간다.
언제 부터인지 프로젝트 진행할때 부터 부정적인 얘기를 다른 사람들에게 소문내는 역활을 자처하던 김선임은 얼마 안되어 우리의 프로젝트와 이별을 했다.
현업은 편리함에 대한 막연한 상상을 한다.
현실의 편리함은 개취 인것을~
이럴때 요청하는 모든 서비스들을 나열 하게 된다면 정보는 파도를 치고 홍수로 나에게 다가 온다.
그리고 다시 아침부터 현업의 험담을 하게 될것이다.
다양한 정보를 복잡하지 않게 한페이지에 넣으려면?
1. A고객, B고객, C고객의 정보들을 분석하고 해당 고객별 구분이 필요하다.
첫번째, 전체 사용할 회원을 정의 한다.
회원의 그룹별 정리 (예시)두번째, 회원의 구분에 따라 화면에 노출할 정보를 체크 한다.
회원별 정보 노출 체크 리스트 (예시)세번째, 그룹별 정보 노출 영역 정리
회원별 정보 노출 영역 정리 (예시)2. 회원의 구분별로 정보를 노출하는 형태의 가능성 확인이 필요하다.
대충 그려진 화면을 가지고 개발팀에 설명을 한다.
경우에 따라서 안되는 기능들이 생길수가 있고 (안되는 기능이 기술적인 어려움일 수도 있지만 환경적인 조건과 개발기간등을 고려하여 협의할 수 있다.) 더 좋은 방향의 가이드도 나올 수가 있다.
3. 화면의 흐름을 만들어 경우에 따라 예외처리 시 불편함이 없도록 한다.
기본적인 업무 흐름 정리 (예시)4. 자세한 화면설계서를 만들고 경우에 따라서는 프로토타입을 만들어 고객과 사용성 검증을 진행 한다.
서베이/설문조사, 사용성테스트-UT, FGI 등을 거처 해당 화면의 고도화를 진행한다.
프로젝트 예산도 고려해야겠지만, 서베이/설문조사 등은 단편적인 얘기만 들을 수 있고 자세한 의견 전달을 받기는 힘들다. 그래서 사용성테스트나 FGI를 좀더 고려해봐야 한다.
FGI는 차후에 좀더 심도 있게 얘길 해보자.
5. 서비스 개발을 진행하고 해당 서비스는 최대한 빠르게 노출 하도록 한다.
고객의 의견을 듣고 개발 진행한 서비스는 최대한 빠르게 많은 고객들에게 보여줘야 한다.
특별하게 개별 기능별로 서비스를 제공하는것도 하나의 방법이 되었다.
작은사이클을 반복하여 최소기능제품(MVP : Minimum Viable Product)을 진화시켜나가는 에자일 방법론으로 서비스의 완성도를 올린 Spotify
고객과의 커뮤니케이션 - 가십거리
가끔 나는 핑계를 만드는데 집착하곤 한다.
회의록을 만들고 회의록 내용을 정리해서 메일을 쓰고 회의록 파일은 첨부하고. 메일 내용에는 언제까지 내용의 수정을 요청하고 2~3일 내 피드백이 없으면 확정으로 다음 프로세스 진행 하겠다고 현업관리자에게 전달을 한다.
이런 메일을 받은 사람은 어떤 느낌일까?
일을 잘하는 사람이네 라고 생각 할까?
가끔은 뭐 어쩌라고~ 할 필요도 있다.
속으로....
