Scenario-based Design

시나리오란? 스크린에 영사할 것을 전제로 하여 영화형식에 따라서 문장으로 작성한 각본을 말한다. 원래 이 말은 16세기 이탈리아의 즉흥희극 콤메디아델라르테(commedia dell’arte)에서 극의 줄거리와 배우의 역할 등을 표시한 메모를 일컫는 것이었다. 그리고 초기의 영화각본도 간단한 메모 비슷한 것이었기 때문에 이 시나리오라는 용어가 쓰이게 되었다.

또한 영화제작이 기업화되고 그 표현기법도 복잡해짐에 따라서 점차로 상세한 각본이 필요하게 되어, 무성영화시대 말기인 1920년대 후반에는 시나리오와 그 작가(시나리오 라이터)의 비중이 커지기 시작하였다. 특히 토키시대가 개막되면서 음성의 효과가 위력을 발휘하게 되자, 그 지위는 더욱 부각되기에 이르렀다.

그러나 오늘날 영국이나 미국에서는 이 시나리오라는 말 대신 ‘스크린 플레이(screen play)’라는 용어가 널리 사용되고 있다. 또 원작 소설 •희곡 •다큐멘터리 등을 영화촬영에 알맞도록 개작하는 것을 ‘어댑테이션(adaptation)’이라 일컫고, 거기에서 영화각본을 만드는 것이 보통이며, 다시 각본에서 세밀한 촬영지시를 모두 써 놓은 ‘콘티뉴이티(continuity)’를 만든다.

그리고 특히 대사만을 전달하는 라이터가 따로 있는 경우도 있고 여러 사람이 협력하여 하나의 각본을 합작하는 예도 많다. 시나리오의 형식은 작가에 따라서 또는 나라에 따라서 다소의 차이가 있어 일정하지 않으나, 유럽과 미국에서는 ‘콘티뉴이티’에 가까운 것이 많고 동양에서는 영화의 이미지를 부각시키기 위하여 문학적으로 표현한 것이 많다.

어쨌든 시나리오는 글자에 의하여 영화의 시청각적인 묘사를 구체적으로 표현하는 것을 목적으로 하고 있다. 영화는 연극에 비하여 장면의 수가 대단히 많아서 시나리오에서는 그 분할과 구성이 중요시되며, 또 장면을 묘사하는 설명문 역시 대사(臺詞)와 마찬가지로 중요시된다.

영화의 각본은 아직 희곡의 경우처럼 독립된 문학의 장르로서 인정 받지 못하고 있으나, 영화제작에 있어 촬영 이전의 단계에서 가장 중요시되는 것으로 이것을 건축의 설계도나 청사진에 비유하는 경우도 많고, 음악의 악보와 비슷한 것으로 생각하는 사람도 있다. 또 소설 등의 원작에 의존하지 않은 창작 대본을, 특히 오리지널 시나리오라고 일컫는다. – 두산세계대백과 사전

유선과 무선의 경계가 사라지고 디바이스가 발전함에 따라 인터넷과 컴퓨팅 환경이 PC에서만 이루어지지 않고 실제 Situation에서 적용되는 시점에 우리는 와 있다.

웹을 기획하고 디자인한다는 것이 그리 쉬운 일만은 아니지만 PC를 벗어난 실 상황에서 어떻게 인터넷과 컴퓨팅 기술이 위치해야 하는지를 파악하고 실천하는 것은 더욱 복잡한 일이다. 이런 상황에서 David & Danny는 Scenario-based Design을 다루고자 한다.

우리 인간이 효과적으로 커뮤니케이션 할 수 있는 이유는 대화가 언어의 교환에만 의존한 것이 아니라 대화를 나누고 있는 당사자를 둘러싼 상황(물리적 상황, 정서적 상황, 역사적 상황 등)에 대한 정보(implicit situational information or Context)를 인간이 적극적으로 활용하기 때문에 가능하다.

‘컴퓨터가 주변 상황, 즉 Context를 이해한다면’ 이란 주제로 시작되는 Context-Aware 서비스는 인터넷의 진보와 디바이스의 한계가 사라지는 접점에서 지배적인 서비스 철학으로 우리에게 다가오고 있다.

