[본캠프] d+3.

박예지·2025년 1월 22일

[UIUX] TIL 📑

목록 보기
12/100

📌
1. 조직과 일하는 방식
2. UX/UI 디자인 프로세스
3. 실무 프로세스
4. 과제

1. 조직과 일하는 방식

조직

- 목적 조직

특정한 목적을 달성하기 위해 여러 직무의 사람들이 모인 팀
스쿼드, 샤일로라고 부르기도 한다.
(ex. 패션팀, 뷰티팀, 홈데코팀 등)

목적을 빠르고 효율적으로 달성할 수 있다는 점이 장점

- 기능 조직

유사한 직무끼리 구성된 팀
(ex. 개발팀, 디자인팀, 마케팅팀 등)

전문 분야에 대해 깊이 논의하고 서로의 발전을 도울 수 있다는 점이 장점

- 매트릭스 조직

기능 조직과 목적 조직이 교차된 형태로 소속된 구성
주로 스타트업에서 이 방식으로 일한다.

일하는 방식

- 린스타트업 (Lean Startup)

빠르게 제품을 테스트하고 그 결과를 다시 제품에 반영하는 운영 방식

핵심은 낭비를 줄이는 것으로, 적은 리소스로 제품을 만들어서 빠르게 시장에 검증해 가면서 기능을 고도화해 나가는 방법

‘만들기 - 측정 - 학습’ 과정 반복, 피드백을 받고 사용자 중심으로 제품을 만드는 것이 중요

- 애자일 (Agile)

일정한 주기로 빠르게 제품을 배포해 사용자의 피드백을 받고 요구 사항을 수정해 나가는 과정을 반복하는 방식

1-4 주의 스프린트 단위로 ‘제품 개발 → 테스트 → 피드백 → 개선’ 과정 반복

빠르게 변화하는 상황에 유연하게 대처 가능

💡용어 정리

  • 스프린트
    집중해서 여러 태스크를 완료하는 1-4주 정도의 짧은 기간
  • 스크럼
    1-4주 단위의 스프린트 안에서 목표를 정하고 우선순위에 따라 제품을 개발하는 방식
  • 이터레이션
    짧은 주기로 스프린트를 이어나가는 것

🌊 폭포수 방식

폭포가 떨어지는 것처럼 수직적으로 각 단계를 거쳐 진행되는 방식 (↔️애자일)

요구사항 설계부터 디자인, 개발이 순서대로, 독립적으로 진행되고 뒤로 다시 되돌아가지 않는다.

속도가 느리고 상황에 유연하게 대처하는 것이 어렵다.

2. UX/UI 디자인 프로세스

1. 기획

- 문제 정의

PO/PM과 함께 제품 목표에 따라 우선순위가 높은 문제를 설정
이 단계에서 디자이너가 참여하기도 하고, PO/PM이 문제를 선정하여 공유하기도 한다.

- 아이데이션

앞서 정의한 문제를 해결할 다양한 아이디어를 내고, 그 중에서 적합한 솔루션을 선택

필요에 따라 러프한 솔루션 스케치 진행

✏️ 솔루션 스케치

아이데이션 단계에서 기획과 아이디어가 잘 보이도록 와이어프레임 형태로 그린다.

- 프로덕트 스펙 문서 작성

디자인에 들어가기 전에 문서에 솔루션에 대한 상세 내용을 글로 먼저 작성

디자인이 나오지 않아도 엔지니어가 솔루션을 미리 상상하고 준비할 수 있다는 것이 장점

2. 디자인

- 초안 디자인

디자인 툴로 솔루션 디자인

디자인 디테일 보다는 전반적인 사용자 여정과 UX에 집중해보면서 프로덕트 스펙 문서에서 놓친 엣지 케이스는 없는지 점검

- 피드백

기획 단계에서 논의한 내용대로 잘 디자인 되었는지 팀원들에게 공유하고 피드백을 받는다.

솔루션의 성격에 따라 프로토타입 툴을 선택하여 사용

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

피드백을 초안에 반영하여 최종 디자인 확정

확정한 최종 디자인을 엔지니어에게 공유하고 개발이 원활하게 진행될 수 있도록 돕는다.

