리소스 및 타임라인 고려 사항 대응

완료됨

소개 시나리오의 개발자는 개발 프로세스 도중 장애 커뮤니티가 참여하도록 하지 않았습니다. 개발자는 어디서부터 시작해야 할지 잘 모르거나 출시 일정, 대역폭에 대해 우려했을 수 있습니다.

이 단원에서는 다음을 비롯해 이러한 문제를 해결하는 기본적인 커뮤니티 참여 개념에 대해 알아봅니다. 이러한 개념은 다음과 같습니다.

  • 기존 피드백 루프로 장애 피드백을 간소화할 수 있는 접근 방식
  • 다양한 사용자 및 관점 참여의 중요성
  • 개발 주기에서 팀이 어디에 있는지에 관계없이 피드백을 수집할 수 있는 잠재적 방법

접근성 피드백을 기존 피드백 프로세스에 포함

팀이 접근성에 대해 처음 접하는 경우 장애인의 관점을 모으는 것이 너무 어렵게 보일 수 있지만 이러한 관점을 수집할 필요는 없습니다. 일반적인 사용자 피드백을 수집하거나 접근성 이외의 사용자 조사를 수행할 때 팀 또는 조직에서 따르는 표준 프로세스를 생각해 보세요.

예를 들어 팀에서는 이미 설문 조사를 전송하거나, 일반적인 연구 조사를 수행하거나, 개발 중인 모든 제품에 대한 재생 테스트를 실행하고 있을 수도 있습니다. 그렇다면 완전히 새로운 프로세스 또는 프로그램을 만들지 않고도 장애 피드백 수집을 시작할 수 있는 한 가지 방법으로, 장애인 플레이어를 이러한 기존 참가자 풀에 포함하기만 하면 됩니다.

참고

가능하다면 이러한 참여를 위해 사용자 연구 팀과 협력하는 것이 좋습니다. 이러한 팀은 의미 있는 질문을 제기하고 데이터를 분석하는 방법에 대해 교육을 받았고 전문 지식이 있습니다. 사용할 수 있는 사용자 연구 리소스가 없는 경우에도 피드백 루프에 접근성 관점을 포함하려는 노력을 계속할 수 있습니다.

다양한 사용자 및 관점 포함

시작하기 전에 다음과 같은 질문을 던져볼 수 있습니다.

  • "피드백 세션에 포함해야 하는 장애인 플레이어의 수는 몇 명인가요?"
  • "한 플레이어의 피드백이 비슷한 장애를 가진 다른 플레이어의 피드백을 대표한다는 사실을 어떻게 알 수 있나요?"

명확한 답변이나 지침은 없지만 장애인 플레이어 한 명의 경험은 다른 장애인 플레이어와 크게 다를 수 있습니다.

그러니 다양한 사용자와 관점을 포함하는 것이 좋습니다. 예를 들어 게임 UI의 시각적 접근성에 대한 피드백을 찾고 있다면 다양한 유형의 여러 시각 장애인 플레이어가 주는 피드백을 고려해야 합니다.

개발 타임 라인 전반에 걸친 피드백 수집

접근성 피드백은 개발 프로세스의 모든 지점에서 수집될 수 있고 수집되어야 함을 기억하는 것도 중요합니다. 협업은 계획 및 목표 설정 단계부터 시작합니다. 처음부터 접근성을 고려하면 접근성 기능이 막바지에 추가되는 상황이 발생하는 것을 피할 수 있습니다.

마지막에 접근성 솔루션을 구현하려고 하면 게임 디자인 내에서 효과적으로 통합되지 않습니다. 처음부터 끝까지 접근성의 우선 순위를 일관되게 지정하는 경우에 달성되는 것과 동일한 수준의 지원 및 효율성을 플레이어에게 제공할 가능성도 거의 없습니다.

다음 정보는 개발의 다양한 지점에서 피드백을 수집할 수 있는 방법을 간략하게 설명합니다.

  • 개발 전: 팀에서 공식적인 계획이나 개발을 시작하지 않았더라도 여전히 장애 커뮤니티가 참여하도록 할 기회가 있습니다. 이 시간을 플레이어가 팀에서 개발하려고 하는 게임과 유사한 장르의 다른 게임을 하면서 과거에 경험했던 장벽에 대한 기본적인 인사이트를 수집하는 데 사용하는 것이 좋습니다. 개발에 앞서 이러한 장벽을 인식하면 게임에 이러한 장벽이 생기는 것을 방지할 수 있습니다.

  • 초기 계획 및 목표 설정: 초기 계획과 목표를 설정한 후 이 정보를 사용하여 피드백을 얻습니다. 플레이어는 예상되는 설정, 역학, 기타 디자인 요소로 인해 발생할 수 있는 잠재적 장벽을 파악하여 접근 가능한 개발로 개선할 수 있습니다. 또한 제안된 접근성 목표 및 이를 달성하기 위한 계획에 귀중한 피드백을 제공할 수도 있습니다.

  • 프로토타입 테스트: 작동 중인 프로토타입 또는 게임 빌드를 사용할 수 있게 되면 플레이어가 재생 테스트 또는 사용자 조사 연구를 통해 피드백을 제공할 수 있도록 실습 기회를 제공하는 것이 좋습니다. 이러한 직접 상호 작용은 특정 게임의 컨텍스트 내에서 개선에 대한 제안을 알려주는 데 중요합니다.

    경험이나 디바이스가 반복을 거치는 과정에도 장애인 플레이어가 계속 테스트에 참여합니다. 이렇게 하면 향후 디자인 반복 시에도 플레이어에게 효과적이고 사용 가능한 솔루션을 계속 제공할 수 있습니다.

    중요

    플레이 가능한 프로토타입에 커뮤니티가 참여하기 시작할 수 있을 때까지 기다리는 것이 매력적으로 보일 수 있습니다. 그러나 초기 개발 단계에 플레이어가 파악한 모든 잠재적 장벽을 고려하는 것이 중요합니다. 이러한 피드백이 없으면 팀에서 미처 파악하지 못한 접근성이 떨어지는 환경을 프로토타입에 포함할 수 있습니다.

    개발의 이 시점에 식별된 수많은 문제를 처리하기에는 너무 늦을 수 있으며, 그 결과 접근성이 떨어지는 환경을 출시하게 됩니다. 개발 과정 전반에 걸쳐 협업하면 접근성에 대한 큰 장벽이 프로토타입에 나타날 가능성을 줄일 수 있습니다.

지식 점검

1.

장애 피드백을 수집하려면 상당한 리소스와 자금이 필요하다는 오해가 일반적입니다. 리소스가 제한된 팀에서 추가 프로그램 또는 작업 흐름을 만들지 않으면서도 장애 커뮤니티의 관점을 포함하려면 어떻게 하나요?

2.

팀은 새로운 플랫폼 게임의 초기 계획과 개발을 시작하도록 꾸려졌습니다. 공식적인 디자인 계획이나 접근성 목표가 없음에도 불구하고 최대한 빨리 장애인 커뮤니티와 컨설팅하기를 희망합니다. 어떻게 팀이 제품 개발 초기에 장애 커뮤니티와 협력할 수 있나요?