Write Thinking

1강 Framework 개념

1. SW 재사용 방안들

복사(Copy) & 붙이기(Paste)

- 초보적인 재사용 방식으로 비슷한 예제를 다른 Source에서 복사해서 사용함.

GregorianCalendar date = (GregorianCalender)Calendar.getInstance();

SimpleDateFormat df = new SimpleDateFormat("yyyyMMdd");

String date = df format(date);

- 예를 들어, A라는 클래스에서 Date타입을 String 타입으로 변환하는 코딩을 하고, 클래스 B에서 동일한 로직이 필요하여 복사했다고 가정한 경우

- JDK 버전이 바뀌어 동일한 기능을 제공하는 향상된 인터페이스가 나오면 위의 코드를 사용한 A, B 클래스를 모두 변경해야 한다.

메서드 호출

- 자주 사용되고, 유사한 기능들을 모아 메서드로 정의하여 재사용함.

public class DateUtility{

public static String toStringToday(String format){

GregorianCalendar date = (GregorianCalender)Calendar.getInstance();

SimpleDateFormat df = new SimpleDateFormat("yyyyMMdd");

String date = df format(date);

}

}

String sdate = DateUtility.toStringToday("yyyyMMdd");

- JDK 버전이 바뀌거나 메서드의 내용이 수정되더라도 해당 클래스를 모두 수정할 필요 없이 toStringToday() 메서드의 내용만 수정하면 된다.

- toStringToday() 메서드의 Signature를 변경하면 이 메서드를 사용하는 모든 클래스에 영향을 준다.

- 메서드 재사용 방법은 '복사 & 붙이기'보다는 진보된 방식이지만, 작업 영역간의 결합도(Coupling) 문제는 여전히 존재한다.

클래스 재사용 (상속)

- 자주 사용되고, 유사한 기능들을 모아 메서드로 정의하여 재사용함.

public class Person{

public String printBirthDate(String format){

DateUtility.toStringToday(birthDate, format);

}

}

- Person을 상속받은 모든 클래스들은 자동적으로 변경된 printBirthDate() 메서드를 사용하게 된다.

- DateUtility 클래스의 메서드가 변경되더라도 printBirthDate()메서드의 인터페이스가 변하지 않으면 나머지 클래스들은 영향을 받지 않는다.

AOP(Aspect Oriented Programming)

- 관심의 분리(Seperatrion of Concerns)

- AOP가 핵심관심모듈의 코드를 직접 건드리지 않고 필요한 기능이 동작하도록 하는 데는 위빙(Weaving)이라고 하는 특수한 작업이 필요하다. 즉, AOP에서 위빙 작업을 통해 핵심모듈 사이사이에 필요한 횡단 관심 코드가 동작하도록 엮어지게 만든다.

- AOP는 OOP를 더욱 OOP 답게 만들어 줄 수 있다.

- AOP는 OOP 뿐만 아니라 기존의 절차적 프로그래밍에도 적용될 수 있다.

2. 디자인 패턴과 프레임워크의 관련성

디자인패턴의 정의

- 프로그램 개발에서 자주 나타나는 과제를 해결하기 위한 방법 중 하나로, 소프트웨어 개발과정에서 발견된 Know-How를 축적하여 이름을 붙여 이후에 재사용하기 좋은 형태로 특정 규약을 묶어서 정리한 것

- 이 용어를 소프트웨어 개발 영역에서 구체적으로 처음 제시한 곳은, GoF(Gang of Four)라 불리는 네 명의 컴퓨터 과학 연구자들이 쓴 서적 'Design Patterns: Elements of Reusable Object-Oriented Software'(재사용 가능한 객체지향 소프트웨어의 요소 - 디자인 패턴)이다.

- 디자인 패턴을 사용하는 이유

요구사항은 수시로 변경 → 요구사항 변경에 대한 Source Code 변경을 최소화

여러 사람이 같이하는 팀 프로젝트 진행 → 범용적인 코딩 스타일을 적용

상황에 따라 인수 인계하는 경우도 발생 → 직관적인 코드를 사용

프레임워크의 정의

- 비기능적(Non-Funtional) 요구사항(성능, 보안, 확장성, 안정성 등)을 만족하는 구조와 구현된 기능을 안정적으로 실행하도록 제어해주는 잘 만들어진 구조의 라이브러리의 덩어리

- 프레임워크는 애플리케이션들의 최소한의 공통점을 찾아 하부 구조를 제공함으로써 개발자들로 하여금 시스템의 하부 구조를 구현하는데 들어가는 노력을 절감하게 해줌

- 프레임워크를 사용하는 이유

비기능적인 요소들을 초기 개발 단계마다 구현해야 하는 불합리함을 극복해준다.

기능적인(Functional) 요구사항에 집중할 수 있도록 해준다.

디자인 패턴과 마찬가지로 반복적으로 발견되는 문제를 해결하기 위한 특화된 Solution을 제공한다.

디자인패턴과 프레임워크의 관련성

- 디자인 패턴은 프레임워크의 핵심적인 특징이고, 프레임워크를 사용하는 애플리케이션에 그 패턴이 적용된다는 특징을 가지고 있다. 하지만 프레임워크는 디자인 패턴이 아니다.

- 디자인 패턴은 애플리케이션을 설계할 때 필요한 구조적인 가이드라인이 되어 줄 수는 있지만 구체적으로 구현된 기반코드를 제공하지 않는다.

- 프레임워크는 디자인 패턴과 함께 패턴이 적용 된 기반 클래스 라이브러리를 제공해서 프레임워크를 사용하는 구조적인 틀과 구현코드를 함께 제공한다.

- 개발자는 프레임워크의 기반코드를 확장하여 사용하면서 자연스럽게 그 프레임워크에서 사용된 패턴을 적용할 수 있게 된다.

3. 프레임워크의 구성요소와 종류

IoC(Inversion of Control)

- IoC란 "제어의 역전" 즉, 인스턴스 생성부터 소멸까지의 인스턴스 생명주기 관리를 개발자가 아닌 컨테이너가 대신 해준다는 뜻임. 즉, 컨테이너 역할을 해주는 프레임워크에게 제어하는 권한을 넘겨서 개발자의 코드가 신경 써야 할 것을 줄이는 전략이다.

- 프레임워크의 동작원리를 제어흐름이 일반적인 프로그램 흐름과 반대로 동작하므로 IoC라고 설명함.

- Spring 컨테이너는 IoC를 지원하며, 메타데이터(XML 설정)를 통해 beans를 관리하고 어플리케이션의 중요부분을 형성함.

- Spring 컨테이너는 관리되는 bean들을 의존성주입(Dependency Injection)을 통해 IoC를 지원함.

클래스 라이브러리(Class Library)

- 프레임워크는 특정 부분의 기술적인 구현을 라이브러리 형태로 제공한다.

- Class Library라는 구성요소는 프레임워크의 정의 중 하나인 "Semi Complete(반제품)" 이다. 라고 해석하게 만들었다.

- 라이브러리와 프레임워크의 차이점

프레임워크와 라이브러리를 구분하는 방법은 실행제어가 어디서 일어나는 가에 달려있다.

라이브러리는 개발자가 만든 클래스에서 직접 호출하여 사용하므로 실행의 흐름에 대한 제어를 개발자의 코드가 관장하고 있다.

프레임워크는 반대로 프레임워크에서 개발자가 만든 클래스를 호출하여 실행의 흐름에 대한 제어를 담당한다.

디자인 패턴

- 디자인 패턴 + 라이브러리 = 프레임워크

- 프레임워크는 디자인 패턴과 그것이 적용된 기반 라이브러리의 결합으로 이해할 수 있다.

- 프레임워크의 라이브러리를 살펴볼 때도 적용된 패턴을 주목해서 살펴 본다면 그 구성을 이해하기 쉽다.

- 특히 프레임워크를 확장하거나 커스터마이징 할 때는 프레임워크에 적용된 패턴에 대한 이해가 꼭 필요하다.

프레임워크 종류

- 아키텍쳐 결정 = 사용하는 프레임워크의 종류 + 사용전략

2강 환경설정

1. JDK(Java Development Kit) 8 설치 및 API 문서

Java SE Development Kit 8 downloads

- URL http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

Java SE Development Kit 8 API

- URL https://docs.oracle.com/javase/8/docs/api/

2. STS(Spring Tool Suite) 3.7.3 설치 및 Spring API 문서

STS downloads

- URL https://spring.io/tools/sts

SpringSource Site

- URL http://spring.io/

SpringFramwork 3.2.17 release API 문서

- URL https://docs.spring.io/spring/docs/3.2.17.RELEASE/javadoc-api/

3. Tomcat 8 설치

Tomcat8.0 downloads

- URL https://tomcat.apache.org/download-80.cgi

4. Oracle 11g XE(eXpress Edition) 설치

- URL http://www.oracle.com/technetwork/database/database-technologies/express-edition/downloads/index.html

3강 Spring Framework 개요

1. Spring Framework 개요

Spring Framework란?

- Java 엔터프라이즈 개발을 편하게 해주는 오픈소스 경량급 애플리케이션 프레임워크이다.

- 애플리케이션 프레임워크

특정 계층이나 기술, 업무 분야에 국한되지 않고 애플리케이션의 전 영역을 포괄하는 범용적인 프레임워크를 말한다.

- 경략급 프레임워크

단순한 웹컨테이너에서도 엔터프라이즈 개발의 고급기술을 대부분 사용할 수 있다.

- 엔터프라이즈 개발 용이

개발자가 복잡하고 실수하기 쉬운 Low Level에 많이 신경쓰지 않으면서 Business Logic 개발에 전념할 수 있도록 해준다. 여기서 Low Level이란 보안, 인증 Transaction처리이다. 이 Low Level를 프레임워크가 해결해준다.

- 오픈소스

Spring은 OpenSource의 장점을 충분히 취하면서 동시에 OpenSource 제품의 단점과 한계를 잘 극복한다.

Spring Framework 전략

- Spring 삼각형

엔터프라이즈 개발의 복잡함을 상대하는 Spring 의 전략

→ Portable Service Abstraction, Dependency Injection, AOP, POJO + BLUEPRINTS

Portable Service Abstraction(서비스 추상화)

- 트랜잭션 추상화, OXM 추상화, 데이터 액세스의 Exception 변환기능 등 기술적인 복잡함은 추상화를 통해 Low Level의 기술구현 부분과 기술을 사용하는 인터페이스로 분리한다. 

(OXM : Object XML Mapping)

객체지향과 DI (Dependency Injection, DI는 의존관계주입의 약자)

- Spring은 객체지향에 충실한 설계가 가능하도록 단순한 객체 형태로 개발할 수 있고, DI는 유연하게 확장 가능한 객체를 만들어 두고 그 관계는 외부에서 다이나믹하게 설정해준다.

AOP(Aspect Oriented Programming 관점지향프로그래밍)

- AOP는 애플리케이션 로직을 담당하는 코드에 남아 있는 기술관련 코드를 분리해서 별도의 모듈로 관리하게 해주는 강력한 기술이다.

POJO(Plain Old Java Object 일반적인 JAVA Object 프로그램)

- POJO는 객체지향 원리에 충실하면서, 특정 환경이나 규약에 종속되지 않고 필요에 따라 재활용될 수 있는 방식으로 설계된 객체이다. JVM만 있으면 돌아가는 프로그램

2. Spring Framework 특징

- 컨테이너 역할

Spring 컨테이너는 Java 객체의 LifeCycle을 관리하며, Spring 컨테이너로 부터 필요한 객체를 가져와 사용할 수 있다.

- DI(Dependency Injection) 지원

Spring은 설정 파일이나(XML)이나 어노테이션(@comment)을 통해서 객체 간의 의존관계를 설정할 수 있도록 하고 있다.

- AOP(Aspect Oriented Programming) 지원 [관점지향프로그래밍]

Spring은 트랜잭션이나 로깅, 보안과 같이 공통적으로 필요로 하는 모듈들을 실제 핵심 모듈에서 분리해서 적용할 수 있다.

- POJO(Plain Old Java Object) 지원

Spring 컨테이너에 저장되는 Java객체는 특정한 인터페이스를 구현하거나, 특정 클래스를 상속받지 않아도 된다.

- 트랜잭션 처리를 위한 일관된 방법을 지원

JDBC, JTA 등 어떤 트랜잭션을 사용하던 설정을 통해 정보를 관리하므로 트랜잭션 구현에 상관없이 동일한 코드 사용가능

- 영속성(Persistence)과 관련된 다양한 API 지원

Spring은 MyBatis, Hibernate 등 데이터베이스 처리를 위한 ORM(Object Relational Mapping) 프레임워크들과의 연동 지원

3. Spring Framework 기능요소

- Spring 프레임워크를 구성하는 기능 요소

Spring Core (Core 컨테이너)

- Spring 프레임워크의 기본기능을 제공한다.

- 이 모듈에 있는 BeanFactory는 Spring의 기본 컨테이너이면서 스프링 DI의 기반이다.

Spring AOP (AOP)

- AOP 모듈을 통해 Aspect 지향 프로그래밍을 지원한다.

- AOP 모듈은 스프링 애플리케이션에서 Aspect를 개발할 수 있는 기반을 지원한다.

Spring ORM (ORM)

- MyBatis, Hibernate, JPA 등 널리 사용되는 ORM 프레임워크와의 연결고리를 제공한다.

- ORM 제품들을 Spring의 기능과 조합해서 사용할 수 있도록 해준다.

Spring DAO (DAO)

- JDBC에 대한 추상화 계층으로 JDBC 코딩이나 예외처리 하는 부분을 간편화 시켰으며, AOP 모듈을 이용해 트랜잭션 관리 서비스도 제공한다.

Spring Web (Web)

- 일반적인 웹애플리케이션 개발에 필요한 기본기능을 제공한다.

- Webwork나 Struts와 같은 다른 웹애플리케이션 프레임워크와의 통합을 지원한다.

Spring Context (Context)

- Context 모듈은 BeanFactory의 개념을 확장한 것으로 국제화(|18N) 메시지, 애플리케이션 생명주기 이벤트, 유효성 검증 등을 지원한다.

Spring Web MVC (WebMVC(Model/View/Controller)

- 사용자 인터페이스가 애플리케이션 로직과 분리되는 웹 어플리케이션을 만드는 경우에 일반적으로 사용되는 패러다임이다.

4강 Spring Project 시작하기

1. STS 소개 및 제공하는 기능

STS(SpringSource Tool Suite) 소개

- Spring 개발업체인 SpringSource가 직접 만들어 제공하는 이클립스의 확장판으로 최신 이클립스를 기반으로 주요한 Spring 지원 플러그인과 관련된 도구를 모아서 Spring 개발에 최적화되도록 만들어진 IDE이다.

STS가 제공하는 기능

- Bean 클래스 이름 자동완성 : 현재 프로젝트의 모든 Source와 라이브러리, JDK안의 모든 클래스 중에서 첫 글자가 SDD로 시작하는 클래스를 자동으로 보여줌

- 설정파일 생성 위저드 : Bean 설정파일 생성 위저드 중 사용할 Namespace와 Schema 버전을 선택하는 화면 (설정파일은 XML에서 하는 작업이다.)

- Bean 의존관계 그래프 : Spring IDE는 XML 설정파일을 읽어서 자동으로 그래프 그려줌, 각 Bean이 어떻게 참조되고, 어떤 Property를 갖는지 알 수 있음

- AOP 적용 대상 표시 : Spring IDE의 XML 설정파일 편집기를 이용하면 AOP의 적용 대상을 손쉽게 확인할 수 있다.

2. Maven과 Library 관리

Maven이란?

- URL http://maven.apache.org 

- 라이브러리 관리 + 빌드 툴

Maven을 사용하는 이유

- 편리한 Dependent Library 관리 - Dependency Management

- 여러 프로젝트에서 프로젝트 정보나 jar 파일들을 공유하기 쉬움

- 모든 프로젝트의 빌드 프로세스를 일관되게 가져갈 수 있음.

Maven이전의 Library 관리 방법

- 과거의 의존성 라이브러리 관리 

라이브러리 사이트 접속 → 라이브러리 다운로드 → 압축 해제 → 프로젝트에 라이브러리 복사 → 플래스 패스에 추가 → 라이브러리 사이트 접속 ...

- Maven에서 의존성 라이브러리 관리

Pom.xml 파일 수정 → 빌드 → Pom.xml 파일 수정 ...

pom.xml

- Maven 프로젝트를 생성하면 pom.xml 파일이 생성된다.

- pom.xml 파일은 Project Object Model 정보를 담고 있다.

pom.xml 의존관계(dependency) 추가

- Spring 프레임워크 설치

http://mvnrepository.com 접근한다.

org.springframework로 검색한다.

spring-jdbc 모듈과 spring-web 모듈을 추가한다.

- Eclipse 제공 : Maven Repositories View

Window → Show View → Other → Maven → Maven Repositories

3. Spring Project 작성하기

STS시작하기

다운받은 Spring-toll-suite-3.7.3.RELEASE의 압축을 풀어서 STS.exe를 실행한다.

Spring Project 생성 및 Spring Module 설치

Java Project → Convert to Maven Project → Add Spring Project Nature

pom.xml 파일에 dependency 추가 : https://mvnrepository.com에서 spring context module 검색

5강 IoC와 DI

1. IoC(Inversion of Control)

IoC의 개념

- IoC(제어권의 역전)이란, 객체의 생성, 생명주기의 관리까지 모든 객체에 대한 제어권이 바뀌었다는 것을 의미한다.

- 컴포넌트 의존관계 결정(component dependency resolution), 설정(configuration) 및 생명주기(lifecycle)를 해결하기 위한 디자인 패턴(Design Pattern)

IoC 컨테이너

- 스프링 프레임워크도 객체에 대한 생성 및 생명주기를 관리할 수 있는 기능을 제공하고 있음. 즉, IoC 컨테이너 기능을 제공한다.

- IoC 컨테이너는 객체의 생성을 책임지고, 의존성을 관리한다.

- POJO의 생성, 초기화, 서비스, 소멸에 대한 권한을 가진다.

- 개발자들이 직접 POJO를 생성할 수 있지만 컨테이너에게 맡긴다.

IoC의 분류

- IoC (Inversion of Control) 안에 DL과 DI가 있음

- DL (Dependency Lookup) : EJB, SPring

- DI (Dependency Injection) : Spring PicoContainer

- Setter Injetion

- Constructor Injection

- Method Injection

DL(Dependency Lookup) 과 DI(Dependency Injection)

DL(Dependency Lookup) 의존성 검색 : 저장소에 저장되어 있는 Bean에 접근하기 위해 컨테이너가 제공하는 API를 이용하여 Bean을 Lookup 하는 것

DI(Dependency Injection) 의존성 주입 : 각 클래스간의 의존관계를 빈 설정(Bean Definition) 정보를 바탕으로 컨테이너가 자동으로 연결해주는 것

DL 사용시 컨테이너 종속성이 증가하여, 주로 DI를 사용함 

Setter Injetion

Constructor Injection

Method Injection

2. DI(Dependency Injection)

DI의 개념

각 클래스간의 의존관계를 빈 설정 (Bean Definition) 정보를 바탕으로 컨테이너가 자동으로 연결해주는 것을 말함

- 개발자들은 단지 빈 설정파일에서 의존관계가 필요하다는 정보를 추가하면 된다.

- 객체 레퍼런스를 컨테이너로부터 주입 받아서, 실행 시에 동적으로 의존관계가 생성된다.

- 컨테이너가 흐름의 주체가 되어 애플리케이션 코드에 의존관계를 주입해 주는 것이다.

- DI의 장점

코드가 단순해진다.

컴포넌트 간의 결합도가 제거된다.

DI의 유형

- Setter Injetion : Setter 메서드를 이용한 의존성 삽입

의존성을 입력 받는 setter 메서드를 만들고 이를 통해 의존성을 주입한다.

- Constructor Injection : 생성자를 이용한 의존성 삽입

필요한 의존성을 포함하는 클래스의 생성자를 만들고 이를 통해 의존성을 주입힌다.

- Method Injection : 일반 메서드를 이용한 의존성 삽입

의존성을 입력 받는 일반 메서드를 만들고 이를 통해 의존성을 주입한다.

- Setter Injection

Setter Injection방법을 사용하면

Hello가 String Printer를 의존하게 된다.

그리고 소스코드에는 new String Printer라는 객체생성코드는 없이 상위 인터페이스의 멤버변수를 하나 호출을 한 후, setter 메소드를 선언을 한다. 

Hello와 String Printer가 의존관계가 있다는 것을 설정파일에 작성하면 된다.

여기서 bean이라는 것은 spring이 관리해주는 관리 객체라는 의미로, container에게 관리를 부탁하는 객체는 bean이 된다.

bean 안에 있는 프로퍼티와 Java에 맵핑되는 setter의 이름이 같게 정의를 해주면 spring이 의존관계가 있다는 것을 알 수 있다.

Setter Injection은 한 번에 한 개씩만 의존관계를 주입받을 수 있다.

한 번에 한개씩 의존관계 주입방법을 개선한것이 Constructor Injection이다.

- Constructor Injection

Constructor Injection방법을 사용하면 인자를 두개를 받는 생성자를 만든 후

설정파일에 construntor-arg라는 태그에 index, value로 작성하여 의존관계가 있다고 설정한다.

3. Spring DI 컨테이너

Spring DI 컨테이너의 개념

- Spring DI 컨테이너가 관리하는 객체를 빈(bean)이라고 하고, 이 빈(bean)들을 관리한다는 의미로 컨테이너를 빈 팩토리(BeanFactory)라고 부른다.

- 객체의 생성과 객체 사이의 런타임(run-time) 관계를 DI 관점에서 볼 때는 컨테이너를 BeanFactory라고 한다.

- Bean Factory에 여러 가지 컨테이너 기능을 추가하여 애플리케이션 컨텍스(Application Context)라고 부른다.

BeanFactory와 Application Context

- BeanFactory

Bean을 등록, 생성, 조회, 반환 관리함

보통은 BeanFactory를 바로 사용하지 않고, 이를 확장한 ApplicationContext를 사용함

getBean() 메서드가 정의되어 있음

- Application Context

Bean을 등록, 생성, 조회, 반환 관리하는 기능은 BeanFactory와 같음

Spring의 각종 부가 서비스를 추가로 제공함

Spring이 제공하는 ApplicationContext 구현 클래스가 여러 가지 종류가 있음

6강 DI 애플리케이션 작성(1)

1. POJO 클래스 작성

POJO 클래스 다이어그램

2. 설정 메타정보 XML 작성

3. DI 테스트 클래스 작성

7강 DI 애플리케이션 작성(2)

1. jUnit의 개요와 특징

jUnit의 특징

- TDD의 창시자인 Kent Beck과 디자인 패턴 책의 저자인 Erich Gamma가 작성했다.

- 단정(assert) 메서드로 테스트 케이스의 수행 결과를 판별한다. 예) assertEquals(예상 값, 실제 값)

- jUnit4부터는 테스트를 지원하는 어노테이션을 제공한다. @Test @Before @After

- 각 @Test 메서드가 호출할 때 마다 새로운 인스턴스를 생성하여 독립적인 테스트가 이루어지도록 한다.

2. jUnit을 사용한 DI 테스트 클래스

jUnit 라이브러리 설치

- http://mvnrepository.com에 접근한다.

- jUnit으로 검색한다.

- jUnit 4.12버전을 pom.xml에 추가한다.

jUnit에서 테스트를 지원하는 어노테이션(Annotation)

- @Test

@Test가 선언된 메서드는 테스트를 수행하는 메소드가 된다.

jUnit은 각각의 테스트가 서로 영향을 주지 않고 독립적으로 실행됨을 원칙으로 하므로 @Test마다 객체를 생성한다.

- @Ignore

@Ignore가 선언된 메서드는 테스트를 실행하지 않게 한다.

- @Before

@Before가 선언된 메서드는 @Test 메소드가 실행되기 전에 반드시 실행되어 진다.

@Test 메소드에서 공통으로 사용하는 코드를 @Before 메소드에 선언하여 사용하면 된다.

- @After

@After가 선언된 메서드는 @Test 메소드가 실행된 후 실행된다.

- @BeforeClass

@BeforeClass 어노테이션은 @Test 메소드 보다 먼저 한번만 수행되어야 할 경우에 사용하면 된다.

- @AfterClass

@AfterClass 어노테이션은 @Test 메소드 보다 나중에 한번만 수행되어야 할 경우에 사용하면 된다.

테스트 결과를 확인하는 단정(assert) 메서드

- org.junit.Assert

+assertEquals(expected[A], actual[B])

객체 A와 B가 일치함을 확인한다.

+assertArrayEquals(expected[A], actual[B])

배열 A와 B가 일치함을 확인한다.

+asserSame(expected[A], actual[B])

객체 A와 B가 같은 객체임을 확인한다.

assertEquals 메서드는 두 객체의 값이 같은지 확인하고, assertSame 메서드는 두 객체의 레퍼런스가 동일한가를 확인한다.(==연산자)

+assertTrue(object[A])

조건 A가 참인가를 확인한다.

+assertNotNull(object[A])

객체 A가 null이 아님을 확인한다.

- 이외에도 다양한 assert 메서드가 존재함.

http://junit.sourceforge.net/javadoc/org/junit/Assert.html

jUnit을 사용한 DI 테스트 클래스(HelloBeanJunitTest.java) 작성

3. Sprint-Test를 사용한 DI테스트 클래스

- http://mvnrepository.com에 접근한다.

- spring-test로 검색한다.

- Spring-test 3.2.17 버전을 pom.xml에 추가한다.

Spring-Test에서 테스트를 지원하는 어노테이션

- @RunWith(SpringJUnit4CLassRunner.class)

@RunWith는 jUnit 프레임워크의 테스트 실행방법을 확장할 때 사용하는 어노테이션이다.

SpringjUnit4ClassRunner라는 클래스를 지정해주면 jUnit이 테스트를 진행하는 중에 ApplicationContext를 만들고 관리하는 작업을 진행해 준다.

@RunWith 어노테이션은 각각의 테스트 별로 객체가 생성되더라도 싱글톤(Singleton)의 ApplicationContext를 보장한다.

- @ContextConfiguration

스프링 빈(Bean) 설정 파일의 위치를 지정할 때 사용되는 어노테이션이다.

- @Autowired

스프링DI에서 사용되는 특별한 어노테이션이다.

해당 변수에 자동으로 빈(Bean)을 매핑 해준다.

스프링 빈(Bean) 설정 파일을 읽기 위해 굳이 GenericXmlApplicationContext를 사용할 필요가 없다.

Spring-Test를 사용한 DI 테스트 클래스(HelloBeanSpringTest.java) 작성

8강 DI 애플리케이션 작성(3)

1. Bean 의존관계 설정 방법

Setter Injection : <property> 태그

- Setter 메서드를 통해 의존관계가 있는 Bean을 주입하려면 <property> 태그를 사용할 수 있다.

- ref 속성은 사용하면 Bean 이름을 이용해 주입할 Bean을 찾는다.

- value 속성은 단순 값 또는 Bean이 아닌 객체를 주입할 때 사용한다.

Constructor Injection : <constructor-arg> 태그

- Constructor를 통해 의존관계가 있는 Bean을 주입하려면 <constructor-arg> 태그를 사용할 수 있다.

- Constructor 주입방식은 생성자의 파라미터를 이용하기 때문에 한번에 여러 개의 객체를 주입할 수 있다.

- 생성자 주입을 위한 설정 : ①index 지정, ②파라미터 이름 지정

POJO 클래스 수정 및 Bean 설정 파일 수정

2. 프로퍼티(Property) 값 설정 방법

- 단순 값(문자열이나 숫자)의 주입(Injection)

- Setter 메서드를 통해 Bean의 레퍼런스가 아니라 단순 값을 주입하려고 할 때는 <property> 태그의 value 속성을 사용한다.

- Spring은 List, Set, Map, Properties 와 같은 컬렉션 타입을 XML로 작성해서 프로퍼티에 주입하는 방법을 제공한다.

- List와 Set 타입 : <list>와 <value> 태그를 이용

- 프로퍼티가 Set 타입이면 <list> 대신에 <set>을 사용하면된다.

- 프로퍼티가 Map 타입이면 <map>과 <entry>태그를 이용

3. 프로퍼티(Property) 파일을 이용한 설정 방법

환경에 따라 자주 변경되는 내용의 분리

- XML의 Bean 설정 메타정보는 애플리케이션 구조가 바뀌지 않으면 자주 변경되지 않는다.

- 반면에 프로퍼티 값으로 제공되는 일부 설정정보 (예-DataSource Bean이 사용하는 DB 연결정보)는 애플리케이션이 동작하는 환경(개발, 테스트, 스테이징, 운영)에 따라서 자주 바뀔 수 있다.

- 변경되는 이유와 시점이 다르다면 분리하는 것이 객체지향 설계의 기본 원칙이다. 설정에도 동일한 원칙을 적용할 수 있다. 

- 환경에 따라 자주 변경될 수 있는 내용은 properties 파일로 분리하는 것이 가장 깔끔하다 XML 처럼 복잡한 구성이 필요 없고 키와 값의 쌍(key=value)으로 구성하면 된다.

환경에 따라 자주 변경되는 내용의 분리의 예시(1)

- value 속성에 설정된 값들은 환경에 따라 변경될 수 있는 내용이다.

- 자주 변경되는 값들은 properties 파일에 넣어 분리하는 것이 좋다.

- 프로퍼티 파일ㄹ로 분리한 정보는 ${}(프로퍼티 치환자)을 이용하여 설정한다.

- ${} 값을 치환해주는 기능은 <context:property-placeholder> 태그에 의해 자동으로 등록되는 PropertyPlaceHolderConfigurer Bean이 담당한다.

Bean 설정 파일 수정

9강 DI 애플리케이션 작성(4)

1. Bean 등록 메타정보 구성 전략

전략(1) XML 단독 사용

- 모든 Bean을 명시적으로 XML에 등록하는 방법이다.

- 생성되는 모든 Bean을 XML에서 확인할 수 있다는 장점이 있으나 Bean의 개수가 많아지면 XML 파일을 관리하기 번거로울 수 있다.

- 여러 개발자가 같은 설정파일을 공유해서 개발하다 보면 설정파일을 동시에 수정하다가 충돌이 일어나는 경우도 적지 않다.

- DI에 필요한 적절한 setter 메서드 또는 constructor가 코드 내에 반드시 존재해야 한다.

- 개발 중에는 어노테이션 설정방법을 사용했지만, 운영 중에는 관리의 편의성을 위해 XML설정으로 변경하는 전략을 쓸 수도 있다.

전략(2) XML과 빈 스캐닝(Bean Scanning)의 혼용

- Bean으로 사용될 클래스에 특별한 어노테이션(Annotation)을 부여해주면 이런 클래스를 자동으로 찾아서 Bean으로 등록한다.

- 특정 어노테이션이 붙은 클래스를 자동으로 찾아서 Bean으로 등록해주는 방식을 빈 스캐닝(Bean Scanning)을 통한 자동인식 Bean 등록기능이라고 한다.

-  어노테이션을 부여하고 자동 스캔으로 빈을 등록하면 XML문서 생성과 관리에 따른 수고를 덜어주고 개발 속도를 향상시킬 수 있다.

-  애플리케이션에 등록될 Bean이 어떤 것들이 있고, Bean들 간의 의존관계가 어떻게 되는지를 한눈에 파악할 수 없다는 단점이 있다.

2. Bean 등록 및 의존관계 설정 Annotation

Bean 등록 Annotation

- @Component

컴포넌트를 나타내는 일반적인 스테레오 타입으로 <bean>태그와 동일한 역할을 함

- @Repository

퍼시스턴스(persistence) 레이어, 영속성을 가지는 속성(파일, 데이터베이스)을 가진 클래스

- @Service

서비스 레이어, 비즈니스 로직을 가진 클래스

- @Controller

프리젠테이션 레이어, 웹 어플리케이션에서 웹 요청과 응답을 처리하는 클래스

- @Repository, @Service, @Controller는 더 특정한 유즈케이스에 대한 @Component의 구체화된 형태이다.

Bean 의존관계 주입 Annotation

- @Autowired

정밀한 의존관계 주입(Dependency Injection)이 필요한 경우에 유용하다.

@Autowired는 프로퍼티, setter 메서드, 생성자, 일반메서드에 적용 가능하다.

의존하는 객체를 주입할 때 주로 Type을 이용하게 된다.

