본문 바로가기

정보처리기사/1과목 소프트웨어 설계

[정보처리기사] Chapter 02. 소프트웨어 설계: 화면 설계

1. 사용자 인터페이스 (UI, User Interface)  (중요도: A)

 사용자 인터페이스는 사용자와 시스템 간의 상호작용이 원활하게 이뤄지도록 도와주는 장치, 소프트웨어를 말한다. 

 초기의 사용자 인터페이스는 단순히 사용자와 컴퓨터 간의 상호작용에 국한되었지만 점차 사용자가 수행할 작업을 구체화시키는 기능 위주로 반전하였고, 최근(2020년 기준)에는 정보 내용을 전달하기 위한 표현 방법으로 변경되었다. 

 

1.1. 사용자 인터페이스의 3가지 분야

물리적 제어에 관한 분야: 정보 제공과 전달

기능에 관한 분야: 모든 사용자가 편리하고 간편하게 사용

콘텐츠의 상세적인 표현과 전체적인 구성에 관한 분야

 

1.2. 사용자 인터페이스의 특징

① UI는 사용자 만족도에 가장 큰 영향을 미치는 요소이다. 

② 소프트웨어 영역 중 변경이 가장 많이 발생한다. 

③ 사용자의 편리성과 가독성을 높임으로써 작업 시간을 단축시키고 업무 이해도를 높인다.

④ 최소한의 노력으로 원하는 결과를 얻을 수 있게 한다.

⑤ 수행 결과의 오류를 줄인다.

⑥ 사용자의 막연한 작업 기능에 대해 구체적인 방법을 제시해 준다.

⑦ 정보 제공자와 공급자 간의 매개 역할을 수행한다.

⑧ 사용자 인터페이스를 설계하기 위해서는 소프트웨어 아키텍처 지식이 반드시 필요하다.

 

▶ 소프트웨어 아키텍처

개발할 소프트웨어의 기본 틀을 만드는 것, 복잡한 소프트웨어 개발 과정을 체계적으로 접근하기 위한 밑그림을 말한다. 

 

1.3. 사용자 인터페이스의 구분

CLI (Command Line Interface): 명령과 출력이 텍스트 형태로 이뤄지는 인터페이스이다.

GUI (Graphical User Interface): 아이콘이나 메뉴를 마우스로 선택하여 작업을 수행하는 그래픽 환경 인터페이스이다.

NUI (Natural User Interface): 사용자의 말이나 행동으로 기기를 조작하는 인터페이스이다.

 

1.4. 사용자 인터페이스의 기본 원칙

◍ 직관성: 누구나 쉽게 이해하고 사용할 수 있어야 한다.

유효성: 사용자의 목적을 정확하고 완벽하게 달성해야 한다.

학습성: 누구나 쉽게 배우고 익힐 수 있어야 한다.

유연성: 사용자의 요구사항을 최대한 수용하고 실수를 최소화해야 한다.

 

1.5. 사용자 인터페이스 설계 지침

지침 유형

내용

사용자 중심

사용자가 쉽게 이해하고 편리하게 사용할 수 있는 환경을 제공하며, 실사용자에 대한 이해가 바탕이 되어야 한다. 

일관성

버튼이나 조작 방법 등을 일관성 있게 제공하므로 사용자가 쉽게 기억하고 습득할 수 있게 설계해야 한다. 

단순성

조작 방법을 단순화시켜 인지적 부담을 감소시켜야 한다.

결과 예측 가능

작동시킬 기능만 보고도 결과를 미리 예측할 수 있게 설계해야 한다. 

가시성

메인 화면에 주요 기능을 노출시켜 최대한 조작이 쉽도록 설계해야 한다.

표준화

기능 구조와 디자인을 표준화하여 한번 학습한 이후에는 쉽게 사용할 수 있도록 설계해야 한다.

접근성

사용자의 연령, 성별, 인종 등 다양한 계층이 사용할 수 있도록 설계해야 한다.

명확성

사용자가 개념적으로 쉽게 인지할 수 있도록 설계해야 한다.

오류 발생 해결 

오류가 발생하면 사용자가 쉽게 인지할 수 있도록 설계해야 한다. 

 

 


2. UI 표준 및 지침  (중요도: B)

2.1. UI 표준 및 지침

웹의 3요소 

내용

