실무에서 더블 다이아몬드를 얼마나 ‘진짜’ 따르나요?
이론과 현실 사이, UXer의 프레임워크를 대하는 자세
안녕하세요. 저는 시각디자인을 전공하고 현재 UXer로 인턴 중인 대학생입니다. 학교에서는 ‘더블 다이아몬드 프로세스’를 교과서처럼 배우고, 과제나 프로젝트도 그 흐름대로 진행해 왔어요. Define, Discover, Develop, Deliver… 이 4단계가 마치 ‘UX의 정석’인 것처럼 말이죠.
그런데 막상 실무에 들어와 보니, 빠듯한 일정이나 정해진 방향성 때문에 아이데이션 전에 이미 솔루션이 정해져 있는 경우도 많고, 리서치나 프로토타입 단계는 거의 생략되기도 하더라고요. 물론 모든 단계를 철저히 따라야 한다고는 생각하지 않지만, ‘이렇게까지 간소화해도 괜찮은 걸까?’ 하는 불안도 있습니다.
멘토님께서는 실무에서 더블 다이아몬드 프로세스를 어떻게 해석하고 활용하고 계신가요? 꼭 순서대로 지켜야 할까요, 아니면 상황에 따라 유연하게 조합하는 편이 더 좋은 UX를 만든다고 보시나요? 실무자의 현실적인 균형감각이 궁금합니다! 감사합니다.
➥ 더블 다이아몬드 프로세스를 교과서처럼 배우고 오롯이 따라왔던 경험, 그리고 실무에서는 그와 다른 현실을 마주하게 된 혼란, 충분히 공감됩니다.
제가 자주 하는 비유가 훈련소와 전쟁터입니다. 훈련소에서는 대개 정지된 과녁을 향해 총을 쏘며 훈련을 합니다. 하나 전쟁터의 상황은 혼돈 그 자체일 것입니다. 전쟁을 겪어보지 않았더라도 전쟁참상을 잘 묘사한 전쟁영화만 봐도 충분히 이를 알 수 있습니다. 더블 다이아몬드와 같은 체계나 프레임워크는 일종의 정지된 과녁과 같은 역할을 합니다. 그것 나름대로 의미를 지니지만 그것은 실전을 그대로 묘사하는 것은 아닐 테죠. 모든 방법론과 프레임워크가 이와 같은 이치를 따른다고 생각합니다.
교과서 vs. 실무 현실 간극
저 역시 처음에는 이 방법론을 잘 따라야 좋겠다고 여겼고, 혹여 뭔가 생략되는 게 보이면 불안한 마음이 들기도 했습니다. 하지만 실무를 오래 하면서 깨닫게 된 점은, 이 프로세스는 ‘지켜야 할 정석’이라기보다, ‘방향을 잃지 않기 위한 나침반’에 가깝다는 것입니다.
현실에서는 Discover 단계에서 충분한 리서치 없이 바로 Define이 이뤄지거나, Develop과 Deliver가 거의 동시에 진행되는 경우도 허다합니다. 이것이 문제 그 자체는 아닙니다. 왜냐하면 일정이나 예산, 리더십의 방향성 등 제약 요소가 많기 때문에 모든 단계를 동일한 깊이와 분량으로 밟는 건 거의 불가능에 가깝기 때문입니다.
그럼에도 불구하고 더블 다이아몬드는 분명 유효한 이유가 있습니다. 그것은 바로, ‘문제 중심적 사고’ 그리고 발산과 수렴의 리듬을 실무자가 느끼도록 돕는 틀이라는 점 아닐까 싶습니다.
실무에서의 실제 활용 방식
저는 실무에서 더블 다이아몬드를 ‘정형화된 프로세스’로 따르기보다 ‘사고의 프레임’으로 활용하고 있습니다. 당연히 상황에 따라 생략하거나 재구성하며 진행하는 것이 훨씬 현실적이고, 오히려 결과물의 품질도 더 나은 경우가 많습니다. 특히 발산과 수렴의 리듬을 그때그때 잘 읽으려고 노력합니다. 이건 꽤나 유용합니다!
예를 들어, 아이데이션 전 이미 솔루션이 정해져 있는 경우에도 저는 가능한 한 최소한의 리서치나 유저 관찰을 통해 ‘현재의 정의(Define)’가 정말 맞는 방향인지 짧게라도 검토해보려 합니다. 물론 이조차 못할 경우는 허다합니다. 그래도 괜찮습니다. 발산이냐 수렴이냐의 목적달성이 흐릿하지만 않다면 말이죠.
또 고객의 Pain Point가 무엇이었는지, 혹은 기존 솔루션이 어떤 한계를 지니고 있었는지를 팀 내에서라도 되짚어 보는 것이죠. 그렇게 짧은 시간 안에라도 문제 중심적인 접근을 한번 거치고 나면, 이후 진행되는 Develop과 Deliver 단계에서도 보다 명확한 기준과 논리를 유지하는데 작지만 도움을 줄 수 있습니다.
비유하자면, 위성사진 수준의 정교함을 가진 지도보다 약도가 때론 더 인지하기 쉬운 것처럼 4D 측면보다 발산과 수렴의 리듬 파악에 주력하면 간단하지만 꽤 큰 도움을 받을 수 있단 것이죠.
유연한 적용의 필요성
이렇게 더블 다이아몬드는 상황에 따라 유연하게 적용해야 오히려 더 효용성이 높아진다고 생각합니다. 모든 프로젝트에서 Discover-Define-Develop-Deliver 순서를 엄격하게 따르는 것은 오히려 프로젝트와 팀을 대단히 경직되게 만들 수 있습니다. 특히 빠르게 제품을 만들어야 하는 애자일한 환경이나, 반복적인 개선 중심의 업무에서는 더더욱 그렇습니다.
대신 저는 다음과 같은 방식으로 프로세스를 유연하게 조합하고 있습니다. 예를 들어, 리서치 시간은 없지만 정성 데이터가 필요할 땐, 기존 VOC(고객의 소리)나 상담 기록 등을 분석해 Define 단계의 근거를 확보할 수 있습니다. Develop과 Deliver가 동시에 요구되는 상황이라면, 빠르게 인터랙션을 구현해 Stakeholder 피드백을 자주 받아가며 보완하려고 노력을 가할 수 있습니다. 이런 판단은 머릿속에 더블 다이아몬드 같은 프레임이 있기 때문에 가능한 결과이기도 합니다. 따라서 정석대로 하지 못하더라도 ‘문제-해결’의 구조를 잊지 않는 것이 핵심입니다.
방법론 집착에서 벗어나기
많은 주니어들이 더블 다이아몬드뿐만 아니라 여러 프레임워크 등을 ‘정석’ 이미지에 가두고 이에 사로잡히곤 합니다. 무언가에 기대로 의탁하고 싶은 심리가 아닐까 합니다. 그러나 실무를 하다 보면 ‘정석대로 안 하는 것이 잘못인가?’라는 불안보다 ‘이 방식이 이 맥락에서 왜 필요한가?’라는 질문이 훨씬 중요하다는 것을 체감하게 됩니다. 그리고 융통성 없이는 한 발자국도 앞으로 나아가기 어려운 상황이 훨씬 더 많기 마련입니다. 그러니 어쩌면 이러한 유연한 운용력이야말로 ‘경력’의 요체라고 볼 수도 있겠습니다.
방법론은 문제를 더 잘 이해하고, 더 나은 해결안을 찾기 위한 ‘도구’ 일뿐이지, 반드시 사수해야 하는 어떤 ‘절대적 진리’가 결코 아니니 어긋남을 불안해할 필요가 전혀 없습니다. 실무는 결국 타협과 선택의 연속입니다. 정해진 시간, 제한된 리소스 안에서 가장 합리적인 판단을 내리는 것. 이것이 ‘실무자의 균형감각’이라고 생각합니다.
실무자로서의 태도 정립
결국 저는 더블 다이아몬드 자체를 따르느냐 마느냐보다, 그 안에 담긴 ‘디자인(D) 사고’의 철학을 잊지 않는 것이 더 중요하다고 생각합니다. 문제를 충분히 들여다봤는지, 사용자의 맥락을 고려했는지, 팀의 아이디어가 근거 기반인지, 빠르게 검증하고 학습하고 있는지. 이런 점들이야말로 실무에서 더블 다이아몬드의 메시지를 어떻게 계승하고 있는지의 척도가 됩니다.
저 역시 프로젝트마다 그 균형을 조금씩 다르게 맞춰가며 일하고 있습니다. 어떤 프로젝트에서는 리서치를 깊게 하고 프로토타이핑은 간소화하고, 또 어떤 프로젝트에서는 이미 검증된 방향성에 맞춰 빠르게 인터랙션을 구현하기도 합니다. 유연하게 해석하면서도, 근거 없는 판단은 지양하는 태도. 이게 바로 제가 실무에서 실천하고 있는 더블 다이아몬드의 현실적인 모습입니다.
이 조차도 복잡하다면 발산이냐 수렴이냐의 맥락을 이해해 이 목적달성에만 집중해 보는 것도 추천합니다.
멘티님이 느낀 불안은 아주 자연스러운 감정이며, 오히려 UXer로서 더 좋은 방향으로 성장하고자 하는 의지의 표현이라 생각합니다. 더블 다이아몬드는 ‘지켜야 할 형식’이 아니라 ‘잃지 말아야 할 방향’ 정도입니다. 실무는 언제나 이상적인 조건과 거리가 멀지만, 그 안에서도 방향성을 유지하는 것이 진짜 실력이고 태도라고 믿습니다. 너무 걱정하지 마시고, 지금처럼 질문을 던지고 스스로 되짚는 과정을 반복해 가며 현장감 있는 UXer로 성장해 가시길 진심으로 응원합니다.