@Autowired는 <property>,<constructor-arg> 태그와 동일한 역할을 한다.

- @Resource

어플리케이션에서 필요로 하는 자원을 자동 연결할 때 사용된다.

@Resource는 프로퍼티, setter 메서드에 적용 가능하다.

의존하는 객체를 주입할 때 주로 Name을 이용하게 된다.

- @Autowired는 타입으로, @Resource는 이름으로 연결한다는 점이 다르다.

- @Value

단순한 값을 주입할 때 사용되는 어노테이션이다.

@Value("Spring")은 <property ... value="Spring" /> 와 동일한 역할을 한다.

- @Qualifier

@Qualifier는 @Autowired 어노테이션과 같이 사용되어 진다.

@Autowired는 타입으로 찾아서 주입하므로, 동일한 타입의 Bean 객체가 여러 개 존재할 때 특정 Bean을 찾기 위해서는 @Qualifier를 같이 사용해야 한다.

Component Scan을 지원하는 태그

- <context:component-scan> 태그

@Component를 통해 자동으로 Bean을 등록하고, @Autowired로 의존관계를 주입받는 어노테이션을 클래스에서 선언하여 사용했을 경우에는 해당 클래스가 위치한 특정 패키지를 Scan하기 위한 설정을 XML에 해주어야 한다.

<context:component-scan base-package="myspring.di.annot" />

<context:include-filter> 태그와 <context:exclude-filter> 태그를 같이 사용하면 자동 스캔 대상에 포함시킬 클래스와 포함시키지 않을 클래스를 구체적으로 명시할 수 있다.

어노테이션을 사용한 POJO 클래스 작성

3. 프로퍼티(Property) 파일을 이용한 설정 방법

Properties 파일 및 Bean 설정파일 작성

10강 사용자 관리 프로젝트

1. 사용자 관리 프로젝트 아키텍처

아키텍처 개요

- 대부분의 중, 대규모 웹 애플리케이션은 효율적인 개발 및 유지보수를 위하여 계층화(Layering)하여 개발하는 것이 일반적이다.

- 사용자관리 프로젝트 아키텍쳐에서 기본적으로 가지는 계층은 프리젠테이션 계층(Presentation Layer), 서비스 계층(Service Layer), 데이터액세스 계층(Data Access Layer) 3계층과 모든 계층에서 사용되는 도메인 모델 클래스로 구성되어 있다.

- 각각의 계층은 계층마다 독립적으로 분리하여 구현하는 것이 가능해야 하며, 각 계층에서 담당해야 할 기능들이 있다.

- 위의 세 가지 계층은 독립적으로 분리할 수 있도록 구현해야 하며, 일반적으로 각 계층 사이에서는 인터페이스(Interface)를 이용하여 통신하는 것이 일반적이다.

- 프리젠테이션 계층

브라우저상의 웹크라이언트의 요청 및 응답을 처리

상위계층(서비스계층, 데이터 액세스계층)에서 발생하는 Exception에 대한 처리

최종 UI에서 표현해야 할 도메인 모델을 사용

최종 UI에서 입력한 데이터에 대한 유효성 검증(Validation) 기능을 제공

비즈니스 로직과 최종 UI를 분리하기 위한 컨트롤러 기능을 제공

@Controller 어노테이션을 사용하여 작성된 Controller 클래스가 이 계층에 속함

- 서비스 계층

애플리케이션 비즈니스 로직 처리와 비즈니스와 관련된 도메인 모델의 적합성 검증

트랜잭션(Transaction) 처리

프리젠테이션 계층과 데이터 액세스 계층 사이를 연결하는 역할로서 두 계층이 직접적으로 통신하지 않게 하여 애플리케이션의 유연성을 증가

다른 계층들과 통신하기 위한 인터페이스를 제공

Service 인터페이스와 @Service 어노테이션을 사용하여 작성된 Service구현 클래스가 이 계층에 속함

- 데이터 액세스 계층

영구 저장소(관계형 데이터베이스)의 데이터를 조작하는 데이터 액세스 로직을 객체화

영구 저장소의 데이터를 조회, 등록, 수정, 삭제 함

ORM(Object Relational Mapping) 프레임워크(MyBatis, Hibernate) 를 주로 사용하는 계층

DAO 인터페이스와 @Repository 어노테이션을 사용하여 작성된 DAO 구현 클래스가 이 계층에 속함

- 도메인 모델 클래스

관계형 데이터 베이스의 엔티티와 비슷한 개념을 가지는 것으로 실제 VO(Value Object) 혹은 DTO(Data Transfer Object) 객체에 해당

도메인 모델 클래스는 3개의 계층 전체에 걸쳐 사용

private으로 선언된 멤버변수가 있고, 그 변수에 대한 getter와 setter 메서드를 가진 클래스를 말함

2. 사용자 관리 프로젝트 클래스 설계

클래스의 역할

- 프리젠테이션 계층

UserController 클래스

UI계층과 서비스 게층을 연결하는 역할을 하는 클래스

JSP에서 UserController를 통해서 서비스 계층의 UserService를 사용하게 된다.

서비스 계층의 UserService 인터페이스를 구현하나 객체를 IoC 컨테이너가 주입해준다.

- 서비스 계층

UserService 인터페이스

서비스 계층에 속한 상위 인터페이스

UserServiceImpl 클래스

UserService 인터페이스를 구현한 클래스

복잡한 업무 로직이 있을 경우에는 이 클래스에서 업무 로직을 구현하면 된다.

데이터 액세스 계층의 UserDao 인터페이스를 구현한 객체를 IoC 컨테이너가 주입해준다.

- 데이터 액세스 계층

UserDao 인터페이스

데이터 액세스 계층에 속한 상위 인터페이스

UserDaoImplJDBC클래스

UserDao 인터페이스를 구현한 클래스로 이 클래스에서는 데이터 액세스 로직을 구현하면 된다.

SpringJDBC를 사용하는 경우에는 DataSource를 IoC 컨테이너가 주입해준다.

MyBatis를 사용하는 경우에는 SqlSession을 IoC 컨테이너가 주입해준다.

3. 사용자 관리 프로젝트 클래스 Code

11강 Spring JDBC 개요

1. 데이터 액세스 공통 개념

DAO(Data Access Object) 패턴

- 데이터 액세스 계층은 DAO 패턴을 적용하여 비즈니스 로직과 데이터 액세스 로직을 분리하는 것이 원칙이다.

- 비즈니스 로직이 없거나 단순하면 DAO와 서비스 계층을 통합 할 수도 있지만 의미 있는 비즈니스 로직을 가진 엔터프라이즈 애플리케이션이라면 데이터 액세스 계층을 DAO 패턴으로 분리해야 한다.

- DAO 패턴은 서비스계층에 영향을 주지 않고 데이터 액세스 기술을 변경할 수 있는 장점을 가지고 있다.

컨넥션 풀링을 지원하는 DataSource

- 컨넥션 풀링은 미리 정해진 개수만큼의 DB 컨넥션을 풀(Pool)에 준비해두고, 애플리케이션이 요청할 때마다 Pool에서 꺼내서 하나씩 할당해주고 다시 돌려받아서 Pool에 넣는 식의 기법이다.

- 다중 사용자를 갖는 엔터프라이즈 시스템에서라면 반드시 DB컨넥션 풀링 기능을 지원하는 DataSource를 사용해야 한다.

- Spring에서는 DataSource를 공유 가능한 Spring Bean으로 등록해 주어 사용할 수 있도록 해준다.

DataSource 구현 클래스 종류

- 테스트 환경을 위한 DataSource

SimpleDriverDataSource

- Spring이 제공하는 가장 단순한 DataSource 구현 클래스이다.

- getConnection()을 호출할 때마다 매번 DB 컨넥션을 새로 만들고 따로 풀(pool)을 관리하지 않으므로 단순한 테스트용으로만 사용해야 한다.

SingleConnectionDriverDataSource

- 순차적으로 진행되는 통합 테스트에서는 사용 가능하다.

- 매번 DB 커넥션을 생성하지 않기 때문에 SimpleDriverDataSource 보다 빠르게 동작한다.

DataSOurce 종류

- 오픈소스 DataSource

Apache Commons DBCP

- 가장 유명한 오픈소스 DB커넥션 풀(pool) 라이브러리이다.

- Apache의 Commons 프로젝트(http://commons.apache.org/dbcp/

c3p0 JDBC/DataSource Resource Pool

- c3p0는 JDBC 3.0스펙을 준수하는 Connection과 Statement 풀(pool)을 제공하는 라이브러리이다.

- c3p0 웹 사이트 (http://www.mchange.com/projects/c3p0/)

두 가지 모두 수정자(setter) 메서드를 제공하므로 Spring Bean으로 등록해서 사용하기 편리하다.

2. Spring JDBC 설치 및 DataSource 설정

- JDBC란?

JDBC는 모든 자바의 데이터 액세스 기술의 근간이 된다.

엔티티 클래스와 애노테이션을 이용하는 최신 ORM 기술도 내부적으로는 DB와의 연동을 위해 JDBC를 이용한다.

안정적이고 유연한 기술이지만, 로우 레벨 기술로 인식되고 있다.

간단한 SQL을 실행하는 데도 중복된 코드가 반복적으로 사용되며, DB에 따라 일관성 없는 정보를 가진 채로 Checked Exception으로 처리한다.

장점 : 대부분의 개발자가 잘 알고 있는 친숙한 데이터 액세스 기술로 별도의 학습 없이 개발이 가능하다

단점 : Connection과 같은 공유 리소스를 제대로 릴리즈 해주지 않으면 시스템의 자원이 바닥나는 버그를 발생시킨다.

- Spring JDBC란?

JDBC의 장점과 단순성을 그대로 유지하면서도 기존 JDBC의 단점을 극복할 수 있게 해주고, 간결한 형태의 API 사용법을 제공하며, JDBC API에서 지원되지 않는 편리한 기능을 제공한다.

Spring JDBC는 반복적으로 해야 하는 많은 작업들을 대신 해준다.

Spring JDBC를 사용할 때는 실행할 SQL과 바인딩 할 파라미터를 넘겨 주거나, 쿼리의 실행 결과를 어떤 객체에 넘겨 받을지를 지정하는 것만 하면 된다.

Spring JDBC를 사용하려면 먼저, DB 컨넥션을 가져오는 DataSource를 Bean으로 등록해야 한다.

- Spring JDBC가 해주는 작업

Connection 열기와 닫기

- Connection과 관련된 모든 작업을 Spring JDBC가 필요한 시점에서 알아서 진행한다.

- 진행 중에 예외가 발생했을 때도 열린 모든 Connection 객체를 닫아준다.

Statement 준비와 닫기

- SQL 정보가 담긴 Statement 또는 PreparedStatement를 생성하고 필요한 준비 작업을 해주는 것도 Spring JDBC가 한다.

- Statement도 Connection과 마찬가지로 사용이 끝나고 나면 Spring JDBC가 알아서 객체를 닫아준다.

Statement 실행

- SQL 담긴 Statement를 실행하는 것도 Spring JDBC가 해준다.

- Statement의 실행결과는 다양한 형태로 가져올 수 있다.

ResultSet Loop 처리

- ResultSet에 담긴 쿼리 실행 결과가 한 건 이상이면 ResultSet 루프를 만들어서 반복해주는 것도 Spring JDBC가 해주는 작업이다.

Exception 처리와 반환

- JDBC 작업 중 발생하는 모든 예외는 Spring JDBC 예외 변환기가 처리한다.

- 체크 예외(Checked Exception)인 SQLException을 런타임 예외(Runtime Exception)인 DataAccessException 타입으로 변환한다.

Transaction 처리

- Spring JDBC를 사용하면 transaction과 관련된 모든 작업에 대해서는 신경 쓰지 않아도 된다.

3. Spring JDBC의 JdbcTemplate 클래스

- JdbcTemplate 클래스

Spring JDBC가 제공하는 클래스 중 JdbcTemplate은 JDBC의 모든 기능을 최대한 활용할 수 있는 유연성을 제공하는 클래스이다.

JdbcTemplate이 제공하는 기능은 실행, 조회, 배치의 세 가지 작업이다.

- 실행 : Insert나 Update같이 DB의 데이터에 변경이 일어나는 쿼리를 수행하는 작업

- 조회 : Select를 이용해 데이터를 조회하는 작업

- 배치 : 여러 개의 쿼리를 한 번에 수행해야 하는 작업

- JdbcTemplate 클래스 생성

JdbcTemplate은 DataSource를 파라미터로 받아서 아래와 같이 생성할 수 있다.

JdbcTemplate template =new JdbcTemplate(dataSource);

DataSource는 보통 Bean으로 등록해서 사용하므로 JdbcTemplate이 필요한 DAO 클래스에서 DataSource Bean을 DI(의존관계 주입) 받아서 JdbcTemplate을 생성할 때 인자로 넘겨주면 된다.

JdbcTemplate은 멀티스레드 환경에서도 안전하게 공유해서 쓸 수 있기 때문에 DAO 클래스의 인스턴스 변수에 저장해 두고 사용할 수 있다.

- JdbcTemplate 클래스 생성 Code

아래의 코드는 일반적으로 사용되는 DAO 클래스의 기본구조이다.

DataSource에 대한 수정자 메서드에서 직접 JdbcTemplate객체를 생성해준다.

- JdbcTemplate 클래스의 update() 메서드

INSERT, UPDATE, DELETE와 같은 SQL을 실행할 때는 JdbcTemplate의 update() 메서드를 사용한다.

int update(String sql, [SQL 파라미터])

update() 메서드를 호출할 때는 SQL과 함께 바인딩 할 파라미터는 Object 타입 가변인자 (Object ... args)를 사용할 수 있다.

update() 메소드의 리턴되는 값은 SQL 실행으로 영향을 받은 레코드의 개수를 리턴한다.

- JdbcTemplate 클래스의 update() 메서드 Code

- JdbcTemplate 클래스의 queryForObject() 메서드

SELECT SQL을 실행하여 하나의 Row를 가져올 때는 JdbcTemplate의 queryForObject() 메서드를 사용ㅎ나다.

<T> T queryForObject(String sql, pSQL 파라미터], RowMapper<T> rm)

SQL 실행 결과는 여러 개의 칼럼(Column)을 가진 하나의 로우(Row)

T는 VO 객체의 타입에 해당된다.

SQL 실행 결과로 돌아온 여러 개의 column을 가진 한 개의 Row를 RowMapper 콜백을 이용해 VO객체로 매핑 해준다.

- JdbcTemplate 클래스의 queryForObject() 메서드 Code

- JdbcTemplate 클래스의 query() 메서드

SELECT SQL을 실행하여 여러 개의 Row를 가져올 떄는 JdbcTemplate의 query() 메서드를 사용한다.

<T> List<T> query(String sql, [SQL 파라미터], RowMapper<T> rm)

SQL 실행 결과로 돌아온 여러 개의 column을 가진 여러 개의 Row를 RowMapper 콜백을 이용해 VO 객체로 매핑 해준다.

결과 값은 매핑 한 VO 객체를 포함하고 있는 List 형태로 받는다. List의 각 요소가 하나의 Row에 해당된다.

12강 Spring JDBC 

1. DB 설정 및 JDBC Driver 설치

DBA 권한으로 접속

- SQL Command 실행

- DBA권한으로 접속

conn sys as sysdba;   입력

password는 설치할 때 지정한 oracle11

- scott 계정 생성

create user scott identified by tiger default tablespace users temporary tablespace temp;

- scott 계정에 권한 주기

grant connect, resource to scott;

DB users 테이블 생성

- scott 계정으로 접속 후 users 테이블 생성

conn scott/tiger

start c:\springframework\user.sql;

Oracle Jdbc Driver 라이브러리 검색 및 설치

- http://mvnrepository.com에 접근한다.

- oracle ojdbc6로 검색한다.

- oracle jdbc 12.1.0.1 버전을 pom.xml에 추가한다.

2. Spring JDBC 설치 및 DataSource 설정

Spring JDBC 설치

- http://mvnrepository.com에 접근한다.

- spring jdbc로 검색한다.

- oracle jdbc 3.2.17 버전을 pom.xml에 추가한다.

DataSource를 Spring Bean으로 등록하여 사용할 수 있다.

3. 사용자관리 프로젝트 실행

사용자관리 프로젝트의 Bean 등록 및 의존관계 설정

- <context:component-scan> 태그 사용

- @Service, @Repository 어노테이션을 선언한 클래스들과 @Autowired 어노테이션을 선언하여 의존관계를 설정한 클래스들이 위치한 패키지를 Scan 하기 위한 설정을 XML에 해주어야 한다.

DataSource 설정 테스트

1강 모바일과 UX/UI/GUI의 이해(1)

1. 모바일 서비스의 이해

- 모바일 서비스의 의미와 특성

스마트폰에서 매일 사용하는 서비스의 종류는 몇 가지일까요?

스마트폰에서 매일 사용하는 서비스의 구분

- 어플리케이션 = '프로그램'을 의미하며, 줄여서 '앱'이라고도 함

- 웹 브라우저 = 인터넷 서핑 전용 앱

기술 구현 방식에 차이가 있지만, 사용자에게 어떤 접근 경로로 다가갈 것인지를 우선으로 판단하여 형태를 결정하는 것을 권장한다. 이에 따라 실제 디자인 방법은 확연하게 달라지게 된다.

모바일 앱과 모바일 웹의 장단점 비교

모바일 앱과 모바일 웹은 장단점이 있으므로 장단점을 이해할 수 있어야 한다.

모바일 앱(네이티브 앱)의 특성

- 사용자 스마트폰 스크린에 노출되며, 앱 아이콘을 누르면 바로 연결되는 장점이 있다.

- 모바일 운영체제별 별도 제작 : 타 운영체제에 사용 불가

애플iOS : 오블젝티브-C / 스위프트, Xcode, 애플 앱스토어

구글 안드로이드 OS : 자바, 안드로이드 스튜디오, 구글 플레이 및 안드로이드 마켓

- 디바이스의 다양한 센서, 기능, 프레임워크를 사용 가능

- 앱 마켓을 통한 구매 필수

모바일 웹의 특성

- 사용자가 사용하는 웹 브라우저 앱을 통해 접속하며 별도의 주소를 입력해야 실행된다.

- 다양한 해상도 대응 방식으로 제작 : 원소스 멀티 유즈 가능

- HTML, CSS, JavaScript 등의 언어로 제작

- 디바이스의 다양한 센서, 기능들 사용 불가(일부 기능은 가능)

보안상의 이유로 하드웨어 및 시스템 접근 제한됨

- 앱 마켓에 노출되지 않음

하이브리드 모바일 앱

- 앱의 장점과 웹의 장점을 합친 방식으로써, 폰갭, 센차터치 등의 별도 기술을 활용하여 웹 결과물을 앱으로 패키징한다.

- 매번 웹에서 콘텐츠 등을 불러오므로 퍼포먼스는 떨어지는 편

- 앱 마켓 등록 가능

- 주로 콘텐츠가 인터넷 중심일 경우 주로 사용하며, 최근엔 완성도가 높아져 네이티브 앱과 거의 구분이 안되는 편

모바일 앱, 모바일 웹, 하이브리드 모바일 앱 비교

- 장단점이 있으므로 구체적인 차이점을 이해하기 위해서는 추후 개발자와 협의를 권장한다.

실제 프로젝트 진행시, 네이티브 앱, 모바일 웹, 하이브리드 모바일 앱의 선택(기술 구현 방식)에 따라, 디자인 및 이미지 작업이 달라지므로, 프로젝트 시작 전에 구체적으로 파악해야 할 필요가 있다.

게임 엔진을 활용한 앱 개발

- 유니티, 언리얼 등의 게임 개발 앱은, 개발 후 다양한 플랫폼으로 변환해주는 기능을 제공해주고 있다.

- 게임 장르에 주로 한정(주로 이미지, 사운드 등을 집중적으로 다루는 데 능함)

- 텍스트 및 많은 양의 정보를 다루는 경우의 앱일 경우 권장하지 않음

- 개발 후, 다양한 플랫폼에 맞추어 export 가능

- http://unity3d.com

- http://unrealengine.com

- 게임 엔진을 활용한 앱 개발로 크로스플랫폼 네이티브 앱을 개발하는 내용도 있다.

2. 모바일 운영체제의 이해와 관련 사이트

- 한국의 모바일 운영체제 점윤율

구글 안드로이드 OS 약 75%, 애플 iOS 약 23% 점유율을 보이고 있다.(2016년 1월 기준)

- 모바일 운영체제별 특징

구글 안드로이드 OS, 애플 iOS는 각 회사의 관점에 따라 스마트폰의 UX/UI/GUI 및 기능 등을 다르게 구성하고 있으므로, 디자인 및 기획을 위해서는 공통점 및 차이점을 정확히 이해하는 것이 중요하다.

공통점 

- 손으로 쥐고 사용하는 디바이스, 터치 및 제스처에 최적화

- 콘텐츠, 콤포넌트가 터치 및 핸드 헬드 디바이스에맞게 구성

- 상/하단에 운영체제 특유의 바 및 주요 요소 배치

- 각 운영체제별 마켓 존재

- 마켓 앱 구매 → 아이콘 터치 → 실행 과정

차이점 

- 디자인 스타일

- 인터랙션

- 타이포그래피

애플 iOS 디폴트 영문 폰트 San Francisco

구글 머티리얼 디자인 디폴트 영문 폰트 Roboto

- 하드웨어

애플 아이폰 6S

구글 넥서스 5X 안드로이드 폰

- 기능, 이미지 구현 방법 등

- 구글 안드로이드 OS 공식 사이트

http://design.google.com/resources  →  Naterial Design Gudelines

디자인, 기획을 위해서는 구글 디자인 가이드 사이트를 참조해야 한다.

- 애플 iOS 공식 사이트

http://developer.apple.com/ios

애플의 개발자 사이트 내의 iOS → 라이브러리를 통해서 관련 정보를 습득할 수 있다.

2강 모바일과 UX/UI/GUI의 이해(2)

1. 모바일 구성 요소와 디자인 프로세스

- 모바일 구성 요소의 이해

모바일 디자인 및 기획시 고려해야 하는 사항

- 프로젝트의 목표 : 매출 목표 외에도 달성하고자 하는 목표 (다운로드 수, 긍정적 리뷰 수 등), KPI(Key Performance Indicator) 등

- UX/UI/GUI : 구체적인 사용자에게 어떠한 경험, 콘텐츠, 기능, 디자인을 제공할 것인지 고민하고 적용하는 영역

- 운영체제 지원 : 1개 운영체제를 지원할 것인지, 다수 지원할 것인지

- 디바이스(해상도) 대응 : 디바이스 종류에 따른 해상도 대응의 범위

- 마켓(경쟁 관계) 리서치 : 마켓의 동향 및 경쟁 관계 분석 등

디자인 프로세스의 이해

- 일반적으로 기획 → 개발 → GUI 디자인 → 마케팅 순으로 진행한다. UX, UI를 특히 고려한다면 어느 위치에 들어가는지 고민해볼 필요가 있다.

- 에자일 개발, 린 UX, 디자인 씽킹 등은 디자인 프로세스의 하나로써 개발/디자인/기획 등에 필요한 구체적인 진행 단계 및 업무를 의미한다.

- 개발자, 디자이너, 기획자, 마케터 등 다양한 영역의 사람들이 모여서 진행

개발자 : 서비스의 기능 구현을 책임진다.

디자이너 : 일반적으로 GUI 디자이너만을 칭하는 경우가 잦다. 경우에 따라 UX/UI 디자이너가 별도로 존재하기도 한다.

기획자 : 일반적으로 콘텐츠, 기능을 통합하는 역할을 맡으며, UI 시나리오 작성 및 프로젝트 기획을 진행하는 경우가 잦다.

마케터 : 수익과 관련된 부분을 책임진다. 마켓 분석, 홍보, 트렌드 분석 등을 주로 한다.

2. 모바일 UX/UI/GUI의 이해

- UX/UI/GUI 이해의 필요성

- 디지털 제품을 디자인할 때는 누가 쓰는지를 잊고 만들게 된다. 

- 만드는 사람들은 다 각자 생각하는 제품의 완성형 모델이 다르다.

- 모바일은 보이지 않는 디지털 제품/서비스를 만드는 것이므로 작업 과정을 구체화하는 필요성이 대두되었고, 그에 따라 더욱 UX/UI/GUI가 구체화 되었다.

- UX, 사용자 경험의 이해 

- 사용자 경험은 사용자가 제품을 사용하는 모든 상황에 있어 만족하는 가치를 전달하는 것이 주 목표이나, 단순하게 사용자의 니즈/가치만을 도출하는 것이 목표가 아니라, 이를 내부의 목표와 기술적 가능성과도 균형을 맞추는 것이 주된 목표라 할 수 있다.

- UX = Union( Technology, User Needs, Business Goals ) 

- 따라서 UX 디자인에서는 사용자 및 관련 분야의 리서치를 주업무로 진행한다. 인터뷰, 설문, 관찰 등의 질적/양적 리서치를 진행하며, 이를 통해 페르소나, 요구 사항 리스트 등을 도출한다. 이를 기반으로 UI/GUI 업무가 진행된다.

- 구체화 되지 않은 내용들을 구체화/가시화 하는 업무이므로 대부분은 스케치, 포스트잇 등을 통해 업무가 진행되게 된다.

- UI, 유저 인터페이스의 이해

- UI는 유저 인터페이스, 즉 사용자가 제품과 맞닿는 지점을 의미하며 다양한 UI가 존재한다. PUI, AUI, GUI등의 요소가 있으며, 이를 포괄하여 UI로 총칭한다.

- 조작 방식과 디바이스(시스템)의 피드백 반응에 대한 인터랙션 디자인을 포괄하는 것으로 설명하기도 한다. 모바일은 터치 및 제스처로 조작되며, 이에 따른 모바일 디바이스의 반응을 인터랙션이라 한다.

- 모바일의 PUI는 대부분 표준화되어 있으며, 조작 방식 또한 표준화 됨에 따라 실제 기획/디자인할 때에는 화면의 레이아웃과 네비게이션을 기획하는 UI 디자인 단계 → 시각으로 구체화 표현되는 GUI 디자인 순으로 진행한다.

- GUI, 그래픽 유저 인터페이스의 이해

- GUI는 그래픽 유저 인터페이스로써, UI 기획 문서를 기준 근거로 하여 구체적인 시각 디자인을 의미한다. 컬러 타이포그래피, 레이아웃, 아이콘 등이 주요 작업 요소이다.

3강 모바일과 GUI 디자인(1)

1. 서비스 목적과 사용자의 이해

- 모바일 서비스의 구체적인 목적과 사용자의 이해

모바일 서비스 목적의 이해

①서비스의 목적

- 브랜드 서비스, 유틸리티 앱, 콘텐츠 서비스, 게임 등의 속성을 명확히 정해야 한다.

- 서비스의 목적을 명확히 함으로써 기능, 구조 등을 명확히 할 수 있다.

- 구체적인 상황에 대한 효과적인 솔루션을 제공해줄 수 있다.

- 내부 팀원들의 커뮤니케이션에도 도움을 줄 수 있다.

②세부 사항 파악

- 카테고리적 특성 : 쇼핑, SNS, 교육, 아동, 유틸리티 등, 속한 카테고리에 따라 사람들이 일반적으로 생각할 수 있는 구조, 레이아웃, 컬러 등의 특성을 포함한다.

- 모바일 특성 반영 : 손으로 들고 다니는 폰, 커뮤니케이션 툴, 다양한 상황 속에서의 사용, 작은 화면, 카메라 촬영 가능 등 ( 예제 : 김기사 앱 vs 아이나비 빌트인 네비게이션 )

③경쟁 차별화 포인트

- 브랜드적인 측면으로써, 다른 서비스와 구별될 수 있는 구체적인 측면, 개발, 기획, 디자인 등 각 팀별로 차별화 포인트를 도출해야 한다.

④기능 & 콘텐츠 리스트 업

- 구체적으로 어떠한 기능과 콘텐츠를 제공할 것인지 리스트업 및 전략을 세우도록 한다. 경쟁 서비스도 반드시 비교하여 체크한다.

모바일 앱의 대상(사용자, 오디언스) 이해의 필요성

- 참조

- 먼저 개발에 따른 기획적 특성인 내부의 '목적'을 구체화하고 난후, 직접 서비스를 사용하는 사용자/오디언스에 '누구에게') 맞추어 디자인하는 것을 권장한다.

- 서비스를 기획한 사람이 절대적 사용자가 되는 경우가 많지 않기 때문에, 실제 그 서비스를 사용하는 사람을 대상으로 생각하는 것이 중요하다.

- 디자인 파트에서 또한 이러한 기획적 측면을 이해하고, 구체적 사용자/오디언스에 맞추어 UI/GUI 디자인을 진행하여야 한다.

사용자와 오디언스의 개념 이해

- 사용자 : 좁은 의미, 구체적 단일 특성을 가진 특수 대상 고객

- 오디언스 : 넓은 의미, 일반적이고 보편적 특성을 가진 일반 대상의 고개

- 앱 디자인시, 사용자가 선호하는 디자인적인 특성을 고려하여 기획, 디자인, 콘텐츠 등을 구성해야 한다.

- 사용자의 적용 : UX 디자인 등을 통해 구체적인 사용자가 지정될 경우 이러한 내용을 근거로 하여 구체적인 디자인 이슈를 도출할 수 있다.

- 오디언스의 적용 : UX 디자인 등의 업무를 통해 구체적인 사용자가 지정되지 않을 경우 (혹은 지시사항 등이 없을 경우), 개략적인 사용자 집단인 오디언스를 구성하여 그에 맞는 디자인을 진행하는 것을 권장한다.

2. 모바일 컬러, 타이포그래피, 레이아웃

- 컬러, 타이포그래피, 레이아웃의 중요성

컬러, 타이포그래피, 레이아웃 = 통합 디자인

모바일의 컬러, 타이포그래피, 레이아웃은 시각디자인의 요소로써 개별적으로 나누어 볼 수 있으나, 최종적으로는 모든 요소가 조화롭게 디자인 되는 것을 목표로 하고 있으므로 통합 디자인 관점의 이해를 할 필요가 있다.

컬러, 타이포그래피, 레이아웃의 세부 작업

다만 실제 디자인 작업 시에는, 각 요소들을 개별적으로 분석하고 이해하고 적용할 필요가 있으므로 유의한다. 아울러 이러한 요소들은 관계 앱들의 리서치를 통해 일반적인 의미의 사용 및 차별화 포인트를 도출할 수도 있다.

- 서비스의 목적과 오디언스에 따른 컬러, 타이포그래피, 레이아웃

사용자와 오디언스의 개념 이해

- 사용자, 오디언스에 따른 UI/GUI 디자인 적용

사용자, 오디언스에 따라 서비스의 구체적인 기능, 테스크, 콘텐츠, 인포메이션 디자인을 진행 → 본격적인 UI/GUI 디자인 작업 이전에 관련 내용으로 리서치할 필요가 있다. 이러한 리서치를 통해 객관성을 확보할 수 있으며, 디자이너 개인 취향에만 따르는 디자인을 방지할 수 있다.

- 대상, 목적, 디바이스 → UI/GUI 디자인

- 모바일 디자인시에는 반드시, 서비스의 목적과 오디언스(혹은 사용자)에 맞추어 디자인을 진행하여야 한다.

사용자, 오디언스에 따른 UI/GUI 디자인 사례

- Sago Mini Friends

- the Lonely Beast ABC (글자수 적음 단순)

- Clash of Clans (요소가 다양함)

- Galaxy on Fire

- amazon (컬러가 많이 사라지고 제품 위주)

- coupang (목적우선 앱)

대상, 목적, 디바이스의 특성에 맞는 UI/GUI 디자인

- 이처럼 대상과 목적 그리고 디바이스의 특성에 맞추어 UI/GUI 디자인을 전개하는 것을 권장한다.

4강 모바일과 GUI 디자인(2)

1. 모바일 운영체제에 따른 GUI 디자인

- 운영체제와 GUI 디자인

 운영체제와 GUI 디자인 FAQ

Q - 모바일 서비스를 개발하기로 하였다면, 그 다음 단계는 무엇인가?

A - 일반적으로 구체적인 UI 기획안을 작업하게 되며, 그리고 안드로이드와 아이폰 중 일부만 개발할 것인지, 아니면 둘 다 개발할 것인지를 결정하게 된다.

Q - 아이폰과 안드로이드폰, 어느 쪽을 먼저 개발하는지에 대해 어떻게 결정하는가?

