[25.01.22] UXUI 디자인 입문 3주차 + TIL

🗓️ 오늘의 일정

- UXUI 디자인 입문 3주차

---

✏️ 디자인 카타

🔷디자이너스: 정보 입력 완료 방식

📢 CTA vs 자동 확인

 

1. B를 선택한 이유

-  내가 입력한 정보에 대한 피드백이 바로바로 돌아온다면(alert toast라든지... validation이 바로바로 되면) 자동확인이 당연히 편할 것 같다. 어쨌든 프로세스가 하나 줄어드는 거니까.
- 하지만 validation이 어떤 상황에서 나타나게 될 것인지? 5자리만 입력했을 때? 이외 숫자 자리수만 맞게 입력하면 틀렸어도 그냥 넘어가는데...

- 자동 확인 후 이동하기 전에 입력하고 나서 1~2초 정도 텀을 두고 넘어간다면 좋을 것 같다. 도허티 임계값은 0.4초이지만 보안과 같은 특정 상황에서는 일부러 느리게 로딩을 진행하는 경우도 있으니...?

- 그러나 사용자가 입력하다 실수할 수도 있으니 자동으로 섹션이 넘어가면 오히려 다시 돌아와야 해서 불편할 것 같다는 점은 지울 수가 없다...

 

2. A를 선택하지 않은 이유
- cta 버튼에 필드가 가려지는 경우가 있다. 공간을 넓게 못 쓴다.

- 결국 프로세스가 하나 늘어나는 거니까 불편함

- 문항이 하나라면 상관 없겠지만, 회원가입이라는 지루한 절차에 매번 버튼을 눌러야 한다면 사용자가 긍정적인 기분을 느끼지는 않을 것 같다

 

3. 다른 사람의 의견

- 프로그레스 바가 있으면 좋을 것 같다.

- B가 사용자 플로우를 깨지 않는다.

- A가 접근성 측면에서 더 타당하다. 실수했을 때 다시 돌아와야 하는데, 손이 불편하거나 타자가 느리면 더 짜증이 날 것이다.

 

4. 정리

- 만약 다음 섹션이 주민번호 앞자리 -> 뒷자리라면 당연히 B 자동 확인 및 섹션 이동이 좋고
- 다음 섹션이 전화번호 입력 및 인증 섹션처럼 아예 페이지가 바뀐다면 A가 나을 것 같다
- 입력 필드 포맷에 따라 필드를 자동으로 추가하는 방식이라면 이름-주민등록번호-휴대폰 번호-통신사 입력할 때까진 B, 모든 필드들 다 채우고 나면 A가 좋을 것 같다

 

5. 사례

때로는 ‘가짜 로딩’ 화면이 필요합니다 - DIGITAL iNSIGHT 디지털 인사이트

 

- 구글은 메일 발송 후 화면 하단에 실행 취소 팝업을 5초간 띄운다. 마치 발송에 5초가 걸리는 척 뜸을 들여 사용자가 행동을 취소할 여유를 주는 것이다.

 

거꾸로 입력하는 가입 화면, 처음에 어떻게 떠올렸을까?

- 토스는 하나의 필드를 채우면 자동으로 다음 필드가 화면에 나타난다. 그러나 버튼에 가려지는 것을 막기 위하여 역방향으로 쌓이는 방식을 선택했다.

---

✏️ UXUI 디자인 입문 3주차

🔷 3주차 강의

📢 제품팀이란?

- 정의: 제품을 만들기 위해 각자 다른 전문적인 능력을 갖춘 사람들이 모인 팀

 

1. 팀 구성 방식

1명의 제품관리자 (PO나 PM), 1명의 디자이너, 2명의 엔지니어가 제품팀을 구성하는 최소 조건

- 기획, 디자인, 개발로 프로세스 진행되어서 기획자 디자이너 개발자는 무조건 있어야 함. 이외 데이터 애널리스트, 마케터, 비즈니스 오퍼레이터 등 포함

 

1) 목적 조직

- 일반적으로 제품팀이라고 하면 목적조직을 말함. "스쿼드", "사일로"라고 부른다.

