3장. 결과
이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: translation-feedback@oreilly.com
전통적으로 소프트웨어 프로젝트는 요구 사항과 결과물로 구성됩니다. 팀에는 요구 사항이 주어지고 결과물을 만들어야 합니다. 이러한 결과물에는 해당 요구 사항을 충족하는 시스템, 기능 및 기술이 설명됩니다. 많은 경우 요구 사항은 전략적 맥락 없이 전달됩니다. 이 작업을 하는 이유는 무엇인가요? 누구를 위해? 성공이란 어떤 모습일까요?
Lean UX는 기능 및 디자인 선택에 대한 전략적 맥락, 더 나아가 디자인 부서뿐 아니라 팀 전체가 성공을 정의하는 방식을 다시 도입함으로써 업무의 틀을 근본적으로 변화시킵니다. 우리의 목표는 결과물이나 기능을 만드는 것이 아니라 고객 행동이나 세상의 변화에 긍정적인 영향을 미쳐 성과를 창출하는 것입니다.
우리는 어떤 사업을 하고 있나요?
Lean UX는 결과물 비즈니스에서 벗어나는 것을 의미합니다 . 우리는 결과물을 만드는 비즈니스에 종사하고 있습니다. 문서와 목업, 프로토타입, 기능, 페이지, 버튼 등 우리가 만드는 것들에 덜 집중하고 결과를 창출하는 데 더 집중해야 합니다. 이를 위해 우리는 우리가 원하는 결과를 만들어내는 것들만 만드는 데 집중합니다.
기능이나 결과물 대신 결과에 집중하는 이유는 무엇일까요? 우리가 디자인하고 구축한 기능이 원하는 가치를 창출할지 예측하는 것이 어렵고, 많은 경우 불가능하다는 사실을 깨달았기 때문입니다. 이 버튼이 사람들의 구매를 유도할까요? 이 기능이 더 많은 참여를 유도할까요? 사람들이 이 기능을 우리가 예측하지 못한 방식으로 사용할까요? 사람들이 우리 서비스와 상호작용하는 방식을 성공적으로 바꿀 수 있을까요? 따라서 기능에 집중하기보다는 우리가 창출하고자 하는 가치에 집중하고 원하는 가치, 즉 결과를 제공하는 솔루션을 찾을 때까지 계속 테스트하는 것이 좋습니다.
이러한 강조점의 변화는 디자이너가 프로세스의 일부로 만드는 문서, 목업, 와이어프레임, 사양, 프로토타입과 같은 것들과 작업의 틀을 잡는 방식 모두에 적용됩니다. 고객이나 이해관계자가 원하는 결과물은 무엇인가요? 물론 웹사이트나 앱을 만들어 달라고 요청할 수도 있습니다. 새로운 페이지, 새로운 흐름, 새로운 카피를 요구할 수도 있습니다. 하지만 이러한 요구에는 이유가 있으며, 그 이유를 이해하고 명확하게 표현하는 것이 우리 업무의 일부입니다. 이 책의 다음 부분에서 그 방법을 자세히 살펴보겠습니다. 하지만 지금은 결과물에서 결과 중심으로, 즉 결과물에서 결과 중심으로 업무를 재구성하는 데 도움이 되는 몇 가지 언어를 소개해드리고자 합니다.
성과에 대한 이야기
에이전시에서 일하는 소규모 팀을 상상해 보세요. 조노, 니콜, 알렉스, 아만다가 새로운 고객을 처음 만납니다. 이 고객은 올해 말에 출시할 새 웹사이트를 디자인, 구축 및 런칭하기 위해 대행사를 고용했습니다.
고객 팀은 이 첫 회의를 준비했습니다. 웹 사이트가 충족해야 하는 세부 요구 사항 목록을 준비하여 ...