디자인 업무를 하다 보면 이상하게 반복되는 순간이 있습니다.

분명 지난 회의에서 이야기했습니다. 피그마에도 코멘트를 남겼고, 슬랙에도 관련 대화가 있습니다. 노션 어딘가에는 정리된 문서도 있을지 모릅니다.

그런데 며칠이 지나면 다시 같은 질문을 받습니다.

“이 화면은 왜 이렇게 구성했나요?”
“이 방향으로 가기로 한 이유가 뭐였죠?”
“지난번에는 어떤 기준으로 이 안을 선택했나요?”
“지금 이 작업은 어디까지 이야기된 상태인가요?”

결국 디자이너는 다시 설명을 시작합니다. 이미 한 번 말했던 배경을 다시 꺼내고, 선택의 이유를 다시 정리합니다. 어떤 피드백이 반영됐는지, 무엇을 보류했는지, 왜 지금 이 방향이 맞다고 봤는지도 다시 연결해야 합니다.

디자인 결과물은 남아 있는데, 그 결과를 선택한 이유는 자주 다시 설명됩니다.

디자인 결과물은 보여도, 결정의 이유는 잘 보이지 않습니다

디자인은 결과물로 확인되는 일이 많습니다.

화면이 바뀌었는지, 버튼이 이동했는지, 문구가 수정됐는지, 플로우가 정리됐는지는 비교적 쉽게 볼 수 있습니다. 피그마 파일을 열면 무엇이 달라졌는지 어느 정도 확인할 수 있습니다. 하지만 그 변화가 왜 생겼는지는 바로 보이지 않습니다.

사용자 흐름 때문에 바꾼 것인지, 개발 일정 때문에 조정한 것인지, 비즈니스 우선순위가 바뀐 것인지, 이전 피드백을 반영한 것인지는 결과물만 봐서는 알기 어렵습니다. 디자인의 표면은 남지만, 그 아래에 있던 선택의 이유는 쉽게 흐려집니다. 그래서 시간이 지나면 결과물은 그대로 있는데도 다시 설명이 필요해집니다. 화면은 남아 있지만, 그 화면을 만든 배경은 다시 꺼내야 하는 상태가 됩니다.

문제는 설명 자체가 아니라, 같은 설명이 반복된다는 점입니다

디자인을 설명하는 일은 필요합니다.

디자이너는 자신의 선택을 팀이 이해할 수 있는 언어로 전달해야 합니다. 왜 이 방향이 사용자에게 더 적합한지, 어떤 기준으로 우선순위를 정했는지, 무엇을 고려했는지 설명하는 과정은 협업에서 중요합니다.

문제는 설명이 필요하다는 사실 자체가 아닙니다.

문제는 같은 설명이 여러 번 반복된다는 점입니다.

회의에서 한 번 이야기한 내용을 슬랙에서 다시 말합니다. 슬랙에서 정리한 내용을 노션에 다시 옮깁니다. 나중에는 피그마 코멘트와 회의 내용을 다시 찾아서 또 설명해야 합니다. 이 과정이 반복되면 디자이너의 에너지는 작업보다 설명을 유지하는 데 더 많이 쓰이게 됩니다.

처음에는 협업을 위한 설명이었지만, 어느 순간부터는 흩어진 맥락을 계속 복구하는 일이 됩니다.

디자이너는 결과물을 만드는 사람인 동시에 맥락을 연결하는 사람이 됩니다

팀에서 디자이너의 역할은 단순히 화면을 만드는 데서 끝나지 않습니다.

사용자 경험을 정리하고, 제품의 방향을 이해하고, 개발 가능성을 고려합니다. 때로는 팀의 의견을 조율하고, 모호한 요구사항을 구체적인 화면으로 바꿔야 합니다. 그래서 디자이너의 일에는 항상 맥락이 따라옵니다.

왜 이 화면이 필요한지, 왜 지금 이 기능이 우선인지, 왜 이 플로우가 더 자연스러운지 설명해야 합니다. 단순히 “이렇게 디자인했습니다”가 아니라 “이런 이유로 이 선택을 했습니다”까지 함께 전달해야 합니다.

그런데 이 맥락은 대부분 여러 도구에 흩어집니다.

피그마에는 시안과 코멘트가 남습니다. 슬랙에는 논의가 남습니다. 노션에는 정리된 문서가 있습니다. 회의에서는 말로 지나간 결정도 많습니다. 도구는 각각의 기록을 남기지만, 그 기록들이 자동으로 하나의 설명으로 이어지지는 않습니다.

결국 디자이너는 작업을 하는 사람인 동시에, 흩어진 맥락을 다시 연결하는 사람이 됩니다.

공유는 글을 잘 쓰는 문제가 아니라, 배경을 잃지 않는 문제입니다

디자인 공유가 어려운 이유는 문장을 못 써서만은 아닙니다.

