[OZ코딩스쿨] Part 2 UI 디자인 실무_회고 (1)

[DAY09]

• HCD(Human-Centered Design) : 사용자의 맥락, 목표, 제약을 먼저 이해하고 설계 시작하는 접근
• Usability : 효과성, 효율성, 만족도로 사용하기 쉬운지 보는 관점
• 핵심 질문
  • 명확성 - 무엇을 할 수 있는지 한눈에 보이는가
  • 일관성 - 비슷한 요소가 비슷하게 동작하는가
  • 우선순위 - 무엇을 먼저 읽고 눌러야 하는가
  • 피드백 - 행동에 즉시 반응하는가

---

[DAY10]

• PD 직무 능력
  • 문제 해결 능력 Problem-Solving - 문제를 풀어내는 과정 (표면적 불만이 아닌 진짜 원인 분석)
  • 사용자 중심 사고 User-Centered - 사용자의 상황과 습관 이해하기 (사용자 리서치, 인터뷰)
  • 심미성 Aesthetic Appeal - 시각적 신뢰와 즐거움의 결합
  • 기능성과 실용성 Functionality & Useablilty - 직관적 흐름 / 조작의 편의성 / 단순함의 미학
  • 커뮤니케이션 Communication - 협업을 이끄는 디자인 언어 (의도 설명, 피드백 수용, 공감대 형성)
• 제품디자인
  1. 목표 설정 Goal Setting : 목표를 명확히 정의하면 제품의 목표가 조직의 방향성과 일치할 수 있음
  2. 리서치 Research : 정보 수집과 데이터 기반 인사이트는 디자인 프로세스를 이해하고 설계하는 데 도움을 줌
  3. 분석 Analysis : 데이터를 인사이트로 바꾸면 디자이너는 자사 사용자층을 더 잘 이해할 수 있음
  4. 제품 전략 및 기획 Product strategy and planning : 제품 팀은 비즈니스 목표를 달성하기 위한 디자인 전략 제안
  5. 실행 및 출시 이후 Execution and post-launch : 제품을 시장에 안착시키는 장기목표를 향한 활동을 추적하는 것이 마지막 의사결정 단계

→ 프로적트 디자이너는 사용자 경험(UX)과 화면 디자인(UI)을 만들어 비즈니스 목표를 달성하는 사람입니다.

 

• UI
  • 탐색 & 이동 UI : “지금 어디에 있는지, 다음에 어디로 갈 수 있는지”
    • 브레드크럼 Breadcrumb : 현재 위치를 단계적으로 이해하게 만드는 경로 표시
    • 페이지네이션 Pagination : 현재 위치와 다음 이동 범위
    • 인피니티 스크롤 : 아래로 스크롤할수록 콘텐츠 자동으로 로드되는 방식 (어디까지 봤는지 파악 어려움, 특정 콘텐츠 재탐색 어려움)
    • 도시락 메뉴 Bento Menu : 여러 기능 모아 보여주는 메뉴
    • 입력 & 선택 UI : 사용자가 입력하고, 고르고, 상태를 바꾸는 인터랙션 요소
      • 검색 필드 Search Field : 원하는 정보를 직접 찾아 들어가게, 메뉴 다 보지 않아도 바로 찾게 함
      • 버튼 Button : 역할에 따라 위계 분명해야 함, 무엇이 가장 중요한 행동인지 시각적으로 보여줘야함
      • 인풋 필드 Input Field : 텍스트 입력하게 만드는 기본 폼 요소 (라벨, placeholder, helper, error 역할 구분해서 설계)
      • 체크 박스 Checkbox : 여러 항목 동시 선택, 복수 선택 가능한지 전체 선택과 부분 선택 상태 필요한지 봐야 함
      • 라디오 버튼 Radio Button : 여러 옵션 중 하나만 고르게 하는 요소
      • 토글 / 스위치 Toggle / Switch : 어떤 기능 켜져 있는지 꺼져있는지 바꾸는 상태 전환 요소 (”지금 상태”를 보여주는 토글인지, “다음 행동”을 묻는 버튼인지 구분)
      • 칩스 Chips : 작은 선택지 가볍게 보여주고 선택 - 필터, 태그, 빠른 선택 UI
      • 선택 / 드롭다운 Select / Dropdown : 여러 옵션 중 하나 고르게 할 때 - 옵션 수 정해져있고, 사용자가 하나를 고르게 해야 할 때 (필터, 정렬, 옵션 선택)
      • 콘텐츠 & 정보 표시 UI : 정보를 어떻게 묶고 보여줄지 결정하는 요소
        • 아코디언 Accordion : 여러 정보 접고 펼치며 보여줄 때 - FAQ, 상품 정보, 설정 메뉴처럼 정보량은 많지만 한 번에 모두 펼칠 필요는 없을 때
        • 캐러셀 Carousel : 여러 콘텐츠 가로로 넘기며 보여주기 - 콘텐츠를 많이 넣기 쉽지만 사용자가 모두 보지 않을 가능성 높음
        • 카드 : 정보를 하나의 덩어리로 묶어 보여줄 때 - 제목, 설명, 가격, 버튼처럼 관련 있는 정보
        • 리스트 / 테이블 : 같은 목록이라도 무엇을 비교하냐에 따라 쓰임 달라짐 - 정보 순서대로 읽게 할 때는 List, 열 단위 비교가 중요할 때는 Table
        • 아이콘 : 짧고 빠르게 의미 전달하는 시각 언어
        • 프로필 / 아바타 : 시각적으로 구분하게 도와주는 대표 이미지 - 텍스트보다 빠르게 사용자 구분
      • 상태, 피드백 & 오버레이 UI : 사용자의 행동에 반응하고, 현재 상태 알려주고, 집중 유도하는 요소
        • 뱃지 Badge : 상태나 수량처럼 짧은 정보 작게 보여줌 - 우선순위를 빠르게 알려주지만 너무 많아지면 오히려 시선 분산
        • 툴팁 Tooltip : 버튼이나 아이콘의 의미를 보조로 설명하는 작은 정보 상자 - 추가 설명
        • 토스트 / 스넥바 Toast / Snackbar : 짧은 피드백을 화면 한쪽에 잠깐 보여주는 알림 요소
        • 모달 / 다이얼로그 Modal / Dialog : 현재 화면 위에 떠서 중요한 결정이나 입력에 집중하게 만드는 오버레이 UI - 정말 중요한 결정인지, 이 화면을 막아도 되는지 판단해야 함
        • 로더 / 스피너 Loader / Spinner : “지금 처리 중” 상태 - 아무 반응이 없는 것보다 “처리 중”을 보여주는 것이 나음, 상황에 따라 Spinner, Skeleton, Dot loader 중 무엇이 맞는지 고름
        • 프로그레스 바 Progress Bar : 작업이 얼마나 진행되었는지 보여줌 - 기다리는 시간이 길수록, 현재 어디까지 진행됐는지 알려주는 것이 불안감 줄여줌
        • 빈 상태 Empty State : “왜 없는지”, “다음에 무엇을 할지” - 빈 상태를 그냥 비워 두면 사용자는 멈춤, 다음 행동으로 연결해주는 장면
      • 패턴 & 심화 UI : 여러 UI 요소 조합
        • 폼 Form : 여러 입력 요소가 한 목적을 위해 묶인 패턴 - 입력 순서, 오류 처리, 완료 버튼까지 한 덩어리로 설계
        • 피커 Picker : 날짜, 시간, 옵션처럼 특정 값 골라 입력 - 직접 입력보다 선택이 안전한 값일수록 적합, 날짜, 시간, 옵션 선택
        • 슬라이더 Slider : 연속적인 값 조절할 때 - 가격 범위, 볼륨, 밝기처럼 “범위 안에서 어느 정도 값” 고르게 할 때
        • 스테퍼 Stepper : 수량이나 단계 한 칸씩 늘리고 줄이게 하는 패턴 - 실수 가능성 줄이고 싶을 때 적합, 장바구니 수량 변경이 대표적
        • 플로팅 액션 버튼 Floating Action Button : 중요한 행동일 때만 - 화면 위에 떠 있는 주요 행동 버튼

---

[DAY11]

• IA Information Architecture
  • Main Category : Bottom Navigation을 메인 카테고리로 설정
  • Sub Category : 메인화면에 보여지는 정보를 서브 카테고리로 설정
  • Depth : 서브 카테고리에서 페이지로 넘어가는 부분을 뜻함
  • Wireflow = Wireframe + User Flow 

→ IA 설계 > User Flow > Wire Flow

