설득력 있는 디자인을 위한 원페이저

왜 이렇게 디자인하셨나요

디자인 리뷰에서 '왜 이렇게 디자인하셨나요?' 라는 질문을 받았다고 해 볼게요. 분명 디자인 결정에 이유가 있었는데도 말로 꺼내기 어려울 때가 있죠? 간격을 16px로 할지 24px로 할지, 어떤 스타일의 버튼을 사용할지 등을 매번 문장으로 정리하며 결정하지는 않으니까요.

이런 판단에는 경험으로는 익혔지만 말로 풀어내기 어려운 지식, 즉 암묵지(Tacit knowledge)가 작용하기도 하는데요. 암묵지를 바탕으로 한 직관적 선택 자체가 잘못되었다는 것은 아닙니다. 다만 함께 제품을 만드는 사람에게는 그 선택을 이해하고 검토할 수 있는 설명이 필요하다는 거죠.

설명이 빠진 자리에는 누군가의 추측이 대신 들어간다

직관적인 판단을 설명하는 일은 다소 피곤할 수 있습니다. 내 논리에 대해서 하나하나 방어해내야 하는 것 처럼 느껴질 수도 있기 때문인데요. 그렇다고 '그냥 이게 좋아서요'라고 대답해버리면, 협업자는 어떤 방향성을 잡고 논의를 이어나가야 하는지 알기 어렵습니다.

개발자는 구현이 어려운 부분을 다른 방식으로 바꿔도 되는지, 매니저는 일정에 여유가 없을 때 어떤 요소를 먼저 덜어낼지 판단해야 합니다. 이 협업자들이 디자인 결정 상의 이유를 모르면 화면을 보고 저마다의 기준으로 우선순위를 추측하게 돼요. 이 상황에서 디자이너가 당연하게 여긴 필수요건이 자연스럽게 반영되긴 힘듭니다.

저는 다른 사람의 구현과 검증에 영향을 주는 판단이 있다면, 그 이유를 설명하는 것도 디자인 작업에 포함된다고 생각합니다. 협업자가 같은 조건을 놓고 결정에 대해 검토하며 논의할 수 있어야 된다는 얘기입니다. 이걸 위해 중요한 결정의 핵심을 한 페이지 안팎으로 정리해 공유하는 협업 프로세스가 필요하고, 이것을 원페이저 방법론(One-pager method)이라고 부릅니다.

함께 판단할 내용을 원페이저에 담기

원페이저는 프로젝트나 제안의 핵심을 짧게 정리해 공유하는 문서입니다. 프로젝트의 목적과 가치를 설명하는 데도 쓰이지만, 이 글에서는 디자인 결정 하나를 함께 검토하기 위한 문서로 범위를 좁혀보겠습니다.

여기에 담을 내용은 지금 결정해야 할 문제, 고려한 대안, 제안하는 선택과 그 이유, 팀원들과 함께 더 확인해야 할 점입니다. 디자인 화면을 보는 것 만으로는 알 수 없는, 판단의 배경 자체를 정리하는 거예요. 다만 과하게 설명적이거나 상세한 정보가 기재될 필요는 없어요. 자세한 정보를 연계해 안내해야 한다면 외부 링크를 별도로 달아두고, 원페이저 내용은 요약적으로 유지하는 것이 좋습니다.

작성 시점에 따라서 원페이저의 역할이 바뀔 수도 있어요. 최종 결정이 끝난 뒤에는 근거를 보존하는 기록으로 쓸 수 있고, 결정 전에는 미처 고려하지 못한 조건이나 다른 관점을 검토받는 자료로 쓸 수 있습니다. 이 글에서는 원페이저를 후자의 용도로 사용하는 것을 상정하고 있지만, 협업 프로세스가 안정화된 후에는 전자의 용도로도 사용해봐도 좋다고 생각합니다.

대화로 확인하고 기록으로 다시 살펴보기

원페이저가 직접 대화하는 것 보다 소통에 있어 효과적일까요? 그렇다고 말할 순 없고, 시간적 제약의 유무에 따른 장단점이 있어요. 대화에서는 상대가 이해하지 못한 부분을 바로 물어보고 설명을 보탤 수 있습니다. 아직 문제 자체가 모호하다면 대화를 나누며 정리하는 편이 나을 수 있겠죠. 다만 그 자리에 없던 사람은 같은 설명을 듣기 어렵고, 참석한 사람끼리도 무엇을 결정했는지 다르게 기억할 수 있습니다.

