애매하다고 디자이너가 다 하는 건 어리석인 짓이다
실무에서 가장 흔하면서도 피로를 크게 만드는 상황은 기획서가 '틀리진 않았는데 바로 디자인하기엔 애매한 상태'일 때다. 요구사항은 정리되어 있고, 기능 목록도 있고, 대략적인 사용자 흐름도 적혀 있다. 얼핏 보면 시작해도 될 것 같다. 그런데 막상 화면으로 옮기려 하면 어딘가 계속 비어 있는 느낌이 든다. 단계가 하나 빠진 것 같고, 예외 상황이 빠진 것 같고, 이 버튼이 왜 여기 있어야 하는지 설명이 잘 되지 않는다.
이때 많은 디자이너는 두 가지 반응을 보인다. 일단 화면을 그리면서 맞춰보거나, 아니면 기획이 더 정리되길 기다리거나. 하지만 현실에서 기다림은 선택지가 아니다. 일정은 이미 시작됐고, 누군가는 일단 시안이라도 요구한다. 그래서 자연스럽게 화면을 먼저 그리게 된다. 문제는 이 선택이 이후의 수정 비용을 빠르게 키운다는 데 있다. 그렇다면 디자이너는 그려야 할까, 그리지 말아야 할까.
기획이 애매한 상태에서 UI를 얹으면, 화면은 나오지만 구조는 계속 흔들린다. 수정이 반복되고, 요구가 추가되고, 화면 수는 늘어나지만 기준은 정리되지 않는다. 결국 디자이너는 왜 자꾸 바뀌는지 모르겠는 상태에 들어간다. 이건 디자인 실력이 부족해서가 아니라, 애초에 구조가 확정되지 않았기 때문이다.
기획서가 애매할 때 디자이너가 먼저 해야 할 일은 기획을 대신 쓰는 게 아니다. 화면을 그리는 것도 아니다. 애매함의 종류를 분리하는 일이다. 화면을 최소화해서 그려나가며(우린 이때 와이어프레임을 활용해볼 수 있다) 채워넣어야 하는 건 어떤 것들이 있는지 확인하고, 빠르게 팀에 상황을 공유해야 한다. 기획서가 불안할 때, 디자이너가 어떤 식으로 진행해야 하는지에 대한 일반적인 방법을 소개한다.
애매함은 막연해 보이지만, 실제로는 몇 가지 유형으로 나눌 수 있다.
첫째, 정보가 부족한 경우다. 예를 들어 '회원 등급에 따라 다르게 노출'이라고만 적혀 있고, 등급 기준이 정의되지 않았다면 그건 디자인 문제가 아니라 데이터 정의 문제다. 이 경우 디자이너가 할 일은 화면을 상상하는 게 아니라, 질문을 명확하게 정리하는 것이다. 이런 질문들을 해볼 수가 있을 것이다.
- 회원 등급은 어떻게 나뉘나요?
- 회원 등급에 따라 화면이 달라질 때, 어떤 것들이 다르게 노출되나요?
- 회원 등급에 따라 화면이 달라질 때, 레이아웃은 동일하고 문구와 콘텐츠만 달라지나요?
둘째, 우선순위가 정해지지 않은 경우다. 이 기능이 필수인지 선택인지, 이 화면이 한 번에 끝나는지 여러 단계를 거치는지, 이 버튼이 메인 액션인지 보조인지가 명확하지 않으면 UI는 계속 흔들린다. 이건 정보의 문제가 아니라 결정의 문제다.
- 이 화면에서 사용자가 반드시 해야 하는 핵심 행동은 어떤 걸까요?
- 여기서 사용자가 이 기능을 선택하지 않으면 어떤 일이 발생하나요?
셋째, 역할 경계가 불명확한 경우다. 에러 메시지는 누가 정의하는지, 비정상 흐름은 어디까지 디자인에서 커버하는지, 정책 문구는 누가 책임지는지 같은 문제다. 이건 기획 문서가 아무리 길어도 해결되지 않는다. 팀의 역할 구조와 연결돼 있기 때문이다. 이런 경우엔 반드시 기획으로 되돌려보내면서, 논의의 장을 열어야 한다. 혼자 끌어안고 있지 말자. 끌어안고 있는 동안 시간은 흐르고, 팀의 비용은 낭비되고, 그 시간을 낭비시킨 만큼 디자이너의 역량 역시 저평가된다.
이 세 가지를 구분하지 않으면, 디자이너는 모든 애매함을 디자인에서 해결해야 할 문제로 떠안게 된다. 그 결과는 반복 수정과 피로로 돌아오게 된다. 디자이너가 나서서 '이 부분이 애매합니다' 라고 이야기하지 않았던 나비효과는, 결국 디자이너 스스로에게 다시 부메랑처럼 추가 업무로, 또는 디자이너가 제대로 하지 못했다는 책임으로 돌아오게 된다.
기획이 애매할수록 디자이너는 UI보다 상태를 먼저 정리해야 한다. 특히 상태에 따른 UI 및 화면 분기다. 쉽게 말해, 사용자가 어떤 행동을 하고, 어떤 조건에 처해 있는지에 따라 디자인이 달라지는 부분들이 있는지를 파악해야 한다는 것이다. 예를 들면 이런 것들이다.
정상 흐름(해피패스)
실패 흐름(에러케이스)
데이터 없음(데드엔드)
네트워크 오류
권한 제한
이 다섯 가지만 적어봐도, 기획의 빈칸이 드러난다. 대부분의 애매함은 이 상태 분기에서 나온다. 정상 흐름만 정의된 기획은 실제 서비스가 아니다. 디자이너가 화면을 그리기 전에 상태를 먼저 나누면, 어디까지가 정의되지 않았는지 명확해진다. 상태가 정리되지 않은 채 UI로 들어가면, 수정은 구조적으로 반복된다. 상태가 추가될 때마다 화면이 늘어나고, 컴포넌트가 복잡해지고, 변형이 쌓인다. 기획이 애매한 게 아니라, 상태 정의가 빠진 것이다.
모든 애매함을 지금 해결할 필요는 없다. 중요한 건 우선순위다. 흔히 디자이너들은 스타일이나 컨텐츠 자체에 매몰되는 경향이 크다. 하지만 색상이나 문구는 나중에 바꿀 수 있다. 일러스트나 로띠같은 그래픽 요소도 갈아끼울 수 있다. 하지만, 플로우 단계 수나 데이터 구조는 나중에 바꾸기 어렵다. 지금 정하지 않으면 수정 비용이 기하급수적으로 늘어나는 것과, 나중에 충분히 바꿔도 되는 것을 구분해야 한다.
이 판단이 없으면 디자이너는 계속 화면을 고치는 사람으로 남는다. 그리고, 화면을 고치는 일이 반복될 수록 믿고 맡길 수 있는 디자이너라고 생각하는 사람들은 점점 줄어들 것이다. 수정이 발생하는 건 자연스러운 일이지만, 수정이 왜 발생하는지에 대해서 먼저 이해하고 빠르게 그 앞단계를 먼저 공격해야 한다. 구조를 먼저 잡아야 수정이 줄어든다. 기획이 애매할수록 더 구조적으로 접근해야 하는 이유다. 디자이너들이여, 오퍼레이터가 되지 말자.
많은 디자이너가 애매한 기획을 보면 의미없는 더미 데이터로 채워 넣는 경우가 많다. 사용자 입장에서 더 나아 보이는 방향으로 흐름을 고치고, 부족한 부분을 보완하는 것이다. 이건 능력처럼 보이지만, 실무에선 리스크가 될 수 있다.
“왜 이렇게 정했나요?”라는 질문이 돌아왔을 때, 근거가 남아 있지 않으면 모든 책임이 디자인으로 돌아온다. 기획에서 누락된 부분을 디자이너가 챙겼는데, 오히려 디자인에서 문제가 발생한다고 보이게 된다. 디자이너들은 현명하게 일해야 한다. 이때 해야 할 일은 내가 임의로 채우는 것이 아니라, 빈칸을 드러내는 것이다. “이 부분은 현재 정의되지 않았습니다”, “이 상태는 추가 논의가 필요합니다”라고 명확히 남겨두는 것이 더 안전하다.
기획이 애매한 상황에서 디자이너의 역할은 기획을 대신하는 것이 아니라, 구조를 명확히 드러내는 것이다. 그 작업이 선행되지 않으면, 디자인은 계속 흔들린다. 기획을 책임지는 사람이 있다면, 해당 부분이 빠져 있다고 내가 날름 채워넣는 것이 아니라 빠져있다는 상황 자체를 빠르게 공유해서 어떻게 할 지 정하는 판을 만드는 것이 더 솜씨 좋은 디자이너고, 그게 현명하게 내 업무 영역 지키면서 일하는 방법이다.
기획이 완벽한 상태에서 디자인을 시작하는 경우는 거의 없다. 애매함은 늘 남아 있고, 빈칸은 어느 정도 존재한다. 하지만 그 애매함을 그대로 둔 채 UI로 먼저 들어갈지, 아니면 구조를 한 번 더 정리하고 갈지는 선택할 수 있다. 겉으로 보기엔 둘 다 비슷해 보이지만, 시간이 지나면 결과는 분명히 갈린다.
애매함을 안고 바로 화면을 그리면, 디자인은 빠르게 나온다. 대신 수정이 잦아지고, 논의는 반복되고, 같은 질문이 다른 형태로 계속 등장한다. 반대로 화면을 조금 늦추더라도 구조를 먼저 분리하면, 초반 속도는 느려질 수 있지만 이후의 수정은 줄어든다. 무엇이 확정되었고 무엇이 보류되었는지가 명확해지기 때문이다.
실무에서 피로를 만드는 건 일이 많아서라기보다, 같은 일을 여러 번 반복하는 상황이다. 기준이 없는 상태에서 그린 화면은 계속해서 다시 그려지고, 정의되지 않은 상태는 계속해서 다른 장면에서 문제를 만든다. 그때마다 디자이너는 “왜 이렇게 자꾸 바뀌지?”라고 느낀다. 하지만 대부분의 경우 문제는 변경이 많아서가 아니라, 처음에 정리되지 않은 채로 시작했기 때문이다.
결국 애매함을 다루는 방식이 디자이너의 피로를 좌우한다. 기획이 완벽해질 때까지 기다릴 수는 없지만, 최소한 구조를 나누고 빈칸을 명확히 표시한 채로 시작할 수는 있다. 그 작은 차이가 이후의 반복을 줄이고, 책임의 경계를 분명히 하고, 수정의 방향을 좁힌다. 실무는 완벽한 기획 위에서 돌아가지 않는다. 대신 애매함을 어떻게 다루느냐에 따라 효율이 달라진다. 그리고 그 차이는 결국 디자이너가 감당해야 할 피로의 크기로 돌아온다.