서비스 기획 핵심잡기 : 상태값 변화

아이템의 상태값 변화가 서비스의 주요 FLOW가 되는 이유

1.

서비스를 분석하는 방법은 여러가지가 있다. 그중 하나는 서비스에 들어가는 '정보' 가 무엇인지를 체크하는 것이다. 그리고 그 정보를 어떻게 외부에서 끌어올 것인지를 확인하면, 이제 실제 서비스의 구조를 설계할 차례다. 그렇다면 대체 서비스 구조는 어떻게 만드는걸까? 사실 이 부분도 정리해보자면 매우 단순하다. 서비스의 핵심내용을 정해두고, 그 과정을 정리해보는 것이다.

예: 단순한 커머스 서비스 사례

1) 사용자가 서비스에 가입을 한 후, 사고싶은 제품을 선택한다.

2) 선택한 제품을 간편결제를 통해 구입한다. 이후 배송이 시작된다.

3) 배송 기업이 제품을 확인하고, 고객 주소로 배송을 진행한다.

4) 배송이 완료되고, 고객은 제품을 받아본다.

실제 서비스는 이것보다 훨씬 복잡한 과정이 들어가겠지만, 일단 단순하게 '어떤 과정'이 이뤄지는지 정리해보자. 일단 회원가입과정이 필요할 것이고, 주소지 입력과정이 별도로 필요하다. 또한 제품 목록을 보고, 그것을 구매할 수 있는 화면이 필요하다. 또한 구매시 결제정보를 입력해 간편결제를 할 수 있는 화면과, 배송상태를 확인할 수 있는 화면도 필요할 것이다. 이렇게 보면 이 서비스는 크게 두가지 상태값을 갖고있다고 할 수 있다.

- 첫번째는 사용자의 회원가입과 정보입력의 상태값 변화다.

회원가입 전 -> 회원가입 후 -> 주소입력 완료

- 두번째는 제품의 구매과정 상태값 변화다

물품 선택 -> 물품 구매진행 -> 구매완료 -> 배송시작 -> 배송중 -> 배송완료

상태값에 따른 알림메시지 사례

커머스의 '구매자' 관점에서는 회원가입과 구매과정 두가지의 상태값 변화만 알더라도 대부분의 기능이나, 필요한 화면들을 확인할 수 있다. 그리고 이런 상태값 변화는 대부분 '알림 메세지'와도 연관이 깊다. 그래서 서비스를 만들때는 이런 상태값에 대한 부분을 개발자들과 미리 상의하거나, 이 지점을 자세하게 정리해둬야한다. 실제로 백엔드 개발자들은 이런 상태값 변화에 대해서 '어떤 조건'으로 그 상태값이 변하는지. 그리고 어떤 순서에 따라 그 상태가 복구되거나, 변화하게되는지를 확인하곤 한다.

2.

실제로 서비스를 기획할때는 사용자의 계정이 등록되거나, 생성되는 과정이 훨씬 복잡한 경우가 많다. 단순 B2C 서비스가 아니라 B2B나 O2O 같은 서비스 제공자나, 특정 기능을 사용하는 사용자 타입이 많기 때문이다. 그들은 가입과정에서부터 각종 서류를 통해 확인과정을 거쳐야하고, 회원가입조차도 여러 단계에 걸쳐 진행되는 경우가 대부분이다. 그렇기 때문에 '회원가입의 상태값'이 훨씬 다양해지게된다. 심지어 회원가입이 완료된 이후에도, 결제정보가 잘못되거나, 운영점수에 페널티를 받거나, 회원 입장에서 계약을 파기하는 등 여러가지 상황이 발생할 수도 있다.

예: O2O 서비스 파트너 가입 사례

1) 사용자가 서비스에 가입을 한 후, 실제 고객들에게 서비스를 제공하게된다.

2) 서비스 가입시 법인사업자와 개인사업자를 구분하여 사업자 등록번호를 인증시킨다