원페이저는 서로 다른 시간에 같은 내용을 읽고 검토할 수 있다는 장점이 있습니다. 설명을 듣는 속도에 맞추지 않고 근거를 찾아보거나, 특정 문장에 질문을 남길 수 있어요. 결정한 뒤에도 당시의 조건과 선택 이유를 다시 확인할 수 있습니다. 채팅에 여러 차례 나눠 설명했다면, 흩어진 논의점들을 한곳에서 찾을 수 있게 정리하는 역할도 합니다.

대신 작성하고 읽는 시간이 필요합니다. 짧게 줄이는 과정에서 중요한 맥락을 빠뜨릴 수도 있고, 글만으로는 오해가 풀리지 않아 대화가 다시 필요할 수도 있어요. 결정이 바뀌었는데 문서를 고치지 않으면 예전 설명이 현재의 기준처럼 남는다는 부담도 있습니다.

그래서 소통 방식을 하나로 통일할 필요는 없습니다. 기존 디자인 시스템 규칙을 적용한 결정이라면 해당 규칙을 연결하는 것으로 충분할 수 있겠죠. 작은 예외는 Figma 주석으로 설명하고, 여러 선택의 이유를 함께 검토해야 할 때 원페이저를 작성하면 됩니다. 문서로 쟁점을 미리 공유하고, 대화로 남은 이견을 다룬 뒤, 결과를 같은 문서에 남기는 식으로 함께 사용할 수 있습니다.

가볍게 시작해보기

처음부터 모든 디자인 작업에 원페이저를 의무화하면 문서를 채우는 작업 자체에 매몰될 위험이 있습니다. 그러니 다음 리뷰에서 팀원의 판단이 필요한 결정 하나를 골라서 가볍게 시작해보세요. 기존 규칙만으로 설명하기 어렵거나, 대안적 옵션들 사이에서 무엇을 우선할지 함께 정해야 하는 결정이 적당합니다.

우선 제안 검토 요청 목적이라면, 작성에 앞서 '누구에게 무엇을 검토받을지'를 정해야 합니다. 단순히 '의견 부탁드립니다'라고 보내기보다, '이런 선택을 해 봤는데, 여기서 놓친 조건이나 더 충족해야 할 것들이 있는지 확인해주세요'처럼 필요한 피드백을 구체적으로 적으세요. 그래야 팀원이 지금 자신의 의견으로 무엇을 바꿀 수 있는지 알 수 있습니다.

원페이저 문서는 팀이 이미 쓰는 Figma 파일의 캔버스 안에 두고, 관련 디자인 요소와 가까이 두거나 별도 표시해서 연관성을 표시하면 됩니다. 검토를 부탁한 팀원과 언제까지 읽고 응답할 지 정하거나, 정기 리뷰가 있다면 그 시간에 함께 읽는 방향도 좋아요. 의견을 받은 뒤에는 원페이저 작성자가 결정을 다시 정리해 갱신하고, 제안 검토용 원페이저가 결정 기록용 원페이저로 바뀌는 것 까지 직접 진행하며 경험해 보는 것이 중요합니다.

중요한 것이 있어요. 원페이저를 한 번 사용한 뒤에는 '문서를 작성했다는 사실'에 큰 의미를 두지 않아야 한다는 것입니다. 원페이저가 실제 논의에 어떤 도움이 됐는지 살펴봐야 하고, 실질적으로 팀원들이 '내가 왜 이렇게 디자인했는지'를 이해할 수 있었는지 확인하는 게 중요합니다. 그리고 원페이저 사용을 통해 '내가 고려하지 못한 것들이 드러났는지'도 확인할 수 있다면 충분히 성공적으로 원페이저를 사용한 것입니다.

예시: 원페이저를 작성하고 함께 검토한다면

가상의 구성원 제거 기능을 예로 들어볼게요. 이미지 예시에 사용된 데이터들은 실존하지 않는 가상의 데이터입니다.

