1. UXUI 입문 강의 2주차

​

​

​

01) 디자인 씽킹

• 논리적으로 제품을 만들 수 있도록 도와주는 프레임 워크

→ 제품을 만드는 틀이라고 보면 됨.

• 사용자에 대한 이해를 기반으로 문제를 찾고 제품을 만들어 검증하는 프로세스.

​

​

​

▫︎ 디자인 씽킹의 5단계

1. 공감하기

• 사용자의 인터뷰나 관찰 등의 다양한 방법으로 사용자와 공감대를 맞추고, 그들의 경험을 완전히 이해하기 위해 노력하는 단계

1. 문제정의하기

• 공감으로 얻은 정보를 해석해 사용자가 불편함을 느끼는 지점을 발견하는 단계

1. 아이디어 발산하기

• 다양한 아이디어를 발산하고 가장 적합한 아이디어를 선택

1. 프로토타입 만들기.

• 사용자가 아이디어를 경험할 수 있도록 구체적인 서비스를 구현하고 개발.

1. 테스트하기

• 프로토 타입을 사용자가 직접 사용해보게 하고 피드백을 받음

5단계의 프로세스는 한 방향으로(1번부터~) 진행하지 않아도 됨.
필요에 따라서 되돌아오고 일부만 반복하기도 함.

​

​

​

▫︎ 디자인 씽킹을 배워야하는 이유

• 디자인은 아이디어를 눈에 보이도록 하는 것.
• 빠른 시간안에 논리적, 현실적으로 가능하도록 해야함.

→ 디자인씽킹은 아이디어를 빠른 시간에 논리적, 현실적으로 눈에 보이도록 해주는 도구.

​

​

​

02) DATA-Driven 과 디자인씽킹

​

​

​

▫︎ 데이터 드리븐이란?

• 데이터 드리븐은 데이터를 중심으로 의사결정을하는 것.

  → 데이터 드리븐이라는 말이 앞에 붙는 다는 것은 데이터를 기반해 결과물을 만든 다는 것.

• 데이터 → 사용자에 대한 이해

• 온라인 기반의 생활 양식으로 사용자의 행동 대부분이 데이터로 쌓이고 점점 더 데이터를 많이 활용 할 수 있게 되어, 여러 데이터를 통해 사용자를 더 잘 이해할 수 있게 되고 그들에게 맞는 정확도 높은 제품 개발 가능.
  ​

​

​

▫︎ DATA-Driven의 중요성

• 정확도 높은 의사결정.
  • 사용자 데이터라는 명확한 근거 기준 → 객관적으로 의사결정 할 수 있도록 뒷받침
    
  • 의사결정에 제품을 만드는 사람의 취향이나 주관이 들어가지 않음.
• 빠른 의사결정으로 제품 개발 속도 상승.
  - 데이터는 다수의 사람이 빠르게 공감할 수 있는 수단.
  - 다수가 같은 의견이면 결정이 빨라지고, 전체적인 제품 개발 속도 상승.
  ​

​

​

▫︎ DATA-Driven과 디자인씽킹

데이터를 체계적으로 잘 활용할 수 있는 프로세스가 중요!

• 데이터가 정답을 말해주지 않음
• 데이터는 도구 → 사람의 활용에 따라 결과 달라짐.
• 어떤 데이터를 볼 건지, 어떻게 해석할 건지는 사람의 몫
• 데이터를 활용하더라도 개인에 따라 주관적으로 의사결정할 위험이 있음

→ 데이터 = 사용자를 이해하는 도구

→ 디자인 씽킹 = 데이터를 체계적으로 활용할 수 있게 해주는 과정

→ 우리는 데이터 드리븐 디자인 씽킹을 해야함.
​

​

​

[디자인씽킹 1단계] 공감하기 empathy

▫︎ 디자인 씽킹에서 가장 중요한 단계

• 회사의 매출은 사용자에게서 창출됨. → 사용자를 정확히 아는 것이 중요
• UXUI 디자이너는 끈질기게 사용자를 조사하고 분석해서 더 많은 사용자가 제품을 잘 쓸 수 있도록 디자인 해야함.
  ​

​

​

▫︎ 공감하기란?

<사용자를 완벽히 이해하는 것이 먼저임>

• 인터뷰나 관찰등의 다양한 방법으로 사용자와 공감대 형성, 그들의 경험을 완전히 이해하기 위한 노력이 필요
• 공감대 형성 후, 충족되지 않은 욕구 (NEEDS)와 불편한 점 (Pain point)들을 파악하며 문제에 다가감.
  ​

​

​

▫︎ 공감하기 단계에서 활용할 수 있는 방법들

​

<A-E-I-O-U 관찰법>

• 무엇인가요?

  • 정보를 체계적으로 수집할 수 있게 5가지 분류로 수집하는 관찰법

• 언제 쓰나요?

  인터뷰나 현장 조사에서 사용자를 관찰 할 일이 있을때 활용
  

• 어떻게 활용하나요?

  • 활동 Activities

  • 환경 Environments

  • 상호작용 Interactions

  • 사물 Objects

  • 사용자 Users

    → 5가지 주제가 적힌 종이나 시트 준비 후 대상을 관찰하면서 발견한 내용을 해당 주제에 맞춰 적기.

​

​

공감지도 (Empathy map)

• WHAT
  • 6개의 도표를 채우며 사용자의 숨겨진 어려움과 욕구를 유추할 수 있도록 도와주는 시각화 도구
• WHEN
  • A-E-I-O-U 관찰법과 마찬가지, 사용자를 관찰 할 때 활용
• HOW

  • 대표 사용자가 누구인지 생각, 가상 인물의 입장이 되어 사분면에 생각과 느낌, 말과 행동, 보는것, 듣는것을 정리.

    → 사용자가 겪을 어려움과 욕구를 유추.

​

​

인터뷰

• WHAT
  • 사용자 파악을 위한 가장 대표적인 방법
  • 다양한 질문 던진 후 대답을 들으며 정보 얻기
• WHEN
  • 제품개발전 두루두루 사용