웹 표준 

(Web Standards)

웹에서 사용되는 규칙 또는 기술을 의미하며 다른 기기나 플랫폼에서도 동일한 동작이 구현되도록 하는 것을 말한다.

웹 접근성 

(Web Accessibility)

누구나, 어떠한 환경에서도 웹 사이트에서 제공하는 정보를 접근하여 이용할 수 있도록 보장하는 것을 말한다. 

웹 호환성 

(Cross Browsing)

하드웨어나 소프트웨어 등이 다른 환경에서도 동등한 서비스를 제공하는 것을 말한다. 

 

UI 표준 및 지침을 토대로 웹 표준(기술 중립성), 웹 접근성(보편적 표현 보장성), 웹 호환성(기능의 호환성)이 고려되었는지 확인하여야 한다. 

 

UI 표준 : 전체 시스템에 포함된 모든 UI에 공통적으로 적용될 내용을 말한다.

UI 지침 : UI 개발 과정에서 꼭 지켜야 할 공통의 조건을 말한다.

 

2.2. 한국형 웹 콘텐츠 접근성 지침(KWCAG)

 장애인이 비장애인과 동등하게 접근할 수 있는 웹 콘텐츠의 제작 방법을 제시한 지침이다. 웹 콘텐츠 제작자, 설계자 등이 접근성이 보장된 웹 콘텐츠를 쉽게 제작할 수 있도록 도와주는 것이며, 이를 평가할 수 있는 요구 조건을 제시한다. 

 

◍ 인식의 용이성 : 대체 텍스트, 멀티미디어 대체 수단, 명료성(정보 전달이 명확함)

◍ 운용의 용이성 : 키보드 접근성, 충분한 시간 제공, 광과민성 발작 예방, 쉬운 내비게이션

◍ 이해의 용이성 : 가독성, 예측 가능성, 콘텐츠의 논리성, 입력 도움

◍ 견고성 : 문법 준수, 접근성

 

내비게이션 구조의 요소

① 메뉴: 계층 구조를 표현하는 기본 요소이다. 사용자가 원하는 페이지로 이동할 수 있다. 

② 링크: 원하는 페이지로 이동할 수 있게 하는 하이퍼링크를 의미한다.

③ 이미지 맵: 그림에 하이퍼링크를 연결하여 원하는 페이지로 이동할 수 있게 한다.

④ 사이트 맵: 사이트의 전체 구조를 한 눈에 알아볼 수 있도록 트리 구조 형태로 만든다.

⑤ 사이트 메뉴바: 사이트 좌측이나 우측에 메뉴, 링크 등을 모아둔다.

⑥ 내비게이션 바: 메뉴를 한 곳에 모아 높은 그래픽이나 문자열 모음이다. 

⑦ 디렉터리: 주제나 항목을 카테고리별로 표현한 방식이다.

 

2.3. 전자정부 웹 표준 준수 지침

정부기관의 홈페이지 구축 시 반영해야 할 최소한의 규약을 정의한 것으로, 모든 사람이 시스템 환경에 구애받지 않고 정부기관의 홈페이지를 이용할 수 있도록 하기 위한 것이다. 다음과 같은 내용으로 지침을 제시하고 있다. 

 

◍ 내용의 문법 준수

◍ 내용과 표현의 분 리

◍ 동작의 기술 중립성 보장

◍ 플러그인의 호환성

◍ 콘텐츠의 보편적인 표현

◍ 운영체제에 독립적인 콘텐츠 제공

◍ 부가 기능의 호환성 확보

◍ 다양한 프로그램 제공

 


3. UI 설계 도구  (중요도: A)

사용자의 요구사항에 맞게 UI의 화면 구조나 화면 배치 등을 설계할 때 사용하는 도구로,  와이어프레임, 목업, 스토리보드, 프로토타입, 유스케이스 등이 있다. UI 설계 도구로 작성된 결과물은 실제 구현되었을 때의 화면 구성과 수행을 기획단계에서 미리 보여주기 위한 용도로 사용한다. 

 

3.1. 와이어프레임(Wireframe)