A - 한국에서는 안드로이드폰 점유율이 높은 관계로, 일반적으로는 안드로이드를 먼저 개발한다.

Q - 디자인 및 디자인 스타일은 어떻게 결정하는가?

A - 어느 쪽의 운영체제를 우선 개발하느냐로 보통 결정되며, 해당 운영체제의 디자인 스타일을 따라가게 되는 편이다.

Q - 안드로이드에 맞추어 디자인을 다하고 나서, 아이폰을 지원하는데 어려움을 겪지는 않는가?

A - 안드로이드일 경우, 머티리얼 디자인 스타일을 따라가게 되는데 실제 아이폰의 디자인 스타일과 차이가 많이 나며, 머티리얼 디자인을 아이폰에 그대로 적용할 경우네는 많은 부분에서 문제가 될 수 있다.

Q - GUI 디자인에 대한 부분은 어떻게 진행되는가?

A - GUI 디자이너를 제외한 다른 파트에 있는 사람들은 비 디자이너이므로, GUI 디자인에 대한 부분은 전적으로 GUI 디자이너가 진행해야 한다. 즉, 컬러, 타이포그래피, 레이아웃, 아이콘 등의 부분은 GUI 디자이너가 작업해야 하며, 모바일 운영체제에 대한 사전 지식과 경험이 필요하며 경우에 따라서는 추가적인 리서치를 진행해야 하는 경우도 잦다.

운영체제와 GUI 디자인 스타일 결정

- 각 운영체제별로 디자인 스타일의 특징과 차이점을 명확히 이해해야 한다.

진행시 2가지 방식으로 디자인 스타일을 결정할 수 있다.

- 운영체제 최적화 디자인 방식 : 각 운영체제별 디자인 스타일에 맞추는 방식

- 운영체제 중립화 디자인 방식 : 공통 요소는 같이 쓰고, 최소한의 요소만 대응하는 방식

- 운영체제 최적화/중립화 GUI디자인

운영체제 최적화 디자인 방식

운영체제 중립화 디자인 방식

- 운영체제 디자인 스타일 결정

최적화 선택시

장점 : 사용자가 자신의 스마트폰에 최적화된 경험을 할 수 있다.

단점 : 비용(시간, 인력 등)이 많이 든다

중립화 선택시

장점 : 디자인 작업이 최적화보다 덜 들어간다

단점 : 대응 운영체제에 대한 지식/경험이 필요하다.

운영체제별 디자인 스타일을 대응하기 위해서는

- 운영체제별 스마트폰을 다 사용해본다

- 경쟁 서비스의 운영체제별 대응을 확인한다.

- 아이폰, 안드로이드폰 서비스를 비교하여 사용해본다

- 운영체제별 디자인 사이트의 디자인 관련 내용을 숙지한다

- 인터넷 정보만으로는 세부적인 내용을 확인할 수 없으므로, 스마트폰을 구해서 앱을 다운 받아서 확인해보는 방법을 권장한다.

5강 모바일 UI/GUI 디자인 컴포넌트 (1)

1.구조 구성 컴포넌트

- 모바일 컴포넌트의 이해

아래와 같은 모바일 디바이스의 특성에 따라 컴포넌트들은 표준화 되었으며, 이러한 차이가 웹 디자인과 비교하였을 때 가장 큰 차이점이라 할 수 있다.

작은 디스플레이, 손으로 들고 사용하는 방식, 손가락으로 조작

모바일은 웹 디자인과 달리 다양한 컴포넌트들이 표준화 되어 있다. 크게 범위를 나눈다면, 아래의 4가지 범주로 나누어 볼 수 있다.

구조 구성 컴포넌트, 콘트롤 컴포넌트, 콘텐츠 디자인, 아이콘 디자인

- 아이폰 : 

스테이터스 바

- 아이폰의 스테이터스 바는 투명하게 적용되며, 네비게이션 바와 합쳐서 보여진다. 디폴트는 검정 글자이며 횐색으로 적용할 수도 있다. 

네비게이션 바

- 아이폰의 네비게이션 바 또한 투명하게 적용되며, 스테이터스 바와 합쳐서 보여진다. 네비게이션 바를 통해 중앙에 현재 위치, 좌측에 이전 위치, 우측에 추가 기능(툴바)을 배치한다.

- 텍스트만으로 표현이 되므로, 글자 간의 충분한 간경이 나오는지 항상 확인한다.

- 네비게이션 바의 디자인 스타일은 모든 페이지에서 동일하게 표현되도록 한다.

- 앱 구조상의 최상단에 위치할 경우, 혹은 적은 페이지의 경우는 현재 위치를 별도로 표현하지 않기도 한다.

- 필요에 따라서는, 프롬프트 창을 띄워서 기존의 페이지를 덮고 특정 행동을 취하게 할 수 있다. 그럴 경우 프롬프트 입력 창이 네비게이션 바에 나타난다.

- 사용자가 콘텐츠에 집중하고자 할 때에는 네비게이션 바를 사라지게 할 수도 있다. 지도 앱의 경우 전체 화면을 제공하기 위해, 화면을 탭하면 네비게이션 바와 툴바가 사라진다.

툴 바

- 네비게이션 바 우측, 혹은 화면 최하단에 액션을 수행하는 아이콘의 형태로 툴 바가 위치한다. 하단에 배치된 툴 바의 경우 키보드가 나타날 때 화면에서 키보드에 가려지는 형태가 되기도 한다.

- 아이패드의 경우 네비게이션 바가 길기 때문에 우측에 다양한 아이콘을 배치하기도 한다.

탭 바

- 하단의 탭 바를 통해서 다른 페이지 뷰로 이동하거나, 모드 혹은 별도의 액션을 실행하기도 한다.

- 5개 이상의 아이콘은 배치하면 안되고, 5개 이상일 경우는 More 아이콘에 관련 내용을 넣는다.

- 가로모드/세로모드 모두 동일한 갯수의 탭 바 아이콘을 제공해야 한다.

서치 바

- 서치 바를 통해서 사용자들은 서치와 관련된 텍스트를 입력할 수 있다.

- 필요에 따라 입력한 텍스트에 대한 Clear 버튼을 배치할 수도 있다.

- 별도의 텍스트 정보를 제공하고자 할 경우, 프롬프트(텍스트 정보 제공)를 제공한다.

스코프 바

- 스코프 바는 일반적으로 서치바와 함께 사용되며, 서치의 범주를 설정하는 데 사용된다.

- 안드로이드폰

툴 바

- 툴 바는 굉장히 다양하게 사용이 된다. 디폴트 사이즈 혹은 확장된 사이즈로 사용 가능하다.

- 컬럼 너비로 사용할 수도 있고, 카드 보드 형식으로 툴 바를 사용할 수도 있다.

- 콘텐츠 위에 플로팅 툴 바로 사용할 수도 있고, 분리형 툴 바로도 사용 가능하다

바텀 툴 바

- 바텀 툴 바는 화면의 하단에 배치되며, 키보드가 나타날 경우에는 키보드 위에 배치할 수 있다.

- 책장(쉘프)형 바텀 툴 바 형태도 가능하다. 이 경우 아래에서 위로 필요 정보가 올라온다.

앱 바

- 과거에 액션 바'로 불리우던 것이 이제는 '앱 바'로 명칭이 바뀌었다.

- 툴 바의 한 종류로 분류되며 브랜딩, 네비게이션, 서치 그리고 액션과 관련된 요소가 배치되는 곳이다.

- 다양한 테마를 적용할 수 있다 : 라이트 / 다크 / 컬러 / 투명

스테이터스 바

- 스테이터스 바는 최상단에 위치하며, 좌측에는 노티피케이션 아이콘이 보여지며, 우측에는 시스템 아이콘 및 시간이 보여지는 곳이다.

- 일반적인 경우(디폴트)에 스테이터스 바는 앱 바에 쓰인 컬러보다 어두운 톤으로 적용되나, 희망할 경우 다른 결러를 적용하거나 투명하게 할 수도 있다.

- 밝은 컬러의 스테이터스 바를 선택한 경우라면 아이콘은 어두운 색으로 적용한다.

사이드 네비

- 사이드 네비는 임시로 나타나거나, 화면 사이즈에 따라서 고정형으로 나타나기도 한다.

- 좌측에 나타나는 경우도 있지만, 우측에 나타나는 경우도 있다. 이 경우 좌측 사이드 네비에서는 네비게이션 / 아이덴티티 중심의 내용이 배치되어야 하며, 우측 사이드 네비에서는 해당 페이지에서 필요로 하는 부가적인 정보를 배치하여야 한다.

탭 바

- 콘텐츠의 카테고리에 따라 구분되어지는 고정 탭 바에는 간결한 명칭을 기입하여야 하며, 다양한 디자인 형태로 구성할 수 있다.

- 디폴드 앱 바 + 고정 탭 바

- 확장형 앱 바 + 고정 탭 바

- 다양한 스타일의 고정 탭 바

화면이 스크롤 될 경우, 상단에 남아있는 고정 탭 바

앱 바의 서치가 활성화 될 경우 + 고정 탭 바

- 고정 탭 바에 컬러를 적용할 경우

디폴트 앱 바 + 고정 탭 바에 아이콘이 배치된 경우

고정 탭 바의 텍스트 걸러는 액션 아이콘과 동일하게 적용

고정 탭 바의 아이콘 컬러도 액션 아이콘과 동일하게 적용

- 고정 탭 바 외에도 '스크롤러블 탭 바'가 있다. 탭이 여러 개가 있을 경우 스크롤로 메뉴를 선택할 수 있도록 하는 방식의 탭 바이다. 고정 탭 바와 달리, 시작 지점이 화면 좌측으로부터 일정 거리 이상부터 시작된다.

6강 모바일 UI/GUI 디자인 컴포넌트 (2)

1. 컨트롤 컴포넌트

- 아이폰

시스템 버튼

- 앱 내에서 특정 액션을 실행하는 버튼. 디폴트는 외곽선 없는 글자 만으로 이루어진 버튼이다. 경우에 따라 아이콘을 포함하기도 한다. 경우에 따라서는 외곽에 선을 넣어서 버튼임을 명확히 하기도 한다.

스위치

- 스위치는 상태를 on/off 하는 경우에 일반적으로 사용된다. 컬러가 있는 좌측 이미지가 on, 컬러가 없는 우측의 이미지가 off이다. 

- 스위치는 테이블 뷰에서만 사용한다.

스태퍼

- 특정 양을 특정 단위로 늘리거나 줄이고자 할 때 사용한다. 일반적으로 +/-를 사용하며, 큰 숫자의 변화가 아닌 경우에 사용한다. 스태퍼를 선택할 경우, 구체적인 수치의 변화를 숫자 등으로 보여주지 않으므로, 사용자가 조작한 결과를 보여줄 수 있을 정도로 다른 변화를 보여주어야 한다.

슬라이더

- 슬라이더를 통해 사용자는 정해진 범위 내에서의 수치 값 변화를 손쉽게 진행할 수 있다. 일반적으로 좌측이 적은 방향이고 우측이 많은 방향이다.

피커

- 피커는 사용자가 하나의 값을 선택해야 할 경우, 손쉽게 선택할 수 있도록 제공해주는 컨트롤 컴포넌트이다. 일반 피커와 데이트(Date) 피커가 있다.

페이지 콘트롤

- 페이지 콘트롤을 통해 사용자는 총 몇 페이지가 존재하며, 현재 몇 번째 페이지에 있는지를 시각적으로 확인할 수 있다. 이 경우 사용자는 단계적으로 하나씩 이동할 수 있으며, 페이지가 너무 많을 경우에는 사용하는 것을 권장하지 않는다. 10개 미만을 권장하며, 20개 이상의 페이지가 필요한 경우 다른 방식을 선택할 것을 권장한다.

버튼

- 버튼은 특정 위치에 한정적으로 액션을 실행하는 역할을 진행한다.

- 추가 버튼 : 특정 아이템 혹은 항목을 추가하는 기능을 한다.

- 인포 버튼 : 해당 아이템의 추가 정보를 제공해주는 역할을 한다.

인디케이터 종류

- 네트워크 액티비티 인디케이터 : 통신 상태 등을 알려주는 시각적 컴포넌트

- 리프레시 콘트롤 : 해당 페이지 새로고침을 알려주는 역할을 한다.

텍스트 필드

- 텍스트 필드는 각 영역을 손으로 탭하게 되면 글자를 입력할 수 있다. 글자 입력시 화면에 키보드가 올라온다.

- 글자 입력시 'Clear'아이콘이 배치되기도 하며, 힌트 텍스트 등을 미리 넣을 수도 있다.

- 필요에 따라서 별도의 버튼 아이콘 등을 배치할 수 있다.

- 안드로이드

버튼 

- 버튼은 텍스트, 이미지, 혹은 둘 다 사용된 형태로 배치되며, 앱의 메인 컬러를 주로 사용하게 된다. - 플랫 버튼 / 레이즈드 버튼 / 플로팅 액션 버튼의 세 가지 형태가 있다.

플로팅 액션 버튼

- 사이즈 : 디폴트 사이즈와 미니 사이즈가 있다. 대부분은 디폴트 사이즈를 사용하며, 미니 사이즈는 비주얼의 통일성을 위해 다른 컴포넌트들과 사용할 때 적용한다.

- 일반버튼의 형태로써 남용해서는 안된다.

- 플로팅 액션 버튼은 Create / Favorite / Share / Navigate 등과 같이 긍정적인 행동을 넣는 것을 권장한다.

- 보관 / 삭제/ 얼럿/ 에러 등과 같이 부정적인 액션을 플로팅 액션 버튼에 놓는 것은 권장하지 않는다. 또한 사소한 역할을 하는 경우도 사용하지 않는 것을 권장한다.

- 플로팅 액션 버튼은 원형의 플랫하며 깊이감을 주는 형태를 하는 것을 권장한다. 다른 형태나 스큐어몰피즘의 형태는 권장하지 않는다.

칩 

- 칩은 해시 태그와 유사한 역할을 하며, 다양한 형태로 구성될 수 있다. 자유 입력 폼 / 사전 정의된 형태 / 아이콘을 포함한 형태 등이 가능하다.

- 콘택트 칩은 이메일 등에서 주로 사용되는 형태로써, 해당 인물의 프로필 이미지와 이름이 보여지며 선택할 경우 주로 뷰가 생성된다.

리스트 콘트롤

- 정의 : 리스트 콘트롤은 리스트 뷰 안의 콘트롤을 의미하며, 리스트 텍스트의 좌, 우에 배치된다. 리스트 아이템의 상태를 나타내거나 추가 정보 혹은 특정 액션을 수행할 수 있는 아이콘의 형태로 배치가 된다.

- 체크 박스 : 체크 박스는 1차 (주요) 액션 또는 2차 (서브) 액션을 할 수 있다.

- 스위치 : 스위치는 2차 (서브) 액션의 역할을 할 수 있다. 온/오프의 역할로 주로 사용된다.

- 리오더 (재정렬) : 리오더는 2차 (서브) 액션의 역할을 할 수 있다. 리스트 에디팅 모드에서 해당 리스트 항목의 위치를 이동하고자 할 때 주로 쓰인다.

- 확장/축소 : 확장/축소 아이콘은 2차 (서브) 액션의 역할을 할 수 있다. 리스트 아이템의 디테일 정보를 확장해서 보고자 할 경우에 사용된다.

피커

- 데이트 피커 : 데이트 피커는 다이얼로그 윈도우로 보여지며, 날짜를 선택할 경우에 쓰여진다.

- 타임 피커 : 타임 피커는 시간을 설정하고 할 경우에 쓰여지며, 다이얼로그 창에 사용된다.

셀렉션 콘트롤

- 체크 박스 : 체크 박스는 제공되는 여러 가지의 항목 중에서 원하는 옵션을 선택하는 데 사용된다. 온/오프로 선택이 되며, 한 하나의 선택지를 제공할 경우는 온/오프 스위치 사용을 권장한다. 어떤 동작을 취하느냐에 따라서 다양한 형태의 표현이 가능하다.

- 라디오 버튼 : 라디오 버튼은 세트 선택지 중에서 하나를 선택해야할 경우에 사용된다. 선택지를 나란히 늘어 놓고 하나를 선택할 경우에 사용되며, 항목들이 많을 겨웅에는 드롭다운 방식의 메뉴를 사용하는 것을 권장한다. 사용자가 어떤 동작을 취하느냐에 따라 다양한 인터랙션을 제공한다.

- 스위치 : 온/오프 스위치는 하나의 셋팅 옵션의 상태를 온/오프 하는데 사용된다. 텍스트로 '온/오프'를 표현하는 것은 권장하지 않고, 아래의 이미지만을 사용하는 것을 권장한다. 사용자가 어떤 동작을 취하느냐에 따라 다양한 인터랙션을 제공한다.

슬라이더

- 정의 : 슬라이더는 사용자가 손쉽게 슬라이더를 손가락으로 선택해서 이동시키며 수치를 조절할 수 있는 기능을 제공한다. 좌측으로 이동할 경우는 수치가 적어지며, 우측으로 이동하면 수치가 커지는 방식이며, 불륨, 밝기, 컬러 값 등을 정할 때 주로 사용된다.

- 연속형 슬라이더 : 가장 일반적인 슬라이더의 형태이며, 선택 상황에 따라 다양한 인터랙션이 제공되므로 참조한다. 경우에 따라서는 구체적인 수치값을 표현하는 경우도 있다.

- 분리형 슬라이더 : 구체적인 수치를 슬라이더에 별도의 아이콘의 형태로 표현하는 형태가 분리형 슬라이더이다.

텍스트 필드

- 정의 : 텍스트 필드에는 숫자, 텍스트, 이메일 주소 등을 입력하는 컴포넌트이다.

- 라벨 : 사용자가 텍스트 입력 필드를 터치하게 되면 해당 필드가 위로 올라오는 듯한 표현이 이루어진다. Floating Inline Label이라 부른다. 라벨에 적용되는 컬러는 앱의 컬러 팔레트 내에서 정해지며, 인터랙션 부분은 아래를 참조한다.

- 싱글 라인 텍스트 필드 : 1줄을 입력할 수 있는 텍스트 필드이다. 싱글 라인 텍스트 필드에 아이콘이 붙을 수도 있다.

- 멀티 라인 텍스트 필드 : 하나의 라인 텍스트 필드이나, 그 안에 여러 줄의 텍스트를 넣을 수 있는 컴포넌트를 '멀티 라인 텍스트 필드'라 한다.

- Full-width 텍스트 필드 : 이메일의 내용을 적는 란과 같은 역할을 하는 것이 'Full-width 라인 텍스트 필드'이다. 싱글 라인 텍스트 필드와 멀티 라인 텍스트 필드가 같이 적용되는 경우가 잦다.

- 캐릭터 카운터 : 구체적으로 입력할 수 있는 글자 수에 제한이 있을 경우, 캐릭터 카운터를 사용한다. 싱글/멀티/Full-width 텍스트 필드에 모두 적용 가능하다.

- 오토 컴플리트 텍스트 필드 : 서치 필드에 글자를 입력할 경우, 추천 항목을 보여주거나 자동 텍스트 완성 등의 기능을 한다. 텍스트를 입력하였을 경우, 해당 텍스트가 삽입된 자동 완성 텍스트를 추천해서 보여주는 기능을 한다. 일부 텍스트를 입력하였을 경우, 완료 형태의 항목을 보여주는 방식으로 자동 완성이 가능하다.

- 서치 필터 : 앱 바에 서치 기능을 활성화하여, 싱글 라인 텍스트 필드로 텍스트를 입력하는 경우이다. 글자를 입력함에 따라 아래에 관련 콘텐츠를 필터링/정렬하여 보여주는 기능을 한다.

- 필수 입력 필드 : 필수 입력 필드는 일반적으로 항목명 옆에 * 별표 표시를 하며, 해당 항목을 입력하지 않았을 경우 붉은 색으로 표기를 할 수 있다.

7강 모바일 UI/GUI 디자인 컴포넌트 (3)

1. 아이콘 디자인

- 아이폰

정의: 아이폰에서는 일반 아이콘을 '템플릿 아이콘'이라 부른다. 그리고 앱 아이콘을 동일한 명칭인 '앱 아이콘'으로 부른다

템플릿 아이콘

- 정의 : 템플릿 아이콘은 아이폰의 화면에서 손쉽게 볼 수 있는 일반 아이콘을 의미하며, 바에 위치하거나 홈스크린 퀵 액션 뷰 등에서도 사용된다.

- 디자인 스타일 : 템플릿 아이콘은 심플한 선으로 디자인하며, 일관성 있게 디자인 요소를 통일할 것을 권장한다. 아울러 최대한 표준 아이콘에 맞추어 디자인을 진행함으로써 사용자가 쉽게 이해할 수 있는 형태를 차용하는 것을 권장한다.

- 템플릿 아이콘의 형태 : 템플릿 아이콘 선택시에는 앱의 고유 컬러로 색을 적용하되, 

(1) 아이콘의 안을 채워 넣거나 반전 형태를 적용하도록 한다. 

(2)의 경우에 따라서는 별도의 원형을 외부에 두어 형태 인식을 좀더 명확히 할 수도 있다. 

(3) 단순히 컬러만을 반전할 경우에 시인성이 떨어진다면 외부의 선을 두껍게 만들어 시인성을 높일 수도 있다.

(4) 아이콘에 디테일을 높ㅇ힌 경우이다. 이 경우에는 외부의 선을 두껍게 한다면 디테일이 떨어지게 되므로, 단순히 컬러만 적용하도록 한다.

표준 템플릿 아이콘 리스트

- 툴 바, 네비게이션 바 적용 템플릿 아이콘

- 탭, 탭 바 적용 템플릿 아이콘

앱 아이콘의 의미와 역할

- 주요 역할 : 앱 아이콘은 앱 스토어에서 사람들에게 보여지는 대표 이미지와도 같은 역할을 하며, 사용자의 스마트폰 홈스크린에 배치되어 앱을 대표하는 대표 이미지이자 입구로써의 역할을 한다.

- 다양한 용도의 앱 아이콘 : 앱 아이콘은 이 외에도 다양한 용도에서 노출이 된다. 사용자의 아이폰 내에서의 검색 결과(스포트라이트), 셋팅 페이지 등에도 보여지며, 웹 사이트의 검색 결과 등에서도 쓰여진다.

앱 아이콘의 디자인

- 디자인 가이드

사람들이 쉽게 그 의미를 알 수 있게 디자인할 것

iOS 7 스타일로 앱 아이콘을 심플하게 디자인할 것

앱의 메인 콘셉트/기능 등을 직관적으로 알 수 있도록 디자인할 것

투명 요소를 포함하지 말 것

정사각형으로 이미지를 제출하면 외곽은 자동으로 잘려짐

- 앱 아이콘 이미지 용도

앱 아이콘은 크게 앱 스토어 등록용과 아이폰 앱 탑재용으로 나눌 수 있다.

앱 스토어용은 1개 사이즈로 제출하면 자동으로 리사이징 되어 외부에 쓰여지나, 앱 탑재용 이미지는 다양한 아이폰의 해상도에 맞는 이미지를 별도로 리사이징해서 탑재해주어야 한다.

- 안드로이드 (Material icon)

정의 : 안드로이드 OS에서는 일반 아이콘을 '시스템 아이콘'이라 부른다. 그리고 앱 아이콘을 '프로덕트 아이콘'으로 부른다. 이 둘의 역할은 아이폰에서의 아이콘들의 역할과 동일하다. 이렇게 명칭이 부여가 된 이유는, 단순히 모바일에서 쓰는 것을 넘어서, 다양한 제품/서비스에 앱이 쓰여지는 것을 가정하여 명칭이 쓰여지는 것으로 이해하면 된다.

시스템 아이콘

- 디자인 스타일 : 안드로이드폰의 모든 아이콘들은 머터리얼 디자인 테마를 적용하고 있으므로, 해당 스타일에 따라 모든 디자인 요소들을 맞출 필요가 있다. 전체적으로 아이폰과 비교하였을 때, 볼드한 스타일이며 플랫하다. 선과 면의 요소로 표현이 이루어지는 특징이 있다.

- 시스템 아이콘의 형태 : 모든 UI가 그렇지만, 안드로이드 시스템 아이콘 또한 일관성 있는 시스템 아이콘을 특히 강조하고 있다. 아이콘의 두께, 모서리 반경, +/- 스페이스의 너비 등의 디테일한 부분들을 모두 따라 줄 것을 권장하고 있다.

시스템 아이콘의 의미와 종류

- 공식 아이콘 라이브러리 참조 : 시스템 아이콘은 그 양이 방대하므로, 공식 아이콘 라이브러리를 참조하여 관련 내용을 학습하도록 한다. 필요시 해당 아이콘을 다운로드 받을 수도 있다.

- design.google.com/icons/

프로덕트 아이콘의 의미와 형태

- 정의 : 프로덕트 아이콘은 앱의 브랜드를 적절히 표현할 수 있는 시각적 대표 이미지의 역할을 하는 것을 권장한다. 친근하면서도 심플하게, 대담한 디자인 스타일을 적용하기를 권장하며, 다른 앱들과 시각적으로도 차별화가 이루어지는 것을 추천하고 있다.

- 프로덕트 아이콘의 머티리얼 디자인 개발 : 머티리얼 디자인의 특징을 잘 살려 심플, 머티리얼 (디지털 페이퍼), 그리자, 밸런스의 요소를 잘 적용하여 프로덕트 아이콘의 시각 디자인 요소를 명확히 하였다.

프로덕트 아이콘의 디자인 

- 프로덕트 아이콘의 그리드 시스템 : 프로덕트 아이콘의 시각적 통일성, 일관성을 위하여, 머티리얼 디자인 테마에서부터는 그리드 시스템을 적용하기 시작하였다. 따라서 안드로이드폰의 프로덕트 아이콘을 디자인 할 경우에는 이러한 형태적 특징을 그리드 시스템에서 시작하는 것을 권장한다.

- 프로덕트 아이콘의 용도 : 아이폰 앱 아이콘과 마찬가지로, 프로덕트 아이콘을 디자인 한 후에는 앱 탑재용 이미지와 앱 마켓 등록용 이미지로 저장하여 사용한다.

- 다양한 스타일의 안드로이드 앱 프로덕트 아이콘 : 머티리얼 디자인으로 앱 아이콘을 디자인하는 것을 권장하고 있으나, 가이드라인과 별개의 디자인 스타일로 만들어진 프로덕트 아이콘들도 많으니, 필요에 따라 추가 리서치를 통해서 아이콘을 기획하는 것을 권장한다.

2. 콘텐츠 디자인 - 아이폰

아이폰 : 액티비티 뷰 콘트롤러, 콜렉션 뷰, 맵 뷰, 팝오버, 테이블 뷰, 템포러리 뷰

- 모달 콘텍스트의 이해

양식/형식을 의미하는 모달리티 modality는 이전부터 존재해왔고 경험한 것을 의미한다. 사용자들은 아이폰 앱을 사용하면서 UI/GUI 디자인을 접하게 되는데, 기존에 경험했던 형태의 UI/GUI를 통해서는 불편함 없이 서비스를 이용할 수 있을 것이므로, 이러한 모달리티를 따르는 것을 권장한다.

- 액티비티 뷰 콘트롤러

내/외로 특정 태스크를 달성하기 위해 액티비티를 선택해야 하는 경우가 있다. 이러한 하나의 활동(북마크 추가, 복사 등)을 '액티비티'라 부른다. 서비스를 사용하던 중 특정 활동을 하게 되면, 이처럼 액티비티 뷰 콘트롤러가 화면에 나타나게 된다. 액션 시트 혹은 팝 오버 뷰에 나타나게 된다. 시스템 제공 기능과 개별적으로 구성한 기능을 배치하여 보여줄 수 있다.

- 콜렉션 뷰

콜렉션 뷰를 통해서는 정렬된 콘텐츠를 커스터마이제이션 할 수 있는 레이아웃에 보여줄 수 있다.

-  맵 뷰

빌트인 맵 앱의 기능을 활용한 맵 뷰를 통해 지역적 데이터 정보를 보여줄 수 있다.

- 팝오버

화면에서 콘트롤 아이콘을 탭하였을 때, 팝오버 뷰가 나타난다. 팝오버가 나타날 경우, 뒤의 화면은 어둡게 변하거나 블럭 효과를 주는 것을 권장한다. 팝오버에는 테이블, 이미지, 지도, 웹, 네비게이션 바, 툴 바 등을 배치할 수 있다. 팝오버에는 별도의 닫기 X 아이콘은 배치하지 않아도 된다.

(1) 팜오버 외부의 영역을 선택할 경우, 팝오버 안의 조작 내용은 저장해야 한다.

(2) 팝오버가 어느 위치를 눌러서 나오게 되었는지를 표시해주어야 한다. 화살표를 보여주게 하는 것도 좋은 방식이다.

(3) 팝오버 안의 내용만으로도 충분히 조작을 할 수 있어야 한다. 팝오버 뒤의 콘텐츠를 보아야 이해하고 사용할 수 있도록 하면 안된다.

(4) 팝오버는 한 번에 하나만 보여지도록 해야 한다.

(5) 팝오버 위에 또 다른 모달 뷰를 놓는 건 안된다.

(6) 팝오버 뷰가 너무 커서 화면 전체를 가리지 못하게 해야 한다.

- 테이블 뷰

정의 : 아이폰에서 가장 자주 쓰이는 뷰이기도 한 테이블 뷰이다. 테이블 뷰는 스크롤이 가능한 싱글 컬럼의 리스트 형태로 쓰여진다. 플레인과 그룹 테이블 뷰의 두 가지 스타일이 있다.

(1) 플레인 스타일 테이블 뷰 : 플레인 스타일 테이블 뷰의 한 열은 라벨이 표기된 섹션을 표기할 수 있으며, 테이블 뷰의 우측에는 추가 인덱스를 표시할 수 있다. 필요에 따라 헤더와 푸터를 붙일 수 있으며, 이 경우 첫 열 이전에 헤더를 배치할 수 있으며 마지막 열 이후에 푸터를 배치할 수 있다.

(2) 그룹 스타일 테이블 뷰 : 그룹 스타일 테이블 뷰에서는 열은 그룹 단위로 보여지게 된다. 이 경우 헤더와 푸터가 배치되며, 그룹에는 최소 1개 이상의 열이 포함되어야 한다.

(3) 4가지 테이블 셀 스타일

a. 디폴트 : 열의 좌측에 이미지가 들어가고, 좌측 정렬로 텍스트가 배치된다.

b. 서브타이틀 : 디볼트와 같으나, 텍스트 아래에 서브타이틀이 배치된다.

c. 벨류 1 : 디폴트와 같으나, 우측에 우측 정렬로 옅은 컬러의 텍스트가 배치된다.

d. 벨류 2 : 이미지는 들어가지 않으며, 우측정렬의 파란색 폰트를 좌측에 배치하고, 좌측 정렬로 검은색 폰트를 우측에 배치하는스타일

- 템포러리 뷰

(1) 얼럿 뷰 : 얼럿 뷰는 사용자가 앱 혹은 디바이스를 사용하는 데 큰 영향을 미치는 중요한 정보를 제공하는 역할을 한다. 충분히 이해할 수 있는 내용 정보를 최대한 짧게 보여주어야 하며, 하나 이상의 선택 버튼을 제공하여야 한다. 얼럿 뷰는 시스템에서 노출 되는 것이므로, 별도의 디자인을 적용할 수는 없다. 얼럿 뷰 안의 타이틀은 최대한 짧게 넣는다. 메세지가 길면 쉽게 파악하기 힘들 수 있으므로 최대한 짧게 넣는 것을 권장한다. 또한 필요에 따라서 작은 글자로 추가 부연 설명 메세지를 넣을 수도 있다. 부연 설명 메세지가 길어질 경우, 스크롤 방식으로 보여질 수 있으나 그렇게 하는 것은 권장하지 않는다. 일반적으로 선택 버튼은 두 개를 제공한다. 두 개 중 하나를 고르는 것이 쉽기 때문에, 일반적으로 두 개의 옵션을 제공한다. 단순히 하나의 옵션만 제공할 경우는 사용자에게 선택의 여지를 주지 않기 때문에 권장하지 않는다. 필요에 따라서 세 개 이상의 버튼을 제공할 수도 있으나, 복잡해지기 때문에 권장하지는 않는다.

