[2/29] 2주차 HW - 테스트케이스 작성 + 디자인 QA로 발견한 이슈 공유하기

📍 실습 목표

제품팀이 무엇인지 알아보고, UXUI 디자이너가 실무에서 사용하는 프로세스를 파악해보자!

 

🌈 이론 정리

제품팀의 이해

| 제품팀이란?

• 제품을 만들기 위해 각자 다른 전문적인 능력을 갖춘 사람들이 모인 팀을 의미합니다.
• 보통 1명의 제품관리자 (PO나 PM), 1명의 디자이너, 2명의 엔지니어가 제품팀을 구성하는 최소 조건입니다. 그 밖에도 회사에 따라 제품팀에 데이터 애널리스트, 마케터, BO(Business Operator) 등이 포함될 수 있어요.

 

💡 그럼 디자이너는 제품팀에만 속하나요?

스타트업에서는 목적조직과 기능조직이 교차하는 매트릭스 조직으로 팀을 구성하기도 해요.

 

| 목적조직과 기능조직, 매트릭스 조직

 

1. 목적조직

• 목적조직은 특정한 목적을 달성하기 위해 여러 직무의 사람들이 모인 팀입니다. 예를 들어, 핀테크 회사라면 도메인별로 대출팀, 카드팀, 예/적금팀으로 나뉠 수 있습니다.
• 일반적으로 제품팀이라고 했을 때 의미하는 조직입니다. 주로 스쿼드나 사일로라고 불리며 제품의 목표를 당성하기 위해 다양한 직무의 사람이 모여있는 팀이기 때문에 속도가 빠르고 효율적이라는 장점이 있습니다.

 

2. 기능조직

• 기능조직은 유사한 직무끼리 구성된 팀을 의미합니다. 예를 들어, 기획팀, 디자인팀, 개발팀 등이 해당됩니다.
• 기능조직은 주로 챕터라고 불립니다. 비슷한 일을 하는 사람들끼리 모여있기 때문에 전문 분야에 대해 깊게 논의하고 서로의 발전을 도울 수 있다는 장점이 있습니다.

 

 

3. 매트릭스 조직

• 구성원이 기능조직과 목적조직이 교차된 형태로 소속된 구성을 의미합니다. 예를 들어, 프로덕트 디자이너는 기능조직인 디자인팀에 속하면서 동시에 목적조직인 스쿼드에 속한다고 할 수 있습니다.
• 일반적으로 많은 스타트업이 이 방식으로 일하고 있습니다.
• 팀의 규모는 회사마다 다를 수 있지만 아마존의 창업자 제프 베조스는 최대 16명을 넘지 않는 것을 추천했습니다.

💡 피자 두 판의 법칙

신속하고 효율적으로 운용할 수 있도록 팀원을 피자 두 판으로 식사를 해결할 수 있는 수 이내로 유지하라는 원칙

 

| 제품팀이 일하는 방식 (린스타트업 & 애자일)

 

1. 린스타트업

• 린스타트업은 빠르게 제품을 테스트하고 그 결과를 다시 제품에 반영하는 운영 방식입니다.
• 린스타트업은 불확실성이 높은 스타트업에서 제품을 효과적으로 개발하기 위해 고안되었습니다. 핵심은 낭비를 중이는 것으로 적은 리소스(인력, 자본, 시간)로 제품을 만들어서 빠르게 시장에 검증해 가면서 기능을 고도화해 나가는 방법을 의미합니다. 
• '만들기 -> 측정 -> 학습'을 반복하면서 피드백을 받고 사용자 중심으로 제품을 만드는 것이 중요합니다.

 

2. 애자일

• 애자일은 일정한 주기로 빠르게 제품을 배포해 사용자의 피드백을 받고 요구사항을 수정해 나가는 과정을 반복하는 방법론입니다.
• 애자일(Agile)은 사전적으로 날렵한, 민첩한이라는 뜻이 있듯이, 애자일한 제품팀은 1~4주의 스프린트 단위로 제품을 개발, 테스트하고 피드백을 받아 개선해 나가는 과정을 반복합니다.
• 수평적으로 일하면서 불필요한 의사결정을 줄이고 즉각적인 계획과 실행으로 피드백을 빠르게 반영할 수 있습니다. 빠르게 변화하는 환경에 맞추어 기민하고 유연하게 대응할 수 있다는 것이 장점입니다.

 

💡 애자일과 반대 의미인 폭포수(Waterfall) 방식과 비교하면 애자일을 이해하는데 도움이 됩니다.

• 폭포가 떨어지는 것처럼 수직적으로 각 단계를 하나씩 단계를 진행하는 방법론입니다.
• 각 단계가 완벽하게 완성되었을 때만 다음 단계로 넘어가고 이전 단계로는 돌아가지 않습니다. 따라서 요구사항 설계부터 디자인, 개발이 순서대로, 그리고 독립적으로 진행됩니다.
• 단계별로 업무 분담이 명확하고 진행 상황 파악이 쉽습니다. 따라서 관리해야하는 직원이 많은 대기업에서 채택하는 방식입니다. 하지만, 속도가 느리고 변화하는 상황에 유연하게 대처하기 어렵다는 단점이 있습니다.

📕 용어 정리

1. 스프린트

