HCI - Safety

* Prevent Human Error

=> 사람은 항상 실수를 한다. 따라서 실수를 제거하는 것은 매우 어려운 일이다. 그러나, 어떤 시점에서 어떤 실수가 주로 일어나는지 예측하여 그 부분을 예방하는 정도는 할 수 있는 범위의 작업이다.

 

* Error Types

=> 사람의 행위는 크게 의도한 행위와 의도하지 않은 행위로 나뉜다. 또한 의도하지 않은 행위는 "실수"로 분별된다.

저번 포스팅의 MHP를 생각해보면, Slip은 Perceptual processor, Cognitive Processor에서는 정상적으로 처리가 되었으나, Motor Processor에서 오류가 발생한 것이고, Lapse는 Memory와 Perceptual Processor, Cognitive Processor의 상호작용 과정에서 오류가 발생한 것이다.

 

예시를 들어보자.

"짜파게티"를 끓인다는 것은 먼저 계획을 세우고(정보 or 기억 기반) Recognition -> MHP -> Execution을 반복하는 closed-loop control의 연속이다.

따라서 이 과정은 계속해서 Perceptual, Cognitive Processor의 상호작용을 거쳐야하는 Attention Cost가 높은 동작이고, 따라서 Lapse, Slip이 발생할 여지도 있으며, Mistake, Appropriation 모두 발생할 수 있는 상황이다.

 

조금 더 자세히 알아보자.

 

* Error Types

1. Mistake

=> Plan 단계에서 실수한 것이다. 혼동하기 쉽지만, Slip과의 차이점은 "의도"를 가지고 한 일이라는 것이다.

예를 들어 지식이 잘못되어 물보다 소스를 먼저 넣는 상황이 있다. 이 상황은 "지식"이 잘못되어있으므로 잘못된 지식이 수정되지 않는 이상 반복될 위험성이 있다. 이러한 Mistake는 다시 또 2개의 종류로 나뉜다.

1-1) Rule-based mistake : 룰은 알지만, 잘못 먹용하는 것이다.

1-2) Knowledge-based mistake : 아예 지식 자체가 틀린 것이다.

 

2. Lapse

=> 들어온 반응에 대한 Perceptual Processor, Cognitive Processor 에서 오류를 일으킨 것이다. 이는 의도적이지는 않은 오류이다.

 

3. Slip

=> Motor processor의 오류다. 즉 흔히 생각하는 "실수"이다. Slip과 lapse는 상호작용이 복잡한 전문적인 행동시 자주 발생한다.

 

 

* Error Sources

=> Perception Error는 주로 감각 기관의 과부하로 발생한다.

=> Cognitive Error는 파악된 데이터에 대한 decision이 어려울 시, 처리를 위해 필요한 Memory가 많이 필요할 시 발생한다.

=> Motor Error는 뭔가 근육의 세밀한 조작을 요하는 Skilled task거나 여러 기관의 협동 작업을 요하는 작업일 때 자주 발생한다.

 

* Capture Errors

- 가장 높은 빈도의 오류이다.

- 기존에 주로 하던 동작과 유사한 다른 동작을 할 때 주로 발생하는 오류이다. 예를들어 친구 집 승강기에서 내 집의 층수를 누르는 것과 같은 오류이다.

 

* Description Errors

- 보통 Similarity 때문에 발생한다.

- Consistency는 learnability에는 좋지만, safety에는 나쁘다는 단점이 있다. (Learnability <-> Safety)

- 따라서 의도하지 않은 Similarity는 safety에 좋지 않다.

 

* Mode Errors

- Mode란 내가 같은 행동을 해도 다른 output을 제공하게 하는 상태이다.

(ex : Caps lock, 그림판 색깔)

- Mode error는 주로 내가 어떤 mode인지 정보가 없을 때 발생한다.

 

* Causes of Slips

- 주로 주의력 부족으로 발생한다.

- Similarity와 주로 하던 것을 하려는 습관 떄문에 발생하는 경우가 잦다.

=> 그러나 Similarity와 반복되는 Perceptual,Congnitive가 필요없는 동작은 Speed를 올려주는 요소이다.

=> 따라서 speed와 accuracy 간에는 trade off가 존재한다.

---

* Error prevention

 

1. Capture error prevention

- 서술했듯이 Capture error는 주로 익숙한 동작의 빌드업을 가지나 중간에 다른 작업을 해야하는 유사성이 있는 작업에서 발생한다.

=> 따라서 저렇게 파란색 3단계를 거치고 주황색으로 진입하는 것이 아니라, 아예 시작점부터 주황색으로 시작하게 하는 방법. 즉 처음부터 익숙한 행동으로 시작이 되지 않게끔 분기시켜버리는 방법이 좋다.

 

2. Description error prevention

- 비슷한 형태를 피한다.

- 붙여둬서 치명적인 기능은 떨어뜨려놓는다. (ex: 저장 버튼 옆에 초기화 버튼을 두면 안된다.)

 

3. Mode error prevention

- mode 자체를 없애는 것이 safety 관점에서는 최고이다. 그러나 이는 speed를 없애는 결과를 초래할 수 있어 현실적으로 어렵다.