기획 단계의 초기에 제작하는 것으로, 페이지에 대한 개략적인 레이아웃이나 UI요소 등에 대한 뼈대를 설계하는 단계이다. 와이어프레임을 제작할 때는 각 페이지의 영역 구분, 콘텐츠, 텍스트 배치 등을 화면 단위로 설계한다. 개발자나 디자이너 등이 레이아웃을 협의하거나 현재 진행 상태 등을 공유하기 위해 사용하는 툴이다.

 

와이어프레임 툴 : 손그림, 파워포인트, 키노트, 스케치, 일러스트, 포토샵 등

 

 

3.2. 목업(Mockup)

 디자인, 사용 방법 설명, 평가 등을 위해 와이어프레임보다 좀 더 실제 화면과 유사하게 만든 정적인 형태의 모형이다. 시각적으로만 구성 요소를 배치하는 것으로 실제로 구현되지는 않는다.

 

◍ 목업 툴 : 파워 목업, 발사믹 목업 등

 

3.3. 스토리보드(Story Board)

 와이어프레임에 콘텐츠에 대한 설명, 페이지 간 이동 흐름 등을 추가한 문서이다. 디자이너와 개발자가 최종적으로 참고하는 작업 지침서로, 정책, 프로세스, 콘텐츠 구성, 와이어프레임, 기능 정의 등 서비스 구축을 위한 모든 정보가 들어 있다. 디스크립션은 화면에 대한 설명, 전반적인 로직, 분기처리 예외 처리 등을 작성하는 부분으로, 명확하고 세부적으로 작성해야 한다. 

 

◍ 스토리보드 툴 : 파워포인트, 키노트, 스케치, Axure 등

 

 

3.4. 프로토타입(Prototype)

와이어프레임이나 스토리보드 등에 인터랙션(UI를 통해 시스템을 사용하는 일련의 상호 작용)을 적용함으로써 실제 구현된 것처럼 테스트가 가능한 동적인 형태의 모형이다. 프로토타입은 사용성 테스트나 작업자 간 서비스 이해를 위해 작성하는 샘플이다. 

 

◍ 프로토타입 툴 : HTML/CSS, Axure, Flinto, 네이버 프로토나우, 카카오 오븐 등

 

 

3.5. 유스케이스(Use Case)

 사용자 측면에서의 요구사항, 사용자가 원하는 목표를 달성하기 위해 수행할 내용 기술한다. 사용자의 요구사항을 빠르게 파악함으로써 프로젝트 초기에 시스템의 기능적인 요구를 결정하고 그 결과를 문서화할 수 있다. 사용자의 요구사항을 구조적으로 표현하여 다이어그램의 형식으로 묘사된다. 

 

 


4. UI 요구사항 확인 (중요도: B)

 새로 개발할 시스템에 적용할 UI 관련 요구사항을 조사해서 작성하는 단계로, 다양한 경로를 통해 사용자의 요구사항을 조사하고 분석한 후 작성해야 한다.

 

요구사항의 순서: 목표 정의 → 활동 사항 정의 → UI 요구사항 작성

 

4.1. 목표 정의

 목표 정의 단계에서는 사용자들을 대상으로 인터뷰를 진행한 후 사용자들의 의견이 수렴된 비즈니스 요구사항을 정의한다. 인터뷰를 통해 사업적, 기술적인 요구사항을 명확히 이해하여야 한다. 

 

4.2. 활동 사항 정의

 조사한 요구사항을 토대로 앞으로 해야 할 활동 사항을 정의한다. 사용자와 회사의 비전을 일치시키는 작업을 진행하며 리서치 규모, 디자인 목표를 결정할 수 있도록 각각에 필요한 예산과 일정을 결정한다. 

 

4.3. UI 요구사항 작성

 UI 요구사항의 작성은 여러 경로를 통해 수집된 사용자들의 요구사항을 검토하고 분석하여 UI 개발 목적에 맞게 작성해야 한다. 실사용자를 중심으로 작성하며 인터뷰를 통해 다양한 의견을 수렴해서 작성하는 것이 좋다. UI 요구사항을 바탕으로 UI의 전체적인 구조를 파악 및 검토해야 한다. 

 

 UI 요구사항 작성 순서: 요구사항 요소 확인→ 정황 시나리오 작성→ 요구사항 작성

 

4.4. 요구사항 요소 확인

파악된 요구사항 요소의 종류와 각각의 표현 방식 등을 검토한다. 

데이터 요구

사용자가 요구하는 모델과 객체들의 주요 특성을 기반으로 하여 데이터 객체들을 정리한다.

기능요구

사용자의 목적 달성을 위해 무엇을 실행해야 하는지 동사형으로 설명한다.

제품/서비스 품질

데이터 및 기능 요구 외에 제품의 품질 서비스, 감성적인 품질을 고려하여 작성한다.

제약 사항

제품 완료 데드라인, 전체 개발 및 제작에 필요한 비용, 시스템 준수에 필요한 규제가 포함된다. 

 

4.5. 정황 시나리오 작성

 사용자의 요구사항을 도출하기 위해 작성하는 것으로, 사용자가 목표를 달성하기 위해 수행하는 방법을 순차적으로 묘사한다. 정황 시나리오는 요구사항 정의에 사용되는 초기 시나리오이며, 개발하는 서비스의 모습을 상상하는 첫 단계이다. 때문에 해당 UI를 사용할 사용자 관점에서 시나리오를 작성해야 한다. 사용자가 주로 사용하는 기능 위주로 작성하며 육하 원칙에 따라 간결하고 명확하게 작성한다. 

 

4.6. 요구사항 작성

요구사항은 정황시나리오를 토대로 작성한다.

정황 시나리오

요구사항

철수는 회의가 끝난 후 휴대폰을 켰다. 

주요 회의 내용을 메모하고 다음 약속을 확인하는 한편, 회의 동안 중요한 전화가 있었는지 확인했다. 

◍ 문자를 입력할 수 있어야 한다.

◍ 약속을 추적할 수 있어야 한다.

◍ 메시지 리스트를 확인할 수 있어야 한다.

◍ 핸드폰으로 구현이 가능해야 한다. 

 

 


5. 품질 요구사항 (중요도: B)

소프트웨어의 품질은 소프트웨어의 기능, 성능, 만족도 등 소프트웨어에 대한 요구사항이 얼마나 충족하는가를 나타내는 소프웨어 특성의 총체이다. 소프트웨어의 품질은 사용자의 요구사항을 충족시킴으로써 확립된다. 

 

ISO/IEC 9126 

소프트웨어의 품질 특성과 평가를 위한 표준 지침이다. 

소프트웨어 품질에 대한 요구사항을 기술하거나 개발중인 또는 개발이 완료된 소프트웨어의 품질 평가 등에 사용된다.

ISO/IEC 9126에서 제시한 품질 특성: 

기능성, 신뢰성, 사용성, 효율성, 유지 보수성, 이식성

 

5.1. 기능성(Functionality)

 사용자의 요구사항을 정확하게 만족하는 기능을 제공하는지 여부를 나타낸다. 적절성, 정밀성, 상호 운용성, 보안성, 호환성으로 구성된다.

 

▶ 상세 품질 요구 사항

적절성/정합성: 지정된 작업과 사용자의 목적 달성을 위해 적절한 기능을 제공할 수 있는 능력 

정밀성/정확성: 사용자가 요구하는 결과를 정확하게 산출할 수 있는 능력 

상호 운용성: 다른 시스템들과 서로 어울려 작업할 수 있는 능력 

◍ 보안성: 정보에 대한 접근을 권한에 따라 허용하거나 차단할 수 있는 능력

호환성: 기능과 관련된 표준, 관례 및 규정을 준수할 수 있는 능력 

 

5.2. 신뢰성(Reliability)

 소프트웨어가 요구된 기능을 정확하고 일관되게 오류 없이 수행할 수 있는 정도를 나타낸다. 성숙성, 고장 허용성, 회복성으로 구성된다.

 

▶ 상세 품질 요구 사항

성숙성: 결함으로 인한 고장을 피해갈 수 있는 능력

◍ 고장 허용성: 결함 또는 인터페이스 결여 시에도 규정된 성능 수준을 유지할 수 있는 능력

회복성: 고장 시 규정된 성능 수준까지 다시 회복하고 직접적으로 영향 받은 데이터를 복구할 수 있는 능력

 

5.3. 사용성(Usability)

 사용자와 컴퓨터 사이에 발생하는 어떠한 행위에 대하여 사용자가 정확하게 이해하고 사용하며, 향후 다시 사용하고 싶은 정도를 나타낸다. 이해성, 학습성, 운용성, 친밀성으로 구성된다.

 

▶ 상세 품질 요구 사항

이해성: 소프트웨어의 적합성, 사용 방법 등을 사용자가 이해할 수 있는 능력

학습성: 소프트웨어 어플리케이션을 학습할 수 있도록 하는 능력

운용성: 사용자가 소프트웨어를 운용하고 제어할 수 있도록 하는 능력

◍ 친밀성: 사용자가 소프트웨어를 다시 사용하고 싶어 하도록 하는 능력 

 

5.4. 효율성(Efficiency)

사용자가 요구하는 기능을 할당된 시간 동안 한정된 자원으로 얼마나 빨리 처리할 수 있는지 정도를 나타낸다. 시간 효율성과 자원 효율성으로 구성된다.

 

▶ 상세 품질 요구 사항

시간 효율성: 특정 기능을 수행할 때 적절한 반응 시간 및 처리 시간, 처리율을 제공할 수 있는 능력

자원 효율성: 특정 기능을 수행할 때 적절한 자원의 양과 종류를 제공할 수 있는 능력 

 

5.5. 유지 보수성(Maintainability)

 환경의 변화 또는 새로운 요구사항이 발생했을 때 소프트웨어를 개선하거나 확장할 수 있는 정도를 나타낸다. 분석성, 변경성, 안전성, 시험성으로 구성된다.

 

▶ 상세 품질 요구 사항

분석성: 결함이나 고장의 원인, 수정될 부분들의 식별을 가능하게 하는 능력

변경성: 결함 제거 또는 환경 변화로 인한 수정 등을 쉽게 구현할 수 있는 능력

안전성: 변경으로 인한 예상치 못한 결과를 최소화할 수 있는 능력 

◍ 시험성: 소프트웨어의 변경이 검증될 수 있는 능력

 

5.6. 이식성(Portability)

 소프트웨어가 다른 환경에서도 얼마나 쉽게 적용할 수 있는지 정도를 나타낸다. 적용성, 설치성, 대체성, 공존성으로 구성된다.

 

▶ 상세 품질 요구 사항

적용성: 원래의 목적으로 제공되는 것 외에 다른 환경으로 변경될 수 있는 능력 

설치성: 임의의 환경에 소프트웨어를 설치할 수 있는 능력

대체성:동일한 환경에서 동일한 목적을 위해 다른 소프트웨어를 대신하여 사용될 수 있는 능력

◍ 공존성: 자원을 공유하는 환경에서 다른 소프트웨어와 공존할 수 있는 능력

 

 


6. UI 프로토타입 제작 및 검토  (중요도: A)

 사용자 요구사항을 기반으로 실제 동작하는 것처럼 만든 동적인 형태의 모형으로 테스트가 가능하다. 프로토 타입은 사용자의 요구사항을 개발자가 맞게 해석했는지 검증하기 위한 것으로 최대한 간단하게 만들어야 한다. 

 프로토타이핑 및 테스트를 거치지 않고는 실제 사용자와 제품 간의 상호 작용 방식을 예측하기 어려우므로 실제 사용자를 대상으로 테스트하는 것이 좋다. 

 

6.1. UI 프로토 타입의 장점과 단점

장점

◍ 사용자를 설득하고 이해시키키 쉽다.
요구사항과 기능의 불일치 등으로 인한 혼선을 예방할 수 있어 개발 시간을 줄일 수 있다.
사전에 오류를 발견할 수 있다.

단점

반복적인 개선 및 보완 작업으로 작업 시간을 증가 시키고, 필요 이상으로 자원을 소모할 수 있다.
부분적으로 프로토타이핑을 진행하다보면 중요한 작업이 생략될 수 있다. 

 

6.2. 프로토타이핑의 종류

1) 페이퍼 프로토타입

 아날로그적인 방법으로, 스케치, 그림, 글 등을 이용하는 것이다. 제작 기간이 짧고, 제작 비용이 적고, 업무 협의가 빠를 경우 사용한다.

◍ 장점: 저렴한 비용, 즉시 변경 가능, 고객이 과대한 기대를 하지 않음

◍ 단점: 테스트하기에 부적당, 공유하기 어려움, 상호 관계가 많은 경우 나타내기 복잡함

 

