UI 디자인에서 카드와 리스트를 선택하는 방법

사람이 서로 다른 항목을 알아보고 탐색해야 한다면 카드를 선택하세요. 일정한 속성을 훑거나, 알고 있는 항목을 찾거나, 순서대로 작업해야 한다면 리스트를 선택하세요. 여러 레코드의 많은 값을 비교해야 한다면 테이블이 더 적합할 수 있습니다.

UI에서 카드와 리스트를 비교할 때 유용한 출발점입니다. 이미지가 많은 제품에는 언제나 카드가 필요하고 업무 앱에는 언제나 행이 필요하다는 규칙은 아닙니다. 같은 모음이 여러 과제에 쓰일 수 있고, 최적의 레이아웃은 현재 화면이 어떤 과제를 쉽게 해야 하는지에 달려 있습니다.

웹사이트 프로젝트 라이브러리를 생각해 봅시다. 시각적 방향을 찾는 디자이너는 썸네일로 적합한 프로젝트를 알아볼 수 있습니다. 기한이 지난 리뷰를 찾는 프로젝트 관리자는 담당자, 상태, 마감일이 필요합니다. 같은 데이터를 보지만 묻는 질문은 다릅니다. 카드의 모서리 반경을 바꿔도 그 차이는 해결되지 않습니다.

무엇을 찾는지 파악하세요

컴포넌트가 아니라 행동에서 시작하세요. “프로젝트 탐색”만으로는 정해지지 않은 것이 너무 많습니다. “숙박업 고객에 맞는 시각적 스타일의 프로젝트 찾기”와 “오늘까지 검토할 항목 찾기”는 다른 정보 우선순위와 레이아웃 평가 기준을 줍니다.

첫 과제에는 알아볼 수 있는 프리뷰가 유용합니다. 큰 제목만으로는 사진 중심인지, 절제된 타이포그래피인지, 화려한 일러스트인지 드러나지 않을 수 있습니다. 두 번째 과제에는 날짜와 상태가 예측 가능한 위치에 있어야 합니다. 장식용 썸네일은 결정에 도움 없이 공간만 차지할 수 있습니다.

사람이 처음 사용할 단서를 적어 보세요. 이미지, 이름, 분류, 담당자, 날짜일 수 있습니다. 이어서 맞는 항목인지 확인할 두 번째 단서를 정하세요. 이 단서들은 항목을 열기 전에 보여야 합니다. 구분하기 위해 모든 후보를 열어야 한다면 목록 화면이 충분한 일을 하지 못합니다.

Nielsen Norman Group의 카드 설명은 서로 다른 콘텐츠를 묶는 카드의 능력과 리스트의 예측 가능한 훑기 경로를 구분합니다. 카드가 공간을 더 쓰고 순위를 덜 분명하게 만들 수 있다는 점도 짚습니다. 어느 패턴이 항상 이긴다고 여기지 말고, 검토할 장단점으로 활용하세요. Nielsen Norman Group의 UI 카드 설명.

Pinterest와 시선 추적 예가 보여 주는 서로 다른 비용

NN/G의 카드 글에 기록된 Pinterest 인터페이스는 이미지, 제목, 보조 정보를 높이가 다른 컨테이너로 묶습니다. 이미지가 인식 단서이고 항목마다 내용의 양이 다른 모음에 맞습니다. 아래는 당시 인터페이스를 기록한 스크린샷입니다.

같은 글에는 카드 레이아웃에서 흥미로운 기사를 찾은 참여자의 시선 추적 세션도 있습니다. 시선 궤적은 후보 사이를 반복해서 이동합니다. NN/G는 이를 명확한 순위가 없고 비교 정보의 위치가 일정하지 않은 레이아웃과 연결합니다.

두 예는 다른 일을 드러냅니다. 마음에 드는 이미지를 고르는 방문자에게 탐색은 과제의 일부입니다. 최근의 기한 초과 레코드를 찾는 실무자에게 카드마다 날짜를 다시 찾는 일은 불필요한 부담입니다. 둘 다 “둘러보기”라고 부르면 레이아웃을 결정할 차이를 가리게 됩니다.

