UX디자인 (2주차) (UX 요구사항 분석)

UX Requirement Engineering

 

😎Requirement is

• 사이트나 애플리케이션이 무엇을 해야 하는지를 정의하는 문장
• 해결해야 할 전체적인 필요에 대한 통찰을 제공
• 다양한 이해관계자들이 제공하는 요구사항을 표현하고 결합
• 디자인 방향을 제시하지만, 구체적으로 어떻게 수행할지에 대한 설명은 없음
• 우선순위 설정과 추적을 위한 독립적인 작업 단위로서 기능

How to get requirements? (요구사항을 어떻게 얻을까?)

• "고객이 온라인으로 주문을 추적할 수 있다" ➔
• Why is it important to business that customers can track orders online? Can it save cost of customer support?
  (고객이 온라인으로 주문을 추적할 수 있다는 것이 왜 중요한가? 고객 지원 비용을 절감할 수 있는가?)
• Does the company have a capability for the online tracking?
  (회사가 온라인 추적 기능을 제공할 수 있는 능력이 있는가?)
• How accurate the tracking have to be?
  (추적의 정확도는 얼마나 되어야 하는가?) ➔
• 이러한 질문들은 견고한 요구사항을 만드는 데 도움이 될 수 있다

Clear and Solid Requirement (명확하고 견고한 요구사항)

1. 사이트 또는 경쟁사의 현재 상태를 이해한다.
2. 이해관계자 및 현재 및 잠재적인 사용자들로부터 필요와 아이디어를 수집한다.
3. 아이디어를 요구사항으로 통합한다.
4. 프로젝트 목표에 따라 요구사항의 우선순위를 정한다.

요구사항 전략

😎Understanding Current State (현재 상태 이해하기)

• How to learn the current state? (현재 상태를 어떻게 파악할까?)
  • 이해관계자 인터뷰 & 사용자 연구
• Heuristic Analysis (휴리스틱 분석)
  • 사용자 경험 분야에서의 모범 사례를 바탕으로 기존 디자인의 사용성을 평가할 수 있는 기법.
• Understand the current state of the site analyzed and propose a list of ideas to the requirement of the new site. (분석된 사이트의 현재 상태를 이해하고, 새로운 사이트 요구사항에 대한 아이디어 목록을 제안)

여기서 Stakeholder 란? 

stakeholder(이해관계자)는 프로젝트나 제품, 서비스에 직간접적으로 영향을 미치거나 영향을 받는 모든 사람을 말합니다. UX 디자인에서는 주로 다음과 같은 사람들을 포함합니다:

1. 고객 및 사용자: 제품이나 서비스를 실제로 사용하는 사람들
2. 프로젝트 팀원: 디자이너, 개발자, 프로젝트 관리자 등 프로젝트에 직접 참여하는 사람들
3. 경영진: 프로젝트나 서비스의 성공이 회사나 조직의 목표에 중요한 사람들
4. 마케팅 팀: 제품의 타겟 시장을 결정하고, 사용자 요구 사항을 수집하는 팀
5. 투자자: 프로젝트에 자금을 제공하거나 사업에 관심을 가진 사람들

Why Heuristics? (왜 휴리스틱인가?)

• 상대적으로 빠르고 저렴한 방법으로 디자인에 대한 피드백을 얻을 수 있다.
• 디자인 품질에 대한 일반적인 이해를 제공하고, 잠재적인 디자인 문제를 식별하는 데 도움을 준다.
• 기존 사이트를 리디자인할 경우, 빠르게 수정할 수 있는 부분을 식별하여 즉각적인 개선을 이끌어 낼 수 있다.

😎사용자 인터페이스 디자인을 위한 10가지 사용성 휴리스틱 - 시험출제 전부

1. Visibility of system status (시스템 상태의 가시성)
   시스템은 적절한 피드백을 통해 합리적인 시간 내에 현재 상황을 사용자에게 항상 알려주어야 한다.
2. Match between system and the real world (시스템과 실제 세계의 일치)
   시스템은 사용자에게 익숙한 단어, 구문, 개념을 사용해야 하며, 시스템 중심의 용어가 아닌 사용자 중심의 언어로 말해야 한다. 실제 세계의 규칙을 따르며, 정보를 자연스럽고 논리적인 순서로 나타내야 한다.
3. User control and freedom (사용자 제어와 자유)
   사용자는 종종 실수로 시스템 기능을 선택하며, 이러한 상태에서 벗어나기 위해 명확하게 표시된 "비상 탈출" 기능이 필요하다. 복잡한 절차 없이 원하는 상태로 빠져나갈 수 있도록 취소 및 되돌리기 기능을 지원해야 한다.
4. Consistency and standards (일관성 및 표준)
   사용자는 서로 다른 단어, 상황, 또는 행동이 동일한 의미인지 헷갈리지 않아야 한다. 플랫폼 규칙을 따르도록 한다.
5.  Error prevention (오류 방지)
   좋은 오류 메시지보다 더 나은 것은 처음부터 문제가 발생하지 않도록 하는 신중한 설계이다. 오류가 발생할 수 있는 조건을 제거하거나, 이를 확인하여 사용자에게 실행 전에 확인 옵션을 제공한다.
6. Recognition rather than recall (회상보다는 인식)
   사용자의 기억 부담을 줄이기 위해 객체, 동작, 옵션을 시각적으로 보이게 한다. 사용자는 대화의 한 부분에서 다른 부분으로 정보를 기억하지 않아도 되도록 해야 한다. 시스템 사용 방법에 대한 지침은 적절할 때 언제든지 보이거나 쉽게 찾을 수 있어야 한다.