2) 디지털 프로토타입

 파워포인트, 비지오, 아크로뱃 등과 같은 프로그램을 사용하는 것이다. 재사용이 필요한 경우, 산출물과 비슷한 효과가 필요한 경우, 숙련된 전문가가 있을 경우에 사용한다.

◍ 장점 : 최종제품과 비슷한 테스트 가능, 쉬운 수정, 재사용 가능

◍ 단점 : 프로그램의 사용법 숙지가 필요함

 

6.3. UI 프로토타입 계획 및 작성시 고려 사항 

계획 시 

고려 사항

◍ 프로토타입의 개발 목적을 확인한다.
◍ 개발에 필요한 환경을 마련한다.
◍ 아키텍쳐의 확정 이후와 프로젝트 실제 분석의 완료전에 진행되어 햔다.
◍ 프로토타입을 통해 발생하는 이슈를 모두 취합하고 해결 방법을 제시한다.

작성 시 

고려사항

◍ 프로젝트 범위, 리스크 상황 등 주변 여건을 감안해서 프로토타입의 범위를 정한다.
◍ 얻고자하는 목표를 확인한다.
◍ 목표 달성을 위한 기간 및 비용을 최저치를 확인한다.
◍ 프로토타입의 검증 범위가 너무 넓고 길지 않게 설정한다.

 

6.4. UI 프로토타입 제작 단계

1단계

◍ 사용자의 요구사항을 분석하는 단계로, 사용자 관점에서 기본적인 요구사항이 확정될 때까지 수행한다.

2단계

◍ 요구사항을 충족하는 프로토타입 작성한다.

◍ 프로토타입은 개발할 시스템의 핵심적인 기능을 중심으로 개발한다.

3단계

◍ 작성된 프로토타입이 요구사항을 잘 수행하고 있는지 사용자가 직접 확인하는 단계이다.

◍ 프로토타입에 대해 다양한 추가 및 수정, 의견 제안이 이루어진다. 

4단계

◍ 작성된 프로토타입을 기반으로 수정과 합의가 이뤄지는 단계이다.

◍ 개발자는 사용자가 요청한 제안 사항을 수용해 보안 작업을 한다.

◍ 최종적으로 승인을 완료할 때까지 3,4 단계를 반복한다.

 


7. UI 설계서 작성  (중요도: B)

UI 설계서는 사용자의 요구사항을 바탕으로 UI 설계를 구체화해 작성하는 문서이다. 상세 설계 전에 대표적인 화면들을 설계한다. UI설계서는 기획자, 개발자, 디자이너 등과의 원활한 의사소통을 위해 작성한다. 

 

UI 설계서 작성 순서: UI 설계서 표지→ UI 설계서 개정 이력→  UI 요구사항 정의서→  시스템 구조→ 사이트 맵→ 프로세스 정의서→ 화면 설계 

 

7.1. UI 설계서 표지 작성

다른 문서와 혼동되지 않도록 프로젝트명 또는 시스템명을 포함 시켜 작성한다.

 

7.2. UI 설계서 개정 이력 작성

UI 설계서 개정 이력은 UI 설계서가 수정될 때마다 어떤 부분이 어떻게 수정되었는지를 정리해 놓은 문서이며, 일반적으로 초안을 V1.0으로 잡고 변경 사항이 있을 때마다 0.1씩 버전을 높이며 작성한다.

 

7.3. UI 요구사항 정의서 작성

UI 요구사항 정의서는 사용자의 요구사항을 확인하고 정리한 문서로, 사용자 요구사항의 UI적용 여부를 요구사항별로 표시한다. 

 

7.4. 시스템 구조 작성

시스템 구조는 UI 요구사항과 UI 프로토타입에 기초해 전체 시스템의 구조를 설계한 것이다. 사용자의 요구사항이 어떻게 시스템에 적용되는지 알 수 있다. 

 

7.5. 사이트 맵 작성

사이트 맵은 시스템 구조를 바탕으로 사이트에 표시할 콘텐츠를 한 눈에 알아 볼 수 있도록 메뉴별로 구분하여 설계한 것이다. 사이트 맵을 작성한 후 사이트 맵의 상세 내용을 표 형태로 작성한다. 

 

7.6. 프로세스 정의서 작성

프로세스 정의서는 사용자 관점에서 사용자가 요구하는 프로세스들을 작업 진행 순서에 맞춰 정리한 것이다. UI의 전체적인 흐름을 파악할 수 있다. 

 

