9. 사용자 중심 디자인

1. 9. 사용자 중심 디자인 물오리의 다리가 짧다고 길게 해 준다면 괴로워 하고, 학의 다리가 길다고 잘라 준다면 슬퍼할 것이다 장자의 『변무편』중에서

2. ■배경 사용자 중심 디자인 가능하면 우리의 직관적인 판단과 일치해야 한다. 이렇게 되기 위해서는 설계자가 사용자를 잘 이해해야 한다. ‘사용자 중심 디자인(User Centered Design, UCD)’은 사용자 이해가 최우선이 되는 디자인 방법이다. UCD는 Norman과 Draper가 80년대 중반 처음 사용한 용어로, 사용자가 시스템 디자인에 직접적인 영향을 주는 시스템 디자인 개념이다. UCD는 두 가지의 다른 관점에서 이해될 수 있다. - (소프트웨어) 공학적인 관점: UCD를 시스템 개발 프로세스로 보는 것. - 심리학적인 관점: 사용성과 결부된 인간요소(human factors)연구에 기반을 둠. 이 장의 내용은? - Winograd의 시스템 디자인 - 공학적 관점에서의 UCD - 심리학적 관점에서의 UCD

3. 위노그라드가 말하는 시스템 디자인 • 디자인은 의식적인(conscious) 활동이다. - 디자인은 실제로 직관이나 암묵적인 지식, 본능적인 반응 등을 통해 이루어지는 경우가 많다. • 디자인 한 가운데는 인간에 대한 관심이 있다. - 디자이너는 한 쪽에서는 기술에 대해서, 다른 한 쪽에서는 인간에 대해서 관심을 가지고 있는 사람이다. 극단에 빠지지 않고 이 두 세계 사이에서 균형을 이루어야 한다. • 디자인은 기술 혹은 재료와의 대화이다. - 새로운 기술이나 재료는 새로운 디자인을 불러일으킨다. 벽돌이나 건축자재가 있기에 건축 디자인이 필요하고, 컴퓨터가 있기에 인터랙션 디자인이 존재한다. • 디자인은 창조적인 활동이다. - 우리가 사는 세계는 하나의 정확한 답만을 요구하는 곳이 아니다. 디자인은 창조적인 해답을 얻는 행위이다. • 디자인은 커뮤니케이션이다. - 시스템은 단지 디자이너가 생각하는 대로 만들어지는 것이 아니라, 사용자와의 계속적인 대화를 통해 제작된다. • 디자인은 사회에 영향을 끼친다. - 디자이너는 기술적인 디자인 뿐 아니라, 조직적인 면, 기술이 사회에 끼치는 영향력까지 고려하여 자신의 역할을 수행할 줄 알아야 한다. • 디자인은 사회적 활동이다. - 시스템 디자인은 한 개인의 역량만으로 이루어지는 것이 아니다. 디자인 문화와 디자인 팀의 조직 등이 디자인에 많은 영향을 미친다.

4. ■UCD의 특징 UCD의 공학적 이해 • 개발 과정에서 사용자에 초점이 맞추어져 있다는 것이다.전통적으로 시스템 디자이너는 사용자보다는 개발자의 입장에서 시스템을 디자인해왔다. 사용자가 디자인 과정에서 그 중심에 서 있다는 것은 컴퓨터공학에서는 매우 새로운 발상이다. • 경험적인(empirical) 정보를 이용한다.사용자를 이해한다는 것은 쉽게 얻어지지 않는다. 수학적인 분석에 의해서 이루어지는 것은 더더욱 아니다. 사용자를 만나야 한다. 이들이 어떻게 시스템을 사용하는지, 이들이 실제로 어떻게 일하는지를 알기 위해 대화를 하든지 관찰을 하든지 해야 한다. 이렇게 해서 얻어진 경험적인 정보들은 디자인 과정에서 그대로 적용되게 된다. • 반복 디자인(iterative design)이 필연적이다.시스템 설계는 사용자의 피드백에 기초해서 이루어지고 다듬어진다. 개발자 중심의 설계와는 달리, 개발자는 물론 사용자의 목소리가 필요하기에 개발 과정은 조금 더 복잡해지고, 설계의 변경도 더 많아진다. 그래서 디자인은 자연히 반복적인 재설계를 요구한다. • 다양한 분야의 협력이 디자인 과정에서 필요하다.시스템 디자인에 심리학이나 문화인류학, 언어학 등의 도움을 필요로 하는 것은 UCD의 또 다른 특징이다.

5. ■UCD 프로세스의 단계 UCD의 공학적 이해 - UCD는 반복적이다. 각 단계는 한 번 수행되어도 필요에 의해 다시 수행될 수 있다. - UCD 단계를 한 가지의 모델로 특징화시키는 것은 불가능하다. 여러 다른 의견이 있다. 소프트웨어 공학에서 다양한 생명주기 모형들이 있듯이 UCD도 한 마디로 이야기할 수 있는 성질이 못 된다. - 여기서는 여러 모형 중 IBM이 사용하는 UCD 프로세스의 5단계를 소개해 보겠다.