(2) 액션 시트 : 액션 시트는 사용자가 선택할 수 있는 몇 가지의 선택지를 제공하는 뷰이다. 사용자가 어떤 행동을 취했을 때, 필요 선택지로 나타나는 방식이다. 두 개 이상의 버튼을 제공한다. 너무 많이 제공하여 스크롤이 되도록 만드는 것은 권장하지 않는다. 아이폰이 세로 모드일 경우, 액션 시트는 화면의 아래에서 나타난다. 아이폰이 가로 모드일 경우, 액션 시트는 팝 오버 뷰로 나타난다. 액션 시트는 테스크를 완수하기 위한 방법이 다양할 경우에 선택지를 보여주는 방식이며, 사용자에게 위험한 결과를 초래할 경우에도 경고성 및 확인차 보여주는 방식으로도 사용된다. 어떠한 상황이든지, 사용자에게 치명적인 결과를 초래하는 경우에는 붉은색 텍스트를 사용하여 경고의 의미를 전달한다.

(3) 모달 뷰 : 모달 뷰는 기존의 뷰 위에 임시적으로 나타나는 뷰이며, 특정 임무를 수행하는 것을 목표로 하는 뷰이다. 현재 있는 위치에서 필요한 기능 혹은 테스크를 완수하기 위해 임시로 나타난다. 해당 기능을 수행한 후에는 사라지는 것이 일반적이다.

8강 모바일 UI/GUI 디자인 컴포넌트 (4)

1. 콘텐츠 디자인 - 안드로이드 폰

안드로이드 폰 : 카드, 다이얼로그, 그리드 리스트, 디바이더, 리스트, 메뉴, 바텀 시트

카드

- 정의 : 카드는 다양한 콘텐츠와 컴포넌트로 구성할 수 있는 하나의 콘텐츠 카드라 할 수 있다. 다양한 형태와 구성, 그리고 콘텐츠에 따른 길이의 변형으로 편리하게 콘텐츠를 보여줄 수 있는 방식이다.

- 카들 콜렉션 : 동일 수준 및 개념의 카드 형태의 콘텐츠를 모아서 볼 수 있으며, 이러한 모음을 카드 콜렉션이라 한다.

- 카드 형태 디자인 Do : 반드시 각 모서리에 라운드/ 그림자 효과가 있어야 한다. 삭제 / 재배열 가능할 수 있다.

- 카드 형태 디자인 Don't 각진 모서리에 그림자 효과가 없으면 '타일tile'이다. 2개 미만의 액션이 배치되어 있다.

- 카드 콜렉션 Do : 장식적 요소가 적어 정보 이해 및 스켄이 빠르다

  그리드 타일을 통해 콘텐츠 갤러리 이미지 정보 전달이 용이하다

- 카드 콜렉션 Don't : 카드 형식을 선택함으로써 정보 스캔이 어렵다. 재배열 / 삭제 불가

갤러리는 일반적으로 카드 형식은 사용하지 않는다.

- 콘텐츠 : 카드 콜렉션을 통해서 다양한 정보와 콘텐츠를 제공할 수 있으며 그에 따라 다양한 스타일의 카드 디자인이 이루어질 수 있다. 따라서 카드에 콘텐츠를 디자인할 경우에는 이미지 위에 텍스트 배치할 경우 가독성이 보장되어야 하고, 콘텐츠의 위계가 명확해야 한다. 카드 안에는 체크 박스, 이미지, 다양한 텍스트 사이즈, 액션 등이 배치될 수 있다. 사이즈 또한 다양하게 변형될 수 있다.

- 스크롤링 : 카드 콜렉션에서 스크롤은 상하 방향으로만 가능하다.

- 액션 : 카드 자체가 터치할 수 있는 콤포넌트의 성격을 가지고 있지만, 기본적으로 몇 가지 레이아웃을 기본적으로 제공해주고 있으므로 추가적인 액션, 아이콘, 콘텐츠 등을 배치할 수 있다. 콘텐츠의 종류와 기획 의도에 따라 이는 굉장히 다양하게 적용될 수 있다.

- 카드 보조 액션 배치 및 레이아웃 : 

a. 액션 가능 영역 / 미디어, 보조 텍스트 

b. 액션 가능 영역 1,2 / 옵션 헤더, 미디어, 보조 텍스트, 보조 액션

c. 액션 가능 영역 1,2,3,4 / 옵션 헤더, 미디어, 보조 액션

d. 액션 가능 영역 1,2,3 / 옵션 헤더, 보조 텍스트, 보조 액션

- UI 콘트롤러를 포함한 카드 사례 : 

별점 UI와 이미지 터치 영역을 포함한 카드 디자인

선택할 수 있는 버튼을 포함한 카드 디자인

슬라이더 UI를 포함한 카드 디자인

고정 탭 바를 포함한 카드 디자인

다이얼로그

- 정의 : 다이얼로그는 특정 테스크를 수행하게 하는 역할로써, 텍스트와 UI 콘트롤러 등을 포함하여 사용된다. 앱의 중요 정보, 결정 사항, 다양한 테스크를 수행할 수 있도록 뷰를 제공한다. 일반 형태의 다이얼로그가 있고, 풀 스크린 다이얼로그는 전체 화면에서 정보 등을 입력하게 한다.

- 얼럿 : 얼럿은 중요한 결정을 해야 하는 경우에 주로 사용된다. 일반적인 경우에는 특정 행동을 유도하는 질문을 한다. '지우시겠습니까?' '연결하시겠습니까' > 결정 사항은 얼럿 내의 액션 버튼을 통해 진행할 수 있다. 액션 버튼에는 구체적인 행동에 대한 결과를 예측하는 용어를 사용한다.

- 얼럿 + 타이틀 바 : 얼럿에 타이틀 바를 사용할 경우는, 무척 중요한 상황에서만 사용할 것을 권장한다. 이 경우는 타이틀에 가장 중요한 내용을 간략히 적고, 콘텐츠 부분에 세부 사항을 자세히 적기를 권장한다.

- 심플 메뉴 : 심플 메뉴는 리스트 아이템에 대한 옵션을 보여주는 역할을 한다. 해당 옵션에서 선택을 하게 하면 선택의 결과가 즉시 반영된다.

- 심플 다이얼로그 : 심플 다이얼로그는 리스트 아이템에 대한 옵션을 보여주는 역할을 한다. 해당 옵션에서 선택을 하게 되면 선택의 결과가 즉시 반영되고, 창이 닫힌다.

- 심플 다이얼로그 Don't 다이럴로그의 바깥 영역을 터치하거나 스마트폰의 back 버튼을 누르면 창이 닫히는데, 별도의 Cancel 혹은 Close 버튼을 두는 것은 옳지 않다.

- 컨펌 다이얼로그 : 컨펌 다이얼로그는 옵션이 반영되기 전에 최종 컨펌을 받는 것을 목적으로 사용하는 경우이다. 최종 'OK'를 눌러야만 결과가 반영된다. 컴펌 다이얼로그 컨펌 다이얼로그는 이전의 리스트 형태 외의 다른 경우에도 사용이 가능하다. 데이트 피커의 경우에도 OK를 눌러야 최종 결정 사항이 반영된다.

- 풀스크린 다이얼로그 : 풀스크린 다이얼로그는 여러 가지의 테스크를 수행해야 하는 경우에 사용한다. 최종적으로 컨펌해야만 최종 작업이 결과에 반영된다. X 혹은 Cancel 할 경우에는, 수행 결과는 반영되지 않는다. 풀스크린 다이얼로그에서는 필요에 따라 추가 다이얼로그를 생성할 수 있다. 풀스크린 다이얼로그에서 일부 항목이라도 변경을 하였을 경우에, 취소를 하게 되면 변경 사항을 저장할 지를 묻는 얼럿을 보여주도록 한다. 만약 수정 사항이 없는 경우는 얼럿을 보여줄 필요 없이, 즉시 이전 화면으로 돌아가도 무방하다.

- 풀스크린 다이얼로그의 네비게이션

자동 저장 구조 : Up Arrow (화살표 아이콘)만 있을 경우에는 화면에서 변경하는 모든 항목들이 즉시 저장되는 방식이다.

수동 저장 구조 : X 아이콘을 누를 경우, 변경 사항을 모두 삭제하게 되며, Save를 누르게 될 경우에는 모든 사항이 저장되게 된다.

그리드 리스트 

- 정의 : 그리드 리스트는 기본 리스트 뷰의 또 다른 대안으로 사용되며, 일반적으로 동질 성격의 콘텐츠를 배열하여 보여주는 방식으로 정렬된다. 일반적으로 이미지와 관계된 경우에 주로 쓰인다. 타일을 사용하며, 특정 간격으로 수평 / 수직 그리드 리스트에 반복적으로 배열된다.

- 타일과 콘텐츠 : 타일 콘텐츠는 주요 콘텐츠와 2차 콘텐츠로 구성된다. 주요 콘텐츠는 일반적으로 이미지이며, 2차 콘텐츠는 액션 혹은 텍스트가 된다. 2차 콘텐츠의 구성 요소인 액션과 텍스트는 배치 위치가 정해져 있으므로 참조한다.

- 스크롤 Do : 일부 이미지가 잘려보이는 형태로 레이아웃을 구성하는 것을 권장한다.

- 스크롤 Don't : 이미지처럼 배치할 경우, 사용자는 화면의 아래에 추가 정보가 있을 거라 예측하지 못할 수 있기 때문이다.

- 이미지 그리드 리스트 : 이미지만으로 그리드 리스트를 구성하는 경우이다. 이 경우 이미지 사이즈를 적절히 구성하는 것이 중요하다. 이미지가 너무 클 경우에는, 빈 공간이 너무 커보일 수 있다.

- 싱글 라인 그리드 리스트 : 1줄의 텍스트를 넣는 그리드 리스트이다. 이 경우 텍스트를 타일의 상단 혹은 하단에 넣을 수 있다. 싱글 라인 텍스트에 아이콘을 추가할 수 있다. 이 경우도 아이콘을 텍스트의 앞 혹은 뒤에 배치하여 사용한다.

- 2 라인 그리드 리스트 : 텍스트가 2줄로 배열되는 구성이다. 이전과 마찬가지로 상단과 하단에 배치할 수 있다. 2라인 그리드 리스트의 텍스트 앞/뒤 위치에도 아이콘을 배치할 수 있다.

디바이더

- 정의 : 디바이더를 통해 리스트, 페이지 레이아웃의 콘텐츠와 그룹을 구분할 수 있다. 디바이더는 옅고 얇은 선으로 표현되지만, 사용자가 충분히 시각적으로 구별할 수 있으며 이를 통해 정보의 구분을 명확하게 할 수 있다.

- 풀 브리드 디바이더 : 풀 브리드 Full-bleed 디바이더는 별개의 콘텐츠 섹션을 나누는 것을 목적으로 쓰여진다. 또한 머티리얼 타일이 확장되어 콘텐츠가 추가적으로 필요할 때도 쓰여진다. 아바타 혹은 아이콘 같은 시각적으로 포인트를 주는 요소가 없을 경우에는 단순한 간격을 주는 것만으로는 구분이 되지 않으므로, 풀브리드 디바이더를 사용하는 것이 각 콘텐츠 타일을 명확히 구분지어 줄 수 있다.

- 인섹트 디바이더 : 'insect삽입'을 의미하는 인섹트 디바이더는 관계 있는 콘텐츠들을 나누는 것을 목적으로 쓰여진다. 연락처 리스트나, 대화 내의 이메일 리스트 등을 섹셕으로 나누는 역할을 한다. 인섹션 디바이더는 아바타 혹은 타이틀 시작 지점 등을 기준으로 시작점을 정한다.

- 디바이더 Don't : 풀 브리드 디바이더를 너무 많이 사용함으로써, 오히려 시각적 노이즈를 만드렁 내고 있다. 이로써 디바이더의 의미가 없어진다. 인섹트 디바이더는 비주얼 노이즈를 주링는 목적에서 주로 쓰여지나, 남용하면 의미가 없어진다.

- 서브 헤더 & 디바이더 : 서브 헤더와 디바이더를 같이 쓸 경우에는, 콘텐츠와 서브 헤더의 의미를 강조하기 위해 디바이더를 서브 헤더에 맞추어 배치한다.

리스트

- 정의 : 리스트는 싱글 컬럼으로 구성되어 있으며, 이 하나의 컬럼은 '타일'의 성경으로 구성되어 있다. 타일에는 콘텐츠를 배치하며, 리스트 내에서 필요에 따라 그 높이 값을 달리한다.

- 콘텐츠 구성 : 1개의 타일이 모여서 리스트를 이루며, 리스트 콘텐츠를 디자인할 때에는 콘텐츠의 위계를 잘 구성하는 것이 중요하다. 이를 통해 사용자가 중요한 정보를 좀 더 쉽게 찾을 수 있게 한다. 예를 들어, 이메일 리스트에 있어 아바타 > 제목 등의 순으로 배열하는 것이 더욱 중요 정보를 먼저 배치하는 것이다. 만약 3줄 이상의 텍스트와 더 많은 정보를 포함하고자 한다면 리스트가 아닌 카드 방식을 추천한다. 주요 액션은 좌측 배치 / 2차 액션은 우측 배치

- 싱글 라인 리스트 : 싱글 라인 리스트에서는 각 타일은 한 줄의 텍스트만을 배치한다. 아이콘과 함께 배치될 수 있으며, 텍스트의 길이는 다양하게 적용될 수 있다.

- 싱글 라인 리스트의 응용 : 싱글 라인 리스트에는 텍스트만 넣거나, 아이콘과 텍스트를 넣거나, 아바타, 텍스트, 아이콘을 전부 넣는 것이 가능하다. 

- 2 라인 리스트 : 2 라인 리스트에는 2줄의 텍스트가 들어간다. 이 또한 싱글 라인 리스트와 마찬가지로 아이콘, 아바타 등과 같이 배치가 가능하다.

- 2 라인 리스트의 응용 : 텍스트만 들어간 형태의 2 라인 리스트, 아이콘과 텍스트를 같이 사용한 경우가 가능하다. 또한 아바타와 텍스트, 그리고 아바타, 텍스트, 아이콘을 사용한 2 라인 리스트가 가능하다.

- 3 라인 리스트 : 3 라인 리스트도 리스트의 형태로 구성이 가능하다. 3 라인 이상의 내용이 들어갈 경우에는, 리스트가 아닌 카드 형태의 구성을 고민해보아야 한다. 3 라인 리스트 또한 다양한 콘텐츠로 구성이 가능하다.

- 3 라인 텍스트의 응용 : 텍스트 만을 사용하거나, 아이콘과 텍스트를 사용한 3 라인 리스트가 있다. 아바타와 텍스트, 또는 아바타, 텍스트, 아이콘의 조합으로도 3 라인 리스트의 타일을 구성할 수 있다.

메뉴

- 정의 : 메뉴는 임시 팝업 형태로 나타나며, 버튼, 액션 등으로 구성된다. 각 메뉴의 항목들은 옵션 액션의 역할을 하며 화면 내에 선택한 항목들에 어떠한 액션을 수행하거나 앱 내에서 어떠한 역할을 하는 것을 선택할 수 있다. 메뉴의 각 항목은 싱글 라인 텍스트로만 구성되어야 하며, 선택시 즉시 수행되어야 한다.

바텀 시트

- 정의 : 바텀 시트는 화면의 하단에서 올라오는 머티리얼 시트이다. 바텀 시트는 사용자가 행동한 액션에 대한 결과로 나타나게 되며, 위로 스와이프 할 경우에는 필요한 추가 정보를 더 볼 수 있게 한다. 바텀 시트는 임시적 모달 시트의 역할을 하기도 하며, 퍼시스턴트 바텀 시트는 앱 구조의 일부로써의 역할을 하기도 한다. 구글 지도 앱의 경우, 바텀 시트는 앱 구조의 일부 역할을 한다.

- 퍼시스턴트 바텀 시트 : 퍼시트턴트 바텀 시트는 앱 구조의 일부로써, 평상시에도 메인 뷰 하단에 남아 있다가 필요에 의해 추가 정보를 보여주는 역할을 한다. 새로운 정보를 보여주거나, 주요 콘텐츠에 대한 콘텐츠를 보여준다. 퍼시스턴트 바텀 시트는 하단에 위치하고 있다가 필요에 따라 화면에서 선택한 지역의 세부 정보를 보여준다. 현재 메인 페이지에서 다른 정보를 살펴보고 있다 하더라도 퍼시스턴트 바텀 시트는 플레이 되고 있는 음악에 대한 정보를 표시하고 있다.

- 모달 바텀 시트 : 모달 바텀 시트는 '메뉴', '심플 다이얼로그' UI의 대안으로 종종 쓰여진다. 다른 앱과 연계 기능이나 콘텐츠를 보여주는 역할을 한다. 다른 뷰 위에 배치 되므로 모달 뷰의 역할을 하며, 뒤 화면을 활성화 시키기 위해서는 모달 바텀 시트를 닫은 후에 사용할 수 있다. 모달 바텀 시트는 리스트 혹은 그리드의 형태로 액션 혹은 선택 옵션 항목을 보여준다. 항목을 보여줄 때에는 중요 정보를 잘 구성하여 사용자가 쉽게 이해할 수 있도록 한다.

- 모달 바텀 시트 Do : 모달 바텀 시트의 높이는 콘텐츠의 높이만큼만 올라오면 된다.

모달 바텀 시트 내에서 많은 수의 선택지가 주어지더라도 최상단의 앱 바를 침범하지는 않는다.

- 모달 바텀 시트 Don't : 포함하고 있는 리스트 항목보다 훨씬 높은 위치까지 리스트가 보여지는 것은 

   권장하지 않는다.

   모달 바텀 시트가 최상단의 앱바를 침범하여 올라와 있으므로, 사용자가 모달 바텀 시트의 외부 영역을 터치하여 모달 바텀 시트를 닫기 어렵다.

- 모달 바텀 시트 조작 : 모달 바텀 시트는 모달 바텀 시트 영역을 스와이프 다운하거나, 외부 영역을 터치하게 됨으로써 모달 바텀 시트를 닫을 수 있다.

9강 컬러 (1)

1. 컬러의 기본 이론

- 기본 개념 학습

컬러의 기본 개념

- 정의 : 컬러는 단순하게 색으로 존재하는 것이 아니라 이미지 감정 등의 다양한 요소를 포함하고 있는 요소이다. 그리고 UI에 사용되는 컬러는 일반 생활에서 컬러를 접하는 것보다 사용성이란 측면에서 구체적인 역할을 하게 되는 경우도 있다.

' 색이란 우리가 무엇인가를 처음 대면했을 때 가장 먼저 인지하는 요소일 것이다. 문화적 / 관습적 인식 때문에 특정 색을 접했을 때 자연스레 어떠한 이미지나 감정을 떠올리게 마련이며, 이에 따라 그 사물이나 디자인에 반응하게 된다. 색은 의미를 지니며 이에 대한 우리의 반응은 문화적 환경, 트렌드, 연령, 개인적 기호 등 다양한 요소에 영향을 받는다. ' - '컬러' 앱브로즈-해리스 지음

가산 혼합, 감산 혼합

- 빛의 색, RGB : 빛의 색을 표현하는 3원색인 RGB는 가산 혼합 방식의 컬러이다. 빛의 속성이기에 겹쳐짐에 따라 밝아지는 방식으로 주로 디지털 미디어인 모니터, 스마트폰 등의 스크린에 적용되는 컬러 방식이다.

- 물체의 색, CMYK : 구체적으로는 인쇄 컬러라고도 불리우는 CMYK는 감산 혼합 방식의 컬러이다. 물감을 덧칠하면 색이 어두워지는 것으로 연결지어 생각하면 된다 .주로 현실의 인쇄물, 페인팅 등이 적용될 때의 컬러이다.

색의 표시

- 색의 3속성 : 하나의 컬러는 색의 3속성을 통해 표현될 수 있다. RGB는 가산 혼합 방식에서의 구성 단위로써는 설명하기 좋으나, 실제 사람의 언어로 컬러를 이해하고 표현하기는 어렵다. 이에 색의 3속성인, 색 (hue/color) / 채도(saturation) / 명도 (brightness) 를 사용해서 컬러를 표현한다.

- 색 hue / color : 색이란 각 색의 고유한 특성을 의미하는 것이며, 시각적으로 구분할 수 있다.

- 채도 saturation : 채도는 색의 선명한 정도를 의미한다. 가장 높은 채도의 색은 선명하게 밝은 빛을 내며, 채도가 낮을 수록 가라 앉는 느낌을 준다.

- 명도 brightness : 명도란 색의 밝고 어두운 정도를 의미한다. 어두워질 수록 검정에 가까워지고 밝을 수록 색의 원색에 가까워진다. 명도와 채도는 별개의 개념이므로 혼동하지 않도록 한다.

- 색상환 the color whell : 배색을 색의 관계를 통해 진행하기 위해서 일반적으로 색상환을 사용한다. 색상환이란 색체 스펙트럼을 둥글게 나열한 형태이며, 색채 이론에서 중요한 역할을 한다. 색상환을 통해 색의 경향(난색/한색 구분)을 파악하거나 관계에 따른 배색 원리를 적용할 수 있다.

- 색상환과 색의 3속성 활용 색상황에 이전에 학습한 3속성을 대입하여 명도와 채도를 포함한 형태의 색상환을 통해 실제 컬러를 선택하고 적용한다.

색 상환을 활용한 배색

- 단색 Monochrome : 색 상환 중 한 가지 색을 의미한다.

- 단색 계열 Monochromatic : 단색 선정 후 명도를 달리하여 사용하는 배색을 의미한다.

- 유사색 Analogous : 선정한 하나의 주색과 그 옆에 바로 인접한 두 색을 의미한다. 유사색을 사용한 디자인은 자연스럽고 조화로운 느낌을 준다.

- 보색 Complementary : 마주보는 위치의 색을 의미하는 보색은, 강렬한 대비 효과로 활기있는 배색이 가능하다.

- 분리 보색 Split Complements : 마주보는 보색 중 한 쪽의 보색에 인접한 두 가지 색을 포함하여, 세 컬러의 배색을 의미한다.

- 삼색 프라이어드 Triad : 색상환에서 같은 간격으로 놓인 세 색의 조합으로, 세 가지 색 모두가 대비되므로 긴장감이 느껴진다.

- 색의 범위 / 색역 gamut

색역의 이해

- 정의 : 색역이란 색 체계와 디바이스에 따라 실제 재현할 수 있는 색의 범위를 의미한다. 따라서, 색역에 대한 개념 없이 컬러 작업을 하게 되면 의도치 않게 다른 컬러가 보여지기도 한다.

 ' 색역이란 특정 색 체계, 장비나 공정에서 재현할 수 있는 색의 범위를 가리킨다. 모니터, 스캐너, 그래픽 프로그램, 인쇄소의 출력기 등은 각각 재현할 수 있는 색의 범위, 즉 색 공간이 다르다. 색 공간이란 디자이너가 활용할 수 있는 색의 범위인 셈이다. 이 때문에 색재현 범위의 가장자리에 있는 색을 써서 작업한 후 다른 기기로 옮겨 재현하면 원본 디자인의 색과 다르게 나올 수도 있다.

'컬러' 앰브로즈-해리스 지음

- 색역의 비교 : RGB 색역과 CMYK를 비교해보면, 겹쳐지는 부분도 있지만 겹치지 않는 부분도 존재한다.따라서, 컬러모드가 달라질 경우 다른 컬러모드에서 표현하지 못하는 색일 있을 수 있다.

- 디바이스와 색역의 비교 : 색역도 별도로 존재하지만, 이러한 색역 또한 어떠한 디바이스냐에 따라서 표현 / 채집할 수 있는 색의 범위가 다르다는 점도 숙지해야 한다.

2. 컬러의 의미와 역할

- 컬러의 의미와 역할의 이해

제품 / 서비스 / 모바일 앱에서 컬러는 실제적으로 굉장히 중요한 역할을 하고 있으며, 단순한 취향을 넘어서 컬러의 의미도 포함하고 있다. 그럼에도 불구하고, 실제 프로젝트 진행시 임의로 선정하는 경우가 잦다. 또한, 컬러는 감정적인 부분도 포함하고 있으며 브랜드 아이덴티티를 나타내는데 중요한 역할을 한다. 더불어 모바일 앱에서는 컬러가 UI에도 적극적으로 사용되므로, UI유저 인터페이스에서의 컬러의 의미를 이해해야 한다.

- 컬러에 따른 감정

컬러별 의미

- 정의 : 컬러는 감정적인 의미로 해석할 수가 있다. 붉은 색은 열정, 사랑, 분노, 위험, 공격 등의 의미를 지닐 수 있다. 파란색은 지식, 차가움, 안정, 평온함 등의 의미를 지닐 수 있다. 이처럼 컬러는 긍정 / 부정의 의미를 동시에 지니며, 한 가지 색뿐만 아니라 여러 색을 조합해서 다양한 의미를 만들어 내기도 한다.

- 국가 / 문화별 컬러의 의미 차이 : 컬러는 또한 나라별로 그 의미를 다르게 가지기도 하며, 특정 컬러는 공통된 의미를 가지고 있기도 한다. 의미가 없거나, 사람들이 각기 다른 의미를 부여하는 경우도 있다. 이 경우는 해당 컬러가 보편적으로 받아들여지지 않는다고 해석하면 된다.

- 대상, 주제에 적합한 컬러 : 누군가를 대상으로 하느냐, 무엇을 주제로 하느냐에 따라 어울리는 컬러인지 아닌지에 대한 일반적인 의견도 존재한다. 변호사를 대상으로 한 앱인데, 핑크색이라면? 어린아이를 대상으로 한 앱인데, 검정색이라면? 희망 / 행복을 주제로 하는데, 회색이라면? 평온함을 주제로 하는데, 붉은색이라면?

브랜드와 컬러

- 기존 브랜드가 선점한 컬러 : 기존 브랜드가 컬러와 의미를 선점하고 있는 경우도 있으므로, 해당 분야에 진출하고자 할 때 주의해서 컬러를 정해야 한다.

- 컬러와 인지 심리 : 컬러를 통해서 감정, 의미를 가지느냐가 중요한 의미를 지니므로 컬러에 대한 심리학 학문도 존재하며, 제품/서비스/앱을 통해서 전달하고자 하는 가치와 브랜드, 그리고 컬러는 일관성이 있어야 한다. 삼성 전자의 블루 컬러를 통해서는 '신뢰'를, LG 전자의 레드 컬러를 통해서는 '열정, 도전'을 SK의 레드, 오랜지 컬러를 통해서는 열정, 도전 그리고'새로움, 이노베이션'을 떠올린다. 따라서 이와 같은 요소를 모바일 앱을 통해 전달하고자 한다면, 컬러에 따른 감정 요소를 구체적으로 이해하고 컬러 선정에 활용할 수 있어야 한다.

UI와 컬러

- 긍정 / 부정의 의미 : 브랜드 아이덴티티를 대표하는 컬러도 있지만, 브랜드 컬러와 별개의 역할로 UI에도 쓰여지며, 구체적으로는 GUI 작업 단계에서 명확히 표현된다. 가장 대표적으로는 YES / NO를 의미하는 초록색과 붉은색이 있으며, 사용자가 버튼 UI를 통해 행동을 선택해야 할 경우에 쓰인다. 사용자가 컬러의 사용 의미를 알고 있다면, 화면에서 정보를 파악하는데 시간을 적게 사용하고도 안심하고 쉽게 행동을 취하게 할 수 있다. 

- 위계 표시 : 모바일 앱의 화면에 텍스트가 표현될 때, 폰트의 굵기와 사이즈로도 중요 정보를 표현할 수 있으나, 컬러도 위계를 나타내는 데 큰 역할을 한다. 컬러의 배색을 통해 무엇이 중요하고 중요하지 않은지를 쉽게 파악할 수 있다. 실제로 사용자는 컬러를 통해 중요도를 파악하고 있다고 인지하지 못하지만, 이를 통해 자연스럽게 사용자의 행동을 유도할 수 있으며, 배색이 엉망일 경우에는 사용자가 불편하다고 여기거나 정보가 (부정적 의미에서) 많다고 여기게 되고 결과적으로 안 쓰게 된다. 중요한 것과 중요하지 않은 것을 디자이너가 의도적으로 이끄는 것은 위계를 디자인하는 것이다.

- 창의력 UI 컬러 적용 : 일반적으로 구매 버튼은 붉은 색이나, 경우에 따라 다른 컬러를 적용해서 그 의미를 전달할 수 있다.

3. 포토샵과 컬러

- 포토샵 Adobe Color CC와 배색

어도비 컬러 CC

- 소개 : 어도비에서는 컬러 배색을 손쉽게 할 수 있도록 도와주는, '어도비 컬러 CC'를 제공하고 있다. 어도비 컬러 CC는 대표 명칭이며, 총 3가지 경로를 통해 배색을 진행할 수 있다.

- Adoble ID를 통한 Creative Cloud 서비스 : 어도비 ID로 로그인해서 작업할 경우 각 서비스 간 작업 결과 공유 및 저장이 가능하다.

어도비 컬러 웹사이트

- 소개 : 이전에는 kuler 라는 명칭으로 제공되던 서비스가 이제는 color.adobe.com 웹 사이트를 통해서 제공하고 있다.

- 주요 기능 : 중앙 색상환을 통해서 배색 구성이 가능하며, 마우스로 해당 지점을 드래그하면 직관적으로 조절이 가능하다. 이러한 결과는 아래에서 바로 결과를 확인할 수 있다. 하단 컬러 부분을 선택한 후, 화살표 아이콘을 누를 경우 작업하고자 하는 컬러모드를 변경할 수 있다. (지원 컬러 모드 : CMYK, RGB, LAB, HSB, HEX)

-  색상 규칙 적용 : 화면 좌측의 '색상 규칙 Color Rules'기능을 통해 앞에서 학습한 배색 규칙을 적용하여 색 구성이 가능하다.

a. 유사

b. 단색

c. 삼각형

d. 보색

e. 혼합

- 이미지에 컬러 추출 : 기본 모드인 '만들기'에 있을 때, 우측 상단의 카메라 아이콘을 통해 이미지를 임포트 할 수 있다. 이를 통해 외부에서 가지고 온 이미지 화일에 대해 컬러 배색을 적용할 수 있으며, 컬러 추출도 가능하다. 이미지에서 자동으로 컬러를 분위기에 따라서 자동 추출해주는 기능이 있지만, 일반적으로 앱의 GUI에 대한 컬러 배색을 위해서는 '사용자 정의'로 필요 부분만을 추출하는 게 일반적이다. 컬러를 추출한 후, 좌측 위의 저장 버튼을 통해 (어도비 ID계정으로) 저장할 수 있다.

- 탐색 메뉴 : 탐색 메뉴에서는 다른 사람들이 저장해서 공개한 컬러 스와치를 볼 수 있다. 이를 통해 필요한 컬러를 별도의 작업 없이도 다른 사람들의 스와치를 사용할 수 있다. 서치 기능을 통해 이전에 공개로 저장한 스와치를 찾을 수도 있다.

- 내 테마 메뉴 : 내 테마 메뉴에는 이전에 저장한 나의 컬러 스와치들을 전부 확인할 수 있다.

모바일 앱 'Adobe Capture CC'

- 소개 : 웹 사이트 외에도 모바일 앱으로도 어도비 컬러 기능을 사용할 수 있다. 아이폰 앱과 안드로이드폰 앱으로 제공되고 있다.(무료)

- 4개의 앱을 하나로 통합 : 어도비의 다양한 모바일 앱들을 2015년 Adobe CC 업데이트시 'Adobe Capture CC'앱에 모아서 1개의 앱으로 만들어 출시 하였다. 총 4가지인 Color, Shape, Brush, Look 기능이 제공된다.

- Color 메뉴 : 여러 기능 중에서도 본 과정에서 살펴볼 기능은, 'Color'이다. 앱 실행 후 나오는 메뉴 중에서 Color를 선택하면 된다.

- 이미지 캡처 및 컬러 배색 : 모바일 앱이라 당연히 UI는 다르지만, 제공하는 기능을 동일하다. 다만 카메라 기능을 통해 원하는 이미지를 촬영한 후 컬러 캡처가 가능하며, 폰에서 캡처 이미지를 불러와서 바로 컬러 스와치 추출이 가능하다.

- 불러온이미지에 대한 색상 무드 적용 : 불러온 이미지 또한, 상단의 색상 무드 아이콘(스마일)을 눌러서 원하는무드를 적용할 수 있다. 라이브러리에 저장된 컬러 스와치를 선택한 후, 편집 기능을 통해 색상 편집'을 진행할 수 있다.

