- Introduction
종이 위에 프로토타입을 설계하고, 실제 사용자들을 대상으로 이것을 테스트하는 기술을 Low-fidelity 또는 lo-fi라 한다. 이 기술은 소프트개발 분야에 있어서 상당히 효과적이고, 간단한 방법이다. 종이 위에 프로토타입을 설계하는 이 Low-fidelity 기술은 개발 초기에 인터페이스를 실제로 수행해 볼 수 있고, 또 실제 사용자와 함께 설계를 테스트 해 볼 수 있기 때문에 이를 시도해 보지 않은 기업에게 잠재적으로 비약적인 해결책을 줄 수 있다. Low-fidelity 프토로타입은 빠르며, 개발 초기 단계에 어느 정도의 결과물을 받을 수 있으며, 이는 High-fidelity에 비해 상대적으로 적은 비용으로 제품을 수정 가능하게 해준다. 또한, High-fidelity에 비해 더 많고, 다양한 아이디어를 테스트할 수 있는 기회를 준다.
- The Problems with Hi-Fi
수년동안, 개발자들은 프로토타입 개발을 위해 데모-빌더부터, 멀티미디어 도구, 고레벨 언어까지 모든 것을 한 번에 사용해왔다. 이는 일명 hi-fi라고 불리는데, 이 방식은 다음과 같은 몇 가지 문제점을 안고 있다.
1) Hi-fi 프로토타입은 실제 개발과 그러한 개발 과정에서의 변화를 주기 위해서 상당한 시간이 소요된다. 반면, Lo-fi 프로토타입은 훨씬 더 빠른 개발 속도를 보이며, 이러한 기술을 배우기도 쉽다.
2) 제품(소프트웨어)을 테스트하는 외양적인 면에 치중하게 된다. 그러한 이유로 개발자는 새로운 혁신적인 아이디어를 생각해내는 것보다 외양 적인 면에 더 시간을 쏟는 경우가 생긴다.
3) 또한, Hi-fi 프로토타입에서의 제품(소프트웨어) 수정은 Lo-fi 프로토타입에서 보다 훨씬 많은 시간과 노력이 요하므로 개발자들은 이러한 제품의 변화에 저항하게 된다.
4) 마지막으로 hi-fi 프로토타입에서 발견된 단 하나의 문제점(bug)이 프로그램 전체를 마비시키는 결과를 가져올 수도 있다.
- A Trojan Meme
Lo-fi 기술을 Jared Spool로부터 적용한 이후(저자는 이를 Trojan Meme로 명명), 저자는 개발을 위해 소요되는 상당한 시간과 비용을 절감하게 된다. 이처럼 개발 초기 단계의 인터페이스 설계에 있어서 반복적으로 시스템을 보다 세련되고, 향상시키는 작업을 formative evaluation이라 한다. 반면, 제품이 완성된 이후, 단 한 번 최종적으로 수행하는 평가 작업을 summary evaluation이라 한다. Summary evaluation은 작업이 어느 정도 잘 수행되었는지 알 수는 있지만, 근본적인 문제를 해결하기에는 너무 늦다는 단점이 있다. 특이할 만한 것은 무엇보다도 이러한 Lo-fi 프로토타입은 개발에 있어서 아주 중요한 요소로 작용한다는 것이다. 왜냐하면 Lo-fi 프로토타입은 개발자가 사용성과 formative evaluation에 대해서 어느 정도 깊이 생각하도록 요구하며, 뿐만 아니라 실제 코드를 작성하기 이전에 개발자가 자신이 설계한 것에 대해서 보다 더 심사 숙고하여 향상 시킬 수 있는 기회를 최대화해주기 때문이다.
- Building a Lo-Fi Prototype
Lo-fi 프로토타입을 설계하기 위해서는 다음과 같은 순서의 작업을 요한다. 먼저, 시스템을 개발하기 위해 필요한 구성 요소들(kit)을 모을 필요가 있다. 그런 다음 최종 마감 시한을 설정한다. 개발자는 메뉴를 어떻게 구성할지, 툴 팔렛트를 어떻게 설정할지 등 여러 가지의 결정 과제를 가지고 있지만, 이 것을 한 번에 해결하려는 것은 오히려 개발자를 혼란스럽게 만든다. 그러므로 개발자는 각각의 중요한 과제에 대해서 데드라인을 설정한다. 그럼으로써, 개발자는 전 보다 각 작업에 대한 적절한 시간 분배와 미리 사전 계획된 반복적인 시스템 향상 작업을 통해서 더 질 높은 시스템을 구축할 수 있게 된다. 마지막으로 단지 시스템에 대한 예시 그림이나 삽화 정도가 아닌 모델을 구상한다. 단지, 종이 위에 그리고, 적는 것 뿐이지만, 실제 사용자가 시스템을 사용한다고 가정하고, 모든 가능한 경우와 시나리오를 기반으로 모델을 만들어내는 것이다. Lo-fi를 통해서 생성된 이러한 모델은 비록 종이 상에서 보여지는 가상의 것으로 실제적인 것은 아니지만, 이 후, 실제 개발 단계에서 상당히 중요하게 사용된다.
- Preparing for a Test
위와 같은 방법으로 Lo-fi 프로토타입을 적절히 설계하였다 하더라도 충분한 준비 과정 없이 그것들이 설계되었다면 쓸모 없는 테스트 결과가 나올 수도 있다. 이러한 것을 방지하기 위해 설계 과정에서 다음의 요소들을 주요하게 다루어야 한다.
첫째로 적절한 프로토타입 테스터를 선택해야 한다. 개발자는 자신의 소프트웨어를 사용할 사람들에 대해 이해하기 위해 충분한 사용자 & 업무 분석을 해야 한다. 그리하여 개발자는 소프트웨어에 관한 적절한 질문 목록을 만들고, 이를 통해서 모든 가능한 테스트 후보자들로부터 적절한 테스트 대표자들을 선택해야 한다. 또한, 최종적으로 완성된 제품을 사용할 것으로 예상되는 사람들과 해당 테스트에 관한 적합한 지식과 기술을 가지고 있는 사람들을 테스터로 선택하는 것도 중요한 일이다. 마지막으로 다양한 분류, 계층의 사람들을 선택하여 보다 폭 넓은 피드백을 받아내는 것도 테스터를 선택하는 데에 있어서 중요하다.
두 번째로 가상의 테스트 시나리오를 작성하고 이를 테스트한다. 업무 분석(Task Analysis) 단계에서 산출된 결과를 바탕으로 시나리오를 제작, 선택하고, 샘플 데이터를 테스터에게 제공하여 해당 프로토타입 시스템을 검토한다. 이러한 테스트 시나리오 작업에 있어서 중요한 것은 이 것이 실제적인 상황에서와 같이 테스트되어야 한다는 것이다. 비현실적인 시나리오와 데이터는 설계된 시스템의 신뢰도에 치명적인 손상을 줄 수 있다.
마지막은 이러한 설계와 시나리오를 바탕으로 실제적으로 적용 하는 것이다. 외부의 사람들에게 테스트 하기 전에 먼저 내부적으로 반복적인 테스트를 거치도록 한다. 여기서 팀 구성원들은 편안한 상태에서 이를 수행할 수 있도록 하며, 또, 적절한 정보를 얻기 위해 필요한 공급과 장비 등도 갖추도록 한다.
- Conducting a Test
실제적으로 테스트를 수행하기 위해서는 4명의 다음과 같은 역할을 가진 사람이 필요하다.
1) Greeter : 사용자(테스터)를 반기는 사람으로써 다른 팀원들이 테스트를 준비하는 동안 사용자에게 안내하고, 테스트를 위한 기본 작업을 수행한다.
2) Facilitator : 테스트 작업이 완료되면 Facilitator가 주도를 한다. 테스트 동안 오직 Facilitator만이자유롭게 테스터와 이야기를 나눌 수 있다. 그리고 사용자에게 지시 사항과 명령을 전달, 테스트 동안 사용자의 생각을 자유롭게 표현하도록 장려, 주어진 시간 내에 모든 작업이 적절히 수행되도록 하는 역할을 맡는다.
3) Computer : 한 명의 팀원은 마치 컴퓨터와 같이 행동한다. 작성된 프로토타입을 기반으로 실제 컴퓨터가 어떻게 행동할지를 예상하여 이와 유사하게 논리적으로 행동하도록 한다. 중요한 것은 단지 사용자와의 상호 작용에 있어서 사용자가 내리는 명령에 적합한 반응만을 보여야 하며, 그 외의 부가적인 설명이나 불필요한 피드백은 주지 않도록 한다.
4) Observer : 나머지 팀원은 이러한 테스트 과정을 관찰하면서 발견된 문제점이나 해결책, 기타 다양한 정보를 기록한다.
위에 주어진 4가지 역할에 맞게 또, 주어진 역할의 순서대로 사용자는 테스트에 임하게 된다. 각각의 업무는 팀원이 지치지 않도록 적절하게 돌아가며 수행되도록 한다. 또한 일반적으로 테스트 세션은 한시간이 조금 넘게 수행되며, 준비 단계, 테스트 수행, 결과 보고 등의 단계를 가지고 있다.
- Evaluating Results
Lo-fi 프로토타입 이던 간에 Hi-fi 프로토타입 이던 간에 적당한 정보가 수집되지 못하거나 개발자의 연구 결과 등에 기반하여 제품이 개량 되지 못한다면 이는 전혀 쓸모없을 수도 있다. 즉, 가치 있는 프로토타입을 위해서는 테스트 세션에 동안에 수집된 다양한 정보들을 적절히 분류하고, 우선 순위를 매기는 데에 많은 시간을 투자해야 한다. 즉 각 팀원들은 특정 인터페이스 구성 요소와 관련이 있는 데이터(예-테스트 세션에서의 노트 카드(Note Card))를 적절히 분류한다. 또한, 테스트 과정에서 발견된 문제점을 적절하게 중요한 순으로 우선 순위를 매기고, 간추려 분류하기 위해 적절한 업무 분담 또한 이루어져야 한다.
- Try It
처음으로 Lo-fi 프로토타입을 접하는 사람이나, 이러한 기술을 접한지 오래되지 않은 사람은 이 기술을 시도해보고, 실패를 겪고, 쉽게 회의감에 빠질 가능성이 있다. 하지만, 더 시간을 가지고, 꾸준히 이 기술을 시도해 본다면 반드시 소프트웨어 설계에 있어서 좋은 결과를 산출해 낼 수 있을 것이다. 이미 Hi-fi 프로토타입을 가지고 작업을 하고 있다면 이를 멈추게 할 수는 없겠지만, 아직 설계에 있어서 초기 단계이거나 프로토타입에 대해서 사용해본 적이 없다면 (또는 더 많은 것에 대해 배울 필요가 있다면) Lo-fi 프로토타입은 적절한 선택이 될 수 있을 것이다.