6. ■UCD 프로세스의 단계 UCD의 공학적 이해 (1) 사용자 요구 정의(market definition) 누가 시스템의 사용자가 될 것인지를 이해해야 하고, 계획하는 시스템과 관련된 다른 시스템들을 알아야 한다. 그리고 시스템이 성공하기 위해 사용자들이 가장 필요로 하는 요구 사항을 결정해야 한다. <방법> 사용자들에게 새로운 시스템 또는 개선에 대한 관심의 정도를 묻고, 그들이 원하는 것들을 열거하고 이를 우선순위 별로 정리하도록 요구한다. (2) 작업 분석(task analysis) 사용자의 목적과 작업, 사용자가 작업하는 방식과 사용도구들, 그들이 경험한 문제들과 그들이 바라는 도구나 과업의 변화들을 발견하고 이해해야 한다. <방법> 사용자들이 자신의 수행하는 작업들을 열거하고 우선순위 별로 이를 정리하도록 요구한다. 그리고 작업을 수행하는 사용자들을 직접 관찰한다.

7. ■UCD 프로세스의 단계 UCD의 공학적 이해 (3) 유사 시스템 평가(competitive evaluation) 다른 유사 시스템의 장단점을 분석한다. <방법> 사용자들이 같은 작업을 다른 시스템을 이용해서 수행하도록 하고 각각의 만족도를 평가한다. 그리고 사용자에게 각 시스템의 장단점을 정리할 것을 요구한다. (4) 디자인과 워크스루(design and walk-through) 해결책을 제안하고, 이 제안에 대해 사용자와의 디자인 워크스루 과정, 즉 시스템 개발자가 아닌 제 삼자인 사용자가 디자인을 평가하는 과정을 통해 개발팀은 사용자의 피드백을 받아야 한다. 그리고 이 피드백을 기초로 하나의 해결책을 설계한다. <방법> 사용자들에게 단순한 저성능(lo-fi) 프로토타입을 평가해 달라고 부탁한다. (5) 평가와 검증(evaluation and validation) 디자인이 바뀔 때마다 사용자의 피드백을 얻어야 한다. 그리고 디자인을 반복한다. <방법> 만들어진 프로토타입을 가지고 작업을 수행하는 사용자를 관찰한다.

8. ■심성 표상과 심성 모형 UCD의 심리학적 이해 인간의 능력은 ‘심성 표상(mental representation)’에서 나온다고 해도 과언이 아니다. 예, 우리가 병원에 갈 때, 우리의 머릿속에는 병원에 대한 표상이 기록되어 있다. 그래서 병원에서 먼저 무엇을 해야 하고, 다음엔 어떻게 행동해야 할지를 아는 것이다. 컴퓨터가 어떻게 동작하는지, 소비자가 어떻게 행동하는 지, 아인슈타인의 상대성이론이 어떤 것인지 등을 이해하는 것은 우리가 이들에 대한 표상을 가지고 있기 때문이다. 인간은 경험을 통해 우리의 경험한 사물, 사건, 일, 사람들을 하나씩 표상해 나간다. 그래서 심성표상은 보이지 않는 내적인 이미지와 같은 것이다. ‘Representation’이라는 단어를 번역할 때, ‘표상’ 대신, ‘표현’이라는 용어를 선택하는 학자들도 있다. 특히 인공지능학자들은 그렇게 부른다. 그러나 다른 학문에서 보편적으로 받아들여지는 용어가 ‘표상’이기에 이 책에서는 이를 사용한다.

9. ■Johnson-Laird가 제시한 세 가지 형태 UCD의 심리학적 이해 • 명제적 표상(propositional representations)은 논리, 기호, 언어와 연관된 표상 • 심상(mental imagery)은 어떤 대상에 대한 지각적인(perceptual) 특징을 보존하는 특수한 표상 • 심성 모형(mental models)은 이 둘 사이에 존재하는, 각 개인이 그들의 경험을 이해하고 설명하기 위해 세우는 지식 구조 • 명제적 표상은 언어적(language-like) 표상, 심상은 회화적(picture-like) 표상

10. UCD의 심리적 이해 Johnson-Laird가 제안한 세 가지 표상. 심성 모형은 언어적인 표상인 명제적 표상과 회화적 표상인 심상 사이에 위치하는 심성 표상이다. Johnson-Laird이 제안한 세 가지 표상에 대한 정의에 의하면, 심성 모형은 심성 표상의 한 형태이다. 하지만, 많은 학자들은 이 두 개념의 차이를 크게 두지 않고 있다.

11. ■심성 모형, 개념 모형, 시스템 이미지 (Donald Norman의 제안) UCD의 심리학적 이해 심성 모형은 사용자가 시스템을 사용하는 데에 필요한 표상(예, 지하철 승차권 판매기에서는 먼저 원하는 도착지의 구간을 선택한 후에 동전을 나중에 집어넣는다. 일반 자판기의 경우, 동전을 넣고 원하는 품목을 선택한다. 자판기와 승차권 판매기는 서로 다른 심성 모형을 가정하고 있다.) 개념 모형(conceptual models)은 시스템 디자이너가 가지고 있는 시스템의 ‘정확한’ 모형이다. 심성 모형과 개념 모형이 같다면 이보다 좋을 수는 없다. 즉 사용자와 디자이너가 시스템을 이용하는 방법에 대해 동일한 표상을 갖고 있다면, 시스템의 사용성이 높아지는 것은 당연하다. 시스템 이미지: 시스템은 사용자와 디자이너 사이의 매개자이다. 시스템의 인터페이스, 시스템의 동작, 시스템의 반응을 통해 둘 사이는 소통이 이루어진다. 이 점에서 시스템 이미지는 중요하다.시스템이 사용자에게 줄 수 있는 중요한 표상은 다음에 소개할 외형 표상(external representation)이다.