• HOW
  - 인터뷰를 통해 얻고자 하는 목적을 분명하게 설정
  - 대답을 듣기에 가장 적절한 사용자 그룹을 생각
  - 그룹의 특성을 생각하며 대상 모집
  - 인터뷰 대상은 5명 정도
  - 미리 궁금한 것들 질문지 작성
  - 대상을 부르거나 있는 곳으로 방문.
  - 예 아니오대답으로 할 수 있는 질문 보다 다양한 대답을 들을 수 있는 개방형 질문
  ​

​

​

▫︎ A-E-I-O-U로 사용자 이해하기

<사용자 관찰 혹은 해석할 때 사용할 수 있는 5가지 분류 체계.>

• 활동 ACTIVITIES

  • 관찰하는 대상이 어떻게 움직이는지 살펴보기

  • 사용자의 모든 행동을 눈여겨 보기

    → 이야기를 나누는 중에 먹거나 보인 행동

    → 특별한 움직임이나 반응, 제스쳐

    → 목적을 이루기 위해 선택한 방법

• 환경 ENVIRONMENTS

  • 관찰하는 곳이나 인터뷰 하는 장소 주변 둘러보기

  • 활동이 일어나는 모든 시간적, 공간적 요소

    → 공간의 조명

    → 흘러나오는 음악

    → 디지털 환경 너머의 물리적 공간(Ex. 지하철, 회사)

    → 개인공간, 공용공간

• 상호작용 INTERACTIONS

  • 관찰하는 대상이 어떤 것과 영향을 주고 받는지 관찰

  • 사람이나 사물 사건 등 다양한 관계 사이에서 발생되는 상호작용

  • ex) 카페에 방문한 사용자가 키오스크 사용법을 정확하게 알고 있는지, 주문하는데 어려움은 없는지, 곤란한 상황에서 어떻게 행동 하는지

    → 상호작용으로 인한 감정변화

    → 일상적으로 반복하는 루틴

• 사물 OBJECTS

  • 관찰하는 대상 주변으로 눈에띄는 것들이 있는지 확인

  • 당연하게 있어야하는 물건 외에 특이한 물건

    → 사람혹은 활동, 환경과 연관이 있는 것

    → 사물이 가진 원래 뜻과 다르게 쓰이고 있는 것

    → 공간과 어울리지 않은 특이한 물건

• 사용자 USERS

  • 관찰하는 대상을 포함하여 주변에 있는 모든 사람 살피기

    → 직접 사용자 외 영향을 받는 간접 사용자

    → 대상의 구체적인 행동이나 니즈 역할 성향 등.

    ​

​

​

[디자인씽킹 2단계] 문제 정의 하기 DEFINE

​

​

​

▫︎ 문제 정의하기란

• 공감으로 얻은 정보를 해석해 사용자가 불편함을 느끼는 지점을 발견하는 단계
• 정의된 문제로부터 아이디어가 나오기 때문에 문제정의가 되지 않으면 아이디어 만들기 불가능
• 문제정의가 잘 되었는지 판별법 체크리스트
  • 무엇이 문제인가
  • 그것이 왜 문제인가
  • 풀어야 할 문제 중 가장 중요한 것인가
    ​

​

​

문제를 잘 정의하는 것이 중요한 이유

• GIGO(garbage-in, gabage-out) 올바르지 않은 데이터를 입력하면 올바르지 않은 결괏값이 나온다는 뜻 정확한 문제정의 → 시작점, = 의미있는 결과 올바른 방향의 솔루션을 위해 현재 상태 파악 후 문제정의. ​

​

​

▫︎ 문제 정의 단계에서 활용할 수 있는 방법

​

​

<친화도 분석>

• WHAT
  • 정보를 무작위로 최대한 많이 수집한 다음, 유사한 그룹으로 묶어 결과 정리
• WHEN
  • 인터뷰, 포커스, 그룹, 필드스터디 등의 정성적인 조사 결과 분석에 유용.
  • 여러 주제로 흩어진 자료 정리 후 일정한 그룹으로 정리
• HOW
  - 해결할 문제 적기
  - 관련 정보 포스트잇에 다양하게 적기
  - 관련성 높은 것들 끼리 묶기
  - 중복, 가치가 낮은 정보는 제거 가능
  - 유사성, 상관성을 고려하여 그룹화 → 그룹 타이틀 적기
  - 그룹화한 결과 살피며 인사이트 정리.
  ​

​

<페르소나 (persona)>

• WHAT

  • 제품 사용자를 대표하는 가상인물

• WHEN

  • 사용자를 잘 이해하기 위해 가상의 페르소나 선정
  • 페르소나는 한 번 설정 후 추가 정보를 통해 더욱 정교화

• HOW
  - 인터뷰, 설문조사, 데스크 리서치 등 사용자에 대해 알 수 있는 정보 모으기
  - 페르소나 템플릿에 내용 적으며 사용자 정의
  - 페르소나 템플릿에 나이, 직업, 성별 등의 인적사항 ~ 행동, 목표, 불편함을 겪는 지점 정의
  ​

​

​

<5 WHYS>

• WHAT

  • 문제의 근본적 원인을 파악하기 위해 5번 질문 반복하는 기법

• WHEN

  • 발견한 문제에 깊이 생각해 보기 위해

• HOW
  - 분석하고 싶은 문제 적기
  - 원인이 파악 될 때 까지 5번 반복하여 질문과 대답 되풀이
  - 마지막 대답을 통해 근본적 원인 파악
  - 원인이 나왔다면 원인을 해결할 수 있는 솔루션 고민
  ​

​

​

<사용자 여정 지도 (customer Journey Map)>

• WAHT

  • 사용자가 제품을 처음 만나는 시점-끝나는 시점 경험의 흐음을 시간이나 순서등에 따라 분석하는 기법

• WHEN

  • 제품 전체의 경험을 점검하고 개선점을 찾고 싶을때 사용

• HOW

  • 만드는 제품, 혹은 특정 문제를 해결하기 위해 사용자가 하게된 행동을 순서대로 나열
  • 행동을 기준으로 여정을 몇 단계로 세분화
  • 단계마다 살펴보며 사용자의 니즈가 무엇인지 살피기
  • 제품안에서 해결해 줄 수 있는 부분이 있을지 고민하기

​

​

​

▫︎ 5WHYS를 이용해 문제 정의하기

