Forms

Forms (폼)

폼은 사용자가 데이터를 제공하거나 옵션을 구성할 수 있게 해주는 관련 입력 컨트롤의 그룹이에요. 폼은 단순하거나 복잡할 수 있으며, 사용 사례와 상황에 따라 전용 페이지, 사이드 패널, 또는 대화상자로 제시될 수 있습니다.

출처: Forms

본문

개요 (Overview)

언제 사용할까요 (When to use)

폼은 사용자 인터페이스에서 매우 흔하며, 입력 방법이 더 똑똑해지고 점점 더 많은 사람들이 모바일과 태블릿을 사용함에 따라 그 디자인과 사용이 계속 진화해요. 사용자가 다음을 하도록 폼을 설계할 수 있습니다.

• 계정 가입/로그인
• 서비스 등록
• 설정 재구성 (예: 알림 활성화)
• 설문 조사
• 제품 구매
• 피드백 제공

사용자 존중하기 (Respect the user)

폼은 정보를 모으고 가능한 한 적은 번거로움으로 사람들을 안내하기 위한 것입니다. 사용자가 폼을 빠르게 훑어보고 완료할 수 있도록 폼은 다음을 해야 해요.

• 절대적으로 필요한 정보만 물어봄으로써 사용자의 GDPR 및 기타 개인정보 보호 규정을 존중하세요.
• 섹션 제목 아래에 관련 작업을 그룹화해 더 많은 맥락을 제공하고 인터페이스를 훑어보기 쉽게 하세요.
• 논리적이고 예측 가능한 순서를 따르세요—예: 이름 먼저, 성 다음.
• 사용자가 가능한 한 오래 단일 상호작용 방법을 유지하게 하세요(즉, 한 폼에서 사용자가 키보드와 마우스를 여러 번 오가게 만들지 마세요).
• 디자인할 때는 사용자를 위해 데이터를 채워주는 비밀번호 관리자와 브라우저 기능을 염두에 두세요.
• 관련이 있을 때만 추가 입력을 점진적으로 공개하세요; 아래 '더 긴 폼을 위한 디자인' 섹션을 참고하세요.

폼의 구조 (Anatomy of a form)

폼은 다음 요소 중 일부 또는 전체로 구성됩니다.

• 라벨(Labels): 입력 라벨은 사용자가 해당 입력이 무엇을 의미하는지 이해하도록 도와줘요.
• 텍스트 입력(Text inputs): 사용자가 자유 형식 텍스트를 입력할 수 있게 해줍니다.
• 데이터 입력(Data inputs): 정보는 체크박스, 라디오 버튼, 드롭다운과 선택, 파일 업로더, 날짜 선택기, 토글 등 다양한 비자유 형식 입력 필드를 통해서도 입력될 수 있어요. 각 컴포넌트의 특정 상태와 시각에 대한 심층 내용은 개별 컴포넌트 페이지를 방문하세요.
• 도움말(Help): 사용자가 올바른 정보를 제공하도록 돕는 툴팁, 플레이스홀더 텍스트, 도움말 텍스트 같은 맥락 내 안내를 제공해요.
• 버튼(Buttons): 사용자가 폼을 제출하거나 종료할 수 있게 해줍니다.

폼 구축하기 (Building a form)

라벨 (Labels)

텍스트와 데이터 입력을 위한 간결한 라벨은 사용자가 자신에게 어떤 정보가 요청되고 있는지 이해하도록 도와줘요.

• 제품 이름과 고유 명사를 제외한 모든 텍스트 요소에는 문장형 대문자를 사용하세요. 문장형은 각 문장의 첫 단어만 대문자로 쓰는 것을 의미합니다.
• 형식이 다르게 보일 수 있지만 모든 입력 컴포넌트에는 라벨이 필요해요.
• 라벨은 필요한 입력을 명확히 진술해야 합니다.
• 라벨 이름 뒤에 콜론을 사용하지 마세요.
• 라벨은 도움말 텍스트가 아닙니다; 간결하게 하세요. 한두 단어만 사용하세요.

상단 정렬 라벨 (Top-aligned labels)

상단 정렬 라벨은 Carbon의 기본값이며(왼쪽 정렬 라벨 대신) 현재 제공되는 유일한 라벨 배치예요. 상단 정렬 라벨은 일관된 왼쪽 가장자리와 라벨-입력 사이의 가까운 근접성을 제공하며, 훑어보기와 빠른 폼 완료에 좋습니다.

장점:

• 상단 정렬은 빠른 완료를 가능하게 해요.
• 라벨 길이가 늘어나거나 달라질 여지가 있습니다(예: 다른 언어).
• 사용자가 익숙한 콘텐츠를 입력하고 데이터 입력 오류를 덜 할 가능성이 있을 때 상단 정렬이 이상적이에요.
• 이 배치는 더 적은 폼 필드를 제시해야 할 때 가장 좋습니다.

선택 vs 필수 (Optional vs. mandatory)

폼 항목은 몇 가지 요인에 따라 선택 또는 필수로 라벨링될 수 있어요. IBM 제품에서 필수 또는 선택 사용에 대한 일반적인 구분은 폼의 복잡성입니다.

• 단순 폼(Simple forms) — 대개 더 짧고 및/또는 사용자·소비자 지향적; 가입, 연락처, 체크아웃 화면 같은 것. 대부분의 필드는 필수가 되는 경향이 있어요.
• 복잡한 폼(Complex forms) — 대개 더 길고 제품 지향적; Enterprise 소프트웨어를 구성하는 데 사용되는 속성과 설정을 포함. 보통 최소한 하나의 필수 필드를 포함하지만, 대부분의 필드는 선택이 되는 경향이 있습니다.

대부분의 필드가 필수인지 선택인지에 유의하세요. 전체 제품의 폼 필드 총수가 당신의 처리를 알려야 하기 때문이에요. 사용되는 패턴은 제품 전체에서 일관되어야 하며, 최소한 제품 내 같은 유형의 모든 폼 사이에서 일관되어야 합니다.

• 대부분의 필드가 필수라면 선택 필드 라벨만 (optional)로 표시하세요.
• 대부분의 필드가 선택이라면 필수 필드 라벨만 (required)로 표시하세요.

폼을 디자인할 때는 시각적 소음과 어수선함을 줄여 사용자가 과제를 더 잘 완료할 수 있도록 목적과 사용 사례를 고려하세요. 이는 제품 내·제품 간 일관성도 보장합니다.

과도한 선택 필드는 피해야 해요. 많은 수의 선택 필드가 필요하다면 과도한 반복을 피하기 위해 선택 필드에 전체 섹션을 할애할 것을 권장합니다.

언제 사용할까요 (When to use)

대부분의 필드가 선택일 때는 필드를 (required)로 표시하세요. 대부분의 필드가 선택일 때는 필드를 (optional)로 표시하지 마세요.

모범 사례 (Best practices)

• 전체 제품의 폼에서 필수와 선택 필드의 총 수를 고려하세요. 사용되는 패턴은 제품 전체에서 일관되어야 하며, 최소한 제품 내 같은 유형의 모든 폼 사이에서 일관되어야 합니다.
• 예를 들어 100가지 유형의 연결 속성 폼이 있고 100개 중 85개 폼에서 필드가 선택이라면, 100개 모두 필수 패턴을 사용해야 합니다.
• 폼을 더 쉽고 효율적으로 만들기 위해 아래 기본 값(Default Values)과 더 긴 폼 설계(Designing for Longer Forms) 섹션에 설명된 기법을 사용하세요.

텍스트 입력 (Text inputs)

자유 형식 텍스트 입력은 폼에서 가장 흔히 사용되는 컴포넌트예요.

무엇을 쓸지 정하기 (Deciding what to use)

Control	Usage	Context
Text input	최대 몇 단어를 캡처	이름, 전화번호, 주소
Password input	문자를 숨겨 개인 데이터를 수집	비밀번호, 사회보장번호(SSN), PIN, 신용카드 정보
Text area	여러 줄의 텍스트를 캡처	피드백, 지원 요청

모범 사례 (Best practices)

• 필드 너비는 반응형 컬럼 또는 미니 유닛 그리드에 정렬하면서도 콘텐츠의 의도된 길이를 반영해야 해요.
• 사용자가 더 작은 화면 크기에서도 정보를 입력할 수 있는지 확인하세요.
• 입력이 필드에 완전히 표시되기 너무 길면 잘라내세요.
• 가능하면 알려진 값을 사전 채우세요. 예: 기본 IP 주소.
• 폼의 첫 필수 입력 필드는 사용자에게 제시될 때 포커스를 받아야 합니다.

데이터 입력 (Data inputs)

이 컨트롤들은 사전 결정된 옵션 집합이나 제한된 값 범위에서 선택하여 사용자가 폼에 입력할 수 있게 해줘요. Carbon은 사용자가 선택할 수 있게 하는 다양한 데이터 입력 컴포넌트를 제공합니다. 각 컴포넌트는 특정 사용 사례를 제공하기 위해 만들어졌습니다.

선택 컨트롤 (Selection controls)