• Layout / Grid / Margin / Column
  • Margin : large 최소 24px / medium 최소 24px / small 최소 16px
  • Column : large 12~16개 / medium 8~12개 / small 4~6개
  • Gutter : large 16~24px / medium 16~24px / small 16px
  → 레이아웃 잡을 때 왜 그리드를 사용할까? 시각적 안정감 / 효율적인 협업 / 확장성
  • 4, 8배수 https://developer.apple.com/design/human-interface-guidelines
  • Header - 정체성과 주요 행동 / Footer - 하단의 보조 정보와 링크
  • GNB - 사용자가 어디든 갈 수 있게 해주는 메인 메뉴 / Sidebar - 섹션 안의 세부 이동 돕는 문맥형 내비게이션

 

• 와이어프레임 → MVP 서비스 고도화 단계
  • Low fidelity - 빠르게 아이디어 스케치
  • Mid fidelity - 기능 흐름과 구조 전달용
  • High fidelity - 사용자 테스트, 개발 전달 등
  • 왜 먼저 와이어 프레임을 그릴까?
    • 구조와 기능에 집중
    • 비용과 시간 절약
    • 원활한 의사소통
    • 사용성 검증

 

• 실무 꿀팁
  1. 디자인에 너무 신경쓰기 X - 와이어프레임은 디자인 시안 X
  2. 빠르게 그리고 초안부터 공유하기 - 디테일보다 러프하게 그린 후 빠른 공유 및 피드백
  3. 모든 화면 일일이 그리기 X - 동일한 화면 복붙 + 핵심 흐름만 연결해서 공통 템플릿화
  4. 사용자 흐름 빠뜨리기 X - 각 화면간에 주석으로 시각화
  5. 사용자 행동 유도 요소 누락 X - “이 화면에서 무엇을 해야하지?” 목적 및 CTA
  6. 디테일한 디자인 X 간단한 주석 달기 - “이 버튼 클릭 시 회원 가입 화면 이동”

---

[DAY12]

• Auto + Layout
  • 원활한 개발 작업 + 같은 규칙으로 화면 확장하기 쉬움 → 디자인 수정 효율 올라감
  • 요소가 규칙에 따라 움직임
    • 버튼 텍스트 길이 변경 → 버튼 크기 자동 반응
    • 리스트 아이템 추가/삭제 → 아래 요소 자동 재배치
    • 카드 내부 정보량 변화 → 간격/패딩 유지
    • 같은 규칙으로 여러 화면/상태 확장 가능

---

[DAY13]

• 오토 레이아웃 = 컨텐츠 흐름 중심
  • chip, 캐러설 UI 등 내용물에 따라 요소가 변해야 할 때 사용
  • 분기점별 레이아웃은 wrap 기능을 사용해야 함
  • wrap은 요소를 고정하는 것이 아니라 흐름에 따라 자동 재배치
• 콘스트레인츠 = 위치 기준
  • 화면 크기가 변해도 요소를 특정 위치에 고정하거나 비율에 맞게 늘어나게 할 때 사용
• 반응형 Responsive - 해상도에 맞는 적절한 사이즈의 화면 보여주는 식
  • 장점
    • 제작된 웹사이트 하나로 다양한 기기에 대응할 수 있고, 하나의 코드로 대응 가능
    • 모든 화면에서 일관된 콘텐츠 경험 줄 수 있음
  • 단점
    • 모든 기기에 대응해야하기 때문에 기기별 웹사이트가 적용되는 방식 통제 어려울 수 있음
    • 디자인에 더 많은 기간과 지식 필요
• 적응형 Adaptive - 각 해상도에 맞춘 화면을 개별로 제작하는 식
  • 장점
    • 기기별 최적화된 맞춤 디자인과 맞춤 경험 제공 가능
    • 고정된 화면들을 만들기에 초기 기획과 디자인 편리
    • 로딩 속도 빠름
  • 단점
    • 기기별로 화면을 만들어야해서 유지보수에 분리
    • 모든 기기에 대한 대응 어려울 수 있음
• 브레이크포인트 Breakpoint
  • 기기의 화면 너비에 따라 레이아웃이 변하는 특정 지점, 미디어 쿼리를 사용해 디자인 전환되도록 설정