• 질문을 통해 문제의 본질에 더 가까이 갈 수 있도록 도와주는 기법
• 5번의 질문을 반복, 표면적 문제가 아닌 근본적 원인 찾기

1. 관찰한 사용자의 문제나 이슈를 상단에 적고 시작.
2. Why 1: 기록한 내용에 대해 ‘왜?’라고 질문
3. Why 2: 첫 번째 질문에 대답 후 다시 그 대답에 대한 이유 질문
4. Why 3,4,5: 원인이 파악 될 때 까지 질문과 대답을 되풀이
5. 마지막 대답을 토대로 문제의 근본적인 원인이나 인사이트 도출

​
<예>

매출이 정체된 가상의 커머스 서비스.

Why 1 왜 매출이 몇 달째 정체하고 있을까?

👉 웹사이트에서 충분한 결제가 일어나지 않고 있다.

Why 2 왜 웹사이트에서 충분한 결제가 일어나지 않을까?

👉 장바구니에서 결제 페이지로 이동하는 과정에 큰 이탈이 발생했다.

Why 3 왜 장바구니에서 결제 페이지로 이동하는 과정에 큰 이탈이 발생했을까?

👉 장바구니에서 결제로 이동하는 퍼널을 찾지 못했다.

Why 4 왜 결제로 이동하는 퍼널을 찾지 못했을까?

👉 결제하기 버튼이 눈에 띄지 않았다.

Why 5 왜 결제하기 버튼이 눈에 띄지 않았을까?

👉 UI가 눈에 띌 만큼 부각되지 않았다.

다섯 번의 질문을 통해 가상의 커머스 서비스의 매출이 정체된 근본적인 원인을 추정
‘장바구니의 결제하기 버튼의 UI가 눈에 띌 만큼 부각되지 않았다’라는 가설을 세운 뒤엔
어떻게 해결할 수 있을지 아이디어를 고민 해야함

---

​

​

​

▪︎ [디자인 씽킹] 3단계 아이디어 발산하기 Ideate

​

​

​

▫︎ 아이디어 발산하기

• 정의한 문제를 해결할 다양한 아이디어 발산, 가장 적절한 아이디어 선택
• HMW, 브레인 스토밍, 아이디어 스케치 등 다양한 방법으로 아이디어 도출 후 가장 중요하다고 생각 되는 아이디어 찾아 집중

​

​

​

▫︎ 아이디어 발산하기 단계에서 활용할 수 있는 방법들

<HMW(How Might We?)>

• WHAT

  • “만약~할 수 있다면 어떨까” 라고 질문을 사용해 가정과 상상 속 아이디어 이끌어 내기

• WHEN

  • 새로운 방식으로 아이디어 떠올려 보고 싶을때 사용

• HOW
  - 사용자가 겪는 어려움 보다 니즈에 집중
  - 우리가 [어떤 역할]로, 어떻게 하면 [목적과 대상]을 위해 [니즈]를 해결 할 수 있을까라는 질문에서 대괄호 안의 내용 채우기
  ​

​

< SCAMPER >

• WHAT

  • 7개의 키워드로 질문 던진 후 대답 생각하고 생각을 전환

• WHEN

  • 새로운 제품에 대한 다양한 아이디어를 발산하는데 활용하기 좋음

• HOW
  - 7개의 키워드에 하나씩 접목 → 새로운 아이디어 떠올리기
  ​

​

<브레인스토밍>

• WHAT

  • 여러사람이 모여 특정 문제에 대해서 최대한 많은 아이디어 발산하는 방식

• WHEN

  • 다양한 아이디어 필요할때

• HOW
  - 사람들과 논의할 주제 정하기
  - 키워드를 보고 연상되는 것을 적고 잘 보이는 곳에 부착
  - 다른 사람들이 적은 내용을 보고 추가로 연상되는 것을 메모하여 이어 붙이기
  - 과정 반복
  - 질<양
  ​

​

< YES AND >

• WHAT

  • “네~그리고”라는 대화법으로 상대방의 말에 동의 후 이야기 이어나가기

• WHEN

  • 회의에서 생산적인 논의와 새로운 아이디어 만들고 싶을때 사용

• HOW
  - 말할때 항상 맨 앞에 “네~그리고” 붙이기
  - 대화가 어색하지 않게 상대방의 의견 경청, 이어지는 내용 덧붙이기
  ​

​
​

​

▫︎ 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단계] 프로토타입 만들기

▫︎ 프로토타입 만들기란?

• 사용자가 아이디어를 경험할 수 있도록 구체적인 제품이나 서비스로 개발
• 다양한 아이디어 중 하나의 아이디어 선정, 가능성 판단하기 위해 최소 기능 중심으로 빠르게 제작
  ​

→ 최소기능이란?

: MVP (MINIMUM VIABLE PRODUCT)

목적을 달성하기 위한 최소한의 기능만 구현한 제품

리소스를 효율적으로 쓰기 위한 목적, 아이디어 확인 가능한 핵심 기능만 최소한으로 만드는 것

• 문제를 해결하는 주요컨셉이 프로토 타입으로 잘 표현되어야 아이디어를 정확히 평가 가능.
  ​

​

프로토타입의 목적은 최대한 빠르게 아이디어의 가능성을 검증하는 것

프로토타입의 핵심

1) 최대한 간결하면서
2) 가능한 한 빠르게 실패를 확인하고
3) 빠르게 반복하는 것입니다.

​

​​

​

▫︎ 프로토 타입 단계 활용할 수 있는 방법

<와이어 프레임>

• WHAT

  • 와이어프레임은 화면의 인터페이스를 단순한 선과 도형으로 표현한 것

• WHEN

  • 아이디어를 구체적인 개념으로 발전시키고, 시각화하여 공유하고 싶을 때 사용

• HOW
  - 종이에 펜으로 스케치, 디자인 툴을 이용해 그리기
  - 와이어프레임의 핵심은 시각적 측면이 아닌 구조에 집중
  - 단순한 선과 도형만 사용해서 기능와 플로우가 잘 드러나도록 표현
  ​​

​

<목업>

• WHAT

  • 실제 프로덕트의 시각적인 컨셉을 담은 화면