12. UCD의 심리적 이해 세 개의 시스템 모형.시스템 디자이너가 머리에 담고 있는 시스템 모형을 개념 모형 (혹은 디자인 모형)이라고 하고, 사용자가 마음에 그리고 있는 시스템 모형을 심성 모형 (혹은 사용자 모형)이라 한다. 이 두 모형의 차이가 적다는 것은 디자이너가 사용자의 심성 모형을 잘 이해하고 있음을 의미한다. 이런 경우 시스템의 인지적 사용성은 높아진다.

13. ■외형 표상(external representation) UCD의 심리학적 이해 표상(representation)의 중요성을 강조한 Simon의 말: “하나의 문제를 해결한다는 것은 그 답을 선명하게 하기 위해 단지 그 문제를 표상하는 것이다.” 부산 시 지하철 노선도. 하나의 어려운 문제를 해결하는 것은 그 문제를 어떻게 표상(혹은 표현)할 것인가에 달려 있다. 지하철 노선도는 출발지에서 목적지까지 어떤 경로를 거쳐 가야 하는지의 문제를 해결할 수 있도록 도와주는 외형 표상이다. 지도는 우리가 길을 찾을 때 꼭 필요한 외형 표상이다.  특별히 Scaife와 Rogers는 외형 표상의 도움을 받는 인지를 외형 인지(external cognition)라 칭한 바 있다.

14. ■행위 유발성 (affordance) UCD의 심리적 이해 행위 유발성 (affordance): 하나의 대상이 인간의 특정한 행위를 이끌 수 있는 특성을 가지고 있을 때 사용하는 용어. 예를 들어, 책상은 인간에게 공부하도록 하는 행위 유발성(affordance)이 강한 대상이다. 의자는 앉는 행위의 유발성을 가지고 있다. 연필 깎기의 구멍은 연필을 집어넣는 행위를 유발하며, 오른쪽 손잡이는 돌리는 행위를 유발한다

15. ■행위 유발성 UCD의 심리학적 이해 한글 도구바 (tool bar)의 일부.아이콘의 이미지는 텍스트로 된 설명 없이도 사용자에게 개발자가 의도했던 행위를 유발시킬 수 있어야 한다. 사용자에게 직관적으로 와 닿는 행위가 아이콘 이미지만을 통해서 이루어질 수 있다면, 이 아이콘은 잘 제작된 아이콘일 것이다. 사용자 인터페이스 제작 시, 행위유발성이 높은 아이콘, 버튼, 이미지를 만드는 것은 매우 중요하다.행위유발성이 약한 이미지는 당연히 개발자의 의도와는 다른 사용자들의 행동을 유발시키게 된다.

16. ■제약 (constraints) UCD의 심리적 이해 제약을 시스템 디자인에 어떻게 이용할 것인가? 제약은 사용자의 가능한 행동을 줄여놓는 것이다. 예 1)어떤 문은 밀고 당기는 것이 가능하지만, 어떤 문은 밀기만 가능한 경우도 있다. 어떤 문은 문고리를 잡아 돌리는 행위가 더 필요한 경우도 있다.제약이 잘못 설계되었을 때는 쉽게 들어갈 수 있는 문도 열지 못하는 경우가 생기거나 들어오고 나서도 때로는 다시 못 열고 갇히게 되기도 한다. 예 2)파일을 다루는 데에도 제약이 필요할 때가 있다. 읽기전용 파일은 편집을 할 수 없게 만든다. 제약은 사용자의 행동을 결정한다. 제약이 불편함을 줄 수도 있지만 반대로 편리함을 제공할 수도 있다. 제약이 사용상의 융통성을 저해시킬 수도 있지만, 사용자의 에러를 막아줄 수 있는 긍정적인 역할을 한다. 그래서 때로는 설계자가 의도적으로 더 많은 제약을 부과하기도 한다.

17. ■제약 (constraints) UCD의 심리적 이해 스케줄 시스템에서의 두 개의 다른 입력 양식. 위에서 보여주는 양식은 어떤 계획을 일(日) 단위로 입력하게 되어있고, 아래의 양식은 분(分) 단위로 입력하게 만들었다. 입력 상에 어떤 제약을 줄 것인지는 그 시스템이 이 입력 자료를 어떻게 이용할 것인가와 많은 연관성을 가지고 있다.

18. ■사상 (mapping) UCD의 심리적 이해 두 개의 대상에 대한 연관성을 우리는 사상(寫像, mapping)이라고 한다. 가스레인지 불 켜기.왼쪽 가스레인지에서는 점화 다이얼이 각각 어떤 점화구와 각각 연관 지어져 있는 지가 모호한 반면, 오른 쪽 가스레인지는 둘 사이의 연관 관계가 분명하다. 사람은 관계를 통해서 사물이나 기능 등을 인식한다. 그래서 사상의 문제가 중요한 것이다.

