검색

전자정부 UI/UX가이드에 의하면 푸터는 브랜드영역에 있어야 하는 항목이고, 사이트 목적에 따라 필수적으로 푸터에 넣어야 되는 항목들이 존재합니다.

따라서 웹사이트의 푸터는 페이지마다 반드시 적용되어야 하는 것은 아닙니다. 푸터는 사용자가 탐색 과정에서 확인하지 못한 내용을 다시 확인할 수 있도록 도와주는 역할을 하지만, 모든 페이지마다 동일한 내용이 반복되지 않아도 됩니다. 특정 정보나 서비스에 대한 접근성을 높이고, 사용자의 다음 행동을 유도하기 위한 목적으로 사용될 수 있기 때문에 웹사이트의 목적과 사용자의 편의성을 고려하여 적절하게 적용되어야 합니다.

푸터 구성 요소 정리

웹사이트 기능별로 필요한 푸터 항목을 아래와 같이 정리할 수 있습니다:

• (기능 없는) 브랜드 홈페이지
  • 회사 정보: 대표자명, 사업자등록번호, 주소, 전화번호 등
  • 이용약관
• 회원가입 기능이 있는 경우
  • 개인정보처리방침
  • 이메일 주소 무단수집 거부 안내
• 결제 기능이 있는 경우
  • 전자상거래 이용약관 추가
• 업종별 특성에 따른 추가 요소
  • 언론사: 고충처리인 제도 안내, 저작권 보호 관련 정보

이 구성을 통해 웹사이트의 목적과 사용자 요구를 충족시키면서 법적 요구사항도 준수할 수 있습니다. 한국디자인시스템

해당 부분은 회사/조직별로 다르며, R&R 정리 및 협업 프로세스 협의를 통해 가장 최선의 방법을 찾아나가야 함. 아래 내역은 참고하시기 바라며, RACI 프레임워크 참조한 적용도 좋은 방법임

협업 기준 명시

• 기획자 : IA / 와이어프레임 1차 설계
• 디자이너 : 디자인 요소/컴포넌트 관점에서 해석 & UX 요소 강화
• 필요 시 RACI 테이블 등 프레임워크 기준 R&R 구분도 가능.

⚠️ 리스크 요소

기획자의 기획서가 과도한 완성형으로 전달되면 디자이너는 경험 개선 여지를 찾기 어려움 → 와이어프레임은 정답이 아님. 더 나은 서비스를 위해 변동될 수 있음을 모두가 인지.

역할 정의 (R&R)

[서비스 제안 & 요구사항 도출]

• 기획자 : 고객 / 비즈니스 / 기능 요구 수집 및 정의, 타겟 유저 페르소나 설정 및 유저 스토리 구성
• 디자이너 : UX 리서치 결과 제공, 유저 페르소나 공유

[서비스 기획]

• 기획자 : IA 설계 및 플로우 차트 정의 (depth에 따른 계위 / 기능 흐름 구성)
• 디자이너 : IA 구조에 기반한 UX 관점의 구조 피드백, 디자인 관점에서 플로우 보완 제안

[와이어프레임]

• 기획자 : 기능 흐름 중심의 와이어프레임 설계, 화면 간 전환, 상태 흐름 정의 포함
• 디자이너 : 초기 비주얼 스케치 및 UX 개선안 적용, 인터랙션 및 사용성을 고려한 재구성 제안

[UI 디자인]

• 기획자 : CTA 및 기능 요구 명확히 정의
• 디자이너 : 유즈케이스(초기/이용/로딩/에러 등)에 따른 화면 디자인, 디자인 시스템 및 컴포넌트 적용 => 최종 Figma 완료본 제작

[피드백 / 수정]

• 기획자 : 사용자 시나리오 기반 피드백 수렴 및 정리
• 디자이너 : 시각적 힌트, 정보 과부하, 사용성 중심 피드백 반영, 디자인 개선안 적용

[개발 전달 (핸드오프)]

• 기획자 : 기능 정의서 작성, 상태 / 예외 처리 정의
• 디자이너 : 디자인 가이드(Figma) 제공, 스타일 가이드 포함

[공동 리뷰 & 개선]

• 기획자 : 개발 및 QA 결과 반영하여 기획 수정,
• 디자이너 : 개발 및 QA 결과 반영하여 디자인 수정

[Release 기준 정리]

• 기획자 : 최종 Release 기준 기획 내용 정리, 백로그 항목 검토
• 디자이너 : 최종 Release 기준 디자인 정리

2. 프로세스 문서화

- 프로세스
    [요구사항 정의] → [IA 구조 작성 ]→ [UX 구조 검토] → [와이어프레임 작성]→ [UI 디자인 및 비주얼 구성] → [기획자-디자이너 상호 피드백] → [최종안 확정] → [개발 진행 ] → [추가 이슈 반영 & 업데이트] 
    
- 커뮤니케이션 가이드
    - 피그마 코멘트 활용 기준
        - 모든 피드백은 @이름 태그 + 목적 명시 → 개발자가 양쪽의 의도 파악하는 것도 가능.
        - 기획자 : 기능 목적 및 기획 의도 공유
        - 디자이너 : 개선 사유 및 의도 공유
        
        (예시)
        @디자이너 기존에 정의된 팝업 대신 다른 형태의 팝업이 필요한 이유가 뭔가요? 
        @기획자 여기서 다른 형태의 팝업을 띄우는 것은 유저에게 다른 액션을 유도하기 위함입니다
        
    - 정기 Sync 및 일일 스크럼을 통해 지속 업데이트

3. 체크리스트 기반 QA

- 각 기능별 기획 의도 vs 실제 구현 내용 비교 가능하도록 UI QA 기준 정리
- 기능 QA & 디자인 QA 일정도 반영 필요
- Tip : Figma  dev mode 이용 시 개발자와의 효율적 커뮤니케이션 가능 (유료) 

4. 적용 시사점

• 당신의 조직이 기획자 주도 조직이라면?

  → 기획자가 기능 명세 및 IA 구조, 플로우 구성, UX 디자이너에게 피드백 우선권과 리디자인 권한을 부여해야 함

• 당신의 조직이 디자이너 중심 조직이라면?

  → IA는 디자이너가 가져가고, 기획자는 비즈니스 로직과 기능 명세에 집중해야 함 raci 프레임워크