설계서 작성시 무엇을 고려해야하나요? (2)
화면설계시 추가로 고려해야하는 사항들
지난 글에서는 화면설계서의 출발점이 되는 와이어프레임과 디스크립션에 대해 정리해보았습니다.
이번 글에서는 설계시 고려해야 할 요소들을 몇가지 더 짚어보겠습니다.
와이어프레임과 디스크립션 작성 시 고려할 사항
1. 디폴트(초기값)
디스크립션에서 항상 빠지지 않고 등장하는 개념 중 하나는 ‘디폴트'입니다. ‘디폴트’는 시스템에서 초기에 미리 설정한 기본 데이터값입니다. 초기값 또는 기본값이라고도 하며 안정적인 구현과 에러 방지를 위해 디폴트를 설정합니다. 위의 1-1 그림에서 지역정보가 사용자의 실제 위치정보와 상관없이 ‘서울 중구'로 노출된다면 이는 디폴트입니다. 반대로 사용자 위치에 따라 지역이 달라진다면 이는 디폴트가 아닙니다. 이외에도 버튼의 활성·비활성화 상태, 아코디언의 접힘 여부, 탭의 초기 선택값 등의 컴포넌트 디폴트도 정의해야 합니다.
2. Error 케이스
에러는 서비스 전반에서 발생하는 공통 에러와 특정 화면에서만 발생하는 에러로 구분할 수 있습니다. 전자는 네트워크 연결 실패, 서버 장애 등이 있고, 후자는 검색 결과가 없거나, 송금이 실패하는 경우 등이 해당합니다.
이 중에서 송금 기능은 다양한 에러 상황을 고려해야 하는 대표적인 사례입니다. 계좌번호 입력 단계에서는 잘못된 계좌 입력이나 동일 계좌 송금과 같은 케이스가 발생할 수 있고, 실제 송금 단계에서는 잔액 부족, 한도 초과, 금융사 점검 등의 다양한 케이스를 고려할 수 있습니다. 여기에 단시간내에 과도한 계좌 조회가 이루어질 경우의 에러 안내처럼 보안 정책에 따른 제한까지 에러 케이스로 정의할 수도 있습니다.
3. Empty 상태
Empty state(빈 상태)는 사용자가 내용이 없는 화면을 보게될 때를 가리킵니다. 예시로는 검색 시 검색 결과가 없는 경우, 게시글이 하나도 없는 경우, 송금 내역이 없는 경우가 있습니다. 빈 상태 화면을 설계할 때는 사용자가 현재 상황을 이해할 수 있도록 안내 문구나 이미지를 제공해야 합니다. 또한 ‘홈으로 가기’ 와 같이 다음 행동을 유도할 수 있는 버튼을 추가하여 이탈을 방지하고, 다음 작업을 용이하도록 하는 것이 중요합니다.
4. 예외 케이스
Error와 Empty 케이스 외에도 사용자가 처해있는 다양한 상황을 생각해보아야 합니다. 지도 앱에서 사용자 위치 권한이 비활성화인 경우, 해외 체류 중인 경우, 기기에 설정된 언어와 서비스 언어가 다른 경우처럼 환경에 따라 안내 방식과 콘텐츠가 달라질 수 있습니다. 언어가 변경된다면 텍스트 길이, 번역이 불가한 단어에 대한 대체 표현까지 함께 설계되어야 합니다.
5. 데이터 로드 시점
일반적으로 콘텐츠 영역은 화면 진입시 데이터를 바로 불러옵니다. 다만 시스템 로직이나 사용자의 인터랙션에 의해 데이터 로드 시점을 정의해야 하는 경우도 있습니다. 예를 들어, 주식 앱의 주가 차트 화면은 짧게는 수 분, 수 초의 시간이 지나거나 주식 거래 체결이 발생함에 따라 차트 그림이 새로 그려집니다. 데이터 로드를 트리거하는 조건이 특정 시간 또는 시스템 로직에 의한 입력값이 되는 것입니다. 이런 경우 데이터 로드의 조건을 명확히 설정해야 개발자가 정확한 구현을 할 수 있습니다.
6. 설계서 유지보수
1) 템플릿 작성하기
설계서 작성에서 가장 먼저 해야 할 일은 템플릿을 만드는 것입니다. 파워포인트로 치면 슬라이드 양식에 해당합니다. 템플릿을 사용하면 설계서의 모든 페이지가 일관된 디자인과 레이아웃을 유지하게 되고, 이는 프로젝트의 일관된 스타일을 보장합니다. 매번 새로운 페이지를 작성할 때마다 디자인과 구조를 고민할 필요가 없으므로 페이지를 빠르고 안정적으로 작성할 수 있습니다.
2) 별도 문서로 관리하는 것이 효율적인지 판단하기
기능이 복잡하고 설명할 내용이 많으면 디스크립션은 별도의 엑셀 문서로 작성하기도 합니다. 하지만 개발자 입장에서 설계서와 기능명세서를 동시에 보는 것이 부담이 되기 때문에 와이어프레임과 함께 작성할 때가 많습니다.
또한 변경이 잦은 내용이라면, 업데이트마다 설계서를 수정해야 하는 번거로움이 생길 수 있습니다. 이런 경우에는 별도 문서로 분리해 관리하는 편이 더 효율적입니다.
좋은 설계서란...
설계서 작성에서 고려해야할 사항에 대해 다양하게 이야기해보았지만, 사실 좋은 설계서의 절대적인 기준은 없습니다. 다만 좋은 설계서를 만들기 위해서는 작업자들과의 적극적인 소통을 통해 설계서를 점차 다듬어나가야 합니다.
많은 기획자들이 처음부터 완벽한 설계서를 만들고 싶어 하지만, 그것은 불가능에 가깝습니다. 기획자는 개발자보다 개발을 모르고 디자이너보다 디자인을 모르기 때문입니다. 기획자의 역할은 설계서 작성 자체에 있지 않습니다. 설계서라는 도구를 가지고 원활한 협업을 통해 프로젝트의 목표를 이뤄내는 것이 기획자의 역할입니다.
오고가는 대화 속에서 서로가 '그건 니 생각이고'라고 외치고 싶은 순간이 있을 것입니다. 하지만 프로젝트 협업 과정에서 기획자는 이러한 갈등을 해소하고 모두가 한 방향으로 나아갈 수 있도록 이끌어야 합니다. 때로는 개발자의 기술적 제약이나 디자이너의 디자인 원칙 등과 충돌할 수 있지만, 이러한 다양한 의견을 수렴하고 조화롭게 결합하는 것이 프로젝트의 성패를 좌우할 수 있습니다.
https://www.thelisn.com/articles