그런데 Context-Aware Service에 대해 토론을 하면 이것을 하나의 킬러앱으로 받아들이는 사람들이 많다. 그리고 대부분 인공지능 기술을 먼저 떠올리곤 하면서 곧 ‘현실성이 부족한 것’으로 취급되는 것을 목격한다.

Context-Aware Service는 하나의 애플리케이션을 의미하지 않는다. 그리고 인공지능 기술이 필수적이긴 하지만 그것만은 아니다. 오히려 서비스를 받는 고객을 어떻게 이해하고 그것을 어떤 시나리오로 전개할 것인가가 사실 더 중요하다.

이런 관점에서 Scenario-Based Design은 Context-Aware Service를 기획하는데 있어 필수적인 요소로 받아들여지고 있다. Scenario-Based Design이란 고객의 시나리오를 이해하고 그것을 element로, function으로, 그리고 서비스로 만들어 가는 프로세스를 말한다.

다시 말해 Scenario-Based Design의 Flow는 1. 고객의 시나리오를 작성하고 2. 그것으로부터 기능을 추출하고 3. 디자인과 프로토타입을 개발하는 3단계 구성을 지니고 있다. 3단계 플로우에 대한 방법론은 제각기 다를 수 있다. 여기서는 먼저 포레스터가 이야기하는 시나리오 디자인을 살펴보고자 한다. 포레스터는 시나리오 디자인을 다음과 같이 정의하고 있다.

Scenario Design is: An approach to creating end-to-end, cross-channel experiences based on an understanding of users, their goals, and their behavior.

포레스터의 정의는 학계에서 연구되는 Scenario-based Design의 영역을 다소 좁힌 감이 있으나 비즈니스적인 관점으로의 해석을 시도하면서 누가 고객인가?, 그들의 목적은 무엇인가?, 그리고 그들은 어떻게 목적을 달성하는가?라는 근본 취지에 대해서는 잘 지적하고 있다.그리고 각 질문들에 대한 답을 얻기 위해 다음과 같은 방법을 제시하고 있다.

1. Who are your users?
Interview real, live people: 회사는 고객의 실제 동기를 찾아 내야 한다. First Union(미국의 거대 금융회사)은 고객과의 직접 인터뷰를 통해 고객 분류를 데모그래픽 접근이 아닌 금융 관리 형태로 분류할 수 있었다.

Develop detailed personas: 개별 고객을 하나의 배우로 가정하는 방식이다. 고객의 Explicit한 정보들은 물론 그들의 좌우명, 현재 가장 관심을 갖는 특정 일이나 취미 등도 포함시켜야 한다.

2. What are their goals?
Observe users as they pursue their goals: Ethnographic 방식을 사용함으로써 회사는 유저들이 접근하는 진짜 목적을 찾을 수 있다. United Airlines Cargo는 화물발송자가 화물을 붙이기 전 공항의 날씨를 먼저 알아본다는 사실을 발견할 수 있었다. 이것은 바로 UAL의 웹사이트를 바꾸어 놓았다.

Document goal specifics: 회사의 관점에서 볼 때 고객이 쇼핑 사이트를 브라우징 한다는 것은 ‘쇼핑을 하고 있다’라고 판단할 수 있다. 그러나 고객은 쇼핑이 아닌 트랜드를 위한 정보수집을 위한 행위일 수 있다. 만약 TV를 본다고 해도 실제로는 DVD를 구입하고자 하는 고객일 수 있다는 것이다.

3. How can users achieve their goals?
Document activities, tasks, and task-specific information: 복잡한 행동을 단순한 요소로 분류해야 한다. 셔츠를 살 때 고객은 여러 가지 행동을 하게 된다. 각각의 행동은 ‘사이즈를 비교한다’ 등의 복합적인 task로 구성된다. 또 각각의 태스크들은 더 작은 정보들의 조각으로 나뉜다. 예를 들어 깃의 모양이나 소매의 형태 말이다.

