User Story와 Usability

우아한 테크코스 레벨3와 레벨4의 커리큘럼을 바꾸면서, 크루들에게 프로젝트 준비를 위한 시간이 주어졌다. 기획서를 작성하고 프로젝트를 준비하는데에 앞서 어떤 메시지를 주면 좋을지 고민이 시작되었다. 그러다 문득 User Story를 작성해보는 것도 좋겠다는 생각이 들어 강의와 실습 컨텐츠를 만들어보았다. 이 자료는 인간중심 UX 디자인과 사용자를 생각하게 하지마를 참고하여 만들었다.

 

User Story는 사용자 상을 제작하고, 사용자의 시나리오를 작성한 후 요구사항으로 도출된다. 아래에서는 http://edu.nextstep.camp/ 을 가상으로 작성해보았다. 요구사항을 도출하기까지 사용되는 In-Depth Interview와 사용성을 위해 진행하는 Usability Test를 비교해 보는 것도 좋을거라 생각한다.

 

👨‍👩‍👧‍👦 1. 사용자

실용주의가 없는 장인정신은 장인정신이 아니다. 장인이 가장 중요하게 초점을 맞추는 것은 고객의 만족이다. 품질은 물론이고 시간과 비용도 고객 만족을 위한 구성요소다. 고객에게 가치를 전달할 수 없다면 잘 작성된 코드라고 할 수 없다. by 소프트웨어 장인

• 기사에서 시사하듯, 소프트웨어(혹은 서비스)는 사용자를 중심에 두어야 한다.

 

1) 잠재 사용자 파악하기

 

(1) 사용자 리서치

• 사용자가 이미 경험한 것들(어떤 인식/태도를 가지고 있는지)를 파악하면 사용자 스토리가 도출된다.

• 유사한 서비스를 사용하는 사용자를 대상으로 리서치를 한다.

a. 그럴듯한 사용자 역할 찾기

제품	예상 역할
교육 서비스	강사, 학생, 강의 컨텐츠를 관리하는 사람, 시스템 관리자 등
구매 서비스	판매자, 구매자, 주문 요청을 처리하는 사람, 배송받는 사람, 시스템 관리자 등
이메일 서비스	이메일 계정 소유자, 외부 이메일 수취인, 시스템 관리자 등

 

b. 인터뷰 주제

* 작업을 이해하는 것도 중요하지만, 왜 그 작업이 존재하는지 이해해야 한다.

 

- 작업 빈도와 우선순위

• 일반적으로 어떤 일을 가장 먼저 합니까? 그 이유는?

• 어떤 일을 가능한 미룹니까?

• 어떤 일들이 시간을 낭비하게 만듭니까?

• 단지 한두가지 일을 할 수 있는 시간이 더 생긴다면, 무엇을 하겠습니까?

• 왜 그 업무에 더 많은 시간을 투자합니까?

 

- 현재 제품의 역할

• 제품을 얼마나 자주 이용합니까?

• 현재의 제품을 어디에 가장 많이 이용합니까?

• 어떻게 이용하는지 보여주실 수 있을까요?

• 이 도구를 사용하기 전에 어떤 다른 도구들을 이용합니까?

• 어떤 도구와 함께 제품을 사용합니까?

• 이 제품을 사용한 후에 어떤 도구를 사용합니까?

• 동일 작업에서 사용한 다른 도구와 이 제 품을 어떻게 비교할 수 있을까요?

 

c. 인터뷰하기

• 참가자들에게 보여달라고 요청하라

• 유도 질문을 하지 마라

• 인터뷰 참가자에게 해결책에 대해 묻지 마라

• 인터뷰 도중 문제를 해결하려고 하지 마라

• 무엇이 좋은 경험을 만들까요? (목적에 대해 직접적으로 질문하면, 유용한 답변을 얻지 못한다.)

 

* 멘탈 모델 객체와 속성

• 멘탈모델은 사용자의 기존 경험, 인식 등으로 형성되며, 시스템의 개념구조와 동작이 사용자의 멘탈모델과 일치하면, 대개 시스템은 사용하기 쉽다.
  
  

  멘탈모델	객체속성
  이메일 메시지	- 누가 보냈는지 - 누가 메시지를 받는지 - 언제 보냈는지 - 무엇에 관한 것인지 - 어떤 첨부물이 있는지 - 상대방이 어떤 행동을 하였는지(전달, 답장 등) - 얼마나 급한 행동인지
  연락처	- 어떻게 그들에게 연락할 수 있는지 - 어디서 일하는지

 

d. 다른 자료들 활용하기

기존 설문조사를 활용하거나 기존 서비스를 벤치마킹하는 것도 좋다. 추가적으로, 웹 로그 등의 데이터는 어디에 문제가 있을 수 있는지 파악하는데 유용하지만 왜 그 문제가 발생하는지 설명하지 못한다.

 

 

(2) 데이터 이해하기