필요에 따라 가이드를 함께 작성하여 전달

👋 핸드오프

디자인을 코드로 개발할 수 있도록 엔지니어에게 전달하는 것

필요한 내용

1. 유저 플로우

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

2. 유즈 케이스

다양한 상황에 따른 화면 정의
모든 케이스에 따라 달라지는 화면을 놓치지 않고 정의
ex. 회원가입 화면 (정상 입력, 오류 케이스, 입력 가능 시간 초과 등)

3. 반응형 레이아웃

디바이스 사이즈에 맞춰 디자인
ex. 375px, 360px, 320px, 768px 등

3. 개발

- 디자인 QA

개발이 완료되면 디자인대로 정확하게 개발되었는지 확인하는 과정

최대한 사용자와 비슷한 환경으로 테스트

앱이라면 적어도 iOS, 안드로이드 두 환경에서 확인

📑프로덕트 스펙 문서

제품을 만들거나 개선할 때 사용하는 문서, 기능의 사양을 정의한 가이드
PRD (Product Required Document, 제품 요구사항 정의서)라고도 불린다.

중요성

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

내용

가능한 하나의 문서에 기획, 디자인, 개발에 필요한 모든 내용 작성

1. 기획 배경 & 문제 정의

기획을 하게 된 배경을 짧게 설명하고 사용자의 문제 정의

  • 문제 발견 과정
  • 문제로 정의한 이유
  • 문제의 원인
  • 누가 이 문제로 영향을 받는지

2. 솔루션 설명

만들고자 하는 솔루션에 대해 UX/UI 관점에서 자세하게 설명

  • 페르소나
  • 사용자 시나리오
  • 기능별 주요 특징 & 요구사항
  • 예외 상황 및 Edge Case 정의
  • 최종 시안

3. 실험 설계

솔루션의 효과를 검증하기 위해 어떤 순서로 실험을 진행하고 어떻게 결과를 분석할 것인지에 대한 계획 작성

  • 실험 가설 : 문제 해결을 통해 만들어 내고자 하는 결과
  • 실험 방식
  • 결과 평가 : 문제가 해결 되었는지 판단할 수 있는 방법
  • 실험 기간

4. 예상 일정 (⭐)

작업에 필요한 시간을 추정하고 예상 일정을 잘 산정하는 것은 효율적인 리소스 관리의 시작점

  • 프로덕트 스펙 초안 작성 완료 예상 일정
  • UI/UX 디자인 최종 시안 제작 완료 예상 일정
  • 개발 분야별 예상 일정
  • 배포 목표 일정

    💡
    프로덕트 스펙 문서는 계속해서 업데이트 되어야한다.
    기획 초기에 만들기 시작해서 기능이 배포되고 실험이 종료될 때까지 끊임없이 업데이트하고 관리되어야한다.

👨‍👩‍👧‍👦 디자인 공유 & 피드백

좋은 피드백을 받기 위해서는 디자인을 올바르게 공유하는 것이 중요

  • 기획 배경과 맥락을 잘 이해해야 좋은 피드백이 나올 수 있다.
  • 피드백을 주는 사람이 전체적인 내용을 알 수 있도록 충분한 정보를 함께 전달

피드백 요청 시 중요한 점

1. 배경

해당 프로젝트를 기획하게 된 배경 설명
구체적인 데이터와 가설 첨부

2. 솔루션 의도

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

3. 필수 리뷰어

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

4. 참고 문서

프로덕트 스펙 문서 함께 첨부
디자인 파일 (다른 디자이너들의 도움을 받을 수 있다.)
이해를 돕기 위해 프로토타입 공유

5. 피드백 기한

제품 개발, 배포 일정에 영향을 주지 않도록 피드백을 받을 수 있는 충분한 여유 시간 확보

일정이 촉박하다면 기한을 함께 표시하여 피드백을 주는 사람도 일정을 고려할 수 있도록 한다. (업무 가시성 향상)

3. 실무 프로세스

1. 협업하기

협업이란 각 직무의 리소스가 낭비 없이 좋은 솔루션을 만드는데 집중적으로 쓰이는 것을 의미한다.

