TIL_2W2D_[디자인씽킹 2단계] 문제 정의하기 Define
디자인씽킹 2단계 문제 정의하기 Define
'문제 정의하기'란
공감으로 얻은 정보를 해석해 사용자가 불편함을 느끼는 지점을 발견하는 단계임
정의된 문제로부터 아이디어가 나오기에 문제 정의가 제대로 되지 않으면 제대로 된 아이디어를 만들 수 없음
문제 정의가 잘 되었다면 다음 질문에 답할 수 있어야 함
무엇이 문제인가?
그것이 왜 문제인가?
풀어야 할 문제 중 가장 중요한 것인가?
문제를 잘 정의하는 것이 중요한 이유는 GIGO(garbage-in, garbage-out), 즉 올바르지 않은 데이터를 입력 시 올바르지 않은 결과값이 나온다는 뜻임
시작점인 문제 정의가 정확해야 의미 있는 결과를 얻을 수 있음
문제 정의하기 단계에서 활용할 수 있는 방법들
디자인씽킹 3단계 아이디어 발산하기 Ideate
아이디어 발산하기는 정의한 문제를 해결할 다양한 아이디어를 내고, 그 중에서 가장 적합한 아이디어를 선택하는 과정임
SCAMPER로 브로인스토밍 해보기
1. 대체하기 Substitute
- A 대신 B를 쓰면 어떨까?
2. 결합하기 Combine
- A와 전혀 다른 B를 합쳐보면 어떨까?
3. 응용하기 Adjust/Adapt
- A를 B 외에 C에도 사용하면 어떨까?
4. 수정하기 Modify - 확대하기 Magnify - 축소하기 Minify
- A를 변형하면 어떨까? A를 확대/축소하면 어떨까?
5. 다르게 활용하기 Put to another use
- A를 B가 아니라 C로 사용하면 어떨까?
6. 제거하기 Eliminate
- A의 일부를 제거하면 어떨까?
7. 역발상 해보기 Reverse, 다시 정렬하기 Rearrange
- A→B를 B→A로 바꾸면 어떨까?
디자인씽킹 4단계 프로토타입 만들기 Prototype
프로토타입 만들기는 프로토타입 단계에서 사용자가 아이디어를 경험할 수 있도록 구체적인 제품이나 서비스로 개발하는 것
다양한 아이디어 중 하나의 아이디어를 선정, 그 가능성을 판단해 보기 위해 최소 기능을 중심으로 빠르게 프로토타입을 만듦
최소 기능이란
MVP(Minimum Viable Product)의 약자로 목적을 달성하기 위한 최소한의 기능만 구현한 제품이라는 뜻임
리소스를 효율적으로 쓰기 위한 목적으로 아이디어 확인할 수 있는 핵심 기능만 최소한으로 만드는 것을 의미
프로토타입의 목적은 최대한 빠르게 아이디어의 가능성을 검증하는 것으로
핵심은
1) 최대한 간결하면서
2) 가능한 한 빠르게 실패를 확인하고
3) 빠르게 반복하는 것입니다.
프로토타입 단계에서 활용할 수 있는 방법들
Lo-fi(Low fidelity)와 Hi-fi(High fidelity) 프로토타입
Lo-fi(Low fidelity) 프로토타입은 시각적 부분 크게 고려되지 않은 와이어프레임 수준으로 움직임을 구현한 프로토타입
디자인 툴 사용하지 않고 펜으로 그려서 테스트하거나, 클릭과 화면 전환 정도로 구현된 단순 프로토타입이 여기에 속함
아이디어를 빠르게 검증해 보고 싶을 때 사용함
Hi-fi(High fidelity) 프로토타입은 최종 제품과 유사 수준으로 구현된 프로토타입
색상과 텍스트 스타일 등 비주얼과 인터렉션 움직임 모두 실제 제품 컨셉과 유사해야 함
구체적 기능이나 화면 사용성 시험해 보고 싶을 떄나 사용자가 프로토타입이라는 것을 인지하지 못할 정도로 몰입한 경험을 테스트 하고 싶을 때 사용함
디자인씽킹 5단계 테스트하기 Test
테스트는 프로토타입을 사용자가 직접 사용해 보게 하고 피드백을 받는 단계임
실무에서는 때에 따라 일부 단계가 생략되기도 하지만 보통 이러한 5단계의 과정을 반복하며 제품을 고도화함
HW. 디자인씽킹 활용해보기
-
1단계 공감하기에서는 공감지도 (Empathy Map)
생각과 느낌
보는 것
전체적인 블루 디자인이 눈에 띄고 타 예약앱에 비하여 단출한 느낌이 있음
듣는 것, 말과 행동
해당사항 무
불편한 것
버튼 주변이 어두운 컬러로 되어 있어 거리낌이 들기도 함 다른 타 앱 홈화면과 비교하였을 때 어떤 앱을 이용할 것이냐고 묻는다면 다른 앱을 이용할 것 같음
얻는 것
서비스를 사용하기에 있어 버튼 부분이 블루로 강조되어 이 서비스를 이용하면 되겠구나하는 생각이 듦 -
2단계 문제 정의하기에서는 5 whys
왜 앱 홈화면에 거리낌이 발생하는가?
어두운 컬러 배치로 적대감이 생김
왜 어두운 컬러 배치로 적대감이 생기는가?
어두운 컬러가 6할 이상을 차지함
왜 어두운 컬러가 6할 이상을 차지하는가?
버튼을 더 돋보이게 하기 위하여 주변을 어두운 계열을 사용함
왜 버튼을 더 돋보이게 하기 위해 어두운 계열을 사용하였는가?
버튼 안의 이미지를 하얀색으로 하였기 때문임
버튼의 이미지가 하얀색으로 하여 그 밖의 요소에 어두운 컬러를 많이 사용함으로 홈화면에 거리낌이 발생함 -
3단계 아이디어 도출하기에서는 SCAMPER
대체하기 Substitute
- 버튼 이미지를 하얀 컬러 대신 어두운 컬러를 쓰면 어떨까?
어두운 컬러로 사용한 후에 푸른 계열의 어두운 6할을 회색조로 변경하는 것
결합하기 Combine
- 버튼의 하얀 이미지를 제외하고 전혀 다른 일러 이미지를를 사용 해보면 어떨까?
응용하기 Adjust/Adapt
- 버튼을 푸르고 어두운 계열 외에 다른 계열을 사용하면 어떨까?
수정하기 Modify - 확대하기 Magnify - 축소하기 Minify
- 버튼을 변형하면 어떨까? 버튼을 확대/축소하면 어떨까?
다르게 활용하기 Put to another use
- 버튼을 상단 배치가 아니라 하단 배치로 하면 어떨까?
제거하기 Eliminate
- 버튼의 이미지를 제거하면 어떨까?
역발상 해보기 Reverse, 다시 정렬하기 Rearrange
- 버튼 형식을 새롭게 바꾸면 어떨까?
제품팀은 제품을 만들기 위해 각자 다른 전문적인 능력을 갖춘 사람들이 모인 팀을 말함
보통 1명의 제품관리자나(PO나 PM), 1명의 디자이너, 2명의 엔지니어가 제품팀을 구성하는 최소 조건임
목적조직은 특정한 목적 달성을 위해 여러 직무의 사람들이 모인 팀을 말함
주로 스쿼드나 사일로라고 부름
제품의 목표 달성을 위해 다양한 직무 사람이 모여있는 팀이기에 속도가 빠르고 효율적이라는 장점이 있음
기능조직은 유사한 직무끼리 구성된 팀을 말함
주로 챕터라고 부름
비슷한 일을 하는 사람들끼리 모여있기 때문에 전문 분야에 대해 깊게 논의하고 서로의 발전을 도울 수 있다는 장점
매트릭스 조직은 기능조직과 목적조직이 교차된 상태로 소속된 구성을 말함
예를 들면 프로덕트 디자이너는 기능조직인 디자인팀에 속하면서 동시에 목적조직인 스쿼드에 속할 수 있음
팀의 규모는 회사마다 다를 수 있지만 아마존의 창업자 제프 베조스는 최대 16명을 넘지 않는 것을 추천
피자 두 판의 법칙
신속하고 효율적으로 운용할 수 있도록 팀원을 피자 두 판으로 식사를 해결할 수 있는 수 이내로 유지하라는 원칙
디자인 카타
오늘의 토픽 - 요즘 트렌드와 가깝다고 생각되는 색상은 무엇인가요?
선택 A안
깔끔하고 주목도가 더 높다고 생각하였음
옛날에 2010년도 당시에 그라데이션이 더 많이 사용되었다고 생각하며, 정신산만한 느낌이 없지 않은 것 같다고 느껴짐
UX/UI 실무 프로세스
1) 디자인 프로세스
기획
-
문제정의
PO/PM과 함께 제품 목표에 따라 우선순위가 높은 문제를 정함**
회사에 따라 문제 정의 단계에서 디자이너가 참여하기도 하고, 참여하지 않고 따른 PO/PM이 문제를 선정해 공유하기도 함 -
아이데이션
앞서 정의한 문제를 해결할 다양한 아이디어를 내고, 그 중에서 적절한 솔루션을 선택함
필요에 따라 러프한 솔루션 스케치를 진행하기도 함
아이데이션 단계에서 그리는 솔루션 스케치는 기획과 아이디어가 잘 보이도록 와이어프레임 형태로 그림 -
프로덕트 스펙 문서 작성
디자인에 들어가기 전, 문서에 솔루션에 대한 상세 내용을 글로 먼저 적어봄
디자인이 나오지 않아도 엔지니어가 솔루션을 미리 상상하고 준비할 수 있다는 장점
회사에 따라 생략되거나 PO/PM 직군이 알아서 하기도 함
디자인
-
초안 디자인
피그마나 스케치 등의 디자인 툴로 솔루션을 디자인
디자인 디테일 보다 전반적인 사용자의 여정과 UX에 집중해 보면서 프로덕트 스펙 문서에서 놓친 엣지 케이스 유무를 살핌 -
피드백
기획 단계에서 논의한 대로 잘 디자인되었는지 팀원들에게 공유 및 피드백을 받음 -
최종 디자인 확정 및 핸드오프
피드백을 초안에 반영하여 최종 디자인 확정
확정한 최종 디자인을 엔지니어에게 공유 및 개발이 원활히 진행될 수 있도록 도움
필요에 따라 가이드를 함꼐 작성해 전달하기도 함
핸드오프는 디자인을 개발할 수 있도록 엔지니어에게 전달하는 것
디자인 공유 시 다음의 내용을 포함해 함께 전달하는 것이 좋음
유저 플로우
처음 시작하는 화면이 어디이며 어떻게 연결되는지, 만드려고 하는 기능의 전체 흐름이 잘 보이도록 구성
유즈 케이스
상황에 따른 화면 정의
반응형 레이아웃
개발
- 디자인 QA
개발이 완료되면 디자인대로 정확하게 개발되었는지 확인하는 디자인 QA 진행
최대한 사용자와 비슷한 환경으로 테스트
앱이라면 적어도 안드로이드, iOS 두 환경을 모두 확인하는 것이 좋음
2) 프로젝트 스펙 문서
프로젝트 스펙은 제품을 만들거나 개선 시 사용하는 문서로 기능의 사양을 정의한 가이드
회사에 따라 PRD(Product Requirements Document, 제품 요구사항 정의서)라고 부르기도 함
어떤 내용이 들어가야 하는가?
-
기획 배경 & 문제 정의
기획된 배경을 짧게 설명, 사용자의 문제를 정의
문제 발견 과정
문제로 정의한 이유
문제의 원인
누가 이 문제에 영향을 받는지 -
솔루션 설명
만들고자 하는 솔루션에 대해 UX/UI 관점에서 자세히 설명
페르소나
사용자 시나리오
기능별 주요 특징 & 요구사항
예외 상황 및 Edge Case 정의
최종 시안 -
실험 설계
솔루션 효과를 검증하기 위해 어떤 순서로 실험 진행, 어떻게 결과를 분석할 것인지에 대한 계획을 적음
실험 가설(문제 해결을 통해 만들어 내고자 하는 결과)
실험 방식
결과 평가(문제가 해결되었는지 판단할 수 있는 방법)
실험 기간 -
예상 일정
프로덕트 스펙 초안 작성 완료 예상 일정
UI/UX 디자인 최종 시안 제작 완료 예상 일정
개발 분야별 예상 일정
프론트엔드, 서버, 이벤트 설계, QA가 각각 세부적으로 작성
배포 목표 일정
프로덕트 스펙 문서는 계속해서 업데이트 되어야 함
기획 초기에 만들기 시작해 기능 배포되고 실험이 종료될 때까지 끊임없이 업데이트 및 관리 필요
3) 디자인 공유하고 피드백 받기
좋은 피드백을 받기 위해선 디자인을 잘 공유하는 것이 중요
디자이너의 업무 대부분 디자인과 피드백, 거듭되는 수정으로 이루어짐
기획 배경과 맥락 잘 이해해야 좋은 피드백이 나옴
피드백 주는 사람이 전체적 내용을 알 수 있도록 충분한 정보를 함께 전달해야 함
디자인 피드백 요청 시 포함하면 좋은 것
-
배경
해당 프로젝트 기획 배경
구체적 데이터와 가설을 더하면 좋음 -
솔루션의 의도
가설에서 어떠한 방향성을 잡고 디자인 했는지 설명
시각적 강조 부분이나 중요하게 생각한 부분 -
필수 리뷰어
다수에게 디자인 공유 시 꼭 피드백을 받고 싶은 사람을 지정하는 것이 좋음
디자인한 화면으로 영향을 받는 곳과 연관된 사람이 있다면 참조 -
참고 문서
프로덕트 스펙 문서를 함께 첨부하면 전반적인 프로젝트를 이해하는 데에 도움
디자인 파일도 함께 공유 시 다른 디자이너들의 도움을 받을 수도 있음
이해를 돕기 위해 프로토타입을 함께 공유하는 것도 좋음
협업은 각 직무의 리소스가 낭비 없이 좋은 솔루션을 만드는 데 집중적으로 쓰이는 것을 의미함
협업의 질은 곧 제품의 질임
PO/PM 이해하기
PM(Product Manager)
프로덕트 매니저는 제품의 전략을 세우고, 우선 순위를 결정해 실행하는 사람
제품의 전략을 수립하고 아이디어의 우선순위를 향해 디자이너와 함께 솔루션 설계, 실제 프로젝트를 수행하는 실무의 성격이 강함
PO는 Product Owner
프로젝트 오너는 제품에 대한 오너십을 갖고 제품이 시장에 잘 전달될 수 있도록 관리하는 사람
일반적으로 PM보다 더 많은 역할과 책임이 주어짐
제품팀을 이끌며, 제품이 시장에 잘 전달될 수 있도록 관리
이해관계자들과 논의, 제품팀의 팀원들이 제품을 잘 만들 수 있는 환경을 만드는 데에도 힘씀
PM과 PO의 차이점
엔지니어 이해하기
프론트엔드 엔지니어
사용자가 만나는 지점, 특히 눈에 보이는 영역의 기능을 구현하는 사람
앱/웹의 페이지, 화면 안의 각종 컴포넌트 즉, UI를 코드로 구현
단순 그래픽 구현을 넘어 화면 간 이동, 컴포넌트 모션, 사용자의 인풋에 따른 반응까지 구현하기 때문에 사용자 경험을 만드는 UX와도 깊게 관련
백엔드 엔지니어
제품 필요 정보를 저장하거나 전송, 관리하는 영역을 담당하는 사람
서버 엔지니어라고도 함
정보 저장, 전송 뿐 아니라 제품 전체를 효율적으로 운영할 수 있도록 구조를 고민하는 역할
상대적으로 프론트엔드 엔지니어보다 디자이너와 접점이 적지만 종종 이야기를 나눌 일이 있음
QA 엔지니어
QA 테스트를 계획, 진행하고 제품 전반적인 품질을 높이는 역할을 하는 사람
기능이 개발되면 배포 전 테스트를 함
지속해서 제품 모니터링, 서비스 안정성과 품질을 지키기 위해 노력
데이터 애널리스트
수집하고 분석해서 인사이트를 제공하는 사람
데이터베이스에서 SQL 같은 언어를 사용해 필요한 데이터 추출, 파이썬 등을 활용해 여러 방면으로 분석하는 일을 함
데이터를 보기 좋은 형태로 가공, 시각화하여 제품팀이 의사결정을 올바르게 할 수 있도록 도움
UX/UI 직무 이해하기
BX 디자이너
Brand eXperience의 줄임말로, 브랜드 경험과 관련된 전반적인 디자인을 하는 사람
로고나 심볼처럼 아주 기본적인 것부터 앱/웹에 들어가는 그래픽, 대외에 노출되는 이미지, 각종 인쇄물 등 브랜드를 나타내는 모든 부분을 담당
UX writer
제품 내의 문구를 담당하는 사람
브랜드의 보이스앤톤을 문구로 전달, 명확한 메시지를 통해 제품의 사용성을 높이는 일을 함
규모가 작은 회사에서는 UX 라이터 직무를 별도로 두지 않고 디자이너가 그 역할을 대신하기도 함
실험은 제품의 개선이 실제로 사용자에게 더 나은 경험으로 이어지는지 데이터로 검증하는 것
왜 실험을 해야 하는가?
사람은 편향적이기 때문에 만드는 사람 주관이 제품에 반영되기 쉬움
데이터로 사용자 데이터를 확인하면, 객관적 의사결정이 가능
호불호가 데이터로 증명되기 때문
실험은 대부분 A/B 테스트로 진행
A/B 테스트 설계를 할 수 없을 때, 특정 상황 시 전후 비교 테스트를 함
A/B 테스트는 두 가지 이상의 버전을 각각 다른 사용자에게 보여주고 성과를 측정하는 실험
사용자를 임의로 대조군(Control)과 실험군(Treatment), 두 집단으로 나누고 서로 다른 안을 보여준 다음 어느 집단이 더 좋은 지표를 보이는지 측정하여 평가
전후 비교 테스트는 실험 기간 전후로 지표가 어떻게 달라졌는지 비교해 보는 방법
실험을 위한 제품 분석 도구
디자인 QA
QA는 Quality Assurance의 약자로, 제품이 출시되기 전에 기능을 테스트하는 것을 말함
제품이 처음 기획한 대로 잘 구현이 되었는지, 회사에서 생각하는 품질 기준이 충족되었는지 확인하는 과정
규모에 따라 별도 QA팀이 있기도, 제품팀에서 QA를 수행하기도 함
QA팀이 있더라도 기능을 만든 담당자라면 대부분 직접 QA를 함
QA의 목적
사용자가 제품을 이용할 수 없을 만큼의 치명적 결함은 없는지
조직 전체에서 기대하는 수준의 품질이 갖춰졌는지
Product Spec 문서에서 작성했던 명세대로 잘 구현되었는지
특수한 상황에서 예상하지 못한 대로 동작하지는 않는지
전반적인 UX가 사용하기 편리한지
QA 문서
체크리스트
예/아니요, 혹은 Pass/Fail로 답변할 수 있는 확인 성격의 항목을 나열한 목록
기능이나 개선 범위가 넓지 않을 때 사용
테스트 시나리오(TS)
기획한 기능이 모두 제대로 동작하는지 확인하기 위해 작성하는 문서
사용자가 기능을 사용하면서 경험하게 되는 과정 상세히 작성
테스트 케이스(TC)
특정 조건에서 요구 사항을 충족하는지 확인하기 위해 여러가지 케이스를 작성한 문서
특정 조건 아래의 환경을 테스트하는 것이기 때문에 특정 조건, 테스트 범위, 케이스, 기댓값, 테스트 환경 등 상세히 작성
디자인 QA
디자인이 정확하게 개발되었는지 확인하는 절차
디자인 QA에서 발견한 이슈 공유하기
어디가 잘못되었는지 엔지니어가 정확하게 알 수 있도록 작성하는 것이 좋음
잘못 개발된 화면과, 원래의 디자인 화면을 기획 의도와 함꼐 전달
조직에 따라 다르지만 지라나 트렐로 같은 프로젝트 관리 툴 사용 시 관리하기 좋게 발견한 이슈를 업무 티켓 형태로 전달하는 것 추천
디자인QA에서 발견한 이슈 공유하는 업무 티켓 예시
이슈의 중요도 정의하기
HW. 테스트케이스 작성 + 디자인 QA로 발견한 이슈 공유하기
테스트케이스 작성하기
화면 이름입력
조건 정상
테스트 케이스 모든 텍스트필드에 정상 값 입력
입력값 정다연
기댓값 주민등록번호 입력칸으로 이동
테스트 환경 iOS/Android/Web
조건 에러
테스트 케이스 형식에 맞지 않는 값 입력
입력값 정다연123456789101112
기댓값 텍스트가 길어 표시가 어려울 경우 ...처리
테스트 환경 iOS/Android/Web
디자인QA로 발견한 이슈 공유하기
Fail
이름을 길게 썼더니 글자가 텍스트 필드를 넘어감
기대 결과
원래 구현되야 하는 것은
정다연123456789...
디자인 툴은 일반적으로 디지털로 이미지를 만들거나 편집할 수 있는 컴퓨터 프로그램임
디자이너에게 디자인 툴은 강력한 무기
좋은 디자이너라면 상황에 맞는 디자인 툴이 무엇인지 알고 잘 활용할 수 있어야 함
디자인 툴의 종류
인터페이스 디자인 툴
디지털 제품의 화면 인터페이스를 그리기 위해 사용하는 툴
대표적으로 피그마, 스케치, XD가 있음
주로 백터 방식을 기반으로 하는데, 다양한 디바이스 화면에 대응해야할 떄가 많아 디자인한 화면을 여러 크기로 늘리고 줄여도 문제 없도록 하기 위한 목적임
그래픽 디자인 툴
비주얼 그래픽 이미지를 만들 때 사용하는 툴
주로 사진 편집, 일러스트를 그려 원하는 이미지를 만듦
대표적으로 포토샵, 일러스트레이터가 있음
3D 그래픽 디자인 툴
3차원 그래픽을 만들 때 사용하는 툴
대표적으로 시네마 4D, 블렌더가 있음
모션 그래픽 디자인 툴
그래픽 리소스를 활용해서 영상을 만들거나 촬영한 영상을 편집할 때 사용하는 툴
대표적으로 프리미어, 애프터이팩트가 있음
비트맵과 백터의 이해
비트맵 이미지는 비트 정보를 가진 픽셀이 모여 만들어진 이미지
카메라로 찍은 사진, 컴퓨터상 주고받는 이미지의 대부분이 비트맵 이미지
대표적인 비트맵 이미지 파일 확장자로는 .jpeg, .jpg, .png, .gif가 있음
비트맵 이미지의 장점
픽셀 하나하나가 이미지를 이루는 요소로 백터보다 정교하게 이미지 표현
비트맵 이미지의 단점
이미지 안의 픽셀 수가 많을수록 품질이 좋아지지만, 용량도 함께 커짐
이미지 크기 편집 시 원본 이미지의 픽셀 수가 변해 손상이 생김
백터 이미지는 그래픽을 수학적인 함수 공식으로 표현한 것을 말함
점과 점을 연결해 선을 만들고, 선과 선을 연결해 면을 만드는 방식으로 이미지를 그림
대표적인 백터 이미지 파일 확장자로는 .svg, .eps, .ai가 있음
백터 이미지의 장점
백터 이미지는 좌표계(x, y)의 점으로 표현하는 것이기 때문에 이미지를 줄이거나 키워도 손상이 생기지 않음
좌표가 적힌 텍스트 파일로 저장되기 때문에 비트맵과 비교해 용량이 매우 적음
백터 이미지의 단점
색 표현에 한계가 있어 사진 같은 이미지 그래픽의 섬세한 작업은 어려움
그래픽 모양을 좌표로 저장하기 때문에 복잡한 이미지를 백터로 만들면 파일 용량이 매우 커질 수 있음
사용하는 곳에 따라 호환성에 문제가 생길 수도 있음
피그마는 클라우드 기반, 멀티 플랫폼 지원으로 여러 사용자가 동시에 파일을 열고 편집하는 것이 가장 큰 특징이자 장점
전 세계에서 가장 많이 쓰는 인터페이스 툴
스케치는 개인 로컬 컴퓨터 기반으로 동작, 안정적이라는 장점
피그마 이전까지 가장 많이 쓰고, 인기 있는 인터페이스 디자인 툴
하지만 2020년부터 피그마가 무섭게 성장하며 점유율의 대부분을 빼앗김
MacOS 기반 프로그램이라 애플 컴퓨터를 가진 사람만 사용할 수 있다는 단점
어도비XD는 어도비 Creative Cloud 플랜을 구독한다면 추가 비용을 없이 무료로 사용할 수 있다는 것이 큰 강점이 있음
평소 어도비 인터페이스가 익숙한 분들은 어렵지 않게 적응할 수 있는 것도 XD만의 장점
단점은 파일을 클라우드 형태로도 저장할 수 있지만 기본적으로 로컬 파일 저장 방식으로, 여러 사람이 다 함께 작업하기는 좋지 않음
프로토타이핑 툴은 화면의 움직임이나 인터랙션을 구현할 수 있도록 도와주는 툴
주로 제품을 실제로 개발하지 않고 아이디어나 컨셉을 테스트하기 위해 사용
사용자 테스트 뿐 아니라 팀원들에게 디자인을 효과적으로 공유하고 싶을 때 활용
구현 정도에 따라 Lo-fi 프로토타이핑 툴과 Hi-fi 프로토타이핑 툴로 나뉨
인터랙션 디자인은
주로 제품에서 말하는 인터랙션은 사용자가 제품을 사용하며 반응을 주고 받는 것을 말함
사용자가 제품을 사용하며 적절한 반응을 주고받고 막힘없이 서로 간 소통을 도움
프로토타입이 중요한 이유 → 인터랙션 디자인을 테스트하기 위해
디자인 정지된 화면이기 때문에 실제 사용자가 제품을 이용하는 과정을 담지 못함
UX는 정지 화면이 아닌 서로 소통하는 인터랙션 과정에서 생겨나는 경험
사용자가 어려움 없이 화면 간 이동, 원하는 기능을 찾고, 잘 사용하는지 보려면 동작하는 프로토타입을 테스트하는 게 정확
피그마 프로토타이핑
화면을 피그마로 디자인 시 파일을 내보내거나 불러오는 과정 없이 간편하게 프로토타입을 만들 수 있는 것이 큰 장점
하지만 실제 데이터를 넣거나 복잡한 애니메이션은 구현하기 어려움
피그마 프로토타이핑의 특징
디자인 → 프로토타이핑으로의 빠른 전환
간편한 경로 연결
프로토파이
코딩 없이 실제 제품과 비슷한 수준의 프로토타입을 만들 수 있다는 것이 큰 장점
눈에 보이는 GUI를 클릭해 작업할 수 있어, 코드가 어려운 디자이너도 편리하게 사용 가능
프로토파이의 특징
Hi-fi 수준의 기능
Conditions (조건부 트리거)
즉, 특정 상황일 때 이동하거나 색상이 변하는 등의 조건을 걸 수 있는 기능
프레이머
코드 기반으로 실제 제품과 가장 유사한 수준으로 프로토타입을 만들 수 있음
Hi-fi 프로토타입으로 코드 기반의 툴
인터페이스 디자인 툴 기능을 함께 제공하여, 디자인부터 프로토타이핑까지 한 번에 할 수 있음
만든 프로토타이핑을 실제 제품으로 배포까지 가능
프레이머의 특징
재사용성
즉, 코드 재사용성, 컴포넌트 재사용성
CMS
Content Management System의 약자로 콘텐츠 관리 시스템으로 기능을 통해 콘텐츠 작성 및 데이터 관리
데이터를 이용해 리스트나 상세 화면에 노출되도록 활용
배포된 화면을 분석할 수 있는 Analytics 기능도 제공하기 때문에 방문자 수와 어떤 경로로 들어왔는지 등을 확인할 수 있음
HW. 피그마로 간단한 프로토타입 만들어보기
디자인 원칙은 인지심리학의 관점에서 디자인할 때 지켜야 할 규칙을 정해놓은 것
많은 사람들이 비슷하게 느끼고, 행동하는 방식에 기초해 디자인하는 방법을 제시
디자인 원칙을 기반해 디자인 시 사람들이 편안하게 느끼고 자연스럽게 행동하도록 유도할 수 있고, 사용성이 높은 제품을 만들 수 있도록 도와줌
디자인 원칙의 종류
게슈탈트 심리학은 사람이 이미지를 인식할 때 주변에 있는 요소 간의 관계와 맥락에 영향을 받는다는 이론
게슈탈트 심리학의 원리
유사성의 원리
크기나 형태, 방향, 색 등의 특성이 비슷한 것끼리 묶어서 지각하려는 경향
비슷한 것을 하나로 묶는 것은 인간의 본성
즉, 모양, 크기, 색상, 방향 등
근접성의 원리
가까운 것끼리 묶어서 지각하려는 경향
즉, 여백 등
모양 < 색상 < 여백
폐쇄성의 원리
공백이 있더라도 틈이나 간격을 메워서 닫힌 형태로 인식하려는 경향
연속성의 원리
연속적으로 직선이나 곡선을 이루는 요소를 잘 인지하는 경향
공통성의 원리
같은 방향으로 움직이는 것들끼리 더 관련성이 높다고 인식하는 경향
왜 게슈탈트 심리학을 알아야 하는가?
형태의 정보 중 필요없는 건 지우고 기억하기 쉬운 상태로 정리해 받아들임
착시 현상, 시각 자극을 인지하는 과정에서 주변의 다른 정보에 영향을 받아 원래의 사물에 대해 시각적인 착각이 생기는 현상
사람의 의식이 기본적으로 통일성, 연속성, 유사성을 요구하여 착시 발생
게슈탈트 심리학이 중요한 이유
사용자가 제품을 경험하는 데 영향
UX 비주얼 디자인 원칙
좋은 UX를 설계할 수 있도록 도와주는 비주얼 디자인 원칙
UX 비주얼 디자인 원칙의 힘
시각적으로 매력적인 이유를 근거로 들어 설명할 수 있도록 도와줌
UX 비주얼 디자인 원칙을 잘 활용 시 심미적 아름다움 뿐 아니라 사용성을 높여줌
원칙에 따라 잘 설계된 디자인은 사용자의 제품 몰입 및 사용 편리
UX 비주얼 디자인 원칙에는
스케일
상대적인 크기를 사용하여 구성의 중요도와 순위 표시
가장 중요 요소는 덜 중요 요소보다 크게 표현
당연하게도 크기가 크면 더 주목
시각적으로 보기 좋은 디자인은 일반적으로 3가지 이하 크기 사용
시각적 위계
중요 순서에 따라 시선의 흐름이 이동하도록 디자인 하는 것
크기, 색상, 간격, 배치 등을 통해 표현
사용자가 화면에서 정보를 찾는 데 어려움을 겪는 경우 명확한 시각적 위계가 없을 가능성이 높음
명확한 시각적 위계를 만들기 위해 2~3개 정도의 텍스트 크기 사용
중요 요소는 채도가 높고 색상 대비가 크게, 덜 중요 요소는 색상 대비가 크지 않도록 적용
균형
디자인 요소 간 적당한 배열이나 비율을 주는 것
수직이나, 수평의 가상 축에 비슷한 양의 시각적 정보가 배치, 꼭 대칭이 아니어도 괜찮음
균형에 활용할 수 있는 요소들
대칭은 안정적이며 정적인 느낌
비대칭은 역동적이며 신선한 느낌
대비
눈에 띄게 구별되도록 강조하기 위해 두 요소 간의 차이를 두는 것
특정 부분을 사용자에게 돋보이게 하고 싶을 때 사용
주로 명암의 차이를 주거나 색상의 차이를 주는 방법을 많이 사용
UX/UI 심리학 법칙
제이콥의 법칙
사용자는 새로운 제품을 사용할 때 이미 알고 있는 익숙한 방식으로 작동하길 원한다는 법칙
인터페이스를 익히는데 드는 정신적 에너지가 감소할수록, 사용자가 목표 달성에 투자할 에너지 증가
목표를 성공적으로 달성할 확률 증가
멘탈모델이 큰 영향
멘탈모델은
자신이나 타인, 개념, 사물, 현상 등 다양한 대상에 대해 갖고 있는 생각 패턴
개개인마다 경험과 학습을 통해 형성되고 사용자의 생각과 행동, 의사결정에 영향을 미침
피츠의 법칙
터치 대상에 도달하는 시간은 대상까지의 거리와 크기와 함수 관계에 있다는 법칙
쉽게 말해, 사용자가 인터랙션해야 하는 대상은 거리가 가깝고, 크기가 커야 사용성이 좋다는 뜻
힉의 법칙
의사결정에 걸리는 시간은 선택지의 개수와 복잡성에 비례해 늘어난다는 법칙
사용자가 선택해야 하는 선택지 증가 시 결정까지의 시간도 증가
사람의 뇌에 한꺼번에 복잡하고 많은 양의 정보가 들어오면 이를 처리하기 위해 인지 부하 발생
밀러의 법칙
보통 사람은 작업 기억에 7(±2)개 정도의 항목밖에 저장하지 못한다는 법칙
밀러의 법칙에서 꼭 기억할 것은 개수가 아닌 정보 덩어리임
기업의 디자인 원칙은 기업의 철학을 담고, 심미성과 사용성이 높은 제품을 만들 수 있도록 제시하는 가이드
기업과 제품의 비전을 공유
공통된 느낌을 주는 일관된 원칙 제시
심미적 UI와 인터렉션을 구현하는 동시에 사용성을 지키는 방법 안내
의사결정 기준, 시간 절약
HW. 디자인 원칙의 실제 사례 찾아보기
- 게슈탈트 심리학에서 3가지를 골라 실제 사례를 찾아보세요.
유사성의 원리
모양을 이용한 유사 관계 형성
멜론
근접성의 원리
아마존 북스
폐쇄성의 원리
다방
- UX 비주얼 디자인 원칙에서 3가지를 골라 실제 사례를 찾아보세요.
스케일
기후행동 기회소득
시각적 위계
유튜브
균형
인스타그램
- 심화 아래에 1가지를 골라 좋은 사례라고 생각되는 제품의 화면을 찾아보고 그 근거를 게슈탈트 심리학, UX 비주얼 디자인 원칙, UX/UI 심리학 법칙을 활용해서 설명해 보세요.
핀터레스트의 검색 화면
게슈탈트 심리학에서 근접성의 원리가 사용되었는데 관련성 있는 것을 보기 편리함
UX 비주얼 디자인 원칙에서 스케일이 사용되었는데 눈에 띄고 크기가 큰 것이 제일 주목됨
UX/UI에 영향을 주는 심리학 법칙의 밀러의 법칙, 정보 덩어리로 묶인 수가 적어 좋음
레퍼런스 분석은 얻고 싶은 정보를 기준으로 다양한 사례를 수집, 세부 요소들로 쪼개어 살펴봄
세부 요소들을 관찰하며 좋은 점, 나쁜 점, 그리고 그 이유를 찾고 생각함
분석을 통해 얻은 인사이트를 정리
레퍼런스 분석은 왜 하는가?
UX/UI 디자이너는 시장과 사용자의 문제 발견, 여러 고민을 통해 해결책을 제시하는 사람임
레퍼런스 분석 과정에서 디자인에 대한 영감을 얻고 좋은 디자인을 구분하는 지식을 쌓을 수 있음
좋은 사용성을 가진 디자인과 나쁜 UX 패턴을 가진 디자인을 고민해 보며 사고력을 기를 수 있음
이 과정에서 쌓은 영감과 지식을 디자인할 때 적용할 수 있고 디자인 능력을 높이는 길이 됨
래퍼런스를 분석하는 방법
화면 구조 분석
화면을 구성하는 요소는
파운데이션 더 이상 세부 속성으로 쪼개지지 않는 가장 기본이 되는 요소
예로는 색상, 폰트, 아이콘
엘리먼트 파운데이션이 모여서 만드는 요소
예로는 버튼, 뱃지, 탭 등
모듈 엘리먼트가 모여서 만드는 요소
예로는 리스트, 캐러셀, 네비게이션 등
페이지 모듈이 모여서 만드는 최종 화면
홈, 마이페이지, 장바구니, 회원가입 등
화면을 해부한다고 생각하고 요소들을 자세히 나누는 것
토스의 화면 구조 분석 예시
디자인 원칙 기반 분석
UI 요소들을 디자인 원칙들을 기준으로 분석해 보는 단계임
쪼개본 UI 요소들을 디자인 원칙에 대입해 보며 사용성이 높은지, 심미적으로 아름다운지 등 다양한 관점에서 디자인 평가
나쁜 점도 타산지석의 사례로 삶을 수 있으니 좋은 점과 나쁜 점 모두 다양하게 찾기
이 단계의 핵심, 주장과 그에 알맞은 논리적 근거를 찾는 것
인사이트 정리하기
분석한 제품에 참고 및 적용하면 좋을 만한 것들을 그룹화하여 정리해 볼 것
한 단계 더 나아가 아쉬운 점, 나쁜 사례를 어떻게 더 나아지게 할 수 있을지 개선점까지 생각해보면 훨씬 도움이 됨
UX/UI 디자인 패턴은 디지털 제품, 주로 앱이나 웹에서 자주 사용되는 디자인 요소임
다수의 제품에서 공통으로 볼 수 있는 UX/UI 디자인 패턴은 보편적인 범위 내에서 디자인하고 동작하는 것이 좋음
사용자는 기존 경험과 학습된 내용 바탕으로 행동하기 때문
자주 사용되는 UX/UI 디자인 패턴은 이런 것이 있음
온보딩 사용자가 제품을 처음 만나는 과정
온보딩 단어의 원뜻은 '조직 내 새로 합류한 사람이 빠르게 조직 문화를 익히고 적응하도록 돕는 과정'
제품에서 온보딩은 서비스를 처음 만나는 사용자가 기능을 잘 이해, 가치를 느낄 수 있도록 돕는 과정
온보딩의 종류
튜토리얼 제품이 매우 복잡하거나 어려운 경우 조작법이나 설명을 넣는 방식
특정 기능을 강조하고 싶을 때도 사용
가치 보여주기
제품을 사용하며 얻을 수 있는 가치를 몇 개의 화면으로 보여주는 방식
가치를 보여주는 온보딩에 함께 고려하면 좋은 것
온보딩 과정을 보고싶지 않은 사용자는 바로 제품의 홈으로 이동하도록 skip 기능 제공
캐러셀 이용해 사용자가 화면을 넘기지 않아도 자동으로 넘어가도록 구성
사용자가 화면을 직접 넘기지 않아도 되는 동영상 구성
개인화 설정하기
개인 맞춤 정보를 제공할 수 있도록 몇 개의 카테고리와 선택지를 주고 정보를 입력하게 하는 방법
개인화가 핵심 기능인 서비스에서 주로 사용되는 유형
로딩 앱이나 웹에서 화면이 그려지는 동안 사용자가 잠깐 기다려야 할 때 보여주는 화면
로딩의 종류
스피너 아이콘 혹은 애니메이션 활용
데이터를 서버에서 불러오거나, 반대로 데이터를 보낼 때 앱과 사용자와의 상호작용 도움
연속적인 움직임을 통해 시스템이 정보를 처리하고 있음을 사용자에게 알려줌
움직이는 모션, 애니메이션은 로딩 지속 시간에 대한 사용자의 인식을 낮춰 기다리는 시간을 짧게 느끼게 함
프로그래스 바
현재 상황을 시각적으로 파악할 수 있게 하는 로딩 바
진행 상황을 유저에게 알려 주어야 하는 케이스에 사용
스켈레톤
불러오는 화면의 빈 버전으로, 화면에서 가장 먼저 노출되어 사용자가 실제 페이지를 예측할 수 있도록 함
단, 스켈레톤이 실제 화면의 로드를 방해하는 주객전도의 상황이 생기지 않도록 주의
가능한 가장 단순한 모습의 회색 박스를 사용하여 불러오는 페이지를 예측할 수 있는 형태로 표현하는 것이 좋음
검색 사용자가 원하는 정보를 빠르게 찾을 수 있도록 키워드로 정보를 찾는 방법
검색 화면의 종류
기본 검색 화면
제품에서 차지하는 검색의 중요도에 따라 검색 기능의 위계가 다른 것에 주목
연관 상품 추천 / 연관 검색어 노출
검색 화면에서는 키워드 검색을 넘어 전반적인 정보의 탐색이 이뤄지는 공간이기도 함
Empty view: 검색 결과가 없을 때
사용자가 결과를 보여줄 수 없을 때 빈 화면을 어떻게 채울지 고민해볼 것
추천 혹은 베스트 상품으로 이어지는 행동을 유도하는 것도 방법
회원가입
리스트
카드
캐러셀