7. Flexibility and efficiency of use (유연성과 사용 효율성)
   가속기는 숙련된 사용자가 상호작용 속도를 높일 수 있도록 도와주며, 시스템은 경험이 부족한 사용자와 숙련된 사용자 모두를 만족시킬 수 있어야 한다.
8. Aesthetic and minimalist design (미적이고 최소주의적인 디자인)
   대화 상자는 필요하지 않거나 드물게 필요한 정보를 포함해서는 안 된다.
9. Help users recognize, diagnose, and recover from errors (사용자가 오류를 인식하고, 진단하며, 복구할 수 있도록 돕기)
   오류 메시지는 코드 없이 평이한 언어로 표현되어야 하며, 문제를 명확하게 지적하고, 해결책을 건설적으로 제안해야 한다.
10. Help and documentation (도움말과 문서화)
    시스템은 도움말과 문서를 제공해야 하며, 이러한 정보는 검색하기 쉬워야 하고, 사용자의 작업에 초점을 맞추어 구체적인 실행 단계를 나열해야 하며, 너무 방대하지 않아야 한다.

How to Analyze? (분석하는 방법)

1. 제품 및 프로젝트의 배경 지식을 수집한다.
2. 사용할 휴리스틱을 선택한다.
3. 사이트의 우선순위가 높은 영역을 검토하면서, 휴리스틱이 잘 지켜졌거나 누락된 영역을 식별한다.
4. 프로젝트 팀과 주요 이해관계자에게 발견 사항을 발표한다.

How does it help? (이것이 어떻게 도움이 되는가?)

• 휴리스틱 분석 후, 우리는 현재 상태에 대한 더 깊은 이해와 요구사항 수집에 기여할 수 있는 아이디어 목록을 갖게 된다.

Gather ideas from Stakeholders (이해관계자로부터 아이디어를 수집하기)

1. 역할과 책임을 개요 작성
2. 올바른 이해관계자들을 수집
   • 요구사항 중심의 인터뷰 또는 미팅 진행
3. 미팅 계획 수립
   • 다룰 주제
   • 질문할 사항
4. 미팅을 효율적으로 운영

Coalescing Requirements (요구사항 통합)

• 수집된 아이디어를 유용한 요구사항으로 변환

위 표 원본

😎User Research (사용자 연구)

• 주요 사용자 그룹 정의
• 사용자 참여 계획 수립
• 연구 수행
• 사용자 그룹 정의 확인 => 페르소나(Persona)와 시나리오(Scenario)를 사용

 

User Interview (사용자 인터뷰) : 사이트의 주요 사용자 그룹에 속한 참가자와의 1:1 대화

Contextual Inquiry(현장에 가서 물어보는 것) : 참가자의 일상적인 환경을 관찰하고 그 환경에서 어떻게 작업하는지 배우는 현장 방문

Surveys (설문조사) : 다수의 사람들에게서 패턴을 식별하기 위해 사용되는 객관식 질문으로 구성된 일련의 질문

Focus Groups (특정 그룹 집단 조사) : 특정 주제에 대해 참가자의 감정, 태도 및 생각을 드러내기 위한 질문을 진행하는 그룹 토론

Card Sorting (카드 정렬) : 참가자가 주제와 같은 항목을 카드로 받아 이를 의미 있는 항목으로 정렬하는 것

Usability Testing (사용성 테스트) : 사용자가 사이트나 애플리케이션에서 전형적인 작업을 수행하며 문제가 발생하는지 확인하는 테스트

위 표 원본 이미지

요구사항 생성

사용자 요구사항 + 비즈니스 요구사항

그 후, 우선순위를 정합니다.

 

명세(Specification)

• 요구사항 명세서(requirements specification)는 개발될 시스템의 동작을 완전하게 설명하는 문서로, 소프트웨어 사용자가 소프트웨어와 상호작용할 방법을 설명하는 사용 사례들(use cases)을 포함할 수 있습니다. 또한 비기능적 요구사항(non-functional requirements)을 포함하며, 비기능적 요구사항은 설계 또는 구현에 제약을 가합니다 (예: 성능 엔지니어링 요구사항, 품질 표준, 또는 설계 제약).
• 소프트웨어 요구사항 명세서는 프로젝트 개발에 필요한 모든 요구사항을 나열합니다. 이 요구사항을 도출하기 위해서는 개발될 제품에 대한 명확하고 철저한 이해가 필요합니다. 이는 프로젝트 팀과 고객 간의 상세한 커뮤니케이션 후에 준비됩니다.

명세(Specification)

Introduction (소개)

• 목적, 정의, 시스템 개요, 참고 자료

Overall description (전체 설명)

• 제품 관점: 시스템 인터페이스, 사용자 인터페이스, 하드웨어 인터페이스, 소프트웨어 인터페이스, 통신 인터페이스, 메모리 제약, 운영, 사이트 적응 요구사항
• 제품 기능, 사용자 특성, 제약사항, 가정 및 종속성

Specific requirements (구체적인 요구사항)

• 외부 인터페이스 요구사항
• 기능적 요구사항
• 성능 요구사항
• 설계 제약사항: 표준 준수
• 논리적 데이터베이스 요구사항
• 소프트웨어 시스템 속성: 신뢰성, 가용성, 보안, 유지보수성, 이식성
• 기타 요구사항

=> 이 명세서는 시스템 요구사항의 전체적인 설명과 더불어 구체적인 요구사항들을 나열하고 있습니다. 제품의 관점과 기능, 사용자 특성에 대해 설명하고, 시스템 인터페이스와 성능, 보안 등 세부적인 항목들을 명시합니다.