스케치는 언제 프로토타입이 되는가

스케치가 프로토타입이 되는 순간

생각의 스케치를 통해 우리가 정의한 문제의 해결 가능성을 넓혔다. 답이 될 수 있는 사고를 시각적인 흐름으로 놓고, 같은 데이터를 여러 차트로 그려 배치하며 다양한 아이디어를 펼쳤다. 이제 그중 가장 좋다고 판단되는 하나를 다른 사람이 경험하고 반응할 수 있는 형태로 전달할 차례다.

디자인 사고는 흔히 공감하고 문제를 정의한 뒤, 아이디어를 내고, 프로토타입을 만들고, 테스트하는 단계로 설명된다. 이 구분은 각 단계의 목적을 이해하는 데 유용하지만, 실제 작업에서 아이디어와 프로토타입 사이에 단단한 벽이 있는 것은 아니다. 생각을 눈앞에 꺼낸 스케치가 앞서 정의한 문제를 해결하기 위한 목적이나 기능을 거칠게라도 수행하고, 다른 사람이 사용하거나 반응할 수 있게 되면 프로토타입이 된다. 슬라이드의 순서가 발표의 흐름을 만들고, 차트가 실제 비교를 가능하게 하며, 동작하는 애플리케이션을 만들었다면 더 이상 생각을 보여 주는 데 그치지 않는다. 사용자가 그 기능을 테스트할 수 있다.

프로토타입은 문제의 답을 테스트하는 형태다

프로토타입의 기준은 화면이나 모형의 완성도가 아니다. 앞서 공감하고 정의한 사용자의 문제를 해결할 수 있는지 시험할 수 있어야 한다. 프로토타입은 테스트를 가능하게 하는 시험용 형태로 이해하면 좋다. 너무 정교하게 만드느라 시험할 시간을 잃어서도 안 되고, 핵심 경험이 작동하지 않아 정의한 문제를 시험할 수 없어서도 안 된다. 디스쿨의 프로젝트 가이드는 프로토타입을 아이디어 활동의 연속으로 보며 '만들며 생각하기(Build to Think)'라는 태도를 제시한다. 프로토타입은 완성품의 축소판이 아니라, 생각을 현실에 닿게 해 다음 생각을 얻는 도구다.

그렇다면 프로토타입으로 무엇을 시험해야 할까. 당연히 앞서 공감을 통해 정의한 문제에 대해, 해결할 수 있는 방법과 사고를 테스트할 수 있어야 한다.

사용자가 이 화면을 실제 업무에서 사용한다면, 정의한 문제를 해결하고 다음 행동을 선택할 수 있는가?

프로토타입이 그럴듯해 보인다고 사용자의 문제를 해결한 것은 아니다. "좋네요"라는 반응과 실제로 일을 더 잘 해내는 것은 다르다. 본래 목적을 잊어서는 안 된다.

예를 들어, 주변 건물을 비교하기 쉽도록 지도 화면을 만들었다고 가정하자. 사용자가 좋은 반응을 보였더라도, 그것만으로 만든 목적을 이루었다고 볼 수는 없다. 실제로 비교할 건물을 더 쉽게 고를 수 있는지는 따로 확인해야 한다.

그러려면 먼저 프로토타입으로 테스트를 해야 할 질문을 정해야 한다. 앞서 문제 정의가 존재해야 하는 이유다. 문제와 질문이 존재해야 비로소, "이 화면이 좋은가?"보다 "목록만 볼 때보다 지도에서 비교할 건물을 더 쉽게 고를 수 있는가?"처럼 구체적으로 물을 수 있다. 프로토타입은 그 목적을 수행하는 것이다.

형태는 새로운 대화를 만든다

프로토타입이 질문을 위한 목적을 수행하면 이제 다시 무엇을 개선될 수 있을지도 보인다. 정말 쉽게 사용했는지, 프로토타입을 이용하면서 망설임이나 어려움은 없었는지 살펴볼 수 있다. 즉, 프로토타입과 시험의 과정이 해법을 좁히는 방향으로만 흐르는 것은 아니다. 아이디어 단계에서 만드는 사람의 생각이 확산되었다면, 프로토타입과 테스트 단계에서는 사용자의 반응이 더해진다. 그 과정에서 말로는 드러나지 않던 필요와 새로운 해법이 발견되기도 한다.

말로는 "깔끔한 대시보드"라고 표현할 수밖에 없던 요구도 화면을 보면 구체적으로 바뀐다. 주제 영역을 어떻게 나눌지, 무엇을 먼저 보아야 할지, 어떤 차이를 또렷하게 드러내야 할지 말할 수 있게 된다. 전 분기와 비교하고 싶은지, 다른 회사나 팀과 비교하고 싶은지에 따라 필요한 차트도 달라진다. 말의 언어가 시각의 언어로 번역되면서 처음에는 존재하지 않았던 공통의 대화 대상이 생긴다.

