brunch

You can make anything
by writing

C.S.Lewis

by Digital wanderlust May 29. 2018

13 화면설계서 - 2편

주요 기능 정책, 레이아웃

4. 주요 기능 정책(정의)

화면설계서 설명(Description)란에 포함되는 부분이나 거기엔 UI에 대한 아주 디테일한 부분까지 모두(단순 '확인' 버튼 클릭 시 액션까지) 표현하기에 주요 정책에 대해서는 별도로 사전 정리하고 들어갑니다. 회원가입 화면을 예로 들어 보겠습니다. 예시 정책으로 일부만 작성했으니 참고로만 봐주시고 괄호( ) 안의 문장은 부연 설명 문구로 정책에는 포함되지 않는 글입니다.

1) ID 입력
- 5 byte 이상 입력해야 하며, 중복체크 한다.(만약 4byte 입력 시 Alert이 뜨고, 중복인 경우 역시 Alert으로 '이미 등록된 ID입니다. 다시 입력해 주세요'라는 문구를 본 적이 있을 것입니다.)

2) 폰인증

- 인증번호는 10번까지 재입력할 수 있으며 10번 이상 틀렸을 시엔 재전송 요청 메시지를 alert 한다.

- 인증번호 재전송은 10번까지 할 수 있으며 10번 이상 재전송을 요청했을 경우 고객센터 문의 메시지를 alert 한다.

- 인증번호 입력 없이 회원가입 버튼을 클릭할 경우 alert으로 메시지를 띄운다.

3) 비밀번호 재설정(요즘엔 '비밀번호 찾기' 기능 대신 '비밀번호 재설정' 기능으로 대체하는 편입니다)

- 재설정 클릭 시 폰인증 프로세스를 거치고, ID 입력 후 비밀번호 재설정 화면으로 이동한다.

- 비밀번호는 8자 이상 영문, 숫자, 특수문자 혼용으로 이에 충족하지 못할 경우 메시지를 입력 텍스트 박스 바로 아래 나타낸다.

- 비밀번호 재입력 시 위에 입력한 비밀번호와 다를 경우 '위에 입력한 비밀번호와 동일하지 않습니다. 다시 입력해 주세요.'라는 메시지를 나타낸다.

4) Email

- @가 들어가 있지 않거나 도메인(ooo.com)과 같은 형식에 어긋날 경우 회원가입 등록 시 유효성 체크를 통해 alert을 띄운다.(물론 위 형식에는 맞으나 가짜 Email(ex. 1234@abc.com)을 입력한 경우 걸러낼 방법은 없습니다. 최소한 아무렇지 않게 입력하는 것을 방지하기 위함이지요. 요즘 Captcha(캡차)라고 자동 생성 방지 또는 도용 방지 차원에서 숫자와 영문을 혼용하여 알아보기 어렵게 보여준 후 이와 동일하게 입력하라는 UI를 보셨을 것입니다. 이 역시 유효성 체크 과정이지요.) 


표 형식이 지원되지 않아 위와 같이 작성했는데 각 항목과 정책을 테이블의 셀로 구분하여 알아보기 쉽게 가독성을 높여 주세요. 이 외에도 서비스의 특성에 따라 많은 정보들을 입력받을 텐데 위와 같이 각 항목들에 대한 정책이 필요하며, 개발 완료 후 QA(Quality Assurance: 품질관리)를 진행할 때 위 정책에 충족하는지에 대한 기준으로 QA Sheet를 작성하고, 이를 근거로 테스트를 진행합니다. 단순한 페이지라면 굳이 정책 정의까지 할 필요는 없습니다.


Alert 메시지를 포함해 공지사항이나 FAQ, 도움말들은 말 그대로 '유저'들을 대상으로 한 커뮤니케이션 문구들입니다. 이때 문장들이 기획자의 성격에 따라 달리 작성되는데 예를 들면 아래와 같습니다.

1) 잘못 입력하셨습니다. 다시 입력해 주시기 바랍니다.

2) 잘못 입력했습니다. 다시 입력하세요.

3) 잘못 입력했네. 다시 입력할 거지?


여기에 정답은 없습니다. 서비스의 성격에 따라 문장의 뉘앙스가 달라지기도 하니까요. 제가 서비스 기획자로서 배움의 단계일 땐 극존칭도 반말도 아닌 중립적인 성격을 띠는 2)번이었는데 요즘엔 1)번의 문장을 자주 접하곤 합니다. 다만, 제가 말하고 싶은 포인트는 1)번이든, 2)번이든, 3)번이든 끝까지 통일성 있게 가라는 것입니다. 혼용해서 사용하면 이 역시 서비스의 완성도를 떨어트리는 요소가 되며, 특히 오타는 서비스가 허접하게 보이는 결정적 순간입니다.


