Pixso 스테퍼 컴포넌트 만들기: 다단계 가입 폼 UI 구현

잘 설계한 스테퍼 컴포넌트는 현재 위치, 완료한 단계, 확인이 필요한 부분, 입력 내용을 잃지 않고 이동하는 방법을 보여 줍니다. 이 튜토리얼에서는 Pixso로 계정, 조직, 환경설정, 검토의 네 단계로 구성된 실제 가입 흐름을 만듭니다. 완성할 결과물은 단계별 상태를 재사용할 수 있고, 반응형 레이아웃, 유효성 검사 후 오류 복구, 제출 피드백, 구현 참고 사항을 갖춘 편집 가능한 다단계 폼 UI입니다.

스테퍼를 그리기 전에 단계별 흐름 정의하기

원과 연결선을 그리기 전에 폼의 동작 규칙부터 정합니다. 가입 예제에서는 각 단계의 목적, 필수 필드, 유효성 검사를 담당하는 부분, 완료를 판단할 근거를 정리합니다. 계정 단계에서는 이메일과 비밀번호를, 조직 단계에서는 회사 이름과 규모를 입력받습니다. 환경설정은 알림 수신 여부를 선택하는 선택 사항입니다. 검토 단계에서는 계정을 만들기 전에 입력 내용을 읽기 쉬운 요약으로 보여 줍니다.

단계 구분이 무엇을 의미하는지 먼저 판단합니다. 진행 상황을 나타내는 스테퍼는 작업 단계가 명확하고 남은 작업을 파악하는 것이 사용자에게 도움이 될 때 적합합니다. 필드가 두 개뿐인 폼이나 각 단계가 자동으로 진행되는 절차에는 유용하지 않습니다. 짧은 폼을 쉬워 보이게 하려고 나누지 마세요. 단계가 늘어날 때마다 탐색, 상태 저장, 복구를 위한 요구 사항도 생깁니다.

이 상태 모델은 모든 필드가 유효해 보인다는 이유만으로 전체 절차를 완료 처리하는 흔한 오류를 막습니다. 필드 유효성, 단계 완료, 제출 진행 중, 제출 실패, 계정 생성 성공은 서로 다른 상태입니다.

Pixso에서 기본 단계 항목 만들기

Pixso에서 디자인 파일을 열고 재사용할 수 있는 가장 작은 단위인 단계 항목 하나를 만듭니다. 표시자, 레이블, 필요한 경우 보조 설명, 연결선을 추가합니다. 오토 레이아웃(Auto Layout)으로 표시자와 레이블 사이 간격을 조절하고, 항목을 상위 오토 레이아웃 프레임에 넣어 텍스트가 길어져도 위치를 일일이 옮길 필요가 없게 합니다.

구조가 정해지면 컴포넌트로 만듭니다. 이름은 모양이 아니라 기능을 기준으로 정합니다. 예를 들어 Stepper/Item처럼 지정합니다. 편집 가능한 컴포넌트에는 레이블과 보조 설명을 위한 텍스트 속성, 그리고 대기·현재·완료·오류처럼 의미가 분명한 배리언트를 갖는 상태 속성이 있어야 합니다. 비활성 상태는 작업 흐름상 접근이 실제로 제한될 때만 사용합니다. 관련 컴포넌트와 배리언트를 구성하는 방법은 Pixso 컴포넌트 도움말에서 확인할 수 있습니다.

색상에만 의존하지 마세요. 현재 단계는 눈에 보이는 레이블이나 구별되는 표시자 형태로, 완료는 체크 표시로, 오류는 아이콘과 텍스트를 함께 사용해 나타냅니다. 기본 배율에서도 레이블을 읽을 수 있어야 하며, 완료한 단계를 누를 수 있다면 충분한 클릭 영역을 확보합니다.

가로형·세로형 스테퍼 배리언트 구성하기

단계 항목 인스턴스 네 개를 Stepper/Account onboarding이라는 상위 컴포넌트에 배치합니다. 넓은 화면에서는 길이가 유연하게 조절되는 연결선을 사용해 가로로 배열합니다. 좁은 화면에서는 세로로 배열하거나, ‘4단계 중 2단계’처럼 짧은 헤더에 현재 단계 레이블을 함께 표시합니다. 네 개의 레이블을 읽을 수 없을 만큼 줄이는 것은 반응형 설계가 아닙니다.

크기를 정할 때는 실제로 사용할 레이블을 넣습니다. ‘2단계’에서는 드러나지 않는 간격 문제가 ‘조직 정보’에서는 나타날 수 있습니다. 완료·현재·오류·대기 상태의 조합을 테스트합니다. 작업 흐름에서 이후 단계로 바로 이동할 수 없다면 스테퍼도 이동이 가능하다는 인상을 주면 안 됩니다. 따라서 이동할 수 있는 완료 단계와 정보만 제공하는 대기 단계를 시각적으로 구분합니다.