그렇다고 사용자가 말한 내용을 화면에 그대로 옮기는 것은 아니다. 앞서 우리는 이미 상대방의 요구에 대해 의심했다. 사용자가 추이를 보고 싶다고 하면 먼저 그 목적을 묻는다. 변화의 정점을 찾으려는 것인지, 다른 대상과 차이를 비교하려는 것인지에 따라 표현 방법이 달라진다. 사용자는 자신이 하는 일의 맥락을 알고, 만드는 사람은 그 판단을 도울 형태를 제안한다. 프로토타입은 주문받은 결과물의 미리보기가 아니라, 사용자의 말과 만드는 사람의 해석 사이에 놓는 번역본이다.

형태를 본 사용자가 미처 말하지 못했던 필요를 발견하면 만드는 사람도 그 반응에서 새로운 해법을 떠올린다. 지금까지 우리가 따라온 디자인 사고는 공감, 문제 정의, 아이디어, 프로토타입, 테스트를 한 번씩 통과하는 직선의 절차가 아니다. 만들다가 새로운 아이디어가 생기고, 시험하다 문제를 다시 정의한다. 필요하면 앞의 노드를 다시 여는 이 왕복이 디자인 사고의 비선형적 특성이다.

한 번은 상업용 부동산 매물을 비교하는 대시보드 프로젝트에 중간부터 참여했다. 공감과 문제 정의를 거치지 못한 채 '화면 기획서'를 받고 프로토타입 작업을 시작했다. 줄글과 간단한 화면 이미지로 된 기획서의 핵심은 특정 건물을 선택하면 일정 반경 안의 다른 건물을 목록으로 보여 주고, 공실률과 관리비, 월세와 세입자 현황을 비교하는 것이었다. 첫 미팅에서도 요구는 그 범위를 벗어나지 않았다.

"특정 건물과 그 반경 내 건물 리스트를 보여 주는 화면이면 될 것 같아요."

사용자는 지도 위의 비교 화면을 요구하지 않았다. 그런 화면이 필요 없어서가 아니라, 가능하다고 생각하지 못했기 때문이었다. 나는 목록만 만들지 않고 지도 기능이 포함된 프로토타입을 보여 주었다. 선택한 건물과 주변 건물의 위치가 한곳에 놓이자 이전에는 없던 요구가 나오기 시작했다. 반경을 원으로 표시할 수 있는지, 선택한 건물의 색을 다르게 할 수 있는지, 주변 건물을 어떤 조건으로 비교할 수 있는지 질문이 이어졌다.

형태를 마주하면, 미처 몰랐던 필요가 드러나고 생각의 범위가 넓어진다

해법을 다시 확산할 새로운 박스가 열린 것이다. 사용자 기존의 사고에서는 정렬과 필터 정도의 아이디어만 존재했을 것이다. 지도라는 박스가 생기자 위치와 거리, 반경과 주변이라는 다른 질문이 생겼다. 만드는 사람이 가능성을 형태로 꺼내자 사용자가 자신의 업무와 연결해 다음 아이디어를 보탰다. 프로토타입은 이미 정한 해법을 확인하는 데서 끝나지 않고, 함께 볼 수 있는 형태를 사이에 놓고 해법의 범위를 넓혔다.

다만 여러번 강조하지만, 사용자의 아이디어를 포함해 가능성이 넓어졌다는 사실이 해법의 타당성을 확인했다는 뜻은 아니다. 새로 생긴 아이디어 역시 사용자의 문제를 실제로 풀 수 있는지 다시 시험해야 한다.

무엇을 비교할지 분명히 하다

항상 프로토타입의 목적이 흐려지는 것을 주의해야 한다. 이때 목적이 흐려지는 가장 빈번한 이유는 프로토타입의 테스트 범위가 넓어지고, 정작 우리가 정의한 문제를 해결할 수 있을지에 대한 테스트와 피드백의 중심이 흐려지는 것이다.

시험용 형태가 커지는 가장 흔한 이유는 한 번에 너무 많은 것을 확인하려 하기 때문이다. 화면의 구성과 문구, 기능과 데이터, 전체 업무 흐름을 한꺼번에 넣으면 무엇 때문에 반응이 달라졌는지 알기 어렵다. 디스쿨은 이를 '변수 하나 정하기(Identify a Variable)'라고 부른다. 사용자에게 중요한 가정 하나를 고르고 그것만 다르게 만든 여러 형태를 비교하는 방법이다.

나는 만들기 전에 가정을 한 문장으로 적는 편을 권한다.

우리는 [사용자]가 [상황]에서 [해법의 핵심 요소]를 경험하면 [기대하는 행동이나 변화]가 나타날 것이라고 생각한다.