포토샵과 Adobe Color Themes 

- 소개 : 포토샵에서도 지금까지 소개한 컬러 CC의 기능을 사용할 수 있다. 포토샵 CC의 상위 메뉴 '창 Window'에서 'Extensions > Adobe Color Themes'를 선택하면 도구 창으로 열 수 있다. 

-  포토샵 내에서 Adobe Color Themes : 포토샵에서 해당 도구를 통해, 웹과 모바일 앱에서 제공한 모든 기능이 동일하게 사용할 수 있다. 상단 메뉴 : 만들기 Create / 탐색 Explore / 내 테마 My Themes

- 포토샵 내에서 Adobe Color Themes : 내 테마 메뉴에서는 이전에 Adobe ID를 사용하여 저장한 '페이스북 ~' 컬러 스와치를 볼 수 있으며, 이를 테마 옆의 아이콘을 눌러서 '스와치로 저장'을 선택하면, 포토샵의 스와치로 바로 옮길 수 있어 유용하다.

10강 컬러 (2)

1. 아이폰과 컬러

- 아이폰의 컬러 정의

커뮤니케이션을 위한 컬러

- 개념 : 아이폰에서 컬러는 단순하게 색을 표현하는 것이 아니라, 컬러를 통해 인터랙션 정보와 시각적 일관성에 대한 정보를 얻을 수 있다.

- 참조 사항 : 

인터랙션을 지정한 컬러를 비 인터랙션 내용에 적용하지 않는다. 

iOS7부터 메인 컬러가 지정된 요소들은 인터랙션을 적용한다. 그렇지만 동일 컬러를 인터랙션이 되지 않는 요소들에 적용할 경우에는 사용자들이 혼란을 겪게 된다. 마치 버튼이 눌리지 않는 것과 같은 혼란을 줄 수 있다.

사용 상황의 컬러 대비를 항상 체크한다.

테스트 걸러와 배경 컬러의 대비가 명확하게 나오지 않을 경우, 구분이 되기 어려울 수 있다. 또한 밝은 대낮의 야외에서 사용하는 경우, 늦은 밤 어두운 곳에서 사용하는 경우가 있을 수도 있으므로 앱에 대한 컬러를 항상 주의한다.

메인 컬러의 적용

- 메인 컬러와 UI의 단순화 : 서비스의 메인 컬러는 일반적으로 1개를 선택하여, 전체 UI에 일관적으로 적용한다.

- 희색 배경 컬러 : 배경은 희색 사용을 추천하며, 흰 바탕의 검은 글자와 같이 전통적 개념의 색 배열을 통해 좀 더 쉽게 콘텐츠에 주목할 수 있도록 배색하는 것을 권장한다.

- 새로워진 컬러 팔레트 : iOS7 업데이트 후부터 새로운 컬러 팔레트를 적용하고 있다. 직접적으로 브랜드 컬러를 적용하지 않더라도, 운영체제에서 일반적 쓰이는 컬러와 얼마나 차이가 나는지는 알 수 있어야 한다.

- 빌트인 앱 (혹은 디폴트 앱) 과 비교 : 아이폰에 기본 설치된 빈트인 앱들과 비교해보아 컬러의 쓰임과 적용을 좀 더 이해할 수 있도록 한다.

2. 안드로이드와 컬러

- 구글 머티리얼 디자인과 컬러

구글 머티리얼 디자인 컬러

- 개념 : 구글의 디자인 테마인 머티리얼 디자인 테마를 안드로이드에도 채용함에 따라, 컬러 또한 머티리얼 디자인의 컬러를 당연히 적용하게 되었다.

- 컬러의 중요성 : 디지털 페이퍼, 컬러 위계, 모션 & 인터랙션을 머티리얼 디자인의 3대 특성으로 대표하며, 컬러도 중요 3요소 중 하나이다.

- 컬러 위계 : 프린트 디자인의 개념을 적극 수용하여 컬러, 이미지, 레이아웃 등의 개념을 모바일에 구현함으로써 특징적인 디자인을 구현하는 개념

- 컬러의 정의 : 머티리얼 디자인에서의 컬러는, 대담한 컬러 배색과 하이라이트 컬러의 사용, 그림자가 표현되는 다양한 상황을 주로 표현한다. 현대 건축, 도로 표지판, 마킹 테입 등에서 아이디어를 얻었으며, 컬러는 새롭고 자극적인 배색을 추천한다.

머티리얼 디자인 컬러 팔레트

- 다양한 컬러의 팔레트 : 머티리얼 디자인 컬러를 선택할 수 있돌고 컬러 팔레트를 제공해주고 있으며, 공식 사이트의 컬러 섹션을 통해서는 포토샵 스와치 컬러 팔레트 화일도 받을 수 있다.

https://www.google.com/design/spec/style/color.html

- 머티리얼 컬러 계획 : 자신의 프로젝트에 적합한 컬러를 선택하거나, 만약 선택하지 못했다면 제공되는 컬러 내에서 컬러를 선택하는 것도 추천한다. 컬러는 메인 컬러(500)로 1개 선택 후, 2개의 메인의 서브 컬러 (예에서는 (700), (800)) 선택, 2팔레트에서 1개의 엑센트 컬러를 선택하면 된다.

- 메인 컬러 선택 : 컬러는 메인 컬러(500)로 1개 선택 후, 2개의 메인의 서브 컬러를 팔레트에서 고르면 된다.

- 엑센트 컬러 선택 : 메인 컬러 계열이 아닌, 대비 되는 다른 컬러 중 하단의 'A~' 가 붙어 있는 컬러 중에 하나를 엑센트 컬러로 선택한다.

- 엑센트 컬러의 역할 : 엑센트 컬러는 플로팅 액션 버튼, 슬라이더, 스위치, 인디케이터, 링크 등의 사용자 인터랙션이 필요한 부분 및 관련 부분에 사용된다.

머티리얼 디자인 컬러 Do & Don't

- 텍스트 내의 컬러 남용 자제 : 웹 링크를 나타내는 텍스트 내의 엑센트 컬러와 달리 전체 텍스트에 엑센트 컬러를 넣는 것은 권장하지 않는다.

- 앱 바에 엑센트 컬러 사용 금지 : 미니 플로팅 액션 버튼에 엑센트 컬러가 적용된 좋은 예와 달리, 액션 바에 엑센트 컬러가 들어온 경우는 나쁜 예이다. 플로팅 액션 버튼과 동일 색이 될 경우에는 색 구별이 잘 가지 않으므로 추천하지 않는다.

3. 모바일 컬러 기획

- 마켓 리서치

관련 리서치

- 리스트업 : 디자인 프로젝트가 시작되면, 최소한 경쟁 서비스와 카테고리 등에 대한 정보를 알 수 있다. 이에 해당 서비스들의 리스트를 작성한 후 다운 받아서 주요 화면을 체크한다.

- 컬러 추출 : 컬러는 메인 컬러와 보조 컬러로 크게 이등분 할 수 있다. 주로 앱 아이콘에서 확인할 수 있는 메인 컬러와 앱 내의 UI를 구성하고 있는 컬러이다.

- 어도비 Color CC를 활용한 추출 : 메인 컬러와 보조 컬러를 어도비 Color CC 관계 서비스를 활용해서 추출한다.

- 메인 컬러 리스트 업 : 메인 컬러는 메인 컬러끼리 모아서 분석한다. 주로 어떤 컬러를 쓰는지를 중심으로 컬러를 체크한다. 이를 통해 앱의 메인 컬러 트렌드와 진행 방향을 알 수 있다.

(SNS는 파란색, 카메라는 따뜻하고 밝은, 쇼핑은 붉은색 위주로 쓴다)

- 서브 컬러 리스트 업 : UI를 구성하고 있는 컬러를 리스트 업 한다. 이를 통해 UI를 구성하고 있는 대다수의 컬러를 이해할 수 있다. 크게 구분한다면, UI 컴포넌트들의 컬러와 폰트로 나눌 수 있다.

- UI 컴포넌트의 컬러 : UI 컴포넌트의 컬러를 통해서는, 실제 UI를 구성할 때 필요한 컬러의 범위를 이해할 수 있다.

- 타이포그래피와 컬러 : 타이포그래피, 즉 폰트의 컬러 쓰임에 대한 추출을 통해서 폰트의 위계, 사용 방식에 대해 이해할 수 있다.

분석과 적용

- 리서치 분석 : 메인 컬러, 서브 컬러를 모아서 비교 분석을 통해 앱 컬러의 방향을 정한다. 필요에 따라서는 화면에 보이는 것처럼, 포지셔닝 맵을 활용하여 컬러를 선정할 수도 있다.

- 컬러의 적용 : 실제 컬러를 적용해보는 단계. 대략적인 컬러의 방향을 잡았다 하더라도 화면을 구성하면서 보게 되면 컬러를 수정하게 될 필요가 있으므로, 선정 후에도 수정의 경우가 있다는 점은 사전에 이해하고 작업을 진행한다.

- 컬러의 수정 : 서브 컬러는 대부분 UI에 적용되는 예이므로, 사전에 기획하고 디자인하게 되면 거의 수정할 경우가 없다. 하지만 메인 컬러는 앱의 전체적인 인상은 물론, 브랜딩의 개념을 포함하고 있으므로 수정하게 될 수 있다.

11강 타이포그래피

1. 모바일과 타이포그래피

- 타이포그래피의 이해

타이포그래피의 정의 ( Typography : 문자를 통한 커뮤니케이션 )

- 단순하게 폰트를 디자이너 마음대로 배열하는 것이 아니라, 구체적 대상, 매체(모바일), 콘텐츠 종류와 양, 비즈니스의 목표와 의도를 고려해서 폰트를 사용해야 한다.

- 고려사항 : 대상, 모바일(매체), 콘텐츠, 비즈니스 목표 & 의도

대상과 타이포그래피

- 유아와 성인은 지적 수준에서 큰 차이를 보인다. 각 대상의 특성에 맞추어 폰트를 적절히 사용해야 한다.

- 유아를 대상으로 할 경우, 글자를 안 씀

- 클래시 오브 클랜은 게임과 어울리는 폰트 사용

매체와 타이포그래피

- 모바일과 잡지, 포스터, 데스크톱 컴퓨터는 각기 다른 방식으로 보여지고 쓰여지고 사용된다. 매체, 여기에서는 모바일을 기준으로 하므로, 디지털 스크린, 작은 스크린 / 손가락 사용에 최적화 되어야 한다. 더불어 모바일 운영체제에 따라 폰트의 쓰임에 대한 가이드가 있으므로 이를 따라야 한다.

콘텐츠와 타이포그래피

- 텍스트, 사진, 동영상, 음악 등, 다루는 콘텐츠에 따라 폰트의 쓰임이 달라진다.

- 운영체제의 타이포그래피

운영체제 디폴트 폰트의 이해

- 앱 디자인시 폰트는 주로 디바이스 탑재 폰트를 주로 사용한다. 그리고 모바일 운영체제별로 탑재하고 있는 폰트들이 다르다. 따라서 이러한 차이가 폰트 사용 및 타이포그래피에 차이를 만든다.

- iOS 디폴트 영문 폰트 San Francisco

- 머티리얼 디자인 영문 폰트 Roboto

개발 툴과 모바일 앱 탑재 폰트

- 개발 툴과 모바일 앱 탑재 폰트를 맞추어야 한다.

- 개발 툴, 포토샵, 디바이스 탑재 폰트가 서로 맞는지 체크해야 한다.

- 빌트인 앱과 표준 타이포그래피의 이해

빌트인 앱 = 운영체제별 표준 타이포그래피의 표본

- 운영체제별로 기본적으로 탑재된 앱을 빌트인 앱 (혹은 디폴트 앱)이라 부른다. 해당 앱을 디자인 분석하고 타이포그래피의 사용을 이해한다면, 표준을 이해하는 것과 같다.

2. 아이폰과 타이포그래피

- 아이폰과 타이포그래피

아이폰 타이포그래피 활용 팁

- 폰트 훼밀리 사용 : 일반적으로는 앱 내에서 한 폰트 웨밀리 만을 사용한다. 여러 개의 폰트들을 사용하는 것은 추천하지 않는다.

- UI의 역할을 하는 타이포그래피 : 텍스트에 컬러가 적용되거나, 아이콘, 보더 등과 함께 사용되면 ui 버튼의 역할을 하게 된다. 아이폰 사용자들이 이를 식별 가능하고 조작 가능한 방식으로 디자인해야 한다.

- 효과적 컬러 사용을 통한 명확한 UI 역할 : 조작을 위한 텍스트의 컬러 적용시, 일반 텍스트와 명확히 구분되게 적용하는 것을 권장한다.

컬러 사용시 '위계'를 명심하라

- 텍스트에는 반드시 컬러의 위계를 적용하라 : 화면에서 텍스트의 중요 정도를 빠르게 파악할 수 있도록 하되, 사이즈는 물론 컬러로도 그러한 의도를 전달할 수 있어야 한다.

San Francisco, Apple SD Gothic Neo

- iOS 9 이후의 영문 시스템 폰트 San Francisco : 운영체제별로 기본적으로 탑재된 앱을 빌트인 앱(혹은 디폴트 앱)이라 부른다. 해당 앱을 디자인 분석하고 타이포그래피의 사용을 이해한다면, 표준을 이해하는 것과 같다.

https://developer.apple.com/fonts/

- iOS의 한글 시스템 폰트, 애플 산돌 고딕 네오 : 운영체제별로 기본적으로 탑재된 앱을 빌트인 앱 (혹은 디폴트 앱)이라 부른다. 해당 앱을 디자인 분석하고 타이포그래피의 사용을 이해한다면, 표준을 이해하는 것과 같다.

http://www.sandollcloud.com/portfolio...page/gothic-neo1/

3. 안드로이드와 타이포그래피

- 머티리얼 디자인과 타이포그래피

안드로이드 타이포그래피 활용 팁

- 영문 폰트와 한글 폰트의 확립 : 머티리얼 디자인이 적용되면서, 영문은 신 버전의 Roboto 폰트가 선정되었고 한글은 Noto Sans CJK KR 폰트가 개발되어 적용되었다.

- 폰트의 구분

English, English-like Scripts

Dense Scripts (Chines Japan Korean)

Tall Scripts (아랍쪽)                        이렇게 3종으로 폰트를 구분한다.

- 폰트 사이즈 표준화

English, English-like Scripts 사이즈 표준화를 정교하게 진행하였으며

Dense Scripts / Tall Scripts 에 대한 사이즈 또한 명확하게 구성하였다.

- Roboto, Noto Sans CJK KR

영문 표준 시스템 폰트

- 새로워진 Roboto 폰트가 제공되며, 머티리얼 디자인에서의 표준 폰트로 사용된다.

주목받고 있는 'Noto Sans CJK KR' 폰트

- 머티리얼 디자인의 한글 표준 시스템 폰트인 Noto Sans CJK KR 폰트는 총 7개의 폰트로 구성되어 있다.

- http://www.google.com/get/noto/

Noto Sans 폰트를 통해 해외 로컬라이제이션이 편리해졌다.

- 중국과 일본 등을 대상으로 한 폰트도 굉장히 많아 졌으며, 폰트별로 한글과도 동일한 7종의 폰트로 훼밀리를 구성해놓아 현지화시 폰트 차이로 인한 디자인 어려움을 많이 없애준다.

4. 모바일 환경에서의 타이포그래피 기획

- 디자인 가이드 참조

운영체제의 공식 개발자 사이트 내의 관계 페이지 참조한다.

- 폰트는 사례에서 정보를 얻는 것도 중요하지만, 정해진 치수가 있을 수 있으므로 정확한 정보는 각 운영체제의 개발자 사이트에서 관련 섹션의 정보를 얻는다. 또한 비정기적으로 업데이트가 되므로, 필요시 관련 내용을 의무적으로 학습해야 한다. 게임이 아닌 경우, 표준 폰트에서부터 시작하는 것을 권장한다.

가이드보다는 앱이 먼저다.

- 애플의 아이폰은 가이드 문서와 앱에 대한 설명이 유사하게 진행되는 편이나, 구글 안드로이드는 머티리얼 디자인 가이드보다 먼저 선행되어 앱 디자인이 업데이트 되는 경향이 있으므로, 최신 앱의 정보를 얻는 방식도 적절히 맞추어 진행한다.

- 템플릿의 활용

공식 리소스 및 외부 리소스를 적극 활용한다.

- GUI 디자이너들은 포토샵 psd 화일을 통해서 직접적인 정보를 얻기도 한다. 공식 리소스 혹은 비공식 리소스에서 포토샵 화일을 획득하고, 관련 정보는 직접 포토샵 psd 화일에서 얻는다. 사전에 미리 셋팅된 리소스를 활용하면 손쉽게 GUI 디자인이 가능하다.

머티리얼 디자인 리소스 페이지

- 구글 머티리얼 디자인 페이지에는 Resources 섹션이 있는데, 이 곳에서 레이아웃 템플릿, 폰트, 컬러 스와치 등 다양한 공식 리소스를 제공하고 있으므로 반드시 체크한다.

https://www.google.com/design/spec/resources/color-palettes.html

- 타이포그래피 적용

대상, 모바일, 콘텐츠, 비즈니스 목적/의도를 명확히 한다.

- 타이포그래피를 적용할 때는 언제나 프로젝트의 관련 요소들ㅇ르 참조하여 구체화하도록 한다.

일관성의 적용

- 폰트의 사용 또한 일관성 있게 적용되어야 한다. 전체에 일관성 있게 적용하도록 해야한다. 사이즈, 컬러, 두께, 위치 등과 관련하여 규정을 정하게 되면 반드시 따라야 한다. 앱에서는 이제 텍스트가 UI의 역할도 하게 됨에 따라 이러한 점을 따르는 것이 굉장히 중요하다.

12강 레이아웃

1. 레이아웃과 그리드 시스템의 이해

- 레이아웃의 이해

레이아웃의 의미

- 레이아웃과 매체 : 콘텐츠의 배치 / 배열을 뜻하는 레이아웃은 주로 한 화면의 구성을 의미한다. 과거에는 책, 신문, 광고 등의 인쇄 매체를 중심으로 다양한 디자인들을 볼 수 있었으나, 최근에는 디지털 디바이스의 레이아웃이 주요한 관심사와 매체로 집중되고 있다.

- 레이아웃의 의미 : 레이아웃은 내용을 어디에 어떠한 식으로 보이게 만드는 지에 대한 실무적인 작업이다.

 ' 레이아웃은 각 디자인 요소를 전체 미적 계획에 맞춰 한정된 공간에 적절히 배열하는 것이다. 이를 테면 형태와 공간의 경영이다. 레이아웃의 주된 목적은 독자들이 의식적인 노력을 기울이지 않고도 텍스트와 이미지를 받아들일 수 있도록 전달하는데 있다. 결과물이 인쇄물이건 전자 매체이건 간에 훌륭한 레이아웃은 독자들이 복잡한 정보들 가운데 필요한 부분을 쉽게 찾을 수 있다. ' 

'레이아웃'앱브로즈-해리스 지음

- 레이아웃의 고려 사항 : 앞서 학습한 타이포그래피와 동일하게, 대상, 매체, 콘텐츠, 목표와 의도를 고려해야 한다. 이를 통해 대상의 지적 수준, 매체의 특성, 전달하고자 하는 의도와 목적에 따라 콘텐츠를 배치하게 된다.

- 레이아웃에 있어 콘텐츠의 중요성 : 레이아웃에 절대 법칙이 반드시 존재하는 것은 아니지만, 어느 경우에서건 콘텐츠 즉 내용이 우선시 되어야 한다는 사실은 변함이 없다.

- 레이아웃의 한계 : 레이아웃은 이처럼, 디자이너가 표현하고자 하는 콘텐츠를 매체라는 정해진 공간과 방법 안에 의도를 가지고 배치하는 것을 의미한다. 하지만 콘텐츠가 많아지고, 페이지가 많아진다면 레이아웃은 이러한 많은 양을 처리하기에 어려움을 겪게 된다. 즉, 일관성 있고 체계적인 디자인을 위한 기준점이 필요하게 되는 것을 의미한다. 따라서, 이러한 상황에 대해서는, 작업에 있어 질서를 부여하는 그리드가 좋은 선택이 될 수 있다.

- 그리스 시스템의 이해

그리드 시스템의 의미

- 그리드의 정의 : 보이지 않는 가이드라인이라고 설명할 수 있는 그리드는 디자인 작업에 있어 일관성과 질서라는 개념을 더해줄 수 있다.

' 그리드란 주어진 공간에 디자인 요소들을 가장 적절하게 배치하기 위한 도구로써 디자인 결정 과정을 쉽게 해 준다. 그리드는 디자인에 더 체계적으로 접근할 수 있게 하며, 공간 비례나 차수 면에서 구성 요소 배치에 정확도를 높여준다.'                                    '레이아웃'앱브로즈-해리스 지음

- 그리드의 종류 : 그리드는 필요에 따라 단순하게도 복잡하게도 만들 수 있기 때문에 얼마든지 다양한 형태의 그리드가 나올 수 있다. 어떠한 그리드를 적용하건 간에, 디자이너가 디자인 작업을 하는데 있어 일관성과 질서라는 요소를 적용하는 데 있어 도움을 준다면 적합한 그리드라 할 수 있겠다. 크게 나눈다면, 인쇄 매체에 대한 그리드와 디지털 매체에 대한 그리드로 나누어 볼 수 있다.

레이아웃과 그리드 시스템의 이해

- 레이아웃과 그리드 시스템의 이해 : 그리드 시스템은 기준 선이자 가이드라인으로 존재한다. 이러한 그리드를 바탕으로 매체의 페이지 혹은 면에 대한 디자인이 이루어진다. 이러한 구체적 배치 작업을 레이아웃이라 한다. 따라서 그리드 시스템은 구체적인 디자인 이전에 공간에 대한 계획 / 기획과 같다고 할 수 있으며, 레이아웃 작업은 구체적인 배치 작업이라 할 수 있다.

2. 앱과 터치 제스처에 맞는 레이아웃

- 터치 제스처와 앱

모바일의 조작 방식, 터치 제스처

- 터치 제스처의 이해 : 터치 제스처, 즉 '손가락을 사용해서 특정 동작을 수행함으로써, 모바일 디바이스에서 의도한 결과를 얻어내는 조작 방식'이라 할 수 있다. 이러한 터치 제스처는 모바일 디바이스의 주요 조작 수단이며, 데스크톱에서 키보드와 마우스를 통해 조작하는 것처럼, 모바일 앱을 사용하는 방식이다.

- 터치 제스처와 레이아웃의 이해 : 모바일의 조작 방식이 터치 제스처이므로, 그에 맞는 레이아웃으로 모바일의 화면이 구성되었다. 즉, 손가락 터치에 적합한 크기의 버튼과 스위치, 콘트롤러 등으로 콤포넌트 등이 만들어졌으며, 글자의 사이즈 또한 그에 맞추어 정해지게 되었다.

- 운영체제별 터치 제스처를 위한 사이즈 : 아이폰과 안드로이드폰, 각 운영체제별로 이러한 최소 영역에 대한 값이 규정되어 있다.

아이폰 : 44x44point = 99x99px(Retina)

안드로이드폰 : 48x48 dp = 7~10mm

- 실제 디자인에 있어 터치 최소 사이즈의 적용 : 최대한 터치 영역에 권장 사이즈를 따라야 하겠지만, 디자인시 따르지 못하게 되는 경우에는 주변의 영역에 여유 공간을 둠으로써 이러한 문제를 해결할 수 있다. 또는 타업체의 디자인 사례를 통해 해결 방안을 리서치하는 것도 권장한다.

- 앱의 기본 레이아웃

모바일 앱의 기본 레이아웃 구성

- 최소 구성 그리드 : 모바일 앱은 디지털 매체이므로, 동일 디바이스 내에서 보여지는 레이아웃이 계속적으로 변화한다. 또한 가로/세로 변환도 이루어지는 특징이 있다. 그럼에도 불구하고, 기본적인 모바일 앱의 그리드로써의 단위는 다음과 같다.

권장 터치 영역 사이즈가 기준이며, 가로 컬럼(행)이 시작점이다.

- 아이폰 44pt, 안드로이드 48dp 높이의 컬럼을 기준 시작 단위로 볼 수 있다.

- 높이는 높아질 수 있지만, 줄어들게 될 경우 터치에 제약을 받을 수 있다.

- 화면 구성 그리드 : 양측 운영체제에 모두 적용되는 기본 그리드의 개념을 살펴본다.

최상단 : 위치 정보 / 최고 중요 정보

중앙부분 : 콘텐츠 좌우에 16px의 안전영역인 공간이 있다. 각 콘텐츠의 높이는 48px를 기준으로 잡는다.

최하단 : 도구 / 기능 / 네비게이션

최상단과 중앙부분 사이, 중앙부분과 최하단의 사이에는 공간을 띄워둔다.

- 의도적 화이트 스페이스 : 시각적 정보 그룹핑을 위해 의도적 화이트 스페이스는 중요하다.

- 정렬의 효과적 사용 : 화면의 좌측 정렬 영역을 우선적으로 시각의 흐름으로 정보를 파악하는 곳이므로, 위계를 정확히 제공하여 정보의 중요도에 따라 사용자가 정보를 받아들일 수 있게한다.

3. UI 디자인의 이해

- UI 디자인 프로세스

전체 디자인 프로세스 리뷰

- UX-UI-GUI, 각 업무 프로세스 내 UI 디자인의 위치를 확인한다.

↓프로젝트 구성 : 비즈니스 구성

↓UX 디자인 : 사용자 정의

↓UI 시나리오 문서 : 콘텐츠와 레이아웃, 네비게이션

↓GUI 디자인 : 콘셉트, 디자인 스타일, 컬러, 폰트, 형태

UI 디자인 프로세스의 이해

- 요구 사항, 관련 정보의 수합 : 구체적인 요구 사항, 내부 목표, 관련 담당자 미팅 등을 통해 모바일 서비스의 구체적인 목표를 확인하고, 관련 정보를 수집한다.

- 플로우 차트, 인포메이션 아키텍처 등 구성 : 서비스의 흐름, 정보 구조 구성 등의 작업을 통해 구체적으로 앱 내에 포함될 요소와 흐름을 정의한다.

- 페이퍼 와이어프레임스케치 : 제공, 수합, 필요 정보에 근거하여 모바일 화면을 스케치로 그려본다. 경우에 따라서는 페이퍼 / 디지털 프로토타입을 제작하여 테스트 (프로토타이핑) 한다.

- (가능시) 포토샵으로 디지털 와이어 프레임을 제작한다 : 손 스케치는 정교하지 못하므로, (가능시) 포토샵으로 UI 와이어프레임을 디자인한다. 일반적으로는 이 단계에 UI 시나리오 문서를 작성한다. (PPT)

- GUI 디자인 : GUI 디자인은 UI 시나리오 문서에 근거하여 GUI 디자인을 진행한다. 포토샵을 사용하며 디자인 후에는 각 이미지들을 추출하여 개발자들에게 전달한다.

- UI 시나리오 문서의 이해

시나리오 문서의 의미와 역할

- UI 시나리오 (기획 문서) : 콘텐츠와 레이아웃, 그리고 페이지 간의 네비게이션을 구체적으로 표현한 문서이며 일반적으로는 기획 문서라고 총칭하기도 한다. 이를 기반으로 GUI 디자인이 이루어지므로, 실제 GUI 디자이너는 이 문서를 충분히 이해하고 GUI 디자인으로 해석할 수 있어야 하겠다. 경우에 따라서는 본 문서에 간략하게 정의한 사용자 정의 앱의 목적 등을 넣기도 한다.

- UI 시나리오 (기획 문서) 사례 - 소개 페이지 : 서비스 소개, 비즈니스 목적, 사용자 정의 등은 이렇게 간략하게 표현하기도 한다.

- UI 시나리오 (기획 문서) 사례 - IA : 인포메이션 아키텍처를 첨부한 문서의 모습

- UI 시나리오 (기획 문서) 사례 - 페이지 레이아웃 : 페이지 레이아웃은 아래와 같이 디테일하게 설명을 포함하여 작성한다.

UI 디자인 패턴의 개념

- UI 디자인 패턴의 정의 : 디자인 패턴이라는 용어는, 이전에 누군가가 해결해놓은 사례를 참조하여 내가 진행하는 업무에 활용하여, 내가 가진 문제 / 상황을 해결하는 것을 의미한다. UI 디자인 및 GUI 디자인시 이러한 디자인 패턴의 개념이 있으면 좀 더 적절한 레이아웃을 구현할 수 있다.

- UI 레이아웃의 범주화 및 리서치 : 페이스북 타임라인 외에도 다양한 타임라인 디자인이 존재하는 것처럼, 내가 작업하는 페이지가 어느 패턴에 속하는지를 먼저 파악한 후, 그에 맞는 페이지들을 리서치하여 최종 작업물에 그러한 내용을 반영하는 것을 의미한다.

13강 UI 시나리오 문서의 이해와 GUI 디자인

1. UI 시나리오 문서와 GUI 디자인

- UI 시나이로 문서의 해석

UI 시나리오의 해설

- GUI 디자이너의 입장 : 실제 업무에서 GUI 디자이너가 작업하는 영역은 컬러, 타이포그래피, 이미지, 형태 정의 등과 같이 시각 디자인에 대한 부분이다. 그러나, UI 시나리오는 단순히 콘텐츠가 어떠한 레이아웃에 배치되어 있는지, 어떠한 네비게이션의 구조로 구성되어 있는지를 보여주는 문서이다. 따라서 이러한 문서를 보고 GUI 디자이너가 적절히 해석하고, 필요에 따라서는 적극적으로 UI 디자이너와 의견을 교환하는 것을 권장한다. 이에 본 챕터에서는 UI 시나리오의 해석 및 GUI 디자인의 적용에 대해 알아보도록 하겠다.

- UI 시나리오 사례 : 아래의 사례를 보고 UI 시나리오 문서를 해석하는 몇 가지 내용을 이해한다. 

- 와이어프레임 : 이미지는 네모에 X자로 선을 그은 형태를 의미, 아이콘은 동그라미, 아바타는 동그라미안에 사람 형태를 그린다. 파워포인트로 문서를 작성하는 게 일반적인 방식이다.

- 기획 중심의 레이아웃 및 구성 : 일반적인 경우, 기획 의도가 우선시되므로 폰트의 사이즈가 가독성에 맞지 않게 작거나, 아이콘이 터치 하기에 너무 좁거나 작게 배치되는 경우가 있을 수 있다.

- 시각적 일관성은 GUI 디자이너의 몫 : UI 시나리오에 있는 아이콘의 시각적 통일성과 일관성은 GUI 디자이너가 해결해야 한다. 즉, 아이콘의 두께나 모서리의 반경과 같은 부분 등은 GUI 디자이너가 맡아서 작업한다.

- GUI 디자이너도 UI 시나리오 문서에 참여한다. : UI 시나리오 문서에 대해 GUI 디자이너에게 전달 사항이 발생하거나, 공유할 경우에는 GUI 디자이너도 문서에 의견 등을 기입할 수 있어야 한다.

- GUI 레이아웃 디자인의 적용

GUI 디자인 작업의 이해

- 픽셀 단위 작업 : GUI 디자인의 레이아웃 작업은 UI 시나리오 문서를 픽셀 단위로까지 구체화하는 단계이다. 따라서, 정확한 단위로 결정해야 하며 UI 디자인을 시각적으로 굉장히 세밀하게 구현해야 한다.

- 통합적 vs 세부적 작업 : 이전에 학습한 내용과 같이, 전체의 통합적 관점에서의 굿 디자인과 세부적 관점에서의 굿 디자인이 이루어져야 한다. 즉, 컬러, 타이포그래피, 레이아웃, 이미지, 아이콘 등 여러가지 요소들이 어우러져야 하면서도 부분적으로 정확한 역할을 해야 한다.

- 모바일 운영체제의 가이드라인을 숙지해야 한다. : 모바일 운영체제에 다양한 컴포넌트와 콘텐츠 디자인 가이드가 존재한다. UI 기획 문서를 참조하여 GUI 디자인을 진행하면서도, 필요에 따라서는 UI 디자이너에게 더 나은 컴포넌트에 대한 이야기를 해줄 수도 있다.