더 좋은 협업을 위해 서로가 더 좋은 퍼포먼스를 낼 수 있도록 돕고 시너지를 낼 수 있도록 해야한다.

- PM/PO

PM 프로덕트 매니저

제품의 전략을 세우고 우선순위를 결정하여 실행하는 역할 (실행)

PO 프로덕트 오너

제품팀을 이끌며 제품이 시장에 잘 전달 될 수 있도록 관리
이해관계자들과 논의하고 제품팀의 팀원들이 제품을 잘 만들 수 있는 환경 조성 (관리)

- 엔지니어

디자이너가 그린 화면을 실제 동작하는 화면으로 만들어주는 역할

엔지니어와의 소통이 잘 될수록 디자인이 더 정확하고 완성도가 올라간다.

프론트엔드 엔지니어

사용자가 만나는 지점, 즉 앱/웹의 페이지, 화면 안의 각종 UI 요소들을 코드로 구현

백엔드 엔지니어

제품에 필요한 정보를 저장하거나 전송하고, 관리하는 영역을 담당

QA 엔지니어

QA 테스트를 계획, 진행하고 제품의 전반적인 품질을 높이는 역할

기능이 개발되면 배포하기 전에 테스트

지속해서 제품을 모니터링하면서 서비스의 안전성과 품질을 지키기 위해 노력

데이터 애널리스트

데이터를 수집하고 분석해서 인사이트를 제공하는 역할

데이터를 보기 좋은 형태로 가공하고 시각화하여 제품팀의 올바른 의사결정을 돕는다.

UX/UI 직무

BX 디자이너

Brand Experience 의 줄임말로, 브랜드 경험과 관련된 전반적인 디자인 담당

로고나 심볼처럼 아주 기본적인 요소부터 웹/앱에 들어가는 그래픽, 대외 노출 이미지 등 브랜드를 나타내는 모든 부분에 관여

UX writer

제품 내의 문구 담당

브랜드의 브랜드 앤 톤을 유지하며 명확한 메세지를 통해 제품의 사용성을 높이는 일을 한다.

2. 실험 문화

실험

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

실험의 중요성

  1. 만드는 사람의 주관이 제품이 반영되기 쉽다.
  2. 사용자의 선호가 데이터로 증명된다.
  3. 데이터로 사용자의 데이터를 확인하면 객관적으로 의사결정을 할 수 있다.

A/B 테스트

두 가지 이상의 버전을 각각 다른 사용자에게 보여주고 성과를 측정하는 실험

방법

  1. 기존 화면은 대조군 (Control)로 설정
  2. 테스트하고 싶은 개선안을 실험군 (Treatment)로 설정
  3. 정확하게 파악하기 위해 테스트하는 변수는 가능한 1개씩 제한

    💡제한하는 이유

    변수의 효과를 정확히 측정하기 위해
    한번에 여러가지 변수를 놓고 테스트를 한다면 여러가지 변수 중 어떤 요소가 어떤 효과를 일으켰는지 정확히 알 수 없다.

이점

  1. 변화를 주었을 때 행동이 달라졌다면 그 안에서 상관관계와 인과관계를 찾아낼 수 있다.

  2. 거듭된 실험을 통해 사용자에 대한 이해도가 높아지고 더 나은 의사 결정을 할 수 있다.

예시

A 집단과 B 집단에게 똑같은 장바구니 화면에서 결제하기 버튼 하나만 다르게 설정하여 보여주었다.

A 집단 - 흰색 버튼 ⬜
B 집단 - 파란색 버튼 🟦

실험결과 B집단의 결제율이 2배 더 높았다.

→ A/B 테스트로 눈에 더 잘 띄는 파란색 버튼이 결제율에 긍정적인 영향을 준다는 사실을 알았다.

실험을 위한 제품 분석 도구

- 앰플리튜드

제품 안에서 일어나는 특정 행동에 이벤트를 심어두면 해당 행동이 일어났을 때를 기록하여 데이터를 쌓고 보여준다.