19. ■Norman의 일곱 가지 디자인 원칙 UCD의 심리적 이해 Norman은 그의 저서 <The Psychology of Everyday Things>에서, 시스템 설계자가 일을 수행하면서 필수적으로 고려해야 할 일곱 가지 디자인 원칙을 제시한 바 있다 (1) 환경 지식과 머리 지식을 모두 이용하라: 인간 머리 속 지식(knowledge in the head)은 ‘부정확’하다. 하지만 이 부정확한 지식을 사용해서 정확한 행동을 해내는 것이 인간이다. 왜 그러한가? 가장 큰 이유는 우리가 가지고 있는 지식 이외에 많은 정보가 환경 속에 있고 이를 인간이 이용하기 때문이다. 이런 지식을 바로 환경 지식(knowledge in the world)이라 한다. 예) 처음 타이핑을 배울 때, 자판 배열에 대해 잘 모른다. 이 때 자판에 대한 우리 머리 속의 지식은 거의 없다. 하지만, 키보드에 글자가 새겨져 있다. 이렇게 표시된 정보는 환경 지식이다. 우리는 이 지식을 이용한다. 그래서 타이핑 치는 법을 배우기 시작한다. 그런데 시간이 지나면, 자판 배열에 대한 머리 지식은 증가한다. 물론 환경 지식을 어느 정도 의존한다.

20. ■Norman의 일곱 가지 디자인 원칙 UCD의 심리적 이해 (2) 작업의 구조를 단순화하라: 기술은 사용자의 작업을 가능하면 단순하게 만들어 주어야 한다. 이 원칙은 우리의 작업을 대신하는 인공지능의 의미보다는 우리의 정신 활동의 능력 향상을 도와주는 도구 제공의 의미가 강하다. (3) 사물을 시각화하라: Norman이 ‘사물을 시각화하라’는 원칙을 세웠을 때는 1988년이다. 이때는 이 원칙이 매우 중요했다. 시각화되지 않은 것이 너무 많았기 때문이다. 그러나 이제 이 원칙은 굳이 말하지 않아도 많은 설계자들이 이미 깊이 인지하고 있는 원칙이 되어 있다. (4) 사상을 바르게 하라: 자연(스러운) 사상이 중요하다.가스레인지의 예에서는 공간적 연관성이 중요하다. 제어 부분과 대상 사이에 시각적인 이미지의 연관성이 높으면 자연 사상으로 가치가 크다.자동차 핸들을 오른 쪽으로 돌리면 차가 오른 쪽으로 진행하고, 왼쪽으로 돌리면, 왼쪽으로 간다. 이와 같이 제어 부분을 어떻게 움직이는가 하는 문제, 즉 제어와 동작 사이의 사상을 생각해 볼 수 있고, 시스템의 반응성의 문제도 사상의 관점에서 설명될 수 있다.

21. ■Norman의 일곱 가지 디자인 원칙 UCD의 심리적 이해 사용자 의도와 피드백 정보 사이의 사상.그림판 사용자가 그리기 모드를 택했을 때, 시스템은 사용자의 의도와 연관된 그리기의 아이템이 푹 들어가게 하였다.이런 시스템의 반응과 사용자의 의도도 일종의 사상의 관계에 있다고 할 수 있다.

22. ■Norman의 일곱 가지 디자인 원칙 UCD의 심리적 이해 (5) 제약의 힘을 이용하라: 사용자에게 지나친 자유와 융통성을 주는 것이 꼭 좋은 것은 아니다. 사용자의 행동을 제약하는 것도 유익할 때가 많다. 어떤 기능을 이용할 수 있는 최선의 방법만을 택하도록 제약을 주면, 사용자는 그것만이 유일한 방법임을 알고 늘 최선의 방법만을 사용하게 된다. 설계자는 물론 융통성과 제약 사이의 균형감을 갖고 있어야 한다. (6) 에러를 대비하라: 에러는 언제든지 가능하다. 사용자는 설계자가 예측한 방법으로만 시스템을 사용하지 않는다. 시스템은 사용자의 실수를 되돌릴 수 있게 해 주어야 한다. 그리고 되돌리는 방법이 쉬워야 한다. (7) 모든 것이 실패했을 때, 표준화 작업을 하라: 설계자는 가능하면 표준을 선택해야 한다. 사용자도 표준을 따르도록 훈련 받아야 한다. 그래야 다양한 시스템에 대한 적응력이 높아진다. 예를 들어, ‘한글’ 워드프로세서와 ‘Outlook Express’ 이메일 시스템의 단축키 <Alt + S> 사용이 어떤 문제를 야기하는 지를 생각해 보자.

23. 10. 참여 디자인 의미 있는 권한 부여의 실험은 단지 노동자가 어떻게 작업을 수행하는가보다는 그들이 하는 일을 얼마만큼 그들 스스로 결정할 수 있느냐에 달려 있다. - T. Eccles

24. 배경 ■참여 디자인 (Participatory Design) 이란? 참여 디자인(participatory design)은 개발자와 사용자들이 모두 시스템의 개발 과정에 참여(또는 개입, involvement)하는 개발 방법 이런 의미에서 일종의 사용자 개입 시스템 개발(user-involved system design) 방법으로 볼 수 있다. 참여 디자인에서 사용자는 단순한 사용자 테스트의 실험 대상자가 아니라, 시스템의 여러 측면에서 요구하거나 조언을 해 줄 수 있는 사람들이다. 북유럽의 세 나라, 스웨덴, 덴마크, 노르웨이가 개념화, 체계화, 실제화 시킨 방법으로, 북유럽 학자들은 일명 스칸디나비안 시스템 디자인(Scandinavian model of system design), 또는 협력 디자인(Cooperative design)이라고도 부르는 개발 방법이다.