모델링의 요점은 데이터를 이해할 수 있게 다듬어서 리서치 내용을 충분히 이해한 상태에서 의사결정을 내릴 수 있게 돕는 것이다.

개별 데이터	아이디어
- 씨유는 일주일에 최소 한 번 수강생들에게 독려 메일을 보낸다. - 포비는 수업 대기신청한 사람들에게 이메일을 보낸다.	이메일 보내기
- 준은 수강생들이 프론트엔드 미션을 잘 소화하도록 며칠에 한번씩 강의 컨텐츠를 올린다	웹 사이트에 교육 컨텐츠 올리기
- 제이슨은 DDD 교육 컨텐츠를 판매한다.	웹 사이트에 상품 컨텐츠 올리기
- 소니는 2일에 한번은 리뷰 요청을 한다	웹 사이트를 통해 코드리뷰 요청하기

 

 

2) Persona 작성하기

Persona란, 잠재 사용자들의 다양한 목적과 관찰된 행동 패턴을 응집시켜 놓은 원형이다.
따라서, Persona를 통해 제품을 정의, 디자인할 수 있다. Persona를 통해 형성된 공통된 '사용자'를 생각하면서 작업을 진행한다.

 

(1) 패턴 분석하기

• 행동 변수란 인터뷰 참가자들간 차이가 있는 행동 및 사고방식들을 의미한다.

• 모집단이라고 믿는 대상과 비교하지 말고 각 인터뷰 참가자들끼리 비교하면서 배치한다.

• 자주 함께 보이는 사람들을 동그라미 쳐둔다.

강의 경험이 많은 강사	강의 경험이 적은 강사	수강생	리뷰어
- 기존 교육 컨텐츠를 판매 - 빈번하지 않은 독려 메일 - 수강생과 자주 이야기 하지 않음 ...	- 교육 컨텐츠 작성에 많은 시간 할애 - 수강생과의 관계에 집중 - 리뷰어와 어느 정도 자주 이야기함 ...	- 프로그래밍 학습에 많은 시간 할애 ...	...

 

(2) 목적 정의하기

• 각 목적은 동사로 작성한다.

  강사	수강생	리뷰어
  - 자기 브랜딩을 하고 싶다 - 강의를 판매하고 싶다 - 리뷰어 품질관리를 하고 싶다	- 프로그래밍 실력을 높이고 싶다 - CS를 학습하고 싶다 - 나의 학습 상태를 확인하고 싶다	- 수강생들과 소통하고 싶다 - 코드리뷰 품질을 높이고 싶다

• 특이점을 명확히 한다.

• Persona간 우선순위를 정한다.

(3) 개별 Persona 설명하기

러너

- 28세 - 3년차 백엔드 개발자 - SI업체 - 비전공 - Mac 사용 현재 수강중인 수업: ATDD - 수강한 이유 : 인수테스트 역량을 키우기 위해 - 이전에 들었던 수업 : Clean Code - 이전 수업의 미션 완료율 : 100% - 리뷰 요청 주기 : 평균 2일에 한번 - 평균 수업료: 77만원 - 수강대기 신청 이유 : 다음 강의를 바로 신청하고 싶었음 - 신청 전 방문 횟수 : 3회 Needs - 프로그래밍 역량을 키우고 싶다. - 수강 후 이직 멘토링을 받고 싶다. Customer Job - 프로그래밍 역량을 키워서 원하는 곳으로 이직을 할 수 있다

 

 

📝 2. 유저 스토리 도출하기

1) 시나리오 제작하기

• 시나리오는 Persona 관점에서 기술한다. Persona에 의한 행동의 결과로서 Persona와 시스템 사이의 인터렉션을 묘사한다.

  제품	페르소나	시나리오
  이메일 시스템	강사	- 개강 알림 메일 보내기 - 독려 메일 보내기
  이메일 시스템	수강생	- 질문 메일 보내기 - 수료증 요청하기 - 멘토링 신청하기
  구매 플랫폼	구매자	- 구매요청

• 정황 시나리오는 버스를 타기 위해 현금을 인출해야 하는 '맥락', 카메라 메모리가 가득 찼기 때문에 업로드해야 하는 '니즈', 구매 요청 접수증 등 '특정 계기'로 시작한다. 정황 시나리오에서 해결안을 미리 제공하지 않아야 한다.

러너는 다음 주에 모집 예정인 ATDD와 DDD 수업들의 알림 메시지를 받았다. 반복적인 유지보수 업무에 지친 그는 이직 준비를 위해 Nextstep에 접속했다. 홈페이지에서 각 과정에 대한 정보들을 확인한 후 수료생들의 미션에 대한 코드리뷰를 확인했다. 그는 브라운 강사에게 이번 ATDD 과정을 수강하려면 어느정도 역량이 필요한지 메시지를 보냈다. 얼마후 워니 강사에게 이전에 요청했던 이력서 피드백을 받았다.

 

 

2) 시나리오에서 요구사항 도출하기

