화면설계 (4) - Description

디스크립션은 설계를 구현 가능한 언어로 번역하는 작업이다

디스크립션은 단순한 보충 설명이 아니라, 설계를 구현 가능한 언어로 번역하는 작업입니다. 화면 설계서에 보이는 UI는 결과물의 형태에 불과하며, 실제 구현 단계에서는 그 안에 담긴 조건, 기준, 변화, 예외 상황까지 모두 명확하게 정의되어 있어야 합니다. 이 정의가 빠지면 개발자는 화면을 ‘추측’으로 구현하게 되고, 그 순간부터 품질의 일관성은 흔들리기 시작합니다. 설계 문서에서 디스크립션은 설계자의 의도를 구체적인 실행 기준으로 바꾸는 영역입니다. 즉, “어떻게 보여야 하는가”를 넘어서 “어떻게 동작해야 하는가”를 규정하는 문장입니다. 이 문장이 부족하면 구현은 어렵고, 해석은 분산되며, 결과는 달라집니다. 그렇기 때문에 디스크립션은 선택이 아니라 필수입니다.

예를 들어 주문 목록 화면에서 기본 정렬이 주문일 순이라고 가정해 보겠습니다. 하지만 사용자가 인기순이나 신청순으로도 정렬할 수 있어야 한다는 요구사항이 명확히 설명되어 있지 않다면, 개발자는 기본값만 구현하거나 임의의 정렬 기준을 추가할 수 있습니다. 이처럼 한 줄의 설명 유무가 기능의 범위를 결정합니다.

결국 디스크립션은 구현 난이도를 낮추는 문장이 아니라, 구현 방향을 고정시키는 기준입니다. 설계가 명확할수록 개발은 단순해지고, 설명이 부족할수록 구현은 복잡해집니다.

 

요소와 속성의 정의는 누락을 방지하는 기준이다

디스크립션에서 가장 먼저 정의해야 할 것은 요소와 속성입니다.
요소는 화면을 구성하는 개별 항목을 의미하고, 속성은 해당 요소가 가질 수 있는 값이나 상태를 의미합니다. 요소와 속성을 명확히 구분하여 정의하지 않으면, 구현 범위가 모호해지고 기능이 일부만 반영되는 문제가 발생합니다.

요소는 예를 들어 주문 상태, 기간 조회, 회원 구분과 같은 항목 자체를 의미합니다. 그리고 속성은 그 항목이 가질 수 있는 값입니다. 주문 상태라면 “결제 대기”, “결제 완료”, “배송 중”이 속성이 됩니다. 기간 조회라면 “주문일”과 “출고일”이 선택 가능한 값으로 정의되어야 합니다. 회원 구분이라면 “일반 회원”, “VIP 회원”이 속성입니다.

이처럼 요소와 속성을 함께 명확히 서술해야 합니다. 단순히 “주문 상태가 있다”고 쓰는 것은 부족합니다. 어떤 상태 값이 존재하는지까지 정의해야 구현이 완결됩니다. 정리하면, 요소는 화면의 구조를 정의하고, 속성은 그 구조 안에서 가능한 범위를 확정합니다. 이 두 가지가 빠지면 기능은 축소되거나 왜곡됩니다.

 

변화 정의는 인터랙션을 설계하는 작업이다

사용자의 행동에 따라 화면이 어떻게 변하는지 정의하는 작업 역시 디스크립션의 핵심입니다. 변화는 단순한 버튼 클릭만을 의미하지 않습니다. 레이아웃 변화, 기능적 변화, 데이터 변경까지 모두 포함됩니다. 사용자가 검색 버튼을 누르면 입력된 값에 따라 결과 목록이 업데이트되어야 합니다. 초기화 버튼을 누르면 모든 입력값이 기본값으로 되돌아가야 합니다. 엑셀 다운로드 버튼을 누르면 현재 화면에 보이는 데이터가 엑셀 파일로 변환되어 다운로드되어야 합니다. 이러한 변화는 설계자가 당연하다고 생각할 수 있지만, 문서에 정의되어 있지 않으면 구현은 달라질 수 있습니다. 모바일 환경에서는 고려해야 할 변화가 더 많습니다. 터치, 더블 탭, 롱 프레스, 스와이프와 같은 제스처가 추가되기 때문입니다. 따라서 인터랙션이 발생하는 모든 지점은 정의되어야 합니다.

결국 변화 정의는 “어떤 행동이 발생했을 때 무엇이 달라지는가”를 명확히 규정하는 작업입니다. 이것이 명확할수록 구현은 예측 가능해집니다.

 

피드백 정의는 사용자의 실수를 예방하는 장치다

사용자의 행동에 대한 시스템의 반응을 정의하는 것 역시 필수입니다. 피드백은 크게 알럿과 컨펌으로 구분됩니다.

