발산과 수렴을 잘해야 디자인을 잘한다

“디자인은 발산과 수렴의 과정입니다”

문제점을 찾아가는 과정에서는 여러 아이디어를 던지고(발산), 정의한 문제들을 해결하기 위해선 한 꼭지로 해결점을 모으는(수렴) 과정이 필요합니다. 그 솔루션에 적합한 디자인을 찾아가기 위해선 여러 안들을 고안하고(발산), 가장 적합한 디자인으로 다듬어야(수렴) 합니다.

이뿐만이 아닙니다. 실무에서는 디자인 리뷰 단계도 필수적인데, 여러 관련자의 다양한 시각에서 피드백을 받고(발산) 이 중 타당한 피드백을 선별하여 적용(수렴)합니다. 발산은 직관에 따른 창발 과정이며, 수렴은 논리적으로 수습하는 과정입니다. 그러므로 발산과 수렴을 잘해야, 디자인도 잘할 수 있게 됩니다.

지금부터 ‘문제 정의 - 디자인 - 피드백’의 세 단계에서 어떤 발산과 수렴의 과정을 거쳤는지에 대한 제 경험을 바탕으로 발산과 수렴하는 방법에 관해 이야기해보겠습니다.

문제 정의의 발산과 수렴

문제의 정체를 파악하고 해결하기 위해서 가장 먼저 What, Why, How가 정의되어야 합니다. 무엇(What)을 이루고자 하는지를 정의하고, 그것을 이루지 못한 이유(Why)를 파악합니다. 그리고 어떻게(How) 하면 그것을 이룰 수 있는지를 생각합니다. 이 과정은 문제를 찾기 위한 탐색을 하고 정의하는 과정이며, 발산 후의 수렴이 이루어지는 단계입니다.

[발산] ‘What, Why’로 문제의 정체 발견하기

예를 들어서 커머스 앱에서 상품 리뷰 수를 늘리고 싶어 합니다. 이때 What은 ‘상품 수령 후 고객이 리뷰를 작성하게 하기’가 될 수 있습니다. 여기서 ‘왜 이제까지 많은 고객이 상품 리뷰를 적지 않았던 걸까?’를 찾는 과정이 Why입니다.

‘리뷰를 적어야 하는 줄 몰라서? 리뷰를 쓸 때 얻어지는 혜택이 잘 드러나지 않아서? 리뷰 남기는 과정이 귀찮아서? 리뷰를 쓸 만큼 좋거나 나쁜 제품이 아니어서? 리뷰 쓰기 버튼이 너무 깊은 페이지에 숨겨져 있어서? 리뷰 쓰는 걸 까먹어서?’

이처럼 상품 리뷰에 관한 아이디어를 끊임없이 생산하면서 진짜 ‘Why(왜?)’를 찾기 위한 생각이 꼬리에 꼬리를 물고 이어질 수 있습니다. 또 사용자 인터뷰나 설문, 혹은 사용자 데이터 탐색을 통해 문제의 근본적인 이유와 실체를 발견할 수 있습니다.

‘사용자 인터뷰를 해보니 (혹은 데이터를 살펴보니), 리뷰 작성 시의 혜택이 더 잘 소구되는 경우에 귀찮음을 무릅쓰고 리뷰를 작성하는군. 그래도 근본적인 문제는 리뷰 쓰는 걸 잊어버렸기 때문으로 보여. 리뷰 쓰는 걸 왜 까먹었을까?’

이처럼 이 단계는 많은 가능성을 찾아 나서는 발산의 과정입니다. 이런 일련의 문제 파악 과정을 통해 어떤 것이 문제의 본질인지 구체화할 수 있습니다. 이 예시에서는 근본적인 이유 Why는 ‘리뷰를 작성해야 하는 것을 까먹기 때문에’로 볼 수 있습니다.

[수렴] ‘How’를 찾고 솔루션 구체화하기

앞서 발견한 문제의 원인 ‘리뷰를 작성해야 하는 것을 잊어버린다’라는 걸 어떻게 해결해야 할까요? 아주 간단하게도 이 문제의 해결 방법, 즉 How는 ‘유저에게 리뷰를 작성하라고 알려준다’라고 할 수 있습니다.

그런데 이 예시에서 하나 참고해야 할 사항이 있습니다. 리뷰 작성 시의 혜택을 잘 소구시킨 경우에 리뷰를 더 많이 작성하는 경향을 보였다는 것입니다. 이런 정보를 바탕으로 해결책을 더 구체화할 수 있습니다.

‘상품을 수령한 유저에게 리뷰의 혜택이 잘 전달되도록 푸쉬 메시지를 보낸다.’

목적 ‘What’을 이루지 못하게 하는 이유, ‘Why’를 해결할 방법, ‘How’를 구체화하고 다듬는 과정 등 이 모든 것들이 발산한 아이디어를 정제해 하나의 해결법으로 모으는 수렴의 과정입니다.

간단한 상황을 예로 들었기 때문에 What과 Why에 따른 How가 비교적 명확하게 도출되었습니다. 하지만 실무에서는 이루고자 하는 목적의 크기와 난이도에 따라 Why와 How가 연결이 잘 안되거나 ‘그럴듯해 보이게만' 정의되는 경우가 참 많습니다. 그러므로 ‘이 방법으로 문제가 해결될 수 있는가?’ 혹은 ‘이걸로 목적을 이룰 수 있는가?’를 끊임없이 체크해야 합니다. 그래서 이 수렴의 과정이 정말 중요합니다.

디자인의 발산과 수렴

디자인 단계에서는 프로젝트의 범위에 따라 발산과 수렴이 연달아 나타날 수 있습니다. 그래서 디자인 작업 툴로 시안을 만들기 전에 PM 혹은 기획자와 함께 이루어져야 할 ‘발산- 수렴’ 단계와 본격적인 디자인 작업을 할 때 나타나는 ‘발산 - 수렴’의 두 과정을 알아보겠습니다.

[발산] 사용자 행동 나열하기

문제정의 단계에서 도출한 해결책을 우리 제품에 적용한다면, 사용자들은 어떤 행동들을 해야 할까요? 디자인 전에 사용자의 행동 시나리오들을 나열해보면 디자인 목표를 구체화하는 데 도움이 됩니다.

이번 예시에서는 문제정의 후 도출한 해결책이 ‘사용자가 100자 이내의 독후감을 쓰고 저장하게 한다’라고 가정해봅시다. 그러면 다음과 같은 사용자 행동들을 나열해 볼 수 있습니다.

사용자는 독후감 쓰기 엔트리 포인트(어떤 기능이나 페이지에 진입하기 위한 터치 포인트)를 확인한다. 엔트리 포인트를 터치한다. 책 제목을 입력한다. 책의 장르를 선택한다. 작가 이름을 입력한다. 읽은 날을 캘린더에서 선택한다. 독후감을 작성한다. 독후감을 100자 이내로 작성해야 함을 확인한다, 저장한다, 저장 전 페이지 이탈 시도를 한다, 이탈 메시지를 확인한다. …

이렇게 나열하다 보면 자연스럽게 어떤 화면이 필요한지, 각 화면에 어떤 요소가 포함되어야 하는지가 나타나고, 디자인 목표를 세울 수 있는 준비가 됩니다.

[수렴] 페이지 별 디자인 목표 세우기

나열한 사용자 행동들을 보면 ‘사용자가 100자 독후감을 쓰고 저장하게 한다’를 위해 어떤 화면에 어떤 UI 요소가 필요한지 정리할 수 있습니다.

• 홈화면: 독후감 작성의 엔트리 포인트
• 독후감 작성 페이지: 제목 입력 영역, 장르 선택 영역, 작가 이름 입력 영역, 날짜 선택 영역, 독후감 작성 영역, 저장 버튼, 글자 수 안내 영역
• 이탈 다이얼로그: 이탈 시 ‘저장 안됨’ 메시지

그리고 이를 바탕으로 각 화면에서 우리의 문제를 해결하기 위해 어떤 디자인 목표를 세워야 하는지도 명확해집니다.

• 홈화면: 독후감 작성의 엔트리 포인트

-> [Design Goal 1] 독후감 작성의 흥미를 끌 수 있는 엔트리

• 독후감 작성 페이지: 제목 입력 영역, 장르 선택 영역, 작가 이름 입력 영역, 날짜 선택 영역, 독후감 작성 영역, 저장 버튼, 글자 수 안내 영역

-> [Design Goal 1] 모든 입력값을 잊지 않고 입력하게 하는 디자인

-> [Design Goal 2] 독후감 작성이 간단명료하게 느껴지는 디자인

이렇게 해결책 적용을 위해 필요한 페이지와 디자인 요소를 정리하고, 디자인 목표를 설정하는 것은 디자인 작업 목표를 논리적으로 정제해 나가는 수렴의 과정입니다. 이렇게 목표를 설정하면 PM과 디자인 화면에 대한 논의가 훨씬 수월해집니다. 목표를 중심으로 달성할 수 있는 화면인지, 아닌지를 기준으로 판단하면 되기 때문입니다. 잘 수렴하여 얻어진 디자인 목표는 우리의 기획과 디자인이 한 방향으로 향하고 있는지를 판단해 줄 이정표가 됩니다.

[발산] 레퍼런스 조사와 시안 작업

이제 디자인 툴을 이용하여 작업에 들어가는 단계입니다. 디자인 목표를 이룰 수 있게 하는 예시화면들을 찾아보고, 그에 따른 시안 작업을 합니다. 확실하지 않은 시안에 대해서는 A안, B안을 만들어 보기도 하고, 그래픽 시안도 여러 가지로 작업해 봅니다. 목표에 기반한 가능성을 열어둔 채 디자인 작업물을 만들어 냅니다.

[수렴] 디자인 목표에 맞게 디자인 정리

디자인 목표를 설정해도 우리의 생각은 언제든 옆으로 튈 수 있습니다. (제가 그런 실수를 자주 합니다.) 그럴 땐 다시 목표를 확인하며 시안을 한땀한땀 조정해 나갑니다.

‘[독후감 작성하기] 글자가 더 커야겠는데?’, ‘엔트리 포인트가 더 강조되려면 더 대비되는 색상의 그래픽으로 바꿔야겠어’, ‘라인 버튼이 아닌 솔리드 버튼으로 바꿔서 가시성을 한 단계 더 높이자’ ‘alert 메시지를 좀 더 강조하자’, ‘이 페이지의 디자인 목표는 간단명료하게 느껴져야 한다는 거였어. 중복되는 타이틀은 없애고 그루핑해서 정리해보자’

이렇게 앞서 정한 디자인 목표의 방향으로 정리해 나갑니다. 이처럼 특정 기준으로 수렴해가는 작업이 있어야 관계자들에게 디자인을 논리적으로 설명하기 쉬워지고, 더 설득력 있는 디자인 시안을 완성할 수 있습니다.

피드백의 발산과 수렴

디자인 작업이 완료되면 디자이너는 다른 디자이너, 기획자 혹은 PM, 때로는 개발자들과 디자인 리뷰를 하게 됩니다. 이때도 잘 발산하고 잘 수렴할 수 있어야 퀄리티를 한층 더 끌어올리는 디자인으로 마무리할 수 있습니다.

[발산] 관련자들에게 피드백 받기

피드백의 발산은, 작업자인 내가 아닌 다른 사람들로부터 쏟아지는 발산입니다. 디자인한 화면의 타당성과 사용성, 개발 효율성 등 다양한 측면으로 피드백을 받게 됩니다. 이 단계는 디자이너가 한가지 작업에만 몰두하게 되면서 미처 보지 못했던 문제를 발견할 수 있습니다. 또 디자이너 관점이 아닌 다른 직무의 관점에서 보는 문제점들도 파악할 수 있습니다.

[수렴] 디자인 목표와 동조되는 피드백 수용

다만 우리는 모든 피드백을 수용할 수 없습니다. 특히 개발이나 비즈니스 측면이 아닌 디자인 측면의 피드백은 주관적인 성향을 띄기 때문에 수용 여부를 결정하기가 더 까다롭습니다. 이때 해결책으로는 다름 아닌 디자인 수렴 단계에서 설정한 디자인 목표입니다. 피드백이 디자인 목표에서 벗어난 내용이라면 적용하지 않아도 좋고, 좋은 피드백이라 할지라도 디자인 목표와의 우선순위를 생각하며 적용 여부를 고민할 수 있습니다. 이렇듯 피드백 단계에서의 수렴 과정은, 정해진 기준으로 피드백 적용의 의사결정이 이루어지는 과정입니다.

나만의 발산과 수렴 방법을 찾자

지금까지 ‘문제정의 - 디자인 – 피드백’에서 일어나는 발산과 수렴에 관해 이야기해보았습니다. 개인 경험을 살짝 더 얘기하자면, 저는 대표적인 발산형의 사람인지라 수렴하는 과정을 힘들어했습니다. 또 답을 찾아가는 ‘수렴'이 아닌, 답을 정하고 꿰맞춰 ‘수렴’하려는 실수도 저지르곤 했습니다. 그러다가 논리적으로 문제를 정의하고 해결하는 팀에 합류하며 제대로 배운 것이 위에서 설명한 ‘잘 수렴’하는 방식이었습니다. 그리고 이를 통한 커뮤니케이션이 의사 결정을 수월하게 하는 걸 깨닫게 되었습니다.

사실 발산과 수렴은 여기에 소개된 것보다 더 많이, 끊임없이 일어날 수 있습니다. 또 사람에 따라 발산과 수렴의 방법이 다를 수도 있습니다. 하지만 하나 확실한 건, 발산과 수렴을 잘할수록 디자인 도출과 커뮤니케이션 능력이 늘어날 것이라는 점입니다. 제 경험을 바탕으로 여러분들도 본인만의 발산- 수렴 방식을 찾을 수 있길 바라봅니다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.