칸반 보드 UI 디자인: Pixso에서 컴포넌트 세트 만들기

실용적인 칸반 보드 UI는 여러 색상의 열을 나열하는 데 그치지 않고, 재사용할 수 있는 상태를 체계적으로 표현해야 합니다. 카드에는 일관된 메타데이터가, 열에는 명확한 제한과 빈 상태가 필요합니다. 드래그 동작도 시작 전, 이동 중, 완료 후의 상태를 구분해야 합니다. 이 튜토리얼에서는 업무를 백로그에서 진행 중, 검토, 완료로 옮기는 제품 팀을 위해 Pixso에서 편집 가능한 칸반 컴포넌트 세트를 만듭니다.

1부. 카드를 그리기 전에 보드 모델 정의하기

먼저 업무 흐름의 규칙을 적습니다. 예제 보드는 네 개의 열을 사용하며, 작업마다 담당자 한 명, 우선순위 하나, 최대 두 개의 라벨을 표시합니다. 진행 중 열에는 카드 세 개까지만 둘 수 있습니다. 카드를 검토 열로 옮기려면 담당자가 지정되어 있어야 합니다. 완료된 카드에는 마감일 대신 완료일을 표시합니다.

이 규칙은 예제 제품의 조건이며 모든 칸반 보드에 적용되는 원칙은 아닙니다. 제품 책임자에게 다음 사항을 확인하세요.

• 어떤 열이 있으며, 누가 열 사이에서 작업을 이동할 수 있는지.
• 열 안의 카드 위치가 수동으로 정한 우선순위인지, 다른 정렬 기준을 따르는지.
• 각 상태 전환에 어떤 필드가 필수인지.
• 진행 중 작업 수 제한을 넘으면 이동을 차단할지, 경고만 표시할지.
• 보관됨, 차단됨, 기한 초과, 완료된 작업을 어떻게 표현할지.
• 다른 협업자가 같은 카드를 이동하면 어떻게 처리할지.

이 규칙을 디자인 옆에 정리해 두세요. Pixso 화이트보드에는 초기 업무 흐름도나 PRD 표를 정리하고, 디자인 파일에는 편집 가능한 보드와 컴포넌트 상태를 담을 수 있습니다. 보드가 정책을 결정하는 것은 아닙니다. 정해진 정책을 눈에 보이게 표현해 검토할 수 있도록 합니다.

정리한 워크플로 규칙을 아래 예시의 백로그, 진행 중, 검토, 완료 네 개 열로 옮겨 보세요. 재사용 가능한 컴포넌트를 만들기 전에 진행 중인 작업(WIP)의 개수 제한, 카드 필드, 빈 상태가 팀의 운영 규칙과 맞는지 확인합니다.

2부. 카드의 정보 구조 설계하기

작업을 나타내는 데 필요한 최소한의 카드부터 시작합니다. 가장 중요한 정보는 작업 제목입니다. 보조 메타데이터는 사용자가 항목을 하나씩 열지 않고도 다음 행동을 결정하도록 도와야 합니다. 이 예제에는 작업 ID, 우선순위, 라벨, 담당자 아바타, 마감일, 댓글 수를 넣습니다. 구현할 때는 보조 기술에서도 담당자의 이름을 알 수 있어야 합니다.

이 칸반 보드 UI에서는 모든 메타데이터 필드가 작업 이동이나 우선순위 판단에 도움이 되도록 구성합니다.

정보는 예측할 수 있는 순서로 배치하세요.

1. 작업 ID와 상태 표시.
2. 정해진 줄 수 안에서 줄바꿈할 수 있는 작업 제목.
3. 제품 영역이나 작업 유형을 나타내는 라벨.
4. 조치가 필요할 때 표시하는 우선순위와 마감일 경고.
5. 담당자와 댓글 수 등의 보조 정보.

카드는 상세 페이지를 축소한 화면이 아닙니다. 훑어보기나 이동 판단에 도움이 되지 않는 메타데이터는 숨기세요. 심각도, 우선순위, 마감 위험을 모두 강한 색상으로 표시하면 보드가 산만해집니다. 가장 중요한 판단에 가장 눈에 띄는 표시를 사용하고, 텍스트나 의미가 분명한 아이콘을 함께 제공하세요.

3부. Pixso에서 카드 컴포넌트 만들기

먼저 Pixso에서 ‘칸반 컴포넌트’라는 페이지를 만들고 원본 컴포넌트를 모을 섹션을 추가합니다. 제목, 라벨, 메타데이터가 실제 콘텐츠에 맞게 배치되도록 레이아웃을 설정합니다. 이 구조를 컴포넌트로 만든 뒤 팀이 실제로 변경하는 속성을 노출하세요.

장식적인 차이까지 모두 컴포넌트 속성으로 만들지 마세요. 라벨 색상마다 별도의 변형을 만들면 라이브러리를 관리하기 어려워집니다. 디자인 시스템에서 허용하는 범위 안에서 스타일이나 변수를 사용하고, 의미에 따라 구분한 제한적인 라벨 색상 팔레트를 정의하세요.