- 제품 목표 달성을 위해 여러 직무 사람들이 모인 팀. 빠르고 효율적

 

2) 기능 조직

- 유사한 직무끼리 구성된 팀. 기획팀, 디자인팀, 개발팀. "챕터"라고 부른다.

- 전문성 극대화

- 회사에 따라 기능조직으로 구성을 해놓고 필요할 때마다 TF(Task Force) 형태로 목적조직을 구성하기도 함.

 

3) 매트릭스 조직

- 기능조직과 목적조직이 교차된 경태.

- 스타트업이 주로 선택.

- 예를 들어, 디자이너 한명이 디자인팀에도 속하고 스쿼드에도 속하는 것.

 

2. 일하는 방식

1) 린 스타트업

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

- 대부분의 기업은 아직 시장에 프로덕트 마켓 핏을 찾지 못하고 성공해야 한다는 목표를 가지고 있다. 시간, 돈, 사람 모든 리소스가 부족한 상황에서 효율적으로, 좋은 제품을 만들기 위해 고안한 방식이다.

- 그렇다면 어떻게 해야 할까? 사용자에게 물어보는 것이다. 자주, 많이. 

- 적은 리소스로 낭비를 줄이는 것. 피드백을 통해 빠르게 반복적으로 개선하는 것.

 

2) 애자일

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

- 1~4주의 스프린트 단위로 제품을 개발, 테스트하고 피드백을 받아 개선

- 린 스타트업과 비슷한 의미. 좀 더 구체적인 방법론이라고 생각하면 됨.

- 워터폴 방식과 비교하면 이해하기 쉽다.

- 워터폴: 단계적. 수직적. 독립적. 규모 큰 대기업에 적합. 업무의 가시성이 뛰어남. 그러나 시장변화에 빠르게 대응하지 못함. 시간과 비용이 많이 소요됨.

- 애자일: 빠름. 작은 단위. 최대 4주 이내. 대응 유연.

 

3) 애자일 용어 정리

 

- 스프린트: 업무 주기를 말한다. {설계, 디자인, 개발, 테스트, 배포} → {요구사항 맞춰 다시 설계, 디자인, 개발, 테스트, 배포}  → 반복. 이 한 주기, 기간을 스프린트라고 한다.

- 스크럼: {설계, 디자인, 개발, 테스트, 배포} 프로세스, 방법론.

- 이터레이션: 스프린트를 반복하는 것.

- 스크럼 방식으로 스프린트를 이터레이션한다...

 

📢 UX/UI 실무 프로세스

1. 디자인 프로세스

 

1) 기획

- 문제 정의: PO/PM이 담당. 디자이너가 참여하는 경우도 있고 아닌 경우도 있다.

- 아이데이션: 해결 방안 아이디어를 내고 솔루션을 선택한다. 솔루션 스케치(와이어프레임)을 진행하기도 한다.

- 프로덕트 스펙 문서 작성: 솔루션에 대한 상세 내용을 글로 먼저 적어보는 것.

 

2) 디자인

- 초안 디자인: 디자인 툴로 디자인. 디테일<전반적인 유저 플로우, UX. 놓친 엣지 케이스(소프트웨어나 시스템이 일반적인 동작에서 벗어나는 예외적인 상황)는 없는지?

- 피드백: 공유, 피드백. 프로토타이핑을 진행하기도 한다.

- 최종 디자인 확정 및 핸드오프: 완성 후 개발자에게 넘긴다!

 

2-1) 핸드오프 (https://yozm.wishket.com/magazine/detail/2099/)

- 엔지니어의 이해를 위해 다음 내용을 포함하는 것이 좋다.

- 유저 플로우: 시작 화면 표시, 연결 표시하여 흐름 시각화

- 유즈 케이스: 상황에 따른 화면 정의. 예를 들어, 회원가입 화면에서는 정상 입력, 입력값 오류, 입력 가능 시간 초과 등의 다양한 상황이 생길 수 있다. 사용자에 액션에 따른 정상, 오류, 기타 페이지를 다 정의해야 한다... 개힘들겠다...

- 반응형 레이아웃을 위한 가이드

 

3) 개발