레이어 패널은 스테퍼, 항목, 표시자, 상태 아이콘, 레이블, 보조 설명, 연결선처럼 예측할 수 있는 계층으로 정리합니다. Pixso의 컴포넌트 구조와 공유 라이브러리를 사용하면 여러 화면에서 이 구성을 유지할 수 있습니다. 다만 원본 컴포넌트를 수정한 뒤에는 각 인스턴스를 확인해야 합니다. 특히 인스턴스별 레이블이나 상태를 따로 지정한 경우에는 점검이 필요합니다.

폼의 기본 틀과 탐색 상태 만들기

스테퍼 아래에 제목, 짧은 안내, 필드 그룹, 인라인 메시지 영역, 탐색 버튼 행으로 구성된 폼의 기본 틀을 만듭니다. 내용 영역의 너비를 일정하게 유지해 단계가 바뀔 때 화면 배치가 갑자기 달라지지 않게 합니다. ‘이전’과 ‘계속’ 버튼은 일정한 위치에 두고, 검토 단계에서만 마지막 동작을 ‘계정 만들기’로 바꿉니다.

디자인 파일에서는 탐색 상태를 별도의 프레임이나 상태 그룹으로 표현합니다.

• 입력 준비: 필수 필드를 입력할 수 있으며, 선택한 유효성 검사 정책에 따라 ‘계속’ 버튼이 활성화됩니다.
• 유효성 검사 오류: 입력값은 그대로 보이고, 오류 요약에서 문제가 있는 필드를 알려 주며, 포커스를 어디로 옮길지 문서에 명시합니다.
• 저장 중: 다음 단계로 이동하기 위한 서버 응답을 기다리며, 같은 동작이 반복 실행되지 않게 합니다.
• 저장 실패: 보안 정책의 적용을 받는 민감한 필드를 제외하고, 수정하거나 다시 시도할 수 있도록 입력값을 유지합니다.
• 진행 상황 복원: 돌아온 사용자에게 저장된 진행 상황과 마지막으로 확인된 단계를 보여 줍니다.

정보가 부족하다는 사실을 비활성화된 ‘계속’ 버튼만으로 설명하지 마세요. 버튼을 사용할 수 없다면 근처에 충족하지 못한 조건을 알려 줍니다. 많은 폼에서는 사용자가 버튼을 눌렀을 때 구체적인 유효성 검사 결과를 보여 주는 편이, 버튼을 사용할 수 없는 이유를 스스로 찾아야 하는 방식보다 명확합니다.

같은 예제로 오류 복구 설계하기

계정 단계에서는 잘못된 이메일을 사용자가 입력한 그대로 표시하고, 필요한 형식을 설명하는 인라인 메시지와 해당 필드로 연결되는 오류 요약을 제공합니다. 단계 표시자는 유효성 검사를 실행한 뒤에만 오류 상태로 바뀌어야 합니다. 사용자가 정상적인 값을 입력하는 도중에 빨간색으로 표시해서는 안 됩니다.

사용자가 검토 단계에서 조직 단계로 돌아왔을 때는 올바른 값과 잘못된 값을 모두 유지해 내용을 이해하고 수정할 수 있게 합니다. 비밀번호처럼 민감한 값은 세션 만료 후 다른 정책을 적용해야 할 수 있습니다. 모든 값이 항상 유지된다고 약속하기보다 이런 예외를 문서에 명시합니다.

검토 단계에는 ‘조직 정보 수정’처럼 이동할 곳을 알려 주는 수정 링크가 필요합니다. 앞선 단계의 수정으로 이후 선택지를 사용할 수 있는 조건이 달라지면, 맞지 않는 선택값을 조용히 유지하는 대신 해당 단계를 다시 확인하도록 표시합니다. 이렇게 해야 다단계 폼 UI가 단계 사이의 의존 관계를 정확히 전달합니다.

검토·제출·성공 상태 분리하기

검토 프레임에서는 비밀번호를 노출하지 않고 계정, 조직, 환경설정 내용을 요약합니다. 사용자는 이전 단계로 돌아가 수정한 뒤 다시 검토할 수 있습니다. ‘계정 만들기’를 선택하면 폼 전체의 제출이 시작됩니다. 이는 검토 단계의 완료와는 다른 동작입니다.

제출 중, 재시도할 수 있는 실패, 성공을 각각 명확한 프레임으로 만듭니다. 제출 중에는 현재 맥락을 유지하고 진행 상태를 텍스트로 표시하며 중복 요청을 방지합니다. 실패하면 안전하게 재시도할 수 있는지 설명하고 민감하지 않은 입력값을 유지합니다. 성공하면 계정 이메일과 다음 동작처럼 계정이 실제로 생성되었음을 확인할 근거를 제공합니다. 모든 필드 옆에 초록색 체크 표시가 있다고 해서 계정 생성이 성공한 것은 아닙니다.

