잘못된 유저 스토리: 유저로서 나는 원하지 않는다
As a user, I don't want to
해당 글은 Pavel Samsonov에 의해 2023년 3월 7일에 작성된 기사를 번역한 글입니다.
이 글을 읽기 전 유의 사항:
UX UI에 관심이 있거나 관련 분야에 종사하고 있는 디자이너분들이 이 기사를 주로 읽을 것으로 생각합니다. 원문에 쓰인 단어 중 디자이너로서 익숙하지 않은 단어는 문단 하단에 정의를 별도로 작성했습니다.
본문에서 사용하는 비용이라는 단어는 cost를 직역한 것으로, 유저가 목표를 달성하기 위해 쓰는 에너지, 수고, 시간 등을 뜻합니다. 한국어로 번역할 적절한 단어를 찾지 못하여 비용이라고 직역한 점 참고하여 읽어주시길 바랍니다.
1997년의 등장 이후 유저 스토리 (user stories)는 어디에서나 흔히 쓰이는 도구가 되었다. “X (유저)로서 나는 Y를 하기 위해 Z를 하기 원한다.”라는 간단한 구성 방식은 수많은 소프트웨어 팀이 고객에게 제공하고자 하는 가치에 집중할 수 있도록 도와주었다.
물론 이론상으로는.
스크럼 매뉴얼 (Scrum manuals)과 애자일 코치 (Agile coaches)는 프로덕트 오너에게 유저 스토리 포맷을 수십 년간 주입한 결과 “유저 스토리”와 “티켓”이 거의 동의어로 자리 잡게 되었다. 스크럼 프로세스에 자신의 업무를 맞추기 위한 노력의 결과로 팀은 유저 스토리가 원래 무엇을 얻게 도와주는 도구인지 목적을 잃어버렸다. 유저 스토리는 이렇게 시작했다.
*티켓 (ticket): 개발자가 어떠한 기능을 만들어야 할 때 보내는 의뢰서와 같은 것으로 원하는 결과물을 개발자가 실제로 구축할 수 있게 도와준다. Task는 유저가 상호작용할 수 있도록 실제 개발해야 하는 단위를 나타내고, 각 task가 담당 개발자에게 티켓으로 할당된다.
[유저]로서 나는 [이익을 얻기] 위해 나는 [목표를 달성하기] 원한다.
에서부터 시작해서
[유저]로서 나는 [도구를 사용하기] 위해 나는 [작업을 수행하기] 원한다.
나는 페이지를 보기 위해 버튼을 클릭하기를 원한다. 나는 고급 제안을 받기 위해 내 이메일 주소를 입력하기를 원한다. 나는 서식 5678-B의 다섯 번째 줄을 채우기 위해 서식 1234-A를 작성하기를 원한다. 가끔은 “~하기 위해 (so that)”라는 단어조차 완전히 누락되기도 한다. 유저로서 나는 로그인하길 원한다.
https://twitter.com/jmspool/status/1163895642298736640?s=20그러나 진실은 나는 프로덕트를 전혀 사용하고 싶지 않다.
이상적인 사용자 경험은 아무 일을 하지 않고도 목표를 달성하는 것이다. 원래 유저 스토리의 포맷은 목표에 전적으로 집중함으로써 이러한 점을 강조했다. 과업 지향적인(task-oriented) 유저 스토리는 목표를 일거리로 대체했다. 이는 유저 스토리의 장점은 취하지도 못하면서 생기는 부작용이다.
다행히도, 이건 해결하기 쉽다. 우리는 그저 유저 스토리를 뒤집으면 된다.
과업(tasks)이 뭐가 그렇게 나쁜 거지?
원래 유저 스토리 포맷에서 가장 중요한 것은 유저가 비용을 기꺼이 지불할만한 혜택을 보여주는 것이다. 어떻게 유저에게 혜택을 제공할지, 그 혜택의 비용이 무엇일지 뿐만 아니라 유저가 직면하게 될 높아진 프로덕트의 복잡성을 처리하는 비용을 모두 포함하여 이를 해결하는 방법은 팀의 자유이다.
하지만 과업, 도구, 기능은 유저에게 혜택이 아니다. 과업을 수행하거나 도구를 다루는 것은 유저가 목표를 달성하기 위해 지불해야 하는 비용 중 하나이다. 프로덕트에 기능을 추가하는 것은 비용을 증가시키기 때문에 경험을 저하한다.
물리적인 프로덕트의 복잡성 비용이 가치를 초과할 때 유저는 해결할 방법이 있다. 소프트웨어의 경우, 그냥 떠난다.팀에게 도움을 주기보다 오히려 이러한 상호 절충 (trade-offs), 과업 지향적 (task-oriented) 유저 스토리는 사용자에게 가치가 부족한 문제를 난독화하여 팀을 더 힘들게 만든다. “유저로서, 나는 서식을 작성하고 싶다”라고 주장하는 것은 유저가 아무 대가 없이 프로덕트에서 어떤 것을 내어줄 것이라고 팀은 착각하게 된다. 이런 유저는 실제로 존재하지도 않지만, 유저는 서식을 작성하고 싶은 사람으로 정의되기 때문에 비용을 찾아낼 수 없다.
저런 유저 스토리로는 모든 티켓이 자기 합리화된다. 기능은 늘어나고, 복잡성도 증가한다. 프로덕트는 사용자에게 가치가 급락하지만, 팀은 유저가 원하는 것을 구축하고 있다고 지속해서 스스로 말하기 때문에 가치가 급락한 것을 알아차릴 수 없다.
그러나 과업 지향적 유저 스토리는 당신이 무엇을 찾아야 하는지 알고 있는 한 완전히 쓸모없는 것은 아니다.
유저 스토리를 뒤집어라
과업 지향적 유저 스토리는 부정확한 명칭 뒤에 숨겨진 유용한 정보 두 가지가 포함되어 있다. 혜택이라고 불리던 것은 실제로는 비용이고, 목표라고 불리던 것은 해결책의 가설 (solution hypothesis)이다. 우리는 새로운 유형의 유저 스토리를 만들기 위해 이 정보를 사용할 수 있다.
과업 지향적 유저 스토리 예를 들어보자:
[유저]로서 나는 [브라우징 경험을 최적화하기] 위해
내 [툴바를 개인 맞춤화하기를] 원한다
우리가 비용을 고려하고 있다는 점을 명심하면서, 우리가 그 비용을 제거할 방법이 있는가? 라고 스스로 물어볼 수 있다.
[유저]로서 내 [툴바를 개인 맞춤화하지 않고도]
[브라우징 경험을 최적화하기를] 원한다
유저가 자신의 툴바를 편집해야 하는 부담을 당연하게 여기기보다는, 이제 팀은 비용이 적게 들면서 더 나은 경험은 어떤 것인지 생각해볼 수 있다. 툴바의 개인 맞춤화를 더 쉽게 만들기 대신에 실질적인 혜택으로 바로 넘어가야 한다.
그 외에도 이런 방식은 기능에 대한 아이디어가 실제로는 가설이라는 것을 강조한다. 유저가 실제로 자신의 브라우징 경험을 최적화하길 원하는가? 어떤 방식으로? 과업 지향적 유저 스토리를 작성하는 팀은 추측에 머물러 있다. 유저 스토리를 뒤집을 준비가 된 팀이 실제 정답을 이제 찾을 준비가 되었다.
반대로 더디게 작업해라
과업 지향적 유저 스토리는 보통 획기적인 역량을 서술하지 않기 때문에 유저 스토리를 작성하는 것은 쉽다. 오히려 너무나 잘 알려져 이젠 당연한 기존의 패턴을 담아낸다. 물론, 유저는 툴바를 개인 맞춤화하길 원한다! 그렇지 않고서야 유저가 어떻게 그들의 브라우징 경험을 최적화할 수 있을까?
만일 뻔한 기능을 이용자 편익으로 고려한다면, 그건 이미 다른 곳에 존재하는 기능일 가능성이 크다. 그러나 모든 기능과 마찬가지로 이는 비용을 대변한다. 그리고 기존의 비용은 유저의 고충 점(pain points)을 찾기 좋은 곳이다.
경쟁업체를 따라 하기 보단, 유저 스토리를 뒤집는 팀이 경쟁업체를 앞서갈 기회를 발견할 수 있다. Amazon은 보도자료에서 “오늘날 고객은 … 해야 한다.”와 같이 약간의 표현의 차이가 있지만, 페인 포인트를 강조하기 위해 비슷한 접근 방식을 취한다.
“오늘날 고객은 그들의 브라우징 경험을 개선하기를 원하면 툴바를 개인 맞춤화해야 한다.” 이는 당신이 목적을 가지고 구축해야 하는 기능이라기보다 훨씬 어려운 사안처럼 들린다. 백로그에 새로운 티켓을 추가하기 위해 서두르는 걸 중단하는 것이 이젠 당신의 프로덕트가 시장에서 참신하고 차별화되는 기회로 바꾼다.
원본 글 링크:
https://uxdesign.cc/as-a-user-i-dont-want-to-973990a30158