- 디자인 QA: 디자인대로 개발되었는지 확인. 최대한 사용자와 비슷한 환경으로 테스트 android, iOS 같이 확인

 

2. 프로덕트 스펙 문서

- PRD(Product Requirements Document, 제품 요구사항 정의서)

- 기획 배경과 솔루션, 기능 요구사항, 실험 계획 등을 정의하여 팀원 모두에게 공유, 가이드.

- 하나의 문서로 작성하는 것이 좋다. 아니라면 URL로 첨

 

1) 기획 배경 & 문제 정의

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

2) 솔루션 설명 (디자이너 역할 가장 중요!)

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

3) 실험 설계

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

4) 예상 일정

• 프로덕트 스펙 초안 작성 완료 예상 일정
• UI/UX 디자인 최종 시안 제작 완료 예상 일정
• 개발 분야별 예상 일정 (프론트엔드, 서버, 이벤트 설계, QA가 각각 세부적으로 작성되어야 함)
• 배포 목표 일정

3. 디자인 공유하고 피드백 받기

- 이해하기 쉽게 충분한 정보를 포함할 것

 

1) 배경

- 기획 배경, 데이터, 가설

 

2) 필수 리뷰어

- 꼭 피드백을 받고 싶은 사람을 지정

- 연관된 사람 참조

 

3) 참고 문서

- 프로덕트 스펙 문서, 디자인 파일, 프로토타입

 

4) 피드백 기한

- 여유를 가지고 공유할 것. 일정에 영향 X

- 여유가 없다면, 피드백 받고 싶은 기한도 함께 표시할 것

📢 협업하기

1. PO/PM

1) PM

- Product Manager. 제품의 전략을 세우고, 우선순위를 결정해 실행

- 실제 프로젝트를 수행하는 실무의 성격이 강하다

- 요구사항 분석, 전략 설계, 지표 관리 및 분석 등의 업무를 수행

 

2) PO

- Product Owner. 제품에 대한 오너십을 갖고 제품이 시장에 잘 전달될 수 있도록 관리

- PM보다 더 많은 역할과 책임을 가진다

- 로드맵과 전략 설계, 지표 관리 및 분석 등의 업무를 수행. 동시에 제품팀의 조직을 관리, 이해관계자와 논의, 환경 조성 등 담당

 

2. 엔지니어

- 엔지니어와의 소통이 원활할수록 디자인이 더 정확하고 완성도 높은 수준으로 사용자에게 전달된다

 

1) 프론트엔드 엔지니어

- 사용자가 만나는 지점, 특히 눈에 보이는 영역의 기능을 구현

- 앱/웹의 페이지, 화면 안의 각종 컴포넌트 즉, UI를 코드로 구현

- 화면 간의 이동, 컴포넌트의 모션, 사용자의 인풋에 따른 반응까지 구현

 

2) 백엔드 엔지니어 (서버 엔지니어)

- 제품에 필요한 정보를 저장하거나 전송하고, 관리하는 영역을 담당. 효율적인 운영 구조 고민.

- 접점은 적지만 그래도 이야기를 나눌 일이 종종 있다!

 

3) QA 엔지니어

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

- 조직 규모 작으면 없을 수도

 

4) 데이터 애널리스트

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

- Raw 데이터를 보기 좋게 가공하고 시각화

 

5) BX 디자이너

- Brand eXperience Designer. 브랜드 경험과 관련된 전반적인 디자인.

- 로고나 심볼처럼 아주 기본적인 것부터 앱/웹에 들어가는 그래픽, 대외에 노출되는 이미지, 각종 인쇄물 등 브랜드를 나타내는 모든 부분을 담당

- BX 디자이너가 정한 BI에 따라 UI를 제작하는 것

 

6) UX writer

- 제품 내의 문구를 담당

- 브랜드의 보이스앤톤을 문구로 전달

- 조직 규모 작으면 디자이너가 대신하기도

 

📢 실험 문화

1. 실험이란?

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

 

2. 실험을 해야 하는 이유

- 편향된 주관 배제

