티스토리 뷰
화면설계서는 어떤 역할을 수행하는가?
화면 설계서는 단순한 문서가 아니라, 프로젝트의 품질을 높이는 중요한 요소다.
1) 구현 기준 제공
- 개발자가 구현할 때 기능 정의와 구성 요소를 정확히 이해할 수 있도록 가이드 제공
- 설계서가 없으면, 개발자가 임의로 UI를 구성할 가능성이 있음
2) 요구사항 및 개선사항 반영 체크
- 설계서를 통해 요구사항이 제대로 반영되었는지 사전 점검 가능
- 인하우스 팀에서는 논의했던 사항이 설계서에 포함되었는지 확인해야 함
=> 설계 단계에서 수정하면 시간이 절약되지만, 개발 단계에서 수정하면 두 배의 시간이 소요됨
3) 사용자 경험(UX) 시뮬레이션
- 화면을 넘겨보면서 사용자 경험(UX)이 직관적인지 확인
- 프로타이핑을 통해서 이 화면의 연계성이 사용자 경험에 도움이 되는지를 체크
- 피그마/XD의 프로토타이핑 기능을 활용해 실제 사용성을 검토
- UX가 불편한 요소를 사전에 발견하여 수정 가능
작성 포인트 : "좋은 화면설계서란?"
-> 프로세스 차트 같은 구조적인 문서보다는, 화면 간의 연계성이 포함된 문서가 더 나은 방식으로 평가된다.
또한, 레이아웃적 특성이 잘 드러난 문서나 공통적인 UI 요소가 명확히 설명된 문서가 더욱 유용하다고 볼 수 있다.
⇒ 사례처럼 프로세스를 정리해주면 훨씬 더 깔끔하다고 인식한다.
1. 프로세스와 레이아웃 구조설명이 충실한 문서
앱 화면 설계 시 고려할 요소
앱을 만들 때에도 공통적인 UI 요소들이 존재한다.
예를 들어
- 헤더(Header) 영역
- 탭바(Tab Bar) 영역
- 전체 메뉴 영역
특히, 진입 화면과 상세 화면이 다를 수 있기 때문에 구조적인 특성을 먼저 앞쪽에서 설명해야 한다.
> 이러한 설명이 부족하면 개별 화면의 이해는 가능하지만, 구현자 입장에서는 가이드가 부족하다고 느낄 수 있다.
> 따라서, 레이아웃과 프로세스적인 측면에서 구조적인 설명이 충실해야 한다.
화면 설계서를 참고서처럼 만드는 것이 좋은데,
정책을 포함하고, 레이아웃 및 프로세스 설명을 충분히 기재하는 것이 중요하다.
=> 이렇게 하면, 구현자들이 큰 틀에서 어떤 역할을 하는지 쉽게 파악할 수 있어 개별 화면에 더 집중할 수 있다.
2. 모듈 단위로 구분되어 있는 문서
📌 반복적인 UI 요소는 모듈화해서 정의하는 것이 가장 좋은 방법이다.
- 한 번 정의하고, 박스형태로 사용
예를 들어
쇼핑몰에서 상품 목록의 공통 UI 요소(매우 세부적인 것 - 상품 이미지, 브랜드명, 가격 정보 등) 다 쓰지 마라. 일일이
넓게는 헤더(Header), 푸터(Footer), 탭바(Tab Bar) 같은 공통 UI 영역
작게는 상품 모듈 같은 것들
=> 속도와 변경에서 훨씬 유연
모듈화를 하지 않으면 발생하는 문제
- 만약 상품 목록에서 가격 표시에 '₩' 대신 '원'을 사용해야 한다면, 화면 설계서 전체에서 이를 수정해야 하는 번거로움이 발생
- 하나라도 놓치면 잘못된 정보가 구현될 가능성이 높음
- 변경 대응이 어렵고, 유지보수가 비효율적임
⇒ 따라서, 화면 설계에서는 반복 사용되는 UI를 개별적으로 정의하지 않고, "공통 모듈"로 지정하여 관리해야 한다.
이렇게 하면, 변경이 생길 때 공통 모듈만 수정하면 되므로 리스크를 줄일 수 있다.
실제 개발에서도 모듈처리해서 불러오는 형태로 작업하지, 매번 하드코딩이나 일일이 구현한다거나 하지를 않는다.
⇒ 싱크를 맞추는 데도 매우 중요.
3. 변경이력과 기록 등 참고 문서가 잘 첨부된 문서
변경 이력이 없을 경우 발생하는 문제
- 최신 버전을 공유했음에도 불구하고, 다른 버전을 보고 작업하는 경우가 많음
- 구현자가 최신 변경 사항을 확인하지 못해 비효율적인 커뮤니케이션 발생
- 어떤 부분이 변경되었는지를 확인하기 어렵기 때문에, 실수가 빈번하게 발생
변경 이력을 명확하게 남기는 방법 : 각 화면 설계서에 "수정 이력 카드"를 삽입(우측)
- 버전별 변경 사항을 검색 가능하도록 문서화
> 검색했을 때 키워드가 걸리게끔
- 설계서에 직접 주석을 추가하기보다는, 별도의 변경 이력 카드를 활용하는 것이 바람직
회원 정책, 비밀번호 정책 등과 같은 정책 관련 내용을 화면 설계서 앞부분에 상세하게 설명/ 참고자료처럼 보이도록
4. 다양한 케이스가 설명되어 있는 문서
회원가입, 버튼 선택 시 발생하는 피드백을 상세하게 정의하는 것이 중요하다.
- 피드백을 알럿창으로 줄 수도 있고, 오류 메시지로도 줄 수 있다.
- 회원 정보 입력 시 오류 메시지
- 버튼 클릭 후 피드백 메시지 (예: 성공, 실패, 경고 등)
✅ 피드백 메시지 정의가 중요한 이유
- UX 라이팅이 발달하면서 일관된 문구 사용이 요구됨
- 기획자마다 다른 표현을 사용하면 사용자가 혼동할 가능성이 있음
- 제공되지 않으면, 사용자가 겪는 경험의 품질이 낮게 느껴진다.
- 일관된 UI/UX 경험을 제공하기 위해, 피드백 메시지를 화면 설계서에서 명확하게 정의해야 함
⇒ 이런 부분에 대해서도 피드백을 최대한 일관성 있게,
어떠어떠한 부분에 대해서 무엇이 필요한지가 명확하게 드러날 수 있는 피드백을 주는 게 화면 설계에서도 중요하다.
또한 그것을 받는 사용자 입장에서도 좋은 경험을 할 수 있는 방법
✅ 피드백 방식의 두 가지 유형
1. 알럿(Alert) 창
- 일방적인 안내 메시지 제공하는 것
- 버튼이 "확인" 하나만 존재한다.
- 모바일에서는 토스트 메시지로 대체되는 경우가 많다.
>> 토스트 메시지 : 왔다가 사라지는 형태
- PC 버전에서도 편리하므로 알럿창보다는 토스트 메시지를 쓴다.
2. 컨펌(Confirm) 창
- 사용자의 선택을 요구하는 메시지
- "예 / 아니오" 같은 옵션 제공
- 예시: "정말 회원가입을 취소하시겠습니까?"
'[기획]' 카테고리의 다른 글
| 화면설계 (4) 디스크립션 (0) | 2025.02.14 |
|---|---|
| 화면설계 (3) 레이아웃 작성 Tip (0) | 2025.02.13 |
| 화면설계 (1) 개요 (0) | 2025.02.12 |
| 백오피스 기획 (0) | 2025.02.07 |
| 정보구조와 카테고리 관리 (0) | 2025.02.07 |