• WHEN

  • 본격적인 UI 디자인 전에, 팀원들과 미리 시각적인 컨셉을 공유하고 피드백을 주고받을 때 사용

• HOW
  - 와이어프레임에서 발전된 형태
  - 색상, 텍스트 스타일, 비주얼 컨셉 등이 표현
  - 모든 화면을 다 그릴 필요 X
  - 컨셉이 잘 드러나는 화면을 몇 가지만 제작
  ​​

​

<프로토타입>

• WHAT

  • 와이어프레임이나 목업의 화면에서 실제 움직임을 구현한 것

• WHEN

  • 실제 제품을 만들기 전에 기능 및 사용성을 평가하기 위해 사용

• HOW
  - 프로토타이핑 툴인 Invision혹은 Protopie를 이용
  - 피그마 자체 기능인 Prototyping을 사용하여 동작을 구현
  ​​

​​​

​

▫︎ LO-FI(Low fidelity) & HI-FI (High fidelity)

일반적으로 프로토타입이라고 하면,
화면의 움직임을 구현해 사용자가 조작할 수 있도록 만든 모형

최종 제품과 얼마나 유사하게 구현했는지의 정도에 따라
Lo-Fi(Low fidelity)와 Hi-Fi(High fidelity).
사용자에게 테스트하고자 하는 목적에 맞게 적절하게 선택.

​​

​

Lo-fi(Low fidelity) 프로토타입

• 시각적 부분이 크게 고려되지 않은 와이어프레임 수준으로 움직임 구현한 프로토타입
• 디지털 툴 사용 X
• 펜과 종이로 그려서 테스트 OR 클릭과 화면전환 정도로 구현된 단순한 프로토타입

→ 아이디어를 빠르게 검증해 보고 싶을 때 이용
​​

​

Hi-fi(High fidelity) 프로토타입

• 최종제품과 유사한 수준으로 구현한 프로토타입
• 색상과 텍스트 스타일 등의 비주얼과 인터렉션의 움직임 모두 실제 제품 컨셉과 유사

→ 구체적인 기능이나 화면의 사용성 시험

→ 사용자가 프로토 타입이라는 것을 인지하지 못할 정도로 몰입한 경험을 테스트 하고 싶을때
​​

​​​

​

▪︎ [디자인씽킹 5단계] 테스트하기 Test

▫︎ 테스트란?

• 테스트는 프로토타입을 사용자가 직접 사용해보고 피드백을 받는 단계
• 테스트 과정 관찰, 피드백 받고 사용자를 더 깊이 이해하게 됨
• 가설이 맞았는지, 틀렸는지 확인 후 다시 문제 정의로 돌아가 사용자의 관점 다듬기 → 프로토타입 개선
  
• 실무에서는 때에 따라 일부 단계 생략
• 보통 이러한 5단계의 과정을 반복하여 제품 고도화
  ​​

​

▫︎ 테스트 단계에서 활용할 수 있는 방법들

<사용성 테스트 (Usability Test)>

• WHAT

  • 사용자에게 직접 제품을 보여주고 평가를 받는 것

• WHEN

  • 제품 출시 전, 후 모두 가능합니다. 제품 개발 단계 전반에 언제든지 제품을 평가하고 싶을 때 활

• HOW
  - 테스트에는 진행자, 참가자, 관찰자 그리고 평가할 제품이 필요
  - 평가하고 싶은 내용을 시나리오로 준비
  - 참가자에게 수행하도록 안내
  - 테스트가 끝난 후 발견한 문제점을 모아 개선점을 도출
  ​​

​

<휴리스틱 평가 (Heuristic evaluation)>

• WHAT

  • 특정 기준에 따라 제품의 사용성을 평가

• WHEN

  • 화면이 사용자가 쓰기 편리하게 설계되었는지 평가하기 위해 활용

• HOW
  - 휴리스틱 평가 기준이 적힌 문서를 만들어 3~5명의 평가자가 동일한 화면을 독립적으로 평가
  ​​

​

<린캔버스 (Lean Canvas)>

• WHAT

  • 제품을 평가할 수 있는 9개의 항목으로 구성된 도표

• WHEN

  • 제품의 사업성 측면에서 놓친 것은 없는지 확인하기 위한 체크리스트로 사용

• HOW

  • 한 장짜리 종이에 다음의 9가지 항목에 대한 질문을 스스로 던져보고 답을 적기

​​

​

<역할극 (Role Playing)>

• WHAT

  • 실제 제품을 사용하는 상황을 가정하고 사용자 역할을 대신해 보면서 문제점을 찾아보는 방법

• WHEN

  • 실제 사용자를 만날 수 없는 상황에서 사용자를 이해해 보기 위해 활용

• HOW

  • 사용자가 어떤 방식으로 경험할지 시나리오를 정하고 각자 역할을 맡기

  • 특정 상황에서 사용자가 어떻게 반응할지 떠올려보고 행동

  • 서로를 관찰하면서 발견한 문제를 적어보고 사용자를 이해하기.

    2. UXUI 입문 강의 3주차

    ​​

​

▪︎ 제품팀

• 제품을 만들기 위해서 다양한 사람들이 모인 팀 (PM, PO / 디자이너/엔지니어+마케터,데이터애널리스트등)

​​

​

<목적조직>

• 특정한 목적을 달성하기 위해 여러 직무의 사람들이 모인 팀
• Ex).핀테크 회사→ 대출팀, 카드팀, 예금팀 적금팀
• 일반적으로 제품팀이라고 하면 목적조직을 의미함
• 목적조직은 스쿼드나 사일로 라고 부름
• 제품의 목표를 달성하기 위해 다양한 직무의 사람이 모여있는 팀이기 때문에 속도가 빠르며 효율적임.
  ​​

​

<기능조직>

• 유사한 직무 끼리 구성된 팀
• 기능조직은 주로 챕터 라고 부름
• 비슷한 일을 하는 사람들끼리 모였기에 전문 분야에 대해 깊게 논의하고 서로의 발전을 도움
  ​​

​

<매트릭스조직>

• 구성원이 기능 조직과 목적조직이 교차된 형태로 소속된 구성.
• 스타트업 방식
• 팀의 규모는 회사마다 다르지만, 아마존의 창업자 제프 베조스는 최대 16명을 넘지 않는 것을 추천한다.
• 속도와 전문성이 높고 목적 조직과 기능 조직의 장점을 다 가져가기 위한 방식
  ​​

​

▫︎ 제품팀이 일하는 방식

​​

​

린스타트업

• 빠르게 제품을 테스트하고 그 결과를 다시 제품에 반영하는 운영방식.
• 린스타트업은 불확실성이 높은 스타트업에서 제품을 효과적으로 개발하기 위해 고안된 전략
• 핵심은 낭비를 줄이는 것으로, 적은 리소스로 제품을 만들어서 빠르게 시장에 검증해 가며 기능을 고도화 해 나가는 방법
• ‘만들기 → 측정 → 학습’ 을 반복하면서 피드백을 받고 사용자 중심으로 제품을 만드는 것을 중요시 함.
  ​​

​

애자일

• 일정한 주기로 빠르게 제품을 배포해 사용자의 피드백을 받고 요구사항을 수정해 나가는 과정을 반복
• 애자일(agile)은 사전적으로 날렵한, 민첩한 이라는 뜻을 갖고 있다.
• 애자일한 제품팀은 1~4주의 스프린트 단위로 제품을 개발, 테스트하고 피드백을 받아 개선해나가는 과정을 반복
• 반대 의미인 폭포수 방식과 비교
  • 폭포수 방식
    • 폭포가 떨어지는 것 처럼 수직적으로 각 단계를 하나씩 해 나감.
    • 각 단계가 완벽하게 완성 되었을때 다음 단계로 넘어가고 이전 단계로 돌아가기X
    • 요구사항 설계부터 디자인, 개발이 순서대로 독립적으로 진행
    • 속도가 느리고 변화하는 상황에 유연한 대처 X
  • 애자일방식
    - 1~4주의 스프린트 단위로 제품을 개발, 테스트하고 피드백을 받아 개선해나가는 과정을 반복
    - 수평적으로 일하면서 불필요한 계획과 실행으로 피드백을 빠르게 반영
    - 빠르게 변화하는 환경에 맞추어 기민하고 유연한 대응 가능
    ​​

​

용어 정리

• 스프린트

  • 사전적의미: 짧은 거리를 전속력으로 달림
  • 제품팀에서 말하는 스프린트는 집중해서 여러 테스크를 완료하는 1~4주의 짧은 기간
  • 스타트업에서는 스프린트를 여러번 반복하여 밀도있게 일함

• 스크럼

  • 1~4주 단위의 스프린트 안에서 목표를 정하고 우선순위에 따라 제품을 개발하는 방식
  • 스프린트에서 설정한 목표에 따라 요구사항 설계 → 디자인 → 개발 → 테스트 → 배포 과정으로 제품 개발하는 애자일 방법론중 하나.
    

• 이터레이션
  - 짧은 주기로 스프린트를 이어나가는 것
  ​​

​​​

​

▪︎ UXUI 실무 프로세스

​​

​

▫︎ 디자인 프로세스

문제정의 → 아이데이션 → 프로덕트 스펙 문서 작성 → 초안 디자인 → 피드백 → 최종디자인 확정 → 디자인 QA

[기획]

1. 문제 정의

   • PO/PM 과 함꼐 제품 목표에 따라 우선순위가 높은 문제를 정함
   • 회사에 따라 문제 정의 단계에서 디자이너가 참여하기도 하고 참여하지 않고 따로 PO/PM이 문제를 선정해 공유

2. 아이데이션

   • 앞서 정의한 문제를 해결할 다양한 아이디어를 내고, 적절한 솔루션 선택
   • 필요에 따라 러프 솔루션 스케치 진행

3. 프로덕트 스펙 문서 작성
   - 디자인에 들어가기 전 문서에 솔루션에 대한 상세 내용을 글로 먼저 적기
   - 디자인이 나오지 안아도 엔지니어가 미리 상상 → 준비 가능 ⇒ 장점
   - 회사에 따라 생략, PO/PM 직군이 맡기도 함.
   ​​

[디자인]

1. 초안 디자인

   • 피그마, 스케치 등의 디자인 툴로 솔루션 진행
   • 디자인 디테일 보다는 전반적인 사용자의 여정과 UX에 집중해 보면서 프로덕트 스펙 문서에서 놓친 엣지 케이스가 없는지 살핌

2. 피드백

   • 기획 단계에서 논의한 대로 디자인이 되었는지 팀원 공유 → 피드백
   • 솔루션의 성격에 따라 피그마 프로토 타이핑이나 프로토 파이 같은 프로토 타입 툴을 사용하기도 함

3. 최종디자인 확정 및 핸드 오프

   • 피드백을 초안에 반영하여 최종 디자인 확정
   • 확정한 최종 디자인을 엔지니어에게 공유
   • 개발이 원활히 진행 될 수 있도록 도움
   • 필요에 따라 가이드 함께 작성하여 전달

   <핸드오프>

   • 핸드오프는 디자인을 개발할 수 있도록 엔지니어에게 전달하는 것을 의미

   • 디자이너의 의도를 엔지니어가 잘 히해해야 제품 구현이 잘 됨.

   • 디자인을 공유할 때 다음의 내용 포함
     유저 프로우

     • 처음 시작하는 화면은 어디이고 어떻게 연결 되는지 만들려는 기능의 전체 흐름이 잘 보이도록 구성

     유즈 케이스

     • 상황에 따른 화면 정의
     • 예) 회원가입 화면에서 정상입력, 입력값 오류, 입력가능 시간 초과 등의 다양한 상황이 생길 수 있기에, 모든 화면을 놓치지 않고 정의

     반응형 레이아웃

     • 대부분의 회사에서는 스크린 크기를 하나 정해 디자인을 하고 반응형으로 대응
     • 아주작은 스크린 크기나 특별한 스크린 크기에 디자인이 어떻게 표현 되어야 하는지 가이드를 줘야함.

​​​
​​
​​

[개발]

• 디자인 QA
  • 개발이 완료되면 디자인 대로 정확하게 개발 되었는지 확인하는 디자인QA
  • 최대한 사용자와 비슷한 환경으로 테스트
  • 앱이라면 적어도 안드로이드, IOS 두 환경 모두 확인해야함.

