소프트웨어 공학에 소프트웨어 개발 주기가 있듯이, 사용자 인터페이스 디자인에도 개발 주기가 있다. 사용자 인터페이스 디자인에 Shneiderman, Gould, Scapin과 같은 많은 연구자와 실무자들이 방법론을 정의하고자 노력하고 있다. ‘Developing Software for the User Interface’에 나오는 방법론을 간단히 소개하겠다.
사용자 인터페이스 설계 단계는 소프트웨어 공학의 개발 단계와 관련 지을 수 있다. 사용자 인터페이스 설계 단계에서 문제 정의, 사용자 모델 정의, 작업 분석 단계는 소프트웨어 공학의 문제 정의 및 요구 분석 단계에 해당하고, 컴퓨터 오브젝트 및 기능 정의, 사용자 인터페이스 모습과 행동 정의는 설계 단계에 해당한다. 각 단계별로 세부 내용을 살펴보자

그림 5. 사용자 인터페이스 설계 단계와 소프트웨어 공학의 설계 단계

1단계 : 문제 정의

해결하기 원하는 문제를 정의한다. 형식 또는 비형식적으로 시스템의 목적을 기술한다.
 

2단계 : 사용자 모델 정의

이 단계에서는 사용자의 특성을 결정한다. 사용자의 특성을 명확히 하지 않고는 좋은 사용성을 가진 시스템을 만들 수 없다. 시스템은 사용자 중심(Norman and Draper, 1986)이어야 하고, 디자이너는 사용자를 알아야 한다(Hnsen 1971).
사용자와 이야기하는 것은 사치가 아니라 필수다(Gould 1988). 사용자를 알아야 한다는 것은 디자이너가 사용자의 어떤 레벨을 지원해야 하는지를 결정해야 함을 뜻한다.
슈나이더만(Shneiderman)은 사용자를 초보자, 중급자, 숙련자로 분류했다. 이 분류는 사용자의 컴퓨터 소프트웨어와 작업에 대한 지식 정도에 따른 것이다.

• 초보자는 컴퓨터 시스템에 대해서는 잘 모르고, 해야 할 작업에 대해서는 조금 아는 사용자를 말한다.
• 중급자는 작업이나 컴퓨터 이슈에 대해서는 잘 알지만 컴퓨터 시스템의 세부 내용에 대해서는 잘 모르는 사용자를 말한다.
• 숙련자는 컴퓨터 시스템이나 작업에 대해서 잘 아는 사용자를 말한다.

사용자는 컴퓨터 시스템에 대해서는 잘 알아도 수행해야 할 작업에 대해서는 초보자일 수 있다. 반대로 컴퓨터 시스템에 대해서는 몰라도 작업에 대해서는 잘 알 수 있다.
예를 들어, 컴퓨터와 관련된 일을 하는 사람은 컴퓨터에 대해 잘 알지만, 작업을 수행하기 위한 시스템에는 초보자가 된다.
따라서 시스템을 설계할 때는 시스템 사용자는 컴퓨터를 아무리 많이 알아도 작업 방법에 대해서는 초보자임을 간과해서는 안된다. 또는 하고 있는 업무를 전산화하는 경우에도 업무는 잘 알지만 컴퓨터 시스템에 대한 지식은 없을 수 있으므로 사용자 인터페이스 설계 시에 이러한 사용자들의 특성 등을 고려해야 한다.
 

3단계 : 작업 분석

문제를 정의하고, 사용자에 대한 정보를 얻은 다음에는 시스템을 통해 수행되어야 할 작업들을 정의한다. 작업 분석(Task Analysis)은 항상 해결해야 할 문제를 정제하고 사용자의 특징들을 세부화한다.
작업 분석의 목적은 해야 할 것을 확인하고, 사용자의 심성모형, 하드웨어 특성 등 환경적인 요소와 일치하여 작업 영역을 구조화한다. 이 작업이 끝난 다음에는 사용자가 컴퓨터를 이용해 수행해야 할 구체적인 작업과 개념이 나와야 한다.
 

작업 분해

사용자는 작업을 할 때 큰 작업 분량을 한 개의 작업이 될 때까지 더 작은 작업들로 쪼개려는 경향이 있다. 작업을 분해하는 방법 중 한가지는 다음과 같다.

1. 작업에 대해 독립적인 개념을 고려하고 작업을 수행하기 위해 동작 숫자를 수치화 한다.
2. 작업과 서브작업으로 나누어 계층화한다.

작업을 위한 동작은 단위 작업과 관련이 있다. 작업에 독립적인 개념은 사용자에 의해 받아들여지는 작업을 정의하는 동작과 관련이 있다. 소프트웨어 면에서 작업은 기능에 대한 추상적인 자료구조와 관련이 있고, 사용자의 입장에서는 시스템이 제공하는 서비스를 결정하게 된다.
작업 분석 단계를 통해서 전체 시스템에 대한 기능적인 기초를 다지게 되므로 사용자가 작업을 이해하지 못하면 작업 수행 중 에러가 발생할 빈도가 높아진다.
만약 작업이 너무 잘게 쪼개지면 사용자는 원하는 작업을 하기 위해 많은 작업을 통해야 가능할 수 있다. 또한 작업이 너무 큰 덩치로 구성되면 사용자는 필요한 컨트롤을 하지 못할 수도 있다.
 

4단계 : 컴퓨터 오브젝트 및 기능 정의

분석한 작업을 컴퓨터의 어떤 사용자 인터페이스를 통해 표현할 것인지를 정의한다. 실제로 사용자는 시스템을 통해 작업할 경우, 컴퓨터 오브젝트를 통해 수행한다. 따라서 사용자가 수행해야 할 동작을 작업에 직접적으로 관련되도록 한다. 작업에 대해 컴퓨터의 직접적인 표현은 사용자의 정신적인 수고를 덜어 줄 수 있다.
작업을 컴퓨터 오브젝트와 일치시켜야 한다. 그리고 작업 수행을 향상시키기 위해 입력 취소(Undo)나 잘라내기-복사-붙여넣기(Cut-Copy-Paste), 온라인 도움말 등과 같은 일반적인 컴퓨터 서비스를 제공하고, 상호작용을 시스템이나 사용자중 누가 이끌어 갈지 결정해야 한다.
 

5단계 : 사용자 인터페이스 정의

이 단계에서는 작업 모델을 작업자가 예측한 대로 사용자 인터페이스를 정의한다. 사용자 인터페이스 설계에서는 컴퓨터나 작업 수행 방법에 대한 상호작용하는 오브젝트를 선택하고, 시스템의 상태를 명확히 한다.
 

상호작용 오브젝트 선택

상호작용 오브젝트란 작업을 하기 위한 마우스나 키보드, 스크린 등의 물리적인 입력이나 출력 디바이스를 말한다. 사용자 인터페이스 단계에서는 추상적인 작업을 실제적인 하드웨어를 통해 구체화해야 한다.
사용자 인터페이스 설계에 있어 일관성 있고, 구체적인 액션의 연속성을 제공하거나 사용자 인터페이스로 표현한 것과 그것이 뜻하는 것의 차이를 줄이기 위해서 적당한 상호작용 오브젝트를 선택해야 한다.
여기서 일관성은 사용자 인터페이스에서 보고 느끼는 것의 일관성을 말한다. 일반적으로 이를 향상시키기 위해 메타포와 사용자 인터페이스 구성요소를 사용한다. 메타포는 오브젝트를 사용자 인터페이스에 은유하는 것이고, 여기서 사용자 인터페이스 구성 요소는 다음에 소개하는 버튼이나 스크롤바, 윈도우 등을 말한다.
따라서 사용자 인터페이스를 설계할 때 이러한 사용자 인터페이스 구성 요소들을 적절히 사용하여 사용자와 상호작용할 수 있도록 해야 한다.
 