물론 정리된 문장은 중요합니다. 팀이 빠르게 이해할 수 있도록 핵심을 전달하는 능력도 필요합니다. 하지만 공유에서 더 어려운 부분은 문장 자체보다 배경을 잃지 않는 일입니다. 어떤 피드백이 있었는지, 어떤 선택지가 있었는지, 왜 다른 안은 제외됐는지, 무엇을 기준으로 지금의 방향을 선택했는지. 이런 내용이 함께 남아야 공유가 의미 있어집니다.

단순히 “수정했습니다”라고 말하는 것과 “이런 이유로 이 방향을 선택했고, 이 부분은 다음 논의가 필요합니다”라고 말하는 것은 다릅니다. 후자는 팀이 다음 행동을 결정할 수 있게 만듭니다. 그래서 좋은 공유는 결과를 전달하는 데서 끝나지 않습니다. 다음 결정을 위한 배경을 함께 남겨야 합니다.

AI가 도와야 할 공유는 ‘문장 생성’만은 아닐 수 있습니다

AI를 활용하면 공유 문장을 더 빠르게 만들 수 있습니다.

작업 내용을 요약하고, 슬랙에 보낼 문장을 만들고, 리포트 형태로 정리하는 일은 분명 도움이 됩니다. 하지만 디자이너의 업무에서 AI가 정말 유용해지려면 단순히 그럴듯한 문장을 생성하는 데서 멈추면 안 된다고 생각합니다.

중요한 것은 설명의 배경을 이어주는 일입니다.

어떤 작업에서 출발했는지, 어떤 상태로 바뀌었는지, 어떤 결정이 있었는지, 무엇이 다음으로 이어져야 하는지를 함께 이해해야 합니다. 그래야 AI가 만든 문장도 단순한 요약이 아니라 실제 협업에 쓸 수 있는 공유가 됩니다.

디자인 업무에서 필요한 AI는 “예쁘게 말해주는 도구”보다 “왜 그렇게 말해야 하는지 알고 있는 도구”에 가까워야 한다고 생각합니다.

D:bo가 앞으로 더 보고 싶은 문제

D:bo는 지금까지 투두와 리포트를 중심으로 첫 버전을 운영했습니다.

할 일을 적고, 진행 상태를 바꾸고, 하루의 업무를 리포트로 정리하는 작은 구조에서 출발했습니다. 이 과정에서 확인한 것은 하나였습니다. 디자이너의 일은 기록되는 것만으로는 충분하지 않다는 점입니다. 기록은 다음 행동으로 이어져야 합니다. 정리된 내용은 공유로 이어져야 하고, 공유된 내용은 다음 결정의 배경으로 다시 활용될 수 있어야 합니다.

그래서 D:bo의 다음 방향에서는 “판단과 공유”를 더 중요하게 보고 있습니다.

디자이너가 매번 같은 설명을 반복하지 않아도 되도록, 작업의 배경과 선택의 이유가 자연스럽게 이어지는 구조를 만들고 싶습니다. 

하루의 시작을 남기고 하루의 흐름을 정리한다면, 그 흐름을 팀과 연결하는 역할을 해야 합니다. D:bo가 앞으로 더 잘 풀고 싶은 문제는 바로 이 지점입니다.

설명이 줄어든다는 것은 협업이 단순해진다는 뜻입니다

디자이너가 설명을 아예 하지 않아도 된다는 뜻은 아닙니다.

오히려 중요한 설명은 더 잘 남아야 합니다. 어떤 선택을 했는지, 왜 그 방향을 택했는지, 다음에는 무엇을 봐야 하는지가 더 분명하게 전달되어야 합니다. 줄어들어야 하는 것은 반복 설명입니다. 이미 이야기한 내용을 다시 찾고, 다시 정리하고, 다시 말하는 시간. 

도구마다 흩어진 내용을 모아 같은 맥락을 복구하는 시간. 이 시간이 줄어들면 디자이너는 더 중요한 판단에 에너지를 쓸 수 있습니다.

팀도 마찬가지입니다.

맥락이 잘 남아 있으면 다음 회의는 짧아질 수 있습니다. 질문은 더 구체적이 됩니다. 결정도 조금 더 빠르게 이어질 수 있습니다. 결국 설명이 줄어든다는 것은 소통이 사라진다는 뜻이 아닙니다. 필요한 맥락이 더 잘 남아서, 협업이 조금 더 단순해진다는 뜻에 가깝습니다.

저희는 D:bo의 다음 버전을 준비하면서 이 문제를 더 깊게 보고 있습니다.

디자이너의 업무가 투두에서 리포트로, 리포트에서 공유로 자연스럽게 이어질 수 있다면 매번 같은 설명을 반복하는 부담도 조금은 줄어들 수 있다고 생각합니다. 아직은 작은 실험이지만 디자인 결과물뿐 아니라 그 결과를 선택한 이유까지 더 잘 남는 구조를 계속 만들어보려 합니다. 그 과정을 이오플래닛에도 계속 기록해보겠습니다.

[D:bo 디보 보러 가기]