IT 직무 이해와 커뮤니케이션 / 협업

 

UIUX 수업이 끝난 후, 본격적인 작업 프로세스 및 협업에 대해서 배우는 시간을 가졌다.

어찌보면 UIUX 학부 프로젝트는 많이 진행했지만 실무를 접해보지 못한 나 같은 교육생에겐 더 없이 이로운 시간이 아니었나 생각한다. 

오즈코딩스쿨의 32~33일차 수업 리뷰를 짧게 올려보고자 한다.

 

 

32일차 : 프로토타입의 기본과 심화까지

 

협업을 위해서 디자이너가 개발자에게 전달해주는 것이 바로 프로토타입이다.

또한, 실제 사용자들에게 User Test 를 진행할 때에도 유용하게 활용하는 것이 바로 프로토타입이다.

나 역시도 프로젝트를 진행하며 사용자 테스트를 위해 디자인 프로토타입을 만들어본 경험이 있었다.

 

따라서 프로토타입의 기본 요소들을 배우고, 프로토타입을 실제로 실습 자료에 적용해보는 시간을 가졌다. 

 

 

프로토타입의 정의란?

- 정적인 디자인을 실제 앱처럼 움직이게 만드는 과정이다.

 

단계별 목적

- 1단계: 사용자 경험 검증

- 2단계: 사용자 테스트 

- 3단계: 개발 커뮤니케이션 (화면 전환 방식, 팝업 동작, 애니메이션 효과, 예외 상황 등)

 

 

프로토타입의 기본 4가지 인터랙션: On Click / Scroll / Sticky / Overlay

프로토타입 심화 : Overlay (오버레이) / Variants (베리언츠) / Interactive Component (인터랙티브 컴포넌트)

 

Variants (베리언츠)

 

하나의 UI 컴포넌트가 가질 수 있는 여러 상태나 형태를 한 세트로 묶어 관리하는 기능

Button Component Set

State = Default
State = Hover
State = Pressed
State = Disabled

 

 

UI의 상태변화를 다음과 같이 변경할 수 있다. 

이때 Change to 라는 액션을 사용해서, 컴포넌트 상태를 변경한다.

Trigger: On click
Action: Change to
Destination: State = Selected
Animation: Smart animate

→ 사용자가 버튼을 클릭하면 선택된 모습의 Variant로 변경

 

 

구체적으로 예시를 들면, 토글 스위치의 on/off 상태에 따라 두 상태 변화를 만들 수 있다.

State = Off
State = On

Off 클릭
→ Change to
→ On

On 클릭
→ Change to
→ Off

 

이와 같은 인터랙션 예시에 사용할 수 있다.

'하나의 컴포넌트 내부 상태를 변경'하기에 좋다. 

Variants
버튼 Default → Pressed
체크박스 Unchecked → Checked
토글 Off → On

버튼 상태
탭 선택 상태
체크박스
라디오 버튼
토글 스위치
아코디언 열림·닫힘
북마크 저장·해제
좋아요 활성·비활성
입력창 기본·포커스·오류 상태
카드 선택 상태
하단 내비게이션 선택 상태

 

Variants 설정을 통해 하나의 화면에서 버튼 상태 여러개를 나타내 줄 수 있다. 

 

 

33일차: Handoff / 화면설계, 기능명세서 / UT & Maze

 

Handoff 란 무엇인가?

 

기획자는 무엇을 만들지 (요구사항, 기능정의) 를 디자이너에게 전달하고,

디자이너는 UIUX를 설계 (어떻게 보일지) 를 개발자에게 전달한 뒤,

개발자는 어떻게 작동할지 (API 연결, 화면 구현) 을 한다. 

 

 

<정의>

디자이너가 완성한 디자인을 개발자가 실제로 구현 가능하도록 전달하는 모든 소통 과정을 핸드오프 라고 한다. 

 

<성공적인 핸드오프의 요건>

질문이 최대한 적게 나오는 핸드오프!! (한마디로) → 명확성 / 일관성 / 효율성이 있다. 

- 명확한 전달, 용어, 숫자, 상태, 규칙에 대한 모호함 X (이를 위해, 마스터 컴포넌트를 전달하기도 한다. (휴먼 에러는 발생할 수 밖에 없으므로))

- 일관성 : 간격, 폰트, 컬러의 일관성 / 스타일 가이드와 명명 규칙

- 효율성 : 잘 정리된 파일 구조와 명확한 탐색 경로, 링크된 자원 

 

 

<그럼 무엇을 써야할까?>

레이아웃 & 간격 - 정확한 마진, 패딩 값 - 요소 간 간격, 정렬 방법 - 그리드 시스템, 반응형 구성	컴포넌트 - 버튼, 입력창 등의 크기 / 색상 / 폰트 - 그림자, 경계선, 둥근 모서리 스펙 - 재사용 패턴 및 변형
상태 명세 - Hover, Active, Disabled 등 - 선택됨/선택 안됨, 확장/축소 상태 - 오류, 로딩, 성공, 진행 중 상태	인터랙션 명세 - 화면 전환, 애니메이션 방식 - 제스처, 드래그, 스크롤 동작

 

 

<ex) 상태별 컴포넌트 정의>

 

개발자에게 모든 것을 이야기 해주어야 한다!

 

 

<핸드 오프에서 어떤 것을 염두해야할까?>

