brunch

You can make anything
by writing

C.S.Lewis

by 송기연 Jan 15. 2024

디자인 프로세스에 대한 단상-8

ep 08.  정의하기(Define)가 잘못되면 아니한 만 못하다

수많은 정보를 데이터로 바꾸고 나는 과정을 거치면, 이 데이터들에 대해서 의미를 부여해야 한다. 데이터는 그 자체로는 아무 쓸모가 없다. 해당 프로젝트에 의미 있는 해석을 도출해야 데이터로서 가치가 있다. 여기서 말하는 가치란, 전체 프로젝트의 방향을 결정하는 것이다. 주로, 디자인 RFP들의 조합으로 만들어지는 디자인콘셉트가 되겠다. 디자인 콘셉트가 방향이라면, 디자인 RFP는 그 방향으로 가는데 필요한 목록이다. 이 두 가지는 이후 진행될 모든 결과물의 초기 시작점이다. 이제야 비로소 본격적인 디자인이 시작된다. 


두 개의 점을 잇는 가장 최단거리는 직선이다. 이 말은 처음 출발 시 방향을 정확하게 잡지 않으면 수정, 실패 등이 눈앞에서 쌓이게 된다는 의미다. 보통, 하나의 프로젝트를 마치고 나서 뒤를 돌아볼 때가 있다. 처음 출발시점을 보면, 보통 빙글빙글 돌아서 오거나 하지 않았어도 될 시행착오들이 많이 보인다. 물론, 지나고 나서의 관점이겠지만, 최대한 효율적인 루트로도 올 수 있었을 거라는 후회가 자주 든다. 이것 역시, 조사하기(Discover)의 관점에서 볼 수 있는 것이다. 아무튼, 프로젝트의 방향을 정한다는 것은 쉬운 일이 아니다. 아직 가지 않은 그 길이 옳은지, 아닌지는 아무도 모른다. 여기서 방향을 설정하는 것을 아주 정확한 방향을 정한다는 의미는 아니다. 그렇게 되면 얼마나 좋을까. 현실에서는 어느 정도 큰 틀의 방향을 정한다는 의미이다. 예를 들어서, 컴퓨터 마우스를 개발하는 디자인을 한다고 하자. 대단히 많은 라인업과 다양한 사용자 층을 모두 만족할 수는 없다. 아무래도 개발예산, 기간, 기능, 포지셔닝 등 클라이언트가 가진 기본적인 콘셉트나 RFP가 있을 것이다. 이를 정보의 균형을 위한 레벨 맞추기(Leveling)를 통해, 디자이너의 시각에서 다시 조사한다. 사용자 그룹과 유통, 판매, 제조 등 프로젝트에 유의미한 영향을 미칠 수 있는 요소를 찾는다. 그래서, 나온 데이터를 분석하고 해석해서, 초기 클라이언트의 콘셉트와 RFP와 비교한다. 일치하는 부분은 강화하고, 차이나는 부분은 재조사나 회의, 전문가 의견, 토론 등을 거쳐서 합의된 방향을 설정한다. 이 단계에서 클라이언트나 다른 이해관계자가 미처 생각지 못했던 RFP항목이나 콘셉트가 발견된다면 유레카인 것이다. 이른바 진짜 문제 정의하기라고도 표현되는 이 것은 전체 디자인개발 프로젝트에서 중요한 역할을 할 수 있다. 클라이언트나 핵심 이해관계자의 획일적 사고를 벗어난 외부 디자이너의 확장된 분석을 통한 콘셉트의 재설정이기에 더욱 의미 있다. 그러나, 오해하지 말아야 할 것이 있다. 반드시, 진짜 문제정의하기가 항상 존재하는 것은 아니다. 거의 대부분 클라이언트의 RFP나 콘셉트가 옳을 확률이 높다. 그것을 다시 한번 확정하고, 더욱 세분화하며, 내용을 강화하는 것이 디자인의 주요한 역할이다. 복권이 매번 당첨되지 않는다. 진짜 문제정의하기가 발견되고, 이를 수용하는 분위기에서 확정까지 된다면 이는 그야말로 큰일 날 뻔한 상황이었던 것이다. 


이 단계에서 정해지는 RFP는 MECE 해야 한다. RFP는 Requst For Proposal(요구조건 세부항목)이고, MECE는 Mutually(상호 간), Exclusive(중복되지 않고), Collectively(전체적으로), Exhaustive(완전히 누락되지 않게) 구성해야 한다는 의미이다. 즉, 전체 RFP의 총합은 각 항목들의 총합이 되어야 한다. 이는 어떤 사항을 중복되지 않고, 누락되지도 않게 하여 부분으로 전체를 파악한다는 것을 의미하는 아주 중요한 개념이다. 제품디자인이라면 주로 기능이 위주가 될 것이고, CMF에 의한 항목 별 사용성이 주요한 RFP가 된다.

제품 이외에 서비스디자인에서는 최종결과물로 예상되는 시스템이나 정책 등에서 다뤄야 하는 항목 별 중요성도 MECE 한 디자인 RFP항목이 될 것이다. 이런 정의하기(Define)가 중요한 것은 프로젝트의 마무리 단계가 되면 프로토타입이 만들어진다. 이렇게 만들어진 프로토타입은 양산(제품일 시)이나 실행(서비스일 시)을 위한 검증단계를 거쳐야 한다. 사용성 테스트나 사용자 시나리오를 통해서 미처 발견하지 못했던 weak point나 개선해야 할 항목을 찾을 수 있다. 이때 기준이 되는 것이 바로 콘셉트이다. 초기에 설정한 이 콘셉트의 방향대로 잘 진행이 되었는지를 세부 RFP항목을 점검함으로써 이룰 수 있다. 이 단계에서도 자연스럽게 데이터가 모이게 된다. 프로젝트 극초기 레벨 맞추기(Leveling) 때의 데이터, 조사하기(Discover) 단계에서 콘셉트와 RFP를 위해 수집되거나 발견되고 정리된 데이터, 프로토타이핑을 완성하기까지 쌓인 데이터, 최종단계에서 이를 검증하는 단계에서의 데이터 수집은 모두 조사하기의 연장선이다. 보통 프로토타입까지 진행된 디자인 프로젝트를 수행한 디자이너나 이해관계자라고 하면 해당 사안에 대한 많은 지식이 쌓였을 것이다. 그러나, 초기에 설정한 콘셉트와 RFP 이외의 아이디어나 데이터는 프로젝트의 곁가지이다. 이 단계에서 가장 중요하게 확인하고 제대로 기획대로 구현(Tangible)되었는지의 기준은 정성적인 콘셉트와 정량적인 RFP다. 


사용성 테스트를 많이 시행하는데, 이는 디자인 프로젝트 성격마다 조금씩 달리해야 한다. 제대로 된 사용성은 양산제품이나 서비스(어플 등)를 대상으로 해야 의미 있다. 아직 미완성 단계인 프로토타입을 가지고 하는 사용성 테스트는 어디까지나 데이터를 감안해서 해석해야 한다. 그럼에도 불구하고 프로젝트의 최종 완성도를 위해서는 냉혹한 검증과정을 거쳐야 한다. 그래야 제대로 된 방향으로 왔는지, 혹은 중간에 다양한 노이즈로 인해 프로젝트의 큰 줄기가 변했는지를 알 수 있다. 


프로젝트가 진행되면서 콘셉트가 바뀔 수 있다. 더 좋은 방향으로 개선되거나 하는 일도 존재한다. 그러나, 기본은 초기 프로젝트의 방향과 RFP에 맞게 마무리하는 것이 더 중요하다고 생각한다. 인하우스 디자이너라고 해도 마찬가지다. 하나를 완벽하게 마무리하지 않고, 주변 일들과 혹은 이후 일들과 연계해서 이어나가는 행위는 언뜻 합리적일 수 있어 보이지만 그렇지 않다. 시작이 있으면 끝이 있다. 새로운 프로젝트는 새롭게 해야 한다. 연관된 작은 프로젝트가 중간 과정에서 관여될 수 있겠으나 큰 줄기는 하나로 진행되어야 한다. 이렇게 정의하기는 전체 프로젝트의 방향을 결정하는 아주 중요한 핵심요소다. 클라이언트나 이해관계자의 니즈가 조건 대비 높거나 모호할 때가 많을 것이다. 이를 잘 수렴하고, 정리하는 것 역시 디자이너의 뛰어난 역량이다. 모든 프로젝트는 초기 명확하지 않다. 최대한 이를 선명하게 정리하고, 앞으로 나갈 수 있는 길잡이 역할을 정의하기(Define) 단계에서 수행한 뒤 본격적으로 달려 나가야 한다. 뒤가 마무리 안된 상태에서 급하게 출발하는 프로젝트는 항상 말썽과 논란이 생기고, 대부분 정해진 기간을 넘어서거나 만족스러운 결과를 도출하지 못할 가능성이 크다. 




정의하기(Define)가 명쾌하지 않으면, 일단 멈춰야 한다. 

정성적 콘셉트와 정량적 RFP를 최대한 명확히 정하고 나면, 힘차게 달릴 일만 남는다. 

작가의 이전글 디자인프로세스에 대한 단상-7
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari