디스크립션 편
잘 만든 화면설계서 기준은 무엇일까?
누군가 나에게 이런 질문을 한다면 나는 이렇게 대답할 것이다. '화면설계서를 공유했는데 디자이너와 개발자가 아무런 질문이 없는 상태'라고 말이다. 잘 기획된 화면설계서는 더 이상의 질문이 필요 없다. 디스크립션에 이미 모든 설명이 들어있기 때문이다.
이러한 이유로 디스크립션만 봐도 웹기획자의 역량과 내공을 어느 정도 가늠해볼 수 있다. 오늘은 화면설계서에서 중요한 부분을 차지하는 디스크립션에 대해 얘기해보고자 한다.
내가 여행 사이트를 리뉴얼하던 때의 일이다. 날씨정보를 제공하는 기능을 개선해야 했는데 클라이언트는 기존 날씨 아이콘을 트렌디하고 심플한 아이콘으로 변경하고 싶어 했다.
일정에 쫓겨 어드민은 미쳐 고려할 여유도 없이 프론트 화면설계부터 부랴부랴 설계했다. 나중에 닥칠 후폭풍은 전혀 예견하지 못한 채 말이다.
나중에 구현하려고 보니 날씨정보는 관리자에서 컨트롤하는 것이 아닌 API로 붙여서 연동해야 했다. 디자인 시안으로 클라이언트에게 컨펌받은 예쁜 아이콘은 우리가 따로 제작 후 매칭해야 하는 여간 손이 많이 가는 작업이었다.
그것만이 문제가 아니었다. API에서 제공하지 않는 항목은 노출 자체가 아예 불가능했다. 한마디로 디자인 시안대로 구현이 불가능한 상황이 된 것이다.
'아, 일정은 촉박한데, 이 개발 범위는 처음에 고려하지 않았는데 어쩌지?' 나는 그날 디자이너와 개발자에게 수정 요청하며 진땀을 흘려야 했다.
프로젝트 규모가 큰 경우 프론트와 어드민을 나눠서 설계하게 되는데 이때 어드민을 고려하지 않고 앞단을 설계하다가 자주 실수하는 경우가 생긴다.
클라이언트에게 컨펌을 다 받아놓은 1.0버전 프론트 화면설계서를 구현이 불가능한 어드민 설계 때문에 수정해야 하는 불상사가 생기기도 한다.
물론 돈과 시간만 있다면야 기능 개발이 전혀 불가능한 것은 아니다. 하지만 프로젝트 규모가 커질수록 다른 파트의 기획과 공통적으로 가져가야 하는 부분이 생기기도 하고, 일정이 촉박할 경우 매우 난감한 상황에 놓이게 된다.
나 역시도 이런 경험으로 진땀을 빼봤던 터라 프론트 기획 시에도 어드민과 어떻게 연계할지 항상 고려하는 습관이 생겼다.
가장 좋은 방법은 디스크립션에 기록하는 습관이다. 이 화면에 관리자 연계되는 부분이 있는지 체크하고 만약 있다면 1.관리자 연동여부, 2.신규/수정/유지 여부 3.간단한 설명을 적어주는 것이다.
이렇게 되면 어드민 기획자는 프론트 기획자의 기획 의도를 이해하기 수월해지고, 개발자는 프론트 화면설계만 보고도 개발범위를 어느정도 가늠할 수 있게 된다.
'화면설계서만 공유했는데 개발자와 디자이너가 아무런 질문을 하지 않는 상태'가 될 수 있는 것이다. 물론 나도 이런 경지까지는 가보지 못했지만 질문의 양을 현저히 줄이는 결과는 만들 수 있었다.
이 밖에도 디스크립션에 중요한 요소들은 많다. 아래는 내가 웹기획 신입 때 가장 많이 놓쳤던 부분이다. 이처럼 나만의 디스크립션 체크리스트를 만들고 최종 점검을 해본다면 분명 큰 도움이 될 것이다.
디스크립션 체크리스트
- 사용자 행동별 Case가 있는가?
: 로그인/비로그인, 성공/실패, 결제수단별 등
- 범위에 대한 정의가 있는가?
: 검색 범위/마이그레이션 범위 등
- 신규/수정/유지에 대한 정의가 있는가?
- 알럿메시지가 정의되어 있는가?
- 페이지 이동 시 정의가 있는가?
- 인터렉션에 대한 고려가 되었는가?
- 운영방법(수시/정기)을 고려한 기획이 맞는가?
- 미정/확인이 필요한 것에 대한 체크가 되있는가?
- 구체적인 예시로 이해를 도왔는가?
- 간결한 문장으로 가독성이 있는가?