​​​
​​
​​

▫︎ 프로덕트 스펙 문서

• 프로덕트 스펙은 제품을 만들거나 개선할 때 사용하는 문서로 기능의 사양을 정의한 가이드
• PRD(Product Requirements Document, 제품 요구사항 정의서)

프로덕트스펙이 필요한 이유

• 팀원 모두가 같은 생각을 갖고 제품을 만들 수 있도록 가이드 하는 역할
  ​​​
  ​​
  ​​

어떤 내용이 들어가는가

• 기획 배경과 솔루션, 기능 요구사항, 실험계획 등을 담고 있음
• 가능한 한 기획, 디자인, 개발에 필요한 모든 내용을 적는 것이 좋음
  → 문서가 여러개로 파편화 되어있으면 URL을 첨부해 한 곳에서 볼 수 있도록 해주기
  ​​​
  ​​
  ​​

기획 배경 & 문제정의

• 기획을 하게된 배경을 짧게 설명, 사용자의 문제 정의
• 문제정의에는 아래의 내용이 필요함
  - 문제 발견과정
  - 문제로 정의한 이유
  - 문제의 원인
  - 누가 이 문제에 영향을 받는지
  ​​​
  ​​
  ​​

솔루션 설명 ⇒ 디자이너의 역할이 가장 중요한 부분

• 만들고자 하는 솔루션에 대해 UXUI 관점에서 자세히 설명
• 솔루션 설명에는 아래의 내용 포함
  - 페르소나
  - 사용자 시나리오
  - 기능별 주요 특징 & 요구사항
  - 예외 상항 및 Edge case 정의
  - 최종시안
  ​​​
  ​​
  ​​

실험 설계

• 솔루션의 효과를 검증하기 위해 어떤 순서로 실험을 진행하고 어떻게 결과를 분석할 것 인지 계획 적기
• 실험가설
  • 문제 해결을 통해 만들어 내고자 하는 결과
• 실험 방식
• 결과평가
  • 문제가 해결되었는지 판단할 수 있는 방법
• 실험기간
  ​​​
  ​​
  ​​

예상기간

• 프로덕트 스펙→ 예상일정 꼭 포함
• 작업에 필요한 시간을 추정, 예상 일정 잘 선정하는 것 → 리소스를 효율적으로 쓰기 위한 시작점
• 프로덕트 스펙 초안 작성 완료 예상 일정
• UIUX 디자인 최종 시안 제작 완료 예상 일정
• 개발 분야별 예상 일정
  • 프론트엔드, 서버, 이벤트 설계, QA가 각각 세부적으로 작성되어 있어야함.
• 배포 목표 일정.
  ​​​
  ​​
  ​​

!!프로덕트 스펙 문서는 계속해서 업데이트 되어야함!!

• 기획 초기부터 기능이 배포되고 실험이 종료 될 때 까지 끊임없이 업데이트 하고 관리 되어야함
  ​​​
  ​​
  ​​

▫︎ 디자인 공유하고 피드백 받기

• 좋은 피드백을 받기 위해서는 디자인을 잘 공유 하는 것이 중요
• 디자이너의 업무의 대부분은 디자인과 피드백, 거듭되는 수정으로 이뤄짐
• 기획 배경과 맥락을 잘 이해해야 좋은 피드백이 나올 수 있음
• 피드백을 주는 사람이 전체적인 내용을 알 수 있도록 충분한 정보를 함께 전달
  ​​​
  ​​
  ​​

디자인 피드백을 요청할 때 포함하면 좋을 것

• 배경

  • 해당 프로젝트를 기획하게된 배경
  • 구체적인 데이터와 가설을 더하면 좋음

• 솔루션 의도

  • 가설에서 어떠한 방향성을 잡고 디자인 했는지 설명
  • 시각적으로 강조하고 싶었던 부분이나 중요하게 생각한 부분이 있다면 함께 작성

• 필수 리뷰어

  • 다수에게 디자인을 공유할땐 꼭 피드백을 받고 싶은 사람을 지정
  • 디자인한 화면으로 영향을 받는 곳과 연관된 사람이 있다면 참조

• 참고문서

  • 프로덕트 스펙 문서를 함께 첨부하면 전반적인 프로젝트를 이해하는데 도움이 됨
  • 디자인 파일도 함께 공유하면 다른 디자이너들의 도움을 받을 수 도 있음.

• 피드백 기한

  • 제품 개발, 배포 일정에 영향을 주지 않도록 피드백을 받을 수 있는 충분한 여유 가지기
  • 만일, 일정이 촉박하다면 피드백 받고싶은 기한을 함께 작성 → 피드백을 주는 사람도 일정을 함께 고려 가능
    

​​​
​​
​​
​​​
​​
​​

▪︎ [실무 프로세스 1] 협업

▫︎ 협업이란?

• 협업의 질 = 제품의 질
• 제품팀은 각자 다른 전문적인 능력을 가진 사람들이 모인것
• 제품팀은 함께 모여 문제를 해결하기 위해 긴 시간 함께 노력
• 협업이란 각 직무의 리소스가 낭비없이 좋은 솔루션을 만드는데 집중적으로 쓰이는 것을 의미
• 서로가 더 좋은 퍼포먼스를 낼 수 있도록 돕고 시너지를 낼 수 있도록 하는 것이 좋은 협업
  ​​​
  ​​
  ​​

▫︎ PM / PO 이해하기

​​​

<PM

• 프로덕트 매니저
• 제품의 전략을 세우고 우선순위를 결정해 실행하는 사람
• 제품의 전략을 수립하고 아이디어의 우선순위를 정해 디자이너와 함께 솔루션을 섥
• 실제 프로젝트를 수행하는 실무의 성격이 가

<PO

• 프로덕트 오너 (미니 CEO)
• 제품에 대한 오너십을 갖고 제품이 시장에 잘 전달 될 수 있도록 관리
• 제품팀을 이끌며 제품이 시장에 잘 전달 될 수 있도록 관리
• 이해관계자들과 논의하고, 제품팀의 팀원들이 제품을 잘 만들 수 있는 환경을 만드는데 힘씀

< 차이점>

• PM과 PO는 제품을 만드는 사람이라는 관점에서는 같음

