기획서가 '틀리진 않았는데 뭔가 빠진' 느낌일 때 디자이너가 먼저 할 일

헤드라인

기획서가 "틀렸다"면 오히려 쉬워요. 문제를 짚어서 되돌려보내면 되니까요. 진짜 피로를 만드는 건 "틀리진 않았는데 바로 디자인하기엔 애매한 상태"예요. 요구사항 정리되어 있고, 기능 목록도 있고, 대략적인 사용자 흐름도 적혀 있어요. 얼핏 보면 시작해도 될 것 같아요. 근데 막상 화면으로 옮기려 하면 어딘가 계속 빈 느낌이 들거든요. 단계가 하나 빠진 것 같고, 예외 상황이 누락된 것 같고, 이 버튼이 왜 여기 있어야 하는지 설명이 안 되고.

이때 디자이너는 둘 중 하나를 택해요. 일단 화면을 그리면서 맞춰보거나, 기획이 더 정리되길 기다리거나. 근데 현실에서 기다림은 선택지가 아니에요. 일정은 이미 시작됐고, 누군가는 일단 시안이라도 요구하거든요. 그래서 자연스럽게 화면을 먼저 그리게 돼요.

문제는 이 선택이 이후의 수정 비용을 기하급수적으로 키운다는 거예요.

애매함에도 종류가 있다 — 세 가지를 구분하지 않으면 전부 디자인의 짐이 된다

기획이 애매할 때 디자이너가 먼저 해야 할 일은 기획을 대신 쓰는 게 아니에요. 화면을 그리는 것도 아니고요. 애매함의 종류를 분리하는 일이에요.

첫째, 정보가 부족한 경우. "회원 등급에 따라 다르게 노출"이라고만 적혀 있고, 등급 기준이 정의되지 않았다면 그건 디자인 문제가 아니라 데이터 정의 문제예요. 이때 해야 할 건 화면을 상상하는 게 아니라 질문을 정리하는 거예요. "회원 등급은 어떻게 나뉘나요?", "등급에 따라 레이아웃이 달라지나요, 아니면 문구와 콘텐츠만 달라지나요?" — 이런 질문들.

둘째, 우선순위가 정해지지 않은 경우. 이 기능이 필수인지 선택인지, 이 화면이 한 번에 끝나는지 여러 단계를 거치는지, 이 버튼이 메인 액션인지 보조인지가 명확하지 않으면 UI는 계속 흔들려요. 정보의 문제가 아니라 결정의 문제.

셋째, 역할 경계가 불명확한 경우. 에러 메시지는 누가 정의하는지, 비정상 흐름은 어디까지 디자인에서 커버하는지, 정책 문구는 누가 책임지는지. 이건 기획 문서가 아무리 길어도 해결되지 않아요. 팀의 역할 구조와 연결돼 있거든요. 혼자 끌어안고 있지 말아야 해요. 끌어안고 있는 동안 시간은 흐르고, 팀의 비용은 낭비되고, 그 시간을 낭비시킨 만큼 디자이너의 역량도 저평가돼요.

이 세 가지를 구분하지 않으면? 모든 애매함이 디자인에서 해결해야 할 문제로 떠안겨요. 그 결과는 반복 수정과 피로. 디자이너가 나서서 "이 부분이 애매합니다"라고 이야기하지 않았던 나비효과가, 결국 추가 업무로, 또는 "디자이너가 제대로 하지 못했다"는 책임으로 돌아와요.

화면보다 '상태'를 먼저 펼쳐라

기획이 애매할수록 디자이너는 UI보다 상태를 먼저 정리해야 해요. 사용자가 어떤 행동을 하고, 어떤 조건에 처해 있는지에 따라 디자인이 달라지는 부분들. 구체적으로는 이런 거예요.

이 다섯 가지만 적어봐도 기획의 빈칸이 보여요. 대부분의 애매함은 여기서 나와요. 정상 흐름만 정의된 기획은 실제 서비스가 아니에요.

상태가 정리되지 않은 채 UI로 들어가면, 수정은 구조적으로 반복돼요. 상태가 추가될 때마다 화면이 늘어나고, 컴포넌트가 복잡해지고, 변형이 쌓이고. 기획이 애매한 게 아니라, 상태 정의가 빠진 거예요. (근데 이걸 "기획이 애매하다"고 느끼는 디자이너가 많다는 게 아이러니죠.)