Pixso AI의 스마트 이름 변경은 의미 없는 레이어 이름을 업무 맥락에 맞는 이름으로 바꾸는 데 도움이 되며, 스마트 레이아웃은 선택한 콘텐츠를 재구성하는 데 활용할 수 있습니다. 두 기능 모두 편집 보조 수단으로 사용하세요. 팀 라이브러리에 컴포넌트를 게시하기 전에 결과의 계층 구조, 간격, 이름을 검토해야 합니다. 현재 기능 개요는 Pixso AI 문서에서 확인할 수 있습니다.

4부. 열과 열의 상태 만들기

열 컴포넌트에는 헤더, 카드 수, 필요에 따른 제한 수, 카드 목록, 추가 동작, 빈 상태가 필요합니다. 카드 내용을 훑어보기 쉽도록 열의 너비를 안정적으로 유지하고, 가로로 넘치는 영역은 보드에서 처리합니다. 진행 중 작업 수가 한도에 도달했을 때 색상만 바꾸지 말고 ‘2/3’처럼 현재 수와 한도를 함께 표시하세요.

카드가 있는 상태, 비어 있는 상태, 로딩 중, 한도 도달, 권한 제한 상태를 만듭니다. 빈 상태가 항상 ‘작업 만들기’를 뜻하지는 않습니다. 검토 열이 비어 있다면 ‘검토를 기다리는 작업이 없습니다’라고 표시할 수 있습니다. 다음 행동은 해당 열의 목적과 사용자의 권한에 따라 달라집니다.

열 하나를 불러오지 못했다면 나머지 보드는 유지하고 해당 영역을 사용할 수 없다고 설명하세요. 데이터를 알 수 없는 상황에서 작업이 없다는 뜻의 빈 상태를 표시하면 안 됩니다.

5부. 칸반 보드 UI 조립하기

네 개의 열 인스턴스를 배치한 보드 프레임을 만듭니다. 검색, 담당자 필터, 라벨 필터, 보기 설정처럼 보드에서 실제로 지원하는 작업에만 도구 모음을 제공하세요. 가능한 모든 관리 기능을 보드 위에 나열하지 마세요.

다음과 같이 현실적인 콘텐츠를 넣고 보드를 확인합니다.

• 짧은 작업 제목과 세 줄짜리 작업 제목.
• 담당자가 없어 검토 열로 이동할 수 없는 작업.
• 마감일이 지났으며 우선순위가 높은 항목.
• 작업 수가 한도에 도달한 진행 중 열.
• 카드가 없는 검토 열.
• 완료일이 표시된 완료 작업.

데스크톱에서 열이 많을 때는 가로 스크롤을 사용하면 카드의 읽기 좋은 너비를 유지할 수 있습니다. 좁은 화면에서는 모든 열을 화면 안에 억지로 넣기보다 한 열에 집중하고 열 전환 컨트롤을 제공하는 방식을 고려하세요. 사용자가 현재 맥락을 유지하면서 열 사이를 어떻게 이동하는지 디자인에 명시해야 합니다.

6부. 드래그 앤 드롭을 상태의 흐름으로 설계하기

반투명 카드 하나만으로는 드래그 동작을 설명할 수 없습니다. 들어 올린 카드, 원래 위치, 이동 가능한 대상, 이동할 수 없는 대상, 삽입 위치, 자동 스크롤 영역, 놓은 뒤의 결과를 표현하세요. 실제 구현에는 키보드와 터치로 이용할 수 있는 대체 방법도 있어야 합니다.

1. 대기 상태: 카드를 쉽게 읽을 수 있으며, 드래그할 수 있다는 표시가 링크나 메뉴를 방해하지 않습니다.
2. 카드를 들어 올린 상태: 원래 위치를 알 수 있고, 이동 중인 카드가 떠 있다는 느낌이 분명합니다.
3. 유효한 대상 위: 삽입 표시가 카드를 놓았을 때의 정확한 위치를 보여 줍니다.
4. 이동할 수 없는 대상 위: 대상 영역에 ‘검토 전에 담당자를 지정하세요’와 같이 적용되는 규칙을 설명합니다.
5. 카드를 놓은 상태: 새 위치에 카드가 표시되고, 보드가 상태 변경을 확인해 줍니다.
6. 이동 실패: 카드를 원래 위치로 되돌리거나 복구할 수 있게 유지하며, 실패 이유와 재시도 방법을 제공합니다.

시각적 디자인만으로 실시간 충돌 처리가 검증되었다고 보아서는 안 됩니다. 다른 사람이 같은 작업을 옮기면 제품에서 적용할 충돌 처리나 새로고침 규칙이 필요합니다. 디자인 프레임에는 의도한 안내 문구를 보여 줄 수 있지만, 동기화는 개발 단계에서 테스트해야 합니다.

7부. 드래그 없이 이동하는 방법 제공하기

드래그는 모든 사람에게 똑같이 편리하지 않으며, 터치 기기에서는 정확히 조작하기 어려울 수 있습니다. 카드 메뉴나 상세 패널에 ‘다른 열로 이동’ 기능을 추가하세요. 이동할 수 있는 열을 나열하고, 제한된 전환의 이유를 설명하며, 선택한 목적지를 확인할 수 있어야 합니다.

