화면설계 (3) - 레이아웃 작성 Tip
레이아웃과 디스크립션을 분리하는 관점
화면설계서를 작성할 때는 레이아웃과 디스크립션을 먼저 구분해 두는 것이 기본이 됩니다. 레이아웃은 버튼, 입력창, 탭과 같은 UI 요소가 화면 어디에 배치되는지를 보여주는 영역이고, 디스크립션은 그 요소들이 어떤 역할을 하며 어떤 기능으로 동작하는지를 설명하는 영역입니다. 두 영역을 구분하지 않으면 화면은 그려졌는데 동작 의도가 빠지거나, 설명은 많은데 화면 구조가 한눈에 잡히지 않는 문제가 생기기 쉽습니다.
레이아웃은 “형태”를 잡아주고, 디스크립션은 “기준”을 잡아줍니다. 구현과 검수의 단계에서는 결국 이 기준이 필요해지기 때문에, 화면설계서가 단순한 스케치에 머물지 않으려면 두 축이 분리된 채로 함께 구성되는 편이 안정적입니다.
작성 Step 1. 거시에서 미시로
레이아웃을 그릴 때는 거시적인 흐름을 먼저 잡고, 그 다음에 미시적인 디테일로 내려오는 방식이 자연스럽습니다. 화면은 고립된 한 장이 아니라 사용자 여정의 특정 지점에 놓여 있고, 사용자는 이전 화면에서 이미 어떤 정보를 보고 들어오며, 다음 화면에서 어떤 행동을 할지를 예상한 채 움직이기 때문입니다.
예를 들어 사용자가 메인에서 상품 목록을 보고 상세 페이지로 이동하는 흐름이라면, 상세 페이지에서 메인과 목록에서 이미 확인한 정보를 다시 강하게 반복할 필요는 크지 않습니다. 상세에서 더 중요한 것은 사용자가 결정을 내리기 위해 필요한 정보와 행동이며, 장바구니 담기나 주문 버튼처럼 실제 행동을 유도하는 핵심 기능이 화면에서 분명히 드러나야 합니다. 이런 우선순위는 디테일을 그리기 전에, 먼저 화면의 “역할”을 규정할 때 정리됩니다.
사례 1. 여행사 상세 페이지
여행 상품 상세 페이지를 설계할 때 핵심이 되는 요소는 가격 정보와 일정 정보입니다. 목록 페이지에서는 사용자가 빠르게 비교할 수 있도록 대략적인 가격과 목적지 정도만 보여도 충분한 경우가 많습니다. 하지만 상세 페이지로 들어오면 사용자는 “이 상품을 선택해도 되는지”를 판단해야 하므로, 옵션 선택에 따라 가격이 어떻게 달라지는지 명확하게 확인하고 싶어합니다.
또한 여행 상품은 일정 자체가 구매 결정의 핵심이 되기 때문에, 1일 차에는 무엇을 하고 2일 차에는 무엇을 하는지처럼 일정 정보가 구체적으로 읽히는 구조가 필요합니다. 결국 상세 화면의 레이아웃은 ‘이미 본 정보’를 확장하기보다는 ‘상세에서만 해결되는 판단’을 중심으로 설계되어야 하며, 이를 위해서는 화면을 바로 그리기 전에 사용자 흐름을 기준으로 구상하는 단계가 선행되어야 한다는 논리로 이어집니다.
사례 2. 주문서 페이지
주문서 페이지는 성격이 더 분명합니다. 이 화면에서 중요한 것은 사용자가 정보를 쉽게 입력할 수 있어야 한다는 점, 장바구니 정보(주문 대상)를 한 번 더 확인할 수 있어야 한다는 점, 그리고 할인 혜택 정보가 명확하게 표시되어야 한다는 점입니다.
주문서 화면은 사용자가 입력을 하면서 동시에 결제 직전의 불안을 해소하는 단계이기도 합니다. 그래서 입력란의 구조가 복잡하거나, 주문 정보 확인이 어렵거나, 할인 적용 방식이 불명확하면 사용자는 쉽게 망설이게 됩니다. 따라서 주문서 레이아웃은 “입력 → 확인 → 혜택 확인 → 최종 결정”이라는 흐름이 자연스럽게 이어지도록 논리적으로 연결되어야 하고, 그 연결이 보이도록 설계 단계에서 먼저 사용자 이동 흐름을 파악하는 접근이 필요합니다.
작성 Step 2. UX 세부 설계는 흐름이다.
UX의 미시적인 설계는 한 화면 안에서도 단계가 갈리는 경우가 많습니다. 겉보기에는 하나의 기능이지만, 사용자의 행동에 따라 화면 상태가 변하면서 여러 단계가 연속적으로 발생합니다. 그래서 UX 세부 설계는 ‘정지된 화면’이 아니라 ‘흐름’으로 다뤄야 한다는 말이 성립합니다.
사례 1. 검색 창 설계
검색 창은 대표적으로 단계가 나뉘는 기능입니다. 사용자가 검색창을 클릭하는 순간, 입력에 집중할 수 있도록 화면 상태가 달라지고 검색창이 열리며, 자동 추천 검색어가 함께 나타납니다. 이후 사용자가 검색어를 입력하면 추천 리스트가 그 입력에 맞춰 바뀌고, 입력을 확정하면 결과 화면으로 전환되면서 화면 구성이 다시 달라집니다.
이런 단계 변화가 화면설계서에 충분히 담기지 않으면, 구현 결과가 단순히 “검색창 하나”로만 처리되어 사용자 입장에서 딱딱하게 느껴질 수 있습니다. 따라서 검색은 “검색 결과 화면”만 설계하는 것이 아니라, 클릭 이후의 상태 변화와 추천 노출, 결과 전환까지 이어지는 흐름을 설계서에서 설명해 두는 방식이 더 자연스럽습니다.
사례 2. 장바구니 설계
장바구니 담기도 마찬가지입니다. 장바구니에 담는다는 기능 자체는 동일해 보이지만, 실제 서비스에서는 동작 방식이 다르게 설계될 수 있습니다. 마켓컬리처럼 담는 순간 “슉”하고 당겨지는 인터랙션을 주는 경우도 있고, 어떤 쇼핑몰은 담자마자 장바구니 화면으로 이동시키기도 하며, 또 다른 서비스는 “장바구니에 추가하시겠습니까?” 같은 팝업 메시지로 확인 절차를 추가하기도 합니다.
같은 기능이라도 이런 디테일 차이가 사용자가 느끼는 경험을 바꿉니다. 그래서 “장바구니 담기”를 단순 기능으로만 적어두기보다, 어떤 방식으로 피드백을 줄지, 사용자의 흐름이 어디로 이어질지를 설계 단계에서 정리하는 것이 사용자 경험의 질을 결정한다는 논리로 연결됩니다.
작성 Step 3. 나만의 컴포넌트 라이브러리를 만들자
화면 설계의 일관성을 유지하려면, 자주 쓰는 UI 요소를 컴포넌트 단위로 정리해 두는 방식이 중요합니다. 컴포넌트는 버튼, 입력창, 체크박스 같은 UI 요소를 의미하며, 이를 체계적으로 정의해 두면 화면 간 일관성을 유지하기 쉬워집니다.
특히 팀 작업에서는 각 설계자가 자기 방식대로 요소를 만들기 시작하면 화면마다 스타일과 규칙이 달라져 통일감이 깨질 수 있습니다. 그래서 리더(PL)가 표준 컴포넌트 라이브러리를 제공하는 형태가 이상적이라는 맥락이 이어지고, 표준화가 되면 설계 속도도 빨라지고 변경 대응도 훨씬 유연해집니다. 설계서에서 자주 등장하는 컴포넌트로는 단일 선택을 위한 라디오 버튼, 다중 선택을 위한 체크박스, 플러스/마이너스나 위/아래 이동 같은 아이콘 버튼, 입력 필드와 그 안의 힌트 텍스트(placeholder), 탭 가이드, 텍스트 노출 영역, 날짜 선택 UI, 파일 업로드, 드롭다운 리스트, 페이지네이션, 검색 조건 프리셋 UI, 툴팁 또는 가이드 버튼 등이 있습니다.
이 요소들은 화면마다 반복적으로 등장하기 때문에, 한 번 정의해두고 재사용할 수 있는 형태로 관리되는 편이 설계의 효율성과 안정성을 동시에 높여줍니다. 특히 날짜 선택처럼 OS, 모바일/PC 환경에 따라 형태가 달라질 수 있는 요소는, 디테일을 설계 단계에서 미리 고려해두어야 구현에서 혼선이 줄어듭니다.
버튼의 규칙과 CTA의 위계
버튼은 겉으로는 단순하지만, 화면의 의도를 가장 직접적으로 드러내는 요소이기 때문에 규칙이 필요합니다. 예를 들어 긍정 버튼을 좌측에 둘지 우측에 둘지 같은 기본 원칙이 먼저 정해져야 화면마다 선택 구조가 달라지지 않습니다.
또한 액션 버튼 중에서도 가장 중요한 행동을 유도하는 CTA(Call To Action)는 가장 눈에 띄어야 합니다. 크기나 명도 같은 시각적 힘을 더 주고, 나머지 버튼은 그보다 한 단계 낮은 위계를 가져가면 사용자가 무엇을 먼저 눌러야 하는지 자연스럽게 이해할 수 있습니다. 결국 화면에서 가장 기획 의도가 잘 드러나야 하는 것이 무엇인지가 눈에 띄는 구조로 정리되어야 한다는 결론으로 이어집니다.
테이블 작성에서 필요한 기본 규칙
테이블은 숫자와 금액이 동일한 방식으로 보이면 안 됩니다. 금액은 우측 정렬로 콤마가 찍혀야 읽기 편하고, 일반 숫자는 중앙 정렬이 더 자연스러운 경우가 있습니다. 문장처럼 읽히는 텍스트는 좌측 정렬이 기본이 되고, 단순한 짧은 텍스트는 중앙 정렬로 처리되는 경우도 있습니다. 이런 정렬 규칙이 먼저 잡혀 있으면 테이블이 많아져도 문서 전체의 통일성이 유지됩니다.
또한 테이블이 이어지는 경우에는 화살표를 이용해 “테이블이 연결된다”는 구조를 보여주는 방식이 사용됩니다. 반복되는 테이블이 많을수록 동일 패턴을 어떻게 표시할지도 규칙으로 잡아야 하고, 링크 텍스트는 언더바 등으로 링크임을 표시해 두는 방식이 일반적입니다. 링크가 서로 다른 목적지로 연결될 수 있는 경우가 있기 때문에, 링크 표기 규칙을 통일해 두는 것이 혼선을 줄입니다.
변경 히스토리와 피드백 창 구분
설계서에는 변경 히스토리 관리 방식이 함께 포함될 수 있습니다. 변경 기록이 없으면 최신 버전을 공유했더라도 다른 버전을 보고 작업하는 상황이 생기기 쉽고, 어떤 부분이 바뀌었는지 확인이 어렵기 때문에 실수와 커뮤니케이션 비용이 증가합니다.
피드백 창 역시 유형이 구분되어야 합니다. 컨펌창, 얼럿창, 시스템 팝업, 레이어 팝업처럼 상황에 따라 사용자에게 요구되는 행동이 다르기 때문에, 동일한 “안내”라도 어떤 형태로 노출될지를 설계 단계에서 분리해 두는 방식이 자연스럽습니다.
설계 도구를 활용하는 방향
실무에서는 PPT 기반 설계가 일반적이지만, 파워목업(PowerMockup)처럼 파워포인트 안에서 UI 컴포넌트를 바로 배치할 수 있는 도구를 활용하면 효율을 높일 수 있습니다. 탭, 드롭다운, 버튼 같은 요소를 도형처럼 빠르게 배치할 수 있기 때문에 PPT 기반 설계에 특히 유용합니다. 피그마는 무료 컴포넌트가 다양하게 제공되어 UI 재사용성이 높고, 디자인 팀과 협업할 때 효과적이라는 장점이 있습니다.