※ 초안입니다. 대충 내용위주로 보세요. 아직 오역이 존재하며, 문장이 매끄럽지 않습니다.
우리가 관심을 두고 있는 속성인 사용성은 단순히 시스템이 얼마나 좋은가 보다는 더 정밀한 속성이다. 시스템은 다양한 방식에서 좋을 수도 있고, 나쁠 수도 있다. 중요한 요구사항을 시스템이 만족하지 못한다면 그것은 아마도 사용성의 부족이 아니라 기능성의 부족일 것이다. 시스템이 매우 고가이거나 자주 죽어버리면 이 문제는 아마도 사용자의 경험을 훼손하는 것일 것이다. 그러나 그러한 것을 이야기하기 위한 사용자 테스트가 필요한 것은 아니다. 더 좁게 정의하자면 사용성은 사용자가 시스템의 기능을 얼마나 잘 사용할 수 있는가를 측정하는 것이다. 사용성은 몇가지 기준을 가질 수 있다. : 학습성, 효용성, 기억지속성, 오류율/심각도, 주관적인 만족도.
주목해야 할 점은 사용성에 대한 이러한 모든 기준을 정량화할 수 있다는 것이다. 마치 어떤 작업에 대해 Y 알고리즘보다 X알고리즘이 더 빠르다고 말하는 것처럼 어떤 작업이나 특정 사용자층에 대하여 Y인터페이스가 X인터페이스보다 더 배우기쉽다거나, 효율적이다거나, 기억하기 쉽다고 말할 수 있다.
모든 사용자나 모든 애플리케이션에서 사용성 기준이 동일하게 중요한 것은 아니다. 그래서 여러분의 사용자를 이해하는 것이 왜 중요하며, 여러분이 무엇을 최적화해야 할 것인지를 알아야하는 이유가 된다. 수천명이 사용하는 웹사이트의 경우 쉽게 배울수 있어야 하는 조건이 중요하다. 실제로는 거의 배우지 않고도 사용할 정도여야 하며, 다른 기준들은 관심사가 아니게 된다. 전문증권맨들이 매일 사용하는 증권거래 프로그램에서는 시간이 바로 돈이므로, 다른 기준들보다는 효율성이 최고의 잣대가 된다.
그러나 사용자를 단순히 초보자나 전문가로 나눠버릴 수는 없다. 증권거래와 같은 몇몇 프로그램들에서 여러분의 사용자는 주식 시장에 대해 잘 알고 있는 해당 분야의 전문가일 수는 있지만 특정 애플리케이션에서는 여전히 초보자일 수 있다. 애플리케이션을 오래 사용한 사람도 몇몇 기능에 대해서는 초보자이거나 아주 가끔 사용한 사람이 되어버릴 수 있다.
사용성은 시스템이 가져야하는 유일한 속성이다.
• 소프트웨어 설계자는 너무 많은 것을 고민한다.:
– 기능
- 사용성
- 성능
- 크기
-비용
-신뢰성
-보안
-표준
• 설계결정중 많은 부분이 다른 속성들간의 트레이드오프와 관련이 있다.
• 이 글에서는 사용성을 최상의 가치로 둔다.
물론 사용성이 혼자 똑~ 떨어져 존재하는 것은 아니며, 시스템에서 가장 중요한 속성이 되지 못할 수도 있다.
우주비행사는 사용성보다는 항법용 컴퓨터의 신뢰성에 더 관심을 가질 수 밖에 없다. 군사 시스템은 로그인하기 쉬운 것보다는 보안을 더 중요시할 것이다. 이상적으로 이러한 시각은 잘못된 이분법이다. : 아무래도 신뢰성있고, 견고하고, 사용성이 뛰어난 시스템이 더 좋을 것이다. 그러나 현실적으로 개발자원은 한정되어 있고, 결국은 트레이드 오프가 이루어질 수밖에 없다.
이 강좌에서는 극단적으로 사용성을 최우선 목표로 삼고 이야기를 펼쳐나갈 것이다.
사용성 공학은 프로세스이다.
Design
Evaluate Implement
그럼 우리는시스템에 사용성을 어떻게 공학적으로 고려해야 할까? 답은 주의를 기울여서 상세하게 프로세스의 수단에 의해 고려해야 한다.이 과정의 목적은 사용성 공학 프로세스에 경험을 제공하는 것이다.
사용성 공학의 첫번째 단계는 여러분의 사용자가 누구이며, 그들이 무엇을 원하는지를 아는 것이다. 사용자들이 누구인가? 사용자들이 이미 알고 있는 것은 무엇인가? 사용자 환경은 어떠한가? 목적은 무엇인가? 어떤 정보를 필요로 하며, 원하는 목적을 달성하기 위해서는 어떤 과정을 거쳐야 하는가? 이것이 바로 업무 분석의 기본요소이다. 때로는 업무분석이 현장에서 이루어져야 할 때도 있다. - 그들이 실제 하는 작업을 보거나, 실제 사용자와 이야기를 나누면서 말이다.
설계 가이드라인은 사용성 공학의 중요한 부분이다. 우리는 이미 앞에서 일관성이나 가능성, 단축키, 오류 방지 등 몇가지 사항을 이야기했었다. 설계 가이드라인은 쉽게 시작할 수 있도록 도와주며, 시작부분에서 보았던 대부분의 바보같은 실수를 예방할 수 있다. 그러나 가이드라인은 경험적 지식이지, 엄격히 따라야 하고, 신속히 처리되는 그런 규칙은 아니다.
설계 가이드라인은 모호한 부분도 있고, 모순되는 부분도 있기 때문에 단순히 디자인 가이드를 따른다고 해서 사용성이 뛰어난 인터페이스를 만들 수는 없다. 어떤 가이드라인에서는 사용자를 관리해서 오류를 예방해야 한다고 한다. 그러나 다른 부분에서는 어떤 일이 일어날 것인지를 사용자가 알아야 하며, 허용할 수 있는 한계 내에서 사용자가 정신적인 부하가 유지된다는 것을 잊지 말라고 한다.
설계 가이드라인은 설계 대안을 이야기할 수 있도록 도와줄 뿐이지, 모든 정답을 제공해 주는 것은 아니다.
우리가 미리 사용성을 예측할 수 없기 때문에 프로토타입을 만든다. - 프로토타입은 가격이 저렴할 수록 더 좋은 것이다. 프로토타입은 언제든지 던져버릴 수도 있다. 뒤에서 우리는 종이가 얼마나 좋은 프로토타입 작성용 도구인지를 알게 될 것이다!
어쨌거나 결국 프토로타입은 실제로, 인터랙티브한 컴퓨터 시스템의 방식을 제공해 주어야 한다. 그래픽 사용자 인터페이스를 구조화하는 다양한 기법들이 개발되었다. 우리는 그것들이 어떻게 동작하고, 어떻게 사용하고, UI툴킷 자체가 어떻게 구현되었는지를 살펴볼 것이다.
이제 우리가 만든 프로토타입을 평가한다.- 때로는 추측에 따라 평가를 수행하기도 하지만, 실제 사용자들을 대상으로 평가한다. 테스트에 대한 구현물을 보는 것은 사용성을 측정하는 유일한 현실적인 방법이다.
반복적 설계
• 씻고, 닦고, 반복하라!
Design
Evaluate Implement
사용성 공학의 가장 중요한 부분은 반복 설계이다. 이는 설계-구현-평가 과정을 한번만 진행하는 것이 아님을 의미한다. 한번만에 우리가 원하는 것을 제대로 만들 수 없다는 사실을 인정해야한다. 평가결과를 가지고 다시 인터페이스를 설계하고 새로운 프로토타입을 만들어 평가를 더 수행한다. 결국 이러한 프로세스의 결과 충분히 사용성이 뛰어난 인터페이스가 만들어지게 된다.
우리가 이 수업과정에서 배울 많은 기법들은 반복적인 디자인 과정에 최적화되어 있다. : 설계 가이드라인은 더 나은 설계를 만드는데 이러한 반복횟수를 줄일 수 있도록 도와주는 역할을 담당한다. 저렴한 프로토타입 및 평가기법은 각각의 반복수행과정의 비용을 줄여준다. 그러나 보통 이러한 기법보다 더 중요한 것은 한방에 원하는 것을 얻을 수 없다는 점이다. 이 과정에서 사용자 인터페이스에 대해 아무것도 배우지 못하더라도, 이점은 꼭 배우기를 바란다.
사용성 정의
• 사용성(Usability) : 사용자가 얼마나 시스템의 기능을 잘 활용하는가를 나타내는 정도
• 사용성 측정 기준
– 학습성(Learnability) : 배우기 쉬운가?
– 효용성(Efficiency) : 일단 학습하고나면 빠른 속도로 사용할 수 있는가?
– 기억지속성(Memorability) : 배운것을 기억하기 쉬운가?
– 오류(Errors) : 오류가 적고, 복구가 가능한가?
– 만족도(Satisfaction) : 사용하는 것이 즐거운가?
• 사용성(Usability) : 사용자가 얼마나 시스템의 기능을 잘 활용하는가를 나타내는 정도
• 사용성 측정 기준
– 학습성(Learnability) : 배우기 쉬운가?
– 효용성(Efficiency) : 일단 학습하고나면 빠른 속도로 사용할 수 있는가?
– 기억지속성(Memorability) : 배운것을 기억하기 쉬운가?
– 오류(Errors) : 오류가 적고, 복구가 가능한가?
– 만족도(Satisfaction) : 사용하는 것이 즐거운가?
우리가 관심을 두고 있는 속성인 사용성은 단순히 시스템이 얼마나 좋은가 보다는 더 정밀한 속성이다. 시스템은 다양한 방식에서 좋을 수도 있고, 나쁠 수도 있다. 중요한 요구사항을 시스템이 만족하지 못한다면 그것은 아마도 사용성의 부족이 아니라 기능성의 부족일 것이다. 시스템이 매우 고가이거나 자주 죽어버리면 이 문제는 아마도 사용자의 경험을 훼손하는 것일 것이다. 그러나 그러한 것을 이야기하기 위한 사용자 테스트가 필요한 것은 아니다. 더 좁게 정의하자면 사용성은 사용자가 시스템의 기능을 얼마나 잘 사용할 수 있는가를 측정하는 것이다. 사용성은 몇가지 기준을 가질 수 있다. : 학습성, 효용성, 기억지속성, 오류율/심각도, 주관적인 만족도.
주목해야 할 점은 사용성에 대한 이러한 모든 기준을 정량화할 수 있다는 것이다. 마치 어떤 작업에 대해 Y 알고리즘보다 X알고리즘이 더 빠르다고 말하는 것처럼 어떤 작업이나 특정 사용자층에 대하여 Y인터페이스가 X인터페이스보다 더 배우기쉽다거나, 효율적이다거나, 기억하기 쉽다고 말할 수 있다.
사용성 기준의 중요도는 바뀐다.
• 사용자에 따라서 바뀐다.
– 초보사용자는 학습성이 필요하다.
– 가끔 사용하는 사용자는 기억 지속성이 필요하다.
– 전문가는 효용성이 필요하다.
• 그러나 완전히 초보이거나 전문가인 사용자는 없다.
– 해당 분야의 경험
– 애플리케이션 경험
– 기능 경험
• 사용자에 따라서 바뀐다.
– 초보사용자는 학습성이 필요하다.
– 가끔 사용하는 사용자는 기억 지속성이 필요하다.
– 전문가는 효용성이 필요하다.
• 그러나 완전히 초보이거나 전문가인 사용자는 없다.
– 해당 분야의 경험
– 애플리케이션 경험
– 기능 경험
모든 사용자나 모든 애플리케이션에서 사용성 기준이 동일하게 중요한 것은 아니다. 그래서 여러분의 사용자를 이해하는 것이 왜 중요하며, 여러분이 무엇을 최적화해야 할 것인지를 알아야하는 이유가 된다. 수천명이 사용하는 웹사이트의 경우 쉽게 배울수 있어야 하는 조건이 중요하다. 실제로는 거의 배우지 않고도 사용할 정도여야 하며, 다른 기준들은 관심사가 아니게 된다. 전문증권맨들이 매일 사용하는 증권거래 프로그램에서는 시간이 바로 돈이므로, 다른 기준들보다는 효율성이 최고의 잣대가 된다.
그러나 사용자를 단순히 초보자나 전문가로 나눠버릴 수는 없다. 증권거래와 같은 몇몇 프로그램들에서 여러분의 사용자는 주식 시장에 대해 잘 알고 있는 해당 분야의 전문가일 수는 있지만 특정 애플리케이션에서는 여전히 초보자일 수 있다. 애플리케이션을 오래 사용한 사람도 몇몇 기능에 대해서는 초보자이거나 아주 가끔 사용한 사람이 되어버릴 수 있다.
사용성은 시스템이 가져야하는 유일한 속성이다.
• 소프트웨어 설계자는 너무 많은 것을 고민한다.:
– 기능
- 사용성
- 성능
- 크기
-비용
-신뢰성
-보안
-표준
• 설계결정중 많은 부분이 다른 속성들간의 트레이드오프와 관련이 있다.
• 이 글에서는 사용성을 최상의 가치로 둔다.
물론 사용성이 혼자 똑~ 떨어져 존재하는 것은 아니며, 시스템에서 가장 중요한 속성이 되지 못할 수도 있다.
우주비행사는 사용성보다는 항법용 컴퓨터의 신뢰성에 더 관심을 가질 수 밖에 없다. 군사 시스템은 로그인하기 쉬운 것보다는 보안을 더 중요시할 것이다. 이상적으로 이러한 시각은 잘못된 이분법이다. : 아무래도 신뢰성있고, 견고하고, 사용성이 뛰어난 시스템이 더 좋을 것이다. 그러나 현실적으로 개발자원은 한정되어 있고, 결국은 트레이드 오프가 이루어질 수밖에 없다.
이 강좌에서는 극단적으로 사용성을 최우선 목표로 삼고 이야기를 펼쳐나갈 것이다.
사용성 공학은 프로세스이다.
Design
Evaluate Implement
그럼 우리는시스템에 사용성을 어떻게 공학적으로 고려해야 할까? 답은 주의를 기울여서 상세하게 프로세스의 수단에 의해 고려해야 한다.이 과정의 목적은 사용성 공학 프로세스에 경험을 제공하는 것이다.
설계
• 업무 분석
– "네 사용자를 알라"
• 디자인 가이드라인
– 바보같은 실수를 피하라
– 모호하거나 모순이 존재할 수 있다.
• 업무 분석
– "네 사용자를 알라"
• 디자인 가이드라인
– 바보같은 실수를 피하라
– 모호하거나 모순이 존재할 수 있다.
사용성 공학의 첫번째 단계는 여러분의 사용자가 누구이며, 그들이 무엇을 원하는지를 아는 것이다. 사용자들이 누구인가? 사용자들이 이미 알고 있는 것은 무엇인가? 사용자 환경은 어떠한가? 목적은 무엇인가? 어떤 정보를 필요로 하며, 원하는 목적을 달성하기 위해서는 어떤 과정을 거쳐야 하는가? 이것이 바로 업무 분석의 기본요소이다. 때로는 업무분석이 현장에서 이루어져야 할 때도 있다. - 그들이 실제 하는 작업을 보거나, 실제 사용자와 이야기를 나누면서 말이다.
설계 가이드라인은 사용성 공학의 중요한 부분이다. 우리는 이미 앞에서 일관성이나 가능성, 단축키, 오류 방지 등 몇가지 사항을 이야기했었다. 설계 가이드라인은 쉽게 시작할 수 있도록 도와주며, 시작부분에서 보았던 대부분의 바보같은 실수를 예방할 수 있다. 그러나 가이드라인은 경험적 지식이지, 엄격히 따라야 하고, 신속히 처리되는 그런 규칙은 아니다.
설계 가이드라인은 모호한 부분도 있고, 모순되는 부분도 있기 때문에 단순히 디자인 가이드를 따른다고 해서 사용성이 뛰어난 인터페이스를 만들 수는 없다. 어떤 가이드라인에서는 사용자를 관리해서 오류를 예방해야 한다고 한다. 그러나 다른 부분에서는 어떤 일이 일어날 것인지를 사용자가 알아야 하며, 허용할 수 있는 한계 내에서 사용자가 정신적인 부하가 유지된다는 것을 잊지 말라고 한다.
설계 가이드라인은 설계 대안을 이야기할 수 있도록 도와줄 뿐이지, 모든 정답을 제공해 주는 것은 아니다.
구현
• 프로토타입
– 저렴하게 제작하고, 버릴 수 있는 구현물
– 낮은 적합도(fidelity) : 종이, 오즈의 마법사
– 중간수준의 적합도 : HTML, Visual Basic
• GUI 구현 기법
– 입/출력 모델
– 툴킷
– UI 빌더
• 프로토타입
– 저렴하게 제작하고, 버릴 수 있는 구현물
– 낮은 적합도(fidelity) : 종이, 오즈의 마법사
– 중간수준의 적합도 : HTML, Visual Basic
• GUI 구현 기법
– 입/출력 모델
– 툴킷
– UI 빌더
우리가 미리 사용성을 예측할 수 없기 때문에 프로토타입을 만든다. - 프로토타입은 가격이 저렴할 수록 더 좋은 것이다. 프로토타입은 언제든지 던져버릴 수도 있다. 뒤에서 우리는 종이가 얼마나 좋은 프로토타입 작성용 도구인지를 알게 될 것이다!
어쨌거나 결국 프토로타입은 실제로, 인터랙티브한 컴퓨터 시스템의 방식을 제공해 주어야 한다. 그래픽 사용자 인터페이스를 구조화하는 다양한 기법들이 개발되었다. 우리는 그것들이 어떻게 동작하고, 어떻게 사용하고, UI툴킷 자체가 어떻게 구현되었는지를 살펴볼 것이다.
평가
• Evaluation puts prototypes to the test
• 전문가 평가
– 경험에 따른, Heuristics and walkthroughs
• 예측 평가
– 공학모델에 대한 테스트(시뮬레이션된 사용자)
(simulated user)
• 경험 평가
– 사용자가 어떻게 하는지를 보다. 그리고 프로토타입을 평가한다.
- 떄로는 경험에 따른 추측을 하기도 하지만, 대부분 실제 사용자에 대해 수행한다.
테스트를 구현하는 것은 사용성을 측정하는 유일한 현실적인 방법이다.
• Evaluation puts prototypes to the test
• 전문가 평가
– 경험에 따른, Heuristics and walkthroughs
• 예측 평가
– 공학모델에 대한 테스트(시뮬레이션된 사용자)
(simulated user)
• 경험 평가
– 사용자가 어떻게 하는지를 보다. 그리고 프로토타입을 평가한다.
- 떄로는 경험에 따른 추측을 하기도 하지만, 대부분 실제 사용자에 대해 수행한다.
테스트를 구현하는 것은 사용성을 측정하는 유일한 현실적인 방법이다.
이제 우리가 만든 프로토타입을 평가한다.- 때로는 추측에 따라 평가를 수행하기도 하지만, 실제 사용자들을 대상으로 평가한다. 테스트에 대한 구현물을 보는 것은 사용성을 측정하는 유일한 현실적인 방법이다.
반복적 설계
• 씻고, 닦고, 반복하라!
Design
Evaluate Implement
사용성 공학의 가장 중요한 부분은 반복 설계이다. 이는 설계-구현-평가 과정을 한번만 진행하는 것이 아님을 의미한다. 한번만에 우리가 원하는 것을 제대로 만들 수 없다는 사실을 인정해야한다. 평가결과를 가지고 다시 인터페이스를 설계하고 새로운 프로토타입을 만들어 평가를 더 수행한다. 결국 이러한 프로세스의 결과 충분히 사용성이 뛰어난 인터페이스가 만들어지게 된다.
우리가 이 수업과정에서 배울 많은 기법들은 반복적인 디자인 과정에 최적화되어 있다. : 설계 가이드라인은 더 나은 설계를 만드는데 이러한 반복횟수를 줄일 수 있도록 도와주는 역할을 담당한다. 저렴한 프로토타입 및 평가기법은 각각의 반복수행과정의 비용을 줄여준다. 그러나 보통 이러한 기법보다 더 중요한 것은 한방에 원하는 것을 얻을 수 없다는 점이다. 이 과정에서 사용자 인터페이스에 대해 아무것도 배우지 못하더라도, 이점은 꼭 배우기를 바란다.
이올린에 북마크하기