시나리오	요구사항
러너는 다음 주에 모집 예정인 ATDD와 DDD 수업들의 알림 메시지를 받았다. 반복적인 유지보수 업무에 지친 그는 이직 준비를 위해 Nextstep에 접속했다.	- 개강 알림 메시지를 보낼 수 있어야 한다. - 메일에서 과정페이지로 접속할 수 있어야 한다.
홈페이지에서 각 과정에 대한 정보들을 확인한 후 수료생들의 미션에 대한 코드리뷰를 확인했다.	- 과정 목표, 커리큘럼, 수강생 리뷰 등을 한 화면에 보여줄 수 있어야 한다. - 코드 리뷰를 볼 수 있어야 한다.
그는 브라운 강사에게 이번 ATDD 과정을 수강하려면 어느정도 역량이 필요한지 메시지를 보냈다.	- 강사에게 메시지를 보낼 수 있어야 한다 - 강사는 메시지에 대한 알림을 받을 수 있어야 한다.
얼마후 워니 강사에게 이전에 요청했던 이력서 피드백을 받았다.	- 강사는 이력서 피드백을 등록할 수 있어야 한다. - 수강생은 피드백이 완료되면 알림을 받을 수 있어야 한다.

 

🤔 3. 사용자를 고민에 빠뜨리지 마라

누구나(평범한 능력과 경험을 가진 사람)이 어려움없이 사용법을 알 수 있어야 하며, 투입한 수고에 비해 얻은 가치가 커야 한다.

 

1) 아래 질문에 답해보자

• 유용성 : 사람들이 필요로 하는 일을 하는가?

• 학습 용이성 : 사람들이 사용법을 알아볼 수 있는가?

• 기억 용이성 : 사용할 때마다 사용법을 다시 익혀야 하는가?

• 유효성 : 맡은 임무를 완수하는가?

• 효율성 : 작업을 수행하는데 드는 시간과 노력의 양은 합리적인 수준인가?

• 호감도 : 사람들이 이것을 갖고 싶어하겠는가?

• 재미 : 사용할 때 즐겁거나 재미있다고 느끼는가?

 

2) 우리가 실제로 웹을 사용하는 방법

• 사용자는 웹 페이지를 읽지 않는다. 훑어본다. 한번에 여러 개를 만들어서 잘 보여주고 싶다는 욕망을 버려라.

• 사용자는 최선의 선택을 하지 않는다. 최소 조건만 충족되면 만족한다.

  • 사용자는 보통 시간에 쫓긴다.

  • 추측이 틀렸을 때 발생하는 불이익이 별로 없다.

  • 선택지를 비교하더라도 결과가 나아지리라는 보장이 없다.

• 사용자는 작동방식까지 이해하려 하지 않는다. 적당히 임기응변한다.

 

3) 심각한 문제

여러번 생각을 하게 되면 피로도가 쌓여서 이탈하게 된다.

 

a. Usability Test

사용성 테스트란, 고객이 우리가 제공하고자 하는 서비스의 구조와 기능을 의도한 대로 인지, 이해, 예측, 실행 할 수 있는가를 확인하기 위한 리서치 방법론 중 하나이다. 참여자에게 특정 과제를 부여한 뒤 관찰을 통해 사용성의 문제점을 발견하는 방법이다.

즉, 사용성 테스트는 사람에 대해 알아보는 것이 아니라, 인터페이스에 대해 문제없이 사용할 수 있는지를 확인하는 것으로 의견이나 과거 사용 경험 등을 묻지 않는다.

 

* 얼마나 진행해야 할까

 

* UT를 통해 알 수 있는 것

• 이 기능을 발견할 수 있는지

• 이 기능은 사용할 수 있는지

• 이 Task를 쉽게 완료할 수 있는지

• 정보를 쉽게 이해할 수 있는지

• 사용자가 필요한 모든 정보를 얻을 수 있는지

* UT를 통해 알 수 없는 것

• 사용자에게 앱이 유용한지

• 어떤 다른 기능을 추가하면 좋은지

유용성 조사에서 선호도를 요구하는 것은 함정이 될 수 있다. (한 사람에게 A/B테스트하지 마라)

 

 

 

4) 호감에 영향을 주는 요인들

 

a. 부정적인 요인

• 사용자가 원하는 정보 숨겨두기

• 사용자를 귀찮게 하기. 전화번호 사이에 (-), 카드번호 공백 등을 사용자에게 넣으라고 강요하지마라

• 필요하지도 않은 정보 물어보기

• 가식적인 표현으로 사용자 기만하기

• 홍보용 장치로 작업 방해하기

• 아마추어 수준의 사이트 제작

b. 긍정적인 요인

• 사용자가 가장 많이 하는 활동을 찾아 명확하게 드러내줘라

• 사용자가 알고자 하는 정보를 공개하라

• 궁금해할 만한 내용을 예측하고 미리 답을 제시해라

• 오류가 발생했을 때 쉽게 회복할 수 있게 하라

• 해결하지 못한 문제가 있을 때는 사과하라