- 운영체제별 고유의 이미지 구현 방식에 대해 숙지한다. : 안드로이드의 나인패치 방식으로 이미지를 작업하는 방법, 아이폰의 오토 레이아웃에 대한 디자인 등, 운영체제별로 이미지를 화면에 구현하는 방식이 다르다. 따라서, 운영체제별로 후반 디자인 작업이 어떻게 이루어지는지 사전에 확인하고 GUI 디자인을 진행한다.

- 결정한 GUI 일관성은 모든 페이지에 적용해야 한다. : 컬러의 쓰임, 아이콘의 형태, 레이아웃의 사용 등 GUI의 모든 시각적 작업들은 모두 동일하게 적용되어야 한다. 만약 웹, 데스크톱 프로그램까지도 디자인하게 된다면, 이러한 점들이 다른 운영체제, 다른 매체에도 적용되어야 한다.

- 스마트폰을 모니터로 사용해야 한다. : 데스크톱 모니터에서 보여지는 화면은 실제 모바일 앱과 차이가 확연히 날 수 밖에 없으므로, 기준 디바이스로 정해진 스마트폰을 통해 GUI 디자인 결과물을 확인해보도록 한다.

2. GUI 리서치 및 무드 보드 작성

- GUI 리서치

GUI 리서치의 이해

- GUI 리서치의 필요성 : 앱 디자인을 할 경우 대다수의 GUI 디자이너들은 별다른 리서치 없이, 바로 포토샵을 통해 디자인을 진행한다. 이전에 학습한 UI 시나리오 문서를 한 쪽에 띄워두고 그대로 포토샵에서 작업을 진행한다. 그렇지만 GUI 디자인은 픽셀 단위의 작업으로 여러 가지 시각 디자인의 요소들이 반영된 결과물이다. 그래서, 실제 작업시 고민되는 부분들이 많이 나오면서 작업 중에 고민을 하게 되고, 대부분은 직접 해결하려고 한다. 하지만 시간이 많이 걸리고 결과물이 좋지 않게 나오는 경우가 많다. 이러한 경우에 GUI 리서치를 진행하면 많은 도움을 받을 수 있다.

- GUI 리서치의 의미 : 리서치는 내가 알지 못하는 대상에 대해 알고자 하는 관련 정보를 습득하는 것을 의미한다. 그리고 이러한 것들을 직접하는 것보다, 주변의 실제 사례를 통해 문제 해결의 실마리를 찾을 수 있다. 단지 기획 파트 뿐만 아니라, GUI 디자인도 리서치를 통해 많은 정보를 얻을 수 있다.

- GUI 리서치가 필요한 상황 : 

Q : 내가 알지 못하는 페이지의 형태를 UI 시나리오 문서에서 발견하였는데, 어떻게 디자인해야 하는가?

Q : 모바일에서 잘 쓰이지 않는 방식의 멀티 테이블 형태인데, 다른 앱에서는 어떻게 디자인했는가?

Q : 터치 제스처에 어떤 시각 반응을 보이는가?

Q : 경쟁사의 앱들은 디자인을 어떻게 하였는가?

Q : 우리 프로젝트도 동일한 콘텐츠를 다루고 있는데, 메인 페이지를 어떻게 차별화 할 수 있는가?

Q : 메인 페이지에서 장문의 텍스트, 웹 링크를 표현할 때, 어떠한 컬러와 폰트 사이즈를 적용하고 있는가?

Q : 운영체제별 GUI 디자인을 어떻게 대응하고 있는가?

- 무드 보드 구성

무드 보드

- 무드 보드의 의미 : 무드 보드는 이미지, 텍스트, 샘플들을 조합해서 만들어 진다. 디자이너들이 일반적으로 작업하는 데 있어, 영감을 얻거나 구체적인 사례가 필요한 경우에 모아서 콜라주 하는 방식으로 진행을 한다. 직접적인 연관이 없더라도 무드 보드에 모아놓은 이미지 등을 통해 나의 디자인 작업에 반영하는 데 의의가 있다.

- 무드 보드의 구성 : 실제로 출력해서 붙여도 좋고, 파워포인트에 콜렉트 해도 좋다. 다만 한 곳에 모여져 있어야 하고 특정 주제로 묶여 있어, 필요시 바로 찾거나 참조할 수 있어야 한다.

- 무드 보드 디지털 툴 : 무드 보드를 위한 다양한 디지털 툴들이 많이 출시되어 있으니 필요에 따라 다양한 툴을 사용해보고 자신에게 맞는 방식을 적용하는 것을 권장한다.

Pinterest, Mural.ly

3. 디자인 스타일 가이드 문서 작성

- 디자인 스타일 가이드의 이해

디자인 스타일 가이드의 필요성

- 내부 스타일 가이드 문서 없이 GUI 디자인시 발생하는 문제점 : 대부분은 별다른 문서를 제작하지 않고, 포토샵에서 psd 화일 안에 실제 폰트, 컬러 등을 적용하여 작업을 진행한다. 그러나 페이지가 많아지고 디자이너가 많아지고, 기간도 길어진다면 작업하는 도중에 최초의 설정 값과 형태 등은 변하게 되며, 어느 순간 기준점을 상실하게 된다.

- 스타일 가이드의 역할 : 스타일 가이드를 디자인의 기준점으로 활용할 수 있다. 구체적인 표현을 하자면, 실제 디자이너들이 작업할 때 참조하는 작업 지시서, 또는 CI 브랜드 가이드와 유사하다고 보면 된다. 따라서 나중에 참여하는 디자이너 등도 해당 문서를 참조하면 디자인을 일관성 있게 디자인할 수 있으므로, 장기적으로 프로젝트에 큰 이익이 된다.

- 스타일 가이드의 형태와 내용 : 구체적인 스타일 가이드에 대한 표준은 없고, 필요에 따라 여러가지 방식으로 작성한다. 문서 정리 방식, psd 화일을 별도의 스타일 가이드로 구성하는 방법 등 다양한 방법이 가능하다. 이 안에는 폰트의 사이즈, 인터랙션에 대응하는 버튼의 단계, 아이콘의 종류와 응용, 앱에 사용되는 각종 컴포넌트들이 구체적으로 쓰여있다. (psd 화일일 경우는 가져다 쓸 수 있도록 정리가 되어있다.)

-  디자인 스타일 가이드 참조

psd 디자인 스타일 가이드 참조

GRID (Landing Page, Portal)

COLOR PALETTE (#000000~#FFFFFF)

TYPOGRAPHY (Headers, Body)

FORMS (Empty, Selected, Typing, Select, Error, Success)

BUTTONS

AVATARS (Big / Middle / Small Size)

ICONS (Landing Page, Portal, Artists/Albums/Activity, Rank, Voting, Social Media)

UI ELEMENTS (Calendar, Slider/Tooltips, Pag nator, Tag-Tooltip,Drop Down Menu, Read more, Move/Hide)

ALERT/ERROR MESSAGES(Info파랑, Warning노랑, Error빨강, Success녹색)

LOGIN

14강 GUI 리서치 프로세스

1. 주요 카테고리별 마켓 리서치

- 애플 앱 스토어

아이폰의 앱 마켓, 애플 앱 스토어

- 애플 앱 스토어는 모바일 앱 마켓 중 최고 퀄리티의 앱들이 있는 곳으로써, 애플 아이폰, 아이패드, 아이팟 앱 및 다양한 콘텐츠를 판매하고 있는 마켓이다.

- apple.com/kr/itunes 를 통한 아이튠즈 다운로드 애플 앱 스토어는 아이폰, 아이패드, 아이팟이 있을 경우, 모바일 내의 앱 스토어 아이콘을 통해 방문할 수 있으며, 맥 컴퓨터에도 기본적으로 아이튠즈를 통해 iOS 앱 스토어에 방문이 가능하다. 만약 윈도우즈 컴퓨터를 사용한다면, 위의 링크로 들어가서 별도의 아이튠즈를 설치한다면, 윈도우즈에서도 애플 앱스토어에 들어갈 수 있다.

국내, 국외 마켓 탐색 

- 한국 앱 스토어 리뷰 : 아이튠즈 설치시, 디폴트로 한국 앱 스토어를 볼 수 있다. 한국 앱 스토어는 한국 내의 순위로만 집계되므로 이러한 점들을 체크한다.

- 국외 앱 스토어 리뷰 : 아이튠즈 앱 스토어 내 우측 하단에 국가 아이콘이 있다. 해당 아이콘을 누르면 나라별로 앱 스토어를 방문할 수 있다.

애픞 앱스토어 리서치 

- 목적별 리서치 진행 : 구성 카테고리, 제공 순위 리스트, 특별 이벤트, 이벤트성 리스트 등 앱스토어에서 제공하는 전반적인 구성과 앱 리스트를 체크한다. 진행 프로젝트가 있다면, 해당 앱이 어떤 카테고리에 속하는지 확인하고 관련 앱들도 리서치 진행한다.

- 키워드별 리서치 진행 : 국내/국외 리서치를 진행할 수 있으며, 진행 프로젝트에 따라 연관 키워드를 다양하게 검색을 해본다.

- 구글 플레이

구글 안드로이드 공식 앱 마켓, 구글 플레이

- play.google.com 혹은 구글 플레이 앱 : 웹사이트 play.google.com 혹은 안드로이드 폰에 설치되어 있는 구글 플레이 앱을 통해 앱 마켓에 방문이 가능하다. 아이폰과 달리 해외 마켓에는 방문할 수 없다. 구글 플레이에서도 앱 외의 다양한 콘텐츠를 판매하고 있다.

구글 플레이 리서치 

- 구성 및 키워드 리서치 : 애플 앱 스토어와 마찬가지로, 앱 마켓에서 제공하는 순위, 리스트 등을 리서치하고 키워드에 따른 리서치를 진행한다.

- 모바일 vs 데스크톱 리서치

매체별 리서치의 장단점

- 소개 : 모바일 리서치는 각 운영체제별 앱 마켓에 들어가서 관련 앱에 대한 내용을 확인하고 다운 받아서 사용해보는 것을 의미하고, 데스크톱 리서치는 앱 마켓리서치와 웹 리서치를 의미한다. 각 장단점을 간략히 확인한다.

- 모바일 리서치 : 직접 앱을 다운 받아서 확인하는 방법인 모바일 리서치는, 실제 앱을 사용해보는 측면에서 제일 권장하는리서치 방법이나, 시간이 많이 걸리는 단점이 있다. 또한, 해당 디바이스가 없을 경우에는 앱을 설치해서 사용해 볼 수가 없다. 스마트폰은 개인용 기기의 성격을 지니고 있기 때문에, 주변 사람들에게 부탁해서 사용해보기에도 애매하다.

- 데스크톱 리서치 : 실제 자료를 정리하고 작성할 수 있는 데스크톱에서 리서치를 하는 건, 우선 편리하기 때문이다. 다만 앱 마켓도 아닌, 일반 웹사이트에서 관련 정보나 스크린 샷 등을 찾는 것은 자제해야 한다. 앱의 변화 속도를 일일히 웹사이트에서 확인할 수가 없으므로, 앱 마켓 방문 위주로 리서치를 진행해야 한다.

2. 운영체제별 GUI 디자인 대응

-  요구 사항 분석

UI 시나리오의 요구 사항 분석

- 담당자 미팅 : GUI 디자인에 앞서 실제 기획한 담당과 미팅하여 GUI 디자인에 대한 의견을 묻는다. 참조 혹은 경쟁 서비스 등의 리서치와 관련된 정보를 요청하여 기록한다. UI 시나리오 중 컬러, 타이포그래피, 레이아웃과 관련된 직접적인 질문을 하여 불명확한 부분을 구체화하고 의견을 맞춘다. 운영체제별 디자인 대응과 관련하여 별도의 의견이 있는지를 확인하는 것도 중요한 부분이다.

- UI 시나리오 숙독 : UI 시나리오를 체크하며 각 페이지를 이해한다. 주요 콘텐츠를 다루고 있는 페이지 등, 각 페이지별로 어떠한 디자인 패턴에 속하는지 확인한다. (메인 페이지 = 타임라인, 서브페이지 = 프로필등) 시각 디자인과 관련하여 별도의 요구 사항이 있는지 확인하고 시나리오에서 이해가지 않는 부분이 있다면 메모하여 담당자에게 질문한다. 최종적으로 리스트를 만들거나, 해당 문서에 구체적인 질문과 진행 방향 등을 적어서 커뮤니케이션 한다.

- 리서치 구조화

리서치 항목 도출

-  결과 종합하여 수행 리스트 작성 : 구체적으로 리서치를 진행하기 위해 수행 리스트를 작성한다. 어떠한 마켓을 방문할 것이며, 어떤 키워드와 카테고리를 검색할 것인지, 디자인 패턴은 어떠한 부분에 대한 리서치가 필요한 지 등을 구체적으로 수행 리스트를 작성한다. 해당 리스트는 필요에 따라 3자와 공유하기도 하고, 본인만 참조하기도 한다.

리서치 앱 리스트 업

- 참조 희망 앱 체크 및 리서치 : 담당자의 참조 앱 리스트, 앱 마켓의 카테고리, 키워드 서치 등을 통해 앱을 리서치하며 리스트를 구체화한다. 해당 앱을 다운 받아서 리뷰하고, 필요에 따라서는 스크린샷을 캡처하여 별도 보관한다.

- 디자인 패턴 관련 앱 체크 : 디자인 패턴 관련 앱은 동일 카테고리와 연관 검색어로 보여지지 않을 수도 있다. 예를 들어, 현재 프로젝트가 커피 관련 앱이지만 그 안에 결제 쇼핑 관련 페이지에 대한 리서치 요구 사항이 있을 경우, 직접적인 커피 앱이 아니더라도 쇼핑 전문 앱을 리서치하여 해당 부분에 대한 디자인을 확인하는 것을 의미한다. 이 경우는 평상시에도 많은 관심을 가지고 앱을 많이 써보았을 경우에 더욱 유리할 수도 있다. 그렇지만 실제 프로젝트 시점에서 트랜드, 디자인의 변화가 있을 수 있으므로 반드시 새롭게 다운로드 / 업데이트하여 관련 부분을 체크한다.

- 운영체제별 비교

멀티 디바이스, 멀티 운영 체제

- 원 서비스, 멀티 플랫폼, 멀티 디바이스의 대응 : 2015-2016년에 들어서면서, 대다수의 모바일 앱 서비스는 멀티 플랫폼, 멀티 디바이스의 개념이 도입되었다. 이에 하나의 서비스라면, 어떤 채널, 매체를 통해서도 동일한 서비스를 받을 수 있는 환경이 구축되었다고 할 수 있다. 이에 디자이너 또한 흐름을 이해하고 동참할 수 있어야 한다.

- GUI 디자인과 멀티 디바이스, 멀티 운영체제 : 간략하게 말하자면, 아이폰 앱과 안드로이드폰 앱을 얼마만큼 다르게 혹은 동일하게 가져갈 것인지를 고민해야 한다는 뜻이다. GUI 디자이너는 운영체제별 디자인 가이드를 숙지하고, 그에 따른 시각 디자인 요소들을 명확히 알아야 하지만, 다른 운영체제 간의 조화를 찾기란 사실 쉬운 일은 아니다.

- 멀티 운영체제에 대한 GUI 리서치 및 분석 : 작업하는 운영체제의 앱을 직접 써보고, 스마트폰을 나란히 늘어놓고 앱을 써보며 비교 분석해보는 것이 좋다. 각 페이지별로 어떠한 디자인 패턴에 속하는지 살펴보고, 해당 페이지가 운영체제별로 어떠한 구성을 이루고 있는지에 대해 3~5개의 앱을 리서치 한다면 구체적인 방향을 알아낼 수 있다.

3. 콘텐츠별 UI/GUI 디자인 구성 원칙의 이해

- 데이터 중심

데이터 중심 앱의 구성 원칙

- 데이터 중심 앱은 제일 많이 볼 수 있는 형태이다. 이메일, 페이스북, 트위터, 채팅창 등이 데이터 중심 앱을 제일 잘 표현해주는 앱이다.

- 구성원칙 : 

스크롤 가능하게

폰트는 한정적으로 사용

손가락 터치 사이즈 반드시 고려 

OS 기본 디폴트 사이즈 고려 

가독성 필수

그래픽적 완성도 더욱 추구

콘텐츠와 조작부 간 명확히 구분

- 이미지 중심

이미지 중심 앱의 구성 원칙

- 이미지 중심 앱은, 사진과 동영상을 주로 다루는 앱을 의미한다. 카메라, 유튜브, 인스타그램 등이 해당 앱이라 할 수 있다.

- 구성원칙 : 

화면을 최대한 넓게 사용 (최대화), 

가로 모드 지원, 

핀치 인/아웃 = 줌/인 아웃 지원

화면 터치할 경우 컨트롤 부 숨김/노출

스와이프로 콘텐츠 네비게이션

콘텐츠 중심의 화면 구성

- 게임

게임 앱의 구성 원칙

- 게임 앱은 일반 앱과 완전 별개의 앱으로 구분하는데 고유의 재미 요소가 필수적이다.

- 구성원칙 :

수준 높은 그래픽 비주얼

일관성

비주얼 스타일의 통일성

1강 사용자경험(UX)의 개념과 이해

1. 사용자 경험(UX)의 정의와 중요성

- 사용자 경험(UX)이란?

사용자 경험(UX)이란, 총체적(holistic)관점으로 그 경험의 작용대상과 인간의 반응으로 이해한다.

- 사전적 정의

사용자 경험(User Experience, UX)은 사용자가 어떤 시스템, 제품, 서비스를 직간접적으로 이용하면서 느끼고 생각하게 되는 지각과 반응, 행동 등의 총체적 경험을 말한다.

- UX 대상과 사용자의 지각과 반은

사용자는 경험의 대상과 지각반응을 통합적으로 인지하고, 구매와 지속적 사용행위를 하게 된다.

- 대상 : 제품, 시스템, 서비스, 회사, 브랜드 등으로 확장된 경험 대상

- 지각반응 : 감정(felling), 태도(attitude), 행동(behavior)의 총합

- UX의 이해와 관점

- 이해와 해석 : 사용자경험 요소와 현상을 어떻게 해석하고 사용자를 이해할 수 있는가?

- 관점 : 사용자에 대한 관점을 넓혀 보다 풍부한 사용자경험 가치를 창출할 것인가?

- UX란 

ICT기술과 모바일 환경에서 다양한 사용 행태를 관찰, 해석하고, 실제 사용자의 경험을 이해하여 잠재 니즈의 발견은 물론, 모바일 서비스에 접목할 수 있는 사용자 인사이트와 사용자 가치를 만들어내는 방법론으로 이해할 수 있다.

- UX 이해의 복잡성

- 주관성(subjectivity) : 인간의 경험은 그 사람의 개인적, 신체적, 인지적 특성에 따라 주관적이다.

- 맥락성(contextuality) : 사용자 경험이 일어나는 상황적 의적 환경에 영향을 받는다.

- 총체성(holistic) : 경험 시점에서 개인이 느끼는 총체적인 심리적, 감성적 결과이다.

2. UX에 대한 이해와 관점

- UX의 이해와 관점

①인지적 관점(Cognitive)

- 인간의 기억과 생각하는 구조의 이해

- 인간이 어떻게 하나의 정보를 받아들여 인지하고 처리하는가?

②사용자 맥락과 상황(Context)

- 경험 발생 상황과 외적 영향

- 사용자는 컨텍스트의 영향으로 외부 환경과 어떤 관계적 경험을 형성하게 되는가?

③감각과 감성(Emotion)

- 역동적이고 다면적인 감각능력과 경험발생 시점에서의 심리적 상태와 변화의 이해

- 어떻게 느끼는가?

④사용자 행위(Behavior)

- 제품, 서비스 경험의 물리적, 인지적, 사회문화적 현상의 해석과 상호작용

- 어떻게 행동하는가?

- 사용자 경험(UX)의 영역

- 사용자 경험(UX)은 특정 영역(domain)을 갖기보다 기존의 다양한 분야와 결합되는 새로운 틀을 제공하는 접근으로 확장되고 있다.

- 단순하게 인터페이스만이 아니라, 제품, 시스템, 서비스, 회사 등 사용자가 특정 포인트를 중심으로 경험할 수 있는 대상이 확장된다.

- 사용자경험(UX)의 중요성

- UX의 이해(사용자를 이해하고 공감하기 위한 사고방식)

UX는 특정 제품과 서비스에 내재되어 있는 개념이 아니라 사용자(User)에 귀속된 개념으로 이해해야 한다.

사용자 경험 가치의 창출은 사람(유저)을 얼마만큼 이해하고 있는가에 달려 있음

- UX디자이너의 역할 : 경험의 기회 제공

UX디자이너는 사용자로 하여금 특정한 경험을 할 수 있도록 경험의 기회를 사용자에게 제공할 수 있어야 한다.

3. 사용자 경험 요소

- 사용자(User)

- 사용자, 과연 그들은 누구인가?

사용자(user)는 어떤 목표와 의도를 가지고 특정 컴퓨터나 시스템(모바일 기기) 등을 사용하며 능동적이고 가변적인 욕구를 가지는 주체다.

- 사용자는 어떤 욕구의 소유자인가?(인간의 본질적 욕구 측면)

Ex) 개인 프라이버시에 민감하며, 사회적 소속감을 중시

- 사용자가 궁극적으로 원하는 것은 무엇인가?(기능적 측면)

Ex) 자신의 개인정보를 친한 지인에게만 안전하게 공유할 수 있는 자신만의 공개 기능

- 사용자 경험(UX)의 기본 요소

- 사용자 경험(UX)을 명확하게 규명하기 위해서는 니즈(User Needs) 이외에 사용동기(Motives), 태도(Attitudes), 사용행태(Behavior)의 기본 구성요소에 대한 구체적인 분석이 필요하다.

사용자 니즈(User Needs) : UX 대상(제품/시스템/서비스)으로부터 특정한 만족감을 얻으려는 사용자들의 기대

사용동기(User Motives) : 사용자들의 행동을 불러일으키는 직접적인 발화제

사용자 태도(User Attitude) : UX 대상에 대해 갖는 개인의 취향과 선호, 선험적인 믿음과 정보

사용자 행위(User Behavior) : UX 대상을 사용하는 과정에서 드러나는 반복적인 행동패턴

4. 모바일 환경과 UX

- 모바일 사용자의 경험의 주요 요소

- 모바일 환경의 이해

모바일 분야는 전방위 산업 분야로 확산되고 있으며, 각 분야 개별 컨텐츠와 플랫폼, 그리고 디바이스를 중심으로 유기적 연결과 통합을 지속하고 있음

- 사용자 관점에서 모바일UX의 라이프사이클

The APP LIFECYCLE

Stage1. The App Store Experience (구매경험)

Stage2. The First-Open Experience (첫인상)

Stage3. Attempting Simple Tasks (단순조작경험)

Stage4. Attempting Complex Tasks (복잡조작경험)

- 모바일 UX의 환경과 영향 요소

사회문화적 환경과 사용자, 사용자의 의도와 목표, 사용자 태스크, 인터페이스와 인터랙션, 모바일  기기(H/W) 연결 속성과 성능, 통신사와 서비스 ... etc (매우매우 미시적부터 거시적까지 다양하다)

2강 모바일앱 환경의 이해와 UX의 중요성

1. 모바일앱(App) 환경 특성의 이해

- 모바일앱(App)의 개념

모바일앱이란?

- 특정 모바일 OS에서 구동되는 애플리케이션(application, 응용프로그램)을 의미한다.

- 스마트 폰에서 애플리케이션(앱)은 특정 용도에 따라 설치되는 컴퓨터의 응용프로그램과 같다.

- 앱을 스마트폰으로 직접 다운로드하여 설치할 수 있는 서비스를 제공하는 곳이 앱 마켓(app market) 또는 앱 스토어(app store)다.

모바일앱 환경의 이해

- 모바일앱(App)의 종류와 특성

- 네이티브 앱(Native App) : 네이티브앱은 모바일OS 제조사에서 제공하는 개발언어를 이용하여 각가의 고유 모바일 OS에서만 동작되는 앱(App)을말한다.

Ex. 자바(Java)로 개발하는 안드로이드앱과 Objective-C 언어로 개발 되는 아이폰앱.)

- 네이티브앱의 장단점

- 모바일 웹(Mobile Web) : 모바일 웹(Web)은 모바일에 최적화된 웹사이트라고 할 수 있고, 디바이스 별 별도의 개발 방식이 필요하지 않으며, 인터넷에 접속이 가능하다면 어떠한 모바일 디바이스로도 접속이 가능하다.

 모바일 웹(Web)은 데스크탑 브라우저에서 실행되는 기능을 모바일 기기 환경에 맞춰서 개발한 사이트이다. (PC용 홈페이지가 모바일 화면으로 보여지는 것)

- 모바일 웹의 장단점

- 하이브리드 앱(Hybrid App) : 하이브리드앱이란 모바일웹(Mobile web)의 홈페이지를 구현하는 웹기능과 앱(App)의 어플기능을 접목시킨 형태로, 네이티브앱과 모바일웹의 장점을 혼합한 앱이다.

 하이브리드앱은 네이티브앱의 형태를 띄고 있어 앱스토어나 마켓에서 다운받아 모바일에 설치할 수 있다.

- 하이브리드앱의 장단점

2. 모바일 사용자경험(UX)의 속성과 특징

- 모바일 사용자행태적 속성

편재성(Ubiquity) : 어디서든 정보검색과 통신이 가능한 이동성(모빌리티)을 구현해 공간성의 제약을 해소.

즉시연결성(Instant connectivity) : 언재 어디서나 사용자가 원하는 즉시, 해당 정보검색과 통신이 가능

개인화(Personalization) : 사용자 개인의 선호와 취향 등 개인 특성에 맞춘 콘텐츠 및 보안 인증 제공.

위치기반(Localization) : 사용자의 현재 위치를 파악하여 주변의 유용한 정보를 제공이 가능

- 모바일 사용자경험의 주요 특징

단순 간결한 경험을 선호

- 사용자 목표와 의도에 연관된 직관적인 UX요소들의 중요성이 PC의 비해 상대적으로 강함.

- 정보에 대한 복잡한 선택 상황을 꺼려함.

다른 사용자와의 소통에 개방적이고 자신의 현재 주변 환경과 교감하고자 함.

- 타인과의 커뮤니케이션 매체로써 PC에 비해 다른 사용자와 교류에 적극적임.

- 정보의 선택, 공유, 평가, 저장, 편집 등에 더 적합한 경험이 형성됨.

- 모바일의 이동성과 위치기반 특성으로 내 주변 상황에 민감함.

새로운 형태의 UX에 비교적 쉽게 적응

- 이미 학습된 모바일 UX/UI 환경에서 새로운 기능과 서비스를 배우는데 쉽게 적응함.

- 스마트기기의 새로운 기능/서비스를 경험을 하고자하는 기대가 자연스럽게 형성됨

새로운 정보제공이나 추천 서비스에 개방적임

- 일상에서 모바일 기기와의 상호작용 시간이 길고, 양방향 인터랙션 경험에 익숙함.

- OS 별 지속적인 앱의 업데이트 환경에 익숙함

- 사용자가 원하고 있는 정보가 사용자의 상황에 맞게 제공되는 방식에 익숙함

3. 모바일UX 특성을 반영한 UI 설계 시 주안점

- 디자인 측면

Desirable : 매력적인 디자인

얼마나 감성적으로 쓰고 싶게끔 디자인 되어 있는지?

Credible : 디자인 신뢰성

어떤 디자인적 요소들이 사용자의 신뢰도의 영향을 미치는지?

Usable : 사용하기 쉬운 사용자 인터페이스(UI)

사용자의 목푤를 달성하기 위해 제공된 인터페이스가 얼마나 쉬운지?

- 정보설계 측면

UseFul : 유용한 기능과 콘텐츠

사용자에게 정말로 필요한, 또는 문제해결을 할 만한 기능과 컨텐츠인가?

Accessible : 접근성의 극대화

누구나 쉽게 접근할 수 있도록 디자인되었는가?

Findable : 정보 탐색 경ㄹ(Navigation)의 일반화

사용자가 필요한 정보와 기능을 쉽게 찾을 수 있게 UI가 설계되었는가?

Valuable : 사용자 만족도

사용자가치가 어떻게 전달되어 만족도를 높일 것인가?

3강 사용자 인터페이스의 개념과 이해

1. 사용자인터페이스(UI)의 정의와 이해

- 사용자인터페이스(UI, User Interface)란?

사용자 인터페이스(UI)는 사람들이 컴퓨터, 시스템, 기기, 도구 등 그 사이에서 일어나는 상호작용(Interaction)을 매개하는 것이다.

- 사람(사용자)과 사물 또는 시스템, 기계, 컴퓨터 등, 그 사이에서 의사소통을 할 수 있도록 일시적 또는 영구적인 접근을 목적으로 만들어진 물리적, 가상적 매개체를 뜻한다.

- 사용자인터페이스는 디스플레이 화면, 키보드, 마우스, 문자, 아이콘, 도움말 등 사용자들과 상호 작용을 하도록 설계된 모든 정보관련 고안품을 포함하여, 응용프로그램이나 웹사이트 등이 상호 작용을 초래하거나 그것에 반응하는 방법 등을 의미한다

- 사용자 인터페이스(UI)의 목적

사용성(usability)는 사용자인터페이스의 주된 목적

- 좋은 사용자 인터페이스는 심리학과 생리학에 기반하여, 사용자가 필요로 하는 요소를 쉽게 찾고 사용하며 그 요소로부터 명확하게 의도한 결과를 쉽게 얻어 낼 수 있어야 한다.

사용자 인터페이스는 상호작용 수단과 방식을 제공

- 입력(I) : 사용자가 시스템을 조작할 수 있게 한다.

- 출력(O) : 시스템이 사용자가 이용한 것에 대한 결과를 표시한다.

- 사용자 인터페이스(UI)의 구분(종류)

상호작용 수단과 방식에 따른 사용자인터페이스의 구분

- CUI(Character based UI) : 문자 방식의 명령어 입력 사용자 인터페이스

- GUI(Graphic UI) : 그래픽 환경 기반의 마우스 입력 사용자 인터페이스

- NUI(Natural UI) : 사용자의 말과 행동 기반 제스쳐 입력 인터페이스

2. 모바일 UI 디자인의 기본 설계 원칙

- 사용자인터페이스 기본 원칙

직관성(Intuitiveness)

앱의 구조를 큰 노력 업이도 쉽게 이해하고, 쉽게 사용하게 해주는지

→ Findability / Ease of use / Consistency

유효성(Efficiency)

얼마나 정확하고 완벽하게 사용자의 목표가 달성될 수 있는지

→ Feedback / Effectiveness

학습성(Learnability)

초보와 숙련자 모두가 쉽게 배우고 사용할 수 있게 해주는지

→ Easy of learning / Accessibility / Memorability

유연성(Flexibility)

사용자의 인터랙션을 얼마나 포용하고, 실수로부터 방지해주는지

→ Forgiveness / Error Prevention / Error Detectability / Error-averse

- 사용자인터페이스 설계 지침-10원칙(한국HCI연구회)

가시성의 원칙(Visibility)

앱의 주요기능(feature)을 노출시켜 최대한 조작이 쉽게 되도록 한다.

조작결과 예측의 원칙(Natural Mapping)

사용자가 앱을 조작하여 작동시킨 결과를 조작 부위만 보고도 미리 예측가능하게 설계해야 한다.

일관성의 원칙(Consistency)

앱의 조작방식에 일관성을 제공함으로써 사용자가 쉽게 기억하고 빠르게 적응할 수 있게 한다.

단순성의 원칙(Simplicity)

앱의 기능구조를 단순화 시켜 조작에 요구되는 노력을 최소화하여 인지적 부담을 줄이게 한다.

지식배분의 원칙(Knowledgein World & Head)

앱의 기능 조작에 요구되는 지식은 사용자의 지식과 기억 구조에 적합하도록하여 학습하기 쉽고 기억하기 쉽게 상호 보완적으로 배분한다.

조작오류의 원칙(Design for Error)

발생된 오류는 쉽게 발견될 수 있도록 하고, 오류의 수정 또한 최대한 쉽게 이루어져야 한다.

제한사항 선택사용의 원칙(Constraints)

앱의 조작 상의 제한사항을 이용하여 가능한 선택의 여지를 줄여 조작방법이 명확하도록 한다.

표준화의 원칙(Standardization)

앱의 기능구조와 디자인을 표준화하여 한번 학습한 이후 효과적으로 사용할 수 있도록 한다.