"지금 안 정하면 비용이 10배 되는 것"과 "나중에 바꿔도 되는 것"

모든 애매함을 지금 해결할 필요는 없어요. 중요한 건 우선순위.

디자이너들이 자주 매몰되는 게 스타일이나 콘텐츠 자체거든요. 근데 색상이나 문구는 나중에 바꿀 수 있어요. 일러스트나 로티 같은 그래픽 요소도 갈아끼울 수 있고요. 반면에 플로우 단계 수나 데이터 구조는 나중에 바꾸기 어려워요. 지금 정하지 않으면 수정 비용이 기하급수적으로 늘어나는 것과, 나중에 충분히 바꿔도 되는 것. 이 판단이 없으면 디자이너는 계속 "화면을 고치는 사람"으로 남아요.

솔직한 이야기 하나 하면요. 화면을 고치는 일이 반복될수록, "믿고 맡길 수 있는 디자이너"라고 생각하는 사람들은 점점 줄어들어요. 수정이 발생하는 건 자연스러운 일이지만, 수정이 왜 발생하는지를 먼저 이해하고 그 앞단계를 공략해야 해요. 구조를 먼저 잡아야 수정이 줄어드는 거예요.

오퍼레이터가 되지 마세요.

빈칸을 채우지 말고, 빈칸을 보여줘라

많은 디자이너가 애매한 기획을 보면 의미 없는 더미 데이터로 채워 넣어요. 사용자 입장에서 더 나아 보이는 방향으로 흐름을 고치고, 부족한 부분을 보완하고. 이게 능력처럼 보이잖아요? 근데 실무에선 리스크가 돼요.

"왜 이렇게 정했나요?" 질문이 돌아왔을 때, 근거가 없으면 모든 책임이 디자인으로 돌아와요. 기획에서 누락된 부분을 디자이너가 챙겼는데, 오히려 디자인에서 문제가 발생한다고 보이게 되는 거죠.

이때 해야 할 일은 내가 임의로 채우는 게 아니라 빈칸을 드러내는 거예요. "이 부분은 현재 정의되지 않았습니다", "이 상태는 추가 논의가 필요합니다"라고 명확히 남겨두는 것이 더 안전해요. 기획을 책임지는 사람이 있다면, 빠져 있다는 상황 자체를 빠르게 공유해서 판을 만드는 게 더 솜씨 좋은 디자이너고, 현명하게 내 업무 영역을 지키면서 일하는 방법이에요.

피로를 만드는 건 일이 많아서가 아니라, 같은 일을 반복하는 것

기획이 완벽한 상태에서 디자인을 시작하는 경우는 거의 없어요. 애매함은 늘 남아 있고, 빈칸은 어느 정도 존재하죠. 근데 그 애매함을 그대로 둔 채 UI로 먼저 들어갈지, 아니면 구조를 한 번 더 정리하고 갈지는 선택할 수 있어요. 겉으로 보기엔 둘 다 비슷해 보이지만, 시간이 지나면 결과는 확실히 갈려요.

애매함을 안고 바로 화면을 그리면, 디자인은 빠르게 나와요. 대신 수정이 잦아지고, 논의는 반복되고, 같은 질문이 다른 형태로 계속 돌아오고. 반대로 화면을 조금 늦추더라도 구조를 먼저 분리하면, 초반 속도는 느려질 수 있지만 이후의 수정은 줄어들어요. 뭐가 확정이고 뭐가 보류인지 명확해지니까요.

실무에서 피로를 만드는 건 일이 많아서가 아니에요. 같은 일을 여러 번 반복하는 상황. 기준 없이 그린 화면은 계속 다시 그려지고, 정의 안 된 상태는 다른 장면에서 계속 문제를 만들어요. 그때마다 "왜 이렇게 자꾸 바뀌지?" 라고 느끼지만, 대부분은 변경이 많아서가 아니라 처음에 정리되지 않은 채로 시작했기 때문이에요.

결국 애매함을 다루는 방식이 디자이너의 피로를 좌우해요. 기획이 완벽해질 때까지 기다릴 순 없지만, 최소한 구조를 나누고 빈칸을 표시한 채로 시작할 수는 있잖아요. 이 작은 차이가 반복을 줄이고, 책임의 경계를 분명히 하고, 수정의 방향을 좁혀요. 그리고 그 차이는 결국 감당해야 할 피로의 크기로 돌아오고요.