• 권한과 세부역할에 차이가 나

• PM

  • 실무 중심으로 프로젝트 관리
  • 요구사항 분석, 전략설계, 지표관리 및 분석 등의 업무 수행

• PO

  • 제품 전반의 로드맵, 제품 관리
  • 로드맵과 전략설계 지표 관리 및 분석 등의 업무를 하며 동시에 제품팀의 조직관리에도 힘씀

• 참고

  → PM / PO 의 업무는 겹치는 부분이 많고, 같은 PM / PO 직무라고 하더라도 회사상황에 따라 상이.
  

​​​
​​
​​

▫︎ 엔지니어 이해하기

• 엔지니어를 이해하는 이유
  - 디자이너가 그린 화면을 실제로 동작하는 화면으로 만들어주기 때문
  - 엔지니어와 소통이 원활할 수록 디자인이 더 정확하고 완성도 높은 수준으로 사용자에게 전달
  ​​​
  ​​

<프론트엔지니어

• 사용자가 만나는 지점, 눈에 보이는 영역의 기능을 구현
• 앱/웹 페이지, 화면 안의 각종 컴포넌트 즉, UI 코드로 구현
• 단순히 그래픽 구현을 넘어 화면간의 이동, 컴포넌트 모션, 사용자의 인풋에 따른 반응까지 구현하기 때문에 사용자의 경험을 만드는 UX와 깊게 관련됨.

<백엔드엔지니어>

• 제품에 필요한 정보를 저장하고 전송하며 관리하는 영역 담
• 서버 엔지니어라고도 함
• 정보를 저장 전송하는 것 뿐만 아니라 제품 전체 효율적으로 운영할 수 있도록 구조 고민
• 상대적으로 프론트 엔드 엔지니어 보다 디자이너와 접점이 적어지지만 제품을 만들다보면 백엔드 엔지니어와도 소통할 일이 있음
• 예) 제품에서 특정 정보를 가져와 사용자에게 보여주는 기능 → 저장된 정보를 가져오는 것이기에 백엔드의 의견 중요

<QA 엔지니어>

• QA 테스트를 계획, 진행하고 제품 전반적인 품질을 높이는 역할을 함
• QA 엔지니어 기능이 개발되면 배포하기 전에 테스트
• 지속헤서 제품을 모니터링 하면서 서비스 안정과 품질 지키기에 노력

<데이터 애널리스트>

• 데이터 애널리스트는 수집하고 분석해서 인사이트 제공
• 데이터 베이스에서 SQL 같은 언어를 사용해 필요한 데이터 추출, 파이썬을 활용하여 여러 방면으로 분석
• 데이터를 보기 좋은 형태로 가공하고 시각화 하여 제품팀이 의사결정을 올바르게 할 수 있도록 도움
  ​​​
  ​​
  ​​​​​
  ​​
  ​​

▫︎ UXUI 직무 이해하기

• 하나의 화면이 완성되기 위해서 UXUI 디자이너 말고도 다양한 직무의 힘이 필요
  ​​​
  ​​

<BX 디자이너>

• Brand experience 의 줄임말, 브랜드 경험과 관련된 전반적인 디자인
  • 로고나 심볼, 아주 기본 적인 것 부터 앱/웹에 들어가는 그래픽, 대외에 노출되는 이미지, 각종 인쇄물 등 브랜드를 나타내는 모든 부분에 기여

• 제품 내 문구 담당
• 단순 글 잘쓰는 사람은 아님
• 브랜드의 보이스앤톤을 문구로 전달, 명확한 메시지를 통해 제품의 사용성을 높임
• 규모가 작은 회사에서는 직무를 별도로 두지 않고 디자이너가 대신함.

▪︎ [실무 프로세스 2] 실험 문화

▫︎ 실험이란?

• 제품의 개선이 실제로 사용자에게 더 나은 경험으로 이어지는지 데이터로 검증하는 것

<실험을 해야하는 이유>

• 사람은 편향적이기 때문에 만드는 사람의 주관이 제품에 반영되기 쉬움
• 데이터로 사용자의 데이터를 확인하면, 객관적으로 의사결정 가능
• 호불호가 데이터로 증명

▫︎ 실험 환경 이해하기

• A/B 테스트
  • 두가지 이상의 버전을 각각 다른 사용자에게 보여주고 성과 측정 실험
  • 사용자를 임의로 대조군과 실험군, 두 집단으로 나누고 서로 다른 안을 보여주고 어느 집단이 더 좋은 지표를 보이는지 측정

A/B 테스트 방법

• 기존 화면은 대조군으로 설정 → 효과를 검증하기 위한 비교 대상
• 테스트 하고 싶은 안을 실험군으로 설정
• A/B 테스트의 효과를 정확히 파악하기 위해 테스트 하는 변수는 가능한 1개로 제한하는 것이 좋음

<A/B 테스트를 하는 이유>

• 제품에 어떤 변화를 줬을 때 사용자가 어떻게 반응하고 행동하는지에 대한 정보를 얻기 위함
• 변화를 주었을때 행동이 달라졌다면 그 안에서 상관관계와 인과관계를 찾아낼 수 있음
• 거듭된 실험을 통해 제품팀은 사용자에 대한 이해도가 높아지고 더 나은 의사결정 가능
• 예)

  • A 집단과 B 집단에게 똑같은 장바구니 화면에서 결제하기 버튼 하나만 다르게 해서 부여줌

    • A집단의 결제하기 버튼은 검은색
    • B 집단의 결제하기 버튼은 빨간색

  • 실험결과 A 집단 보다 B 집단의 결제율 2배

    → A/B 테스트로 제품은 빨간색 결제하기 버튼이 결제율에 긍정적인 영향을 준다는 사실 배울 수 있음

<실험을 위한 제품 분석 도구>

• 앰플리튜드
  • 제품안에서 일어나는 특정 행동에 이벤트를 심어두면 해당 행동이 일어났을 때를 기록해 데이터를 보여줌
  • 이벤트별 분석, 화면별 분석, 리텐션 그래프,유저 구성 등 기능이 있어 제품에 관한 다양한 데이터 얻고 분석 → 현 시점 가장 강력한 데이터 분석 툴
    