행동유도성의 원칙(Affordance)

사용자에게 앱의 기능을 어떻게 조작하면 될 것인가에 관한 단서(cue)를 제공함으로써 조작의 가능성을 높인다.

접근성의 원칙(Accessibility)

사용자의 성별, 연령, 인종 등에 따른 다양한 계층의 사용자를 수용할 수 있도록 고려해야 한다.

3. 좋은 UI의 특징 및 관련 원칙들

- 화면의 구성관련

조직성 + 일관성

- 조직성은 사용자에게 일관성 있는 개념적 구조를 제공

- 일관성은 사용자가 예측할 수 있는 UI를 반영하여 용이성을 향상

간결성 + 명료성

- 간결성이란 커뮤니케이션을 위해 꼭 필요한 요소만을 디자인

- 사용자에게 한 번에 너무 많은 기능을 제공하지 않음

- 디자인된 모든 요소들의 의미가 모호하지 않고 명료해야 함

- 감성, 인지적 품질 관련

가독성 + 시인성

- 너무 많은 버튼이 디스플레이 되거나 너무 복잡한 아이콘은 사용자에게 부담을 줄 수 있음

- UI를 바로 보고, 그 의미를 혼동 없이 쉽게 읽고 정확하게 이해할 수 있어야 함.

접근성 + 관용성 : 다양한 사용자 고려

- 불특정 다수의 사용자도 시스템 UI에 접근할 수 있도록 하고, 동시에 다양한 사용자의 문화적, 언어적 차별이 없이 사용자 요구를 반영해야 함

- 사용성 관련

메타포 + 피드백

- 현실세계의 대상물들(도구)을 메타포로서 인터페이스에 옮겨 놓은 아이콘들은 직관적 사용성에 효과적으로 작용한다.

- 메타포의 활용은 문화적, 언어적 장벽들을 자연스럽게 극복하게 해준다.

- 피드백은 사용 결과와 반응의 대화를 이끌어낸다.

- 작업을 수행 할 때 반응(피드백)은 가능한 한 즉각적으로 제공하여 시각적 혹은 청각적 신호로 제공해야 한다.

- 사용자에게 시스템이 무슨일이 일어나고 있는지를 피드백을 통해 계속 알려 주어야 한다.

4강 사용자 인터랙션(Interaction) 디자인 이해

1. 인터랙션(Interaction)의 의미와 이해

- 인터랙션(InteractioN)이란?

인간이 제품이나 서비스를 사용하면서 상호간 작용하는 것

- 컴퓨터에 의해 작동되는 전자 제품, 시스템 환경과 사용자의 행동간의 상호작용 또는 상호 영향성을 의미

- 인간과 인간, 인간과 물질, 인간과 시스템, 시스템과 시스템 간 상호작용이 일어나는 방법 또는 양식

- 인터랙션의 목적

인터랙션 디자인 : 사람 - 기기 간 커뮤니케이션 관점 = '대화(dialogue)'

- 인간이 제품이나 서비스를 사용하면서 상호작용하는 방식 또는 양식을 보다 용이하게 디자인하는 분야

- 인터랙션 디자인은 사용자 간 커뮤니케이션뿐만 아니라 서로 간의 행위 소통 자체를 위한 디자인

- HCI(Human-Computer Interaction)

HCI는 과학과 인문학 사이의 인터페이스

- 컴퓨터 시스템과 상호작용의 연구 분야

- 시스템을 사용하는 인간(사용자)의 특성을 이해하는 분야

- 사용자와 컴퓨터 사이를 잇는 사용자 인터페이스에서 발현

HCI의 목적

- 스마트환경에서 제품과 서비스의 최적 경험

- 궁극적인 목적은 사용자의 의지를 보다 자유롭게 하고, 창의력을 증진시키고, 인간 사이의 의사소통과 협력을 증진시킴.

2. 사용자의 행동모델과 인터랙션 디자인

- 사용자 행위 단계와 좋은 인터랙션 디자인

- 사용자의 목적과 그것을 달성하기 위해 할 수 있는 행위 간의 차이가 작아야 함.

- 원래 목적과 실행 결과 간 차이가 적어야 함.

사용자는 어떻게 사고(think)하고 사용행위(behavior)를 하는가?