선택 컨트롤은 사용자에게 사전 결정된 옵션에서 선택을 제공해요. 디자인할 때 제시해야 할 옵션 수와 사용자가 선택해야 할 항목 수를 고려하세요. 이러한 고려 사항이 어떤 컴포넌트를 쓸지 결정합니다. 일반적인 선택 컨트롤: 체크박스, 라디오 버튼, 파일 업로더, 토글, 선택 리스트(콤보 박스와 멀티셀렉트).

무엇을 쓸지 정하기 (Deciding what to use)

Control	Usage	Context
Checkbox	하나 이상의 선택을 선택 또는 해제	약관 동의, 선택 항목 추가, 해당 사항 모두 선택
Radio button	둘 이상의 선택에서 오직 하나만 선택	유형 선택, 배송 방법 등
Toggle	둘 이상의 이진 옵션 중 하나를 선택	사용자 설정 변경; On/off; Show/hide
File uploader	폼에 파일 또는 여러 파일을 업로드/첨부	SSL 인증서 첨부, 지원 티켓에 구성 파일 추가
Combo box	더 긴 리스트에서 자동완성(type-ahead) 기능으로 단일 항목을 선택	주, 국가, 언어 기본 설정 고르기
Multiselect	더 긴 리스트에서 여러 항목을 선택	MultiSelect 제품 예시 추가

라디오 버튼:

• 사용자를 위해 기본 옵션을 미리 선택하세요; 사용자가 다른 옵션을 선택하면 기본값은 선택 해제됩니다.
• null 옵션의 경우 "None" 라벨이 있는 라디오 버튼을 제공하세요.

라디오 버튼과 체크박스:

• 라디오 버튼과 체크박스 항목 텍스트는 컨트롤의 오른쪽에 옵니다.
• 가능하면 체크박스와 라디오 버튼 그룹을 더 나은 훑어보기를 위해 세로로 배열하세요.

토글:

• 접근성 제약 때문에 토글에는 항상 영향을 받는 속성을 라벨링하세요; 색상이 유일한 표시자가 될 수 없습니다.
• 단독 토글 또는 체크박스는 사용자가 켜거나 끌 수 있는 단일 옵션에 사용될 수 있어요.
• 토글은 제출이 필요 없는 즉시 업데이트 폼에서 매우 흔한 컨트롤입니다.

선택 리스트:

• 사용자에게 제시할 옵션이 다섯 개를 초과하면 체크박스나 라디오 버튼이 아닌 선택 리스트(콤보 박스 또는 멀티셀렉트)를 사용하세요.

경계 입력 컨트롤 (Bound entry controls)

경계 입력 컨트롤은 날짜와 시간 같은 숫자 데이터를 입력할 수 있게 해줘요(예: 숫자 입력, 날짜 선택기, 슬라이더 컴포넌트). 사용자 입력을 제한하며 키보드와 마우스 상호작용에 동등하게 의존합니다. 유효한 입력만 허용하므로 필드 검증이 필요 없습니다.

무엇을 쓸지 정하기 (Deciding what to use)

Control	Usage	Context
Number input	증분 값을 늘리거나 줄이기	주문 수량
Slider	숫자 범위에서 하나의 숫자 선택	백분율, 볼륨, 타임라인, 데이터 시각화
Date picker	캘린더에서 단일 지역화 날짜 또는 날짜 범위 입력/선택	여행, 회의, 이벤트 일정
Time picker	시간을 시/분으로 입력	회의와 여행 시간 일정

도움말 제공하기 (Offering help)

툴팁 (Tooltips)

툴팁은 특정 폼 필드에 익숙하지 않은 사용자에게 추가 설명을 제공하는 데 매우 유용할 수 있어요. 이상하게 보일 수 있는 요청에 대한 근거도 제공할 수 있습니다. 그러나 연구에 따르면 사용자는 과제 완료에 필수적인 정보에 접근하기 위해 툴팁을 파고들어야 해서는 안 됩니다.

Carbon에서는 필수가 아닌 추가 정보를 나타내기 때문에 "?" 아이콘 대신 "i" 아이콘을 사용해요.

툴팁은 호버(데스크톱)와 클릭(태블릿 및 모바일) 시 나타납니다.

Do (권장):

• 외곽선 "i"(정보) 아이콘이 있는 툴팁을 사용하세요.
• 설명적이거나 추가된 정보에 툴팁을 사용하세요.
• 툴팁은 마이크로콘텐츠입니다; 간결하게 유지하세요.

Don't (피해야 할 것):

• 툴팁은 다른 곳에 맞지 않는 콘텐츠의 만능 해결책이 아닙니다; 의도적으로 그리고 매우 드물게 사용해야 합니다.
• 필수 정보를 툴팁에 절대 두지 마세요.

도움말 텍스트 (Helper text)