시스템의 상태를 명확하게 한다

사용자가 시스템을 사용하기 위해 버튼과 같은 상호작용 오브젝트를 선택하지만 시스템의 동작 상태는 알 수 없다. 따라서 작업 계획을 세우고, 에러를 감지하고, 에러 복구 등을 제공하기 위해 시스템의 상태를 사용자 인터페이스를 통해 사용자에게 명확히 알려주어야 한다. 이는 피드백을 통해 이루어진다는 것을 이미 언급한 바 있다.
사실 사용자와 시스템과의 상호작용은 사용자의 액션과 시스템의 피드백으로 이루어진다. 따라서 사용자 인터페이스 설계에 있어 시스템의 상태를 명확히 하고 사용자에게 피드백을 주는 것은 매우 중요하다.
예를 들어 워드프로세서에서 현재 입력 모드가 수정모드인지 삽입 모드인지를 표시하는 것이나, 웹 브라우저에서 온라인 상태인지 보안 상태인지를 표시하는 것은 사용자가 시스템의 현재 상태를 알 수 있게 한다. 일반적으로 윈도우 하단의 ‘상태바’라는 컨트롤을 통해 시스템의 현재 상태를 보여준다.
 

그림 6. 넷스케이프의 상태 바

6단계 : 디자인 평가

디자인 평가 단계는 설계한 인터페이스가 분석한 작업에 맞게 잘 설계가 되었는지, 사용자의 능력이나 지식에 대해 적당한지, 사용자가 쓰기 쉽고 편리한지 등을 평가한다. 사용자 인터페이스를 코딩을 통해 구현한 뒤 수정하는 것은 어렵고 많은 비용이 소요되므로, 디자인 평가는 코딩으로 구현되기 전에 이루어져야 하고, 여러 단계를 통해 평가해야 한다.
평가를 위해서는 프로토타이핑 방법을 사용하는 것이 좋다. 인터페이스를 종이에 그려서 하는 방법도 있고 컴퓨터를 이용하는 방법도 있다. 요즘은 그래픽 툴이 매우 좋아 프로토타이핑 하기에는 매우 편리하다. 델파이나 비쥬얼 베이직과 같은 비주얼 툴을 이용하면 실제 시스템에서 동작할 수 있는 프로토타입을 쉽게 만들 수 있다.
작업을 수행하기 위한 시나리오를 만들어서 사용자가 시나리오를 따라 작업을 수행하도록 하거나 설문을 통하는 방법도 있다. 이밖에 사용성 평가 실험실을 통해 설계한 인터페이스에 대한 사용성 평가(Usability Testing)를 할 수 있다.
코딩에 대한 기능상의 오류를 찾기 위한 베타 테스트가 아니라 사용성 측면에서 인터페이스가 잘 설계되었는지를 테스트하는 것이다. 평가 방법론은 GOMS (Goals, Operators, Methods, Selection rules)나 휴리스틱(Heuristic) 등의 사용성 공학(Usability Engineering)의 방법론이 있다.
간략히 GOMS와 휴리스틱 평가 방법론을 소개하면 다음과 같다. GOMS는 사람이 화면에서 어떤 오브젝트를 보는데 몇 초가 걸리고, 인지하는데 몇 초가 걸리고, 결정을 해 마우스를 클릭하는데 몇 초가 걸리니 이 인터페이스는 어떻다! 라는 매우 분석적인 평가 방법이고, 휴리스틱 평가 방법은 전문가로 구성된 집단에서 설계한 사용자 인터페이스에 대해 의견을 내게 하여 인터페이스를 평가하는 방법이다.
일반적으로 GOMS는 비용이 많이 들지만 평가에 대한 정확도는 높고, 휴리스틱 평가 방법론은 비용은 적게 들지만 정확한 평가가 되지 않을 수 있다. 기업에서는 비용이 적게 드는 휴리스틱 방법론을 많이 사용한다.