- 도널드 노먼의 7단계 행동 모델(Donald Norman's 7 Stage of Action model)

사용자가 달성하고자 하는 목표에 도달하기까지의 의도와 행동-기대결과-해석과 평가-피드백의 과정(행위이론

1. Forming the Goal (목표)

목표는 막연히 얻고 싶은 것으로, 매우 부정확한 형태로 나타날 수 있다.

→ 스마트 디바이스의 기능이 결정되었는가?

2. Forming the Intention (의도)

막연한 목표에 의도나 계획이 있고, 구체적으로 어떤 목표인지 분명히 진술한다.

→ 어떤 조작이 가능한가?

3. Specifying an action (행동 단계 설정)

의도에 맞는 정확한 행동 단계를 구체적으로 진술한다.

→ 의도와 행동과의 대응관계(매핑)는 정해졌는가?

4. Executing an Action (실행)

실제적인 무엇인가를 실행하는 단계로 실제 결과물을 내어 놓는다.

→ 행위의 수행이 가능한가?

5. Perceiving the state of the world(지각)

실제로일어난 일에 대해서 지각하고 이해한다.

→ 대상인 시스템이 어떤 상태에 있는지를 알 수 있는가?

6. Interpreting the State of the world (지각의 해석)

실제로 일어난 일에 대해서 지각하고, 인식한 것에 대한 감각을 해석한다.

→ 시스템의 상태와 해석의 대응(피드백)이 결정되었는가?

7. Evaluating the Outcome (결과 평가하기)

수행 결과와 원하던 목표에 대해 비교와 평가를 한다.

→ 사용자가 원했던 목표와 시스템의 결과가 잘 맞아 떨어지는가?

3. 모바일 인터랙션 디자인의 구성 요소

- 사용자 목표와 행위, 결과의 차이(gap)를 줄여주는 요소

심성 모형(Mental model)과 개념모형(Conceptual model)

- 심성 모형 : 사용자가 생각하고 행동하는 구조를 설명하는 개념

- 개념 모형 : 사람이 시스템과 제품 등의 개념을 이해하려고 머리 속에 만드는 모형

매핑(Mapping)

- 행위와 실제 조작, 결과가 대응하는 것으로 시스템 상태가 눈에 보이도록 대응관계를 확정해야 함

- 사용자가 모바일 기기를 조작해 작동시킨 결과를 조작 부위만 보고도 미리 에견, 또는 기능적 유추할 수 있도록 하는 것.

메타포(Metaphor)

- 메타포는 어떤 것을 머리에 떠올릴 때 직관적으로 반응하는 느낌과 해석을 의미한다.

- 인터랙션 디자인은 눈으로 보기만 해도 (직관적), 사용자는 기기의 상태와 가능한 여러 행위들을 파악 가능해야 한다.

어포던스(Affordance, 행동유도성)

- 어포던스(Affordance)는 어떤 행동을 유도한다는 뜻으로 행동유도성이라고도 한다.

지각된 어포던스의 4가지 원리(도날드노먼)

- 이미지들의 선택과 허용 가능한 상호작용 양쪽에서 일반적으로 익숙한 사용법을 따르라

- 사용자가 원하는 행동을 묘사하는 단어를 사용하라

- 메타포(Metaphor, 은유)를 사용하라.

- 인터페이스를 학습한 이후 이것을 다른 부분에 활용할 수 있도록 지속적으로 같은 컨셉 모델을 따르도록 하라

피드백(Feedback)

- 피드백은 어떤 작동이 실제로 이루어졌는지 어떤 결과가 달성되었는지에 대한 정보를 사용자에게 알려주는 것이다.

- 사용자의 행위 결과에 관한 충분한 피드백을 지속적으로 받을 수 있어야 한다.

5강 사용성의 이해와 사용성 평가의 활용

1. 사용성(Usability)의 정의와 중요성

- 사용성(Usability)란?

사용자가 어떤 도구를 특정 목적을 달성하기 위해 사용할 때에 어느 정도 '사용하기 쉬운가(easy to use)'를 말한다.

사용자들이 목표를 이루기 위해 특정한 상황에서 사용하는 시스템, 제품 또는 서비스에 대한 유효성(effectiveness), 효율성(efficiency), 만족도(satisfaction)의 정도(ISO)

- 사용성의 이해

사용성은 사용자와 컴퓨터간에 일어나는 상호 작용에서 경험하는 '사용의 품질'을 의미한다.

유효성 (Effectiveness)

- 사용자가 원하는 목적을 제대로 달성하였는가?

- 사용자 요구에 적합하고 안정적이고 신뢰성이 있는 제품

효율성 (Efficiency)

- 사용자가 원하는 목적을 가능한 편리하게 수행하였는가?

- 사용 방법을 학습하기 쉽고 사용자의 실수를줄여주는 제품

만족도 (Satisfaction)

- 전반적인 사용 만족도는 어떠하였는가?

- 사용자의 감성적, 경험적인 성향에 부합하는 제품

- 야콥 닐슨(Jakob Nielsen)의 사용성 지침

①알기 쉬운 시스템 상태(Visibility of system status

- 절절한 피드백을 통해 적절한 반응시점에 사용자에게 "시스템마다 무슨 일이 일어나고 있는지"를 알 수 있게 해야 한다.

②실제 사용 환경에 적합한 시스템(Match between system and the real world)

- 사용자의 실제환경과 유사한 친숙한 단어와 문구, 개념 등을 사용하여 자연스럽고 논리적인 정보를 제공해야 한다.

③사용자에게 자유와 주도권 제공(User control and freedom)

- 사용자가 시스템의 기능 선택에서 실수를 하거나 원치 않는 상태로부터 확실한 실행 취소 및 재실행 기능을 제공해야 한다.

④일관성과 표준화(Consistency and standards)

- 동일한 상황에서 상이한 버튼, 피드백, 아이콘 등으로 UI의 일관성을 해쳐 사용자에게 혼란을 주어서는 안된다.

⑤오류 예방(Error prevention)

- 오류가 발생하기 쉬운 조건을 제거하거나 조건을 설정할 수 있는 사용자에게 작업을 취하기 전에 확인 옵션을 제공해야 한다.

⑥기억을 불러오지 않고 보는 것만으로 이해할 수 있는 디자인(Recognition rather than recall

- 시스템을 사용하기 위한 설명은 언제든지 적절할 때 볼 수 있거나 쉽게 찾을 수 있어야 한다.

⑦유연성과 효율성 (Flexibility and effciency of use)

- 사용자가 자주 실행하는 기능은 사용자가 직접 효율화를 조정할 수 있도록 한다.

⑧심플하고 아름다운 디자인(Aesthetic and minimalist design)

- 사용자의 의도와 달성목표를 수행하는 과정에 불필요하거나 상관없는 정보는 제거하고 심플한 디자인을 구현할 수 있어야 한다.

⑨사용자가 오류를 인식하고 진단하고 복구할 수 있도록 지원(Help users recognize, diagnose, and recover from errors)

- 오류 메시지는 쉽게 이해되어야 하며, 문제 상황을 정확히 알려주고, 그 해결책 또한 제공해야 한다.

⑩도움말과 설명서 준비(Help and documentation)

- 어떤 정보든 쉽게 찾을 수 있고, 사용자의 행위에 초점을 가지고, 수행할 구체적인 단계가 나열되고, 분량이 너무 많지 않아야 한다.

- 사용성(Usability)의 속성과 원칙

사용성은 사용자 경험의 구성요소 중 하나로 다양한 하위 속성을 포함하고 있다.

2. 사용성 평가 원칙과 절차

- 사용성 평가(Usability Evaluation)의 정의와 목적

사용성 평가는 제품과 시스템의 복잡하나 기능들을 사용자가 보다 쉽고 편리하게 조작할 수 있도록 사용자 인터페이스를 개발 또는 개선하기 위해 문제점을 찾아 내고 개선안을 발굴하는 과학적 조사과정이다.

- 신규 또는 기존의 특정 제품, 시스템, 서비스의 기능에 대한 사용자측명의 평가와 일련의 과정

- 제품과 시스템의 복잡한 기능에 대해 사용자가 보다 쉽고 편리하게 사용할 수 있도록 사용자 인터페이스 등에 대한 사용 측면의 평가와 개선

- 사용성 평가(Usability Evaluation)의 절차(3단계)

사용성 평가는 제품 및 시스템의 완성단계에서 시행되므로 주로 수행 데이터(performance data)분석을 통해 검증 결과를 도출해 낸다.

1단계 - 태스크 시나리오(task scenario) 수행과 측정 및 기록

실제 사용 상황을 가정해 미리 작성된 태스크 시나리오에 맞춰 기기 조작을 실행한다. 수행 시간, 수행도, 특이사항, 주요 오류 유형을 측정하고 기록한다.

2단계 - 사용자 만족도를 평가와 개선, 보완 사항 발굴

제품에 대한 사용자 인터페이스의 주요 구성 요소 별 사용자 만족도를 평가해 해당 제품의 사용성을 높이기 위해서 우선적으로 개선 보완해야 할 요소를 발굴한다.

3단계 - 문제점의 개선, 보완하기 위한 새로운 아이디어 탐색(반복)

주요 사용상 오류의 원인을 진단하고 이를 개선 및 보완하기 위한 아이데이션(ideation)을 진행하고, 향후 사용자 인터페이스 개발을 위한 새로운 아이디어를 탐색한다.

- 사용성 평가 항목과 측정지표

3. 사용성 평가의 활용

- 사용성 평가의 장점 및 중요성

사용성 평가는 상세한 문제점 진단 및 개선 방향을 제시할 수 있다.

사용성 평가를 통해 제품, 시스템 또는 서비스를 사용하는 인간의 행동에 대해 구체적으로 정리하기 때문에 단계별로 상세한 문제점 발견을 가능하게 하고, 같은 측정 방법을 기준으로 기존 제품 또는 경쟁 제품과의 비교를 통해 개선의 가능성을 평가할 수 있다.

사용성 평가는 문제점의 진단과 발견된 이슈의 중요도 판단에 도움을 준다.

사용성 평가를 통해 제품, 시스템 또는 서비스의 문제점의 진단에서 나아가 발견된 이슈의 중요도를 판단할 수 있다고, 문제의 우선순위에 따른 문제점과 개발 이슈의 제공으로 결정권자의 빠른 판단을 가능하게 한다.

- 사용자 경험(UX)과 사용성(Usability)의 관계

사용성은 사용자경험의 품질

사용자 경험(UX)은 도구적 품질(사용성, 유용성), 비도구적 품질(심미성 측면, 상징성 측면)의 인지에 대한 감정 반응이며 상호작용 하면서 시스템 특성, 사용자 특성 및 컨텍스트는 큰 영향을 미친다. 또, 사용자 경험의 실제 결과는 이 모든 것의 종합적인 것.

- 말크(Mahlke, 2007)

제품이나 서비스의 도구적 품질의 인지 요소인 유용성과 사용성

비도구적 품질의 인지 요소인 심미성과 상징성

유용성, 사용성과 심미성, 상징성에 대한 종합적 결과인 감정반응

6강 사용자중심디자인(UCD)

1. 사용자중심디자인의 개념과 중요성

- 사용자중심디자인(UCD, User Centered Design)의 개념

디자인적 문제해결 과정

- 사용자 중심 디자인(UCD)은 사용자를 중심으로 사고하여 만들어 내는 인터페이스, 서비스, 제품 디자인의 철학적 접근 방법이자 디자인 사상이다.

- UCD의 최종적 단계에서의 결과물인 디자인은 '인간(사용자)의 편의와 가치의 실현에 초점'을 맞추게 된다.

사용자중심디자인과 사용자 인터페이스

- UCD는 사용자가 무엇을 할 수 있고', '무엇을 원하고', '무엇을 할 필요가 있는지에 따른 사용자 인터페이스(UI)의 최적화를 통해 사용자중심디자인 가치를 현실화하는 노력에 있다.

사용자의 이해가 최우선이 되는 디자인 방법론

- 개발과정에 사용자가 개입, 사용자 테스트가 중요시되는 디자인 방법론

- 사용성과 직접적으로 결부된 인간 요소(human factor)연구에 기반을 둠

- 심성모형, 행동유도성 등의 개념을 바탕으로 사용자를 이해하고 디자인에 반영

사용자중심디자인의 중요한 원칙

- 실체 제품을 사용하는 최종 사용자에 집중한다

- 요구 사항과 디자인을 사용자와 함께 검증한다

- 디자인, 프로토타입 제작, 새발을 반복적으로 수행한다.

- 전체적인 사용자 경험을 고려한다.

2. 사용자중심디자인의 구성요소

- 사용자중심디자인의 핵심가치

사용자

사람들이 진심으로 바라고 원하는 것은 무엇인가?

사용 편의성(usability)

다양하고 복잡 다기능화 되어가는 스마트기기의 사용자가 보다 사용이 편리한 제품과 서비스를 디자인해야 하는 필요성

사용자 참여 디자인(participatory-design)

디자인 단계별로 실제 사용자들을 참여시켜서 설계와 검증을 진행, 제품의 기획과 설계 등 모든 단계에서 사용자를 참여시켜서 확인하고 그들이 쉽게 사용할 수 있는 제품을 만드는 것이 사용자중심디자인의 핵심

- 사용자중심디자인의 특징

사용자의 개발 절차의 개입

- UCD는 철저하게 사용자에 초첨이 맞춰어져 있다.

- 사용자의 경험적(empirical)정보를 이용하여 그들이 원하는 디자인 요구사항을 도출한다.

반복적 디자인과 다양한 분야의 협력

- 사용자의 피드백, 테스트 등을 통해 제품과 서비스는 개발과정에서 수많은 평가 개선의 반복과정을 거친다.

- 사용자의 이해가 중요하기 때문에 심리학, 인류학, 문화, 언어 등 인문사회학적 접근과 협력이 요구된다.

3. 사용자중심디자인 프로세스의 이해

- 사용자중심디자인 프로세스의 기본 원칙

사용자의 참여와 반복적 사용자 평가

- 단계 정의보다 각각 사용자 개입이 어떻게 이루어지는가가 중요

- 사용자의 요구를 만족하는 시스템 디자인

- 사용자의 이해와 프로토타입을 통한 디자인에 대한 반복적 사용자 평가와 개선

- 사용자중심디자인 수행 단계

사용자 이해 단계

- 사용자의 행동과 태도를 파악하고, 그들이 원하고 필요로 하는 것이 무엇인지 찾아낸다.

→ FGI, 필드리서치를 통한 사용자 조사 실시

인터랙션 정의 단계

- 사용자 조사를 통해 얻은 결과를 바탕으로 사용자 프로필을 만들고 정보 구조와 작업 구조를 정의한다.

→ 사용자 요구사항을 정의하고 전반적인 인터랙션 구조를 파악

UI 디자인 단계

- 개략적 컨셉에서 구체적인 설계까지 사용자와 함께 다양한 프로토타입을 평가하면서 디자인을 완성해가는 단계이다

→ 다양한 수준의 프로토타입을 만들어 사용자를 참여시켜 평가를 반복한다 (저수준/고수준 프로토타입 제작)

사용자 검증과 평가 단계

- 프로토타입 작성이 완료된 후 개발의 진행과 완료 시 필요한 평가를 수행하는 단계다.

→ 프로토타입이 실제 개발 가능한지 검토하고, 내부의 UI가이드라인과 OS나 제조사에서 제공하는 디자인 가이드라인이 지켜졌는지 점검한다

개발 완료 단계

- 실제 개발된 제품을 대상으로 사용성 테스트를 진행한다.

- 개발이 완료되고 출시된 이후에는 사용자 반응을 파악한다.

→ 제품 출시 후에도 사용자 피드백을 지속적으로 수집하고 사용자 중심의 혁신 과정을 반복해야 제품의 경쟁력을 지속적으로 높일 수 있다.

7강 UX시나리오

1. UX 시나리오의 이해

- UX 시나리오

UX 시나리오는 구체적인 미래 시점의 상황에서 사용자가 겪을 경험을 예상해보는 도구이다.

- UX 시나리오의 목적과 활용

- 미래의 사용자가 무엇을 원하고 필요로 하는지와 제품서비스가 추구하는 사용자 가치에 대한 통찰력을 반영한다.

- UX 시나리오의 목표와 범위 내에서 사용자(고객)의 환경과 현상, 그리고 그들이 처한 문제점에 대한 진단 및 해결 방향을 설정하는 과정을 통해 제품과 서비스 이면에 숨겨진 사용자 경험가치의 본질을 찾아가는 과정이다.

- 사용자 경험의 속성과 흐름을 파악할 수 있다

- 미래의 불명확한 사용 상황을 보다 구체화하기 위한 도구이다.

- 미래의 사용자가 무엇을 원하고 필요로 하는지에 대한 제품서비스 검증의 단계이다.

- UX시나리오는 구체적인 사용자와 컨텍스트를 정의하고, 사용자 행위 중심의 태스크(task)를 정의하여 상호작용 방식을 구체화하기 때문에 정보구조, 인터랙션 디자인 등의 UI 설계에 유용하게 활용된다.

2. UX 시나리오의 유형과 장단점

- 페르소나(Persona) 기법

가상의 사용자

- 페르소나는 '가상의 인물(Persona)'을 통해 그들 사용자들의 이용행태와 제품, 서비스에 대한 니즈(Needs)에 주목하여 이를 서술적으로 정의하는 기법이다.

- 목표 사용자를 보다 면밀하게 분석하기 위해, (가상)사용자들을 특정한 기준에 따라 분류한 뒤, 이들 각각의 사용자 유형들을 가공의 캐릭터 또는 프로필 등으로 표현하는 기법이다.

장점

- 사용자를 집중해서 분석하도록 해준다.

- 사용자에 대한 감성적인 이해를 도와준다.

- 효과적으로 사용자를 알게 해준다.

- 페르소나를 작성하게 되면, 사용자는 하나의 동일한 유형으로 존재하지 않고, 이용환경(Context)이나 성별/연령별/직업별 특성, 제품에 대한 기대, 니즈, 동기, 태도, 이용행태 등이 다르다는 것을 발견하게 된다.

- 유저 스토리(User story)

사용자 리서치의이해도 향상

- 리서치 결과는 가장 특징적인 이야기들만 담겨져 있기 때문에 모든 사용자의 모든 경험을 대변할 수 없다.

- UX 디자이너는 리서치 결과를 보다 풍성하게 꾸며서 다른 이해관계자들에게 효과적으로 설명할 필요가 있는데, 이 때 사용하는 방법이 사용자 스토리이다.

구성 요소

- 사용자들은 이런 사람이다.

- 사용자들은 이럴 때 제품을 이용한다.

- 사용자들은 제품을 이렇게 이용한다.

- 사용자들은 제품 이용 시에 이런 갈등을 겪는다.

- 사용자들은 제품에 대해서 이런 니즈를 가지고 있다.

- 니즈에 부합하는 디자인 아이디어가 반영되어도 된다.

- 사용자 여정맵(Journey Map)

시간의 흐름에 따른 사용자 경험의 파악

- 사용자 여정맵은 사용자들이 수행하는 제품/서비스 이용흐름을 조망하고 문제를 발견하는 데 탁월한 툴이다.

- 미리 해당 제품(서비스)을 분석하고 Journey Map을 그려봄으로써 예상되는 사용자들의 이용 경험을 모형화해 볼 수 있다.

특징

- 사용자의 긍정, 부정을 나타내어 부정을 긍정으로 끌어올리며, 효과적인 서비스 설계가 가능함

장점

- 사용자 여정의 의도적인, 의도하지 않은 측면을 이해하는데 도움을 줌

- 서비스의 실제 그리고 일상적인 터닝 포인트를 밝힐 수 있음

- 필요 없는 단계와 중복되는 수고에 대해 파악할 수 있음

3. UX 시나리오의 작성 방법론

- 페르소나 기반 UX 시나리오 작성

페르소나 기법의 장점

- 예측하기 힘든 수 많은 사용자에 대한 동기, 욕구, 패턴을 구체적으로 요약, 제시함

- 다양한 프로젝트 구성원들이 의사 결정을 할 때 그 기준으로 작용함

- '사용자는 이렇게 생각할 거에요.' 라는 주관적 예측을 줄임

- 사용자의 기술적 수준에 대한 시각차를 좁힘

- 특정한 사람을 위해 디자인한다는 느낌을 가질 수 있음

- 사용자에 대한 관점을 여러 부서 사이에서 계속 일치시킬 수 있음

페르소나 기반 UX 시나리오 작성 가이드

- 동기 : 사용자가 얻으려고(의도/목표) 하는 것

- 니즈 : 목표 달성을 위해 사용자가 필요로 하는 것

사용전 - 사용과정 - 사용 후

- 페르소나가 서비스를 어떻게 사용할 것인지에 대한 설정

- 페르소나가 서비스를 사용하기 전에 어떤 정보를 알고 있을지 정의

- UX 시나리오는 페르소나의 다음 행동이 어떤 것인지 명시해야 함

- 사용자 여정맵 작성

여정맵 기법의 장점

- 여정맵은 실제 사용자의 서비스 경험을 시각적으로 재현해보는 맵으로 사용자의 긍정적, 부정적 반응을 나타냄

- 여정을 맵핑하는 것은 서비스들을 이해하고 서비스와 사용자와의 갭, 개선과 혁신의 디자인적 기회를 알아보는데 가장 심플하고 유용한 접근임

- 사용자 여정맵은 사용자들이 경험하게 될 서비스의 인터랙션과 제스츄어, 터리 포인트들로 구성됨

여정맵 작성 가이드

- 서비스 이용전 / 이용 중 / 이용 후로 구분한다.

- 사용자의 컨텍스트를 고려해 가로축을 설계하고, 세로축은 사용자의 긍부정을 표현한다.

- 지나치게 복잡해지지 않도록 하고, 선형 그래프로 한눈에 전체 경험을 조망할 수 있돌고 한다.

- 되도록 그림 이미지를 활용한다.

- UX 시나리오의 요소

동기/계기와 의도(Motivation & intention)

- 사용자 행동이 일어나게 되는 직접적인 이유(목표)

사용자 행위(User Interactivity)

- 사용자 인터랙션/인터페이스에 대한 사용자 행동패턴

기대 결과의 평가와 해석(Evaluation & Interpretation)

- 의도 / 원했던 목표와 실행 결과의 평가와 인식/감각적 해석

기억과 태도(Memory & Attitude)

- 결과에 대한 만족/불만족 수준의 기억-다음 행동 영향을 주는 요인

- 사용자 경험의 흐름과 요소

사용자에게 형성될 UX의 구조와 요소를 파악

- 사용자에게 어떤 동기로 작용, 특정 행동을 야기하여, 기대(의도)에 대한 평가와 해석, 기억과 태도로 이어지는 경험 흐름의 구조

사용자 경험의 흐름 파악

동기/계기와 의도(Motivation & intention) → 사용자 행위(User Interactivity) → 기대 결과의 평가와 해석(Evaluation & Interpretation) → 기억과 태도(Memory & Attitude) → 동기/계기와 의도(Motivation & intention)

- UX 시나리오 작성 가이드(6단계)

User definition : 목표 사용자는 누구인지?

(User definition) 사용자(고객)은 누구인지?

- 사용자의 성격, 선호, 라이프스타일, 직업, 가치관 및 태도 등으로 사용자 정의

User needs/problem : 사용자에게 제공하고자 하는 UX는 무엇인지?

(Needs/Problem) 사용하는 가장 큰 이유는?

- 해당 제품서비스가 해결, 또는 제공하고자 하는 혁신적인 사용자니즈 정의

Context of use : 사용자는 어떤 상황에서 사용하게 되는지?

(Context of Use) 어떤 상황에서 사용하는지?

- 사용환경과 상황-시간, 장소, 또는 특정 이벤트 등 사용의 전후 맥락을 정의

Key-function : 제품서비스의 주요 기능은 무엇인지?

(Function) 어떤 기능 때문에 사용하는지?

- 사용자가 사용하게 될 제품서비스의 핵심 기능 정의

User task-flow : 사용자는 해당 기능을 어떤 방식으로 사용하게 되는지?

(User Task Flow) 그 기능을 어떻게 사용하는지?

- 사용자가 인터페이스와 인터랙션 방식 등을 실행하는데 있어서 하나의 목적을 달성해 나가는 경로나 과정

User value/benefit : 사용자가 최종적으로 얻게되는 UX 가치, 또는 편익은?

(Benefit/Value) 그래서 어떤 의미가 있는지?

- 사용자가 해당 제품의 기능과 서비스를 이용하는 가장 큰 이유(why)와 만족의 수준 정의

8강 사용자분석 방법론

1. 사용자의 정의와 특성의 이해

- 사용자(User) 정의

사용자, 과연 그들은 누구인가?

- 사용자(user)는 어떤 목표와 의도를 가지고 특정 컴퓨터나 시스템(모바일 기기)등을 사용하며 능동적이고 가변적인 욕구를 가지는 주체다.

사용자는 어떤 욕구의 소유자인가? (인간의 본질적 욕구 측면)

Ex. 개인 프라이버시에 민감하며, 사회적 소속감을 중시

사용자가 궁극적으로 원하는 것은 무엇인가?(기능적 측면)

Ex. 자신의 개인정보를 친한 지인과만 안전하게 공유할 수 있는 자신만의 공개 가능

- 사용자(User)의 종류

주사용자(primary users)

- 사용자분석의 주요 대상이 되는 사용자 그룹을 말하며, 특정 목적을 달성하기 위해 시스템이나 컴퓨터를 통해 스스로 정보처리를 하거나 기능을 이용하는 사람

부사용자(secondary users)

- 실제로 시스템을 사용하는 사람은 아니지만, 주사용자가 시스템을 어떻게 사용하는가에 영향을 주거나 받는 사람들

구매자로서 사용자(users as buyer)

- 실제로 시스템이나 기기를 구입하는 과정에서 결정권을 행사하는 집단

- 비즈니스환경에서는 구매자와 사용자 간에 매우 다른 목표, 특성 그리고 행동양식이 존재한다.

관리자로서 사용자(user as manager)

- 실제 사용자와는 다른, 조직 내에서 실질적으로 조직의 일을 관리하는 사람들

- 사용자(User)의 특성

행태적 특성(behavioral attributes)

- 상호작용성과 관련된 행태 : 자주(빈도), 정기적으로, 또는 집중해서 오랫동안, 일시적인 상호작용

- 정보와 관련된 행태 : 얼마나 많이, 얼마나 복잡한가에 대한 정보를 대하는 행태

- 기능과 관련된 행태 : 검색 기능, 이미지처리, 저장, 편집, 공유 기능 등에 관한 행태

개인적인 특성(personal attributes)

- 성격적인 특성

- 신체적인 특성

- 문화적 특성

- 동기적인 특성

사용자의 숙련 정도

- 초보자

- 중급자

- 숙련가

- 전문가

2. 사용자 분석 방법론

- 사용자분석(user analysis)의 목적과 중요성

사용자 분석은 왜 해야 하는가?

- 사용자의 욕구, 인지적 특성, 행동양식 및 상황을 고려해 제품/시스템/서비스 설계에 반영한다.

- 사용자로 하여금 학습 없이도 시스템에 대한 정보를 충분히 얻을 수 있고 쉽게 제품/기능을 사용할 수 있게 하기 위함이다.

사용자 분석 대상 '사용자의 어떤 특성을 어떻게 정리할까?'

- 사람 자체에 대한 사용자(user) 분석'

→ 보편적 인간 중심 -who, when, where

- 사람 행동에 대한 '사용자 행동과 경험(UX) 분석'

→ 특정 제품서비스 사용자 행태 중심 - how, what, why

사용자 분석의 중요성

- 사람이 생각하고 행동하는 과정은 복잡하고 이해하기 어렵다.

- 어떤 사용자를 위한 제품, 시스템을 개발할 것인지를 명확하게 파악해야 그 사용자들에게 최적의 경험을 제공하는 제품, 시스템을 개발할 확률이 높아진다.

- 사용자분석은 사용자 요구와 선호도를 파악하고 그 개발 제품서비스의 시장적합성을 높이는 절차이다.

- 사용자 분석 3단계 - 역할 모형을 중심으로

1단계 : 사용자 분석의 대상이 되는 조사주세를 선정하고 참여자들을 선정하는 단계

- 실제 사용자를 대표할 수 있는 사람, 조직 내 사용자와 가장 접촉이 많은 부서 관계자로 선정팀 구성

- 성별/연령별, 교육/소득수준, 지역적/문화적/언어적 특성, 취미 등 분석 대상 사용자 리스트 작성

- 사용자 선발 질문지 작성 - 해당 시스템이 성격에 알맞은 주제에 대한 구성원 모집 목적

- 사용자 분석 절차의 확정 - 사용행태, 숙련 정도, 개인적 특성을 확인 할 수 있는 적합한 방법 선정

2단계 : 선정된 사용자들을 대표하는 소수의 사람들을 대상으로 한 역할 모형(user role model)의 구조 선정

- FGI(Focus Group Interview) 기법을 활용한 조사 주제의 확정과 역할 모형 구조 선정

- 역할 모형 - 역할은 사용자와 시스템간의 관계에 초점 (욕구, 필요, 관심사항, 기대수준, 사용 행태 등)

- 한 사람이 특정 시스템에 여러 가지 역할을 수행, 또는 여러 사람이 한 시스템에 동일한 역할을 수행

- 정리 및 보고서 작성 → 역할 지도(role map)의 작성

3단계 : 실제 역할 모형에 들어가는 상세한 사용자의 프로파일을 파악하는 단계

- 사용 가치 프로파일 : 기능적 가치, 유희적 가치, 사회적 가치, 개인적 가치

- 사용성 속성 프로파일 : 효율성, 정확성, 일관성, 유연성, 의미성

- 감성 프로파일 : 정서와 미적 인상 및 개성

- 숙련도 프로파일 : 해당 분야 지식, 시스템 지식, 기기 지식 수중

- 사용 행태 프로파일 : 상호작용과 관련하여 사용 빈도와 강도, 복잡도

- 사용자 분석의 중요성

사용자 요구사항이나 필요성이 제대로 반영되지 않은 시스템 개발은 심각한 오류를 발생할 수 있다.

- 사용자가 아니면, (개발자 자신은) 실제 시스템을 사용한 과정에서 겪게 되는 문제점이나 시스템을 이용하는 궁극적인 목적 등을 알아낼 수 없다.

사용자 분석은 개발 초기 뿐만 아니라 제품, 시스템 개발의 전체 단계에 걸쳐 점진적이고 반복적으로 이루어야 한다.

- 그 이유는 시스템이 개발되어 감에 따라 사용자가 원하는 바와 사용자가 불편을 느끼는 점이 역동적으로 바뀌기 시작하면서 점점 더 자신이 원하는 사양과 불편한 점에 대해서 구체적으로 이야기 할 수 있기 때문이다.

3. 사용자 분석의 주요 기법

- 사용자 분석 도구와 기법

성공적인 사용자 연구를 위해서는 대상이 되는 사용자와 시스템의 목적, 상황을 명확히 한 뒤, 이에 따른 각 사용자 연구방법들의 장단점을 잘 이해하고 최적의 방법론을 선택해야 한다.

- 설문조사(questionnaire) / 서베이(*survey)

- 가장 널리 사용되는 니즈 분석기법으로 대표적인 정량조사 기법

- 조사의 효율성을 위해 모집단을 대표하는 표적 집단을 추출하고 조사하는 표본조사

- 일지 연구(diary study)

- 일상생황에서 사용자에게 일정 형식의 일지를 제공하고,

- 사용자 스스로 수행하는 일이나 생각, 감정 등을 카메라 등의 매체로 기록

- 장시간 연구 가능하고, 시각적 정보를 쉽게 얻을 수 있다.

-  단, 사용자 동기에 따라 얻을 수 있는 정보가 크게 달라지는 단점(인터뷰 보완)

- 포커스 그룹 인터뷰(FGI)

- 사용자가 경험한 내용을 포커스 그룹 인터뷰를 통해 개방적 토의를 진행하고, 그 자료를 분석하는 질적 조사기법

- FGI의 장점은 저비용으로 대상으로 부터 필요한 정보를 빠르게 얻을 수 있다.

- 또한 그룹 내 시너지 효과도 얻을 수 있다.

- 다만, 대상자 수가 적어 대표성이 떨어지고 사회적 조정(moderation) 능력에 좌우되는 면이 있다.

- 라이프스타일 분석(AIO 분석)

- 시장 세분화를 위한 클러스터링(clustering)기법의 일종

- 소비자의 생활양식에 의한 시장세분화를 하기 위한 방법으로, 소비자 생활양식은 AIO(Activity, Interest, Opinion)의 척도로 측정된다.

- 사용자가 어떤 시간을 보내고(A), 어떤 일을 중시하며(I), 어떤 견해를 갖고 있는가(O)를 척도로 나타내어 수치화한다.

- 사장에 대한 풍부한 정보를 주는 반면 세분화의 경계가 모호해 측정이 어려울 수 있다는 단점이 있다.

- 시나리오 분석(scenario analysis)

- 미래에 나타날 수 있는 여러 가지 모습들을 일관성과 논리성을 갖춘 상태에서 제시하는 것 (Michael Porter, 1985)

- 이 기법은 아이디어의 발상 및 기회 포착에서부터 완제품의 사용 환경, 기술, 목적에 이르기까지 디자인 프로세스 전반에 걸쳐 적용이 가능한 미래예측기법

- 시나리오 플롯을 구성할 때 대안적인 미래들이 분기하기 시작하는 시점에서 줄거리를 결정하는 것

- 귀납적 방법과 연역적 방법으로 구성할 수 있다.

- 관찰법(observation) / 에쓰로그래피(ethnography)

- 특정한 실험체계 내의 제한된 이슈로는 사용자의 무의식에 잠재된 니즈(latent needs) 도출에 한계가 있음. ( Ex: 호순 효과 )

- 관찰을 통해 인간과 인간 행동에 영향을 미치는 주위의 환경 요소들을 고려해 객관적인 관점에서 정상적인 접근이 가능하다.

- 로그 분석(Log analysis)

- 웹사이트나 모바일앱, 디지털기기의 사용자의 사용기록에 대한 분석이다.

- 방문자수와 페이지 뷰수, 쿠기 값 분석 등으로 사용자 정보를 분석하는 방법

- 개별 사용자의 행동들은 로그를 통해 기록하고 그 로그 분석을 통해 사용자의 행동 패턴 등을 분석이 가능하다.

- 로그파일, 코드 삽입(ASP), 통계 등을 이용한 로그 분석이 가능하다.

9강 페르소나와 사용자모델링 방법론

1. 사용자 모델링의 이해

- 사용자 모델링(user modeling)

정의

사용자 모델링은 실제 시스템 개발에 부합하는 사용자 모형(Model)을 제작하여, 특성을 시스템의 개발 목적에 따라 '사용자의 행동을 체계적으로 파악해 나가는 과정'이다.

사용자 분석 vs 사용자 모델링의 관계

사용자 분석이 사용자의 니즈를 전반적으로 조사하는 것이라면, 사용자 모델링은 그 추려진 분석 내용을 '시스템에 구현하고 구체화시키는 과정'이다.

- 사용자 모형(model) 구분

인지적 모형(cognitive model)

사용자가 어떻게 시스템을 이해하고, 사용 과정을 어떻게 배우고, 실제로 어떻게 사용하는지와 관련된 모형이다.

역할 모형(user role model)

사용자와 시스템 간의 상호 역할관계에 초점을 둔다. ( 욕구, 필요, 기대, 관심, 행태 등의 집합)

사회기술 모형(socio-technical model)

기술적인 요소가 동시에 고려된 사회적 맥락, 또는 서비스 생태계를 이해하는 것을 목표로 한다.

2, 멘탈 모델의 정의

- UI가 사용자의 멘탈모델과 맞지 않는다!?

멘탈모델(Mental Model)이란 사람들이 자기 자신, 다른 사람, 환경, 자신이 상호작용하는 사물들에 대해 갖는 모형이다. 사람들은 경험, 훈련, 지시를 통해 멘탈모델을 형성한다.

- 멘탈 모델링 과정

사용자의 사용에 관련된 행동 패턴과 태스크 분석을 통해 UI 설계 지침으로 활용

1. 사용자 인터뷰하기 - 사용자는 어떻게 행동하는가? 에 대한 사용자 진술의 수집

2. 사용자 행동 추출하기 - 사용 목적에 다른 행동의 양상과 속성, 절차 등을 추출

3. 행동 패턴 찾기 - 개별 행동들의 패턴화된 특징 도출

- 멘탈 모델의 역할

멘탈 모델을 만든다는 것은?

- 멘탈 모델은 사람들의 행동 동기, 사고 과정뿐만 아니라 그들이 행동하는 감성적, 철학적 배경에 대해서도 깊이 이해하는 데 효과적인 방법이다.

- 멘탈 모델은 사용자가 이용하는 서비스의 목적, 기능, 방법 등 다양한 이슈들에 대해서 사용자들이 경험하거나 하게 될 많은 상황을 규명하고 분류하는데 효과적인 방법이다.

3. 사용자모델링과 페르소나 작성 방법론

- 페르소나(persona)의 정의

어원 : 그리스의 고대극에서 배우들이 쓰던 가면을 일컫는다.

사용자 모델링에서 페르소나의 정의

- 어떤 제품 혹은 서비스를 사용할 만한 목표 인구 집단 안에 있는 '다양한 사용자 유형들을 대표하는 가상의 인물을 구체화하는 것'을 말한다.

사용자 모델링에서 페르소나의 역할

- 목표 사용자 그룹들의 이해를 돕는 역할

- 제품과 시스템이 얼마나 적합할지, 만족도를 향상시키도록 유도하는 가이드 역할

- 사람의 개성을 부여함으로써 보다 인간적인 접근을 하고 동감을 느끼는 것이 가능

- 사용자 요구분석 → 페르소나(가상의 사용자) → 사용자 시나리오(기능 정의) → 구체화/개발(UI, 인터랙션)

- 페르소나의 장점

- 페르소나를 사용하면 사용자를 인간의 얼굴을 가진 한 개인적인격체로서 보다 인간적으로 가깝게 이해할 수 있다.

- 가상의 인물이지만 실제 사용자들이 필요하고 느낄만한 것에 대해보다 쉽게 이해하고 접근할 수 있게 된다.

- 페르소나는 마케팅, 디자인, 판매 등 다양한 개발 조직 간에 사용자 이해를 위한 상호소통의 도구로서 유용하게 이용할 수 있다.

- 페르소나의 활용 지침

- 페르소나는 사용자를 상세히 묘사한 것으로 사용자 유형 프로필을 보여 준다.

- 페르소나는 일반적으로 80% 정도의 사용자를 커버할 수 있는 3~5명의 대표 사용자를 대상으로 구성한다.

- 페르소나는 디자인 개발 결과물에 대한 평가척도로, 페르소나의 이물자체는 가상이지만 실제 사용자들에게서 얻어진 자료를 바탕으로 만들어져야 한다.

- 페르소나 구성요소

- 기본 사항 : 사진, 이름, 개인 설명 등의 몰입을 도와주는 요소들

- 목표 : 경험적 목표, 궁극적 목표, 인생의 목표

- 계기/동기 : 제품과 서비스를 사용하게 된 주된 이유

- 태도/관점 : 제품과 서비스를 바라보는 생각과 관점

- 행태의 흐름 : 사용 내역(얼마나 자주)

- 환경 : 라이프스타일

- 숙련도 : 기술 활용 능력

- 불만족도 : 기존 제품서비스 사용경험의 문제점

- 니즈 : 기대하고 바라는 바

- 페르소나 작성 프로세스

↓ 사용자 컨텍스트 분석(context Analysis) 및 요구사항(requirement Analysis) 분석

↓ 주요 행동 패턴으로부터 전형적인 특성들을 결정

↓ 맵핑법을 통해 인터뷰 대상자를 특성에 매치하고 패턴을 도출

↓ 주요 패턴으로부터 '페르소나'를 결정하고 '페르소나' 목적을 정의

↓ '페르소나를 정교하게 다듬고 실질적 모델을 완성

- 페르소나 작성 시 주안점

- 사용자 설문이나 사용 후기의 양식을 통해 얻은 자료로 사용자의 과거 경험을 파악, 이를 통해 니즈를 분석하고 최종적으로 가상의 사용자를 설정한다.

- 사용자 분석을 통해 얻은 정성, 정량 조사 자료를 기반으로 만들어지는 것이기 때문에 신뢰성 있는 리서치가 진행되어야 한다.

- 사실에 기반을 둔 사용자 조사 자료를 통해 얻을 신뢰할 수 있는 데이터라는 사실을 늘 인지하고 있어야 한다.

- 최대한 다양한 요구사항을 고려한 제품, 서비스에 대해 하나 이상의 페르소나가 존재한다는 사실을 충분히 인지한다.

10강 UX기획 및 컨셉메이킹 방법론

1. UX 기획 및 디자인 전략 기초

- UX 기획과 전략의 기본 지식

사용자경험(UX)디자인이란?

- UX Design은 실제 사용자의 컨텍스트와 니즈를 읽고, 그것을 제품/서비스로 만들어내는 '방법론'이다.

- UX의 핵심은 '사용자에게 어떤 가치를 제공할까'를 고민하는 '가치중심적 사고'를 기반으로 제품서비스를 디자인/설계한다.

UX 목표 : 사용자를 위한 디자인

- UX는 보기 좋은 시각물을 만드는 것이 아니라, 풍부한 사용자 경험을 제공하는게 목표이다.

- 양질의 사용자경험을 제공하기 위해서는 사용자를 깊이있게 이해하는 것이 필요하다.

- 사용자를 이해하는 것은 특정한 컨텍스트에서 사용자들이 인지적/감성적/행위적 특성을 발견하는 일이다.

- UX의 가장 중요한 것은 사용자의 니즈의 도출과 욕구충족이다.

UX 기획의 기본 요소

- 사용자 맥락(User Context)

사용자의 제품서비스의 사용상황(시간, 장소)과 사용 전후의 전반적인 맥락

- 사용자 니즈(User Needs)

UX 대상(제품/시스템/서비스)으로 부터 특정한 만족감을 얻으려는 사용자들의 기대

- 사용 동기(User Motives)

사용자들의 행동을 불러일으키는 직접적인 발화제

- 사용자 태도(User Attitude)

UX 대상에 대해 갖는 개인의 취향과 선호, 선험적인 믿음과 정보

- 사용자 행위(User Behavior)

UX 대상을 사용하는 과정에서 드러나느 반복적인 행동패턴

사용의 경험 가치

실용성, 용이성, 효율성, 느낌

사용성의 극대화

사용자 인터페이스(UI), 효과성, 효율성, 만족도

2. UX 컨셉 도출과 디자인프로세스의 이해

- 컨셉 모델(Concept Model)

- 머리속의 생각들을 가시화 시키는 기초작업 : "아이디어 + 기획"의 시각화

    "서비스와 기능이 어떤 구조로 형성되는지 그려내는 시각화의 초기 단계의 방법론이다.

- UX 기획에 있어 컨셉모델의 역할

- 사용자분석과 사용 모델을 바탕으로 실제 사용자경험의 컨셉모델을 만들어 개별 경험 요소들이 어떻게 디자인에 반영될 지에 대한 방향을 잡아 준다.

- 기획 초기에 컨셉 모델을 그려놓고 시작하면 협업자간 커뮤니케이션에 큰 도움이 된다.

- UX 기획 및 디자인프로세스의 이해

- 비즈니스 전략

비즈니스 목표와 비전의 이해, 브랜드전략, 시장/경쟁사 분석 등

- UX 리서치와 디자인전략 수립

사용자분석, 요구사항 도출, 페르소나, 사용자 인터뷰 등

- UX 디자인 컨셉

사용자 테스트, 아이데이션, 컨셉모델 등

- UX 디자인 개발 수행

스토리보드, 와이어프레임, 키스크린, UI개발, 사용자테스트 등

3. 프로토타이핑(prototyping)

- 프로토타이핑의 목적

프로토타입의 개념

- 프로토타입은 시제품이 나오기 전 제품의 원형을 의미한다.

- 제품, 또는 시스템의 미완성 버전 또는 중요한 기능들이 포함되어 있는 시스템의 초기 모델로 활용된다.

- 프로토타입은 사용자의 모든 요구사항이 정확하게 반영될 때까지 계속해서 개선/보완된다.

프로토타입의 목적 및 장점

- 프로토타입핑의 장점은 최종 사용자가 초기 모델을 사용하면서 평가할 수 있어, 시제품의 개선 보완할 부분의 파악이 용이하다는 점이다.

- 프로토타입은 개발자와 사용자의 의사소통의 채널이고, 언제든지 변경이 가능한 유연성을 갖고 있다.

- 디자인, 개발팀 간 시제품 디자인 검토 및 협업을 도와 주고 UI 설계 시 발생되는 여러 개발이슈에 대한 의사결정에 도움을 준다.

- 개발 주기의 단축과 사용자의 요구사항을 정확히 파악해 사용성의 만족도를 향상시킬 수 있다.

- 프로토타이핑 방법론

저수준 프로토타이핑(Low-fidelity prototyping)

- 저수준 프로토타이핑은 빠른 시간 안에 프로토타입 제작이 필요한 경우에 사용되는 방법

- 주로 페이퍼 프로토타이핑(paper prototyping) 기법을 사용

- 초기 아이디어 구현 단계에서, 사용자의 반응을 확인하고 사용자로 부터 요구사항을 빠르게 파악하기 위한 목적

고수준 프로토타이핑(High-fidelity prototyping)

- 디자인의 시제품, 애플리케이션의 베타 버전 등의 최종 완성물과 동일한 프로토타입을 제작

- 제품, 시스템 전체 기능과 서비스, 디자인 평가 보다는 발견하지 못한 작은 문제점을 수정하기 위한 목적

수평적 프로토타이핑(Horizontal prototyping)

- 다양한 기능을 반영하여 최종 제품서비스를 전반적으로 예상해 볼 수 있음.

- 세부적인 상세한 기능 정보 설계가 아닌 인터페이스의 표층만을 사용하기 때문에, 프로토타입의 크기가 작고 메뉴의 하위에 대한 작업은 진행되지 않은 상태의 프로토타이핑

수직적 프로토타이핑(Vertical prototyping)

- 제품과 시스템의 많은 기능 중, 주요 기능만을 선별해 세부 기능까지 상세하게 구현하는 방법

- 인터페이스의 몇 가지 경로만 완전히 실행되게 만들고 나머지 경로는 포함되지 않음

- 주요 기능 메뉴의 모든 하위 동작이 실행되기 때문에 사용자가 실제로 사용할 수 있도록 제작함.

- 프로토타이핑의 과정(5단계)

1단계 : 사용자 요구사항 분석

2단계 : 프로토타입 설계/스케치

3단계 : 프로토타입 개발

4단계 : 사용자 평가(수정/보완 반복)

5단계 : 프로토타입 정제

11강 UI 스토리보드 작성과 UI 상세설계 가이드

1. UI 스토리보드의 정의와 목적

- 스토리보드(Storyboard)의 이해

Storyboard란, UX구현에 수반되는 사용자와 태스크, 인터페이스 간 상호작용을 시각화하여, 개발자/디자이너와의 의사소통을 돕는 도구이자, 완성해야 할 앱서비스와 예상되는 사용자경험을 미리 보기 위한 방법론이다.

- UI 스토리보드의 목적

모바일앱에 필요한 기능 조각들 간 관계의 설계

- 앱 설계에 필요한 조각들을 모아서 순서대로 놓고, 배치해보고, 쌓아서 조립하는 과정

- 실제 개발 단계에서 발생할 수 있는 문제점을 미리 발견하고 대처하기 위한 과정

2. UI 스토리보드의 구성요소

- 스토리보드(Storyboard)의 활용

UX 스토리보드의 작성 프로세스

- 사용자 시나리오를 시각화하면서 평가하는 과정을 거친다

- 사용자 Task에 따른 세부적인 기능들 간의 흐름과 관계망을 파악할 수 있다.

- 개발자와 사용자 간의 피드백을 받으면 스토리보드를 재정비할 수 있다

UX Concept → 기능 → 순서 → 관계 → 구조 → 설계 → 연결 → 검증 → 디자인 개발         

- UI 스토리보드 작성 프로세스

UX 스토리보드의 구성요소

- Feature list : UX concept/UX Needs의 구현에 필요한 기능 리스트

- User Task-flow : 해당 기능수행과 사용자의 행위 매핑 및 흐름도

- Information Architecture(IA) : 정보의 구조화와 위계관계망(우선순위)

- Wireframe : 해당기능 구현을 위한 인터페이스 요소의 배치와 화면 구조

- Workflow : 여러 개의 와이어프레임 또는 개별 기능 간 화면 전환 흐름도

3. UI 상세 화면 설계(Skeleton) 방법론

UI 상세 화면 설계 프로세스

Feature List → Task Flow → Process Diagram → IA → Wire-frame → Work-flow

UI feature 리스트 작성 단계

- UI 구현에 수반되는 앱시스템, 서비스, 장치 등 인터페이스 Feature 목록 나열하고 앱 개발에 필요한 기능들을 추출하고 우선순위를 정의하는 단계

→ 사용자의 니즈를 충족시키기 위한 앱의 기능들을 나열한다.

→ 우선순위 설정 방법에 따라 기술된 기능의 우선순위를 정한다.

→ 기능간의 포함관계를 고려하여 삭제 및 추가한다.

→ 정의된 기능들에 대해 우선순위를 설정한다. 

User Task-Flow 작성 단계

- 기능수행을 위한 사용자의 행위 순서(흐름)로 나열하고 검증하는 단계

(각 페이지마다 가지고 있는 기능을 그리면 된다)

Process Diagram 작성 단계

- 각 기능들 사이 관계(조건과 실행)를 정립하여 구조화하는 단계

(각 페이지들과의 관계를 Yes/No로 프로세스 흐름대로 표시한다.)

IA(Information Architecture) 구조화 단계

- 각 기능들을 정보의 위계와 관계망으로 구조화하기

(기업 조직도처럼 기능별로 조직도를 그린다)

Wireframe 설계 단계

- 해당기능 구현을 위한 인터페이스와 실제 화면에 그려보기

(각 화면을 그림으로 그려보는 것이다.)

Workflow 설계 단계

- 화면전환 및 화면 간 상호작용 및 시뮬레이션 해보기

(Wireframe으로 만들어낸 설계를 화면전화이 발생시 어떤 기능을 가지는지 작성하는 것이다.)

12강 UI 디자인 패턴과 UI 가이드문서 작성

1. UI 디자인 패턴과 적용 가이드

- 접근성과 항해성 관련 UI 패턴

사용자가 인터페이스를 사용하면서 경헝하게 되는 기능 및 이벤트/컨텐츠의 방위(orientation)와 경로(path)의 인지와 탐색을 위한 UI 패턴

- Side Menu(drawer)

- Action Bar(Android)

- Dropdown Navigation

- Dash board

- Pop-over Navigation

- Side Menu(drawer)

- 메뉴(이벤트) 호출/컨텍스트 유지

- 여러 가지 기능을 화면 내 배치하지 않고, 좌우 Side Menu로 숨겨진 공간에 배치하여 화면 내 구성요소 단순화

- 장점 : 화면 내 공간 효율성 각 기능 간 context 분리가 명확

- 단점 : 다른 기능 수행 시 현재 화면 유지가 어려움

- Action Bar(Android)

- 접근성 향상

- 전체 페이지 내 공통된 2~3개의 기능을 항상 제공하면서 접근이 자주 있는 기능의 배치

- 장점 : 모든 페이지에서 일관되게 제공되는 형태를 통해 주요기능에 대한 접근성 확보/공간 효율

- 단점 : 상단 바에 너무 많은 기능이 제시되면 혼잡도 증가

- Dropdown Navigation

- 접근성/공간 절약

- 메뉴들을 숨겼다가 펼쳐서 해당 메뉴 선택하여 이동하는 경우, 세부 카테고리가 위에서 아래로 펼쳐지는 구조

- 장점 : 각 기능/메뉴 간 전환이 쉽고 빠름. 3D 효과와 함께 제시함으로써 시각적으로 쉽게 인지 가능

- 단점 : 각 기능간 타이틀 바를 표시하므로 공간 활용 비효율적, 3D 효과로 인해 인지적 부담 유발 가능

- Dash board

- 카테고리 커스텀

- 사용자 관련 데이터를 가공하고 개인화하여 보여줄 때, 복수의 기능 카테고리를 한 페이지 안에 표시

- 장점 : 주로 아이콘과 함께 표시되어 어떤 컨텐츠를 담고 있는지 직관적으로 확인할 수 있음

- 단점 : Dash Board 내 제시 가능한 카테고리 개수가 제한적임(스크롤로 보완 가능)

- Pop-over Navigation

- navi-컨텍스트 유지

- 메뉴 개수가 4~5 이상이고 페이지간 전환시 Navi-context유지(머물러 있는)가 필요할 때, 버튼을 눌렀을 때 메뉴나 기능이 화면 위에 오버레이(overlay) 형태로 표시

- 장점 : 화면 위에 이동 가능한 메뉴나 접근 가능한 기능들을 제시 가능

- 단점 : 메뉴 제공 시 화면의 일부를 덮을 수 있음

- 학습성 관련 UI 패턴

처음 사용자, 또는 초급 사용자를 위해 시각적 언어와 익숙한 사용성을 제공하여 학습성을 높이기 위한 UI 패턴

- Guide Text

- Coach Mark

- Guide Text

- 데이터 입력 방식의 학습성

- 사용자가 처음 페이지에 진입하여 데이터가 없을 때, 또는 데이터 입력 필드에서 해당 필드 내 입력될 데이터를 텍스트로 안내

- 장점 : 해당 영역에서 필요한 설명을 그 안에서 설명해주므로 직관적이고, 사용자의 행동을 유도할 수 있음

- 단점 : 텍스트 양이 너무 많아질 경우 화면이 복잡해질 수 있음

- Coach Mark

- 학습성/특정 피쳐

- 앱 실행 후 처음 접하는 기능과 인터렉션 등을 좀더 자세히 페이지 상에서 설명

- 장점 : 직접 인터랙션을 따라 하게 유도할 수도 있음

- 단점 : 모든 사용자에게 제공하여 번거로울 수 있음

- 공간 효율성 관련 UI 패턴

단위화면(기능) 구조의 컴포넌트화를 통해 접근성을 높이고 최대한 화면 공간 구성의 효율성을 확보

- Compose Screens

- Contextual Hovering Menu

- Card UI

- Compose Screens

- 접근성/멀티 이벤트

- 메시지를 작성하는 화면으로 키보드 상단에 수행 가능한 액션들을 제공하여 추가 기능에 대한 접근성을 높임

- 장점 : 텍스트 입력 외에 추가적인 기능도 페이지 전환 없이 바로 수행이 가능하고, 추가 기능을 강조할 수 있음

- 단점 : 화면의 절반을 차지하는 키보드 위에 추가로 1줄을 더 차지하므로 공간 활용이 비효율적.

- Contextual Hovering Menu

- 접근성/멀티 이벤트

- 모든 페이지에서 수시로 접근해야 하는 기능이 있을 경우, 화면 낸 상시로 떠있는 형태의 메뉴 아이콘 제공

- 장점 : 수시로 접근해야 하는 기능을 할당하여 모든 페이지에서 접근성을 높임

- 단점 : 화면 내 항상 일부 영역을 차지하므로, 해당 영역에 이미지나 주요 정보를 가릴 수 있음

- Card UI

- 유연한 레이아웃

- 다양한 컨텐츠를 카드 형태로 나열하여 보여줌

- 장점 : 컨텐츠의 개수가 늘어나도 정렬/그룹/확장 등을 통해 레이아웃을 유동적으로 대응할 수 있음

- 단점 : 텍스트가 위주인 컨텐츠에는 적당하지 않음

2. OS 별 앱 UI 구조와 특성

- iOS : Human Interface Guideline

컨텐츠 중심(Defer to content)

- 사용자가 컨텐츠를 이해하고 상호작용 하는 것을 도와줘야 하는 반면, 컨텐츠에 집중하지 못하도록 방해해서는 안된다.

- 전체 화면을 최대한 활용

- 각종 UI 요소는 최대한 절제, 사용자가 컨텐츠에 집중할 수 있도록 함

- 반투명 컨텐츠 레이어 뒤에 현재 작업의 힌트를 제공해서 문맥(context) 유지

시각적 명료성(Provide Clarity)

- 글꼴은 읽기 쉽게, 아이콘은 이해하기 쉽게, 장식적인 요소는 절제

- 여백을 적극적으로 활용

- 색 사용을 절제하여 컨텐츠 강조, 키 컬러를 통해 주요 기능 강조

- 자동으로 자간, 행간을 조정하는 시스템 폰트 활용

정보와 시각의 계층 구조 활용(Depth for Communication)

- 상호작용을 위한 정보와 시각의 계층 구조 활용, 눈으로 보여지는 요소들은 층 구성(layered)으로 이루어져 사용자의 이해를 돕고 재미를 추가한다.

- 정보를 별도 레이어로 표시하여 작업 문맥(context) 유지

- 상위 레이어를 통해 폴더를 표현하고 폴더 내 컨텐츠와 스크린을 분리

- 카테고리 구분을 레이어 형태로 표현

- Android : Human Interface Guideline

사용자를 매혹하기(Enchat Me)

- 애니메이션, 사운드 효과 등을 통해 사용자를 자극하거나 사용자가 좀 더 원하는 기능을 맞춤 기능으로 제공

- 표면의 미적 요소나 애니메이션, 사운드 효과를 통해 사용자를 자극

- 사용자가 직접 터치하고 조작할 수 있는 형태의 버튼을 제공

- 주요 기능을 저해하지 않는 범위 내에서 맞춤 기능 제공

- 사용자가 매번 선택하도록 요구하기보다, 이전 선택을 기반으로쉽게 접근하도록 제시

사용자 생활을 단순하게 만들기(Simplify My Life)

- 텍스트보다는 사진으로 정보를 전달하고, 너무 복잡한 기능은 뒤에 숨겨두어 앱 사용 방식을 단순화

- 가능한 간단한 단어로 이루어진 짧은 문구를 사용

- 기능을 시각적으로 단순하게 만들기보다 눈에 띄게 만들어서 기능적 차이를 알아볼 수 있게 하고, 같은 방식으로 작동하도록 제공 

- 현재 필요하지 않은 옵션은 숨기고 작업 진행 상황에 맞게 옵션을 표시

- 정말 중요한 태스크를 제외하고는 작업을 중단하는 일은 최소화

사용자를 놀라게 만들기(Make Me Amazing)

- 복잡한 태스크를 쉽게 완료할 수 있도록 세분화하고 명료한 피드백을 제공하거나, 복잡한 기능을 손쉽게 활용할 수 있도록 간편한 방법으로 제공

- 사용자가 자기 탓으로 느끼지 않도록 명확한 복구 지침을 제공

- 복잡한 태스크를 쉽게 완료할 수 있도록 여러 단계로 나누고, 미묘한 피드백이라도 제공

- 초보자들이 하기 힘든 기능은 단축키와 같이 쉽게 접근할 수 있는 형태로 제공

- 화면 내 중요한 기능을 쉽게 찾고 수행할 수 있도록 제공

3. UI 설계 문서의 작성 방법론

- UX/UI 개발 프로세스의 이해

UX/UI 기획 → UI 설계문서 → GUI 디자인 → GUI 가이드라인 → Coding 개발

- UX/UI 기획의 주요 산출물

사용자요구 분석( User Need Analysis)

사용자분석 리서치 → 페르소나 작성 → 사용성 테스트

정보/컨텐츠 개발전략 문서(Contents Strategy)

벤치마킹 → 컨셉모델 → (정보)컨텐츠 인벤토리/IA 문서

- UI 설계문서(UI document)

UI 설계문서의 개념과 목적

- UX 기획 설계를 토대로 해당 프로젝트의 실물 개발에 필요한 이미지 리소스, 텍스트 크기, 기타 컴포넌트의 속성 및 위치 등 UI 개발을 위한 일종의 설계도면과 같다

- 디자인을 개발하기 위한 설명서, 즉 개발자와 디자인 실무자를 연결해주는 일종의 협업 도구이기 때문에 개발자가 쉽고 원활히 알아볼 수 있도록 문서를 작성하는 것이 중요하다.

UI 설계문서의 구조와구성요소

- 프로젝트 정의/목적, 기본 규칙(Basic Rule), 세부 화면 정의, 수정보완 업데이트 히스토리 등

- 주요 내용 : 태스크 플로우차트, 와이어프레임, IA, 키스크린, 스토리보드 등