도움말 텍스트는 입력 라벨 아래에 나타나며 사용자가 올바른 정보를 제공하도록 돕습니다. 도움말 텍스트는 필드가 포커스될 때도 항상 사용 가능해서, 알아야 할(need-to-know) 정보에 대한 올바른 선택입니다. "있으면 좋은" 맥락이나 배경 정보에는 플레이스홀더 텍스트나 툴팁을 사용하세요.

Do (권장):

• 도움말 텍스트를 입력 라벨에 부차적인 중요한 정보로 생각하세요.
• 도움말 텍스트를 가능한 한 짧고 구체적으로 유지하세요.
• 사용자를 과부하시키지 않으려면 정말 필요할 때만 도움말 텍스트를 사용하세요.

Don't (피해야 할 것):

• 필드 라벨 대신 도움말 텍스트를 절대 사용하지 마세요.
• 도움말 텍스트는 입력 영역보다 길게 이어져서는 안 됩니다.

필드가 나란히 나타나고 한 입력에는 도움말 텍스트가 있고 다른 입력에는 없을 때, 항상 입력 필드를 상단 정렬하세요(라벨이 아니라).

플레이스홀더 텍스트 (Placeholder text)

플레이스홀더 텍스트는 무엇을 입력할지에 대한 힌트나 예를 제공해요(예: YYYY-MM-DD). 플레이스홀더 텍스트는 사용자가 데이터 입력을 시작하면 사라지므로 중요한 정보를 담아서는 안 됩니다. 요청된 입력이 사용자에게 낯설거나 형식이 의심스러울 때 플레이스홀더 텍스트를 사용하세요.

Do (권장):

• 힌트를 가능한 한 짧게 유지하고 입력 필드를 절대 넘치게 하지 마세요.
• 실제 값 대신 예시를 적절히 익명화하세요.

Don't (피해야 할 것):

• 비밀번호 요구사항 같은 복잡하고 긴 요구사항을 전달하는 데 플레이스홀더 텍스트를 사용하지 마세요. 대신 인포팁(infotip)을 사용하세요.
• 필요하지 않을 때 플레이스홀더 텍스트를 제공하지 마세요.
• 필드 라벨의 대체물로 플레이스홀더 텍스트를 절대 사용하지 마세요.

기본 값 (Default values)

모든 유형의 입력에 기본 값을 설정할 수 있어요. 기본 값이 제공되면, 그것이 어쨌든 흔히 사용될 값이고 사용자가 제출 전에 잊거나 변경하지 않기로 해도 혼란이나 오류를 일으키지 않는 것인지 확인하세요. 좋은 기본 값은 인지 부하를 줄여줍니다.

예를 들어:

• 사용자의 출신 지역을 감지하거나 결정할 수 있다면 "Country" 드롭다운에서 국가를 미리 선택하세요.
• 공통 또는 최소 값(즉, 할당량이나 메모리 한도)이 있다면 그 값을 사전 채우세요.
• 텍스트 입력을 사전에 감지하거나 결정할 수 있다면(즉, 회사명) 그 값을 사전 채우세요.
• 시작 날짜가 필요하다면 현재 날짜를 기본값으로 사용하세요.

버튼 (Buttons)

주요 동작에는 기본(primary) 버튼을, Cancel이나 Discard 같은 보조 동작에는 보조(secondary) 버튼을 사용하세요.

버튼 정렬 (Button alignment)

정렬은 버튼이 컨테이너나 레이아웃의 오른쪽 또는 왼쪽으로 정렬되는지 여부를 말해요. 버튼 정렬은 구축 중인 폼의 유형에 따라 달라집니다. 여기서는 버튼 컴포넌트와 관련된 정렬을 간단히 다루고, 폼 변형에서 더 상세한 정보를 제공합니다.

여백 vs 전체 박음질 (Margins vs. full bleed)

사이드 패널, 대화상자, 그리고 타일 안의 다른 모든 폼에서 버튼 그룹은 컨테이너의 너비에 걸쳐 있어야 하고 버튼은 아래 가장자리까지 번져야 해요. 이 배열에 버튼 콘텐츠가 너무 길면 버튼을 세로로 쌓고(기본 버튼을 맨 아래에) 여백과 패딩을 유지하세요. 자세한 내용은 버튼 사용 가이드를 참고하세요.

Alignment	Bleed	Use case
Left-aligned	No	대화상자가 아닌 페이지 내 폼
Right-aligned	No	기본 동작이 앞으로의 탐색 단계를 암시하는 다단계 폼/마법사
Full-width	Yes	대화상자와 사이드 패널에 제시되는 모든 폼, 그리고 어떤 경우 타일 안의 폼