Map user’s paths to find potential shortcuts: 위에서 적은 내용들을 마케터, 개발자, 디자이너들이 이해할 수 있는 형태로 재 작업 해야 한다. 그래서 다이어그램과 고객 스텝이 반영된 도큐멘테이션이 완성된다.

Design incrementally better ways for users to reach success: 사람들은 그들만을 위해 사진을 찍지는 않는다. 다른 사람들에게 보여주기 위한 목적이 크다. 코닥과 CVS는 온라인에 있는 사진을 실제로 인화해 주는 솔루션을 만들었다. 고객들은 그것을 편집할 수 있고 그리고 메일로도 보낼 수 있고 실제로 프린트 할 수도 있다. 사진 공유라는 고객의 골을 잘 이해한 예로 볼 수 있다.

그러나 위의 이야기는 대체로 결과론적인 이야기에 집중되고 있어서 구체적으로 ‘어떻게?’ 라는 답은 찾기 어렵다. 앞에서 말한 3단계 플로우 중 가장 힘든 것이 바로 ‘고객의 시나리오를 작성’하는 일이 아닐까?

만약, 특정 제조업을 위한 시나리오 디자인을 한다면 비교적 고객의 시나리오를 작성하는 일이 단순할 수 있겠지만 만약, 포탈 같은 형태의, 타겟이 대단히 넓은 B2C 인터넷 기업이 고객의 시나리오를 작성하려면 어떻게 해야 될지 막막한 것이 사실이다.

어떻게 고객의 시나리오를 잘 그려낼 수 있을까? 여기서 우린 다시 ‘시나리오’란 단어에 집중할 필요가 있다. IBM 리서치 센터의 Dan Gruen은 1999년 희곡의 스토리 요소를 비유한 흥미로운 논문을 발표했는데 여기서 시나리오를 작성하는 5개 요소들은 다음과 같다.

Fleshed-out characters: It allows an audience to understand, related to, and often empathizes with them as people.

Detailed settings: Compelling stories include details of time and place, helping the audience situate themselves in the setting in which the story takes place.

Goals and obstacles: The plots of compelling stories typically are based around a conflict or obstacle that must be overcome to accomplish a goal.

Causality: Stories are more than lists of unrelated events. Events in stories are connected through causal relationships, though these relationships sometimes only become clear at the end.

Dramatic elements: It and plotlines are essential to stories, adding to their interest and emotional engagement. Dramatic elements heighten the sense of something being at stake and reveal character’s core value.

There was a fear that including crises and other exceptional events would detract from the generalizability of the stories, making it harder for people to map them to their own, presumably more controlled domains. It leads to stories that involve situations in which the tool will make a critical difference.

위의 요소들을 추출하기 위해 다양한 방법들을 시도해 볼 수 있다. 먼저 표본 집단의 선정작업이 이루어지고 나면 그들의 하루 일과를 캐주얼 하게 수집하는 것으로 시작해 볼 수 있을 것이다.

그 후에 워크샵을 통해 시나리오를 완성해 나가는 방법이 미국의 몇 개 연구소들에서 사용하는 방법이다(더 자세한 부분은 독자들의 몫으로 남겨두고자 한다). 조사과정을 통해 고객의 시나리오가 어느 정도 그려졌다면 다음은 그 시나리오로부터 기능요소를 추출하고 디자인과 프로토타입을 개발하는 단계로 넘어간다.

지금까지 Scenario-based Design에 대한 시대배경과 3단계 플로우, 그리고 ‘시나리오’에 맞추어 실제로 시나리오를 그리는 작업에 대해 간략하게 이야기 했다. 다음 기회에 Davidndanny.com을 통해 좀 더 구체적 사례를 이야기 하는 시간을 약속하며 글을 닫는다. 2002-10-16

Written By
More from David Kim
Physical Metadata
Amsterdam에서 진행된 Playing FLICKR 행사에서, Physical Metadata란 아이디어가 눈에 들어오는군요. 일종의 Locative...
Read More
Leave a comment

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

3 + 17 =