와이어프레임이 추상적인 것을 구체화해 어떻게 보이는지를 가늠하고 협의하는 Tool이라면(와이어프레임, 동상이몽을 해결하거나 좁히거나!), 프로토타입은 실제 서비스 출시 전에 어떻게 작동하는지와 서비스의 전체적인 느낌을 알기 위해 만드는 일종의 시제품을 말한다.
프로토타입은 전체 프로세스의 모든 화면 디자인 파일이 있고 세부적인 버튼과 링크들이 다 작동하는 실제와 거의 근접한 수준까지 만들기도 하고, 이미지 파일 하나에 해당 페이지의 콘텐츠와 디자인적인 느낌만 알 수 있게 담고 실제 버튼과 링크는 작동하지 않는 간단한 형태까지 해당 서비스의 목적에 따라 다양하게 만들 수 있다. (더 간단하게는 파워포인트로 필요한 화면만 만들어 본다거나 이 화면들을 사용 순서에 따라 화면이 작동하는 것처럼 순서대로 종이를 배치해서 해볼 수도 있다)
쇼핑몰의 상품 페이지에서 티셔츠를 구매하는 경우를 가정해 보자. 상품 페이지에서 색상과 사이즈를 선택하고 장바구니에 담아 쿠폰 적용을 하고 카드 결제를 한 뒤 마이페이지에서 주문 상세 내역과 배송 현황을 확인하는 것까지를 전체 프로세스로 봤을 때, 이 과정 전체를 하기도 하고 다른 프로세스는 특별한 문제가 없고 주문하기만 개선이 필요한 경우라면 배송정보를 넣고 결제 수단을 선택하는 주문하기 페이지만 잘라서 프로토타입을 만들어 볼 수도 있다.
또한 주문서 페이지의 경우도 실제 주문자와 배송정보의 빈칸을 직접 다 입력하고 카드, 쿠폰 등 결제 수단을 선택하게 해서 결제가 이루어지는 과정과 유사하게 프로토타입을 만들 수있다. 반면 디자인 된 이미지 파일 하나에 다 가상의 정보가 입력되어 있고 결제 정보도 세팅되어 주문하기 페이지의 전체적인 느낌과 기능적으로 필요한 게 빠져있는지와 이상 유무만 살펴볼 수 있게 간소화해 만들 수도 있다.
프로토타입은 실제 웹페이지나 서비스를 개발하기 전에 서비스의 컨셉과 방향성이 맞는지 또는 미처 생각하지 못했던 고객 사용의 어려움이 있는지 등 본격적인 자원이 투입되기 전에 검증을 하는데 목적이 있다. 그렇기 때문에 그 목적과 필요에 따라 유연하게 만들면 되지 정해진 규칙이나 엄격하게 실제 서비스와 꼭 같아야 한다는 법은 없다.
아울러 모든 페이지와 서비스들에 대해 프로토타입을 만들 필요는 없다. 왜냐하면 프로토타입을 만드는 것 자체도 공수가 들어가는 일이고 이를 통해 내부 검토뿐 아니라 고객 테스트까지 한다면 굉장히 자원이 많이 들어가는 일이 되기 때문이다.
예를 들어 로그인 같은 경우는 아이디와 비밀번호를 입력하고 로그인 버튼만 누르면 되기 때문에 특별히 예외적인 상황이나 복잡성, 다양성이 없어 그냥 기본에 충실하게 서비스를 제공하면 된다. 하지만 쇼핑몰의 주문 페이지는 각종 입력 사항이 많고, 결제 방법 설정이나 할인 쿠폰 적용 등 복잡도가 높고 다양한 케이스들이 나올 수 있어 사용자가 이해하거나 사용이 어려운 기능들이 있을 수도 있어 간결한 형태의 표준화된 서비스라고 보기는 힘들다.
두 예시의 차이처럼 일정 수준 표준화된 영역은 굳이 프로토타입을 안 만들어도 되지만 반드시 기능적으로 에러 없이 사용이 가능해야 하는데 복잡성이 높은 서비스 영역은 가급적 프로토타입을 통해 미리 점검하고 개발을 진행하는 게 좋다.
프로토타입을 통해 미리 문제점을 발견하고 개선 및 수정을 통해 시행착오를 줄일 수 있다면 그 프로토타입은 성공적인 것이라고 할 수 있다. 그리고 프로토타입 단계에서 선제적인 조치가 잘 취해진다면 고객 불편함도 미연에 방지하고 추후 디자인, 개발 과정에서 시행착오나 수정에 따라 발생하는 자원과 비용을 줄일 수 있다.
또 어떤 경우는 아이디어 수준에서는 잘 모르고 진행하다가 프로토타입 단계에서 고객 조사나 내부 논의 중 고객 사용성이 어렵거나 비즈니스 목표와 맞지 않는 게 파악되기도 한다.
그런 경우 해당 서비스 출시하지 않기로 하는 경우도 있는데 디자인, 개발까지 완료하고 안 좋은 고객 경험을 준 뒤 욕을 먹으면서(?) 서비스를 접는 것보다 여러 면에서 더 잘 된(?) 일이 되기도 한다. 그렇기 때문에 중요한 영역의 비표준화된 서비스 영역은 프로토타입을 통해 작업을 진행하는 게 길게 보면 훨씬 효율적인 방식이다.