버튼 강조 (Button emphasis)

강조는 보조·3차 동작과 관련된 기본 버튼의 위치를 말해요. 폼에서 여러 버튼을 사용할 때 기본 버튼의 위치는 버튼 그룹 가이드에 따라 달라질 수 있습니다. 페이지 레이아웃, 폼 유형, 정렬 같은 요인이 버튼 강조에 영향을 줍니다.

기본 버튼은 페이지 내 폼이나 오른쪽 정렬 기준에 맞지 않는 대부분의 다른 폼 레이아웃에서는 왼쪽 정렬되고 보조/3차 버튼의 왼쪽에 위치합니다. 기본 버튼은 진행형 폼, 마법사, 대화상자 창이나 사이드 패널 같은 구조적 컨테이너 안의 폼에서는 오른쪽 정렬되고 보조/3차 버튼의 오른쪽에 나타납니다.

버튼을 상단 정렬하지 마세요 (Do not top-align buttons)

전용 페이지 폼의 상단에 버튼을 고정하는 트렌드가 제품 팀들 사이에 있어요. 여러 이유로 이 배열을 권장하지 않습니다.

첫째, 우리는 사용자에게 필수 입력만 요청해야 하고 그 정보를 간결하고 의도적인 방식으로 이끌어내야 합니다. 따라서 사용자가 폼을 제출하기 전에 적절한 입력을 통해 스크롤할 것이라고 가정해야 합니다.

둘째, 전용 페이지 폼은 모달이 아니며 사용자가 이전 워크플로우에 접근하는 것을 막지 않아요. 페이지 상단의 브레드크럼의 일부로, 또는 프로그레스 인디케이터 컴포넌트(폼이 다단계 흐름의 일부라면)를 통해 뒤로(back) 버튼을 사용할 수 있습니다. 브라우저 뒤로 버튼도 사용 가능합니다. 요컨대, back은 보조 버튼의 동작이 되어서는 안 됩니다. 보조 버튼은 보통 과제 취소를 위해 예약됩니다.

셋째, 그리고 가장 중요한 것은, 상단 고정 버튼은 사용자가 폼을 완료하고 제출할 준비가 되었을 때 콘텐츠와 매우 어색한 관계를 만듭니다. 미래에 고정 동작을 추구하는 것이 필요하다고 느낀다면, 버튼 그룹을 담는 고정 푸터나 트레이를 살펴봐야 합니다.

기본과 보조 버튼을 폼 하단에 배치하세요. 레이아웃에서 기본과 보조 동작 버튼을 상단 정렬하지 마세요.

동작 이름 짓기 (Naming actions)

"Submit" 같은 추상적 용어는 사용자에게 폼이 일반적이라는 인상을 줍니다. 버튼의 간결함이 핵심이지만, 버튼이 수행할 동작을 구체적으로 사용자에게 알려주려고 노력하세요.

버튼에 작업 특정 언어(task-specific language)를 사용하세요. 동작을 설명할 때 모호한 언어를 사용하지 마세요.

동작 (Behavior)

오류와 검증 (Errors and validation)

효과적이고 즉각적인 오류 메시징은 사용자가 문제를 이해하고 고치는 방법을 돕습니다. 먼저 사용자에게 무슨 일이 일어났는지 알리고, 다음 단계나 가능한 해결책에 대한 안내를 제공하세요. 항상 폼에 오류 상태를 제시하고 가능하면 인라인 오류를 사용하세요.

클라이언트 측 검증 (Client-side validation)

폼 제출 전에 사용자의 데이터를 검증할 것을 권장합니다. 이러한 실시간 인라인 검증(일명 클라이언트 측 검증)은 필드가 포커스를 잃자마자 일어나야 해요. 이는 수정해야 할 요소를 쉽게 식별하는 데 도움이 됩니다.

필드 아래의 검증 라벨은 사용자 데이터의 문제를 설명할 때 가능한 한 정보를 많이 제공해야 합니다. 예를 들어 비밀번호 제한이 16자를 요구하지만 사용자가 여섯 자만 입력했다면, 텍스트는 "비밀번호는 최소 16자여야 합니다."처럼 읽혀야 합니다.

일반적인 사용자 오류는 다음과 같습니다.

• 데이터 잘못된 형식화
• 필수 필드 비워두기
• 필수 필드를 불완전하게 두기

서버 측 검증 (Server-side validation)

서버 측 오류가 관련될 때 인라인 알림이 작동합니다. 즉, 사용자가 폼 전체를 제출하려 하고 페이지가 감지된 오류와 함께 다시 로드되는 경우입니다.

이런 상황에서는 인라인 알림과 가능하면 인라인 오류 메시징을 모두 사용해 사용자가 수정하게 도와주세요. 인라인 오류 메시지는 폼 기준이 충족되면 사라져야 합니다.

버튼 활성화와 비활성화 (Enabling and disabling buttons)

• 오류를 반환하기 전에 서버 측 제출이 필요한 짧은 폼의 경우, 폼의 모든 요구사항이 충족될 때까지 기본 동작 버튼을 비활성화할 것을 권장합니다.
• 더 긴 폼의 경우 기본 동작 버튼을 비활성화하지 마세요. 오류 메시지와 기본 동작 버튼이 화면에 동시에 보이지 않을 수 있기 때문입니다.
• 사용자가 폼을 제출할 때 중복 제출을 방지하기 위해 기본 동작 버튼을 비활성화하세요.
• 폼 처리에 시간이 걸릴 것이라면 피드백 메시지와 프로그레스 인디케이터(예: 스피너 또는 프로그레스 바)로 사용자에게 전달하세요.

인라인 편집 (In-line editing)

인라인 편집은 사용자가 팝업을 편집하기 위해 다른 페이지로 이동하는 대신 제자리에서 폼 텍스트를 편집할 수 있게 해줘요. 이렇게 하면 사용자가 편집을 위해 전체 폼을 새로 고칠 필요가 없습니다.

Carbon은 인라인 편집에 대한 통합된 안내가 없어요. 많은 제품이 서로 다른 방식으로 접근하는 것이므로, 미래에는 더 견고하고 중앙화된 안내를 제공하고 싶습니다.

더 긴 폼을 위한 디자인 (Designing for longer forms)

제품 디자이너들은 웹 폼의 적절한 길이에 대해 자주 묻습니다. 안타깝게도 한 가지 크기가 모두에게 맞는 답은 없어요. 당신의 대상 고객과 의도, 그리고 제품의 맥락이 최선의 해결책을 결정합니다. 더 긴 폼을 덜 압도적으로 만드는 몇 가지 기법이 있습니다.

점진적 공개 (Progressive disclosure)

사용자의 이전 선택에 기반해 발생할 수 있는 추가 콘텐츠를 공개하려면 점진적 공개를 사용하세요. 이러한 보이기/숨기기 접근 방식은 사용자가 작업 흐름을 짧게 유지하면서도 관련 정보에 집중할 수 있게 해줍니다.

아코디언 폼 (Accordion forms)

아코디언 폼은 사용자가 관련 정보의 섹션을 동적으로 드러내고 숨길 수 있게 해줘요. 점진적 공개처럼 아코디언 폼은 사용자가 페이지 사이를 탐색하지 않고 관련 정보에 집중할 수 있게 합니다. 일반 규칙으로 이 기법은 대화상자 폼에서는 사용해서는 안 됩니다.

연구에 따르면 아코디언 폼은 완료 속도와 페이지 로드 시간을 크게 향상시킬 수 있습니다. 그러나 같은 연구는 기본 동작 버튼이 섹션에만 적용되는지 전체 폼에 적용되는지에 대해 사용자에게 혼란이 생길 수 있다고도 제안합니다.

IoT 팀은 아코디언 폼에 대한 몇 가지 디자인 탐구를 했지만, Carbon이 이 상호작용에 대한 안내를 확고히 하기 전에 더 많은 디자인 반복과 사용자 테스트가 필요합니다. 미래에 정제된 사용 예시를 주목하세요.

다단계 폼 (Multistep forms)

다단계 폼은 폼 필드를 여러 화면에 분산시키고 사용자 상태를 단계별로 추적하는 프로그레스 인디케이터(세로 또는 가로)를 통합합니다. 각 화면의 필드 사이에는 논리적 관계가, 섹션 사이에는 선형 관계가 있어야 합니다.

이 접근 방식은 여정을 따라 폼 진행 상황을 저장하는 데 좋고, 사용자가 이전 단계로 돌아가 제출 내용을 검토할 수 있게 합니다.

폼 디자인하기 (Designing a form)

레이아웃 (Layout)

폼 제목 (Form headings)

제목은 폼을 설명해요. 제목은 폼 위계에서 가장 큰 타입 크기여야 합니다. IBM 제품 UI는 폼이 컨테이너나 대화상자 안에 있으면 이 목적을 위해 $productive-heading-03 토큰을 자주 사용합니다. 폼이 페이지의 유일한 요소라면 더 큰 타입 크기를 사용해야 합니다. 제목 뒤에 짧은 설명자가 올 수도 있습니다.

그룹 및 섹션 제목 (Group and section headings)

