📌
1. 조직과 일하는 방식
2. UX/UI 디자인 프로세스
3. 실무 프로세스
4. 과제
특정한 목적을 달성하기 위해 여러 직무의 사람들이 모인 팀
스쿼드, 샤일로라고 부르기도 한다.
(ex. 패션팀, 뷰티팀, 홈데코팀 등)
목적을 빠르고 효율적으로 달성할 수 있다는 점이 장점
유사한 직무끼리 구성된 팀
(ex. 개발팀, 디자인팀, 마케팅팀 등)
전문 분야에 대해 깊이 논의하고 서로의 발전을 도울 수 있다는 점이 장점
기능 조직과 목적 조직이 교차된 형태로 소속된 구성
주로 스타트업에서 이 방식으로 일한다.

빠르게 제품을 테스트하고 그 결과를 다시 제품에 반영하는 운영 방식
핵심은 낭비를 줄이는 것으로, 적은 리소스로 제품을 만들어서 빠르게 시장에 검증해 가면서 기능을 고도화해 나가는 방법
‘만들기 - 측정 - 학습’ 과정 반복, 피드백을 받고 사용자 중심으로 제품을 만드는 것이 중요

일정한 주기로 빠르게 제품을 배포해 사용자의 피드백을 받고 요구 사항을 수정해 나가는 과정을 반복하는 방식
1-4 주의 스프린트 단위로 ‘제품 개발 → 테스트 → 피드백 → 개선’ 과정 반복
빠르게 변화하는 상황에 유연하게 대처 가능