• 구글 에널리틱스 (GA4)

  • 구글에서 제공하는 무료 분석툴, 대중적 인지도 높고 많이 쓰임
  • 구 버전 universal Analytics 에서 Google Analytics4 로 버전 변경
  • 차이가 커서 구분을 잘 해야함
  • GA4는 이벤트 중심으로 데이터 수집, 특정 페이지 조회, 링크나 버튼 클릭, 스크롤 내리기 등 사용자 상호작용 기록

• 차이점

  • 앰플리튜드
    • 유로 → 조직 규모의 영향
    • 제품에 관한 대부분의 데이터를 추적하고 분석 가능
    • 가장 기능이 다양하며 인지도 높음
    • PM/PO가 사용
    • 이벤트 기반 분석
    • 제품 팀을 위한 솔루션에 가까움
  • 구글 애널리틱스
    • 무료, 일부 기능 유료
    • 마케팅 플랫폼과 연계가좋아 마케터들이 많이 사용
    • 과거에는 세션과 페이지 뷰 기반, 업그레이드 후 앰플리튜드와 동일하게 이벤트 기반 분석으로 변화
    • 마케팅 팀을 위한 솔루션에 가까움

​​​
​​
​​​​​
​​
​​

▪︎ [실무 프로세스 3] 디자인QA

▫︎ QA란?

• Quality Assurance 의 약자, 제품이 풀시되기전 기능 테스트 하는 것
• 제품이 처음 기획한 대로 잘 구현되었는지, 회사에서 생각하는 품질 기준이 충족 되었는지 확인하는 과정
• 규모에 따라 별도로 QA 팀의 유무 → 제품팀에서 하기도 함
• QA 팀이 있더라도 기능을 만든 담당자라면 대부분 직접 QA함

QA의 목적

• 사용자가 제품을 이용할 수 없을만큼 치명적 결함의 유무 확인
• 조직 전체에서 기대하는 수준의 품질인지
• 프로덕트 스첵 문서에서 작성했던 명세대로 잘 구현 되었는지
• 특수한 상황에서 예상하지 못한 대로 동작하지 않는지
• 전반적은 UX가 사용하기 편리한지

▫︎ QA 문서

​​​
​​
​​

QA 할 때 준비해야할 문서

• 체크리스트

  • 예 / 아니오 혹은 PASS/ FAIL 로 대답할 수 있는 확인했습니다! 성격의 항목을 나열한 목록
  • 기능이나 개선 범위가 크지 않을 떄 사용
  • 예) 버튼을 눌렀을 때 색상이 변하나요? 예) 버튼을 눌렀을 때 A 페이지로 이동하나요?
    

• 테스트 시나리오 (TS)

  • 기획한 기능이 모두 제대로 동작하는지 확인하기 위해 작성하는 문서
  • 사용자가 기능을 사용하면서 경험하게 되는 과정을 상세하게 적습니다.
  • 예) 회원가입 flow 테스트 상황
    • 회원가입은 카카오톡, 네이버, 일반 회원가입 3가지가 있다
    • 일반 회원가입의 경우 이메일, 비밀번호, 이름을 입력한다.
    • 올바르지 않은 정보를 입력할 경우 텍스트 필드 아래에 얼럿 메시지가 노출된다.
    • CTA 버튼을 누르면 회원가입 요청을 보낸다

• 테스트 케이스 (TC)
  - 특정 조건에서 요구사항을 충족하는지 확인하기 위해 여러 케이스 작성 문서
  - 특정 조건 아래 환경을 테스트 하는 것이기 때문에 특정 조건, 테스트 범위, 케이스, 기대값, 테스트 환경 등을 상세히 작성
  - 예) 회원가입 flow 테스트 상황

      ​​​

  ​​
  ​​

▫︎ 디자인 QA

• 디자인이 정확하게 개발 되었는지 확인하는 절차

디자인QA에서 발견한 이슈 공유하기

• 디자인과 다른 부분을 발견했다면 팀원과 내용공유 후 수정 요청
• 어디가 잘못되었는지 엔지니어가 알 수 있도록 정확하게 작성
• 잘못 개발된 화면과 원래의 디자인 화면을 기획의도와 함께 전달
• ‘지라’나 ’트렐로’ 같은 프로젝트 관리 툴을 사용한다면 좋게 발견한 이슈를 업무 티켓 형태로 전달하는 것 추천 → 회사마다 상이
  

이슈의 중요도 정의하기

• 중요한 것 부터 해결 할 수 있도록 중요도 표시
• HIGHEST : 당장 대응이 필요할 정도로 주요 기능에 문제가 있는 경우
• HIGH
  • 사용자가 행동을 완수할 수 없는 경우
  • 기능상 사용성에 치명적인 문제가 될 수 있는 것
• MEDIUM
  • 사용자가 행동을 완수 하는 데 어려움을 겪을 수 있는 문제
  • 단계를 넘어가는 데 문제는 없음
  • 기획이나 피그마 디자인 화면과 다르게 적용되어 있는 것
  • 사용자가 상황을 제대로 이해하기에 어려움이 있는 것 (예: 네트워크 오류로 팝업이 떠야하는 상황에서 알 수 없는 오류 팝업 뜸)
  • 시각적으로 오류가 난 것 처럼 보이는 것
• LOW
  • 기능상 문제가 없는 것
  • 피그마 화면과는 다르지만 맥락 상 과정을 이해하기 어려움이 없는 것
  • 오픈 후 수정되어도 문제없는 디테일한 부분
• LOWEST
  - 단순 의견 정도의 레벨로 급하게 반영되지 않아도 될 이슈 ​​​
  ​​
  ​​
  

3. 회고

• 두 주차 강의를 하루만에 듣기는 힘든 것 같다.
• 저번주에 클론디자인이 시간이 너무 오래걸려서 오늘 강의를 좀 몰아들었는데 다음 부터는 그냥 클론디자인 (최대한 빠르게) 1개 제작, 강의 한 주차 수강 하는 식으로 해야할 것 같다.
• 내용 정리를 하면서 들으니 확실히 머리에 잘 들어온다
• 개인 과제에서 내가 저 방식들을 다 응용할 수 있을지 걱정된다.
• 리서치가 정말 중요할 것 같다.