그룹 제목은 폼 안의 컨트롤과 필드 그룹을 설명해요. 그 크기도 맥락과 폼 제목 크기에 따라 조정되어야 합니다(즉, 선택된 토큰은 필드 라벨보다 크지만 당연히 폼 제목보다는 작아야 합니다). 입력은 사용자가 무엇을 요구받는지 논리적으로 이해하도록 그룹화되어야 합니다. 그룹 제목을 짧고 정확하게 만들되, 필요하면 그룹에 대한 짧은 설명을 추가할 수 있습니다.

간격 (Spacing)

입력이 너무 가까이 있으면 사용자가 혼란스러워할 거예요. 단일 폼 요소 사이와 입력 그룹 사이에 충분한 간격을 보장하려면 여백, 스페이서, 거터, 키 정렬을 안내로 사용하세요. 자세한 내용은 2x Grid를 참고하세요.

폼 맥락 (Form context)

폼은 전용 페이지로 또는 대화상자, 타일, 사이드 패널 안에 나타날 수 있어요. 폼의 맥락은 레이아웃과 세로 간격에 영향을 줍니다. 일반 규칙으로 전용 페이지 폼은 더 많은 복잡성을 처리할 수 있어요. 자세한 사용 안내는 아래 폼 변형을 참고하세요.

전용 페이지 폼에서는 반응형 그리드를 사용해 레이아웃 결정을 이끌어내세요. 대화상자와 사이드 패널 폼은 박스 모델로 되돌아가므로 디자이너는 필드 너비를 안내하기 위해 미니 유닛을 사용합니다. 두 시나리오 모두에서 정렬과 형태의 일관성이 핵심이에요.

개별 입력 필드는 맥락에 관계없이 제품에서 기본 40px 높이입니다. 전용 페이지 폼에서는 입력 필드 사이에 32px 스페이서를 권장합니다. 사이드 패널이나 모달 같은 포함된 폼에서는 디자이너가 입력 사이에 24px 또는 심지어 16px로 되돌릴 수 있습니다.

입력·동작·섹션 분리하기 (Separating inputs, actions and sections)

폼 섹션 사이의 세로 간격도 폼이 전용 페이지인지 컨테이너인지에 따라 달라집니다. 그룹 사이의 간격은 개별 항목 사이의 간격과 관련해 조정되어야 합니다. 예를 들어 개별 입력 사이의 세로 간격이 24px라면 첫 입력 전과 섹션 사이에 32px 스페이서를 고려하세요. 전자가 32px라면 후자는 40px를 고려하세요.

일반 규칙으로 마지막 입력과 버튼 또는 버튼 그룹 사이에 48px 스페이서를 권장합니다. 다시 말하지만, 이는 모바일과 특정 포함된 폼에서는 달라질 수 있습니다.

구분선 (Rules)

디자이너는 폼 안에서 정보 그룹을 분리하기 위해 구분선(rules)을 자주 사용합니다. Carbon은 폼 안의 구분선(즉, 너비, 두께, 세로 여백)에 대한 통합된 안내가 없어요. 미래에 그 사용에 관한 더 상세한 안내를 제공할 의도입니다.

컬럼 (Columns)

Nielsen Norman Group의 연구에 기반해, Carbon은 일반적으로 단일 컬럼 폼을 권장합니다. 단순히 다중 컬럼 폼이 오해를 더 잘 일으키기 때문입니다. 그러나 더 큰 화면 크기와 많은 빈 공간에 직면하면 다중 컬럼 폼이 좋은 아이디어처럼 보일 수 있습니다. 그리고 어떤 상황에서는 적절합니다.

다중 컬럼 폼을 만들고 싶다면 컬럼 수는 페이지의 입력 컨트롤 수, 서로의 관계, 제품 창의 화면 크기에 따라 달라져야 합니다.

항상 상식을 사용해 관련 필드를 가로로 그룹화하세요. 한 줄에 2~3개의 입력은 논리적으로 함께 속한다면 문제를 일으키지 않습니다. 예시:

• [first name][mi] [last name]
• [credit card number][expiration date] [security code]
• [city][state/province] [zip code]

다단계 폼이 더 나은 선택일 수 있을 때 사용자에게 너무 많은 정보를 과부하시키지 마세요.

많은 입력에 직면했을 때는 다단계 폼을 고려하세요. 특히 모달에서 너무 많은 입력 컨트롤을 한 번에 사용자에게 과부하시키지 마세요.

변형 (Variants)

위에서 언급했듯이 폼은 사용 사례와 상황에 따라 전용 페이지, 사이드 패널, 또는 대화상자로 제시될 수 있습니다.

무엇을 쓸지 정하기 (Deciding what to use)