스타일 테스트보다 정보 테스트를 먼저 해 보세요. 제안한 그리드의 썸네일을 가려 보세요. 주된 과제가 불가능해진다면 이미지가 필요한 근거를 담고 있을 가능성이 높습니다. 날짜와 상태가 잘 보여 과제가 쉬워진다면 이미지가 작업과 경쟁하고 있을 수 있습니다.

항목을 열기 전에 보여야 할 것을 정하세요

대안을 비교할 때는 같은 레코드, 필터, 행동을 사용하세요. 한 사람에게는 기한이 지난 항목을 찾게 하고 다른 사람에게는 시각적 방향을 알아보게 하세요. 이때 어느 레이아웃을 먼저 보여 주는지 번갈아 바꾸세요. 잘못된 선택, 불필요한 상세 페이지 방문, 돌아온 뒤 위치를 잃는 일을 기록하세요. 더 예쁜 화면을 선호한다는 의견은 외관에 관한 유용한 피드백이지만 어느 레이아웃이 과제를 돕는지의 답은 아닙니다.

컨테이너를 고르기 전에 내용을 읽으세요

실제 레코드에서 소규모 표본을 뽑되, 레이아웃에 맞추기 까다로운 사례도 포함하세요. 프로젝트 라이브러리라면 짧은 제목, 긴 제목, 없는 썸네일, 보관된 프로젝트, 담당자가 없는 프로젝트가 될 수 있습니다. 똑같은 임시 사각형으로 채운 화면보다 내용이 적절한 레이아웃에 대해 더 많이 알려 줍니다.

내용의 차이가 큰 모음에는 항목마다 일관된 요약을 만드는 카드가 유리할 수 있습니다. 같은 필드가 반복되는 모음이라면 리스트를 선택할 이유가 강해집니다. 이 관찰만으로 결론이 나지는 않지만 디자인이 무엇을 수용해야 하는지는 알려 줍니다.

미디어가 없는 경우를 특히 살피세요. 대부분의 레코드에 의미 있는 이미지가 없다면 카드 그리드는 반복되는 대체 이미지의 갤러리가 되기 쉽습니다. 레이아웃은 시각적 인식을 약속하지만 실제 내용은 텍스트 검색 과제를 제공합니다. 장식의 변주를 만들어 내는 대신 텍스트 우선 리스트나 작은 선택적 썸네일을 고려하세요.

반대로 시각적 포트폴리오를 파일명으로 줄인 리스트는 필요한 정보를 없앨 수 있습니다. “Project 14”와 “Project 15”는 정확한 이름이어도 약한 인식 단서입니다. 화면에 더 많은 행을 넣는 것보다 유용한 프리뷰를 추가하는 일이 더 중요할 수 있습니다.

예제: 하나의 라이브러리, 두 가지 기본 화면

가상의 프로젝트 여섯 개를 생각해 봅시다. Cedar Lodge, Harbor Rooms, Studio North, Maple Clinic, Archive House, Lumen Shop입니다. 모든 레코드에는 썸네일, 담당자, 리뷰 상태, 리뷰 마감일이 있습니다. 표시가 달라져도 이 필드는 바뀌지 않습니다.

시각적 탐색에는 썸네일을 크게 보여 주고 바로 아래에 프로젝트 이름을 놓습니다. 짧은 분류와 절제된 상태 라벨을 추가합니다. 누구에게 연락할지 판단하는 데 도움이 된다면 담당자도 덜 강조해 표시할 수 있습니다. 데이터가 있다는 이유로 모든 메타데이터를 카드에 채우지는 마세요.

리뷰 관리에는 간결한 행부터 시작합니다. 이름과 필요하다면 작은 썸네일을 앞에 두고, 상태와 마감일을 일정한 위치에 표시합니다. 리뷰 열기 같은 구체적인 행동을 보여 줄 수 있습니다. 시각적 스타일을 묘사하는 장식적인 설명은 이 맥락에서 덜 유용합니다.

두 화면이 정확히 같은 필드를 보여 줄 필요는 없습니다. 다만 같은 대상을 일관되게 설명해야 합니다. 같은 상태를 한 화면에서는 “Ready for review”(검토 준비 완료), 다른 화면에서는 “Pending”(대기 중)이라고 부르면, 화면을 전환하면서 프로젝트 상태가 바뀌었다고 생각할 수 있습니다.

초기 화면은 주된 목적에 맞춰야 합니다. 발견을 돕는 페이지는 카드로, 리뷰 대기열은 행으로 시작할 수 있습니다. 전환을 제공해도 합리적인 기본값을 고를 책임은 남습니다. 많은 사람은 처음 만난 표현을 그대로 사용합니다.

각 화면이 자기 과제를 돕게 하세요

카드: 내부의 읽는 순서를 세우세요

카드에도 읽는 경로가 필요합니다. 항목을 식별하는 요소, 설명하는 요소, 행동을 시작하는 요소를 정하세요. 썸네일, 제목, 배지, 작성자, 태그, 버튼이 똑같이 주의를 요구하면 카드가 유용한 요약 대신 작은 대시보드가 됩니다.

탐색용 프로젝트 라이브러리에서는 썸네일과 제목으로 정체성을 드러냅니다. 분류는 해석을 돕고 상태와 담당자는 보조 사실입니다. 필드마다 색을 달리하지 않아도 크기, 굵기, 근접성, 절제로 이 순서를 표현할 수 있습니다.

비교할 사실은 비교할 위치에 두세요. 카드가 탐색용이어도 여러 후보에서 같은 상세를 확인할 수 있습니다. 상태를 같은 영역에 두고 라벨 형식을 통일하세요. 중요한 메타데이터의 위치가 제각각 달라지도록 두기보다는 설명을 조금 줄이는 편이 나을 때가 많습니다.

이미지가 차지하는 공간의 이유가 있어야 합니다. 레이아웃을 알아볼 수 없을 만큼 작은 스크린샷이 이미지가 없는 것보다 유용하다고 할 수는 없습니다. 식별 특징을 중심으로 자르고, 적절하면 종횡비를 통일하며, 자의적인 자르기를 섞어 프로젝트보다 그리드가 더 복잡해 보이지 않게 하세요.

이미지가 없는 상태도 지원해야 합니다. 이름과 분류로 정체성을 지키는 조용한 대체 화면을 쓰세요. 이미지가 없는 레코드가 모음에서 가장 눈에 띄도록 만들지 마세요.

카드에는 경계도 필요하지만 모두 무거운 테두리와 깊은 그림자를 가질 필요는 없습니다. 목표는 정보를 항목에 연결하는 것입니다. 장식을 추가하기 전에 간격과 절제된 표면 처리를 사용하세요. 한 장에서는 보기 좋은 처리도 스무 장에 반복되면 단조로워질 수 있으니 모음 전체를 검토하세요.

리스트: 일정한 훑기 경로를 유지하세요

행마다 구조가 다르면 리스트의 장점을 쉽게 잃습니다. 식별 정보는 안정적인 위치에 두고 보조 필드의 순서를 정하세요. 아래로 이동할 때마다 행을 다시 배울 필요가 없어야 합니다.

리뷰 대기열에서는 프로젝트 이름을 먼저 놓으세요. 상태와 마감일은 반복해서 찾기 쉬운 곳에 둡니다. 마감일로 정렬한다면 날짜를 보여 주세요. 숨긴 필드로 정렬하면 독자는 보이지 않는 규칙을 찾게 됩니다.

정보 밀도는 읽기와 상호작용을 고려해 결정해야 합니다. 화면에 레코드를 최대한 많이 넣는 경쟁이 아닙니다. 행에는 이름을 구분하고 컨트롤을 편하게 사용할 수 있을 만큼의 공간이 필요합니다. 밀도를 높인 탓에 담당자와 상태가 하나의 회색 줄처럼 뭉쳐 보인다면, 표시되는 레코드가 늘어도 도움이 되지 않을 수 있습니다.

둘째 줄은 의도적으로 쓰세요. 짧은 설명이나 워크스페이스 이름처럼 구분 정보를 담을 수 있습니다. 제목을 다른 말로 반복하지 마세요. “Cedar Lodge website” 아래 “Website project for Cedar Lodge”는 길이만 늘리고 식별에 별 도움이 되지 않습니다.

리스트에도 이미지를 넣을 수 있습니다. 작고 의미 있는 썸네일은 예측 가능한 행 구조를 유지하면서 레코드를 알아보게 합니다. 질문은 이미지가 있어도 되는지가 아니라 항목에서 지배적이어야 하는지입니다.