7.7. 화면 설계

 화면 설계는 UI 프로토타입과 UI 프로세스를 참고하여 필요한 화면을 페이지별로 설계한 것이다. 화면을 구분하기 위해 화면별 고유ID를 부여하고 별도 표지를 작성한다. 와이어프레임과 스토리 보드를 사용한다.

 


8. 유용성 평가 (중요도: C)

 유용성은 사용자가 시스템을 통해 원하는 목표를 얼마나 효과적으로 달성할 수 있는가에 대한 척도로 UI의 주된 목적은 유용성이 뛰어난 UI를 제작하는 것이다. 

 UI 유용성 평가는 용자가 생각하는 사용자 모형과 시스템 설계자가 만들려고 하는 개발자 모형 간의 차이를 최소화하기 위해 작성된다. 사용자가 시스템을 얼마나 편리하게 사용할 수 있는지를 평가하는 것으로 시스템의 문제를 찾아내고 개선 방향을 제시하기 위한 조사 과정이다. 

 

◍ 실행 차: 사용자가 원하는 목적과 실행 기능이 다르기 때문에 발생

◍ 평가 차: 사용자가 원하는 목적과 실행 결과가 다르기 때문에 발생

 

8.1. 실행 차를 줄이기 위한 UI 설계 원리 검토

사용자 의도 파악: 불필요한 기능 혹은 중복 기능 여부 확인한다. 

행위 순서 규정: 행위 순서를 세분화하여 제시, 사용자의 변경이 가능하도록 해야한다. 특정 작업을 수행하기 위한 단계는 최소화하고, 다양한 방법을 통해 수행할 수 있도록 설계한다. 또한 사용자 경험을 고려하여 친숙한 것이 유리하다. 

행위의 순서대로 실행: 프로세스의 흐름을 직접적으로 파악할 수 있도록 제공한다. 사용자가 행위 순서대로 실행할 때 어려움이 없어야 한다. 작업이 원활하게 진행되도록 과도한 상호 작용은 피한다. 

 

8.3. 평가 차를 줄이기 위한 UI 설계 원리 검토

◍ 수행한 키 조작의 결과를 사용자가 빠르게 지각하도록 유도한다.

◍ 키 조작으로 변화된 시스템의 상태를 사용자가 쉽게 인지하도록 유도한다.

◍ 사용자가 가진 원래 의도와 시스템 결과 간의 유사 정도를 사용자가 쉽게 파악하도록 유도한다. 

 


9. UI 상세 설계 (중요도: B)

9.1. UI 시나리오 문서

 UI 상세 설계는 UI 설계서를 바탕으로 실제 설계 및 구현을 위해 모든 화면에 대한 자세한 설계를 진행하는 단계로, UI 상세 설계를 할 때는 반드시 시나리오를 작성해야 한다. 시나리오 문서는 사용자 인터페이스의 기능 구조, 대표 화면, 화면 간 인터랙션의 흐름, 다양한 상황에서의 예외 처리 등을 문서로 정리한 것이다.때문에 사용자가 최종 목표를 달성하기 위한 방법이 순차적으로 묘사되어 있다. 

 

9.2. UI 시나리오 문서 작성 원칙

◍ 개발자가 전체적인 UI의 기능과 작동 방식을 한눈에 이해할 수 있도록 구체적으로 작성한다. 계층 구조 또는 플로차트 표기법으로 작성하는 것이 일반적이다.

◍ 모든 기능에 공통적으로 적용될 UI 요소와 인터랙션을 일반 규칙으로 정의한다.

◍ 인터랙션의 흐름을 정의하며, 화면 간 인터랙션의 순서, 분기, 조건, 루프 등을 명시한다

◍ 예외 상황에 대비한 다양한 케이스를 정의한다.

◍ UI 일반 규칙을 지키면서 기능별 상세 기능 시나리오 정의한다. 

 

9.3. UI 시나리오 문서 작성을 위한 일반 규칙 

구분

설명

주요 키의 위치와 기능

모든 화면에 공통적으로 배치되는 주요 키의 위치와 기능을 설명한 것으로, 여러 화면 간의 일관성을 보장한다.

공통 UI 요소