- 객관적인 의사 결정

- 호불호를 데이터로 증명

 

3. 실험 환경 이해하기

1) 전후 비교 테스트

- 실험 기간 전후로 지표가 어떻게 달라졌는지를 비교

 

2) A/B 테스트

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

- 기존 화면은 대조군(Control), 테스트하고 싶은 안을 실험군(Treatment)으로 정한다.

- 이처럼 사용자를 두 집단으로 나누고 어느 집단이 더 좋은 지표를 보이는지 측정하여 평가한다.

- 변수의 효과를 정확히 측정하기 위해 변수는 1개로 제한한다. 

- 제품 변화를 통한 행동 양상의 변화를 측정하여 상관관계와 인과관계를 분석하여 더 나은 의사결정을 할 수 있다.

- 사용하는 도구는 다음과 같다.

Amplitude | Product Analytics & Event Tracking Platform | Amplitude

 

Google Analytics  |  Google for Developers

 

📢 디자인 QA

1. QA

- Quality Assurance. 제품이 출시되기 전에 기능을 테스트.

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

- 결함 유무, 품질 수준, Product Spec 구현 정도, 비정상 케이스, UX 사용성을 확인한다

 

2. QA 문서

1) 체크리스트(CL)

- 예/아니요, 혹은 Pass/Fail로 답변

- 기능이나 개선 범위가 작을 때 사용.

 

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

- 기능 동작 여부 확인

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

 

3) 테스트 케이스(TC)

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

- 특정 조건, 테스트 범위, 케이스, 기댓값, 테스트 환경 등을 상세히 작성

 

2. 디자인 QA

- 디자인 화면과 개발 화면을 비교. 잘못된 부분 발견 시 내용 공유하고 수정 요청

- 지라나 트렐로 같은 프로젝트 관리 툴을 사용. 업무 티켓 형태로 전달

디자인 QA 업무 티켓 예시

 

- 🍯꿀팁: 이슈의 중요도 표시하기. 업무 일정이 촉발할 때, 효율성을 높이기 위함

 

🔷3주차 숙제

뱅크샐러드 휴대폰 본인인증

1. 테스트 케이스 작성

화면	조건	테스트 케이스	입력값	기댓값	테스트 환경
휴대폰 본인인증 (텍스트 필드)	정상	모든 텍스트 필드에 정상 값 입력	이름: "홍길동" 주민등록번호 7자리: "######-#" 통신사 선택 모달: skt 휴대폰 번호: "###-####-####"	인증요청 버튼 터치 → 약관 동의 모달 (체크박스)	Android
휴대폰 본인인증 (텍스트 필드)	에러	이동통신사 정보에 등록된 정보와 일치하지 않는 이름 입력	이름: "홍?동"	유효성 검사 모달 "정보를 확인해 주세요 (이하생략) "	Android
휴대폰 본인인증 (텍스트 필드)	에러	올바르지 않은 형식의 이름	이름: "[모음]길동"	유효성 검사 라벨 "한글 또는 영문으로 입력해주세요"	Android
휴대폰 본인인증 (텍스트 필드)	에러	이동통신사 정보에 등록된 정보와 일치하지 않는 주민등록번호 입력	주민등록번호 7자리: "#####?-#"	유효성 검사 모달 "정보를 확인해 주세요 (이하생략) "	Android
휴대폰 본인인증 (텍스트 필드)	에러	이동통신사 정보에 등록된 정보와 일치하지 않는 통신사 선택	통신사 선택 모달: kt	유효성 검사 모달 "정보를 확인해 주세요 (이하생략) "	Android
휴대폰 본인인증 (텍스트 필드)	에러	이동통신사 정보에 등록된 정보와 일치하지 않는 휴대폰 번호 입력	휴대폰 번호: "###-?###-####"	유효성 검사 모달 "정보를 확인해 주세요 (이하생략) "	Android
휴대폰 본인인증 (약관 동의 모달)	정상	필수 동의 항목 모두 동의	모두 동의하기 터치	인증번호 입력 모달 "인증번호 입력 (이하생략) "	Android
휴대폰 본인인증 (약관 동의 모달)	정상	필수 동의 항목 모두 동의	[선택] 항목 제외	인증번호 입력 모달 "인증번호 입력(이하생략)"	Android
휴대폰 본인인증 (약관 동의 모달)	에러	필수 동의 항목에 동의하지 않음	필수 항목 n개 제외하고 선택	(1시간 제한 걸려서 확인 불가...)	Android
휴대폰 본인인증 (텍스트 필드+약관 동의 모달)	에러	5번(사실 몇 번인지 세지 않아서 확실하지 않음) 틀리고 다시 인증 요청	정상값 or 에러값 상관없이 입력 필수 항목 동의 or not	인증 제한 모달 "최대 인증 시도 횟수를 초과했습니다. 1시간 뒤에 다시 시도해주세요.	Android
휴대폰 본인인증 (인증번호 입력)	정상	2분 내로 올바른 인증번호 입력	인증번호: "######"	확인 버튼 터치 → 잠금번호 입력으로 이동	Android
휴대폰 본인인증 (인증번호 입력)	에러	일치하지 않는 인증번호 입력	인증번호: "#####?"	(1시간 제한 걸려서 확인 불가...)	Android
휴대폰 본인인증 (인증번호 입력)	에러	2분 내로 입력하지 않음	인증번호:	(1시간 제한 걸려서 확인 불가...)	Android

