
작은 화면에 표를 표시하는 방법은 오랫동안 화두가 되어왔습니다. 빠른 구글 검색을 통해 반응형 표를 디자인하는 다양한 의견과 제안을 제시하는 수많은 자료, 튜토리얼, 비디오를 찾아볼 수 있습니다. 그래서 여기에 제 생각을 정리해보았습니다.
SaaS 기업의 제품 디자이너로서 복잡한 데이터의 대량 처리를 자주 다루게 됩니다. 신중하게 고려된 표는 훌륭한 사용자 경험과 괴로운 경험 사이의 차이를 만들어냅니다.
신중하게 고려된 표란 무엇을 의미할까요?
잘 생각한 테이블은 데이터를 행과 열로 구성하여 사용자에게 쉽게 스캔할 수 있도록 정보를 정리하고 그룹화합니다. 사용자 관련 정보를 표시하며 접근성을 고려한 신중한 상호 작용을 통합하며 사용자 친화적인 UI를 갖추고 있습니다. 여기에 UI만큼 중요한 것들도 있죠. 그것은 단순히 "이쁘게" 보이는 것뿐만이 아닙니다. 글꼴 크기, 간격, 여백 및 테두리에 대한 전략적인 디자인 결정을 통해 복잡한 테이블을 쉽게 이해할 수 있도록 하는 것입니다.
하지만 여기서 끝이 아닙니다. 좋은 테이블 사용자 경험을 위해서는 사용자가 데이터를 어떻게 활용할지도 고려해야 합니다. 정보를 비교하여 정보를 분석하여 결정을 내리는 데 필요한가요? 어떠한 조치를 취해야 하는가요?
반복을 거쳐 사용자에게 완벽한 테이블을 마침내 만들었을 때 — 멋있게 보이고 훌륭한 마이크로 상호 작용, 필터링, 정렬, 열 사용자 정의, 고정 헤더 및 열 고정을 갖추고 있어 좋은 테이블 사용자 경험에 필요한 모든 것을 갖춘 테이블이라면 — 도대체 모바일 화면에서 어떻게 보일까요? 🙀
반응형 디자인인가요?
이 질문을 많이 듣는 것 같아요... 그것은 반응형인가요? 제 경험상으로 대부분의 디자이너들은 테이블을 디자인할 때 데스크톱을 우선적으로 고려하고 "반응형" 부분은 나중에 처리하는 경향이 있어요.
제가 이렇게 말씀드리는 것은 조금 위험할 수도 있지만 테이블은 본질적으로 반응형이 아니라고 말씀드릴게요. CSS와 미디어 쿼리를 사용하여 테이블 헤더를 숨기고 행과 셀을 스택 가능하도록 변경하여 display 속성을 변경한다면 기술적으로 테이블의 기능을 제거하는 것이죠.
비록 이 방식은 복잡하지 않은 테이블에서 작동할 수 있지만 몇 가지 문제점이 있습니다:
-
접근성: 스크린 리더 및 다른 보조 기술은 브라우저가 테이블 구조를 올바르게 전달하는 데 의존합니다.
-
반복적인 헤더: 맨 위의 테이블 헤더를 숨기고 각 스택 가능한 행에 표시하는 것은 반복적일 수 있습니다.
-
제한 사항: 순서 및 그룹화 방식을 변경하는 데 제한이 있습니다. 테이블 행의 데이터를 볼 때 합리적으로 보이는 것이 쌓인 뷰에서도 잘 작동하지 않을 수 있습니다.
-
이제 테이블이 맞나요? 테이블은 두 차원의 행과 열로 구성된 셀을 포함하는 데이터의 테이블을 나타내는 요소인 경우에만 의미가 있습니다.
워크어라운드를 사용하여 이용 사례에 대한 접근성을 해결할 수 있습니다. 에이드리언 로젤리의 '반응형 접근 가능한 테이블'에 대한 기사를 읽어보세요.
그러나 테이블을 "응답형"으로 만드는 것이 최선의 방법인지 의문이 듭니다. 디자이너와 개발자로서, "반응형 웹 디자인"이라는 용어가 뇌리에 새겨져 있어서 매우 창의적인 방법을 사용하여 CSS 미디어 쿼리를 사용하여 테이블이 더 이상 테이블로 보이지 않거나 작동하지 않도록 만들어 버립니다. 하지만 또 다른 선택지가 있습니다. 적응형 컴포넌트입니다. 컨텍스트에 따라 컴포넌트를 변경하는 것은 나쁜 생각이 아닐 수도 있습니다.
사용자 콘텍스트 고려
쌍방향(양방향) SaaS 환경에서 테이블은 많은 데이터를 비교하고 사용자가 정보를 바탕으로 판단을 내릴 수 있고 가능성 있는 조치를 취할 수 있는 역할을 합니다. 사용자 페르소나는 아마도 관리자나 경영진 역할을 하는 사람일 것이며 업무를 처리하기 위해 데스크톱, 랩톱 또는 심지어 태블릿을 사용할 가능성이 매우 높습니다. 이러한 장치들에 대해 화면 크기가 충분히 크기 때문에 수평 스크롤이 있더라도 테이블이 그냥 테이블일 수 있습니다. 열이나 행을 고정하고 사용자가 열을 숨길 수 있게 함으로써 복잡한 대형 테이블의 인지 부담을 줄일 수 있습니다.
사용자가 모바일 장치에서이 표를 결코 확인하지 않는다는 것은 아닙니다. 작은 장치에서 큰 표는 혼잡하고 읽기 어려울 수 있습니다. 따라서, 네, 우리는 작은 화면에서의 표를 다루어야하지만, 표 속성을 변경하기 위해 미디어 쿼리를 사용할 수 있는 방법을 고려하는 대신, 사용자가이 맥락에서 데이터를 사용하기를 어떻게 의도하는지에 대해 생각해 봅시다.
모바일 장치에서 데이터를 분석하는 것이 우선순위가 아닐 수 있습니다. 사용자의 요구 사항은 빠른 조치를 취하는 것일 수도 있습니다. 물론, 이 모든 것은 가정에 기반하며 적절한 사용자 연구가 디자인 결정을 검증할 것입니다. 제가 말하려는 것은, 표를 반응형으로 만드는 것이 그저 반응형으로 만드는 것만큼은 아닙니다. 사용자의 여정이 다르다면 구성 요소도 그에 맞게 조정해야 할 수도 있습니다.
다양한 맥락에 맞는 적응형 구성 요소
위의 가정을 참으로 받아들인다면, 사용자가 급히 움직이고 빠른 작업 - 행 삭제, 상태 업데이트 또는 작업 지정과 같은 -을 수행하려는 상황을 상상해보세요. 그러면 간략화 된 데이터를 표시하여 빠르게 스캔하고 빠른 작업을 수행 할 수있도록 목록 요소를 사용하는 것이 의미론적으로 적절합니다.
목록 항목은 순서가 지정되어 있거나 지정되어 있지 않을 수 있지만 CSS를 사용하면 목록이 일반적인 목록과 같지 않아도 됩니다. 좋은 예는 목록을 카드처럼 보이도록 스타일링하는 것입니다. 정보를 어떻게 조직하고 그룹화하는지는 중요하지만 항상 접근성을 염두에 두는 것이 중요합니다. 나는 베를린의 프론트엔드 개발자인 Kitty가 리스트를 사용하여 접근성 있는 카드를 만드는 방법을 훌륭하게 설명하는 것을 좋아합니다.
하루의 끝에는 사용자에게 가장 적합한 선택을 합니다. 모든 디자인 결정에는 장단점이 따르게 됩니다. 사용자의 여정과 필요성이 서로 다를 수 있다는 것을 항상 기억하는 것이 중요합니다. 사용자의 맥락과 우선순위를 이해하고 그에 적응하며 접근성이 뛰어난 효율적인 솔루션을 만드는 데 집중해 봅시다. 유연성과 사용자 중심적 사고는 우리가 탁월한 디자인을 제공하는 데 가장 중요한 도구가 될 것입니다.