체크 박스, 라디오 버튼, 텍스트 박스 등의 UI 요소를 언제, 어떤 형태로 사용할지를 정의하고, 사용자가 조작하면 어떻게 반응하는지 그 흐름을 설명한다. 

기본 스크린 레이아웃

모든 화면에 공통적으로 나타나는 Titles, Ok/Back, Soft key, Option, Functional Buttons 등의 위치와 속성을 정의한다.

기본 인터랙션 규칙

터치 제스처 등에 공통적으로 사용되는 조작 방법과 실행, 이전, 다음, 삭제, 이동 등의 화면 전환 효과 등을 기술한다.

공통 단위 태스크 흐름

많은 기능들에 공통적으로 사용되는 삭제, 검색, 매너 모드 상태 등에 대한 인터랙션 흐름을 설명한다.

케이스 문서

다양한 상황에서 공통적으로 적용되는 시스템의 동작을 정의한 문서이다.

 

9.4. UI 시나리오 문서의 요건

◍ 완전성: 누락되지 않도록 최대한 상세하게 기술해야 한다. 해당 시스템의 기능보다는 사용자의 태스크에 초점을 맞춰 기술한다. 

◍ 일관성: 서비스 목표, 시스템 및 사용자의 요구사항, UI 스타일 등이 모두 일관성을 유지해야 한다.

◍ 이해성: 누구나 쉽게 이해할 수 있어야한다. 추상적인 표현 방식은 삼가한다.

◍ 가독성: 표준화된 템플릿을 이용하여 가독성을 높인다. 읽기 편하도록 취할 수 있는 규칙과 기준을 마련하고 이를 적용한다.

◍ 수정 용이성: 시나리오 수정이나 개선이 쉬워야 한다.

◍ 추적 용이성: 변경 사항은 언제, 어떤 부분이, 왜 발생했는지 쉽게 추적할 수 있어야한다. 

 

9.5. UI 시나리오 문서로 인한 기대 효과

◍ 요구사항이나 의사소통에 대한 오류 감소한다.

◍ 개발 과정에서의 재작업 감소, 혼선을 최소화할 수 있다.

◍ 불필요한 기능을 최소화할 수 있다.

◍ 소프트웨어 개발 비용 절감할 수 있다.

◍ 개발 속도를 향상할 수 있다.

 

 


10. HCI / UX / 감성공학 (중요도: C)

10.1. HCI(Human Computer Interaction or Interface)

 HCI는 사람이 시스템을 보다 편리하고 안전하게 사용할 수 있도록 연구하고 개발하는 학문으로, 최종 목표는 시스템을 사용하는데 있어 최적의 사용자 경험(UX)을 만드는 것이다. 

 

10.2. UX(User Experience)

 사용자가 시스템이나 서비스를 이용하면서 느끼고 생각하게 되는 총체적인 경험을 말한다. 단순히 기능이나 절차상의 만족뿐만 아니라 사용자가 참여, 사용, 관찰하고, 상호 교감을 통해서 알 수 있는 가치 있는 경험을 말한다. UI가 사용성, 접근성, 편의성을 중시한다면 UX는 이러한 UI를 통해 사용자가 느끼는 만족이나 감정을 중시한다. 

 

▶ UX의 특징 

◍ 주관성: 사람들의 개인적, 신체적, 인지적 특성에 따라 다르므로 주관적인 특성을 가진다.

◍ 정황성: 경험이 일어나는 상황 또는 주변 환경에 영향을 받는다.

◍ 총체성: 개인이 느끼는 총체적인 심리적, 감성적 결과이다.

 

10.3. 감성공학

 감성공학은 제품이나 작업환경을 사용자의 감성에 알맞도록 설계 및 제작하는 기술이다. 인문사회과학, 공학, 의학 등 여러 분야의 학문이 공존하는 종합과학이다. 인간의 삶을 편리하고 안전하며 쾌적하게 만드는 것을 목적으로 하며, 인간의 감성을 구체적으로 제품 설계에 적용하기 위해 공학적인 접근 방법을 사용한다.

 

▶ 감성공학의 요소기술 

◍ 기반 기술 : 제품 설계에 적용할 인간의 특성을 파악한다.

◍ 구현 기술 : 인간의 특성에 맞는 인터페이스 구현한다.

◍ 응용 기술 : 인간에 맞는지 파악해 새로운 감성을 만든한다.