1) 모든 예외 케이스를 명시한다. (에러 메세지, 빈 화면, 로딩 상태 등까지)

2) 최대/최소 글자수를 명시한다 (텍스트가 너무 길거나 짧을 때 레이아웃의 변경)

3) 접근성을 고려한다. (스크린 리더 지원, 키보드 내비게이션, 색상 대비 등)

 

 

<그럼 Figma에서는 어떻게 작업할까?>

파운데이션 기반 디자인 시스템을 구축한다.

 - Color, Typography, Spacing을 공통 규칙으로 관리한다.

 - 디자인 시스템을 활용한다.

 

Frame 설정 및 네이밍

 - 웹 / 모바일 표준 해상도를 기준으로 프레임을 설정한다. (와이어프레임 작업은 375 * 812)

- 실무에서는 디바이스 점유율 또는 지원 해상도를 기준으로 설정하는데, 작은 화면에서 큰 화면으로 확장하는 것이 더 쉽기 때문에 이렇게 한다.

- 계층형 네이밍 예시: 1, 홈, 1-1, 상품검색, 1-2, 검색결과, 1-3, 알람

- 코드 & 화면명 네이밍 예시: HOME-001 홈, MYP-001 마이페이지, MYP-002 회원정보 수정, ORD-001 주문내역

 

인터랙션 및 개발 전달사항 정리

- 아코디언, 드롭다운, 바텀시트 or 버튼 상태별 안내 / 인터랙션 링크 공유

- 캐러셀은 최대 10개까지 노출 / 피드는 무한 스크롤(Infinite Scroll) 적용 768부터 3열로 노출되도록 변경 

- 화면 너비 768px 이상에서는 3열로 노출

 

 

<Handoff 를 위한 Asset 관리 및 명세>

아이콘, 이미지 자신을 체계화 하고 일관되게 제공

 

 

디자인 에셋을 네이밍(naming) 하는 것에는 4가지 종류가 있다.

- snake-case / kebab-case / camelCase / prefix.

 

최종적으로 핸드오프 단계에서 확인해야 하는 것은 다음 4가지와 같다.

1) 레이어 정리 : 불필요한 요소 / 숨겨진 레이어 제거, 논리적인 그룹과 명확한 네이밍으로 정리

2) 스타일 적용 확인 : 모든 텍스트와 색상이 디자인 시스템의 스타일 / 토큰을 사용하는지 확인

3) 반응형 대응: 모바일, 템플릿, 데스크탑 등 다양한 디바이스별 프레임이 올바르게 설정 되어있는지 활용

4) 상태 케이스 확인: 에러 상태, 로딩 화면, 빈 화면 등 모든 예외 실험에 대한 디자인이 누락되지 않았는지 확인

 

플로우 링크 점검

- 모든 화면과 상태가 적절히 연결되어 있는지 확인

- 개발자가 전체 사용자 플로우를 이해할 수 있도록 프로토타입 링크,  User flow를 제공하는 것이 좋다. 

 

핸드오프를 전달 후, 개발 QA에 참여하고, 이슈트래킹을 통해 계속해서 확인하는 것이 필요하다. 

또한, 전달사항을 문서화하는 것을 습관화 하고, 이슈 트래커/공식문서(Notion 등의 공유틀)를 사용해 과정을 투명하게 관리하는 것이 좋다.

 

 

핸드오프를 전달할 때 함께 전달하면 좋은 문서는 다음과 같다.

1) 디자인 Foundation 문서 - 타이포그래피, 컬러, 스페이싱, 레디우스 ...

2) Component, Design Asset - 페이지 따로 설정해서 컴포넌트 정리

3) IA - 2~3depth 로 엑셀/스프레트 시트로 작성

4) Wire Flow - lo~hi-fi 까지 흐름 이어주기

 

 

<화면 설계, 기능 명세서>

기능 명세서의 기본 구조를 배웠다.

구현해야하는 기능에 대해 상세하게 작성하는 문서로,

- 기능이 어떻게 작동하는지

- 작동되지 않을 때 case에서는 어떻게 처리(에러)하는지 를 기재한다.

 

> 예시 화면들을 몇 개 보여주셨다.

 

 

<UT & Maze>

마지막으로 UT 를 위한 프로토타입 만들기와 메이즈 이용법에 대해서 배웠다. UT를 위한 프로토타입을 만들 때, 시나리오를 기반으로 한 Task 위주의 연결 플로우를 만드는 게 좋다.이것은 나도 프로젝트를 진행할 때 동일하게 했던 방식이다.모든 기능이 구동하는 개발 프로토타입을 만드는 것도 당연히 좋겠지만, 일반적으로 그럴 자원과 시간이 부족하기 때문에 사용자 테스트 전까지는 만들 플로우를 중점적으로 정하고 그것을 실행에 옮기는 게 낫다고 생각한다. 

 

 

 

---

 

 

가장 새로운 것을 많이 배운 건, HandOff 문서에 대한 전반적인 내용이었다.

기능 명세서나 Maze 이용은 드문드문 해본 적이 있지만, 실제로 개발자와 협업을 하여 일을 할 수 있는 기회는 없었기 때문이다.

바이브 코딩이나 Figma Maze를 이용해서 프로토타입을 만들 때 왜 프로세스가 꼬였는지, 레이어 정리를 어떻게 해야하는지 감을 잡을 수 있는 중요한 시간이었던 것 같다.