25. 참여 디자인의 출발 70년대 초반 노르웨이에서 시작: 컴퓨터 시스템을 제철산업현장에 소개하고 개발하는 일에 컴퓨터 전문가들이 노동자들과 함께 협력한 것이 그 시초로, 이를 NJMF (Norwegian Iron and Metal Workers' Union) 프로젝트라고 부른다. 70년대 말에 스웨덴에서 수행된 DEMOS프로젝트는 스웨덴 노동조합의 지원을 받아 진행되어, 노동자들은 물론, 컴퓨터과학자, 사회학자, 경제학자, 엔지니어 들이 함께 협력하면서 작업을 효과적으로 도울 수 있는 시스템들을 개발. DEMOS 프로젝트의 초점은 “노조, 산업 민주화, 컴퓨터”으로, 참여디자인의 시작은 8장에서 언급한 정치적 사용성과 깊은 관련을 가진 채 시작 됨. 80년대에는 스웨덴과 덴마크가 같이 협력한Utopia 프로젝트가대표적이다.스웨덴의 ‘Aftonbladet‘신문의 레이아웃 시스템을 만듦. 북유럽 중심으로 출발한 PD는 80년대 90년대에 들어서면서, 북미까지 그 영향력을 미침.

26. 참여 디자인이란? ■참여 디자인이란의 특징 • 이 장에서 다음의 다섯 가지의 특징을 살펴 보자. • 사용자 개입 • 설계 방법과 도구의 다양성 • 도구 관점 • 학제간 협력과 통합적 이해 • 민주적 협력과 갈등

27. 참여 디자인이란? ■사용자 개입 사용자를 개발 단계에 개입시키는 이유는? 사용자들은 시스템이 필요한 업무(work) 분야의 전문가이기 때문에 그들이 개발에 참여할 때, 그들의 요구 사항이나 일의 특성 등이 효과적으로 반영되는 시스템을 만들 수 있기 때문이다. 그리고 개발자들의 실제 업무 상황에 대한 이해가 증진되기 때문이다. 참여 디자인에서의 사용자는 바로 협력 디자이너(co-designer)이다. ■설계 방법과 도구의 다양성 설계나 제작 시 다양한 도구와 방법이 사용된다. 예) 그래픽 프로그램들은 물론,카드보드(cardboard), 스크린 샷, 간단한 스케치를 위한 종이와 연필, 비디오 등 역시 프로토타입 미디어가 사용된다. 그리고 개발자와 사용자 사이의 워크샵이나 포럼을 열기도 한다.

28. 참여 디자인이란? 종이 목업(mock-up) 준비 작업. 참여디자인은 다양한 프로토타입 제작 방법을 수용한 디자인 방식으로 잘 알려져 있다. 그 중 종이 목업 제작은 참여디자인의 트레이드마크가 될 만큼 유명하다. 사용자들이 원하는 바를 시스템 제작 초기부터 잘 반영하는 것이 필요했고, 이를 위해서는 빨리 쉽게 만들 수 있는 프로토타입 제작이 요구되었다. 이 때, 종이 목업, 스케치 등을 사용하였다.

29. 참여 디자인이란? ■도구 관점 Utopia 프로젝트의 열매 중 하나는 ‘도구 관점(tool perspective)’이라는 디자인 방식이다. 이 관점이 가정하고 있는 핵심적인 아이디어는, ‘컴퓨터는 노동자 즉 사용자를 위한 도구가 되어야 한다는 것과 사용자는 그 도구를 잘 제어할 수 있어야 한다’는 것이다. 이는 HCI 연구가 활발한 지금 생각하면 아주 당연해 보이는 말이지만, 70년대 후반에는 매우 획기적인 생각이었다. PD(참여 디자인)는 어떤 혁신적인 무언가를 만들어낸다기보다는 점진적으로 스케치, 그림, 목업, 프로토타입 등 다양한 도구들을 개발하면서 적절한 시스템을 발견해 나가는 과정을 중요시한다. PD는 어떤 스펙이나 형식보다는, 협력을 어떤 방법으로 할 것인가, 프로토타입을 어떻게 사용할 것인가, 어떻게 서로 다른 디자인 방식을 조화시킬 것인가 등의 문제를 더 깊이 다루기 때문에, 소프트웨어공학에서 의미하는 디자인에 비하면 비형식적이다.

30. 참여 디자인이란? ■학제간 협력과 통합적 이해 PD는 컴퓨터 엔지니어이나 그래픽 디자이너 등의 개발자들과 사용자는 물론, 사회학, 교육학, 심리학 등의 배경을 가진 사람들이 개발 과정에 참여함을 의미한다. 이러한 학제 간의 협력은 시스템 개발의 폭넓은 접근 방법을 이끌게 된다. ■민주적 협력과 갈등 사용자가 시스템 설계와 의사결정까지 직접 영향력을 행사할 수 있는 구조라는 점에서 민주적이라 할 수 있다. 북유럽은 전통적으로 노동자의 권익이 가장 잘 보장된 대륙이다. ‘노동자 = 사용자’ 라는 등식이 성립한다면, 북유럽은 사용자의 목소리를 잘 반영될 수 있는, 사용자 개입의 민주적 개발 방법이 발전할 수 있는 토양이 잘 갖추어진 대륙이다. 민주적 협력 뒤에는 늘 갈등의 요인이 있음을 또한 기억할 필요가 있다.