3) 특정 서비스 업종이 가능하다는 별도 기관의 증명서를 등록해야한다.

4) 이후 서비스가 가능한 개별 인원에 대한 건강증명서를 등록해야한다.

5) 이 내용을 모두 검토한 이후 관리자를 통한 가입심사가 진행된다.

6) 가입심사에 통과한 대상은 알림메시지를 전달받고, 관리자는 그들과 입점계약을 진행한다.

7) 입점계약이 완료된 이후, 카드정보를 등록하여 서비스 수수료 결제수단으로 사용한다.

8) 서비스 수수료 결제에 문제가 있을 경우, 파트너는 신규 서비스 제공이 불가능하도록 일시정지상태가 된다.

9) 서비스 과정에서 사용자 피드백에 따라 운영점수가 차감되며, 서비스 계약이 파기될 수 있다.

 위의 O2O 사례처럼, 개별 서비스마다 회원가입에 '단계'가 존재할 수 있고, 심지어 회원가입 이후에도 회원의 상태값은 여러가지로 바뀔수 있다. 그렇기 때문에 이런 지점들을 반영해서 관리자페이지를 만들 경우,이 모든 과정을 한눈에 확인할 수 있는 화면들이 필요할 것이다. 심지어 개별 파트너들이 다시 서비스를 진행한다면, 개별 진행건에 대한 상태값도 별도로 정리해줘야한다.

- 파트너 가입에 따른 상태변화

파트너 가입대기 -> 서류내용 확인 -> 가입심사 진행 -> 입점계약 진행 -> 결제수단 등록 -> 실제 서비스 진행

- 파트너 활동 / 사용자 예약에 따른 상태변화

사용자가 서비스 요청 -> 파트너 입찰 -> 사용자가 파트너 선택 -> 예약완료 -> 서비스 진행 -> 서비스 완료

텍스트만으로 상태값을 정리하면, 내용을 파악하기가 쉽지 않은 경우가 있다. 그런 경우 단계별 표를 그려서 각각의 회원가입이나, 서비스 활동의 과정을 정리해보면 이해가 훨씬 쉬워진다. 각 단계에 필요한 정보가 무엇인지. 누가 어떤 역할을 하기때문에 다음 단계로 넘어가게되는지 등을 한눈에 알아보게 되는 것이다. 특히 사용자 타입이 많고, 기능이 복잡한 서비스일수록 이런 '상태값'을 단계별로 정리하는 과정이 꼭 필요하다. 특히 이 지점을 보기 쉽게 정리할수록 개발자가 구조를 잘못 이해하거나, 잘못된 기능을 개발할 가능성도 낮아진다.

3.

상태값 변화는 대부분의 서비스의 핵심 아이템이나, 핵심 기능들을 정리하고 확인하는 용도로는 아주 적합하다. 다만 각각의 유저타입이 사용하는 작은 기능들이나, DB에서 상태값을 따로 관리하지않는 기능들은 확인하기가 어렵다. 그렇기 떄문에 '어떤지점을' 상태값을 별도로 관리할 것인지. 그 지점이 필요하지 않은 지점은 무엇인지를 구분해주어야한다.

지금까지 단순한 유저 입장의 커머스에서부터, O2O 서비스까지. 여러 상태값 변화에 대한 내용을 이야기해보았다.  만약 ERP나 그룹웨어처럼, 다수의 그룹이 섞여있는 형태의 서비스라면 어떤 상태값들이 있을 수 있을까? 이처럼 유저타입과 서비스 플랫폼에 따라 다루는 정보가 크게 달라지고, 개발자와의 커뮤니케이션도 더욱 복잡해진다. 그렇기에 좋은 서비스를 만들고싶다면 이런 '상태값'을 기준으로 개별 내용들을 확인하고. 얼마나 다양한 유저 타입들이 서비스 진행에 엮이는지를 세세하게 파악해야한다.

-

유저 타입에 대한 내용은 다음시간에 !