사용자가 적극 비교하는 정렬 필드가 행에 여럿 쌓인다면 이미 테이블을 설계한 것인지 생각해 보세요. 실패가 아닙니다. 테이블은 명시적인 헤더를 주고 비교를 직접 지원할 수 있습니다. 리스트라고 불러도 열의 관계가 사라지지는 않습니다.

모든 곳을 클릭 가능하게 만들기 전에 클릭 동작을 정하세요

카드는 항목을 열고, 메뉴를 표시하고, 즐겨찾기를 넣고, 분류 링크를 보여 줄 수 있습니다. 행동을 더할 때마다 표면이 복잡해집니다. 이미지, 제목, 빈 곳, 보조 컨트롤을 선택하면 무엇이 일어나는지 설명해야 합니다.

명확한 주된 목적지 하나를 사용하세요. 제목은 프로젝트를 열고 썸네일은 이미지 뷰어를 연다면, 그 차이에 이유와 이해할 수 있는 단서가 필요합니다. 그렇지 않으면 시각적으로 연결된 요소가 무관한 링크처럼 행동합니다. 이름과 배경이 다른 화면으로 가는 행도 같은 문제를 만듭니다.

W3C 디자인 시스템은 개별 링크가 있는 카드와 표면 전체가 링크인 카드를 모두 설명하고, 제목 단계가 주변 페이지에 맞아야 한다고 명시합니다. 시각적인 카드가 하나의 필수 상호작용 모델은 아니라는 점을 상기시킵니다. W3C의 카드 컴포넌트 패턴.

프로젝트 예에서는 링크 제목과 독립된 메뉴가 이해하기 쉬운 출발점입니다. 구현에서 주된 클릭 영역을 넓힌다면 메뉴가 독립적으로 작동하고 필요할 때 텍스트를 선택할 수 있는지 확인하세요. 링크를 중첩하거나 모든 텍스트 조각을 키보드가 따로 멈추는 지점으로 만들지 마세요.

선택과 열기는 다릅니다. 여러 프로젝트를 골라 작업하려는 사람에게는 눈에 보이는 선택 상태와 명확한 해제 방법이 필요합니다. 명시적인 모드 전환 없이 한 화면의 첫 클릭은 선택이고 다른 화면의 첫 클릭은 열기가 되어서는 안 됩니다. 전환은 표현을 바꾸는 것이지 기본 행동을 조용히 재정의하는 것이 아닙니다.

포인터로 조작할 때의 동작과 함께 키보드로 조작할 때 기대하는 동작도 적으세요. 포커스는 어디로 가나요? 무엇으로 항목을 여나요? 보조 메뉴에는 어떻게 도달하나요? 스크린샷은 답할 수 없으니, 시각적 위계가 명확하면 조작 구조도 명확하리라 가정하지 말고 상호작용 검토에 포함하세요.

두 화면이 모두 필요한 경우에만 전환을 제공하세요

같은 사람이 인식과 훑기를 실제로 오간다면 카드·리스트 전환은 가치가 있습니다. 하나가 다른 하나의 약한 버전이면 도움이 적습니다. 두 화면을 지원하면 콘텐츠 상태와 조작 세부사항도 두 배가 됩니다.

전환을 넣는다면 필터, 정렬, 선택한 모음을 유지하세요. 검토 대기로 좁힌 라이브러리가 리스트로 바뀌자 모든 프로젝트로 돌아가면 안 됩니다. 전환은 결과를 표현하는 방식을 바꾸지, 현재 조건에 맞는 결과를 바꾸지 않습니다.

의미가 있다면 선택을 보존하고 한계는 명확히 하세요. 일괄 행동이 리스트에만 있다면 선택 항목을 조용히 버리지 말고 설명하세요. 가능하면 양쪽에서 행동을 일관되게 유지할 수 있는지도 고려하세요.

라벨이 있고 활성 상태가 보이는 컨트롤을 쓰세요. 그리드와 행 아이콘이 도움이 되지만 모양만으로 모든 레이아웃을 설명할 수는 없습니다. “카드”, “리스트” 같은 짧은 라벨은 특히 좁은 화면에서 두 표현이 비슷할 때 선택을 분명하게 합니다.