동일한 Alert 메시지에서도 '5분 초과하셨습니다'라고 했다가 몇 장 뒤에서는 좀 더 개선하고 싶은 마음에 '5분 초과하여 종료됩니다'라고 적습니다. 그러면 앞 페이지에서도 반드시 동일하게 수정해야 합니다. 만약 등록 페이지를 변경하게 되면, 등록한 내용의 뷰 페이지, 수정 페이지, 목록 페이지도 수정해야 하고, 여기에 전체 서비스 구성도(서비스가 너무 복잡한 경우), IA, UI Descripton 모두 변경해야 합니다. 정말 피곤하고 안타까운 일이지만 서비스 기획자는 꼼꼼해야 할 수 있는 직업입니다.


A, B, C 이해관계자들과 협의하며 드디어 화면설계서를 완성했는데 D, E라는 이해관계자들이 나타나 '이것은 이렇게밖에 할 수 없습니다. 내부 정책상 이렇게 수정되어야 합니다.'라고 했을 때 잠시 좌절감에 멍해지기도 하지만 그에 맞게 수정할 수 있어야 합니다.

남들이 놓치는 요소들을, 미처 생각지 못 한 요소들을, 수많은 경우의 수들을 전부 고민하고 또 고민해서

서비스 플로우를 그리고 화면설계서를 그리는 것이지만 유관부서 이해관계자들에 의해 수없이 수정되는 것이 바로 화면설계서입니다. 이는 나의 기획에 대한 자존심을 건드리는 일, 귀찮은 일이라고 생각하기 보단 'USER'들을 위해 더 나은 서비스 제공을 위한 작업이라 생각하면 좋겠습니다.


아주 타이트한 프로젝트의 경우 화면설계서를 수정해야 하는 시점에 디자인, 퍼블리싱 그리고 개발도 이미 진행을 하고 있을 때라 그들의 짜증과 불평불만을 듣게 마련입니다.(물론 충분히 이해해 주는 사람도 많습니다) 하지만 성공적인 프로젝트의 오픈을 위해 원만하게 끝까지 이끌어 가는 것도 서비스 기획자이자 PM의 몫입니다.



5. Layout(레이아웃)

서브 메뉴가 어떤 페이지에서는 상단에, 어떤 페이지에서는 좌측에 위치하는 사이트는 본 적이 없을 것입니다. 즉 전 페이지에 공통이 되는 UI를 먼저 기획하는데 이를 레이아웃 또는 와이어 프레임이라 부르기도 합니다. 보통 메인과 서브 페이지의 레이아웃을 잡는데 때론 메뉴의 특성에 따라 두 세가지의 서브 페이지가 나오기도 합니다. 메뉴 UI 구성은 이 규칙에 따라 공통적으로 적용되며 각각 해당 메뉴 페이지의 상세 화면을 기획하게(화면설계서를 그리게) 됩니다. 

레이아웃 포맷 역시 구글 이미지 검색 결과를 링크했으니, 최대한 심플하게 영역 구분 정도로 되어 있는 이미지들을 참고로 봐주시면 좋겠습니다. 마음에 드는 이미지가 있는데 저작권이 적용되는 이미지일 수도 있어 포괄적으로 공유합니다.

https://goo.gl/9SLPFV


화면설계서 Tip. - UI Components

기획팀에서 근무하는 경우 본인뿐 아니라 팀원들 모두 서비스 기획자들이고, 모두 화면설계서를 작성합니다. 그리고 누구나 '확인'과 '취소' 버튼, '이전'과 '다음' 버튼, App.에서 'On/Off' 버튼, Select box, Radio button, Check box(checked or unchecked), Table, Scrolling, Tab, Search, Paging number, Push alert number, SNS Share, System alert, SMS UI, Pop-up window, Icons 등을 매번 본인 스타일로 그립니다. 이를 팀 내에서 공통 UI 가이드로 제작해 배포하면 각자 이러한 UI를 그리는 수고를 덜어 시간 단축에 매우 큰 도움이 됩니다.

이런 공통 UI를 쉽게 그리기 위한  유무료 툴도 많은데 일전에 소개드린 프로토타이핑 툴들이 대표적입니다. 저는 Power Mockup이라는 Plug-in 형태의 유료 툴을 이용하는데 가격도 비싸지 않고, 무제한이라는 점이 큰 장점입니다.

https://www.powermockup.com/

개인적으로 적절한 아이콘을 찾기가 쉽고, 화면설계서 전체적인 UI를 통일성 있게 보이는데 도움을 주어 매우 유용하게 사용하고 있습니다.

반드시 팀 내 공통 가이드를 만들지 않더라도 본인만의 컴포넌트들을 만들어 놓고, 복사해서 붙여넣기 방식으로 작업하면 퇴근 시간을 단축시킬 수 있습니다. 다음 편에 이보다 한 2배 시간을 단축시킬 수 있는 팁을, 그 다음 편엔 한 3 배 단축시킬 수 있는 팁도 공유하겠습니다.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari