좋은 버튼 UI는 세 가지를 분명하게 전달합니다. 누르면 어떤 일이 일어나는지, 지금 가장 중요한 행동은 무엇인지, 현재 실행할 수 있는지입니다. 먼저 행동과 버튼 문구를 정하고, 중요도에 맞게 강조한 다음, 포인터나 키보드로 편하게 조작할 수 있는 영역을 설계하세요. 실제로는 주문이 확정되는데 버튼에 ‘계속’이라고 적혀 있다면, 색을 선명하게 만드는 것만으로는 해결되지 않습니다.
주문서에 ‘주문하기’, ‘장바구니 저장’, ‘배송지 수정’이라는 세 가지 행동이 있다고 생각해 봅시다. 세 버튼이 모두 같은 강도로 시선을 끌 필요는 없습니다. Pixso의 UI 디자인 작업 공간에서 재사용할 수 있는 컴포넌트로 만들고, 버튼만 모아 놓은 화면이 아니라 실제 주문서 안에서 비교해 보세요.

색보다 먼저 행동의 우선순위를 정하세요
시각적 위계는 제품팀이 홍보하고 싶은 기능의 수가 아니라 사용자가 지금 하려는 일을 따라야 합니다. 주문 내용을 최종 확인하는 단계에서 ‘주문하기’는 구매를 완료합니다. ‘장바구니 저장’은 나중에 구매하려는 의도를 보존하고, ‘배송지 수정’은 주문 정보의 일부만 바꿉니다. 각 행동의 역할을 구분하세요.
| 주문서의 행동 | 표현 방식 | 이유 |
|---|---|---|
| 주문하기 | 결제 금액 가까이에 두는, 배경색이 채워진 주요 버튼 | 고객이 내용을 확인한 뒤 현재 작업을 완료하는 행동입니다. |
| 장바구니 저장 | 테두리형 또는 강조를 낮춘 보조 버튼 | 유효한 대안이지만 반드시 거쳐야 하는 다음 단계처럼 보여서는 안 됩니다. |
| 배송지 수정 | 배송 정보 영역 안에 두는 간결한 텍스트형 컨트롤 | 영향 범위가 해당 정보에 한정되므로 바꾸는 내용 가까이에 있어야 합니다. |
‘주요 버튼은 하나’라는 원칙은 한 의사결정 영역 안에서 유용합니다. 긴 페이지 전체에 강조된 행동을 두 개 이상 둘 수 없다는 뜻은 아닙니다. 상품 페이지에는 구매 영역과 별도의 설정 작업이 함께 있을 수 있습니다. 중요한 것은 사용자가 선택해야 하는 순간에 두 행동이 서로 경쟁하는지입니다.
데이터를 삭제하는 행동은 또 다릅니다. ‘배송지 삭제’가 중요하다는 이유만으로 주요 구매 버튼과 같은 브랜드 색을 적용해서는 안 됩니다. 결과를 설명하고, 제품에서 정한 삭제·파괴적 행동의 표현을 사용하며, 안전하게 돌아갈 방법을 제공하세요. 부정적으로 들리는 모든 행동을 빨간색으로 만들 필요는 없습니다. ‘수정 취소’는 보통 안전하게 빠져나오는 행동입니다.
결과를 예상할 수 있는 문구를 쓰세요
결과가 모호할 수 있다면 행동과 대상을 함께 적으세요. ‘배송지 저장’은 무엇이 바뀌는지 알려 줍니다. ‘완료’는 저장인지, 창 닫기인지, 저장하지 않고 나가기인지 불분명할 수 있습니다. ‘주문하기’는 주문을 확정한다는 뜻을 전달합니다. ‘계속’은 실제로 다음 단계가 있을 때 적절합니다.
보조 버튼도 정확해야 합니다. ‘장바구니 저장’은 실제로 장바구니가 보관될 때 쓸 수 있습니다. 상품 목록으로 돌아가는 기능이라면 ‘쇼핑 계속하기’가 맞습니다. 안심할 만한 문구를 붙여도 실제 동작이 다르면 혼란은 남습니다.
링크와 버튼은 동작으로 구분하세요. 주문 내역 페이지로 이동하는 것은 탐색이므로, 시각적으로 강조하더라도 링크에 해당합니다. 주문을 제출하거나 배송지 편집 창을 여는 것은 행동입니다. WAI-ARIA 버튼 패턴은 이 역할을 구분하고 키보드 동작을 설명합니다.
아이콘은 의미를 더하거나 빠르게 알아보는 데 도움이 될 때 사용하세요. 작은 화살표는 다음 단계로의 이동을 보조할 수 있지만, 모호한 ‘이동’ 문구를 대신 설명하지는 못합니다. 아이콘만 있는 편집 컨트롤에는 ‘배송지 수정’처럼 의미 있는 접근성 이름을 지정하고, 마우스를 올리지 않아도 용도를 이해할 수 있게 하세요.
보이는 사각형뿐 아니라 조작 영역을 설계하세요
버튼에는 눈에 보이는 형태와 실제로 누를 수 있는 영역이 있습니다. 디자이너는 둘 다 지정해야 합니다. 작은 연필 아이콘을 더 큰 조작 영역 안에 둘 수 있지만, 그 영역이 옆의 ‘배송지 삭제’와 겹쳐서는 안 됩니다. 보이지 않는 여백도 어느 부분을 누르면 반응하는지 예측할 수 있을 때 도움이 됩니다.
WCAG 2.2의 최소 타깃 크기 기준은 포인터 조작 대상에 24 × 24 CSS 픽셀을 사용하며, 간격이나 문장 안의 텍스트 등에 대한 예외를 정의합니다. 이는 최소 기준이지, 주문서의 주요 버튼을 그만큼 작게 만들라는 권고가 아닙니다. 중요한 터치 동작에는 더 크고 편안한 영역을 선택하고 주변 컨트롤과 함께 평가하세요.
이 예에서는 주요 버튼의 높이를 48픽셀로 시작하고, 읽기 쉬운 글자와 충분한 좌우 여백을 넣어 봅니다. 48픽셀은 설계를 시작하기 위한 선택이지 모든 상황에 적용되는 접근성 의무 기준은 아닙니다. 배송지 수정 컨트롤은 더 간결하게 표현하더라도 실제 조작 영역은 충분히 확보할 수 있습니다.
관련된 행동은 모아 두되, 잘못 누르지 않도록 적절한 간격을 두세요. ‘주문하기’와 ‘장바구니 저장’이 똑같이 강조되어 있다면 간격만 넓혀서는 위계 문제가 해결되지 않습니다. 먼저 강조 수준을 조정하고 간격을 정하세요.
버튼 너비는 내용과 레이아웃에 맞추세요
데스크톱 주문서에서는 내용에 맞춘 너비의 버튼을 주문 요약 아래에 배치할 수 있습니다. 좁은 화면에서는 가로 전체를 사용하는 주요 버튼이 더 쉽게 눈에 띄고 닿기 쉬울 수 있습니다. 그렇다고 짧은 문구를 거대한 빈 배너처럼 만들거나, 긴 번역 문구를 잘라서는 안 됩니다.
문구, 선택적 아이콘, 안쪽 여백, 최소 높이를 기준으로 버튼을 구성하세요. 영어 문구의 길이만 보고 모든 버튼의 너비를 고정하지 마세요. ‘주문하기’, ‘장바구니 저장’과 더 긴 다른 언어의 문구를 같은 컴포넌트에 넣어 봅니다. 공간이 부족하면 글자를 억지로 줄이기보다 보조 행동을 주요 행동 아래로 옮기는 편이 낫습니다.
유난히 긴 문구를 어떻게 처리할지도 정해야 합니다. 먼저 의미를 유지하면서 불필요한 표현을 줄이고, 그래도 길다면 컨테이너가 늘어나거나 행동 그룹이 세로로 쌓이게 하세요. 컴포넌트가 이를 고려해 설계되었다면 두 줄 문구도 사용할 수 있습니다. 하지만 높이가 고정된 알약 모양 버튼 안에서 우연히 줄이 바뀌는 것은 다른 문제입니다.
화면의 배치 순서와 키보드 이동 순서 모두 논리적이어야 합니다. 데스크톱에서 다른 위치에 있었다는 이유로 모바일에서는 덜 중요한 행동에 먼저 포커스가 가서는 안 됩니다. 하단 고정 주문 영역을 사용한다면 마지막 콘텐츠와 포커스된 컨트롤이 가려지지 않을 공간을 남겨야 합니다.
인터랙션 상태마다 서로 다른 역할을 주세요
호버, 포커스, 누름, 로딩은 단순히 색을 다르게 칠한 상태가 아닙니다. 각각 다른 질문에 답합니다. 주문서에서는 어떤 행동인지, 키보드로 어느 컨트롤을 조작할지, 입력이 받아들여졌는지, 주문이 아직 처리 중인지를 구분할 수 있어야 합니다.
- 기본: 조작하기 전부터 행동과 중요도를 보여 줍니다.
- 호버: 포인터에 반응하되, 터치 사용자도 알아야 할 정보를 호버에만 숨기지 않습니다.
- 키보드 포커스: 현재 조작할 컨트롤을 눈에 띄게 표시합니다. 호버와 동시에 나타날 수 있으므로 둘 중 하나만 존재한다고 가정하지 마세요.
- 누름: 실행 입력에 대한 짧은 반응을 제공합니다. 구매 성공을 뜻하지는 않습니다.
- 로딩: ‘주문 처리 중…’처럼 진행 중인 작업을 알리고 의도치 않은 중복 제출을 방지합니다.
- 사용 불가: 지금 실행할 수 없다는 것을 나타냅니다. 이유가 불분명하다면 가까운 곳에 설명을 둡니다.
문구가 ‘주문 처리 중…’으로 바뀌거나 진행 표시가 나타나도 버튼 너비가 유지되도록 하세요. 그렇지 않으면 포인터 아래의 조작 대상이 움직이거나 옆의 행동이 밀릴 수 있습니다. 설명 없이 돌아가는 표시만 보여 주는 것보다 처리 중인 행동을 문구로 알려 주는 편이 이해하기 쉬울 수 있습니다.
클릭하자마자 버튼을 성공 체크 표시로 바꾸지 마세요. 주문 완료는 결과가 확인된 뒤에 보여 주어야 합니다. 결제 시스템에서 결과를 확정할 수 없다면, 페이지는 상황을 설명하고 적절한 다음 행동을 안내해야 합니다. 곧바로 두 번째 결제를 유도해서는 안 됩니다. 이는 시각적 상태를 하나 추가하는 것만으로 정할 수 없으며 개발팀과 동작을 합의해야 합니다.
폼의 비활성 버튼도 주의해야 합니다. 무엇이 빠졌는지 설명하지 않고 ‘주문하기’를 회색으로 만들면 고객이 원인을 찾아 헤매게 됩니다. 합리적인 경우에는 제출 행동을 실행할 수 있게 두고 미완성 항목을 알려 줄 수 있습니다. 반드시 사용할 수 없는 상태여야 한다면, 배송 방법을 선택하지 않았다는 안내처럼 이유를 가까이에 보여 주세요.
강조하면서도 읽기 쉬워야 합니다
테두리에는 잘 어울리는 브랜드 색이 흰 글자의 배경으로는 적절하지 않을 수 있습니다. 호버와 포커스를 포함해 각 상태의 실제 전경색과 배경색 조합을 확인하세요. 일반 크기의 버튼 글자에는 WCAG의 텍스트 대비 기준에 따라 최소 4.5:1의 대비가 요구됩니다. 큰 글자와 비활성 컨트롤에는 별도 규정이 있지만, 그 예외를 보조 행동의 가독성을 낮추는 근거로 삼아서는 안 됩니다.
키보드를 쓰는 사람에게는 보이는 포커스 표시가 필요합니다. WCAG의 포커스 표시 기준은 키보드로 조작할 수 있는 인터페이스에서 포커스를 시각적으로 식별할 수 있도록 요구합니다. 개발자가 호버 색을 보고 추측하게 두지 말고 디자인 파일에 표현하세요.
‘배송지 수정’으로 편집 창을 열 때 포커스가 어디로 이동하고, 닫은 뒤 어디로 돌아오는지 기록하세요. ‘주문하기’에는 입력 오류가 났을 때와 주문이 확정됐을 때의 동작을 지정합니다. 보기에는 맞는 버튼이라도 포커스를 예상하지 못한 곳으로 보내면 작업 흐름을 끊습니다.
Pixso에서 필요한 버튼 세트를 만드세요
실제 주문서의 세 가지 행동부터 시작합니다. Auto Layout 컨테이너 안에 문구와 필요한 아이콘을 배치하고, 안쪽 여백, 정렬, 간격을 일관되게 설정하세요. 더 긴 문구를 넣어 비교한 뒤 재사용 가능한 컴포넌트로 만듭니다.
이 페이지에 필요한 주요·보조·문맥형 표현을 관련 컴포넌트 변형으로 구성하고, 필요한 인터랙션 상태를 더하세요. 적절한 곳에 공통 텍스트·색상 스타일을 사용하면 연결된 컨트롤에서 같은 디자인 결정을 공유할 수 있습니다. Pixso는 Auto Layout, 컴포넌트 변형, 공통 스타일을 지원합니다. 여기서 원하는 결과는 가능한 모든 조합을 모은 거대한 목록이 아니라, 서로 일관되게 작동하는 컨트롤 세트입니다.

컴포넌트의 모양과 페이지의 반응은 구분하세요. 로딩 버튼은 재사용할 수 있지만, 주문이 처리 중인지 실패했는지 확정됐는지는 주문서가 판단합니다. 마찬가지로 재사용 가능한 ‘수정’ 표현이 배송지를 대화상자로 열지 별도 페이지로 열지 결정하지는 않습니다. 이런 결정은 주문서 프레임 옆에 기록하세요.
같은 페이지의 데스크톱·모바일 버전에 인스턴스를 배치합니다. 짧고 긴 문구, 키보드 포커스, 제출 대기, 복구 가능한 오류를 비교하세요. 실제 맥락에서 컴포넌트를 검토해야 합니다. 어떤 행동이 주문을 완료하고 어떤 행동이 세부 정보만 바꾸는지 고객이 여전히 이해할 수 있나요?
개발 전달 자료에는 버튼의 시각적 역할, 조작 영역의 크기, 크기 조절 방식, 상태 표현, 각 인스턴스가 실행하는 행동이 포함되어야 합니다. 개발자는 동작하는 인터페이스에서 키보드 조작과 제출 동작을 구현하고 테스트해야 합니다. 디자인 파일은 요구사항을 명확하게 전달하는 자료이지 실제 구매를 실행하는 시스템은 아닙니다.
Pixso에서 버튼 컴포넌트를 만들어 사람들이 실제로 사용하는 화면 안에서 비교해 보세요.