Pixso의 댓글 기능으로 제품 담당자 및 개발자와 상태 전환을 검토합니다. 디자인 파일은 의도한 동작을 전달하는 자료입니다. 실제 구현에서는 유효성 검사, 데이터 유지, 키보드 이동 순서, 포커스 이동, 보조 기술에 전달되는 상태 안내, 요청 중복 방지, 보안을 검증해야 합니다.

검토와 개발 전달을 위한 컴포넌트 세트 정리하기

같은 디자인 파일 안에 문서용 페이지를 만들고 컴포넌트 구조, 배리언트, 반응형 예시, 가입 화면을 모읍니다. 스테퍼를 사용할 상황, 실무상 허용할 레이블 길이, 완료한 단계의 선택 가능 여부, 유효성 검사 시점, 데이터 유지 규칙, 모바일 대안 등 사용 지침도 포함합니다.

팀의 관리 정책이 허용한다면 승인한 컴포넌트를 팀 라이브러리에 게시합니다. 개발자는 공유 파일에서 간격, 글자 스타일, 에셋, 주석을 확인할 수 있습니다. 코드 생성 기능을 사용하더라도 결과물은 개발 검토를 위한 출발점으로 보아야 합니다. 실제 서비스의 폼이 데이터와 접근성을 올바르게 처리한다는 증거로 삼아서는 안 됩니다. Pixso의 협업 워크플로를 이용하면 댓글과 개발 전달 맥락을 관련 프레임에 연결해 유지할 수 있습니다.

레이블·단계 번호·접근성 설계 의도 확인하기

단계 번호는 순서를 이해하는 데 도움이 되지만 유일한 레이블이 되어서는 안 됩니다. ‘조직 정보’ 없이 ‘2단계’만 보여 주면 의미가 부족합니다. 다단계 폼 UI를 구현할 때는 현재 단계를 프로그램으로 식별할 수 있게 해야 하며, 시각적인 완료·오류 아이콘에는 같은 의미의 텍스트가 필요합니다. 페이지 제목과 스테퍼가 서로 다른 위치를 안내해서도 안 됩니다.

화면을 200%로 확대하고 번역문이 긴 경우에도 스테퍼 컴포넌트를 점검합니다. 상태 텍스트가 올바른 단계 옆에 남아 있는지, 연결선이 건너뛴 단계까지 완료했다는 인상을 주지 않는지, 세로 배치가 예상한 읽기 순서를 따르는지 확인합니다. 완료한 단계가 링크라면 이름으로 목적지를 알 수 있어야 합니다. 상호작용할 수 없는 항목을 버튼처럼 꾸미지 마세요.

스테퍼 컴포넌트 설계를 문서화할 때는 ‘계속’, ‘이전’, 유효성 검사 실패, 제출 실패 뒤의 포커스 이동 의도를 포함합니다. 디자인 프레임만으로 포커스 동작을 증명할 수는 없지만, 구현 과정의 모호함은 줄일 수 있습니다. 새 단계 제목, 첫 번째 오류 필드, 오류 요약 중 어디로 포커스를 옮길지 기록하고 실제 브라우저에서 검증합니다.

스테퍼 컴포넌트 설계 체크리스트

• 단계 순서가 임의의 화면 분할이 아니라 실제 사용자 작업을 반영한다.
• 현재·완료·대기·오류·접근 불가 상태가 시각 요소와 텍스트로 구분된다.
• 색상 외에도 상태를 전달하는 단서가 있다.
• 완료한 단계로의 이동과 이후 단계의 접근 가능 여부가 명확하다.
• 이전 단계로 돌아가도 보안 정책에 따라 수정 가능한 입력값이 유지된다.
• 필드 유효성, 단계 완료, 폼 제출, 최종 성공을 서로 구분한다.
• 긴 레이블과 좁은 화면을 위해 의도적으로 설계한 반응형 배리언트가 있다.
• 오류 메시지가 문제와 복구 방법을 알려 준다.
• 구현 테스트에서 키보드 순서, 포커스, 상태 안내, 데이터 유지, 중복 제출을 확인한다.

마무리

좋은 스테퍼 컴포넌트 설계는 번호가 붙은 원을 꾸미는 데서 끝나지 않습니다. 작업 흐름의 동작 규칙에서 출발해 복구 과정을 검증해야 합니다. Pixso에서 재사용 가능한 단계별 상태를 만들고 반응형 배리언트를 구성한 다음, 하나의 완전한 다단계 폼 UI에 적용하세요. 탐색, 유효성 검사, 데이터 유지, 제출, 성공 조건까지 문서화하면 디자인팀과 개발팀이 구현 전에 정확히 검토할 수 있는 편집 가능한 컴포넌트 세트가 완성됩니다.