폼 UI 디자인은 각 필드가 받는 값과 필요한 이유를 정한 뒤, 입력 컴포넌트·검증·오류 복구·전송 결과를 하나의 흐름으로 연결하는 작업입니다. 이 튜토리얼에서는 가상의 팀 워크스페이스 가입 폼을 처음부터 끝까지 만듭니다. Pixso 자체의 가입 화면이 아니라 직접 설계할 서비스의 예시입니다. 같은 폼으로 요구사항, 반응형 레이아웃, 조건부 필드, 프로토타입, 접근성 검토와 D2C를 활용한 개발 전달까지 이어 가겠습니다.

1. 가입 폼의 목적과 필드별 요구사항 정하기
예제의 목적은 새 팀의 워크스페이스를 만드는 것입니다. 입력란을 그리기 전에 계정 생성, 초기 사용 환경 설정, 약관 동의에 필요한 정보를 구분하세요. 다른 가입 화면에 있다는 이유만으로 질문을 추가하지 않습니다.
Pixso 화이트보드에 요구사항 표를 만듭니다. 표, 흐름도와 PRD 같은 초기 기획 자료를 제품·디자인·콘텐츠·보안·개발 담당자가 함께 볼 수 있게 정리하세요. 필드마다 한 행을 두고, 필수 규칙의 담당자를 정한 뒤 세부 화면을 설계합니다.
| 필드 | 목적과 입력 방식 | 규칙과 예시 | 담당 |
|---|---|---|---|
| 업무 이메일 | 계정 식별자, 이메일 입력란 | 필수. 서비스가 허용하는 이메일 형식. 예: alex@studio.com | 계정 시스템 개발 |
| 비밀번호 | 계정 인증 정보, 비밀번호 입력란 | 필수. 길이와 허용하지 않는 값은 제품 보안 정책으로 정의 | 보안 |
| 팀 규모 | 초기 안내 조정, 단일 선택 | 필수. 1명, 2~10명, 11~50명, 51명 이상 | 제품 |
| 국가/지역 | 지역별 초기 설정, 검색 가능한 콤보박스 | 필수. 지원하는 값 중 하나를 선택 | 운영 |
| 관심 분야 | 관련 활용 안내 선택, 체크박스 | 선택 사항. UI 디자인, 프로토타이핑, 디자인 시스템 | 성장 담당 |
| 약관 | 동의 기록, 체크박스 | 필수. 기본값은 미선택. 현재 약관으로 연결 | 법무 |
제품 규칙과 표현 방식을 나누세요. ‘팀 규모는 하나의 값’이라는 규칙을 먼저 정하고, 라디오 버튼과 선택 상자 중 어느 것이 적합한지는 화면에서 판단합니다. 비밀번호 규칙은 보안 담당자가 정하며 디자이너가 임의로 만들지 않습니다. 이렇게 나누면 나중에 검증 동작도 검토하기 쉽습니다. 스프레드시트에서 레코드를 가져오는 흐름이라면 열 연결과 가져오기 미리보기에서 각 열의 의미와 변경 내용을 먼저 확인하게 합니다.
2. 정보 구조와 첫 Pixso 초안 만들기
폼을 세 묶음으로 나눕니다. ‘계정 정보’에는 업무 이메일과 비밀번호, ‘팀 설정’에는 팀 규모·국가/지역·관심 분야, ‘동의’에는 약관과 주요 버튼을 둡니다. 한 열로 배치하면 레이블과 값의 읽는 순서가 위에서 아래로 이어집니다. 좁은 화면에서도 같은 순서를 유지하고, 데스크톱의 빈 공간을 채우려고 관련 없는 필드를 나란히 놓지 마세요.
레이아웃을 빠르게 탐색하려면 Pixso의 AI 패널에서 AI Design을 선택하고 다음처럼 구체적으로 요청할 수 있습니다.
계정 정보, 팀 설정, 동의의 세 그룹으로 구성된 반응형 팀 워크스페이스 가입 폼을 만들어 주세요. 업무 이메일, 비밀번호, 팀 규모, 검색 가능한 국가/지역, 선택 사항인 관심 분야, 약관 체크박스와 워크스페이스 만들기 버튼을 포함하세요. 데스크톱과 모바일 화면, 기본·필드 오류·전송 중·서버 오류·성공 프레임을 보여 주세요.
결과를 Pixso에서 편집한 뒤 1절의 표와 필드를 하나씩 대조합니다. 임의로 추가된 질문은 삭제하고, 레이블과 빠진 상태를 보완하세요. AI 결과는 레이아웃 초안이며 승인된 데이터 모델이나 접근성 검증 결과가 아닙니다. 이 단계에서는 표의 여섯 행이 모두 화면의 컨트롤과 연결되는지, 담당자가 없는 질문이 추가되지 않았는지를 확인합니다.
예제 폼의 구조 배치하기
- 데스크톱과 모바일 프레임을 만듭니다.
- 세 필드 그룹을 같은 순서로 배치합니다.
- 약관 체크박스 다음에 ‘워크스페이스 만들기’ 버튼을 둡니다.
- 버튼 다음에는 전송 피드백을 위한 짧은 상태 영역을 둡니다.
- 프레임 옆 메모에서 각 필드를 요구사항 표의 해당 행과 연결합니다.
3. 레이블, 입력 컨트롤, 도움말과 상태 설계하기
‘업무 이메일’ 컴포넌트부터 만듭니다. 레이블은 항상 보이게 두고, 플레이스홀더는 ‘name@company.com’처럼 예시로 사용합니다. 도움말은 ‘업무 중 확인하는 이메일을 입력해 주세요’처럼 추가 정보가 있을 때만 넣습니다. 오류 상태에서도 입력값을 남겨 두고, ‘name@example.com 형식으로 이메일을 입력해 주세요’처럼 수정할 방법을 알려 주세요.
컨트롤은 작업에 맞춰 고릅니다. 팀 규모는 검색이 필요 없는 짧은 단일 선택 목록이므로 기본 선택 상자가 적합할 수 있습니다. 국가/지역은 목록이 길어 검색 가능한 콤보박스가 유용합니다. 관심 분야는 서로 독립적이므로 아무것도 선택하지 않거나 여러 개를 고를 수 있는 체크박스를 씁니다. ‘복제’, ‘삭제’ 같은 명령을 실행하는 메뉴와 폼 값을 선택하는 컨트롤은 다릅니다. W3C 콤보박스 패턴(영문)에서 편집 가능한 방식과 선택 전용 방식의 용어·키보드 동작을 확인할 수 있습니다.
Pixso에서 Input/Text 컴포넌트를 만들고 기본, 포커스, 입력됨, 오류, 비활성, 읽기 전용 상태를 구분합니다. 필드별 성공 표시는 도움이 될 때만 추가하세요. 이메일 입력란이 초록색이라고 전체 가입이 끝난 것은 아닙니다. ‘전송 중’, ‘전송 실패’, ‘워크스페이스 생성 완료’는 폼 전체의 상태로 따로 둡니다.
금액을 받는 폼은 표시 형식과 오류 상태를 만들기 전에 통화, 구분 기호와 소수 자릿수 규칙을 정해야 입력값을 일관되게 해석할 수 있습니다.
Auto Layout으로 레이블, 입력란, 도움말 또는 오류 문구를 세로로 쌓고 왼쪽 정렬과 간격 값을 정합니다. Pixso AI 기능 안내(영문)에 따르면 Smart Layout은 선택한 여러 레이어에 Auto Layout을 적용할 수 있지만 단일 레이어나 Section에는 적용할 수 없고, 이미 Auto Layout을 쓰는 레이어는 바꾸지 않습니다. Smart Rename은 문맥에 맞는 이름을 제안하면서 사용자가 정한 이름을 덮어쓰지 않습니다. 인스턴스와 그 내부 레이어, 숨김·잠금 레이어, 단일 도형·벡터·텍스트 등은 제외됩니다. 제안된 이름도 팀의 명명 규칙에 맞는지 검토하세요.

