잘못된 유저 스토리 사용의 역습: ‘기능’은 비용이다.
이 글은 UX Collective 내 Pavel Samsonov의 As a user, I don’t want to를 번역, 의역, 재구성, 내용 추가한 글입니다.
[실전에 잘못 적용되고 있는 오늘날의 스토리]
수십년간 스크럼 매뉴얼, 애자일 코치들은 유저 스토리라는 개념을 프로덕트 오너(PO, Product Owner)에게 주입식으로 교육하기 시작했고, 결국 ‘유저 스토리’를 ‘제품 개발 티켓’을 쓰기 위한 무언가로 변질시켜 버렸다.
애자일 가치관을 기반으로 일하는 방식을 변화시키기보다, 자신들의 업무를 애자일인척 포장시키기 위해 유저 스토리를 자신의 산출물에 맞게 끼워맞추기 시작했다. 그렇게 사용자가 스토리가 원래 달성하고자 했던 목적은 사라지고 말았다. ‘Z 달성을 위해’ 영역에는 사용자가 ‘삶에서 달성하고자 하는 목적’이 아닌, ‘제품 안에서 해야하는 작업(task)’이 자리 잡았다.
[유저 스토리(user story)의 본질]
1997년 등장한 ‘유저 스토리’는 소프트웨어 제품 조직에서 자주 쓰이는 개념이 되었다.
“X(라는 사용자)로서, Z(라는 목적)달성을 위해 Y(라는 제품/기능)을 원한다.”
이 문장은 수많은 팀들이 고객을 이해하고, 고객에게 가치를 제공할 제품이나 기능을 만드는 데에 큰 도움을 주기 시작했다.
유저 스토리는 사용자의 사용 맥락을 이해하고, 사용자가 삶에서 달성하려는 것과 그와 연관된 제품의 가치를 연관짓기 위해 나온 개념이다. 그래서 ‘Z(라는 목적)달성을 위해’에 들어갈 내용은 사용자가 궁극적으로 해결할 수 있는 문제, 필요 등이 서술되어야 한다.
하지만 오남용된 유저 스토리는 다음과 같은 작업 지향적(task-oriented)인 성격만 남게 된다.
“사용자로서, 나는 페이지를 보기 위해, 버튼을 클릭하고 싶다.”
“사용자로서, 나는 독점 혜택을 받기 위해, 이메일을 입력하고 싶다.”
“사용자로서, 나는 5678-B 양식의 5번째 줄을 채우기 위해, 1234-A 양식을 작성하고 싶다. ’
“사용자로서, 나는 로그인 하고 싶다.”
그렇게 “[사용자]로서 나는 [이익을 얻기 위해] [목표에 도달하기를] 원한다”는 “[사용자]로서 나는 [도구를 사용하기 위해] [작업을 수행하기를] 원한다.”가 되어버렸다. 사용자의 사용 맥락에 근거한 사용 목적과 가치는 온데 간데 사라져 버리고, ‘기능을 원하기에 기능이 필요하다.’라는 식의 순환 논리만 남은 것이다.
이상적인 사용자 경험은 아무 일도 하지 않고 목표에 도달하는 것이다. 원래의 사용자 스토리 형식은 순수하게 목표(사용자가 손쉽게 달성하고자 하는 것)에만 집중함으로써 이를 상기시킨다. 또한, 사용자가 대가(ex. 시간, 노력, 비용 등)를 지불할 만한 이점을 개략적으로 설명하여 어떤 방식으로 어떤 가치를 전달해야 하는지를 명쾌하게 풀어낸다.
하지만 오남용된 작업 지향적 사용자 스토리는 사용자의 목적을 ‘작업’으로 대체해 버린다. ‘작업’은 시간, 노력 등의 자원을 투입해야 하기 때문에 그 자체로서는 사용자가 지불해야 하는 비용 중 하나다. 그렇기 때문에 제품에 기능을 추가하는 것이 높은 확률로 경험의 질을 저하시키는 것이다.
[작업 지향적 스토리가 낳는 비극]
(1) 사용자의 빠른 이탈
“사용자로서, 나는 페이지를 보기(작업1) 위해, 버튼을 클릭(작업2)하고 싶다.”
이 문장을 해석하면, 또 다른 작업을 하기 위해 작업을 하는 것이다. 이렇게 이어진 스토리는 비용을 치른 후 또 다른 비용을 치르게 하는 구조를 만들어내며, 제품의 복잡성과 작업 요구량은 무한히 증식한다. 소프트웨어 제품 경험에서 사용자는 비용이 가치(편익)를 초과하면, 쉽게 이탈해버린다.
(2) 조직적 혼란
과업 지향적 유저 스토리는 사용자가 무엇이 필요한지 모호하게 만들어 의사결정을 더 혼란스럽게 만든다. 스토리 작성자가 "사용자로서, 나는 양식을 작성하고 싶다"라는 문장의 뉘앙스는 팀에게 마치 ‘이 양식 작성 기능을 만들면 사용자가 돈을 지불할거야!’라는 식의 착각을 하게 만든다. 하지만 이러한 스토리가 담고 있는 내용은 그저 사용자가 지불해야 할 비용(=기능을 사용하기 위해 양식을 작성’해야’ 한다.)뿐이다.
그리고 이러한 유저 스토리는 순환 논법적 특성으로 인해 모든 개발 티켓이 스스로를 정당화시키며, 자연스레 기능은 늘어나고 제품의 복잡성은 증가한다. 제품이 지닌 사용자 가치는 급격하게 하락하지만, 작업 지향적 스토리는 이를 착각하게 만들기 때문에 조직이 이를 스스로 알아차릴 수 없다.
[이렇게 개발된 제품에 대해 고객은 이렇게 대답할 것이다.]
”사용자로서, 나는 이 제품을 사용하기 싫어요.”
작업 지향적 유저 스토리는 사용자의 맥락이 부재한다. 문장 겉으로는 ‘사용자’가 적혀있지만, 본질은 ‘조직 내 이해관계자’가 중심이 되어버린 것이다. 이를 기준으로 작업하다 보면, 제품이 달성해야 하는 고객 가치가 상실되어 버린다. 결국 가치있는 제품/기능을 만드는 것이 목적이 아니라 PM/PO 혹은 이해관계자가 만들고 싶은 것을 만드는지 확인하는 방법론으로, 사실상 워터폴을 애자일의 언어로 하는 것과 다름 없다.
[작업 지향적 스토리를 역으로 활용하는 프레임워크]
과업 지향적 스토리를 역으로 이용할 수 있는 프레임워크가 있다. 바로 ‘뒤집기(invert)’다. 과업 지향적 스토리 안에는 두 가지 유용한 정보가 있다. 대부분의 경우, 과업 지향적 스토리 내에 이점/혜택으로 불리는 내용이 실제로는 ‘비용’이고, 목표라고 불리는 것은 ‘해결책 가설’이다.
예를 들어, 다음과 같은 과업 지향적 스토리가 있다고 해보자.
“사용자로서, 나는 [내 브라우징 경험을 최적화하기 위해] [도구 모음을 커스터마이즈]하고 싶다.”
여기서 [내 브라우징 경험을 최적화하기 위해]는 목표로 보이지만 실제로는 ‘해결책 가설’이며, [도구 모음을 커스터마이즈]는 이점처럼 서술되어 있지만 실제로는 ‘비용’이다. 그렇다면 이를 제대로 스토리화 하면 다음과 같이 정리할 수 있다.
“사용자로서, 나는 [도구 모음을 커스터마이즈하지 않고도] [내 브라우징 경험을 최적화]하고 싶다.”
앞뒤 내용을 뒤집고, 앞의 문장을 부정형으로 바꾸는 것이다. 이 프레임워크를 사용하면 사용자가 달성하려는 가치와 이를 충족시키기 위한 조건도 함께 명시하면서, 다양한 해결책을 아이디에이션 할 수 있는 출발점을 제공해준다.
[사용자가 삶에서 달성하려는 것으로부터 시작할 것(working backwards)]
유저 스토리가 다양한 해결책의 가능성을 지닌 것이 아니라, 명백한 하나의 기능을 떠올리게 한다면 잘못된 스토리일 가능성이 높다. 그렇게 만들어진 제품/기능은 이미 다른 곳에 존재하거나 폐기되었을 것이다. 그러한 것을 만들고 다시 출시하는 것은 명백한 자원 낭비로 이어진다.
모든 기능은 본질적으로 비용이다. 그렇기 때문에 기능이 나온 이유로 거슬러 올라가, 정말 이 기능이 사용자의 가치(편익)을 극대화시켜 기꺼이 제품에 실제 돈을 지불할 만큼인지를 판별할 수 있는 스토리가 필요하다.
Source: https://uxdesign.cc/as-a-user-i-dont-want-to-973990a30158