상업용 부동산 대시보드라면 이렇게 쓸 수 있다. '매물을 비교하는 담당자가 주변 건물의 위치와 거리를 한 화면에서 보면, 목록만 볼 때보다 비교할 후보를 더 쉽게 고를 것이다.' 이 문장에서 확인할 것은 지도의 존재이고, 기대하는 변화는 비교 후보를 고르는 행동이다. 데이터 항목과 과업은 같게 두고 목록 화면과 지도 화면을 같은 수준으로 구현하면, 화면 전체에 대한 막연한 선호보다 지도가 판단에 어떤 차이를 만드는지 볼 수 있다.

당시 내가 실제로 한 일은 지도 화면을 보여 주어 사용자가 미처 말하지 못한 요구를 끌어낸 것이었다. 두 화면을 같은 조건에서 비교한 정식 테스트는 아니었다. 이 경험을 더 엄밀한 실험으로 밀어붙인다면 무엇을 같게 두고 무엇만 바꿀지가 분명해진다는 뜻이다. 팀의 의견이 갈릴 때도 말로 승부하기보다 핵심 요소만 다른 두세 개의 형태를 만들어 같은 과업으로 비교할 수 있다.

피드백이 핵심을 향하게 만들다

프로토타입 형태의 공식은 없다. 확인하려는 가정을 시험할 수 있다면 손으로 그린 화면이나 포스트잇으로 붙인 흐름도 프로토타입이 될 수 있다. 그러나 낮은 완성도와 조악함은 같지 않다. 앞서 프로토타입의 목적을 분명히 하려면 사용자가 검증하려는 문제에 집중할 수 있도록 설계해야 한다.

문제를 함께 정의한 사용자는 무엇이 시험 대상이고 무엇이 임시 요소인지 어느 정도 구분할 수 있다. 하지만 대부분의 사용자는 이를 스스로 걸러 보아야 할 이유가 없다. 핵심 기능이 작동하더라도 주변의 데이터와 문구가 비현실적이면, 본래 문제를 풀 수 있는지보다 프로토타입의 부족한 부분에 먼저 반응한다.

나도 그런 피드백을 자주 경험했다. 확인하고 싶은 것은 지표의 구성과 판단의 흐름인데, 버튼이 작동하지 않거나 가상 데이터가 어색하면 대화는 그곳에 머물렀다. 그래서 사용자가 직접 거치는 핵심 흐름만큼은 최종 결과물에 가깝게 구현하려 한다. 여기서 완성이란 화려하게 꾸민다는 뜻이 아니다. 맞춤법이 틀린 문구와 어색한 가상 데이터를 걷어내고, 기본적인 시각 요소와 상호작용을 갖춰 실제 서비스처럼 받아들일 수 있게 만드는 것이다. 완성도는 장식이 아니라 피드백이 진짜 문제를 향하게 만드는 조건이다.

이는 디스쿨의 '의도적으로 만들고 다듬기(Build and Craft Intentionally)'와 맞닿아 있다. 디스쿨은 보여줄 대상과 원하는 피드백에 맞는 구체화 수준을 선택하라고 한다. 프로토타입 가이드도 시험하려는 부분에는 완성도를 높이고 나머지 부분에는 힘을 덜 쓰라고 안내한다. 조악함 자체가 원칙이 아니라, 알고 싶은 것에 맞는 선택적 완성도가 원칙이다.

실제와 비슷해야 하는 것은 무엇보다 사용자가 문제를 푸는 경험이다. 진짜 데이터에 가까운 예시와 핵심 상호작용, 판단에 필요한 문구는 실제처럼 만든다. 반면 시험과 관계없는 설정 화면과 부가 기능, 보이지 않는 뒷단의 시스템은 생략하거나 작동하는 척할 수 있다. 영화 세트처럼 사용자가 거칠 동선은 실제처럼 만들되, 보이지 않는 뒤편까지 완성된 건물을 지을 필요는 없다.

실수에서 회복하는 경험이 핵심 과업의 일부라면 정상적인 흐름만 구현해서는 안 된다. 실제 경험은 잘못된 입력, 빈 결과, 로딩, 취소와 되돌리기에서 무너질 수 있다. 하지만 모든 예외를 만들 필요는 없다. 이번 테스트에서 확인할 실패와 회복만 작동하게 만든다.

전문 소프트웨어와 AI, 그리고 우리의 경험과 숙련도는 이러한 필요한 완성도를 채우는 비용을 낮출 수 있다. 그렇게 확보한 시간을 모든 기능을 늘리는 데 쓰기보다, 사용자가 불필요한 결함에 주의를 빼앗기지 않고 핵심 과업을 수행하게 만드는 데 써야 한다. 프로토타입은 출시 전 제품이 아니라, 이번 질문에 답할 만큼만 실제처럼 만든 경험이다.