- 인증번호 재요청도 여러번 하면 에러가 날 것 같은데 제한 걸려서 모르겠음...

 

2. 디자인QA로 발견한 이슈 공유

Fail	기대 결과
- 긴 텍스트 입력 시 텍스트 필드 컨테이너를 자체를 이탈 - 텍스트 필드를 초기화하는 X 버튼이 나타나지 않음	- 긴 텍스트 입력 시 말줄임표를 사용 - 텍스트 필드에 텍스트 입력 시 컨테이너 내부 우측에 즉시 X 나타남

 

3. 이슈 공유 메세지 작성

[회원가입/로그인 화면 디자인 QA 중 이슈 발생]

홍길동 [Product Designer]
@전우치

전우치 엔지니어님 안녕하세요! 
다름이 아니라 회원가입/로그인 화면 디자인 QA 진행 과정에서 이슈를 발견하여 수정 요청 드리고자 메세지 드렸습니다.

참고 문서: Figma file
마감 기한: ~~~~까지
수정 방향:

Fail	기대 결과
- 긴 텍스트 입력 시 텍스트 필드 컨테이너를 자체를 이탈 - 텍스트 필드를 초기화하는 X 버튼이 나타나지 않음	- 긴 텍스트 입력 시 말줄임표를 사용 - 텍스트 필드에 텍스트 입력 시 컨테이너 내부 우측에 즉시 X 나타남

궁금하신 사항 있으시면 언제든지 연락 주세요. 감사합니다.

---

🗒️ TIL

✨ 오늘 새롭게 알게 된 내용

- 실무에서 활용되는 용어들을 알게 되었다!

- 엣지 케이스, PRD, 핸드오프, 퍼널(이건 플로우랑 헷갈렸었다)...

- 확실히 강의를 들으니 이해가 잘 된다 읽기만 하는 것보다 ㅎㅎ

 

✨ 오늘 있었던 어려움

- 3주차 숙제를 아직 못끝냈다네요... 

+++ 끝냈어요 와아아아아앙

 

✨ 어려움을 극복하기 위해 내가 시도한 것과 해결 방법

- 테스트 케이스 를 열라 찾아보고 있다네요... omg 유튜브야 나를 도와줘

- 그리고 머리가 너무 아프고 토할 것 같아요 i'm about to vomit rn

 

✨ 오늘의 회고와 발전 방향

- uxui 디자이너가 되고 싶다고 해놓고 실무 프로세스도 제대로 모르고 있다는 게 좀 창피했다... 오늘 알았으니까 됐어 어제의 나보다 나아졌다 부처님 이르시길 집착하지 말라고 하셨다

- 암튼 그렇다네요? 내일은 4주차 무사히 듣고 운동도 하는 게 목표예요 예~~~