4. 검증 시점, 오류 복구와 전송 피드백 연결하기
검증은 입력 도중인 사람을 방해하기보다 문제를 고치게 도와야 합니다. 이 예제에서는 입력이 끝나기 전에 ‘잘못된 이메일’이라고 표시하지 않습니다. 계속 또는 제출 시 서비스의 형식 규칙에 맞지 않는 ‘alex@studio’가 들어 있다면 그 값을 그대로 남겨 수정할 수 있게 하세요. 구현 패턴에 따라 해당 필드나 오류 요약으로 포커스를 안내하고, 요구하는 형식을 설명합니다. ‘alex@studio.com’으로 고친 뒤에는 새 값을 다시 검사한 후 오류를 해제합니다. 이 예제의 형식 규칙을 모든 이메일 서비스의 보편적인 판정으로 보지는 마세요.

GOV.UK 검증 안내(영문)는 오류를 이해하고 고칠 수 있도록 사용자가 입력한 정보를 다시 보여 주도록 설명합니다. 이미 검증을 통과한 값뿐 아니라 고쳐야 할 잘못된 값도 도움이 됩니다. 다만 민감한 필드는 별도 정책을 따릅니다. 일시적인 클라이언트 오류에서는 현재의 안전한 입력 과정 안에서 비밀번호를 유지할 수 있어도, 세션 만료나 보안 경계를 넘을 때는 지우고 이유를 알려야 할 수 있습니다. ‘모두 보존’이라는 원칙만으로 비밀번호, 결제 정보나 다른 민감한 값을 지속 저장해서는 안 됩니다.
검증 시점은 조건에 따라 정합니다. 다음 표는 이 가입 폼의 선택지를 비교하기 위한 기준입니다.
| 시점 | 도움이 되는 경우 | 피하거나 늦출 경우 |
|---|---|---|
| 입력 중 | 미완성 값을 오류로 단정하지 않고 비밀번호 조건이나 글자 수를 안내할 때 | 입력을 마칠 충분한 기회가 아직 없을 때 |
| 필드를 벗어날 때 | 가벼운 검사가 도움이 되고 다시 수정할 때 안내가 혼란을 만들지 않을 때 | 다른 필드에 의존하거나 형식이 더 바뀔 수 있을 때, 서비스가 계속·제출 중심으로 검증할 때 |
| 계속·제출 시 | 필수 항목, 필드 간 규칙, 약관과 최종 클라이언트 검사를 할 때 | 영향받은 필드를 알려 주지 않는 일반 오류만 표시할 때 |
| 서버 응답 시 | 이메일 중복, 권한, 정책 등 서버가 확정해야 하는 값을 검사할 때 | 내부 코드만 보이거나 수정 가능한 입력을 지우거나 확정 전에 성공을 표시할 때 |
이제 Pixso에 폼 전체의 상태 세 가지를 추가합니다. ‘전송 중’에서는 민감하지 않은 입력을 유지하고 버튼을 ‘워크스페이스 만드는 중…’으로 바꾸며 진행 표시와 중복 실행 방지를 설계합니다. ‘전송 실패’는 무슨 일이 생겼는지 쉬운 말로 설명하고 ‘다시 시도’를 제공합니다. 모든 필드 옆에 초록색 체크를 붙여 성공처럼 보이게 하지 마세요. ‘워크스페이스 생성 완료’는 서버가 작업을 확정한 뒤에만 나타나며 다음 이동 경로를 제공합니다. W3C 폼 알림 안내(영문)는 오류와 성공을 시각적으로뿐 아니라 보조 기술에도 전달하는 방법을 다룹니다.