• 반응형 디자인 선택하는 5가지 이유
  1. 디바이스의 유연한 대응 : 특정 기기값이 아닌 유연한 그리드를 사용해 무수히 다양한 화면 크기에 즉각 대응
  2. 유지보수 효율성 : 기기별로 여러 개의 소스 코드를 만들 필요 없이 단 하나의 코드로 모든 환경 관리
  3. SEO(검색엔진 최적화) 유리 : 단일 URL을 사용하므로 구글 등 검색엔진에서 유입 경로 분산 방지
  4. 일괄된 사용자 경험(UX) : 어떤 기기로 접속하더라도 서비스의 흐름과 시각적 아이덴티티가 동일하게 유지
  5. 비용 및 시간 절감 : 초기 설계 난이도는 높지만, 장기적으로는 기기 출시 때마다 새로 레이아웃 짤 필요 없어 경제적
• 디자이너, 개발자 협업 프로세스
  • 1단계 : TO-BE 기획 단계에서 디자이너가 개선 방향을 정의하고, 구현 가능 여부 함께 검토
  • 3단계 : IA 설계를 공유하며, GNB 기준으로 구성된 Sub Category를 개발자와 함께 확인
  • 4단계 : 개발자와 Breakpoint 기준을 협의한 후 화면 고도화 진행
  • 5단계 : 배포 전, 해상도별 레이아웃이 정상적으로 작동하는지와 인터랙션이 의도대로 구현되었는지 점수

---

[DAY14]

- MVP Project Process (Minimum Viable Product)

• Foundation : 디자인 시스템의 가장 기초가 되는 ‘시각적 원리(Visual Principle)’을 정리한 기본 설계 기반
  • 모든 디자인의 ‘출발점’이자 ‘공통 언어’
  • Color, Typography, radius, gap, patting, shadow
  1. 일관성
  2. 접근성
  3. 효율성
  → 개발 협업 디자이너와 개발자 간 스타일 값 불일치 → QA 단계에서 재작업 증가

 

• 디자인 시스템 설계 구조
  • 프로미티브 토큰 Primitive : 모든 토큰 값의 시작 raw value에 이름 붙이기
    • color, typo, space, radius
    • font-family, font-size, font style, font weight, Line height, Letter spacing
    • spacing(padding, gap), radius, unit, 4배수
  • 시멘틱 토큰 Sementic : 프로미티브 토큰을 참조해 사용 역할을 정의한 토큰
  • 컴포넌트 토큰 Component : 시멘틱 토큰을 참조해 매우 구체적인 역할 정의
    • 시멘틱 토큰을 버튼, 카드 등 UI 컴포넌트에 적용 시 지정
    • 디자이너는 보통 시멘틱 코드까지만 정의

---

[DAY15]

- 컴포넌트 Component : 일괄된 디자인을 유지하며 수정이 필요할 때 한 번의 수정으로 모든 인스턴스가 업데이트되는 기능 - 반복적으로 사용하는 디자인요소들을 컴포넌트화하면 디자인을 효율적으로 할 수 O

• Main Component : 아이콘 → 모듈 → 템플릿 → 페이지 구성
  • 스타일, 구조, 기본 상태를 결정하는 기준점
  • 한 번 속성을 수정하면, 원본의 속성 따라가지 X - 자식 요소를 수정할 경우, 더이상 부모 요소 변경 따르지 X
  • ‘/’를 활용해 인스턴스 폴더 구분하기
  • Current name($&) : 현재 레이어 이름 유지 (ex_Icon/레이어명 = Icon/$&)
  • Number() : 숫자를 오름차순 / 내림차순
  • Detach instance : Cmd + Option + B - 한 번 연결 해제하면 다시 연결 X
  • component 등록 시 왼쪽 패널의 Assets에서 확인 가능
  • 복붙 가능하며 부모 component 확인하고싶다면 마스터 - from this file로 확인 가능
• Component Property : 원본을 직접 수정하지 않아도 필요한 내용만 변경할 수 있게 도와줌
  • Text Property : 텍스트 변경
  • Boolean Property : 요소 보이기/숨기기
  • Instance Swap : 다른 컴포넌트로 교체 - 교체하고 싶은 아이콘이나 이미지도 컴포넌트 설정 되어있어야함

⛓️ 참고 사이트

https://designsystem.line.me/

https://gds.gmarket.co.kr/

https://carbondesignsystem.com/

https://atlassian.design/components