요약
지역 기반 도움 교환 플랫폼에서, 사용자가 지원을 요청하는 대표적인 방법 3가지에 대해
시나리오 기반 유저스터디를 진행하고 각 방법의 장단점에 관한 피드백을 정리한 연구
목차별 내용
1. Introduction
Support requests in local support exchange에 대한 기본적인 설명 (ex. 설탕 한 컵 요청 - 이렇게 물리적이고 간단한 요청을 예시로 설명함)
도움 요청과 현재 요청 방식에 대한 문제점 : 도움 요청에 대해서 사용자가 꺼리게 되는 이유, social cost 등
대표적인 도움 요청 방법, 유저스터디 결과 각기 다른 이유로 선호하는 방식들이 달랐음 -> 이를 분석하여 design implication을 정리함
2. Literature review
- 도움 요청 플랫폼 관련 내용 : 지역 기반 도움 요청 플랫폼들도 있었지만 이런 bespoke 플랫폼 말고도 페이스북이나 구글 독스 같은 플랫폼들을 이용하는 것이 더 흔했음.
- 도움 요청 방식 3가지 :
(1) private requests (low visibility) : 중재자(moderator)를 통해서 개인적으로 도움 요청 내용을 정해진 양식에 작성하여 전달하고, 중재자가 도움 요청 내용을 게시하고, 지원자들을 받아서 매칭시켜주는 방식 (아래 사진처럼 도움 요청자의 신원과 관련한 정보가 public에 노출되는 정도가 가장 낮다)
(2) public indirect requests (mid visibility) : 중재자에게 도움 요청 내용을 전송해서 중재자가 포스트를 게시하고, 도움을 제공하고자 하는 사람들이 댓글을 다는 형식
(3) public direct requests (high visibility) : 중재자 없이 도움을 요청하는 사람이 직접 포스팅, 제공자가 댓글을 달아서 직접 연락
- visibility와 도움요청 자발성, 소셜 cost의 관계 : visibility가 높을 수록 도움 요청을 꺼려한다는 내용
- 개인적인 고통, 약점 노출에 대한 문제 in HCI
3. Method
Preferences and perceptions regarding the three methods of making a support request in local support exchange. <- 이 문구가 이 논문의 가장 핵심적인 주제인 것 같다.
3.1 Scenarios and Interventions
- 실험시 사용했던 시나리오 (도움 요청 시나리오 3가지) : 여기서 인상적이었던 건 시나리오 기반의 실험은 되게 흔한 방식이라고 생각했는데, 이에 대해서도 reference를 첨부해 두었다는 것, 시나리오 실험 기법의 효과에 대해 작성된 연구가 있다는 것도 처음 알았음
- Intervention은 여기서 언급되는 도움 요청 방법이다.
3.2 Survey
참가자들 자격요건, 시나리오, 테스크
3.3 Participants
참가자 모집 경로, 필터링 기준, demo 정보 (가계소득수준은 왜 있는거임)
3.4 Qualitative Analysis
Dovetail 툴 써서 inductive thematic analysis했다는 내용? - HCI 수업때 배운 thematic analysis 봐서 괜히 반가움
4. Findings
method 2번이었던 moderate visibility - public indirect requests 가 106표로 1등이었고, 그 다음이 low visibility (private) 88표, high visibility (85표) 그리고 각 선택 이유에 대해서 참가자들이 코멘트 남긴 것을 서브섹션에 정리해두었다.
4.1 Effectiveness in Getting Support : 얼마나 효과적으로 도움을 받을 수 있는지 측면
- 도움 요청 빨리 받는 것은 High Visibility가 좋음 (16표)
- moderate도 공개적으로 노출됨 (14표)
- private가 (도움을 받는 것이) 확실한 것 같음
4.2 Convenience : 도움 요청 방식의 편의성 (정확한 정보를 전달할 수 있는지 측면)
- low visibility방식이 필요한 정보를 확실하게 전달할 수 있음 (정해진 요청 양식이 있어서) (20표)
- moderate도 중재자와 상호작용하면서 정확한 정보를 제공할 수 있음 (17표)
- high 방식이 간단하고, 예측가능함 (내가 올린 것이 그들에게 전달되는 것과 같으니까) (14표)
4.3 Privacy vs. Community Belonging : 프라이버시 보호 측면, 커뮤니티 소속감 측면
- privacy 측면과 social image 등을 고려하면 low가 좋음 (특히 금전적 요구일 때)
- 그치만 같은 문제를 겪고 있는 사람들과의 유대감을 향상하는 것을 생각하면 high가 더 좋음, 직접 interaction 할 수 있음
5. Discussion
논문 전체 내용 요약과 함께 각 finding들을 보완할 수 있는 design implication 제안
5.1 Navigating the Trade-offs of Private and Public Requests
DI : 사용자가 댓글을 달 때 공개할지 비공개할지 선택할 수 있게하자
DI : 도움 요청글을 올릴 때 타켓 청자를 고를 수 있게 하자
5.2 Enhancing Perceived Control and Predictability of Support Requests
DI : 도움 요청글을 올릴 때 챗봇을 사용해서 정확하고 필요한 정보를 제공할 수 있게 하자
DI : 중재자가 올린 글을 수정할 수 있게하고, 그들의 요청을 누가 볼 수 있는지 제어할 수 있게 하자
DI : Progress bar를 볼 수 있게 하자
DI : 같은 요청을 제출한 사용자의 수를 보여주자, 그리고 요청이 완료되는데 걸린 평균시간을 보여주자
5.3 Facilitating Learning to Offer Support
DI : 도움 요청자들에게 선행 성공적인 도움 교환 사례를 보여주자 (동의하에)
6. CONCLUSION AND FUTURE WORK
의문인점..왜 갑자기 마지막에 Anonymity가 얼마나 social cost를 줄일 수 있는지에 대한 이야기를 언급했는지는 약간 어색하다고 생각함. 아무리 향후연구여도
리뷰
- Literature review 부분에 소제목이 없고 각 단락이 거의 독립적인 내용이어서 매끄럽게 읽히지 않았음 (소제목이나 단락 구분을 짧은 제목으로라도 했으면 좋았을 듯)
- Method 3.1 섹션에서 오타 발견 (Figure reference 깨진 듯)
- survey할 때 Qualtrics 썼다고 하는데, 설문조사용 플랫폼으로 쓰기 좋을 것 같다. 굿 정보
- 약간 의아했던건 굳이 reCAPTCHA 써서 봇들 걸렀다는거 언급한 점..? 근데 이게 온라인으로 서베이를 해서 필요한 내용인 것 같기도..?
- Findings에서 분석한 내용을 design implication으로 정리해둔 것 같긴 했지만 엄청 명확하게 드러나진 않았고, 욕심 내자면 해당 design implication이 반영된 가상의 시스템 UI가 들어갔으면 더 좋았을 것 같음
- 확실히 CHI 논문들은 Pre-study나 survey의 결과랑 method나 결과들과의 연관성이 뚜렷한 것 같다. (이 부분 생각해서 보완 필요)