5. 복잡한 선택과 조건부 필드 구성하기
국가/지역은 입력란처럼 보이는 명령 메뉴가 아니라 실제 선택 패턴으로 설계합니다. 팝업에는 후보 값이 나오고, 입력한 글자로 목록을 좁히며 방향키로 탐색하고 Enter로 선택하고 Escape로 닫습니다. 결과 없음과 선택 해제도 문서화하세요. 입력한 문자열과 확정된 선택을 구분하는 방법은 지원하지 않는 국가명을 입력했을 때의 동작을 정하는 데 도움이 됩니다. 검색이 필요 없거나 목록이 짧다면 기본 선택 상자가 더 간단합니다.
팀 규모에서 ‘51명 이상’을 고른 경우에만 선택 항목인 ‘회사명’을 바로 아래에 표시합니다. 구현에서는 새 필드가 나타난 사실을 적절히 알립니다. 다시 ‘2~10명’으로 바꾸었을 때는 제품 정책이 삭제를 요구하지 않는 한 현재 세션의 회사명을 유지하는 설계를 고려할 수 있습니다. 값을 지워야 한다면 삭제 전에 결과를 설명하세요.
배송 주소를 받는 폼에서는 국가에 따라 필요한 필드가 달라집니다. 국제 주소 폼 설계 예제에서 국가 변경 시 입력값을 보존하는 방법과 직접 입력·주소 후보 확인 흐름을 살펴볼 수 있습니다.
폼 전체를 복제하기보다 컴포넌트 속성으로 레이블, 문구, 아이콘, 상태와 선택 필드의 표시 여부를 표현합니다. Input/Text를 수정하면 인스턴스에도 반영한 뒤 줄바꿈, 간격, 정렬과 의도하지 않은 재정의를 확인하세요. 원본 컴포넌트의 변경이 전파된다고 검토가 필요 없어지는 것은 아닙니다. 팀이나 커뮤니티의 리소스를 가져올 때도 해당 컴포넌트의 인터랙션과 접근성은 따로 살펴봅니다.
6. 접근성과 반응형 동작 명세하기
프레임 옆에 구현할 의미 구조를 기록합니다. 업무 이메일과 비밀번호에는 프로그램이 인식할 수 있는 레이블을, 도움말과 오류 문구에는 해당 입력란과의 연결을 지정합니다. 팀 규모에는 하나의 접근 가능한 이름과 선택값이 필요하고, 관심 분야에는 그룹 이름이 필요합니다. 약관 체크박스의 레이블과 링크는 각각 조작할 수 있어야 합니다. 어떤 상태에서도 키보드 포커스가 보여야 합니다.
전송 피드백을 알리는 방식도 정합니다. 필드 오류는 해당 필드와 연결하고, 폼의 상태 영역은 ‘워크스페이스 만드는 중…’, 재시도 가능한 실패, 확정된 성공을 전달합니다. 작은 갱신마다 포커스를 옮기지는 마세요. 제출 후 여러 오류를 찾는 데 도움이 된다면 오류 요약으로 안내하고, 성공 후에는 구현 흐름에 따라 확인 제목이나 확정된 목적지로 이동합니다.
모바일에서도 필드 순서를 유지하고 적절한 가상 키보드 유형을 사용합니다. 고정 버튼 영역이 약관이나 오류를 가리지 않게 하세요. 데스크톱에서는 짧은 입력란을 화면 전체로 늘리기보다 적절한 최대 폼 폭을 정합니다. 200% 확대, 긴 번역문, 긴 이메일, 지원하는 경우 오른쪽에서 왼쪽으로 읽는 레이아웃, 지역별 국가 이름을 시험하세요. Pixso AI Smart Text로 번역 초안을 탐색할 수 있지만 최종 문구는 언어·법무·제품 담당자가 검토해야 합니다.
7. Pixso 프로토타입에서 전체 전송 흐름 따라가기
캔버스에 여섯 프레임을 순서대로 만듭니다. ‘01 기본’, ‘02 이메일 오류’, ‘03 전송 준비’, ‘04 전송 중’, ‘05 서버 오류’, ‘06 워크스페이스 생성 완료’입니다. 현실적인 같은 예시값을 이어서 쓰고, 처음의 형식 검증부터 비동기 처리와 완료 확인까지 상태가 어떻게 바뀌는지 보여 주세요.
Pixso 프로토타입 미리보기에서 연결한 화면을 따라갑니다. ‘alex@studio’를 고치면 이메일 오류에서 전송 준비로 넘어가는지, 전송 중에는 기다리는 이유와 중복 실행 방지가 분명한지 살펴보세요. 서버 오류에서 다시 시도할 때에는 민감하지 않은 입력이 유지되는 경로를 검토합니다. 발표나 공동 검토에 사용할 기기에서는 링크와 미리보기를 미리 열어 전환이 실제로 작동하는지 확인합니다.
참여자에게 각 상태를 검토하게 하고 해당 화면이나 전환 옆에 구체적인 의견을 남깁니다. 실시간 회의든 비동기 검토든 질문은 같습니다. 오류에서 다음 행동을 알 수 있는지, 대기 표시가 처리 중임을 전달하는지, 마지막 화면이 작업 완료를 명확히 보여 주는지 확인하세요. 의견이 화면과 떨어진 메모에만 남지 않도록 디자인의 해당 위치와 연결합니다.
8. 시험 결과를 정리하고 D2C로 개발 전달하기
전달 전에는 빈 필수 항목, 미완성 이메일과 수정된 이메일, 비밀번호 조건, 지원하지 않는 국가/지역, 팀 규모 ‘51명 이상’의 조건부 필드, 미동의 약관, 전송 중 중복 클릭, 재시도 가능한 서버 오류, 세션 만료와 확정된 성공을 모두 확인합니다. 데스크톱과 모바일에서 오류 문구가 줄바꿈될 때 다음 조작 대상이 예상치 못하게 밀리지 않는지, 합의한 보안 정책 안에서 입력을 검토하고 고칠 수 있는지도 봅니다.
필드 이름, 컴포넌트 출처, 형식, 검증 시점, 정확한 안내 문구, 의존 관계, 반응형 규칙, 포커스, 상태 알림과 값 보존 규칙을 기록합니다. 각 프레임을 해당 상태가 필요한 요구사항과 연결하세요. 링크 공유와 댓글을 활용하면 검토 결정을 디자인 가까이에 남길 수 있습니다.
코드 중심의 전달에는 Pixso의 Design to Code(D2C)를 활용할 수 있습니다. 공식 D2C 안내(영문)는 Design Mode와 Dev Mode에서의 사용, React·Vue·HTML·ArkUI·Flutter 출력, 프레임이나 레이어 선택, 프레임워크별 설정, 생성된 파일 구조와 에셋 검토, 코드 패키지 내려받기를 설명합니다. 작업공간에 제공되는 출력 옵션을 고른 뒤 이 순서로 진행하세요. 안내상 Design Mode에는 디자인 최적화가 포함되고 Dev Mode는 확인·생성·내보내기에 초점을 둡니다. 별도 D2C+ 경로에는 기업용 좌석과 파일 범위 같은 조건이 있으므로 두 경로의 이용 조건을 같은 것으로 가정하지 않습니다.
D2C 출력만으로 폼 동작이 완성되지는 않습니다. 개발자는 의미에 맞는 입력 컨트롤, 레이블·안내 연결, 안전한 인증 정보 처리, 실제 서비스 호출, 중복 요청 방지, 결과 알림, 서버 검증과 필요한 분석을 구현해야 합니다. 키보드와 보조 기술로 시험하고, 기본 화면 하나가 아니라 여섯 프로토타입 상태 모두와 구현 결과를 대조하세요.
가입 폼 전달 전에 확인할 항목
- 여섯 기본 필드의 목적, 규칙과 담당자가 정해져 있습니다.
- 모든 컨트롤에 보이는 레이블이 있고 필요한 형식 안내를 오류 전에 제공합니다.
- 팀 규모는 단일 선택이며 국가/지역 검색은 실제로 도움이 되는 경우에 사용합니다.
- 이메일 오류에서도 ‘alex@studio’를 남겨 수정할 수 있게 합니다.
- 민감한 값은 일괄 보존이 아니라 명시적인 보안 정책을 따릅니다.
- 전송 중에는 진행을 알리고 중복 실행을 막습니다.
- 전송 실패에서 재시도할 수 있고 필드의 유효성을 작업 성공으로 표시하지 않습니다.
- 워크스페이스 생성 완료는 서버가 결과를 확정한 뒤 나타납니다.
- 프로토타입에는 기본·오류·전송 중·재시도·성공이 연결되어 있습니다.
- D2C 전달 후에도 의미 구조, 보안, 서버 처리와 접근성 구현을 검토합니다.
입력부터 생성 완료까지 연결된 폼 만들기
좋은 폼은 무엇을 입력하고 어떻게 고치며 작업이 끝났는지를 분명하게 보여 줍니다. 이 예제의 가입 폼처럼 필드별 요구사항에서 컴포넌트, 조건부 입력, 검증, 전송 상태와 개발 전달까지 이어서 설계하세요. 실제 서비스에 적용할 때는 예시 규칙을 승인된 요구사항으로 바꾸고, 제품·보안·접근성·개발 담당자가 같은 흐름을 검토하게 합니다.