알럿은 단순한 안내 메시지입니다. 예를 들어 “이 작업을 실행할 수 없습니다.”와 같은 문구가 이에 해당합니다. 컨펌은 사용자에게 선택을 요구하는 메시지입니다. “정말 삭제하시겠습니까?”와 같이 예 또는 아니오를 요구하는 형태입니다. 삭제 버튼을 클릭했을 때 컨펌 창이 표시되어야 하는지, 비밀번호 입력이 틀렸을 때 어떤 문구가 출력되어야 하는지까지 명확히 정의해야 합니다. 예를 들어 “쿠폰이 리스트에서 삭제되고 고객에게 발급된 쿠폰은 유지됩니다. 선택된 데이터를 삭제하시겠습니까?”라는 컨펌 문구와, 삭제 완료 후 “정상적으로 삭제되었습니다.”라는 토스트 메시지까지 정의해 두면 재사용성과 일관성이 높아집니다.

UI로만 설명하는 방식은 채널에 따라 달라질 수 있습니다. 모바일과 PC는 표현 방식이 다를 수 있기 때문입니다. 따라서 문서에는 텍스트로 명확히 정의하고, 채널별 표현 방식은 별도로 관리하는 것이 효율적입니다. 피드백이 명확히 정의되면 사용자의 실수는 줄어들고, 경험의 일관성은 높아집니다.

 

링크와 이동 경로는 화면 아이디로 정의해야 한다

특정 버튼 클릭 시 이동하는 페이지는 화면명으로 기재하는 것보다 화면 아이디로 명확히 정의하는 것이 좋습니다. 화면명은 유사 명칭이 존재할 수 있어 혼동의 여지가 있습니다. 예를 들어 “선택 시, 수기 발급 팝업 호출(GN-5.3.4.1.2)”과 같이 정보 구조화 단계에서 정의한 화면 아이디를 함께 기재하면, 구현자는 정확한 화면을 호출할 수 있습니다. 이동 경로를 구체적으로 정의하는 것은 개발자의 혼동을 줄이는 기본 작업입니다.

 

설명에 포함할 세 가지 - 요소/속성 정의, 인터렉션, 사용자 피드백

설명란에는 반드시 세 가지가 포함되어야 합니다. 첫째는 요소와 속성 정의입니다. 화면을 구성하는 각 항목이 무엇이며, 그 항목이 어떤 값을 가질 수 있는지까지 명확히 규정해야 합니다. 단순히 항목의 존재만 언급하는 것으로는 부족합니다. 가능한 값과 범위까지 함께 정의해야 구현 범위가 확정됩니다.

둘째는 인터랙션에 따른 변화 정의입니다. 사용자의 클릭, 선택, 입력과 같은 행위가 발생했을 때 화면과 데이터가 어떻게 달라지는지 서술해야 합니다. 변화는 단순한 버튼 동작을 넘어서 레이아웃의 변화, 데이터 갱신, 상태 전환까지 포함합니다. 이 부분이 빠지면 개발자는 화면을 정적인 구조로만 이해하게 되고, 실제 동작은 설계 의도와 달라질 수 있습니다.

셋째는 사용자 피드백 정의입니다. 알럿과 컨펌을 포함하여 사용자의 행동에 대해 시스템이 어떤 메시지로 응답하는지 명확히 기재해야 합니다. 특히 삭제, 수정, 오류 상황과 같이 사용자의 실수 가능성이 있는 지점에서는 피드백 정의가 더욱 중요합니다. 메시지 문구와 발생 조건이 명확할수록 사용자 경험은 안정됩니다.이 세 가지가 빠지면 설계는 완성된 문서가 아닙니다.

화면이 아무리 잘 그려져 있어도, 요소의 범위와 변화의 기준, 피드백의 조건이 정의되지 않으면 구현은 해석에 의존하게 됩니다. 해석에 의존하는 순간, 결과물은 사람마다 달라질 수밖에 없습니다.추가적으로 해상도, 이미지 사이즈, 관리자에서 관리되는 위치와 같은 운영 관점의 정보까지 기재하면 문서는 설계 단계를 넘어 운영 단계까지 고려한 기준 문서가 됩니다. 이는 단순히 구현을 위한 문서를 넘어, 유지보수와 확장을 위한 기준이 됩니다.

설명은 길어지는 것이 문제가 아닙니다. 모호해지는 것이 문제입니다. “이 정도면 알겠지”라는 전제가 들어가는 순간, 문서는 설계자의 머릿속에서만 완성된 상태로 남게 됩니다. 그러나 문서는 타인이 이해하고 실행하기 위한 도구입니다. 이해를 전제로 쓰는 것이 아니라, 오해를 방지하기 위해 써야 합니다.결론적으로 디스크립션은 설계자의 의도를 고정하는 문장입니다. 요소를 정의하고, 변화를 규정하고, 피드백을 명시하면 구현의 방향은 하나로 수렴합니다. 설계 문서는 시각 자료로 시작할 수 있지만, 최종적으로 완성하는 것은 설명입니다. 그림이 방향을 보여준다면, 설명은 그 방향을 확정합니다.