• 스프린트는 사전적 의미는 짧은 거리를 전속력으로 달리는 것을 의미합니다.
• 제품팀에서 말하는 스프린트는 집중해서 여러 태스크를 완료하는 1~4주 정도의 짧은 기간을 뜻합니다.
• 주로 스타트업에서 스프린트를 여러 번 반복하며 밀도 있게 일합니다.

2. 스크럼

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

3. 이터레이션

• 짧은 주기로 스프린트를 이어 나가는 것을 의미합니다.

 

UXUI 실무 디자인 프로세스

| UX/UI 실무 프로세스

1. 디자인 프로세스

 

1). 기획

• 문제 정의 -> 아이데이션 -> 프로덕트 스펙 문서 작성

2). 디자인

• 초안 디자인 -> 피드백 -> 최종 디자인 확정 및 핸드오프

3) 개발

• 디자인 QA

2. 실험 문화

• 제품의 개선이 실제로 사용자에게 더 나은 경험으로 이어지는지 데이터로 검증하는 것입니다.
• 실험은 대부분 A/B 테스트로 진행됩니다.
• A/B 테스트 설계를 할 수 없을 때, 특정한 상황에서는 전후 비교 테스트를 하기도 합니다.

💡  A/B 테스트란 두 가지 이상의 버전을 각각 다른 사용자에게 보여주고 성과를 측정하는 실험입니다.

 

3. 디자인 QA

• QA : Quality Assurance의 약자로, 제품이 출시되기 전에 기능을 테스트하는 것을 의미합니다.
• 제품이 처음 기획한 대로 잘 구현이 되었는지, 회사에서 생각하는 품질 기준이 충족되었는지를 확인하는 과정입니다.
• 규모에 따라 별도로 QA 팀이 있기도 하고 제품팀에서 QA를 수행하기도 합니다.
• QA 팀이 있더라도 기능을 만든 담당자라면 대부분 직접 QA를 합니다.

3-1. QA 문서

1) 체크리스트(CL) 

• 예/아니요, 혹은 Pass/Fail로 답변할 수 있는 확인 성격의 항목을 나열한 목록입니다.
• 기능이나 개선 범위가 넓지 않을 때 사용합니다.

2) 테스트 시나리오(TS)

• 기획한 기능이 모두 제대로 동작하는지 확인하기 위해 작성하는 문서입니다.
• 사용자가 기능을 사용하면서 경험하게 되는 과정을 상세하게 적습니다.

3) 테스트 케이스(TC)

• 특정 조건에서 요구 사항을 충족하는지 확인하기 위해 여러가지 케이스를 작성한 문서입니다.
• 특정 조건 아래의 환경을 테스트하는 것이기 때문에 특정 조건, 테스트 범위, 케이스, 기댓값, 테스트 환경 등을 상세하게 적어야 합니다.

3-2. 디자인 QA

• 디자인과 다른 부분을 발견했다면 팀원들과 내용을 공유하고 수정을 요청해야 합니다.
• 어디가 잘못되었는지 엔지니어가 정확하게 알 수 있도록 작성하는 것이 좋습니다.
• 잘못 개발된 화면과, 원래의 디자인 화면을 기획 의도와 함께 전달해야 합니다.
• 조직에 따라 다르지만 지라나 트렐로 같은 프로젝트 관리 툴을 사용한다면 관리하기 좋게 발견한 이슈를 업무 티켓 형태로 전달하는 것이 효율적입니다.

3-3. 이슈의 중요도 정의하기 

• 배포 일정이 촉박한 경우 QA에서 발견한 모든 이슈를 수정하지 못하고 배포해야 할 때도 있습니다. 이때는 제품의 퀄리티를 해치는 이슈 먼저 해결할 수 있도록 이슈별 중요도를 표시해 주는 것이 좋습니다.

**HIGHEST**

• 당장 대응이 필요할 정도로 주요 기능에 문제가 있는 경우

**HIGH**

• 사용자가 행동을 완수할 수 없는 이슈
• 기능상 사용성에 치명적인 문제가 될 수 있는 것

**MEDIUM**

• 사용자가 행동을 완수하는 데 어려움을 겪을 수 있는 문제
• 단계를 넘어가는 데에 어려움이 없으나 기획이나 피그마 디자인 화면과 다르게 적용된 것
• 사용자가 상황을 제대로 이해하기에 어려움이 있는 것 (예시: 네트워크 오류로 팝업이 떠야 하는 상황에서 알 수 없는 오류 팝업이 뜨는 이슈)
• 시각적으로 오류가 난 것처럼 보이는 것

**LOW**

• 기능상 문제가 없는 것
• 피그마 화면과는 다르지만, 맥락상 과정을 이해하기에 어려움이 없는 것
• 오픈 후 수정되어도 문제없는 디테일한 부분

**LOWEST**

• 단순 의견 정도의 레벨로 급하게 반영되지 않아도 될 이슈

 

🌈 과정

 

1. '뱅크 샐러드'앱의 로그인 및 회원가입 과정에서의 테스트케이스 만들기

테스트 케이스

 

 

2. 테스트 케이스를 바탕으로 개선되어야 할 부분의 디자인QA 만들기

인증번호 입력하는 창에 대한 디자인QA