기획자가 고민해야하는 것들
서비스를 만들 때, 기획자가 항상 확인하고 고민해야하는 것들에 대해서
기획자가 서비스를 만들때 항상 고민해야하는 것들이 있다.
오늘은 그런 '고민이 필요한 지점'에 대해서 정리를 해보려한다.
일반적으로 서비스를 만들기 '전'의 상황에서는 보이는 것들이 그리 많지 않다. 타사와의 비교나, 기술적 우위같은 것들은 당장의 사용성을 좋게만들 수 있을것이다. 하지만 페이지가 늘어나고 복잡한 기능이 늘어날수록 개발인력들은 더 많은 시간을 투자해야한다. 서비스를 "사용하는 사람" 의 입장에서만 생각한다면, 편의성을 강화하기 위해 최선을 다하면 된다고 말하는 사람도 있을 것이다. 하지만 서비스를 "만드는 사람"의 입장에서 생각한다면, 이 지점은 전혀 다른 관점을 갖게된다.
1.
비즈니스적 관점을 이해하기
기획자는 서비스를 만들기 이전부터 서비스에 대한 이해가 가장 중요하다. 해당 업계의 규모는 어떻고, 우리는 어떤 위치에 있는지. 다른 서비스들은 어느정도의 회원수와 사용시간을 갖고있는지. 우리가 처음 서비스가 만들어진 이후에는 어떤 방법으로 사람들을 모을 것인지. 처음 사용하는 사람들이 서비스를 시작하기 위해, '어떤 과정들을 겪어야하는지'. 이런 다양한 지점들을 생각하며, 우선순위를 조절해나가야한다. 불필요한 화면이나 기능, 유기적으로 연결되지않은 과도한 컨텐츠는 사용자나 개발자를 혼란스럽게 만들 뿐이다.
또한 비즈니스 모델에 대해 이해하고, 사람들이 이 서비스의 어떤 지점에 끌리게될 것인지. 타 서비스와의 차별지점을 어떻게 보여줄 것인지. 그들이 얼마나 자주 서비스를 사용하게되는지. (서비스 사용주기) 등에 대해 고민하고, 상황에 맞는 플랫폼을 골라야한다. 예를 들어 초기 서비스를 만드는 상황이라면, 가능하면 가벼운 초기모델을 통해 서비스 초기 모델을 확립하고, 사용자들이 얼마나 호응하는지, 직접 체크를 해보고 난 다음에 고도화된 서비스를 만들어도 된다. 처음부터 많은 기능을 담은, 무거운 서비스를 만들어보아야, 개발비만 많이 나간다는걸 기억하자.
2.
개발 Stack에 대한 이해도를 키우기
개발 stack은 서비스에 쓰이는 개발 언어나, 솔루션 등의 조합 (Stack : 모아서 쌓다) 을 말한다. 일반적으로 특정 개발 stack은 상황이나 이유가 있어서 쓰이는 것들이 대부분이다. 예를 들어 파이썬은 로직이 복잡해 연산작업이 많이 필요한 경우에 자주 사용되고, 자바스크립트는 웹이나 앱에서 정규표현식 등을 사용하는데 가장 일반적으로 사용되는 개발언어다. 이처럼 일반적인 개발 언어나 특정 개발기술, 라이브러리, 솔루션 등이 어떤 용도로 사용되는지를 알고있어야 그 조합이 어떤 결과를 만들어낼지도 쉽게 알 수 있다.
또한 인력구성을 하는 과정에 있어서도 대중적인 개발 stack을 선택하는 것이 안전하다. 개발 인원들 중 그만두는 사람이 생기거나, 몸이 아파진다거나 하는 경우는 실무에서 꽤 흔한 일이다. 이 경우 대체인력을 찾아야하거나, 익숙치않은 개발기술을 새로 배워야하는 인원이 생기기도한다. 특수한 기술이나 개발 stack을 사용할수록 이런 대체인력을 찾기가 어려워지며, 개발자 포럼 등에서 문제 해결법을 찾기도 어렵다. 게다가 서비스를 만든 이후에도 유지보수가 필요한 경우에도, 이 부분은 계속해서 문제가 된다.
3.
디자인적 완성도를 상황에 맞게 조절하기.
일정이 빠듯한 경우, 디자인적 완성도는 포기하거나, 더 단순한 형태의 설계로 처리를 해야하는 경우도 있다. 실제로 관리자 admin 과 같은 화면들이 이런 경우인데. 남들에게 보여줘야할 지점이 아닌경우. 어쩔수없이 희생을 하게되는 지점들이 있다. 1픽셀, 글자 하나에 울고 웃는 디자이너들이 보면 멱살을 잡을지도 모르겠지만. 일정이 바빠진다면 포기해야하는 것들 중 하나가 바로 디자인 퀄리티다.
레이아웃적 다양성에 대해서도, 생각을 해볼 필요가 있다. 계속해서 단순한 반복 패턴. 레이아웃을 사용하면 지루해지니, 화면 배치를 다양하게 쓰는 사람들이 있다. 이 경우는 불필요한 레이아웃이 많아지게되면서, 실제 개발기간이 더 늘어날 수 밖에 없다. 디자인 시스템레벨의 정교한 반복 재사용을 하라는게 아니다. 단지 주요한 2~3개 패턴으로 처리할 수 있는 단순한 구조의 설계가 더 효율적이라는 이야기이다. 단순하고 효율적인 설계는 개발기간을 단축시키는 첫 시작점이 된다.
4.
반복될 수 있는 단순한 UI 컴포넌트와 스타일을 사용하기
개발자들은 UI를 만들 때, 기본 UI에서 변형할 수 있는 것과, 그렇기 않은 커스텀 UI를 구분해 사용한다. 그리고 이런 UI들은 각각의 OS나, 디자인 라이브러리 등에서 가져올 수 있는 것들이 있으면 더욱 좋다. 디자인적 완성도나, 독창성을 위해서 UI를 창조하는 일은 가능하면 피하는게 좋다. 일관성있는 패턴화를 통해 비슷한 UI들에서 쉽게 수정해서 사용하거나. 기존 UI를 조합해 새 UI를 만드는것도 괜찮은 방식이다. 다만 이러한 케이스의 경우 디자인시스템 레벨의 모듈화를 하지 않으면, 실제로 실무에서 적용하기는 어려운 경우가 많다.
예를 들어 일반고객용 서비스 앱과, 다른 유저타입이 사용해야하는 별도앱을 따로따로 만들어야하는 상황인 경우. 이 경우에도 공유되는 UI 컴포넌트가 동일하거나, 유사한 형태인 것이 가장 바람직하다. 다만 이 두 유저의 사용방식이나 환경이 달라지는 상황이라면, 이런 법칙을 강제로 깨야하는 경우가 생긴다. (예 : 일반 고객은 2030 유저 / 별도 유저타입은 4050 이상인 경우) 이런 경우는 별도의 컴포넌트와 스타일을 적용할 수 밖에 없는데, 당연히 작업량과 기간도 그만큼 늘어난다고 보면 된다.
5.
좋은 디자인과, 좋은 기획서는 서로 다르다는걸 기억하기
좋은 디자인은 사용자와 관리자들이 실제로 서비스를 사용할 때의 편의성을 고민한다. 하지만 '좋은 기획서'라는 것에서는 그 누구보다 개발자를 위해 친절한 설명이 필요하다. 대부분의 IT 기업에서는 넉넉치않은 개발금액과 일정에 쫗기게되는 경우가 많다. 그래서 기획자들은 일정에 맞추기위해 기획서의 설명이나 로직 부분을 빼버린 채 엉터리 기획서를 만드는 경우가 많다. 개발자가 '알아서 하겠지'라는 막연한 기대를 갖고 일을 대충 한다는 이야기다. 결국 각각의 요소가 제대로 설명되지않은 기획서는 QA 단계에서 문제를 더 키우게된다
기획서는 개별 정보들이 '어떻게 표기되고' 또 '어떤 조건으로 인해 등장하는지'를 말해줘야한다. 그런데 만약 이 지점이 제대로 정리되어있지 않고, 각각의 화면에서 뿌려지는 정보의 '조건'이 정확하지 않다면 어떻게 될까? 대부분의 경우 개발자들은 자신이 이해한 선에서 로직적 문제가 없는지를 살피고, 그 다음 단계로 넘어가버린다.그리고 나중에야 그 문제를 발견하게되어, 기능개선이나 업데이트를 하게 된다는 거다. 애초에 이런 상황을 만들지 않으려면, 기획서가 중요한 로직과 상태변화 등을 큼지막하게 정리해줘서, 개발자들의 이해를 도울 수 있어야한다.
6.
중학생이 봐도 이해할 수 있도록 정보를 풀어서 보여주기
기획서를 만드는 작업은 설명서를 만드는 작업과 비슷하다. 서비스를 처음보는 사람이, 그 로직을 보고 실제 개발을 할 수 있어야한다. 하지만 대부분의 경우 기획서에는 자체적인 형식이 있고, 그 형식에 맞추다보면 정작 설명을 할 공간이 부족하다. (내가 PPT 기반의 기획서를 좋지 않게 보는 이유중 하나가 바로 이 지점이다.) 그렇다보면 한 화면에서 동시에 설명해야할 내용들을 몇 페이지나 뒤에서 다루게되기도 한다. 심지어는 문서 규격에만 충실할 뿐인, 이게 대체 뭔지 알 수 없는 결과물을 만들어내기도한다.
좋은 기획서는 다음의 세가지를 모두 신경써야한다.
1) 이 행동이 다음 행동으로 어떻게 이어지는지 : 기능적 FLOW 표기
2) 이 화면의 요소들이 각각 무슨 의미이고, 어디로부터 왔는지 : 세부적인 정보설명
3) 조건이나 수식이 들어가는 경우, 어떤 지점을 체크하는지 : 로직에 대한 설명
- 기능적 FLOW 표기 : 각각의 버튼이나 UI를 눌렀을 때 어떤 일이 일어나는지에 대한 기능과 FLOW에 대한 표기를 말한다. 이 경우 한 화면에 존재하는 모든 UI 뿐 아니라 OS의 자체 기능 (back button이나 alarm)같은 것들도 포함하게된다.
- 세부적인 정보 설명 : 한 화면에 들어가는 수많은 정보들이 '알려주기 위한 안내성 정보'인지, 다른곳에서 끌어온 끌어온 '외부 정보' 인지, 여러 정보들의 조합을 통해 만들어진 '조합성 정보'인지를 일일히 설명하는 과정을 말한다. 이외에도 외부 API를 통해서 가져오는 정보나, 직접 입력받는 정보들도 있으니, 그 출처를 정확히 써주는게 중요하다.
- 로직에 대한 설명 : UI 요소나 정보표기가특정 상태에서만 등장하거나 사라진다는 '조건문' (if, else)에 관련된 내용이다. 사용자의 입력이나, 특정 행동이 동작조건이 될 수 도 있고, DB 기준의 특정 요소의 상태값이 동작조건이 될 수도 있다.
7.
서비스 개발 이후, 운영인력의 모습을 상상하기
일반적으로 서비스가 만들어지고 나면 자체적인 운영인력이 생기기 마련이다. 대부분의 운영인력들은 개발이나 기획에 대해서 잘 알지 못한다. 그들은 이미 만들어진 서비스 환경을 기반으로 고객을 응대하고, 문제발생시 가장 편리한 해결방식을 사용한다. 만약 서비스환경이 복잡해서 더 많은 것들을 외우고, 특정한 방식으로만 행동하기를 강제하게된다면, 현장에서 문제가 발생할 가능성이 커진다. 그들이 실수하지 않을만한 수준으로 단순하게 설계를 해두지 않는다면, 서비스가 계속해서 업데이트를 하게 될수록 문제는 더욱더 심각해진다.
대부분의 운영인력은 운영 메뉴얼을 보고 움직이지 않는다. 아니, 자세한 메뉴얼을 만들더라도 그걸 그대로 따라하는 것이 쉽지 않은 일이다. 그러니 두꺼운 메뉴얼을 만들기보다는, 애초에 운영과정에서 별다른 관리나 체크가 필요하지 않게 만드는게 가장 우선이다. 숨겨져있는 옵션을 만든다거나, 사용 FLOW가 복잡한 상황. 혹은 개별 정보값을 숙련자만 알아볼 수 있도록 압축시킨다던가 하는 상황은 피하자. 아르바이트나 인턴이 서비스 관제를 맡더라도 문제가 생기지 않을 정도로 단순한 형태를 추구하는게 좋다.
8.
기능을 추가해야할 때, QA까지 생각하기
무언가 기능을 꼭 넣어야한다면, 그 내용을 조건별로 체크하는 QA 과정이 뒷따른다는걸 기억하자. 적어도 3~4개의 OS별 디바이스에서 각각의 기능이 잘 동작하는지를 체크해봐야하니. 동일한 화면을 10번 정도는 사용해보게될 가능성이 높다. 심지어 오류 수정을 하더라도 또다시 '오류가 해결되었는지'를 확인하기 위해 4~5번 이상은 체크를 해봐야한다. 그러니 기능 추가를 하기 전에는 이 기능이 정말 필요한 기능인지 고민을 해봐야한다.
실제 QA 과정에서는 한가지 기능만 체크할 수 있는 경우는 거의 없다. 대부분 그 단계로 들어서기 위해 매번 정보를 초기화하거나, 새로 가입을 하거나, 카드정보를 새로 추가하거나, 또다른 계정에 로그인하거나 하는 식의 '리셋과정' 이 꼭 필요하다. 심지어 특정 조건들은 혼자서는 그 환경을 만들 수 없는 경우도 있다. 그러니 매번 DB의 데이터를 삭제하거나, 개발자가 특정 값을 넣어줘야한다. 그러니 QA 과정에서 얼마나 많은 시간이 드는지. 또 얼마나 기계적인 반복작업이 이어질지를 미리 생각해볼 필요가 있다는 것이다.
-
기획자는 디자인으로 죽고사는 사람이 아니다. 각 구성원들이 작업을 진행할 수 있도록 돕고, 관리하는 프로젝트 매니저 (PM)의 역할에 더 가깝다. 디자인에 집착하지말고, 서비스가 기간 내에 잘 만들어질 수 있는 방향을 찾고, 거기에 맞는 전략적인 선택지를 선택해야한다. 당장 눈앞의 문제를 넘어 미래에 발생할 수 있는 문제를 미리 예측해야하는 경우도 많으니, 다양한 준비를 해두도록 하자.