31. 사용자 중심 디자인과 참여 디자인 UCD(사용자 중심 디자인)와 PD와의 관계. PD를 UCD의 한 특별한 형태로 보는 것이 일반적인 시각이다. 하지만 엄밀히 말하자면, 이 둘은 서로 많은 공유점을 가지고 있지만 사실은 각각 다른 디자인 방법이라고 할 수 있다. PD는 시스템 개발을 둘러싼 정치적 역학 관계나 민주화 과정과도 결부된 문제들을 심각하게 다루는 경우가 많기 때문이다. 이는 UCD의 특징과는 다른 모습이다. 특별히 PD는 8장에서 언급한 정치적 사용성과 많은 관련을 가지고 있다.

32. 이상과 현실 참여 디자인의 실제 적용의 예는 많다. - NJMF 프로젝트에서의 컴퓨터 기반의 기획(planning)과 제어 시스템 개발 - 그래픽 레이아웃 프로그램, TIPS의 개발을 이룬 유토피아 프로젝트 - 분산 환경하에서 EU 국가들 간의 공동작업을 돕는 시스템 개발의 EuroCoOp 프로젝트 - 장소가 다른 두 연구 그룹 사이의 비디오 커뮤니케이션을 돕는 시스템 VideoCafe의 제작 - 초등학생들을 위한 스토리 텔링(story telling) 시스템의 개발 등 참여 디자인 방법의 많은 성공 사례들에도 불구하고, 이에 대한 비판도 만만치 않다. 주된 이유는 이 방법을 수행하는 데 따르는 사용자와의 협력을 위한 시간적 정신적 물질적 비용만의 문제만이 아니라, 학제 간 협력이 이루어질 때의 비용, 그리고 여러 목소리를 조율하는데 따르는 비효율성 등의 문제가 따르게 된다. 참여디자인은 이상적인 측면을 가지고 있긴 하지만, 가장 HCI적인 개발 방법이라 보고 있다. 이는 참여디자인이 HCI를 특징 지어줄 수 있는 여러 요소들, 사용자 이해, 사용자 중심의 개발, 학제 간 연구 등을 진지하게 실현시킨 포괄적이고 종합적인 개발 방법이기 때문이다.

33. 11. 시나리오 기반 시스템 디자인 이야기가 길 필요는 없다. 그러나 그것을 짧게 만들기까지는 긴 시간이 소요될 것이다. - H. D. Thoreau

34. 배경 과학의 세계에서는 가시화 또는 수식화가 가능하지만, 관습의 세계에서는 이것이 불가능하다. 하지만 가시화가 되지 않고서는 시스템을 만들 수 없는 것이 개발자가 갖는 딜레마이다. 가시화할 수 없는 것을 가시화하는 하나의 방법이 시나리오 제작이고, 이를 이용한 설계 방법이 시나리오 기반 디자인 (Scenario-Based Design, SBD)이다. Rosson과 Carroll의 책 <Usability Engineering: Scenario-Based Development of Human Computer Interaction>은 HCI의 이론과 기술을 이용하여 SBD가 어떻게 응용될 수 있는지를 잘 보여주고 있는 HCI 개설서이면서 동시에 SBD 개설서로서의 가치를 가진 책이다. 이 장에서는 시나리오 기반 디자인(SBD)에 대한 간단한 개략적 설명과 함께, Rosson과 Carroll의 책을 중심으로 그들이 말하는 SBD를 소개하고자 한다.

35. 왜 SBD인가? ■시나리오를 보는 관점들

36. 왜 SBD인가? ■시나리오를 보는 관점들 (Rolland가 말하는 네 가지 관점) • 형태(form)를 생각하는 관점: 시나리오 작성에 어떤 형식을 갖추고 있는지 비형식적인지의 문제는 이러한 관점에서 바라볼 수 있는 대표적인 문제이다. 우리가 잘 아는 소프트웨어공학에서의 “유즈 케이스(use cases)”는 형식을 갖춘 시나리오 기술 방법이다. 어떤 시나리오는 테이블, 구조화된 텍스트나 스크립트를 사용한다. • 내용을 보는 관점: 시나리오는 사건이나 행동, 활동에 대한 정보(behavioral information)의 내용을 담을 수 있고, 데이터나 속성을 가지고 있는 객체를 나타낼 수도 있다. 어떤 시나리오에서는 부서, 회사구조 등의 조직에 대한 정보를, 혹은 사람들의 특성이나 관점, 요구, 희망 등 사용자들에 대한 정보를 담을 수도 있다. • 목적을 보는 관점: 시나리오의 작성 목적이 시스템 개발일 수 있고, 좁게는 예외처리(exception handling)를 다룰 때 혹은 시스템 설계를 변경하려 할 때, 시나리오를 사용할 수도 있다. 소프트웨어공학에서는 시스템 요구분석을 위해, HCI에서는 요구분석은 물론, 사용자가 시스템을 사용하는 방법을 가시화하기 위해 시나리오를 사용하는 경향이 있다. • 생명주기 관점: 시나리오도 하나의 소프트웨어처럼 생명주기를 갖는다. 한 번 만들어진 시나리오를 고치지 않고 계속 사용하는 경우도 있지만, 많은 경우 시간이 지남에 따라 시나리오도 수정된다. 또 처음에는 대략적으로 시나리오를 작성하다가도 시간이 흐를수록 점차 더 자세한 내용을 담는 경우가 많다.