=> 그러므로 현재 내가 어떤 mode에 있는지를 알려주는 visibility를 증가시키면 어느정도 개선이 가능하다.

(caps lock이 켜져있다고 알려주기.)

=> 혹은 shift를 누르고 대문자를 치는 것처럼 mode를 일시적으로만 킬 수 있게 구성해도 된다.

 

* Safety by Forcing User Interaction

-> 사용자의 상호작용의 범위를 강제함으로써 Safety를 확보할 수도 있다.

 

1. Interlock : 내부에서 자체적으로 특정 조건 성립시 action을 막는 것이다. (ex: 근처에 사람이 있다면 불이 켜지지 말 것.)

=> Action에 mutual dependency를 넣는 것이다.(Sequence 생성)

2. Lockin : 실수로 중요한 트렌젝션이 망가지지 않도록 강제로 특정 action을 유지시키는 것이다.(ex: 업데이트 중 다른 것 불가)

3. Lockout : 중요한 작업을 하기 이전, User에게 한번 더 체크를 하는 것이다.

(ex: 메일을 보내기 이전 메일 전문을 한번 더 보여줌. - Confirmation Dialogs)

 

* Confirmation Dialogs

- 사전 확인을 한번 더 받아서 Safety 면에서는 효과가 있다.

- 그러나 efficiency를 심하게 떨어뜨리고, 익숙해질시 safety 효과도 많이 사라진다.

=> 따라서 undo와 같은 reversibility가 확인을 받는 것보다 더 좋은 접근이다.

 

* Writing Error message Dialogs

=> 제일 좋은 케이스는 미리 error를 예방하거나 좀 더 시스템을 flexible, tolerant하게 짜는 것이다. 

=> 그러나 부득이하게 출력해야한다면, 정확하, user의 input의 문제점을 알려주며, user의 언어로 출력하는 것이 맞다.

=> 즉, 너무 전문적이게 오류를 출력하는 것이 아니라 확실한 오류의 이유와 해결법을 쉽게 말해주는 것이 좋은 것이다.

 

* Clearly Marked Exits

- 긴 작업과 같은 경우에는 취소할 수 있는 여지를 주어야한다. 따라서 모든 dialog는 cancel 버튼이 있어야한다.

 

* Never Ask Me Again

- Dialog에 다시 묻지 않기가 있는 경우를 많이 봤을 것이다. 이를 사용할 시 효율성(speed)는 당연히 올라갈 것이다. 그러나 오류가 발생했을 때 습관처럼 사용하던 사람들은 자신의 옵션 등을 까먹을 가능성이 높다.(정확도 하락)

=> Efficiency와 Accuracy는 trade-off이다.

 

* CRUD

- user에 의해 입력된 input은 user에 의해 변경이 가능해야한다.

- 따라서 UI는 다음과 같은 기능을 제공해야한다.

1. Create a data item

2. Read it

3. Update it

4. Delete it

---

 

* Support Undo

- 대표적인 실수 회복 방안이다. Undo/Redo가 있다. 요새는 대부분의 프로그램이 Multiple undos 를 지원한다.

 

* Forming a Mental Model of Undo

- Undo는 action의 효과를 무효화한다.

- 그러나 Undo에는 몇가지 고려할 사항이 있따.

1. 얼마만큼이나 undo 해야하는가?

2. 어떻게 action 중에 undo가 가능한 놈들만 골라 담지?

3. 어떤 것이 undoable한 action일까?

4. 얼마나 많은 prev. action을 커버해야할까

 

* What will be undone?

- 현재 창에서의 Action만(Word), 전체적인 app에서(Excel), 모두의 action(multiuser apps), 컴퓨터에 의한 action도(MS Office의 AutoCorrect와 AutoFormat은 user가 하지 않고 컴퓨터가 자동으로 한거라도 undo가 가능하다.)

 

* How is the stream divided into units?

- 어떤 단위로 undo가 되어야할까? => UX에 중요한 사항이다.

1. Lexical Level(마우스 클릭, 움직임 등) => 너무 하위 level이다.

2. Syntactic Level(Commands and buttom presses)

3. Semantic Level(데이터 구조를 바꾸는 변화 -> 이것이 일반적인 level 이다.)

4. Text entry is aggregated into a single action(그러나 문맥 단위로 하기에는 개행문자 등이 수집에 방해가 된다.)

5. User defined Level

 

* Which actions are undoable?

- application과 UX에 따라 매우 다양하다. (Selection, Keyboard focus, Changing viewpoint, Layout change 등)

 

* How far back can you undo?

- history size로 undo 가능 range 관리.(메모리 효율은 떨어진다.)

- application을 껏다 켜도 undo가 되려면 action stream도 파일에 따로 저장해둬야한다.

 

* Undo의 디자인 원칙

1. Visibility : 사용자가 쉽게 접근할 수 있는 방식으로 기능 제공해야함.(ex : ctrl+Z)

2. Aggregation : 여러 작업을 한번에 취소 가능해야함.

3. Reversibility of the Undo itself (Redo) : Undo 자체를 취소 가능해야함.

=> Undo만이 reversibility를 확보하는 방법은 아닌 것을 명심하자.(Undo 말고도 사용자가 작업을 되돌릴 수 있는 다른 방법이 있어야한다.)