반응형
2. UI 설계하기
2-1. UI 흐름설계
- UI 설계서 구성에 따른 작성 방법 : UI 설계서 구성은 UI 설계서 표지, UI 설계서 개정 이력, UI 요구사항 정의, 시스템
구조, 사이트 맵, 프로세스 정의, 화면 설계 등으로 이루어진다.
UI 설계서 표지 | UI 설계서에 포함될 프로젝트 명 또는 시스템 명을 포함시킨다. |
UI 설계서 개정 이력 | UI 설계서 처음 작성 시에는 첫 번째 항목으로 ‘초안 작성’을 포함시키고 그에 해당되는 초기 버전(version)을 1.0으로 설정한다. 변경 또는 보완이 충분히 이루어져 완성이 되었다고 판단할 경우 버전을 x.0 으로 바꾸어 설정한다. |
UI 요구사항 정의 | UI 요구사항들을 재확인하고 정리한다. |
시스템 구조 | - UI 프로토타입을 재확인한다. - UI 요구사항들과 UI 프로토타입에 기초해 UI 시스템 구조를 설계한다. |
사이트 맵(Site Map) | - UI 시스템 구조의 내용을 사이트 맵의 형태로 작성한다. - 사이트 맵 상세 내용(Site Map Detail)을 표 형태로 작성한다. |
프로세스(Process) 정의 | 사용자 관점에서 요구되는 프로세스들을 진행되는 순서에 맞추어 정리한다. |
화면 설계 | UI 프로토타입과 UI 프로세서 정의를 참고해 각 페이지별로 필요한 화면을 설계한다. - 각 화면별로 구분되도록 각 화면별 고유 ID를 부여하고 별도의 표지 페이지를 작성한다. - 각 화면별로 필요한 화면 내용을 설계한다. |
- 유용성 : 사용자가 시스템을 통해 원하는 목표를 얼마나 효과적으로 달성할 수 있는가에 대한 척도이다.
- 유용한 시스템을 설계할 때 고려사항 : 사용자가 시스템의 구조, 기능, 가치 등에 대해 가지고 있는 마음 속 모형인 사용자 모형과 시스템 설계자가 만들려고 하는 개발자 모형 사이의 차이를 최소화하려는 노력이 필요하다.
- 사용자 모형과 개발자 모형 간의 차이 발생 : 시스템에서의 실행 차, 즉 실행 가능한 기능과 사용자의 원래 목적이 서로 상이하기 때문에 발생한다. 평가 차, 즉 시스템의 실행 결과와 사용자의 원래 목적이 서로 상이하기 때문에 발생한다.
- 실행 차를 줄이기 위한 UI 설계 원리
사용 의도 파악 | - 사용자의 원래 목적을 명확히 파악하여 불필요한 부가 기능 때문에 시스템 성능이 떨어지지 않도록 해야 한다. - 사용자가 보다 관심을 가지는 항목을 눈에 띄는 위치에 배치하고 적절한 시점에 해당 기능이 제공되도록 하여야 한다. |
행위 순서 규정 | - 사용자 행위의 순서를 세분화시킨 뒤 순서대로 명확하게 제시하여 선택할 수 있도록 해야 하고 또한 의도에 따라 행위의 순서를 사용자가 임의로 변경 가능하도록 해야 한다. - 하나의 작업을 수행하기 위한 단계 수를 최소화시키고, 동일한 결과를 여러 가지 다른 방법으로도 달성 가능하도록 설계 시 고려해야 하며, 행위의 순서가 사용자의 기존 경험에 비추어 가능한 한 친숙하도록 설계해야 한다. |
행위의 순서대로 실행 | - 프로세스의 흐름을 UI를 통해 직관적으로 알 수 있게 제공함으로써 사용자가 의도한 행위의 순서를 실제 실행으로 옮기는 데 어려움을 최소화해야 한다. - 과도한 상호 작용으로 인해 작업이 원활히 진행되지 못하는 상황이 발생되지 않도록 고려해야 한다. - 사용자가 의도한 행위와 가장 잘 어울리는 입력 장치를 선택하고, 사용자의 행위에 대해 적절한 피드백과 취소 기능을 제공해 주며, 디폴트 값을 적절하게 설정함으로써 불필요한 조작을 최소화하여 사용자가 의도한 행위를 효율적으로 실행할 수 있도록 설계해야 한다. |
- 평가 차를 줄이기 위한 UI 설계 원리
수행한 키 조작의 결과를 사용자가 빠르게 지각하도록 유도 | - 사용자가 수행한 행위에 대해 아무런 변화된 결과가 제공되지 않는다면 사용자는 자신이 제대로 조작하였는지 의심하게 되므로, 이러한 평가 차가 발생하지 않도록 설계해야 한다. - 가능한 한 빠른 처리를 통해 즉각적으로 반응되도록 해야 하며, 즉각적인 반응이 힘들더라도 가능한 한 반응 속도를 높이도록 노력해야 한다. 또한 사용자가 수행한 행위로 인해 현재 시스템의 변화가 이루어졌음을 가능한 한 직관적으로 피드백해 주어야 한다. |
키 조작으로 변화된 시스템의 상태를 사용자가 쉽게 인지하도록 유도 | 사용자가 수행한 행위로 인해 변화된 시스템의 상태를 사용자가 직관적으로 인지할 수 있도록 시스템을 설계해야 한다. 이를 위해 시스템의 상태 정보를 단순하게, 그리고 이해하기 쉽게 제시해야 한다. |
사용자가 가진 원래 의도와 시스템 결과 간의 유사 정도를 사용자가 쉽게 파악하도록 유도 | 사용자가 가진 원래 의도가 시스템을 통해 충족되었는지 또는 충족될 수 있는지를 사용자가 쉽게 파악할 수 있도록 설계해야 한다. 이를 위해 미리보기 기능처럼 예상 결과를 사전에 제시할 수 있다면 제공해 주는 것이 대부분의 경우 바람직하다. |
- 스토리보드 작성 기법 : 스토리보드는 디자이너와 개발자가 최종적으로 참고하는 산출 문서이며, 정책이나 프로세스 및 콘텐츠의 구성, 와이어프레임(UI, UX), 기능에 대한 정의, 데이터베이스의 연동 등 구축하는 서비스를 위한 대부분의 정보가 수록되어 있는 문서이다.
메뉴 구성도 만들기 (스토리보드 1단계) |
전체적인 메뉴 구성도이며, 어떤 것을 보여주고 결정된 사항을 표현하기 위한 메뉴의 순서와 구성 단계, 용어를 정의한다. |
스타일 확정 (스토리보드 2단계) |
레이아웃이나 글자 모양, 크기, 색상, 그래픽에서의 일관성을 유지해야 한다. |
설계하기 (스토리보드 3단계) |
화면에 보여지는 시각적인 디자인 콘셉트를 잡는다. |
2-2. UI 상세설계
- UI 시나리오 작성 원칙 : UI 상세설계에 있어 시나리오 작성은 반드시 필요한 사항이다. 정보통신산업진흥원 부설 SW공학센터의 “소프트웨어 개발 UI/UX 참조모델 가이드“(2014)에 따르면 시나리오 작성의 원칙은 다음과 같이 설명한다.
1. UI의 전체적인 기능과 작동 방식을 개발자가 한눈에 쉽게 이해 가능하도록 구체적으로작성하여야 한다. |
2. 모든 기능은 공통 적용이 가능한 UI 요소와 인터랙션을 일반적인 규칙으로 정의한다. |
3. “대표 화면의 레이아웃과 그 화면들 속의 기능”을 정의한다. 이때의 대표 화면은 시나리오에 포함되는 서로 다른 형태를 가진 독립적인 화면들을가리킨다. |
4. 인터랙션의 흐름을 정의하며, 화면 내와 화면 간 인터랙션의 순서(Sequence), 분기(Branch), 조건(Condition), 루프(Loop) 등을 명시한다. 이때의 인터랙션은 페이퍼 프로토타입에서 발견된 문제점을 모두 개선하여 적용한 최종 인터랙션이어야 한다. |
5. 예외 상황에 대비한 케이스를 정의한다.대부분의 소프트웨어 개발자와 품질 관리자 들이 UI 시나리오 문서에서 가장 많은 불만을 드러내는 부분이 예외 케이스의 정리가 부실하다는 것이다. |
6. UI 일반 규칙을 지키면서 기능별 상세 기능 시나리오를 정의한다. |
7. UI 시나리오 규칙을 지정한다. |
- 프로토타입 제작 구분
주요 키의 위치와 기능 | 화면상에 공통적으로 배치되는 주요 키의 위치와 기능을 설명한 것으로 여러 화면 간의 일관성을 보장하기 위한 것이다. |
공통 UI 요소 | 체크 박스, 라디오 버튼, 스크롤바, 텍스트 입력 필드, 상하/좌우 휠, 모드 설정, 탭, 팝업 등의 각 UI 요소를 언제 사용하며 어떤 형태인지 정의하고 사용자의 조작에 어떻게 반응하는지 그 흐름을 상세하게 설명한 것이다. |
기본 스크린 레이아웃 (Basic Screen Layouts) |
여러 화면 내에 공통적으로 나타나는 Indicators, Titles, Ok/Back, Soft Key, Option, Functional Buttons 등의 위치와 속성을 정의한 것으로서 여러 기능들 간에 화면 레이아웃의 일관성을 보장하기 위한 것이다. |
기본 인터랙션 규칙 (Basic Interaction Rules) |
터치 제스처 등의 공통적으로 사용되는 조작의 방법, 홈 키의 동작 방식과 같은 운항 규칙, 실행, 이전, 다음, 삭제, 이동 등의 화면 전환 효과 등에 대해 기술한 것이다. |
공통 단위 태스크 흐름 (Task Flows) |
많은 기능들에 공통적으로 자주 나타나는 삭제, 검색, 매너 모드 상태에서의 소리 재생 등의 인터랙션 흐름을 설명한 것이다. |
케이스 문서 | 다양한 상황에서의 공통적인 시스템 동작에 대해 정의한 문서이다. (ex. 사운드, 조명, 이벤트 케이스 등) |
- UI 시나리오 문서 작성의 요건 : 정보통신산업진흥원 부설 SW공학센터의 소프트웨어 개발 UI/UX 참조모델 가이드(2014)에 따르면 시나리오 작성의 요건은 다음과 같이 설명한다.
완전성(Complete) | (1) (누락 없이) 완전해야 한다. (2) 최대한 빠짐없이 가능한 한 상세하게 기술한다. (3) 시스템 기능보다 사용자의 태스크에 초점을 맞춰 기술한다. |
일관성(Consistent) | (1) 일관성이 있어야 한다(서비스에 대한 목표, 시스템 및 사용자의 요구사항). (2) 모든 문서의 UI 스타일(Flow 또는 Layout)을 일관적으로 구성한다. |
이해성(Understandable) | (1) 처음 접하는 사람도 이해하기 쉽도록 구성하고 설명한다. (2) 이해하지 못하는 추상적인 표현이나 이해하기 어려운 용어는 사용하지 않는다. |
가독성(Readable) | (1) 문서를 쉽게 읽을 수 있어야 한다(문서 템플릿과 타이포그래피). (2) 표준화된 템플릿을 작성하여 적용한다(회사의 고유한 문서 양식). (3) 버전의 넘버링은 v1.0, v2.0 등과 같이 일관성 있게 한다. 문서의 인덱스에 대한 규칙 적용, 목차 제공이 중요하다. (4) 줄의 간격은 충분하게 유지하며, 단락에 대한 구분과 들여쓰기의 기준을 마련하여 읽기에 쉽고 편해야 한다. (5) 여백과 빈 페이지는 적절하게 활용하여 여백의 미를 살리도록 한다. (6) 시각적인 효과를 위한 하이라이팅은 일관성 있게 활용하도록 한다. (7) 편집기의 상호 참조(Cross-referencing) 기능을 활용한다(하이퍼링크 등). |
수정 용이성(Modifiable) | (1) 쉽게 변경이 가능해야 한다. (2) 수정 또는 개선 사항을 시나리오에 반영함에 있어 쉽게 적용할 수 있어야 한다. (3) 동일한 수정 사항을 위해 여러 문서를 편집하지 않도록 한다. |
추적 용이성(Traceable) | (1) 쉽게 추적이 가능해야 한다. (2) 변경 사항들이 언제, 어디서, 어떤 부분들이, 왜 발생하였는지 추적이 쉬워야 한다. |
모범적인 UI 시나리오 문서의 효과 | (1) 요구사항 오류가 감소한다. (2) 의사소통 오류가 감소한다. (3) 개발 과정에서의 재작업이 감소하고, 혼선이 최소화된다. (4) 불필요한 기능을 최소화한다. (5) 시나리오 작성과 소프트웨어 개발 비용을 절감한다. (6) 개발 속도를 향상시킨다. (7) 유관 부서 만족도를 제고한다. |
※ 자료 출처 : 국가직무능력표준 ☞ ncs.go.kr
반응형
'Memorandum' 카테고리의 다른 글
정보처리기사 필기 소프트웨어 설계 - 애플리케이션설계(NCS학습모듈) (2) (0) | 2023.01.19 |
---|---|
정보처리기사 필기 소프트웨어 설계 - 애플리케이션설계(NCS학습모듈) (1) (0) | 2023.01.18 |
정보처리기사 필기 소프트웨어 설계 - 화면 설계(NCS학습모듈) (1) (2) | 2023.01.13 |
정보처리기사 필기 소프트웨어 설계 - 요구사항 확인(NCS학습모듈) (3) (0) | 2022.12.07 |
정보처리기사 필기 소프트웨어 설계 - 요구사항 확인(NCS학습모듈) (2) (0) | 2022.12.06 |
댓글