실행 취소가 없는 상황에서, 프로덕트 디자이너가 제거 대상을 한 번 더 확인하는 단계를 제안하려고 합니다. 다음 리뷰 전에 그 이유를 공유한다면 다음의 이미지처럼 정리할 수 있습니다.

여기서 결정을 위한 옵션으로 제시한 a안과 b안에 대한 예시 이미지도 이어서 보여드릴게요.

이 문서에서 팀원이 '확인 단계가 실수를 줄인다는 근거가 있나요?'라고 물었다고 해볼게요. 디자이너는 아직 검증하지 않았다는 점을 분명히 언급했어요. 그러면 그 불확실성을 감수하고 결정할지, 추가로 확인한 뒤 결정할지를 팀과 함께 논의할 수 있습니다. 예상한 효과와 확인한 사실을 구분했기 때문에, 어느 부분의 근거가 부족한지 찾아볼 수 있는 거죠.

논의 끝에 제안한 안을 선택했다면 해당 원페이저가 '결정된 것'임을 알 수 있도록 표시하고, 선택 이유와 남은 검증 과제를 갱신합니다. 판단에 필요한 자료가 부족해 보류했다면 그 상태와 추가로 확인할 내용을 남겨두면 됩니다. 모든 논의 내용들을 원페이저 내용에 옮길 필요는 없고, 나중에 읽는 사람이 현재 결론과 그 이유를 알 수 있도록 정리하는 것이 중요해요.

원페이저의 서식이나 내용 구성, 표(Table) 사용 여부 등은 얼마든지 목적에 따라 변형되어도 괜찮습니다. 그리고 원페이저를 별도의 문서화 도구로 옮겨서 관리하는 것도 좋고요.

원페이저만으로는 합의에 이르지 못합니다

판단의 이유를 잘 적었다고 해서 그 판단을 뒷받침하는 구체적인 증거가 생기지는 않아요. 사용자의 행동을 확인해야 하는 문제라면 조사나 검증이 필요합니다. 원페이저는 검토가 필요한 것을 알리거나, 결정된 것을 기록하는 데 쓸 수 있긴 해도 근거를 증거로 바꾸는 역할은 아니에요.

팀원들이 원페이저 내용을 이해했다고 해서 내 제안에 항상 동의하는 것도 아닙니다. 같은 자료를 보고도 포지션이나 역할에 따라 중요하게 보는 조건이 다를 수 있어요. 기준의 우선순위를 조정하거나 책임 있는 사람이 결정을 내려야 하는 상황에서는 그 논의가 별도로 필요합니다. 내용을 더 설득력 있게 다듬는 것과는 별개의 문제겠죠.

의견을 내도 결정에 반영될 여지가 없거나, 읽고 검토할 시간이 확보되지 않은 상황도 마찬가지입니다. 원페이저를 도입하는 것만으로 그런 협업 상의 제약적 상황까지 개선되지는 않아요. 피드백이나 댓글이 없다는 이유로 모두 동의했다고 판단해서도 안 됩니다. 실제로 검토했는지와 어떤 이견이 남았는지를 확인해야 해요.

그래도 내 판단의 이유부터 꺼내놔야 협업할 수 있다

이런 한계들이 있어도, 원페이저를 시도해볼 이유는 충분합니다. 내 머릿속에 있는 판단의 이유를 팀원이 구체적으로 질문하고 수정 의견을 낼 수 있는 대상으로 만들기 때문입니다. 설명이 부족한 것인지, 근거가 부족한 것인지, 판단 기준이 다른 것인지 구분하려면 우선 내가 어떤 생각을 했는지 드러나 있어야 하니까요.

문서 작업을 번거로워하거나 어려워하는 사람들이 많죠? 저도 솔직히 문서를 쓰기보다는 Figma에서 실질적인 디자인 작업을 하는 것을 선호합니다. 그래도 중요한 선택을 앞두고 있다면, 내 생각을 정리해 팀원에게 검토를 부탁하는 시간도 필요하다고 생각합니다. 디자인 리뷰를 앞두고 있다면, 이번에는 원페이저를 만들어서 진행해보면 좋겠습니다. 그리고 팀원의 질문을 받은 뒤, 더 좋은 디자인을 찾고 결과를 기록하는 것 까지 해보는 거예요.