이 항목에서는 유용성 개념과 소프트웨어 디자인 프로젝트의 중요한 부분이 되어야 하는 이유를 소개합니다.
소개
소프트웨어를 만드는 컨텍스트에서 "유용성"이라는 용어는 시스템이 아닌 사용자를 프로세스의 중심에 두는 접근 방식을 나타냅니다. 사용자 중심 디자인이라고 하는 이 철학은 디자인 프로세스의 시작부터 사용자의 관심사와 옹호를 통합하고 사용자의 요구가 디자인 결정에서 가장 중요해야 함을 지시합니다.
이 방법에서 가장 눈에 띄는 측면은 사용자가 제품 인터페이스를 작업하고 상호 작용하고 디자이너 및 개발자와 자신의 견해와 관심사를 공유하는 유용성 테스트입니다.
유용성 정의
이 섹션에서는 소프트웨어 개발의 컨텍스트에서 유용성이 무엇을 의미하는지, 그리고 소프트웨어가 개발 프로세스의 다른 측면과 어떤 관련이 있는지를 정의합니다.
사용 편의성
유용성은 제품을 사용하여 규정된 작업을 수행하는 것이 얼마나 쉬운지를 측정하는 척도입니다. 이는 유틸리티 및 유사성에 대한 관련 개념과 다릅니다.
유용성 및 유틸리티
제품의 품질을 결정하는 중앙 특성은 유용성입니다. 이렇게 하면 제품의 실제 사용이 디자이너가 달성하려는 목표를 달성할 수 있는지 여부를 측정합니다. 유용성 개념은 유틸리티 및 유용성으로 더욱 확장됩니다. 이러한 용어는 관련되어 있지만 서로 교환할 수 없습니다.
유틸리티는 제품에서 작업 또는 작업을 수행하는 기능을 나타냅니다. 제품이 수행하도록 디자인된 작업이 많을수록 더 많은 유틸리티를 사용할 수 있습니다.
1980년대 후반의 일반적인 Microsoft MS-DOS 워드 프로세서를 고려해 보세요. 이러한 프로그램은 많은 강력한 텍스트 편집 및 조작 기능을 제공했지만, 사용자는 이를 수행하기 위해 수십 개의 비전 키 입력을 배우고 기억해야 했습니다. 이와 같은 애플리케이션은 높은 유틸리티(사용자에게 필요한 기능을 제공)하지만 유용성이 낮다고 할 수 있습니다(사용자는 학습하고 사용하기 위해 많은 시간과 노력을 기울여야 합니다). 대조적으로, 계산기와 같은 잘 디자인 된 간단한 응용 프로그램은 사용하기가 매우 쉬울 수 있지만 많은 유틸리티를 제공하지 않습니다.
두 가지 자질은 모두 시장 수용에 필요하며, 둘 다 전체 유용성 개념의 일부입니다. 물론 프로그램이 매우 사용 가능하지만 가치 있는 작업을 수행하지 않는 경우 아무도 사용하지 않습니다. 그리고 사용하기 어려운 강력한 프로그램을 제공하는 사용자는 저항하거나 대안을 모색 할 가능성이 높습니다.
유용성 테스트를 통해 사용자가 특정 작업을 수행하는 것이 얼마나 쉬운지 확인할 수 있습니다. 그러나 제품 자체에 값이나 유틸리티가 있는지 직접 확인하는 데는 도움이 되지 않습니다. (사용자는 유용성 테스트 중에 유틸리티 관련 의견을 자원할 수 있지만, 다른 보다 강력한 연구 방법을 사용하여 의견을 확인해야 합니다.)
그것을 좋아하고 그것을 사용
유사성은 항상 제품에서 바람직한 특성입니다. 사람들이 제품을 좋아하는 경우, 그들은 그것을 사용 하 고 다른 사람에 게 그것을 추천 가능성이 높습니다. 그러나 유틸리티와 마찬가지로 유용성과 유사성을 혼동하지 않도록 주의해야 합니다.
사람들은 유틸리티 및 유용성과 관련이 없는 이유로 제품을 자주 좋아합니다. 그들은 그 스타일에 끌리거나 제품이 그들에게 부여한다고 믿는 상태에 끌리게 될 수 있습니다. 사람들은 일반적으로 매우 사용 가능한 제품을 좋아하지만 잘 좋아하는 제품을 사용할 수 있다고 가정해서는 안됩니다.
유용성은 사용자가 제품을 사용하여 수행해야 하는 작업을 수행할 수 있는지 여부에 관한 것입니다. 유용성 테스트는 주로 기본 설정이 아닌 성능을 측정합니다. 그러나 표준화된 설문지를 사용하여 제품 전체의 기본 설정을 측정할 수 있습니다.
검색 및 학습 및 효율성 비교
유용성에는 많은 측면이 있지만 일반적으로 이 용어는 특히 검색, 학습 및 효율성의 특성을 나타냅니다.
- 검색에는 특정 요구 사항에 대한 응답으로 제품의 기능을 찾고 찾는 작업이 포함됩니다. 유용성 테스트는 사용자가 기능을 찾는 데 걸리는 시간과 사용자가 수행하는 오류 수(위치에 대한 잘못된 선택)를 결정할 수 있습니다.
- 학습은 사용자가 검색된 기능을 사용하여 작업을 완료하는 방법을 이해하는 프로세스를 나타냅니다. 유용성 테스트는 이 프로세스에 걸리는 시간과 사용자가 기능을 학습하는 동안 발생하는 오류 수를 결정할 수 있습니다.
- 효율성은 사용자가 기능을 "마스터"하고 추가 학습 없이 사용하는 지점을 나타냅니다. 유용성 테스트는 숙련된 사용자가 기능을 사용하는 데 필요한 단계를 실행하는 데 걸리는 시간을 결정할 수 있습니다.
이러한 세 가지 기본적인 유용성 측면은 현재 진행 중인 작업의 특성과 사용자가 수행하는 빈도에 따라 크게 영향을 받습니다. 일부 기능은 거의 사용되지 않거나 너무 복잡하여 사용자가 기본적으로 매번 다시 학습합니다. 이러한 기능을 위해 Microsoft는 종종 프로세스를 통해 사용자를 안내하는 마법사를 개발합니다.
슬로건이 작동하지 않음
소프트웨어 개발자는 "제품을 더 유용하게 만들기"와 같은 간단한 슬로건이 유용성 문제를 해결하는 데 도움이 될 것이라고 생각하는 경우가 있습니다. 유용성에 대한 긍정적인 태도는 중요하지만, 생성되는 특정 제품의 맥락에서 일반 사용자와의 적절한 유용성 테스트만 개발자에게 사용자의 요구를 충족하는 제품을 만드는 데 필요한 정보를 제공할 수 있습니다. "제품을 더 유용하게 만들기"는 모든 소프트웨어 개발자의 슬로건이어야 하지만 개발자가 유용성의 의미를 알고 있는 경우에만 의미가 있습니다. 일반 사용자로 테스트하는 것이 가장 신뢰할 수 있는 방법입니다.
유용성이 중요한 이유는 무엇인가요?
이 섹션에서는 유용성이 중요한 이유와 사용자 중심 디자인 원칙을 개발 프로세스에 통합하는 방법에 대한 몇 가지 일반적인 질문에 답변합니다.
왜 신경써야 할까요?
유용성 고려 사항이 제품 디자인 프로세스에 아직 통합되지 않은 경우 왜 필요하거나 바람직한지 궁금할 수 있습니다. 결국, 유용성 작업을 전혀 수행하지 않고 버그가 없는 작업 제품을 릴리스할 수 있습니다. 그러나 사용자 중심 디자인 원칙을 통합하면 여러 영역에서 훨씬 향상된 제품으로 이어질 수 있습니다.
유용성 테스트를 수행하는 가장 좋은 이유는 사용자의 지원 호출 수를 줄이기 위한 것입니다. 부실한 유용성은 사용자가 소프트웨어 기술 지원 라인을 호출하는 주요 이유이며, 모든 소프트웨어 회사 임원 및 Information Services 관리자는 제품 지원이 얼마나 비싼지 알고 있습니다. 또한 사용자에게 지원을 청구하면 제품에 대한 불만의 가능성이 높아질 수 있습니다. 사용자가 제품을 쉽게 사용할 수 있는 경우 기술 지원을 자주 요청할 필요가 없습니다.
내부 사용을 위해 생성된 소프트웨어의 경우 유용성을 개발 프로세스의 중요한 부분으로 만드는 다음으로 가장 좋은 이유는 학습 비용을 줄이는 것입니다. 매우 사용 가능한 제품은 유용성이 높은 우선 순위가 아닌 제품보다 사용자가 학습하는 것이 훨씬 쉽습니다. 사용자는 기능을 더 빨리 학습하고 지식을 더 오래 유지하므로 학습 비용 및 시간 감소와 직접적인 상관 관계가 있습니다.
유용성 테스트는 사용자 수용을 개선하는 데 도움이 됩니다. 수용은 유용성, 유틸리티 및 유사성을 비롯한 여러 가지 요인으로 인해 발생합니다. 소매 제품의 경우, 사용자 동의는 종종 구매를 반복하거나 충성도와 직접적인 상관 관계를 가지며, 이는 사용자가 다른 사람에게 제품을 추천할 가능성이 높다는 것을 의미합니다. 내부 애플리케이션의 경우 사용자 동의는 소프트웨어를 사용하여 설계한 작업을 수행하여 생산성을 높이는 데 도움이 되는 의지와 관련이 있습니다. 유용성 증가는 사용자 수용 증가에 기여할 수 있는 요인 중 하나입니다.
유용성은 경쟁사와 제품을 차별화하는 데 도움이 될 수 있습니다. 두 제품이 유틸리티에서 실질적으로 같으면 더 나은 유용성을 가진 제품은 아마도 우수하다고 간주될 것입니다. 또한 Windows 모양 및 느낌과 함께 제공되는 프로그래밍 지침은 기본 사용자 인터페이스에 대한 경기장을 평준화하여 유사한 기능을 제공하는 많은 프로그램이 모양과 동작을 약간 비슷하게 표시하고 작동합니다. 이러한 유사성은 유용성의 작은 차이가 사용자 기본 설정에 큰 영향을 미칠 수 있음을 의미합니다.
마지막으로, 모든 제품은 결국 유용성을 테스트합니다. 사용자는 제품을 사용할 때마다 제품에 대한 유용성 테스트를 수행하고, 지속적인 사용 또는 부족을 통해 평결을 렌더링합니다. 제품을 출시하기 전에 테스트하면 제품에 대한 사용자의 환경이 긍정적인지 확인하는 데 도움이 될 수 있습니다.
비용은 어떻게 됩니까?
소프트웨어 개발자와 프로젝트 관리자는 사용자 중심 디자인 프로세스를 시작하고 적절한 유용성 테스트를 수행하려면 허용할 수 없는 시간과 비용을 필요로 하는 경우가 많습니다. 현실은 사용자에 초점을 맞추는 데 소요되는 시간과 비용의 비용이 상대적으로 작은 경우가 많으며, 그렇지 않은 비용과 비교할 때 확실히 그렇게 됩니다.
예를 들어 제품이 여전히 드로잉 보드에 있을 때 이전과 달리 개발 주기 후반에 디자인 수정을 하는 데 드는 시간과 비용을 고려합니다. 베타 기간이 지나면 유용성 테스트를 위해 제품에 사용자를 노출할 때까지 기다리면 개발하는 데 많은 시간이 걸린 프로그램의 일부가 해체될 수 있습니다. 그리고 제품이 실제로 출시 될 때까지 기다린 다음 부정적인 피드백에 따라 변경하거나 가난한 디자인을 지원하면 높은 제품 지원 비용 또는 사용자의 열악한 수신으로 인해 비용이 헤아릴 수 없을 정도로 높아질 수 있습니다.
합리적인 유용성 연구는 일반적으로 약 2주 이내에 수행될 수 있으며 개발 주기 후반에 변경을 수행하는 시간과 비용을 크게 줄일 수 있습니다. 테스트 수행 비용은 제품의 특성 및 테스트되는 인터페이스 부분에 따라 달라집니다.
유용성 테스트는 코드 테스트와 비슷하다고 생각합니다. 성공적인 프로젝트 관리자는 개발 프로젝트를 계획할 때 코드 테스트를 담당합니다. 프로젝트 일정 및 예산에 따라야 하는 추가 항목으로 볼 수 없습니다. 대신, 대안이 훨씬 더 비싸기 때문에 프로젝트 관리자는 코드 테스트를 비즈니스 비용으로 수락합니다. 유용성 테스트도 마찬가지입니다.
유용성을 높이면 어떻게 해야 하나요?
유용성의 중요성을 읽고 이해하면 소프트웨어 개발자는 사용 편의성을 더하기 위해 단순히 제품에 추가할 수 있는 성분인 것처럼 유용성을 추가하려는 유혹을 받습니다. 대신 유용성은 여기 또는 그곳의 프로세스에 추가되는 "사물"이 아니라 디자인 프로세스 자체의 일부여야 합니다. 유용성 전문가가 "사용자 포커스" 및 "사용자 중심 디자인"을 언급하는 이유는 사용자의 요구 사항을 디자인 프로세스의 중심으로 유지하는 데 따라 유용성이 달라지기 때문입니다. 필요에 따라 사용자 중심 디자인에는 인터페이스의 단추 및 메뉴 배치를 제어하는 규칙 집합을 따르는 것 이상이 포함됩니다. 유용성 테스트는 디자인 작업을 확인할 수 있는 기회입니다. 그것은 제품에 유용성을 "추가"하는 방법이 아닙니다.
굴드, 보이스, 루이스(1991)는 사용자 중심 디자인의 네 가지 중요한 신조를 식별합니다.
사용자에게 초기에 집중합니다.
개발자는 디자인 프로세스 초기에 사용자의 요구 사항을 이해하는 데 집중해야 합니다.
통합 디자인.
디자인의 모든 측면은 순서가 아닌 병렬로 진화해야 합니다. 제품의 내부 디자인을 사용자 인터페이스의 요구 사항과 일치하도록 유지합니다.
초기 및 지속적인 테스트.
소프트웨어 디자인에 대한 현재 가능한 유일한 접근 방식은 경험적 접근 방식입니다. 실제 사용자가 작동한다고 결정하면 디자인이 작동합니다. 개발 프로세스 전반에 걸쳐 유용성 테스트를 통합하면 제품이 출시되기 전에 디자인에 대한 피드백을 제공할 수 있습니다.
반복 디자인.
큰 문제는 종종 작은 문제를 마스크. 디자이너와 개발자는 테스트를 통해 디자인을 반복적으로 수정해야 합니다.
사용자를 포함해야 하는 이유는 무엇인가요?
개발자는 일반적인 사용자가 아니라는 것을 인식해야 합니다. 그들은 평균 사용자보다 개발 중인 시스템에 대한 더 친밀한 지식과 이해를 가지고 있습니다. 따라서 대부분의 사용자에게 명확하지 않거나 혼동되는 인터페이스의 측면은 프로젝트에서 작업한 사람에게 완벽하게 명확할 수 있습니다. 일부 소프트웨어 개발자는 평균 사용자와 어느 정도 공감할 수 있지만 실제 사용자와 제품의 실제 상호 작용을 대체할 수는 없습니다.
따라서 일반적인 사용자의 요구 사항에 일찍 집중하고 사용자 테스트를 기반으로 디자인을 수정함으로써 사용자 중심 소프트웨어 개발자는 더 나은 디자인을 생성하고 결과적으로 더 나은 제품을 생성합니다.
더 나은 디자인으로 사용자의 수용이 향상됩니다. 소매 소프트웨어의 이점은 분명합니다: 판매 증가. 내부 사용을 위해 개발된 소프트웨어에서도 수용이 중요합니다. 사용자 중심 디자인에 대한 집중을 늘리면 생산성이 향상되고 지원 필요성이 줄어듭니다. 또한 개발 초기부터 사용자를 눈에 띄게 참여시키는 것은 사용자의 관심사와 요구에 대한 관심을 보여 줍니다. 이는 개발 노력에 도움을 줄 의지를 증가시키는 것입니다.
지침을 따를 수 없나요?
Microsoft는 Windows 프로그램이 일관된 모양과 느낌을 갖도록 Windows 컴퓨팅 플랫폼에 대한 인터페이스 지침 집합을 개발했습니다. 다른 회사는 다른 컴퓨팅 플랫폼에 대한 유사한 지침을 개발했으며 Jakob 닐슨과 같은 유용성 전문가들은 사용 가능한 웹 페이지 설계에 대해 광범위하게 작성했습니다. 이러한 항목에서 사용할 수 있는 풍부한 정보를 통해 디자이너는 사용 가능한 제품을 생산하는 데 필요한 지침 및 표준을 엄격하게 준수하는 것이 전부라고 생각하는 경우가 있습니다.
이 방법의 문제는 지침이 본질적으로 일반적이라는 것입니다. 지침은 다양한 경우에 적용되어야 하므로 개발 중인 특정 애플리케이션에 대한 최선의 조치 과정을 항상 규정하지는 않습니다. 잘 작성된 지침 집합을 준수하면 일관된 인터페이스를 디자인하는 데 도움이 될 수 있지만 실제 사용자로 테스트하지 않는 한 유용성을 보장할 수 없습니다. 지침을 사용하는 경우 지침이 모든 결과의 최고를 가리키는 요리책처럼 사용하지 마세요. 두 개발자는 서로 다른 두 가지 방법으로 동일한 지침을 구현할 수 있으며 두 구현 모두 상황에 똑같이 적합하지 않을 수 있습니다. 경우에 따라 지침을 엄격하게 준수하면 결과가 나빠지거나 지침 간의 충돌이 발생할 수 있습니다. 사용자 중심 디자인만 문제가 되기 전에 이러한 문제를 플러시하는 데 도움이 될 수 있습니다.
이에 대해 생각하는 또 다른 방법은 사용자 중심 디자인이 사용자 인터페이스 지침이 아닌 디자인 결정의 중재자가 되도록 하는 것입니다.
유용성 랩을 빌드해야 하나요?
유용성 테스트는 천장에 장착된 카메라, 단방향 미러 및 기타 포커스 그룹 트래핑을 사용하여 비용이 많이 드는 랩에 커밋하는 것을 의미한다고 가정하지 마세요. 확실히, 많은 테스트를 수행하는 회사는 종종 전용 랩을 구축하는 것이 편리하다고 생각하고 유용성 컨설턴트는 종종 고객에게 제공하는 다양한 시설과 장비를 가지고 있습니다. 그러나 유용하고 유효한 유용성 테스트는 다양한 설정 및 상황에서 수행할 수 있습니다.
한 가지 방법은 단순히 테스터가 인간 참가자 연구를 수행하고 데이터를 수집하는 데 정통한 사람이 작업할 때 사용자 뒤에 앉아 작업을 수행하는 사용자를 관찰하는 것입니다. 회의실이나 사무실에서 쉽게 수행할 수 있습니다. 관찰을 사용한 테스트에 대한 자세한 내용은 다른 리소스의 Dumas 및 Redish 항목을 참조하세요.
유용성 테스트가 개발되고 점점 더 복잡해짐에 따라 비디오 카메라, 단방향 미러 또는 사용자의 모니터를 실시간으로 보고 기록할 수 있는 도구와 같은 장비를 추가할 수 있습니다.
또는 유용성 컨설턴트에게 테스트를 아웃소싱할 수 있습니다. 다음 섹션에는 올바른 컨설턴트를 찾는 방법에 대한 팁이 포함되어 있습니다.
시작하려면 어떻게 해야 하나요?
개발 프로세스에 사용자 중심 디자인 원칙을 통합하기로 결정한 후에는 유용성 전문가를 고용할지 아니면 사용 가능성 테스트를 공급업체에 아웃소싱할지 결정해야 합니다.
UPA(유용성 전문가 협회)에는 유용성 컨설턴트를 찾는 데 도움이 되는 공급업체 가이드가 있습니다.
일부 컨설팅 그룹은 유용성 랩을 설정하거나 사내 유용성 프로그램을 개발하여 유용성 원칙을 디자인 프로세스에 통합하는 데 도움이 될 수 있습니다.
유용성 전문가를 고용하는 경우 휴먼 팩터 및 인체 공학 협회는 잠재적 인 직원을 찾는 데 도움이 될 수있는 배치 서비스를 제공합니다. 또한 많은 유용성 전문가는 SIGCHI(컴퓨터-인간 상호 작용) 및 UPA에 대한 ACM 특수 관심 그룹에 속합니다. 게시 또는 컨퍼런스에 고용 광고를 게재합니다.
어떤 경로를 사용하든 이러한 경로는 테스트 서비스임을 기억하세요. 디자이너가 일반적인 사용자가 아니라는 원칙은 유용성 전문가의 경우도 마찬가지입니다.
이러한 회사 및 조직에 대한 자세한 내용과 유용성 테스트 및 사용자 중심 디자인에 대한 자세한 내용은 기타 리소스를 참조 하세요.