리스크는 줄이고 실행은 빠르게, 프로토타입 제작 성공하는 법

6분

2021.01.08.

2.7K

중소기업이나 스타트업은 제품을 개발할 때, 리스크를 줄이기 위해 최종제품을 출시하기 전, 프로토타입을 먼저 출시하는 경우가 많습니다. 프로토타입을 제작하는 과정을 최적화하면 가장 공격받기 쉬운 결함들을 제거하고, 효율적인 모델을 만들 수 있는데요. 여러분이 새로운 비즈니스를 구상 중이라면 '프로토타입'은 반드시 필요합니다. 그래서 이번 시간 위시켓은 여러분께 프로토타입이 무엇인지, 이를 만들기 위해서 실제로 무엇을 해야 하는지 꼼꼼하고 자세하게 알아보는 시간을 갖고자 합니다. 빠르게 아이디어를 실행하고, 실패 요인은 줄이고 싶다면 집중해 주세요!

'프로토타입'이 뭘까?

프로토타입은 디자인 개발의 탐색 단계에서 찾아낸 내용들을 실제로 구현해보는 겁니다. 따라서 디자인 사고의 맥락에서 실행되는 것이 포인트이며, 사용자 중심의 디자인을 구현할 수 있어야 하죠. 프로토타입을 통해서 문제를 해결하는 과정을 거치면 최종 결과물을 이용하는 사용자들과 안정적으로 상호작용하고, 수익성과 생산성까지 최대화할 수 있게 됩니다.

효율적인 프로토타입 테스트를 위해 알아야 할 점들

01. 최소한의 변수로 테스트하기

여러분이 제어할 수 있을 정도의 변수를 이용해 테스트하는 것이 좋습니다. 너무 많은 변수들을 설정해서 유저들에게 혼란을 일으켜서는 안됩니다. 여러분이 테스트하고자 하는 특정 변수가 유저들의 눈에 확실히 띌 수 있도록 디자인하세요. <좋은 프로토타입의 예> 다음은 P2P 결제 앱을 위해 만든 두 가지의 디자인입니다. 이 프로토타입의 목적은 '현금 상환이 가능할 때, 유저들이 인식하는 앱의 가치가 올라가는가?'입니다.

[유형 A: 기본 유형/ 유형 B: 현금 상환 유형]

유형 A에서는 결제 앱의 기본적인 구성들을 볼 수 있습니다. 유형 B는 유형 A와 거의 같지만 단 한 가지 부분이 다른데요. 바로 'Redeem(현금상환)' 버튼이 있다는 겁니다. 이 버튼은 앱에 '적립금이나 차액을 현금화하는 기능'이 있다는 사실을 유저에게 알려줍니다. 디자인 특면이 테스트에 영향을 미치지 않게 두 가지 유형 모두 같은 레이아웃과 색채 배열로 이루어져 있는 것도 확인할 수 있죠. 이처럼 프로토타입 테스트에서 '시험대에 올려야 할 변수'를 제외한 나머지 변수들은 동일해야 합니다. 테스트 변수를 제외한 나머지 요소들을 제어함으로써 특정한 변화가 유저의 가치 인식에 미치는 영향을 정확하게 관찰할 수 있기 때문이죠. 보통 프로토타입에서 시험하는 변수들은 문구, 버튼의 위치, 돌출형 스크린 혹은 이미지 같은 것들인데요. 이러한 변수들은 유저들이 발견하기 쉬워야 하고, 유의미한 인식의 변화를 이끌어낼 만한 것이어야 합니다. <나쁜 프로토타입의 예>

위의 예시는 두 개의 상이한 시각적 접근을 보여주고 있습니다. 아이콘 모양부터 내부 콘텐츠의 색, 모양 등 전부 다른데요. 이 테스트에서는 정확히 어떤 변수가 유저의 반응을 촉발했는지 구별할 수 없습니다.

02. 현실적인 요소는 신경 쓰지 말자

프로토타입 테스트에서는 시험해봐야 할 변수들에 대해서만 생각하세요. 물론 최종적으로 나올 제품의 경우, 선택한 색상이 브랜드 이미지와 맞아떨어지는지, 사용한 사진들은 직접 찍은 것인지, 법적으로 소송에 휘말릴 부분은 없는지, 모든 링크들이 제대로 작동하는지 등 여러 측면에서 면밀하게 검토되어야 합니다. 하지만 프로토타입 테스트의 목적은 특정한 부분에 대한 유저의 반응과 가치 인식에 대해 알아보는 것이므로 이러한 현실적인 요소들은 신경 쓰지 않으셔도 됩니다. 프로토타입 테스트는 '비용 절약'을 하기 위한 절차라는 것을 잊지 마세요. 완전한 디자인을 위해 시간과 자산을 쏟게 되면, 이 테스트의 본래 목적에서 벗어나게 됩니다.

03. 테스트 경로를 명확하게 설정하기

프로토타입 테스트를 실행하는 유저들은 매우 변덕이 심합니다. 눈앞에 있는 프로토타입이 인상적이지 않거나 어렵다고 생각되면 테스트를 끝내지 않고 그만두죠. 또한 유저들은 프로토타입을 사용해보고 계속적으로 이 제품을 이용할지, 유료 제품으로 구매할지를 결정합니다. 따라서 최종제품을 사용하는 방법이 다소 복잡해지더라도 프로토타입 테스트를 사용하는 경로는 제한적이고 단순해야 하는데요. 여러분이 테스트하고자 하는 핵심적인 요소 이외의 쓸데없는 요소들은 모조리 제거하는 게 좋습니다. 모든 버튼이 작동할 필요도, 모든 버튼들에 대한 유저의 피드백을 받을 필요도 없죠. 유저들이 제품을 사용하고 싶은 마음이 들게 할 부분만 가동하면 됩니다. <예시: 트립어드바이저> 트립어드바이저에서 호텔 예약 과정에 대한 피드백을 모으기 위해서는 '호텔 예약 과정에 한정된 스크린'만 유저들에게 보이면 됩니다. 유저들이 예약을 하기 위한 단계를 한눈에 밟아갈 수 있도록 하는 것이죠. 첫 번째 이미지의 빨간 박스가 '유저가 클릭하도록 유도해야 하는 공간'입니다. 이 프로토타입은 호텔 예약 과정만을 테스트한다는걸, 잊지 마세요. 항공권이나 식당 검색과 같이 호텔 예약과 상관없는 요소들은 이 테스트에서 포함되지 않습니다.

첫 번째 단계: 원하는 호텔을 찾기 위한 간단한 정보 입력

두 번째 단계: 장소와 날짜를 설정한 뒤, 'Find Hotels' 버튼 클릭

세 번째 단계: 이전 단계에서 설정한 조건들에 맞는 호텔 리스트 검색

네 번째 단계: 선택한 호텔을 예약하기 위한 정보 추가 입력

위의 예시 이미지들은 호텔 예약의 과정을 보여주는 기본 단계입니다. 이 단계들을 담는 화면에는 테스트하고자 하는 내용만 들어가 있어야 하죠. 그렇지 않으면 관련 없는 부분이 유저들의 호기심을 자극해서 의도하지 않은 부분에 대한 피드백을 받을 확률이 높아집니다.

04. 유저의 피드백뿐만 아니라 '행동 패턴'도 관찰하자.

초기의 프로토타입 테스트는 한 개나 두 개의 화면에 대한 유저들의 응답을 받는 정도로 간단할 수 있습니다. 하지만 점차 테스트가 반복되면 유저의 행동 패턴도 파악할 수 있죠. 어떤 순서로 유저들이 화면을 이동하는지, 혹은 어떤 부분에서 오랜 시간을 보내는지 등을 파악할 수 있다는 말입니다. 테스트를 계속할수록 유저들의 행동 패턴에 대한 통찰력도 기를 수 있을겁니다!

> 이 글은 'Optimizing Your Design For Rapid Prototype Testing'을 각색하여 작성되었습니다.

로그인하고 자유롭게 의견을 남겨주세요.