37. 왜 SBD인가? ■ SBD의 필요성 • 시나리오는 구체적이다. 엔지니어가 행동에 들어가기 위해서는 손에 잡힐 듯한 가시적인 모델이나 구체적인 형상이 필요하다. 시나리오는 구체적인 모델을 만들기 위해 필요하다. 시스템이 복잡할수록 클래스 모델(class model)과 같은 개념적인 모델을 설계하는 데에 어려움이 많이 따른다. 시나리오는 이 어려움을 해결할 수 있는 좋은 방법이 된다. • 시나리오는 융통성 있는 제작 도구이다. 시나리오의 특징은 불완전하다는 데에 있다. 쉽게 고쳐질 수 있고, 다듬어질 수 있다. 하드웨어를 수정하는 것보다는 소프트웨어의 경우가 더 쉽고, 소프트웨어보다는 시나리오를 바꾸는 것이 훨씬 용이하다. • 시나리오는 영역 전문가와 개발자 사이의 소통 기반이다. 시스템을 완성하기 전까지는 중간과정의 시스템들인 프로토타입들이 필요하다. 바로 이 프로토타입을 평가할 수 있는 도구가 시나리오이다. 시나리오 작성자 즉, 영역전문가(domain experts)는 엔지니어 즉, 개발자가 만든 프로토타입을 시나리오에 기초해서 무엇이 잘못되었고 잘못 이해되었는지를 평가할 수 있다. • 시나리오는 인간의 활동을 기술한다. 시나리오는 만들어질 시스템에 대해서 서술한 것이지만, 그 시스템을 사용할 사람들의 활동과 일, 놀이 등에 대한 이해를 기반으로 둔 것이다. 그래서 시나리오는 시스템에 대해서 말하는 것이 아니라, 사람들의 활동을 기술한 것이다. 이런 의미에서 시나리오 작성은 궁극적으로 기계 혹은 기술 중심의 시스템 설계방식을 탈피하고, 인간의 활동과 일 중심의 설계방식을 진작하는 효과를 거둘 수 있다.

38. Rosson과 Carroll의 SBD ■ SBD 설명을 위한 가상 과학 전시회 사례 연구 Rosson과 Carroll은 SBD를 설명하기 위해, ‘가상 과학 전시회(virtual science fair)’ 라는 하나의 분명한 응용 영역을 택한 바 있다. MOOsburg. Rosson과 Carroll을 비롯한 많은 연구자들은 MOOsburg라는 가상 커뮤니티 네트워크 시스템을 개발하였다(http://moosburg.cs.vt.edu참조). 이 시스템은 미국 버지니아 주에 있는 블랙스버그(Blacksburg) 시민들이 이용하기 위해 개발된 시스템으로 그들이 서로 협력하고 소통할 수 있는 환경을 제공한다. 가상 과학 전시회. Rosson과 Carroll은 MOOsburg를 이용하여 가상 과학 전시회의 개발을 계획하고 있었다. 블랙스버그의 과학 전시회에서는 중고등학교 학생들이 각 개인이 공부하고 연구한 결과를 전시회장에서 전시한다.

39. Rosson과 Carroll의 SBD ■ SBD 프로세스

40. Rosson과 Carroll의 SBD ■첫 단계: (요구) 분석 단계 사용자들에 대한 연구, 필드 연구 등을 수행 시나리오는 책상에서 만들어지는 것이 아니다. 시나리오 제작자들은 사용자 연구를 통해 경험적인 정보를 얻어야 하고, 이를 통해 시나리오를 작성해야 한다.그래야 이 시나리오가 사실적이고 현실적인 것이 된다. 특별히 분석 단계에서의 시나리오를 문제 시나리오(problem scenarios)라고 부른다. 문제 시나리오는 시스템이 사용될 수 있는 상황에 대한 묘사가 잘 나타나 있다. 결코 상황에 대한 문제(problem)를 강조하기 위한 것은 아니다.

41. Rosson과 Carroll의 SBD ■두 번째 단계: 디자인 단계 • 개발 프로세스의 핵심으로 또 다시 세 개의 부분 단계로 나누어진다. • 활동 시나리오(activity scenarios). • 작업을 통하여 발생할 수 있는 사용자의 가상 활동 시나리오를 통하여, 사용자의 구체적인 목적과 요구사항 분석, 그리고 시스템의 기능에 초점을 맞춤. • 활동 시나리오의 영역은 작업을 하는 사용자의 활동 뿐 만 아니라 사회적인 측면도 고려되어야 함. • 정보 시나리오(information scenarios). • 사용자 그룹에서 발생하는 행동들에 대한 정보의 구조화 및 계층화를 통해 사용자의 목적 및 요구사항을 스크린 상에 시각적으로 보여주고 표현하는데 초점을맞춤. • 정보의 시각화 (스크린 레이아웃의 대략적인 스케치 등)는 구체적인 정보 설계 시나리오를 작성하는데 유용한 사용자 인터페이스 기술임. • 상호작용 설계 시나리오(interaction scenarios) • 작업을 수행하기 위해 사용자가 취하는 물리적 행동들과 이에 대한 시스템의 반응에 초점을 맞춤. • 사용자의 목적, 직조작, 피드백, 최적의 상호작용 패턴, 융통성 등과 관련하여 시나리오를 기술.

42. Rosson과 Carroll의 SBD ■세 번째 단계: 프로토타입 제작 평가 단계 SBD 과정에서 여러 차례에 걸쳐서 다양한 형태의 프로토타입이 제작 평가된다. 프로토타입은 종이 스케치에서 실제 시스템에 이르기까지 여러 형태가 제작될 수 있다. 사용자는 제작된 시나리오들을 직접 읽고 나서 프로토타입을 살피거나 사용하면서 이 프로토타입이 시나리오가 의도했던 바와 잘 부합하는지, 사용성의 문제는 없는지 등을 평가할 수 있다.

43. Rosson과 Carroll의 SBD ■요구 분석 SBD에서 요구분석의 결과는 정확한 요구 명세서가 아니라 문제 시나리오이다. 문제 시나리오는 시나리오의 상황에 대한 영향도 분석(claims analysis)과 함께 작성된다. 영향도 분석은 가상 사용자들(stakeholders 또는 potential users)에게 영향을 주는 상황들에 대한 특징을 기술하되, 그 장단점을 분석하는 것을 뜻한다. 예를 들어, 회사 내 공문의 전자 문서화가 실행되었을 때의 장점은 보관의 용이성, 수정의 용이성, 시간 이용의 효율성 등을 들 수 있고, 단점으로는 대면 기피 현상 초래, 전자문서 전달 확인의 어려움, 종이와 펜을 사용할 때보다 사용의 불편함과 제약이 뒤따른다는 것 등을 들 수 있다.

44. Rosson과 Carroll의 SBD ■요구 분석 –무엇을 하는가? SBD 요구분석의 개요.디자인할 시스템에 대한 비전과 철학(rationale), 사용자 그룹 정의와 가정과 관련된 근개념(root concept)을 설정하는 것이 최우선적인 일이다. 그런 후에 필드에서 직접 관찰, 기록, 인터뷰 등을 수행하며 사용자들의 일하는 방식 등을 이해하는 필드 연구가 필요하다. 이 연구 결과를 종합하여, 문제 시나리오 작성과 영향도 분석을 수행하는 데, 영향도 분석은 상황들에 대한 장단점을 도출하는 것을 뜻한다.

45. Rosson과 Carroll의 SBD ■요구 분석 - 근개념 필드로 나가기 전, 개발팀은 프로젝트의 비전과 철학,그리고 디자인 프로세스와 관련 된 초기 가정들과 관계자(혹은 사용자)에 대한 이해, 즉 근개념(root concept)을 설정 공유해야 한다. 근개념에서의 비전과 철학은 때로는 사용자를 통해서, 또 때로는 마케팅 부서나 경영진을 통해서도 얻어진다 근개념은 말 그대로 시스템 디자인 과정의 기초가 되는 개념들이다. 설계자들은 근개념을 바르게 세워야 하고, 모든 과정 동안 이를 늘 마음에 두어야 한다.

46. Rosson과 Carroll의 SBD ■요구 분석 –근개념 (예)

47. Rosson과 Carroll의 SBD ■요구 분석 - 필드 연구 필드 연구는 현장(field)에 직접 나가 사람들의 활동을 관찰하고 그들의 의견을 들은 결과를 분석 정리하여, 사람들, 활동, 작업, 문화 등을 이해하려는 행위 개발 팀은 시스템과 관련한 수많은 의문점들을 가지게 된다. (예를 들어, 과학 전시회의 경우, 학생들이 출품하는 프로젝트는 어떤 것이 있는지, 일단 출품이 되면 심사과정은 어떤지, 교사들과 학생들 사이에는 어떤 협력이 이루어지는지 등) 필드 연구 수행자는: - 관찰하고 기록하고, 기록된 것을 분석할 수 있어야 한다. - 인터뷰를 수행한다. - (컴퓨터 이외의) 도구에 대한 관찰력이 필요하다. 얼마나 많은 양의 필드 데이터를 모을 수 있는가? 얼마나 자주 현장을 방문할 필요가 있는가? 얼마나 많은 사람과 인터뷰를 할 수 있는가? 많을수록 좋지만, 시간과 금전, 프로젝트의 범위에 따라 그 해답은 결정된다고 볼 수 있다.

48. Rosson과 Carroll의 SBD ■요구 분석 –종합과 분석 필드 데이터가 모이면 이를 종합하여 분석하는 과정이 남아 있다. 이 과정에서는 다음 네 가지의 분석이 요구된다. - 사용자 분석 - 작업 분석 - 도구 분석 - 현장 테마 분석

49. Rosson과 Carroll의 SBD ■요구 분석 –종합과 분석 사용자 분석. 필드 데이터의 결과를 토대로 각 사용자 그룹의 프로파일(profile)을 작성한다.

50. Rosson과 Carroll의 SBD ■요구 분석 –종합과 분석