이벤트별 분석, 유저 구성 등의 기능이 있어 제품에 관한 다양한 데이터를 얻고 분석할 수 있다.

제품팀을 위한 솔루션에 가깝다.

- 구글 애널리틱스 (GA4)

구글에서 제공하는 무료 분석 툴

이벤트 중심으로 데이터를 수집하고 특정 페이지 조회, 스크롤 내리기 등 사용자 상호작용을 기록한다.

마케팅 팀을 위한 솔루션에 가깝다.

3. 디자인 QA

QA (Quality Assurance)

제품이 출시되기 전에 기능을 테스트 하는 것

제품이 처음 기획한 대로 잘 구현이 되었는지, 회사에서 생각하는 품질 기준에 충족되었는지 확인하는 과정

기능 QA, 디자인 QA가 있다.

기능을 만든 담당자라면 대부분 직접 QA에 참여한다.

내용

  1. 사용자가 제품을 이용할 수 없을 만큼의 치명적인 단점은 없는지 확인
  2. 조직 전체에서 기대하는 수준의 품질이 갖춰졌는지 확인
  3. Product Spec 문서에 작성했던 명세대로 잘 구현되었는지 확인
  4. 특수한 상황에서 예상하지 못 한 대로 동작하지 않는지 확인
  5. 전반적인 UX가 사용하기에 편리한지 확인

QA 문서

1. 체크리스트

예/아니오 혹은 Pass/Fail 로 답변할 수 있는 확인 성격의 항목을 나열한 목록

기능이나 개선 범위가 크지 않을 때 사용

2. 테스트 시나리오

기획한 기능이 모두 제대로 동작하는지 확인하기 위해 작성하는 문서

사용자가 기능을 사용하면서 경험하게 되는 과정을 상세하게 작성

3. 테스트 케이스

특정 조건이나 요구 사항을 충족하는지 확인하기 위해 여러가지 케이스를 작성한 문서

특정 조건 아래의 환경을 테스트하는 것이기 때문에 특정 조건, 테스트 범위, 케이스, 기대 값, 테스트 환경 등을 상세하게 작성

디자인 QA

디자인 화면과 개발된 화면을 띄워놓고 비교해보며 다른 부분이 발견됐다면, 팀원들과 내용을 공유하고 수정 요청

잘못 개발된 화면, 원래의 디자인 화면을 기획 의도와 함께 전달

발견한 이슈를 업무 티켓 형태로 전달하기 위해 지라나 트렐로와 같은 프로젝트 관리 툴 사용

이슈의 중요도 정하기

일정이 촉박한 경우 QA에서 발견한 모든 이슈를 수정하지 못 하고 배포해야할 수도 있다.

제품의 퀄리티를 해치는 이슈 먼저 해결할 수 있도록 이슈별 중요도를 표시해야한다.

4. 과제

👩‍💻
뱅크샐러드의 회원가입/로그인 과정에서 휴대폰 본인인증 화면에 대한 QA를 한다고 가정하고 숙제를 해볼게요.

  • 참고로 뱅크샐러드는 회원가입과 로그인 과정이 같습니다.
  • 앱을 설치(혹은 재설치)한 후 첫 화면이 휴대폰 본인인증입니다.
  • 휴대폰 본인인증 단계에서 일어나는 여러 가지 케이스를 테스트 케이스로 작성해 보세요.

테스트 케이스 작성

🎙️소감

실제 UIUX 디자이너가 어떤 조직에 속하고 어떤 프로세스로 일을 하는지 알아볼 수 있는 챕터였다.
생각보다 더 다양하고 세심한 일을 한다는 것을 알게되었다.

또한 과제로 뱅크 샐러드의 핸드폰 본인인증 화면에 대한 테스트 케이스를 작성해보았는데 본인인증 하나에 이렇게 많은 경우의 수가 존재하고 그것들을 고려해야 한다는 것을 깨달았다.

내가 아무 생각 없이 봐오던 화면들도 이런 과정들을 거쳐 배포됐을 생각을 하니 대단해보인다.

🤠 다음 시간 학습할 내용
디자인 툴
프로토타이핑 툴

profile
Life is pain au chocolat 🍞

0개의 댓글