재방문자도 생각하세요. 구현된 제품에서 선호 화면을 기억하면 유용할 수 있지만 과제가 바뀌는 맥락을 덮어써서는 안 됩니다. 리뷰 대기열과 공개 영감 갤러리가 하나의 전역 설정을 공유할 필요는 없습니다. 저장이 우발적인 동작이 되지 않게 범위를 정하세요.

좁은 화면에서도 과제를 유지하세요

휴대전화에서는 그리드가 한 열이 되곤 합니다. 그렇다고 자동으로 유용한 리스트가 되지는 않습니다. 카드 이미지가 화면 대부분을 차지하고 필요한 필드는 훨씬 아래에 남을 수 있습니다. 레이아웃이 바뀐 뒤 정보 위계를 검토하세요.

탐색용이라면 넉넉한 프리뷰가 여전히 적절할 수 있습니다. 리뷰 대기열에는 읽기 쉬운 날짜가 있는 간결한 요약이 더 유용할 수 있습니다. 데스크톱의 맨 오른쪽 열이었다는 이유로 결정적인 필드를 숨기지 마세요.

보조 필드는 정해진 순서로 줄바꿈하거나 둘째 줄로 옮기세요. 공간을 아끼려고 상태를 설명 없는 색점으로 만들지 마세요. 펼쳐야 보이는 곳에 옮긴다면 모든 항목을 열지 않고도 주된 과제를 할 수 있는지 결정하세요.

긴 이름은 특히 문제를 잘 드러냅니다. 앞부분이 같고 끝에서 차이가 나는 실제적인 프로젝트 이름 두 개를 사용하세요. 둘 다 똑같이 잘린다면 좁은 레이아웃은 레코드 식별 능력을 잃었습니다. 글자 크기를 줄이기 전에 줄바꿈, 가용 폭, 보여 줄 식별 필드를 조정하세요.

조작 영역은 따로 확인하세요. 넓은 행에서는 쓰기 편한 메뉴 버튼도 폭이 좁아지면 제목이나 체크박스에 너무 가까워져 조작하기 어려울 수 있습니다. 작은 컨트롤 세 개가 있는 카드는 폭이 줄면 특히 조작하기 어려워질 수 있습니다. 과제가 간단해진다면 선택적 행동은 표면에서 빼되 명확한 접근 경로를 남기세요.

실제 찾기 과제로 리스트와 그리드를 비교하세요

검토자에게 선호만 묻지 말고 관찰 가능한 답이 있는 과제를 주세요. 프로젝트 라이브러리의 시각적 탐색은 절제된 숙박업 방향의 프로젝트 찾기일 수 있습니다. 알고 있는 항목 찾기는 Archive House, 관리용 훑기는 특정 담당자의 가장 이른 리뷰 찾기가 될 수 있습니다.

양쪽에 동등한 내용을 쓰세요. 한쪽만 썸네일이 좋거나 글이 짧거나 필터가 유용하면 레이아웃 외의 것도 비교하는 셈입니다. 개선 자체가 가치 있어도 카드나 리스트가 본질적으로 낫다는 근거로 오해해서는 안 됩니다.

어디서 망설이는지 보세요. 빠진 상태를 알아내려고 반복해서 연다면 콘텐츠 문제입니다. 돌아온 뒤 위치를 잃는다면 탐색 문제입니다. 그리드 둘째 줄을 건너뛴다면 시각적 순서 문제일 수 있습니다. 관찰마다 다른 변경을 가리킵니다.

선호하는 디자인에 불리한 과제도 넣으세요. 카드를 좋아하면 반복 필드 찾기를, 리스트를 좋아하면 비슷한 이름 사이의 시각적 인식을 시험하세요. 목적은 첫 목업의 승인을 받는 것이 아니라 선택의 비용을 드러내 감수할 만한지 판단하는 것입니다.

OpenDesign에서 HTML 레이아웃 대안을 만들고 검토하고, 화면 크기 프리셋을 확인하고, 특정 카드나 행에 댓글을 달 수 있습니다. 레코드와 요건을 맥락에 두어 수정의 기준을 유지하세요. 검색, 저장된 설정, 지속되는 선택은 구현된 흐름에서 테스트하세요.