키보드 사용자를 위해 최종 제품에서 메뉴, 명령 또는 사용법이 안내된 들어 올리기·놓기 조작을 제공할 수 있습니다. 어떤 방식을 선택하든 포커스의 이동을 예측할 수 있어야 하며, 카드의 새 위치를 보조 기술에 알려야 합니다. 디자인 검토에 그치지 말고 실제 구현에서도 이러한 동작을 테스트하세요.

8부. 보드 상태를 가리지 않는 필터 설계하기

필터는 사용자가 볼 수 있는 항목을 바꾸며, 실제 업무 흐름을 변경하지는 않습니다. 적용된 필터와 명확한 초기화 방법을 표시하세요. 열에 표시되는 숫자가 전체 카드 수인지 현재 보이는 카드 수인지 정의해야 합니다. 현재 결과 수를 보여 준다면 ‘8개 중 2개’처럼 표시해, 필터 때문에 가려진 작업을 누락된 작업으로 오해하지 않도록 하세요.

검색 결과에서는 일치하는 텍스트를 강조할 수 있지만 상태 표시는 없애지 마세요. 결과가 없을 때는 조건에 맞는 카드가 없다고 안내하고, 사용자가 수정할 수 있도록 필터를 유지합니다. 서버에서 검색을 처리하는 보드라면 로딩과 부분 실패 상태도 추가하세요.

9부. 팀과 함께 컴포넌트 세트 검토하기

인스턴스를 검토한 뒤 승인된 원본 컴포넌트를 팀의 재사용 라이브러리에 게시합니다. 해당 카드나 열의 정확한 상태에 댓글을 달아 콘텐츠, 권한, 상태 전환에 관한 결정을 기록하세요. Pixso는 실시간 공동 편집과 맥락에 연결된 댓글을 지원하므로 제품, 디자인, 개발 담당자가 하나의 편집 가능한 결과물을 함께 검토할 수 있습니다.

칸반 보드 UI 검토에는 재사용할 원본 컴포넌트와 실제 사용 조건을 반영한 보드 인스턴스가 모두 포함되어야 합니다.

팀의 Pixso 디자인 시스템에 카드 구조, 속성 정의, 라벨 제한, 열 너비, 빈 상태, 이동 규칙, 잘못된 사용 사례를 문서화합니다. 검토할 파일은 Pixso 제품 디자인 작업 공간을 통해 공유하세요. 컴포넌트를 게시했다고 제품 규칙까지 승인된 것은 아닙니다. 각 상태 전환 제약 조건을 그 근거가 되는 공식 정책이나 요구사항 문서과 연결하세요.

10부. 개발 전달을 위해 보드 정리하기

반응형 규칙, 영역 넘침, 간격, 카드 텍스트 잘림, 상태 대응 관계, 모든 드래그 상태에 설명을 달아 주세요. 각 전환마다 실행 조건, 낙관적 업데이트 또는 서버 확인 후 업데이트 여부, 실패 복구, 완료를 확인하는 표시를 명시합니다. 개발자가 시각적 속성과 업무 규칙을 구분할 수 있어야 합니다.

Pixso의 개발자 검사 기능과 D2C는 React, Vue, HTML, ArkUI, Flutter 코드 생성 등을 통해 전달 작업을 지원할 수 있습니다. 생성한 코드도 프로젝트의 상태 모델, 드래그 라이브러리, 시맨틱 구조, 키보드 동작, 성능, 데이터 동기화, 테스트 관점에서 개발자의 검토가 필요합니다. 현재 작업 흐름은 Pixso D2C 가이드에서 확인하세요.

11부. 칸반 보드 UI 디자인 체크리스트

• 열, 전환 규칙, 권한, 작업 수 제한의 책임자를 지정했는가.
• 카드가 상세 페이지처럼 복잡해지지 않으면서 메타데이터로 빠른 파악을 돕는가.
• 기본, 선택됨, 드래그 중, 차단됨, 완료, 실패 상태를 모두 다뤘는가.
• 열에 카드가 있음, 비어 있음, 로딩, 한도 도달, 사용 불가 상태가 포함되어 있는가.
• 드래그 중 삽입 위치와 이동할 수 없는 대상이 명확한가.
• 드래그하지 않고도 카드를 옮길 수 있는가.
• 필터가 카드 수와 검색 결과 없음 상태에 미치는 영향을 알 수 있는가.
• 긴 콘텐츠, 다국어 표시, 좁은 화면, 높은 확대 배율을 검토했는가.
• 실시간 충돌, 권한, 키보드 동작을 실제 구현에서 테스트했는가.

마무리

명확한 업무 규칙, 재사용할 수 있는 카드·열 컴포넌트, 이동 전 과정을 표현한 상태 흐름을 토대로 칸반 보드 UI를 만드세요. Pixso는 팀이 편집 가능한 컴포넌트, 공유 기준, 검토 댓글, 개발 전달 맥락을 관리하도록 돕습니다. 각 시각적 상태를 실제 권한, 데이터 동작, 구현 테스트와 연결할 때 더 견고한 결과물을 만들 수 있습니다.