- 사용자 인터페이스
- 사용자와 시스템 간의 상호작용이 원활하게 이뤄지도록 도와주는 장치나 소프트웨어
- 정보 내용을 전달하기 위한 표현 방법
- 사용자 인터페이스의 세가지 분야
- 물리적 제어에 관한 분야
- 콘텐트의 상세적인 표현과 전체적인 구성에 관한 분야
- 기능에 관한 분야
- 사용자 인터페이스의 특징
- 변경이 가장 많이 발생
- 사용자의 편리성과 가독성을 높임으로써 작업 시간을 단축시키고 업무에 대한 이해도를 높여줌
- 최소한의 노력으로 원하는 결과를 얻을 수 있게 함
- 수행 결과의 오류를 줄임
- 구체적인 방법을 제시
- 정보 제공자와 공급자 간의 매개 역할을 수행
- 소프트웨어 아키텍처를 반드시 숙지해야 함
- 사용자 인터페이스의 구분
- CLI : 명령과 출력이 텍스트 형태로 이뤄지는 인터페이스
- GUI : 아이콘이나 메뉴를 마우스로 선택하여 작업을 수행하는 그래픽 환경의 인터페이스
- NUI : 사용자의 말이나 행동으로 기기를 조작하는 인터페이스
- 사용자 인터페이스의 기본 원칙
- 직관성 : 누구나 쉽게 이해하고 사용할 수 있어야함
- 유효성 : 사용자의 목적을 정확하고 완벽하게 달성해야 함
- 학습성 : 누구나 쉽게 배우고 익힐 수 있어야 함
- 유연성 : 사용자의 요구사항을 최대한 수용하고 실수를 최소화해야 함
- 사용자 인터페이스의 설계 지침
- 사용자 중심 : 사용자가 쉽게 이해하고 편리하게 사용할 수 있는 환경을 제공하며, 실사용자에 대한 이해가 바탕이 되어야 함
- 일관성 : 버튼이나 조작 방법 등을 일관성 있게 제공하므로 사용자가 쉽게 기억하고 습득할 수 있게 설계해야 함
- 단순성 : 조작 방법을 단순화시켜 인지적 부담을 감소시켜야 함
- 결과 예측 가능 : 작동시킬 기능만 보고도 결과를 미리 예측할 수 있어야 함
- 가시성 : 메인 화면에 주요 기능을 노출시켜 최대한 조작이 쉽도록 설계해야 함
- 표준화 : 기능 구조와 디자인을 표준화하여 한 번 학습한 이후에는 쉽게 사용할 수 있도록 설계해야 함
- 접근성 : 사용자의 연령, 성별, 인종 등 다양한 계층이 사용할 수 있도록 설계해야 함
- 명확성 : 사용자가 개념적으로 쉽게 인지할 수 있도록 설계해야 함
- 오류 발생 해결 : 오류가 발생하면 사용자가 쉽게 인지할 수 있도록 설계해야 함
- UI 표준 및 지침
- UI 표준과 지침을 토대로 기술의 중립성(웹 표준), 보편적 표현 보장성(웹 접근성), 기능의 호환성(웹 호환성)이 고려되었는지 확인
- 한국형 웹 콘텐츠 접근성 지침(KWCAG)
- 장애인이 비장애인과 동등하게 접근할 수 있는 웹 콘텐츠의 제작 방법을 제시
- 목적은 웹 콘텐츠 저작자, 웹사이트 설계자 등이 접근성이 보장된 웹 콘텐츠를 쉽게 제작할 수 있도록 도와주는 것
- 웹 접근성의 준수 여부를 평가할 수 있는 요구조건과 이를 모두 준수할 경우 얻을 수 있는 기대 효과가 제시되어 있음
- 웹 콘텐츠 접근성 지침 준수를 위한 고려 사항
- 이미지에 대체 택스트 제공
- 키보드만으로 접근할 수 있어야 함
- 충분한 시간 제공
- 광과민성 발작을 일으킬 수 있는 콘텐츠는 제공 x
- 예측이 가능해야 함
- 입력 오류를 방지하거나 정정할 수 있어야 함
- 웹 콘텐츠는 마크업 언어의 문법을 준수
- 접근성이 있어야 함
- 전자 정부 웹 표준 준수 지침
- 정부기관의 홈페이지 구축 시 반영해야 할 최소한의 규약을 정의한 것
- 이를 준수할 경우의 기대 효과가 제시되어 있음
- 전자정부 웹 표준 준수 지침 사항
- 문서타입을 명시
- 문서타입에 맞는 문법을 준수
- 인코딩 방식을 표기
- 논리적인 마크업 언어를 사용
- 스크립트의 비표준 문법을 확장하는 것은 배제
- 다양한 브라우저에서 접근
- 운영체제에 종속적이지 않아야함
- UI 설계 도구
- 사용자의 요구사항에 맞게 UI의 화면 구조나 화면 배치 등을 설계할 때 사용하는 도구
- 종류 : 와이어프레임, 목업, 스토리보드, 프로토타입, 유스케이스
- 화면은 어떻게 구성되는지, 어떤 방식으로 수행되는지 등을 기획단계에서 미리 보여주기 위한 용도
- 와이어프레임
- 기획 단계의 초기에 제작하는 것
- 페이지에 대한 개략적인 레이아웃이나 UI 요소 등에 대한 뼈대를 설계하는 단계
- 영역 구분, 콘텐츠, 텍스트 배치 등을 화면 단위로 설계
- 개발자나 디자이너 등이 레이아웃을 협의하거나 현재 진행 상태 등을 공유하기 위해 사용
- 툴 : 손그림, 파워포인트, 키노트, 스케치, 일러스트, 포토샵 등
- 목업
- 디자인, 사용 방법 설명, 평가 등을 위해 와이어프레임보다 좀 더 실제 화면과 유사하게 만든 정적인 형태의 모형
- 툴 : 파워 목업, 발사믹 목업 등
- 스토리보드
- 와이어프레임에 콘텐츠에 대한 설명, 페이지 간 이동 흐름 등을 추가한 문서
- 최종적으로 참고하는 작업 지침서
- 정책, 프로세스, 콘텐츠 구성, 와이어프레임, 기능 정의 등 서비스 구축을 위한 모든 정보가 들어 있음
- 제목, 작성자, UI 화면, 디스크립션을 기입
- 툴 : 파워포인트, 키노트, 스케치, Axure 등
- 프로토타입
- 와이어프레임이나 스토리보드 등에 인터렉션을 적용함으로써 실제 구현된 것처럼 테스트가 가능한 동적인 형태의 모형
- 사용성 테스트나 작업자 간 서비스 이해를 위해 작성하는 샘플
- 작성 방법에 따라 페이퍼 프로토타입과 디지털 프로토타입으로 나뉨
- 툴 : HTML/CSS, Axure, Flinto, 네이버 프로토나우, 카카오 오븐 등
- 유스케이스
- 사용자 측면에서의 요구사항으로, 사용자가 원하는 목표를 달성하기 위해 수행할 내용을 기술
- 사용자의 요구사항을 빠르게 파악함으로써 프로젝트의 초기에 시스템의 기능적인 요구를 결정하고 그 결과를 문서화 할 수 있음
- 자연어로 작성된 사용자의 요구사항을 구조적으로 표현한 것으로, 일반적으로 다이어그램 형식으로 묘사
- 유스케이스 다이어그램 -> 유스케이스 명세서
- UI 요구사항 확인
- 새로 개발할 시스템에 적용할 UI 관련 요구사항을 조사해서 작성하는 단계
- 다양한 경로를 통해 사용자의 요구사항을 조사하고 분석한 후 작성해야 함
- UI 요구사항 확인 순서
- 목표 정의
- 활동 사항 정의
- UI 요구사항 작성
- 목표 정의
- 사용자들을 대상으로 인터뷰를 진행한 후 사용자들의 의견이 수렴된 비즈니스 요구사항을 정의
- 인터뷰를 통해 사업적, 기술적인 요구사항을 명확히 이해
- 인터뷰 진행 시 유의사항
- 개별적으로 진행
- 가능한 많은 사람을 인터뷰, 개인의 중요한 의견을 놓치지 않도록 주의
- 한시간 넘지 않게 하기
- 사용자 리서치 시작 전에 하기
- 활동 사항 정의
- 조사한 요구사항을 토대로 앞으로 해야 할 활동 사항을 정의
- 사용자와 회사의 비전을 일치시키는 작업
- 예산과 일정을 결정
- 기술의 발전 가능성을 파악
- UI 디자인의 방향을 제시
- 사업 전략 및 목표, 프로세스의 책임자 선정, 회의 일정 및 계획 작성, 우선순위의 선정, 개별적인 단위 업무를 구분함
- UI 요구사항 작성
- 사용자들의 요구사항을 검토하고 분석하여 UI 개발 목적에 맞게 작성
- 실사용자 중심으로 작성
- 여러 사람의 인터뷰를 통해 다양한 의견을 수렴해서 작성
- UI의 전체적인 구조를 파악 및 검토
- 작성 순서
- 요구사항 요소 확인 -> 정황 시나리오 작성 -> 요구사항 작성
- 요구사항 요소 확인
- 요구사항 요소의 종류와 각각의 표현 방식 등을 검토
- 요구사항 요소
- 데이터 요구, 기능 요구, 제품/서비스의 품질, 제약 사항
- 정황 시나리오 작성
- 사용자의 요구사항을 도출하기 위해 작성하는 것으로, 사용자가 목표를 달성하기 위해 수행하는 방법을 순차적으로 묘사한 것
- 초기 시나리오
- 사용자 관점에서 시나리오를 작성
- 기능 위주로 작성
- 간결하고 명확하게 작성
- 외부 전문가 또는 경험이 풍부한 사람에게 검토
- 요구사항 작성
- 정황 시나리오를 토대로 작성
- 품질 요구사항
- 소프트웨어의 기능, 성능, 만족도 등 소프트웨어에 대한 요구사항이 얼마나 충족하는가를 나타내는 소프트웨어 특성의 총체
- ISO/IEC 9126
- 소프트웨어의 품질 특성과 평가를 위한 표준 지침으로서 국제 표준으로 널리 사용
- 2011년에 호환성과 보안성을 강화하여 ISO/IEC 25010으로 개정됨
- 기능성
- 소프트웨어가 사용자의 요구사항을 정확하게 만족하는 기능을 제공하는지 여부를 나타냄
- 적절성/정합성
- 정밀성/정확성
- 상호 운용성
- 다른 시스템들과 서로 어울려 작업할 수 있는 능력
- 보안성
- 호환성
- 기능과 관련된 표준, 관례 및 규정을 준수 할 수 있는 능력
- 신뢰성
- 소프트웨어가 요구된 기능을 정확하고 일관되게 오류 없이 수행할 수 있는 정도
- 성숙성
- 결함으로 인한 고장을 피해갈 수 있는 능력
- 고장 허용성
- 결함 또는 인터페이스 결여 시에도 규정된 성능 수준을 유지할 수 있는 능력
- 회복성
- 영향 받은 데이터를 복구할 수 있는 능력
- 사용성
- 사용자와 컴퓨터 사이에 발생하는 어떠한 행위에 대하여 사용자가 정확하게 이해하고 사용하며, 향후 다시 사용하고 싶은 정도
- 이해성
- 학습성
- 운용성
- 친밀성
- 사용자가 소프트웨어를 다시 사용하고 싶어 하도록 하는 능력
- 효율성
- 사용자가 요구하는 기능을 할당된 시간 동안 한정된 자원으로 얼마나 빨리 처리할 수 있는지 정도를 나타냄
- 시간 효율성
- 자원 효율성
- 특정 기능을 수행할 때 적절한 자원의 양과 종류를 제공할 수 있는 능력
- 유지 보수성
- 환경의 변화 또는 새로운 요구사항이 발생했을 때 소프트웨어를 개선하거나 확장할 수 있는 정도를 나타냄
- 분석성
- 결함이나 고장의 원인, 수정될 부분들의 식별을 가능하게 하는 능력
- 변경성
- 안정성
- 시험성
- 소프트웨어의 변경이 검증될 수 있는 능력
- 이식성
- 소프트웨어가 다른 환경에서도 얼마나 쉽게 적용할 수 있는지 정도를 나타냄
- 적용성
- 원래의 목적으로 제공되는 것 외에 다른 환경으로 변경될 수 있는 능력
- 설치성
- 임의의 환경에 소프트웨어를 설치 할 수 있는 능력
- 대체성
- 공존성
- UI 프로토타입의 개요
- 사용자 요구사항을 기반으로 실제 동작하는 것처럼 동적인 형태의 모형으로, 테스트가 가능함
- 사용자의 요구사항을 개발자가 맞게 해석했는지 검증하기 위한 것으로, 최대한 간단하게 만들어야 함
- 일부 핵심적인 기능만을 제공하지만 최종 제품의 작동 방식을 이해시키는데 필요한 기능은 반드시 포함
- 실제 사용자를 대상으로 테스트하는 것이 좋음
- UI 프로토타입의 장, 단점
- 장점
- 사용자를 설득하고 이해시키기 쉬움
- 개발 시간을 줄일 수 있음
- 사전에 오류를 발견할 수 있음
- 단점
- 작업 시간을 증가 시킬 수 있고, 필요 이상으로 자원을 소모할 수 있음
- 부분적으로 프로토타이핑을 진행하다보면 중요한 작업이 생략될 수 있음
- 장점
- 프로토타이핑의 종류
- 페이퍼 프로토타입
- 아날로그적인 방법, 스케치, 그림, 글 등을 이용하여 손으로 직접 작성하는 방법
- 제작 기간이 짧은 경우, 제작 비용이 적을 경우, 업무 협의가 빠를 경우 사용
- 디지털 프로토타입
- 파포, 아크로뱃, 비지오, 옴니그래플 등과 같은 프로그램을 사용하여 작성하는 방법
- 재사용이 필요한 경우, 산출물과 비슷한 효과가 필요한 경우, 숙련된 전문가가 있을 경우 사용
- 페이퍼 프로토타입
- UI 프로토타입 계획 및 작성 시 고려 사항
- 계획 시 고려 사항
- 프로토타이핑 일정은 일반적으로 아키텍처가 확정된 이후 프로젝트의 실제 분석 작업이 완료되기 이전에 진행
- 작성시 고려사항
- 얻고자하는 목표 확인
- 검증할 범위가 너무 넓거나 기간이 길면 목표가 커져서 문제가 될 수 있으니 주의
- 계획 시 고려 사항
- UI 프로토타입 제작 단계
- 1단계: 사용자의 요구사항을 분석
- 2단계: 요구사항을 충족하는 프로토타입을 종이에 손으로 직접 그리거나 편집 도구 등을 이용하여 작성, 핵심적인 기능을 중심으로 개발
- 3단계: 작성된 프로토타입이 요구사항을 잘 수행하고 있는지 사용자가 직접 확인하는 단계
- 4단계: 작성된 프로토타입을 기반으로 수정과 합의가 이뤄지는 단계
- 3, 4단계 반복
- UI 설계서의 개요
- 사용자의 요구사항을 바탕으로 UI 설계서를 구체화하여 작성하는 문서로, 상세 설계 전에 대표적인 화면들을 설계함.
- UI 설계서 표지, UI 설계서 개정 이력, UI 요구사항 정의서, 시스템 구조, 사이트 맵, 프로세스 정의서, 화면 설계 순으로 작성
- UI 설계서 개정 이력 작성
- UI 설계서가 수정될 때마다 어떤 부분이 어떻게 수정되었는지를 정리해 놓은 문서
- 처음 작성 시 첫 번째 항목을 '초안 작성', 버전을 1.0으로 설정
- UI 설계서에 변경 사항이 있을 때마다 변경 내용을 적고 버전을 0.1씩 높임
- UI 요구사항 정의서 작성
- 사용자의 요구사항을 확인하고 정리한 문서로, 사용자 요구사항의 UI 적용 여부를 요구사항별로 표시함
- 시스템 구조 작성
- UI 요구사항과 UI 프로토타입에 기초하여 전체 시스템의 구조를 설계한 것
- 사용자의 요구사항이 어떻게 시스템에 적용되는지 알 수 있음
- 사이트 맵 작성
- 시스템 구조를 바탕으로 사이트에 표시할 콘텐츠를 한 눈에 알아 볼 수 있도록 메뉴별로 구분하여 설계한 것
- 사이트 맵을 작성한 후 사이트 맵의 상세 내용을 표 형태로 작성
- 프로세스 정의서 작성
- 사용자 관점에서 사용자가 요구하는 프로세스들을 작업 진행 순서에 맞춰 정리한 것
- UI의 흐름을 파악할 수 있음
- 화면 설계
- UI 프로토타입과 UI 프로세스를 참고하여 필요한 화면을 페이지별로 설계한 것
- 화면별 고유ID를 부여
- 대표적인 화면들에 대해 포함될 정보, 인터페이스 요소, 레이아웃 등이 표현된 와이어프레임을 대략적으로 스케치
- 스토리보드 형태로 작성
- UI 시나리오 문서 개요
- UI 설계서를 바탕으로 실제 설계 및 구현을 위해 모든 화면에 대한 자세한 설계를 진행하는 단계
- 반드시 시나리오를 작성해야 함
- 사용자 인터페이스의 기능 구조, 대표 화면, 화면 간 인터렉션의 흐름, 다양한 상황에서의 예외 처리 등을 문서로 정리한 것
- 사용자가 최종 목표를 달성하기 위한 방법이 순차적으로 묘사되어 있음
- UI 설계자 또는 인터랙션 디자이너가 UI 시나리오 문서를 작성하면 그래픽 디자이너가 시나리오를 바탕으로 디자인을 하고 개발자가 UI를 구현
- UI 시나리오 문서 작성 원칙
- 계층 구조 또는 플로차트 표기법으로 작성
- 모든 기능에 공통적으로 적용될 UI 요소와 인터랙션을 일반 규칙으로 정의
- 인터랙션의 흐름을 정의하며, 화면 간 인터랙션의 순서, 분기, 조건, 루프 등을 명시
- 예외 상황에 대비한 다양한 케이스를 정의
- UI 시나리오 문서 작성을 위한 일반 규칙
- 주요 키의 위치와 기능
- 공통 UI 요소
- 기본 스크린 레이아웃
- 모든 모든 화면에 공통적으로 나타나는 Titles, Ok/Back, Soft Key, Option, Bunctional Buttons 등의 위치와 속성을 정의
- 기본 인터랙션 규칙
- 터치 제스처 등에 공통적으로 사용되는 조작 방법과 실행, 이전, 다음, 삭제, 이동 등의 화면 전환 효과 등을 기술
- 공통 단위 태스크 흐름
- 많은 기능들에 공통적으로 사용되는 삭제, 검색, 매너 모드 상태 등에 대한 인터랙션 흐름을 설명
- 케이스 문서
- 다양한 상황에서 공통적으로 적용되는 시스템의 동작을 정의한 문서
- UI 시나리오 문서의 요건
- 완전성
- 사용자의 태스크에 초점을 맞춰 기술
- 일관성
- 이해성
- 가독성
- 수정 용이성
- 추적 용이성
- 완전성
- UI 시나리오 문서로 인한 기대효과
- 요구사항이나 의사소통에 대한 오류가 감소
- 개발 과정에서의 재작업이 감소, 혼선이 최소화 됨
- 불필요한 기능을 최소화
- 소프트웨어 개발 비용을 절감
- 개발 속도를 향상