💡용어 정리
- 스프린트
집중해서 여러 태스크를 완료하는 1-4주 정도의 짧은 기간- 스크럼
1-4주 단위의 스프린트 안에서 목표를 정하고 우선순위에 따라 제품을 개발하는 방식- 이터레이션
짧은 주기로 스프린트를 이어나가는 것
폭포가 떨어지는 것처럼 수직적으로 각 단계를 거쳐 진행되는 방식 (↔️애자일)
요구사항 설계부터 디자인, 개발이 순서대로, 독립적으로 진행되고 뒤로 다시 되돌아가지 않는다.
속도가 느리고 상황에 유연하게 대처하는 것이 어렵다.
PO/PM과 함께 제품 목표에 따라 우선순위가 높은 문제를 설정
이 단계에서 디자이너가 참여하기도 하고, PO/PM이 문제를 선정하여 공유하기도 한다.
앞서 정의한 문제를 해결할 다양한 아이디어를 내고, 그 중에서 적합한 솔루션을 선택
필요에 따라 러프한 솔루션 스케치 진행
✏️ 솔루션 스케치
아이데이션 단계에서 기획과 아이디어가 잘 보이도록 와이어프레임 형태로 그린다.
디자인에 들어가기 전에 문서에 솔루션에 대한 상세 내용을 글로 먼저 작성
디자인이 나오지 않아도 엔지니어가 솔루션을 미리 상상하고 준비할 수 있다는 것이 장점
디자인 툴로 솔루션 디자인
디자인 디테일 보다는 전반적인 사용자 여정과 UX에 집중해보면서 프로덕트 스펙 문서에서 놓친 엣지 케이스는 없는지 점검
기획 단계에서 논의한 내용대로 잘 디자인 되었는지 팀원들에게 공유하고 피드백을 받는다.
솔루션의 성격에 따라 프로토타입 툴을 선택하여 사용
피드백을 초안에 반영하여 최종 디자인 확정
확정한 최종 디자인을 엔지니어에게 공유하고 개발이 원활하게 진행될 수 있도록 돕는다.
필요에 따라 가이드를 함께 작성하여 전달
👋 핸드오프
디자인을 코드로 개발할 수 있도록 엔지니어에게 전달하는 것
필요한 내용
1. 유저 플로우
처음 시작되는 화면은 어디이고 어떻게 연결되는지 만들려는 기능의 전체 흐름이 잘 보이도록 구성
2. 유즈 케이스
다양한 상황에 따른 화면 정의
모든 케이스에 따라 달라지는 화면을 놓치지 않고 정의
ex. 회원가입 화면 (정상 입력, 오류 케이스, 입력 가능 시간 초과 등)3. 반응형 레이아웃
디바이스 사이즈에 맞춰 디자인
ex. 375px, 360px, 320px, 768px 등
개발이 완료되면 디자인대로 정확하게 개발되었는지 확인하는 과정
최대한 사용자와 비슷한 환경으로 테스트
앱이라면 적어도 iOS, 안드로이드 두 환경에서 확인
제품을 만들거나 개선할 때 사용하는 문서, 기능의 사양을 정의한 가이드
PRD (Product Required Document, 제품 요구사항 정의서)라고도 불린다.
팀원 모두가 같은 생각을 갖고 제품을 만들 수 있도록 가이드하는 역할
가능한 하나의 문서에 기획, 디자인, 개발에 필요한 모든 내용 작성
기획을 하게 된 배경을 짧게 설명하고 사용자의 문제 정의
만들고자 하는 솔루션에 대해 UX/UI 관점에서 자세하게 설명
솔루션의 효과를 검증하기 위해 어떤 순서로 실험을 진행하고 어떻게 결과를 분석할 것인지에 대한 계획 작성
작업에 필요한 시간을 추정하고 예상 일정을 잘 산정하는 것은 효율적인 리소스 관리의 시작점
💡
프로덕트 스펙 문서는 계속해서 업데이트 되어야한다.
기획 초기에 만들기 시작해서 기능이 배포되고 실험이 종료될 때까지 끊임없이 업데이트하고 관리되어야한다.
좋은 피드백을 받기 위해서는 디자인을 올바르게 공유하는 것이 중요
해당 프로젝트를 기획하게 된 배경 설명
구체적인 데이터와 가설 첨부
가설에서 어떠한 방향성을 잡고 디자인 했는지 설명
시각적으로 강조하고 싶었던 부분이나 중요하게 생각한 부분 작성
다수에게 디자인을 공유할 때에는 꼭 피드백을 받고 싶은 사람 지정
디자인한 화면으로 영향을 받는 곳과 연관된 사람 참조
프로덕트 스펙 문서 함께 첨부
디자인 파일 (다른 디자이너들의 도움을 받을 수 있다.)
이해를 돕기 위해 프로토타입 공유
제품 개발, 배포 일정에 영향을 주지 않도록 피드백을 받을 수 있는 충분한 여유 시간 확보
일정이 촉박하다면 기한을 함께 표시하여 피드백을 주는 사람도 일정을 고려할 수 있도록 한다. (업무 가시성 향상)
협업이란 각 직무의 리소스가 낭비 없이 좋은 솔루션을 만드는데 집중적으로 쓰이는 것을 의미한다.
더 좋은 협업을 위해 서로가 더 좋은 퍼포먼스를 낼 수 있도록 돕고 시너지를 낼 수 있도록 해야한다.
제품의 전략을 세우고 우선순위를 결정하여 실행하는 역할 (실행)
제품팀을 이끌며 제품이 시장에 잘 전달 될 수 있도록 관리
이해관계자들과 논의하고 제품팀의 팀원들이 제품을 잘 만들 수 있는 환경 조성 (관리)
디자이너가 그린 화면을 실제 동작하는 화면으로 만들어주는 역할
엔지니어와의 소통이 잘 될수록 디자인이 더 정확하고 완성도가 올라간다.
사용자가 만나는 지점, 즉 앱/웹의 페이지, 화면 안의 각종 UI 요소들을 코드로 구현
제품에 필요한 정보를 저장하거나 전송하고, 관리하는 영역을 담당
QA 테스트를 계획, 진행하고 제품의 전반적인 품질을 높이는 역할
기능이 개발되면 배포하기 전에 테스트
지속해서 제품을 모니터링하면서 서비스의 안전성과 품질을 지키기 위해 노력
데이터를 수집하고 분석해서 인사이트를 제공하는 역할
데이터를 보기 좋은 형태로 가공하고 시각화하여 제품팀의 올바른 의사결정을 돕는다.
Brand Experience 의 줄임말로, 브랜드 경험과 관련된 전반적인 디자인 담당
로고나 심볼처럼 아주 기본적인 요소부터 웹/앱에 들어가는 그래픽, 대외 노출 이미지 등 브랜드를 나타내는 모든 부분에 관여
제품 내의 문구 담당
브랜드의 브랜드 앤 톤을 유지하며 명확한 메세지를 통해 제품의 사용성을 높이는 일을 한다.
제품의 개선이 실제로 사용자에게 더 나은 경험으로 이어지는지 데이터로 검증하는 것
두 가지 이상의 버전을 각각 다른 사용자에게 보여주고 성과를 측정하는 실험
💡제한하는 이유
변수의 효과를 정확히 측정하기 위해
한번에 여러가지 변수를 놓고 테스트를 한다면 여러가지 변수 중 어떤 요소가 어떤 효과를 일으켰는지 정확히 알 수 없다.
변화를 주었을 때 행동이 달라졌다면 그 안에서 상관관계와 인과관계를 찾아낼 수 있다.
거듭된 실험을 통해 사용자에 대한 이해도가 높아지고 더 나은 의사 결정을 할 수 있다.
A 집단과 B 집단에게 똑같은 장바구니 화면에서 결제하기 버튼 하나만 다르게 설정하여 보여주었다.
A 집단 - 흰색 버튼 ⬜
B 집단 - 파란색 버튼 🟦
실험결과 B집단의 결제율이 2배 더 높았다.
→ A/B 테스트로 눈에 더 잘 띄는 파란색 버튼이 결제율에 긍정적인 영향을 준다는 사실을 알았다.
제품 안에서 일어나는 특정 행동에 이벤트를 심어두면 해당 행동이 일어났을 때를 기록하여 데이터를 쌓고 보여준다.
이벤트별 분석, 유저 구성 등의 기능이 있어 제품에 관한 다양한 데이터를 얻고 분석할 수 있다.
제품팀을 위한 솔루션에 가깝다.
구글에서 제공하는 무료 분석 툴
이벤트 중심으로 데이터를 수집하고 특정 페이지 조회, 스크롤 내리기 등 사용자 상호작용을 기록한다.
마케팅 팀을 위한 솔루션에 가깝다.
제품이 출시되기 전에 기능을 테스트 하는 것
제품이 처음 기획한 대로 잘 구현이 되었는지, 회사에서 생각하는 품질 기준에 충족되었는지 확인하는 과정
기능 QA, 디자인 QA가 있다.
기능을 만든 담당자라면 대부분 직접 QA에 참여한다.
예/아니오 혹은 Pass/Fail 로 답변할 수 있는 확인 성격의 항목을 나열한 목록
기능이나 개선 범위가 크지 않을 때 사용
기획한 기능이 모두 제대로 동작하는지 확인하기 위해 작성하는 문서
사용자가 기능을 사용하면서 경험하게 되는 과정을 상세하게 작성
특정 조건이나 요구 사항을 충족하는지 확인하기 위해 여러가지 케이스를 작성한 문서
특정 조건 아래의 환경을 테스트하는 것이기 때문에 특정 조건, 테스트 범위, 케이스, 기대 값, 테스트 환경 등을 상세하게 작성
디자인 화면과 개발된 화면을 띄워놓고 비교해보며 다른 부분이 발견됐다면, 팀원들과 내용을 공유하고 수정 요청
잘못 개발된 화면, 원래의 디자인 화면을 기획 의도와 함께 전달
발견한 이슈를 업무 티켓 형태로 전달하기 위해 지라나 트렐로와 같은 프로젝트 관리 툴 사용
일정이 촉박한 경우 QA에서 발견한 모든 이슈를 수정하지 못 하고 배포해야할 수도 있다.
제품의 퀄리티를 해치는 이슈 먼저 해결할 수 있도록 이슈별 중요도를 표시해야한다.
👩💻
뱅크샐러드의 회원가입/로그인 과정에서 휴대폰 본인인증 화면에 대한 QA를 한다고 가정하고 숙제를 해볼게요.
- 참고로 뱅크샐러드는 회원가입과 로그인 과정이 같습니다.
- 앱을 설치(혹은 재설치)한 후 첫 화면이 휴대폰 본인인증입니다.
- 휴대폰 본인인증 단계에서 일어나는 여러 가지 케이스를 테스트 케이스로 작성해 보세요.


실제 UIUX 디자이너가 어떤 조직에 속하고 어떤 프로세스로 일을 하는지 알아볼 수 있는 챕터였다.
생각보다 더 다양하고 세심한 일을 한다는 것을 알게되었다.
또한 과제로 뱅크 샐러드의 핸드폰 본인인증 화면에 대한 테스트 케이스를 작성해보았는데 본인인증 하나에 이렇게 많은 경우의 수가 존재하고 그것들을 고려해야 한다는 것을 깨달았다.
내가 아무 생각 없이 봐오던 화면들도 이런 과정들을 거쳐 배포됐을 생각을 하니 대단해보인다.
🤠 다음 시간 학습할 내용
디자인 툴
프로토타이핑 툴