웹 디자인 #23
웹 디자인 #23웹 UI에서 피드백이 중요한 이유
사용자가 웹사이트에서 버튼을 눌렀는데 아무런 반응이 나타나지 않는다면 어떤 생각이 들까요?
버튼이 정상적으로 눌린 것인지, 오류가 발생한 것인지, 다시 눌러야 하는지 판단하기 어렵습니다. 사용자는 같은 버튼을 여러 번 누르거나 작업을 중단할 수도 있습니다.
이처럼 피드백이 없는 UI는 사용자를 불안하게 만들고 서비스에 대한 신뢰를 떨어뜨립니다.
웹 인터페이스에서는 사용자의 행동과 시스템의 상태를 시각적으로 알려줘야 합니다.
예를 들면 다음과 같습니다.
- 저장 버튼을 누른 뒤 저장이 완료되었다고 알려줍니다.
- 파일을 업로드하는 동안 현재 진행률을 보여줍니다.
- 삭제처럼 되돌리기 어려운 행동을 한 번 더 확인합니다.
- 데이터를 불러오는 동안 로딩 상태를 표시합니다.
- 익숙하지 않은 아이콘의 의미를 짧게 설명합니다.
- 현재 확인해야 할 알림이 있다는 사실을 배지로 알려줍니다.
이러한 역할을 담당하는 대표적인 UI 컴포넌트에는 얼럿, 토스트, 배지, 로딩, 프로그레스 바, 툴팁, 팝오버, 모달이 있습니다.
각 컴포넌트는 모두 정보를 전달하지만 사용자의 흐름을 방해하는 정도와 요구하는 행동이 다릅니다.
따라서 메시지를 보여줘야 한다고 해서 모든 상황에 모달이나 얼럿을 사용하는 것은 적절하지 않습니다. 메시지의 중요도와 사용자가 반드시 행동해야 하는지에 따라 적절한 컴포넌트를 선택해야 합니다.
피드백 컴포넌트는 방해 강도가 다르다
피드백 UI는 사용자의 흐름을 얼마나 강하게 끊는지에 따라 구분할 수 있습니다.
배지는 화면에 조용히 표시되며 사용자가 즉시 반응하지 않아도 됩니다. 토스트는 잠시 나타났다가 사라지며 현재 작업을 막지 않습니다.
툴팁과 팝오버는 사용자가 특정 요소를 선택하거나 마우스를 올렸을 때 보조 정보를 제공합니다.
반면 얼럿과 모달은 사용자의 주의를 강하게 요구합니다. 모달이 열리면 일반적으로 뒤에 있는 화면과 상호작용할 수 없으며, 사용자는 모달을 처리하거나 닫아야 기존 작업으로 돌아갈 수 있습니다.
간단하게 정리하면 다음과 같습니다.
| 컴포넌트 | 주요 목적 | 사용자 흐름 방해 정도 |
|---|---|---|
| 배지 | 상태와 변화가 있음을 표시 | 매우 낮음 |
| 토스트 | 행동 결과를 가볍게 전달 | 낮음 |
| 로딩 | 처리 중인 상태 전달 | 상황에 따라 다름 |
| 프로그레스 바 | 작업 진행 정도 전달 | 낮음 |
| 툴팁 | 짧은 보조 설명 제공 | 낮음 |
| 팝오버 | 조금 더 자세한 보조 정보 제공 | 중간 |
| 얼럿 | 주의와 결정을 요구 | 높음 |
| 모달 | 특정 정보와 행동에 집중시킴 | 높음 |
피드백 컴포넌트를 선택할 때는 메시지가 얼마나 중요한지뿐 아니라 사용자의 현재 작업을 중단시킬 필요가 있는지 함께 판단해야 합니다.
얼럿이란?
얼럿은 사용자의 주의가 필요하거나 특정한 결정을 요구하는 메시지입니다.
사용자가 메시지를 확인하고 선택해야 하므로 모달 형태로 표시되는 경우가 많습니다.
대표적인 사용 상황은 다음과 같습니다.
- 계정 삭제
- 프로젝트 삭제
- 저장하지 않은 상태로 페이지 나가기
- 중요한 설정 변경
- 결제 또는 플랜 업데이트
- 되돌리기 어려운 작업 확인
얼럿은 사용자의 흐름을 강하게 멈추는 컴포넌트입니다. 따라서 단순한 성공 메시지나 가벼운 안내에 사용하기보다 반드시 확인이 필요한 상황에 사용해야 합니다.
되돌릴 수 없는 행동에는 확인이 필요하다
계정이나 프로젝트를 삭제하는 것처럼 되돌릴 수 없는 행동은 사용자의 실수로 발생했을 때 피해가 클 수 있습니다.
이러한 상황에서는 작업을 즉시 실행하기보다 얼럿을 통해 한 번 더 확인해야 합니다.
삭제 확인 얼럿에는 일반적으로 다음 요소가 들어갑니다.
- 어떤 항목이 삭제되는지 알려주는 제목
- 삭제 후 되돌릴 수 없다는 설명
- 작업을 취소하는 버튼
- 삭제를 확정하는 버튼
삭제 버튼은 위험한 행동이라는 사실을 알아볼 수 있도록 디스트럭티브 스타일로 표현할 수 있습니다.
일반적으로 빨간색 계열을 사용해 다른 행동과 구분하며 삭제, 계정 삭제, 영구 삭제처럼 결과를 명확하게 표현합니다.
단순히 확인이라고 작성하면 어떤 행동이 실행되는지 모호할 수 있습니다.
저장되지 않은 작업을 보호하는 얼럿
사용자가 글이나 프로젝트를 편집하던 중 저장하지 않고 페이지를 벗어나려고 할 때도 얼럿을 사용할 수 있습니다.
이때 중요한 것은 두 행동의 우선순위를 명확하게 표현하는 것입니다.
예를 들면 다음과 같습니다.
- 계속 편집하기
- 저장하지 않고 나가기
사용자의 작업이 사라지는 것을 막는 것이 더 안전한 선택이라면 계속 편집하기를 상대적으로 강조할 수 있습니다.
두 버튼을 모두 같은 수준으로 표현하면 사용자가 실수로 작업을 잃을 수 있습니다.
얼럿에서는 단순히 선택지를 나열하는 것이 아니라 어떤 행동이 더 안전하고 권장되는지 시각적으로 알려주는 것이 중요합니다.
상황에 따라 강조해야 할 버튼이 달라진다
얼럿의 버튼 우선순위는 항상 취소 버튼이 강조되거나 항상 확인 버튼이 강조되는 방식으로 정해지는 것은 아닙니다.
현재 얼럿의 목적에 따라 달라집니다.
삭제처럼 위험한 행동에서는 실수를 막는 방향을 우선할 수 있습니다. 반면 사용자의 플랜을 업데이트하거나 결제를 진행하는 흐름에서는 결제를 완료하는 버튼을 주요 CTA로 강조할 수 있습니다.
따라서 얼럿을 설계할 때는 다음 질문을 확인해야 합니다.
- 사용자가 실수했을 때 피해가 큰 행동은 무엇인가?
- 서비스가 권장하는 안전한 행동은 무엇인가?
- 현재 흐름에서 사용자가 달성하려는 목표는 무엇인가?
- 버튼을 눌렀을 때 어떤 결과가 발생하는가?
- 행동을 되돌릴 수 있는가?
버튼 스타일은 단순히 보기 좋게 나누는 장식이 아니라 사용자의 선택을 안내하는 역할을 합니다.
얼럿을 설계할 때 주의할 점
얼럿은 반드시 확인이 필요한 상황에만 사용하는 것이 좋습니다.
사소한 메시지마다 얼럿을 띄우면 사용자는 반복적으로 작업을 멈춰야 하며, 나중에는 내용을 제대로 읽지 않고 습관적으로 버튼을 누를 수 있습니다.
얼럿을 설계할 때는 다음 항목을 확인할 수 있습니다.
- 사용자가 반드시 확인해야 하는 메시지인가?
- 현재 작업을 멈출 만큼 중요한 상황인가?
- 제목만 읽어도 상황을 이해할 수 있는가?
- 행동의 결과가 구체적으로 설명되어 있는가?
- 버튼 문구가 행동의 결과를 명확히 표현하는가?
- 위험한 행동이 다른 버튼과 구분되는가?
- 더 안전한 선택이 무엇인지 이해할 수 있는가?
- 얼럿을 닫거나 취소할 수 있는가?
토스트란?
토스트는 사용자의 행동에 대한 가벼운 상태 피드백을 전달하는 메시지입니다.
화면의 흐름을 막지 않고 잠시 나타났다가 자동으로 사라지는 것이 특징입니다.
대표적으로 다음과 같은 상황에서 사용할 수 있습니다.
- 저장이 완료되었습니다.
- 삭제가 완료되었습니다.
- 링크가 복사되었습니다.
- 설정이 변경되었습니다.
- 작업 중 오류가 발생했습니다.
- 네트워크 연결 상태가 변경되었습니다.
토스트는 사용자가 반드시 선택해야 하는 메시지가 아닙니다. 사용자는 토스트가 표시되어도 현재 작업을 계속할 수 있습니다.
토스트가 표시되는 위치
데스크톱처럼 화면이 넓은 환경에서는 우측 상단에 토스트를 배치하는 경우가 많습니다.
모바일에서는 화면 상단이나 하단에 표시할 수 있습니다.
배치 위치를 정할 때는 현재 화면의 주요 콘텐츠와 입력 영역을 가리지 않는지 확인해야 합니다.
예를 들어 회원가입 폼을 작성하는 중이라면 토스트가 입력창이나 제출 버튼 위에 겹치지 않아야 합니다.
여러 개의 토스트가 연속으로 발생한다면 일정한 간격으로 쌓이게 만들거나, 이전 토스트를 정리한 뒤 새로운 토스트를 보여주는 규칙도 필요합니다.
토스트의 대표적인 유형
토스트는 전달하려는 메시지의 성격에 따라 여러 유형으로 나눌 수 있습니다.
성공 토스트
사용자의 행동이 정상적으로 완료되었음을 알려줍니다.
- 저장되었습니다.
- 파일이 업로드되었습니다.
- 설정이 변경되었습니다.
오류 토스트
작업이 실패했거나 문제가 발생했음을 알려줍니다.
- 저장하지 못했습니다.
- 네트워크 연결을 확인해 주세요.
- 파일 업로드에 실패했습니다.
정보 토스트
사용자에게 참고할 만한 상태나 변경 사항을 안내합니다.
- 새로운 버전이 업데이트되었습니다.
- 설정 변경 사항이 다음 로그인부터 적용됩니다.
액션이 포함된 토스트
메시지와 함께 간단한 행동을 제공할 수 있습니다.
예를 들어 항목을 삭제한 뒤 실행 취소 버튼을 함께 제공하는 방식입니다.
다만 토스트는 자동으로 사라지기 때문에 중요한 행동을 오직 토스트 안에서만 제공하면 사용자가 놓칠 수 있습니다.
토스트는 얼마나 오래 보여줘야 할까?
토스트가 너무 빨리 사라지면 사용자가 메시지를 읽기 전에 없어질 수 있습니다.
반대로 너무 오래 화면에 남아 있으면 콘텐츠를 가리고 답답한 느낌을 줄 수 있습니다.
영상에서는 일반적인 토스트의 표시 시간을 약 3초에서 5초 사이로 설명합니다.
다만 메시지의 길이와 포함된 행동에 따라 표시 시간을 조정해야 합니다.
짧은 성공 메시지는 비교적 빠르게 사라져도 되지만, 사용자가 내용을 읽거나 실행 취소 같은 행동을 선택해야 한다면 더 긴 시간이 필요할 수 있습니다.
사용자가 기다리지 않고 직접 닫을 수 있도록 닫기 버튼을 함께 제공할 수도 있습니다.
토스트를 남용하면 안 되는 이유
버튼을 누를 때마다 토스트가 나타나면 화면에 시각적인 소음이 발생합니다.
사용자가 이미 화면의 변화로 결과를 충분히 이해할 수 있다면 토스트를 추가하지 않아도 됩니다.
예를 들어 탭을 선택한 뒤 선택 상태가 명확하게 바뀌었다면 탭이 변경되었습니다라는 토스트는 필요하지 않습니다.
토스트는 다음과 같이 결과를 놓치기 쉬운 중요한 행동에 사용하는 것이 좋습니다.
- 저장 완료
- 삭제 완료
- 복사 완료
- 작업 실패
- 연결 상태 변경
배지란?
배지는 상태나 새로운 변화가 있다는 사실을 비교적 조용하게 알려주는 컴포넌트입니다.
얼럿처럼 사용자의 즉각적인 결정을 요구하지 않지만, 확인할 정보가 있다는 사실을 전달합니다.
대표적인 예시는 다음과 같습니다.
- 읽지 않은 알림 개수
- 새로운 메시지
- 새로운 기능
- 승인 완료
- 검토 필요
- 비활성화 상태
- 로그인 여부
- 상품 재고 상태
배지는 아이콘이나 메뉴, 텍스트 옆에 작은 형태로 배치됩니다.
배지의 색상에는 의미가 필요하다
배지는 작은 컴포넌트이기 때문에 색상을 통해 상태를 빠르게 전달하는 경우가 많습니다.
영상에서는 다음과 같은 색상 사용 예시를 설명합니다.
- 빨간색: 긴급한 상태, 오류, 읽지 않은 알림
- 파란색: 안내, 정보, 새로운 소식
- 노란색: 주의, 확인이 필요한 상태
- 초록색: 정상, 완료, 승인
- 회색: 비활성화, 비로그인, 보조 상태
색상은 디자인 시스템과 서비스의 규칙에 따라 달라질 수 있지만, 같은 서비스 안에서는 동일한 의미로 일관되게 사용해야 합니다.
한 화면에서 빨간색이 오류를 의미하다가 다른 화면에서는 새로운 기능을 뜻한다면 사용자가 상태를 오해할 수 있습니다.
또한 상태를 색상만으로 전달해서는 안 됩니다.
가능하다면 텍스트와 아이콘, 숫자 등을 함께 사용해 의미를 보완하는 것이 좋습니다.
배지를 너무 많이 사용하면 생기는 문제
모든 메뉴와 카드에 배지를 붙이면 무엇이 중요한지 구분하기 어려워집니다.
빨간 점과 숫자 배지가 화면 곳곳에 반복되면 사용자는 계속해서 확인해야 한다는 압박을 느낄 수도 있습니다.
따라서 배지는 실제로 사용자의 확인이 필요한 정보에만 사용해야 합니다.
배지를 설계할 때는 다음 질문을 확인할 수 있습니다.
- 사용자가 반드시 알아야 하는 상태인가?
- 배지를 확인한 뒤 수행할 행동이 있는가?
- 색상의 의미가 서비스 전체에서 일관적인가?
- 배지가 없어도 상태를 충분히 이해할 수 있는가?
- 한 화면에 배지가 지나치게 많이 표시되고 있지 않은가?
로딩 상태란?
로딩 상태는 사용자의 행동이나 데이터 처리가 즉시 완료되지 않을 때 현재 작업이 진행 중이라는 사실을 알려주는 피드백입니다.
아무런 로딩 표시가 없다면 사용자는 시스템이 멈췄거나 버튼이 작동하지 않았다고 생각할 수 있습니다.
대표적인 로딩 표현에는 다음과 같은 방식이 있습니다.
- 로딩 스피너
- 스켈레톤 UI
- 로티 애니메이션
- 버튼 내부 로딩
- 프로그레스 바
어떤 방식을 사용할지는 기다리는 시간과 콘텐츠의 형태, 작업 진행률을 알 수 있는지에 따라 달라집니다.
로딩 스피너
로딩 스피너는 원이나 점이 반복적으로 회전하는 형태로 현재 작업이 처리 중임을 보여줍니다.
대표적으로 다음과 같은 상황에서 사용할 수 있습니다.
- 데이터를 불러오는 중
- 서버에 요청을 보내는 중
- 로그인 처리 중
- 화면을 전환하는 중
- 짧은 작업을 처리하는 중
스피너는 현재 작업이 진행 중이라는 사실은 알려주지만 완료까지 얼마나 남았는지는 보여주지 않습니다.
따라서 비교적 짧거나 진행률을 정확히 계산하기 어려운 작업에 적합합니다.
스켈레톤 UI
스켈레톤 UI는 실제 콘텐츠가 표시될 자리를 회색 블록과 선 형태로 먼저 보여주는 로딩 방식입니다.
사용자는 콘텐츠가 불러와지기 전에도 화면에 어떤 정보가 나타날지 예상할 수 있습니다.
예를 들어 카드 목록을 불러온다면 다음 영역을 스켈레톤으로 표현할 수 있습니다.
- 이미지 영역
- 제목 영역
- 짧은 설명 영역
- 버튼이나 메타 정보 영역
스켈레톤 UI는 콘텐츠 구조가 정해져 있고 여러 정보가 로딩되는 화면에 활용할 수 있습니다.
실제 콘텐츠와 스켈레톤의 구조가 크게 다르면 콘텐츠가 나타나는 순간 화면이 흔들리거나 갑작스럽게 변할 수 있습니다. 따라서 최종 콘텐츠의 크기와 형태를 어느 정도 반영하는 것이 좋습니다.
로티 애니메이션을 활용한 로딩
브랜드의 특성과 서비스 분위기를 표현하기 위해 로티 애니메이션을 로딩 화면에 사용할 수도 있습니다.
단순한 스피너보다 개성 있는 경험을 제공할 수 있지만, 로딩의 목적은 사용자가 현재 상태를 이해하도록 만드는 것입니다.
애니메이션이 지나치게 복잡하거나 무거우면 오히려 로딩 성능에 부담을 줄 수 있으므로 장식적인 표현보다 전달력과 성능을 먼저 고려해야 합니다.
버튼 내부의 로딩 상태
전체 화면에 큰 로딩을 표시하지 않고 사용자가 누른 버튼 안에서만 로딩 상태를 보여줄 수도 있습니다.
예를 들어 저장하기 버튼을 누른 뒤 버튼 안의 텍스트를 스피너로 변경하는 방식입니다.
버튼 내부 로딩은 어떤 행동이 처리되고 있는지 사용자가 바로 연결해서 이해할 수 있다는 장점이 있습니다.
로딩 중에는 같은 버튼이 여러 번 클릭되지 않도록 해야 합니다.
중복 클릭을 허용하면 동일한 요청이 반복되어 게시물이 여러 번 등록되거나 결제가 중복으로 처리되는 문제가 생길 수 있습니다.
프로그레스 바란?
프로그레스 바는 일정한 단계나 진행률을 가진 작업이 현재 어느 정도까지 완료되었는지 보여주는 컴포넌트입니다.
스피너가 단순히 처리 중이라는 사실만 전달한다면, 프로그레스 바는 완료까지 얼마나 남았는지를 보여줍니다.
대표적인 사용 상황은 다음과 같습니다.
- 파일 업로드
- 파일 다운로드
- 설문 작성
- 회원가입 단계
- 결제 과정
- 온보딩 과정
- 여러 단계의 프로젝트 생성
진행률을 수치로 계산할 수 있다면 막대와 함께 백분율을 표시할 수 있습니다.
65% 업로드됨
진행률을 정확히 계산하기 어렵더라도 전체 단계 중 현재 몇 번째 단계인지 보여줄 수 있습니다.
총 4단계 중 2단계
진행 상황을 알려주면 기다림을 견디기 쉬워진다
사용자가 작업이 얼마나 걸릴지 전혀 알 수 없으면 실제 대기 시간이 짧더라도 더 길게 느낄 수 있습니다.
반면 시간이 조금 더 걸리더라도 현재 진행 상태와 남은 단계를 확인할 수 있다면 기다릴 이유를 이해할 수 있습니다.
프로그레스 바를 설계할 때는 다음 내용을 보여줄 수 있습니다.
- 현재 진행률
- 완료된 단계
- 현재 진행 중인 단계
- 남아 있는 단계
- 예상 소요 시간
- 작업을 취소할 수 있는지 여부
진행률을 실제 처리 상태와 다르게 표시하면 사용자의 신뢰를 떨어뜨릴 수 있습니다. 단순히 애니메이션을 빠르게 움직이는 것보다 실제 작업과 연결된 상태를 보여주는 것이 중요합니다.
툴팁이란?
툴팁은 아이콘이나 버튼의 의미를 보완하는 짧은 설명 컴포넌트입니다.
주로 사용자가 요소 위에 마우스를 올렸을 때 작은 말풍선 형태로 나타납니다.
대표적인 사용 예시는 다음과 같습니다.
- 아이콘 버튼의 기능 설명
- 생소한 용어의 간단한 의미
- 비활성화된 기능의 이유
- 데이터 그래프의 짧은 수치 정보
- 입력 조건에 대한 짧은 안내
툴팁은 메인 콘텐츠가 아니라 보조 설명입니다. 따라서 가능한 한 짧고 명확하게 작성해야 합니다.
툴팁은 짧게 작성한다
툴팁 안에 긴 문단을 넣으면 작은 영역에서 읽기 어렵고 사용자의 흐름을 방해할 수 있습니다.
영상에서는 툴팁을 가능하면 한 줄 이내의 짧은 문장으로 제공하는 것이 좋다고 설명합니다.
예를 들면 다음과 같습니다.
- 링크 복사
- 프로젝트 삭제
- 전체 화면으로 보기
- 알림 설정
- 최근 업데이트 날짜
더 많은 설명이 필요하다면 툴팁보다 팝오버나 별도의 도움말 영역이 적합할 수 있습니다.
툴팁이 없어도 사용할 수 있어야 한다
툴팁은 이해를 보조하는 역할입니다.
사용자가 기능을 사용하기 위해 반드시 툴팁을 열어봐야 한다면 기본 UI가 충분히 직관적이지 않은 것일 수 있습니다.
특히 중요한 버튼이나 필수 기능을 아이콘만으로 표현한 뒤 모든 의미를 툴팁에 의존하는 방식은 주의해야 합니다.
가능하다면 텍스트 라벨과 익숙한 아이콘, 명확한 위치를 활용하고 툴팁은 추가 설명으로 사용하는 것이 좋습니다.
모바일에는 호버가 없다
데스크톱에서는 마우스를 올리는 호버 동작을 이용해 툴팁을 보여줄 수 있습니다.
하지만 모바일에서는 마우스 포인터가 없기 때문에 동일한 호버 방식에 의존할 수 없습니다.
모바일에서는 다음과 같은 방식을 고려할 수 있습니다.
- 아이콘을 탭하면 툴팁을 표시합니다.
- 다시 탭하거나 바깥 영역을 누르면 닫습니다.
- 중요 설명은 툴팁 대신 화면에 직접 표시합니다.
- 별도의 정보 버튼을 제공합니다.
툴팁을 설계할 때는 데스크톱의 마우스 오버뿐 아니라 키보드 포커스와 모바일 터치 방식도 함께 고려해야 합니다.
팝오버란?
팝오버는 특정 요소를 클릭했을 때 열리는 보조 정보 창입니다.
툴팁보다 더 많은 정보를 담을 수 있으며, 설명뿐 아니라 버튼과 링크 같은 간단한 행동을 포함할 수도 있습니다.
대표적인 사용 예시는 다음과 같습니다.
- 사용자 프로필 요약
- 일정 미리보기
- 알림 상세 정보
- 필터 설정
- 도움말과 추가 설명
- 간단한 설정 변경
팝오버는 현재 페이지를 떠나지 않고 관련 정보를 빠르게 확인하거나 작은 행동을 수행할 수 있도록 돕습니다.
툴팁과 팝오버의 차이
| 구분 | 툴팁 | 팝오버 |
| 주요 목적 | 짧은 설명 | 추가 정보와 간단한 행동 |
| 열리는 방식 | 주로 호버 또는 포커스 | 주로 클릭 또는 탭 |
| 정보량 | 한 줄 정도의 짧은 내용 | 여러 줄의 정보와 버튼 가능 |
| 상호작용 | 일반적으로 단순 확인 | 내부 요소와 상호작용 가능 |
| 닫기 방식 | 포인터가 벗어나면 닫힘 | 닫기 버튼이나 바깥 클릭 |
팝오버에 너무 많은 입력 요소와 복잡한 기능을 넣으면 작은 페이지처럼 복잡해질 수 있습니다.
내용이 많거나 작업 단계가 복잡하다면 팝오버보다 모달이나 별도 페이지가 더 적합할 수 있습니다.
팝오버를 닫는 방법
팝오버는 툴팁보다 크고 사용자가 직접 열기 때문에 닫는 방법도 명확하게 제공해야 합니다.
대표적인 닫기 방식은 다음과 같습니다.
- 닫기 버튼 선택
- 팝오버를 열었던 버튼 다시 선택
- 팝오버 바깥 영역 선택
- 키보드 ESC 키 사용
팝오버가 열린 상태에서 화면의 다른 작업을 수행하기 어렵다면 사용자는 쉽게 닫을 수 있어야 합니다.
모달이란?
모달은 현재 화면 위에 표시되어 특정 정보와 행동에 사용자의 주의를 집중시키는 컴포넌트입니다.
모달이 열리면 일반적으로 뒤에 있는 페이지와는 상호작용할 수 없습니다.
배경에는 어두운 오버레이나 블러 효과를 적용해 현재 모달이 활성화되어 있다는 사실을 전달합니다.
모달은 다음과 같은 상황에서 사용할 수 있습니다.
- 중요한 정보 확인
- 삭제와 같은 행동 확인
- 로그인과 회원가입
- 간단한 프로젝트 생성
- 짧은 폼 작성
- 이미지와 콘텐츠 상세 보기
- 특정 설정 변경
얼럿도 모달 형태를 사용하는 경우가 많지만, 모든 모달이 얼럿은 아닙니다.
얼럿은 주의와 결정을 요구하는 메시지이며, 모달은 더 넓은 범위의 콘텐츠와 행동을 담을 수 있는 화면 구조입니다.
모달을 사용하는 것이 적합한 상황
모달은 페이지를 완전히 이동할 필요는 없지만 현재 행동에 집중해야 할 때 유용합니다.
예를 들어 새 프로젝트를 생성할 때 다음 정도의 정보만 필요하다고 가정해 보겠습니다.
- 프로젝트 이름
- 카테고리
- 짧은 설명
- 생성 버튼
이 정도의 간단한 작업이라면 별도의 페이지로 이동하지 않고 모달 안에서 처리할 수 있습니다.
사용자는 기존 페이지의 맥락을 유지한 상태에서 작업을 완료하고 바로 돌아올 수 있습니다.
별도 페이지가 더 적합한 상황
모달 안에 지나치게 많은 정보와 기능을 넣으면 작은 화면 안에서 복잡한 작업을 수행해야 합니다.
다음과 같은 경우에는 별도 페이지를 검토하는 것이 좋습니다.
- 입력해야 할 필드가 매우 많습니다.
- 여러 단계로 작업을 진행해야 합니다.
- 긴 설명과 참고 자료가 필요합니다.
- 데이터 테이블과 복잡한 설정이 포함됩니다.
- 작업 중 다른 정보를 함께 확인해야 합니다.
- 모바일에서 모달 내부가 지나치게 길어집니다.
모달은 페이지 이동을 줄이는 데 도움이 되지만 모든 작업을 모달에 넣는 것이 좋은 것은 아닙니다.
모달의 기본 구성
모달에는 일반적으로 다음 요소가 포함됩니다.
- 제목
- 설명
- 본문 콘텐츠
- 입력 요소
- 주요 행동 버튼
- 취소 또는 닫기 버튼
- 배경 오버레이
사용자는 모달이 왜 열렸고 무엇을 해야 하는지 바로 이해할 수 있어야 합니다.
제목과 버튼 문구는 모달의 목적을 명확하게 표현해야 합니다.
모달을 닫는 방법
사용자가 모달 안의 행동을 완료하지 않더라도 기존 화면으로 돌아갈 수 있는 방법을 제공하는 것이 좋습니다.
대표적인 방법은 다음과 같습니다.
- 우측 상단 닫기 버튼
- 취소 버튼
- 배경 오버레이 선택
- 키보드 ESC 키
다만 삭제 확인처럼 실수로 닫히면 안 되는 중요한 상황에서는 오버레이 선택으로 닫히는 동작을 제한할 수도 있습니다.
모달의 목적과 입력 중인 데이터의 중요도에 따라 닫기 규칙을 정해야 합니다.
작성 중인 폼을 닫을 때 데이터가 사라진다면 바로 닫기보다 한 번 더 확인하는 흐름이 필요할 수 있습니다.
모달과 팝오버의 차이
| 구분 | 팝오버 | 모달 |
| 표시 위치 | 선택한 요소 주변 | 화면 중앙 또는 전체 영역 |
| 배경 상호작용 | 가능한 경우가 많음 | 일반적으로 제한됨 |
| 정보량 | 비교적 적음 | 더 많은 콘텐츠와 입력 가능 |
| 주요 목적 | 보조 정보와 간단한 행동 | 특정 작업에 집중 |
| 오버레이 | 보통 사용하지 않음 | 일반적으로 사용 |
| 흐름 방해 정도 | 중간 | 높음 |
사용자의 주의를 강하게 집중시킬 필요가 없다면 모달보다 팝오버가 더 가벼운 선택이 될 수 있습니다.
상황에 맞는 피드백 컴포넌트 선택하기
메시지를 보여줄 때는 먼저 사용자가 반드시 확인하거나 행동해야 하는지 판단해야 합니다.
반드시 결정을 내려야 한다면
얼럿이나 모달을 사용할 수 있습니다.
- 계정 삭제
- 저장하지 않고 나가기
- 중요한 설정 변경
- 결제 확인
결과를 가볍게 알려주면 된다면
토스트가 적합할 수 있습니다.
- 저장 완료
- 복사 완료
- 삭제 완료
- 간단한 오류 안내
새로운 상태가 있음을 지속적으로 보여줘야 한다면
배지를 사용할 수 있습니다.
- 읽지 않은 알림
- 새로운 메시지
- 승인 상태
- 검토 필요
작업이 진행 중임을 알려줘야 한다면
로딩 스피너나 스켈레톤 UI를 사용할 수 있습니다.
완료까지 얼마나 남았는지 알려줘야 한다면
프로그레스 바가 적합합니다.
짧은 설명이 필요하다면
툴팁을 사용할 수 있습니다.
조금 더 많은 정보나 간단한 행동이 필요하다면
팝오버를 사용할 수 있습니다.
현재 페이지에서 특정 작업에 집중해야 한다면
모달을 사용할 수 있습니다.
피드백 UI에서 자주 발생하는 실수
모든 메시지를 모달로 보여준다
모달은 사용자의 현재 작업을 중단시킵니다.
저장 완료와 같은 가벼운 메시지까지 모달로 보여주면 사용자는 매번 닫기 버튼을 눌러야 합니다.
반드시 확인해야 하는 상황이 아니라면 토스트나 화면 내부의 상태 표현을 검토하는 것이 좋습니다.
중요한 내용을 토스트로만 보여준다
토스트는 잠시 나타났다가 사라집니다.
사용자가 반드시 읽어야 하는 정책 변경이나 되돌릴 수 없는 작업을 토스트로만 전달하면 내용을 놓칠 수 있습니다.
중요한 정보는 지속적으로 확인할 수 있는 화면이나 얼럿, 모달을 사용해야 합니다.
토스트 표시 시간이 너무 짧다
메시지를 읽기 전에 토스트가 사라지면 피드백의 의미가 없어집니다.
내용의 길이와 포함된 행동을 고려해 충분한 표시 시간을 제공해야 합니다.
토스트가 입력 영역을 가린다
토스트의 위치만 일관되게 유지하려다 현재 사용 중인 버튼이나 입력창을 가릴 수 있습니다.
데스크톱과 모바일의 화면 구조를 각각 확인해 주요 인터페이스와 겹치지 않도록 해야 합니다.
배지를 너무 많이 사용한다
모든 메뉴에 빨간색 배지가 표시되면 실제로 중요한 알림이 무엇인지 구분할 수 없습니다.
배지는 확인이 필요한 정보에만 제한적으로 사용해야 합니다.
로딩 중 중복 클릭을 허용한다
처리 중인 버튼을 계속 누를 수 있으면 같은 요청이 여러 번 전송될 수 있습니다.
로딩이 시작되면 버튼을 비활성화하거나 중복 요청을 막아야 합니다.
로딩만 보여주고 진행 상황을 숨긴다
파일 업로드처럼 시간이 걸리고 진행률을 계산할 수 있는 작업에서는 스피너만 보여주는 것보다 프로그레스 바가 더 적합합니다.
사용자가 언제 작업이 끝날지 판단할 수 있도록 현재 진행률을 알려줘야 합니다.
툴팁에 긴 내용을 넣는다
툴팁은 짧은 보조 설명을 위한 컴포넌트입니다.
설명이 여러 문단으로 길어진다면 팝오버나 별도의 도움말 영역을 사용하는 것이 좋습니다.
호버에만 의존한다
모바일에는 호버 동작이 없으며 키보드 사용자도 마우스를 사용하지 않을 수 있습니다.
툴팁과 보조 설명은 포커스와 터치에서도 사용할 수 있도록 설계해야 합니다.
모달 안에 지나치게 많은 내용을 넣는다
복잡한 설정과 긴 폼을 작은 모달 안에 넣으면 사용하기 어려워집니다.
작업이 복잡하다면 별도의 페이지나 단계형 화면을 사용하는 편이 좋습니다.
모달을 닫을 방법이 명확하지 않다
사용자가 작업을 취소하고 돌아갈 수 없다면 인터페이스에 갇힌 느낌을 받을 수 있습니다.
닫기 버튼과 취소, ESC 키 등 상황에 적합한 종료 방법을 제공해야 합니다.