Form variant	Usage	Context*
Dedicated page	더 복잡하고, 길거나, 다단계의 사용자 입력 요청	새 서비스 생성(프로비저닝), 더 복잡한 주문 폼 등
Dialog	편집과 관리 작업과 자주 관련된, 중요하고 드문 사용자 입력 요청	사용자 권한, 서비스 업그레이드
Side panel	사용자가 영향을 받는 정보를 참조해야 하는 반복적 사용자 입력 요청	데이터 테이블의 행 정보 조정

• 제품 팀의 더 많은 입력을 찾고 있습니다. 사용 사례에 대해 저희에게 연락해 주세요.

대화상자 폼:

• 다섯 개 미만의 입력을 다룰 때 대화상자 폼을 사용하세요.
• 아코디언이나 탭에서 정보를 숨기지 마세요.
• 더 상세한 안내가 있는 대화상자 패턴이 곧 출시될 예정입니다.

사이드 패널 폼:

• 다섯 개 초과의 입력을 다룰 때 사이드 패널 폼을 사용하세요.
• 아코디언이나 탭에서 정보를 숨기지 마세요.

접근성 (Accessibility)

폼을 구성할 때는 먼저 사용된 각 컴포넌트에 대한 특정 접근성 안내를 참조하세요. 모든 텍스트 입력에는 설명적이고 보이는 라벨과 함께 입력 형식에 대한 하드코딩된 지침이 있어야 합니다. 폼은 <form> 요소로 감싸야 합니다.

폼에 대한 요구사항은 사용자가 폼에 들어가기 전에 알려지고 선언되어야 합니다.

시각 장애 사용자가 직면하는 가장 중요한 도전은 폼 순서입니다. 폼은 탭 탐색 가능해야 하고 필수 필드는 그렇게 명확히 라벨링되어야 합니다.

잘못 입력된 데이터나 정보가 누락된 필수 필드를 사용자에게 알리기 위해 검증 메시지가 포함되어야 합니다.

도움말 텍스트(label)는 사용자가 폼 필드를 완료하는 방법을 이해하도록 지침을 제공하고 필수·선택 입력, 데이터 형식, 기타 관련 정보를 나타내는 데 사용되어야 합니다.

각 폼 요소에 대한 심층 접근성 안내는 WCAG 웹사이트를 참고하세요.

관련 (Related)

컴포넌트 (Components)

• 버튼 (Button)
• 체크박스 (Checkbox)
• 콤보 박스 (Combo box)
• 멀티셀렉트 (Multiselect)
• 비밀번호 입력 (Password input)
• 라디오 버튼 (Radio button)
• 텍스트 영역 (Text area)
• 텍스트 입력 (Text input)
• 토글 (Toggle)

패턴 (Patterns)

• 대화상자 (Dialogs)
• 알림 (Notifications)

참고 자료 (References)

• Alita Joyce, Tooltip Guidelines, (Nielsen Norman Group, 2019)
• Jakob Nielsen, OK-Cancel or Cancel-OK? The Trouble With Buttons, (Nielsen Norman Group, 2008)
• Kathryn Whitenton, Website Forms Usability: Top 10 Recommendations, (Nielsen Norman Group, 2016)
• Luke Wroblewski, Testing Accordion Forms, (A List Apart, 2010)

추가 읽기 (Further reading)

• Nick Babich, The Power of Defaults, (UX Planet, 2017)
• Raluca Budiu, Marking Required Fields in Forms, (Nielsen Norman Group, 2019)
• Andrew Coyle, Design Better Forms, (UX Collective, 2016)
• Hoa Loranger, Form Design Quick Fix: Group Form Elements Effectively Using White Space, (Nielsen Norman Group, 2013)
• Marieke McCloskey, Accordions Are Not Always the Answer for Complex Content on Desktops, (Nielsen Norman Group, 2014)
• Jakob Nielsen, The Power of Defaults, (Nielsen Norman Group, 2015)
• Preibusch et al., The privacy economics of voluntary over-disclosure in Web forms (2013)

더 알아보기 (Learn more)

폼은 관련 입력 컨트롤을 그룹화해 사용자 데이터를 수집하는 핵심 패턴이에요. 라벨은 상단 정렬을 기본으로 간결하게 쓰고, 필수/선택 표시는 대다수 필드에 반대 패턴으로만 표시합니다. 선택·경계 입력 컨트롤을 사용 사례에 맞게 고르고, 툴팁·도움말·플레이스홀더 텍스트를 구분해 사용하세요. 검증은 클라이언트 측 인라인으로 하고, 복잡한 요청에는 전용 페이지를, 다섯 개 기준으로 대화상자·사이드 패널을 고르며, 단일 컬럼을 기본으로 하는 게 좋습니다.