Agile UX: UX와 제품 디자인을 Agile에 통합하는 방법

DevOps는 종종 회사의 소프트웨어 및 시스템 개발을 둘러싼 프로세스, 운영, 방법론, 도구 및 문화로 정의됩니다.

그러나 엔지니어링은 진공 상태에서 작동하지 않습니다. 청사진, 아이디어, 디자인 및 개념은 레이아웃, 흐름 및 상호 작용을 결정하는 제품 디자인 전문가로부터 나옵니다. 이들은 DevOps의 목표와 원하는 결과를 공유하는 엔지니어링이 아닌 개인 및 팀입니다.

DevOps는 개발자가 IT와 연결하는 방법, 인프라를 관리하는 방법, 프레임워크를 개선하는 방법 그 이상입니다. 얼마나 많은 팀이 소프트웨어 개발 프로세스에 진정으로 관여하고 있는지, 그들의 역할과 작업이 얼마나 얽혀 있는지 인식하고, 모든 사람이 회의에 참여할 수 있도록 하는 더 나은 방법을 찾는 것입니다.

개발자와 엔지니어링 설계자는 제품 및 크리에이티브 팀이 소프트웨어 또는 시스템을 설계할 때 참여하기를 원합니다. 그러나 DevOps의 현재 정의에서 그것이 어디에 있습니까? 제품, UX 및 크리에이티브 팀은 엔지니어링 프로세스 동안 계속 참여하기를 원하지만 많은 방법론에서 이를 배제합니다. 이것들은 우리가 부숴야 할 오래된 사일로입니다.

고객은 사용자 경험(UX)만 봅니다. 그들은 당신이 얼마나 많은 개발자를 가지고 있는지 또는 당신이 Agile인지 Lean인지 알지 못합니다. 그들은 어떤 DevOps 도구가 사용되고 있는지 전혀 모릅니다. 회사의 UX는 제품이며, 당신을 만들 수도 있고 망가뜨릴 수도 있습니다. 그들은 누가 이 쓰레기를 만들었는지 궁금해합니다. 경쟁이 치열하고 사람들이 기꺼이 앱을 제거하거나 웹사이트를 떠나는 상황에서 귀하를 버린 고객과 두 번째 기회를 얻을 수 있습니까?

Agile은 UX 또는 UX 전문가와 협력하는 경우가 거의 없습니다.

많은 엔지니어링 팀은 종종 UX가 고립되고 협업하기 어렵다고 생각합니다. UX는 린(Lean)으로 보이지 않으며 Agile의 많은 특징은 UX 작업 방법에 대한 세부 사항을 제외합니다. 일부 애자일 접근 방식은 특정 기능을 설명하는 제품 소유자가 "충분히 좋다"고 제안합니다.

SAFe Agile은 UX 사일로를 해결하는 가장 좋은 방법은 이를 완전히 배제하는 것이라고 결정하는 실수를 범합니다. SAFe는 "애자일 팀이 자체적으로 "린 UX"를 수행할 수 있도록 지원합니다. 더 많은 기업이 UX 전문가와 완전한 UX 프로세스를 통합하는 것의 가치를 이해함에 따라 SAFe는 잘못된 방향으로 가고 있습니다.

Agile 교육 및 책에서 UX 및 프로세스에 대한 설명이 없기 때문에 전 세계 팀이 전문 제품 디자이너의 참여를 배제하거나 최소화하게 되었습니다.

• UX가 페이지에 상자를 그린다고 잘못 상상하면 "내가 그 일을 할 수 있다"고 가정하기 쉽습니다. 많은 American Idol 오디션 참가자들이 지구상에서 최고의 가수라고 확신하는 것처럼, 대부분의 제품 관리자와 엔지니어는 UX에 뛰어나다고 스스로 평가합니다. 이것은 일반적으로 그들이 화면 배치에 능숙하다고 믿는다는 것을 의미합니다. 그러나 이 기사에서 실제로 UX 작업에 들어가는 것이 무엇인지 설명하면 UX 전문가가 와이어프레임을 만드는 개발자를 UX 작업을 받아야 하는 사람으로 보지 않는다는 것을 알게 될 것입니다.
• 스크럼에 관한 책에서는 UX 전문가가 병목 현상이 발생하면 자신의 일을 수행하기 위해 UX가 아닌 역할을 교육해야 한다고 제안합니다. 이러한 유형의 결정은 소프트웨어 개발의 다른 역할에 대해 거의 제안되지 않습니다. 부트캠프를 하거나 프로그래밍에 관한 책을 읽은 후에도 훈련되지 않았거나 경험이 없는 개발자가 코딩을 하는 것을 누구도 원하지 않을 것입니다. 우리는 개발자가 병목 현상이 발생하면 프로젝트 관리자에게 코딩을 하도록 교육해야 한다고 제안하지 않습니다.
• UX가 예술적(UI) 직업이라고 잘못 생각하는 고용 관리자는 UX 작업을 수행할 아티스트를 고용합니다. UX 학위와 UI 학위 사이에는 교육적 중복이 없습니다. 타고난 재능은 종종 겹치지 않습니다. UX에 뛰어난 사람은 가난한 예술가일 수 있고 그 반대의 경우도 마찬가지입니다. "UX/UI"에 대한 고용은 종종 최소한의 UX 경험, 전문 지식, 프로세스 또는 교육으로 훌륭한 아티스트를 제공합니다.

결론만 바라보는 사람들은 UX 교육, 경험, 전문 지식, 기술 또는 타고난 재능이 부족한 개인에게 UX 작업을 제공하여 예산을 줄이는 것을 좋아할 것입니다. 그러나 이것은 근시안적이며 생산성, 효율성, 문화, 제품 및 고객 만족도 저하로 이어질 수 있습니다.

애자일에 전문 UX 전문가 통합의 중요성

2018년 말 경영컨설팅업체 맥킨지앤컴퍼니(McKinsey & Company)는 300개 이상의 기업을 대상으로 연구한 보고서인 '디자인의 비즈니스 가치(Business Value of Design)'를 발간했다.

그들은 "디자인이야말로 기업이 군중 속에서 돋보일 수 있는 유일한 방법"이라는 사실을 깨달았습니다. 경쟁업체가 유사한 기능 세트를 보유하고 있을 때 차별화되는 요소는 무엇입니까? 디자인은 때때로 단지 미학 또는 이것이 우리 브랜드처럼 보이게 하는 것으로 생각됩니다. 그러나 "UX"와 함께 사용할 때 디자인은 기능의 아키텍처와 화면, 단계, 흐름, 레이아웃, 프로세스, 구성 및 메뉴에 대한 결정을 의미합니다.

UX는 지속적인 개선 프로세스의 일부이며, 항상 사용자를 더 잘 이해하고, 사용자의 요구에 가장 잘 맞는 기능과 제품을 선택 및 설계하고, 문제점을 해결하고, 의미 있는 혁신을 가져오기 위해 노력합니다.

McKinsey는 또한 "회사는 디자인을 나중에 적합한 작은 도구로 보기보다 프로세스 초기에 전체적으로 수용해야 합니다."라고 보고했습니다. 사용자 경험에 대한 관심을 최소화하거나 배제하거나 제품 출시 이후에 수행할 수 있다고 가정하는 팀은 잘못된 접근 방식을 취하고 있습니다.

McKinsey는 정량적 데이터를 수집하고 UX 디자인을 채택한 기업이 5년 동안 32% 더 많은 수익과 56% 더 많은 주주 수익을 창출한다는 것을 발견했습니다. 회사가 "사용자 중심"이라고 선언하는 것만으로는 충분하지 않습니다. 계획 및 포트폴리오에서 개발 및 QA에 이르기까지 UX 실무자와 프로세스를 통합하는 과정을 거쳐야 합니다.

UX가 있거나 없는 소프트웨어 개발 프로세스

회사에서 소프트웨어 디자인 및 개발 프로세스에 UX 전문가를 포함하지 않는 경우 프로세스는 아래 이미지와 같을 가능성이 큽니다.

고객, 제품 관리자, CEO 또는 비전을 가진 사람이 엔지니어링에 원하는 것을 알려줍니다. 엔지니어링에서 빌드하고 테스트한 다음 스테이징 또는 프로덕션 서버에서 가져옵니다. 그러면 비전을 가진 사람은 그것을 보고 행복하지 않습니다. 그들은 다른 것을 원하거나 마음이 바뀌었습니다.

그런 다음 엔지니어링은 처음으로 돌아가서 이 사람이 지금 원하는 것이 무엇인지 알아내고, 구축하고, 테스트하고, 이것이 매력이라는 것을 손가락으로 교차해야 합니다.

팀에 UX 전문가가 있는 경우 프로세스가 상당히 다릅니다. 비전을 가진 사람이 아이디어, 데이터, 고객의 애로사항을 가지고 UX에 옵니다. UX는 사용자 중심의 설계 프로세스에서 작업을 순환한 다음 엔지니어링이 한 줄의 코드를 작성하기 전에 이러한 개념을 테스트합니다. 이를 통해 구축하려는 제품 또는 기능이 대상 고객에게 올바른 아이디어를 올바르게 실행할 수 있습니다.

테스트는 몇 가지 결함을 드러낼 수 있으며, 이는 UX가 반복하고 종종 다시 테스트할 수 있도록 합니다. UX 프로세스가 끝나면 엔지니어링에 전달할 준비가 된 완전히 검증된 디자인이 있습니다.

도중에 누군가 마음이 바뀌면 그 사람은 개발자에게 변경 요청으로 넣는 것이 아니라 UX와 이야기합니다. UX는 프로세스 중에 간섭을 실행하며 실제 또는 원형 고객에 대한 설계, 결정 및 테스트에 UX가 관여하지 않고는 엔지니어링에 아무 것도 전송되지 않습니다.

누군가가 이 시점에서 마음을 바꾸는 데 드는 비용이 최소이기 때문에 이 시점에서 마음의 변화는 재앙이 아닙니다. 엔지니어링은 청사진을 제공하지 않았고 시작도 하지 않았으며 재구축할 것도 없습니다. UX는 디자인을 반복하고 아이디어가 고객 기반과 잘 일치하는지 확인하기 위해 사용자 테스트를 수행할 수 있습니다. 마음의 변화는 시간을 소모하지만 예산에 대한 전반적인 영향은 작습니다.

UX에는 공식화된 프로세스가 있습니다.

사용자 중심 디자인(UCD)은 UX 전문가에게 실제 또는 원형 사용자를 대상으로 연구, 디자인, 프로토타입을 만들고 테스트한 다음 테스트를 통해 배운 내용을 기반으로 반복하도록 지시하는 작업을 포함하는 공식화된 프로세스입니다.

이러한 영역 중 일부에 중점을 두고 기능 및 프로젝트에 대한 요구 사항과 초기 논의 로 시작합니다. UX가 먼저 요구 사항 및 기타 프로젝트 정보를 얻었을 때 바로 협업을 시작하는 것이 중요합니다. UX는 구축할 수 없는 것을 설계했다는 사실을 나중에 알게 되어서는 안 됩니다.

제품 또는 프로젝트 관리자가 기능과 우선 순위를 결정할 때 UX 작업자나 관리자를 데려오는 것부터 시작하세요. 사용자에게 가치가 없는 프로젝트는 제거할 수 있어 막대한 시간과 비용을 절약할 수 있습니다. 여기에서 수행되지 않은 작업의 양을 최대화해야 합니다. 제품 및 엔지니어링은 기능 또는 전체 프로젝트를 줄이거나 제거하여 엔지니어링 작업을 덜 생성할 때 UX를 지원해야 합니다. 그러나 너무 자주 프로젝트에 자아가 부착되어 팀원들이 초기 대화에서 UX를 제외하여 프로젝트 자금을 조달하는 경우가 많습니다.

연구 는 UX가 하는 일의 중요한 부분입니다. 사용자를 포함하지 않고는 사용자 중심이 아닙니다. 통계와 양적 데이터는 훌륭하지만 사용자를 인터뷰하고 깊이 이해하고 질적 데이터를 얻는 것 외에는 대안이 없습니다. UX는 무엇을 아는 것이 아니라 그 이유를 알고 싶어합니다.

UX 연구는 또한 타겟 고객의 원형인 페르소나를 중심으로 모든 사람을 통합함으로써 팀원들을 같은 페이지로 끌어들입니다. 사용자 인터뷰를 기반으로 학습한 내용을 집계하고 모든 사람을 6명 이하의 페르소나로 요약합니다. 무엇이 그들에게 동기를 부여합니까? 그들에게 필요한 것은 무엇입니까? 우리 회사, 제품 또는 서비스에 대한 기회는 어디에 있습니까?

페르소나를 사용하는 가장 좋은 방법은 페르소나를 모든 곳에 포함시키는 것입니다. 제품은 페르소나(및 좋은 데이터)를 기반으로 기능을 상상합니다. 페르소나를 기반으로 한 UX 디자인. QA 테스트는 그들이 이러한 페르소나라고 상상하면서 테스트합니다. 마케팅은 인구 통계 및 기타 세부 정보를 추가할 수 있지만 브랜드 보이스, 소셜 미디어 및 광고가 페르소나에게 어떻게 전달되는지도 고려해야 합니다.

페르소나는 비 UX 작업자가 "음, 나는 이런 방식이 좋아" 또는 "CEO가 이런 방식을 좋아한다"에서 벗어날 수 있도록 도와줍니다. 우리는 이러한 타겟 고객을 위해 디자인하고 있으며 귀하 또는 CEO가 페르소나에 적합하지 않은 경우 UX는 자아 또는 개인 취향에 좌우되지 않습니다. UX는 고객 중심을 유지해야 합니다.

정보 아키텍처 는 계층, 구조 및 분류와 관련이 있습니다. 이것은 사이트 탐색일 수도 있고 전자 상거래 데이터베이스에서 제품이 분류되는 방식일 수도 있습니다. 고객이 카테고리, 메타 데이터 및 필터별로 제품을 쉽게 찾을 수 있도록 하고 싶습니다.

경험 디자인이라고도 불리는 인터랙션 디자인 은 대부분의 사람들이 UX를 상상할 때 생각하는 것입니다. 와이어프레임과 프로토타입, 설계 및 개념의 청사진입니다. 여기에는 프로세스 흐름, 레이아웃, 메뉴, 상호 작용, 경로, 선택 항목 등이 표시됩니다.

UX 프로토타입은 살아 움직이는 와이어프레임과 같습니다. 클릭 가능한 대화형 디지털 모형입니다. 코드를 작성할 필요가 없습니다. 이를 신속하게 생성하는 데 도움이 되는 소프트웨어가 있습니다. 조건부 논리, 변수, 모바일 스와이핑 제스처, 드래그 앤 드롭 및 모든 종류의 이벤트 트리거가 있기 때문에 보다 현실적인 프로토타입을 찾는 회사는 Axure를 사용합니다. 거의 모든 유형의 장치에 대한 프로토타입을 만들 수 있습니다.

UX 프로토타이핑은 다음을 위해 수행됩니다.

• 영감
• 협력
• 반복
• 솔루션 살펴보기
• 투자자를 위한 프레젠테이션(스타트업용)
• 솔루션이 대상 고객과 잘 연결되는지 확인하기 위해 프로토타입을 테스트합니다.
• 개발자나 다른 팀원에게 대화형 모델을 제공합니다. 이는 문서 페이지보다 선호되는 경우가 많습니다(클릭 가능한 모델 없음).

이제 사용성 테스트라고도 하는 사용자 테스트 로 이동합니다. 이 테스트는 UX 프로세스 중에 발생하며 엔지니어링이 한 줄의 코드를 작성하기 전에 발생합니다. 아이디어와 실행이 대상 고객에게 환상적인지 확인하려면 개념과 디자인을 테스트해야 합니다.

사용자 테스트는 모든 결함을 밝혀내고 UX가 아이디어를 반복할 수 있는 기회를 제공합니다. 이는 엔지니어링이 구축하거나 재구축할 것이 없기 때문에 현재로서는 저렴합니다.

UX가 엔지니어링에 전달하기 전에 테스트를 실행하는 5가지 주요 이유가 있습니다.

1. 엔지니어링의 시간과 자원을 최대한 활용합니다. 테스트 참가자가 엔지니어가 만든 완제품을 보게 하려면 버그가 있는지 빌드하고 테스트해야 합니다. UX 테스트에서 필요한 변경 사항이 밝혀지면 개발자는 다시 빌드해야 하고 QA는 다시 테스트해야 합니다. UX 테스트가 개념의 더 큰 실패를 보여주었다면 이것은 어디에서나 끝날 코드가 아니기 때문에 엔지니어링 시간이 완전히 낭비되었음을 의미할 수 있습니다. 이 개념은 다시 생각하고, 재설계하고, 새롭게 테스트해야 합니다.
2. 무대 뒤에서 반복합니다. 회사에서 빌드만 하고, 배송하고, 반복하고, 빌드하고 다시 배송하는 경우, 이는 고객이 다양한 버전을 보고 있음을 의미합니다. 그들은 진행 중인 작업을 보고 소시지가 만들어지는 것을 보고 있습니다. 이것은 종종 고객이 진화하는 시스템을 계속해서 다시 배워야 하는 답답하고 혼란스러운 경험입니다. UX 프로세스의 배후에서 반복하고 테스터에게 프로토타입 또는 데모 버전임을 분명히 하는 것이 좋습니다.
3. 모니터링 및 측정. 새로운 개념이 실시간으로 출시되면 UX 연구원은 사람들이 그것을 사용하는 것을 지켜보고 질문하고 UX가 무언가가 준비되었거나 다른 반복이 필요한지 결정하는 데 필요한 유형의 피드백을 얻을 수 있는 좋은 방법이 없습니다. UX는 항상 무엇을 또는 ​​얼마나 많이 하는 것이 아니라 왜, 질적으로 알고 싶어합니다. 사용자는 어떻게 지출, 전환, 참여 등을 하고 있습니까? 적절한 UX 테스트를 피하면 문제나 고객의 문제점을 진단하고 수정하기가 더 어려워집니다.
4. UX 테스트는 그 자체로 비용을 지불합니다. UX 테스팅은 큰 비용이 들지 않습니다. 일부 타사 테스트 도구는 테스트 참가자당 $100 미만을 원하고 일부는 수천 달러의 최소 연간 약정을 요구합니다. 소프트웨어 개발 프로세스에 대한 회사의 전체 예산과 초기 테스트 피드백의 중요성을 고려할 때 이는 큰 비용이 아닙니다. 사용자 테스트 라운드는 프로그래머가 실행 취소하거나 다시 빌드해야 할 수 있는 것을 빌드하도록 만드는 것보다 거의 항상 비용이 적게 들고 빠르게 진행됩니다.
5. 사용자 테스트는 인수를 해결합니다. 회사에서 UX 전문가가 제품 디자인 방식에 대한 최종 결정을 내리도록 허용하지 않는 경우 빌드하고 배포해야 할 항목에 대한 다양한 아이디어가 있을 때 UX가 제품, 엔지니어링 또는 이해 관계자와 충돌할 수 있습니다. 고객. 또는 UX에 두 가지 강력한 아이디어가 있고 어떤 것이 고객과 더 잘 연결되는지 궁금해한다면 어떻게 될까요? 여기서 해결책은 사용자 테스트입니다.

UX는 개념의 프로토타입을 만들 수 있습니다. 특히 아이디어와 팀 구성원 간에 이미 타협점을 찾을 수 있는 경우 경쟁을 최고의 두 가지 디자인으로 요약하는 것이 가장 좋습니다. 이것은 우리가 UX가 원하는 것, 제품이 좋아하는 것, 엔지니어링 헤드가 좋아하는 것, 스크럼 마스터가 좋은 아이디어라고 생각하는 것, CEO의 인생 파트너가 좋아하는 것을 테스트하지 않는다는 것을 의미합니다.

사용자 테스트를 통해 고객이 의견을 말하고 기능 또는 제품에 대한 올바른 방향을 찾는 데 도움이 됩니다. 어떤 아이디어가 가장 고객 만족도를 높일 수 있는지 모든 사람에게 알려주는 엄격한 양적 및 질적 데이터를 팀에 제공하여 논쟁을 해결합니다.

사용자가 참여하지 않는 사용자 중심의 디자인이 아닙니다. 이것은 우리가 추측하거나 추측하거나 "그냥 배송"하는 것이 아니라 실제 또는 전형적인 고객을 대상으로 조사하고 테스트한다는 것을 의미합니다. 우리는 우리가 "방금 배송"한 것이 사용자 테스트를 통해 검증되었고 훌륭한 아이디어를 훌륭하게 실행했는지 확인해야 합니다.

UX가 우회되거나 축소되면 어떻게 됩니까?

Skype는 최근 Snapchat과 유사하게 만들려는 2017년 재설계가 실패했다고 발표했습니다. 사용자는 새로운 기능을 원하지도, 필요하지도, 좋아하지도 않았습니다. 반발은 Skype가 2018년 Skype를 다시 설계하겠다고 발표할 만큼 충분히 컸습니다. (https://devops.icu/skypes-coming-redesign-of-ir-last-redesign/)

UX 전문가는 프로세스의 여러 단계에서 이러한 기능이 원하지 않거나 실패할 가능성이 있다는 것을 알고 있었을 것입니다. 대상 사용자를 대상으로 한 연구에서는 Skype가 Snapchat이 되는 것을 원하지 않는다는 사실이 빠르게 드러날 수 있었습니다. 이 초기 시점에서 프로젝트를 중단하거나 선회하면 Skype가 수백만 달러와 나쁜 언론 및 고객 소외를 절약할 수 있습니다.

UX 연구를 우회했더라도 사용자에 대한 UX 프로토타입을 테스트하면 고객이 Skype가 이러한 방향으로 가는 것을 원하지 않는다는 것을 분명히 했을 것입니다. UX가 여전히 프로세스를 진행하고 있기 때문에 엔지니어링은 아직 한 줄의 코드도 작성하지 않았습니다. 이것은 엔지니어링이 할 필요가 없는 단순성과 작업을 축하하면서 엄청난 시간, 돈, 인적 자원을 절약할 수 있었습니다.

애자일 UX 프로세스

애자일 선언문 원칙을 기억하십시오. 귀하의 최우선 순위는 가치 있는 소프트웨어를 구축하여 고객 만족입니다. (UX) 작업자에게 필요한 환경과 지원을 제공하고 작업을 완료하도록 신뢰하십시오. 하지 않은 일의 양을 최대화하십시오. 좋은 디자인에 대한 지속적인 관심은 민첩성을 향상시킵니다.

앞으로 나아가는 프로젝트는 적절한 연구, 디자인 및 테스트가 시작될 수 있도록 UX에 거대한 활주로를 제공해야 합니다. 킥오프 미팅에 UX를 초대하지 말고 최종 와이어프레임이 며칠 안에 제공되어야 한다는 요구에 놀라지 마십시오. 그것은 UX가 아닙니다.

이것을 BDUF(Big Design Up Front)로 보지 마십시오. 이는 사람들을 움츠리게 만들고 이것이 우리가 멀리해야 하는 것이라고 선언하도록 고안된 용어입니다. 프로젝트나 기능이 크거나 새로운 경우 UX는 사용자 중심 디자인 프로세스의 전부는 아니지만 대부분을 순환해야 합니다. UX의 경우 더 큰 기능을 위한 가장 작은 부분은 사용자의 워크플로 또는 프로세스입니다. 더 작은 것을 설계하고 테스트하면 진정한 사용자 경험에 대한 큰 그림을 얻지 못할 위험이 있습니다.

예를 들어 사용자가 등록하고 구매하는 흐름을 설계하는 경우 암호 선택 필드를 설계하고 이를 엔지니어링에 제출할 수 없습니다. UX가 작은 부분으로 작동했다면 전체 프로세스를 언제 테스트할까요? 전체 흐름을 테스트하지 않고는 전체 흐름에 대한 사용자의 반응을 알 수 없습니다... 즉, 사용성 테스트에 들어가기 전에 전체 흐름을 설계해야 합니다.

기능, 스토리 또는 수정 사항이 작은 경우 UX 실무자는 사용자 중심 디자인 프로세스의 하위 집합을 수행하고 더 빠르게 작업할 수 있습니다. UX는 항상 최대한 빠르게 진행되지만 훌륭한 UX 전문가는 수행 중인 작업의 품질을 희생하지 않도록 최선을 다할 것입니다. 빠른 대 좋은 싸움에서 UX는 항상 빠른 것보다 좋은 것을 선택합니다. 당신도 그렇게 해야 합니다.

예산과 일정은 UX가 빠른 피드백을 받고 반복하는 것을 방해합니다. UX 실무자는 고객에게 실제로 효과가 있는 디자인을 목표로 항상 피드백과 제품 개선 기회를 원합니다. 포트폴리오 관리 및 계획 초기에 UX 실무자를 데려오면 UX는 필요한 시간과 예산을 예측할 수 있습니다. 이것은 나중에 놀라움이나 갈등의 원인이 되어서는 안 됩니다.

UX 실무자는 애자일 팀의 일원입니다.

애자일 팀에 UX 디자이너를 포함시키십시오. 계획, 스탠드업, 레트로 및 UX가 논의될 수 있는 모든 회의에 그들을 초대하십시오. UX 작업에 필요한 타이밍에 대해 놀라지 않도록 릴리스 계획 중에 UX가 시간을 예상할 수 있도록 합니다. 그들 없이 결정을 내리지 마십시오. UX 팀원이 회의에 참석하지 못한 경우 채팅, 이메일 또는 회사에서 사용하는 모든 방법을 통해 직접 찾을 수 있을 때까지 기다리십시오.

질문, 모호성 또는 버그를 JIRA 또는 사용하는 버그 추적 시스템의 UX 팀원에게 할당하십시오. UX 문제가 다른 문제와 동일한 시스템에 있는지 확인하십시오. 다른 모든 것에 VersionOne을 사용하는 경우 Trello 보드에서 UX 문제를 삭제하지 마십시오.

UX가 긴 활주로를 가진 후 이 기능이나 제품에 필요한 경우 UX가 엔지니어링보다 2번 이상의 스프린트가 되도록 하는 것이 가장 좋습니다. UX는 당신과 함께 질주할 수 있습니다. 많은 기술 이야기를 얻거나 기술 부채를 백로그로 수정하십시오. 그렇게 하면 UX의 창의적이고 순환적인 프로세스가 늦게 실행되거나 더 많은 스프린트가 필요한 경우 개발자가 진정으로 애자일할 수 있습니다. UX를 ​​기다리는 대신 제품이나 엔지니어링이 우선시하는 일부 낮은 행잉 과일로 전환할 수 있습니다.

또한 자원 조달, 할당 및 인력 배치를 고려하십시오. 프로젝트 규모에 따라 1명의 UX 디자이너에게 3개 이하의 프로젝트를 배정합니다. 테스팅과 분석도 함께 하는 별도의 전문 UX 연구원이 있는 경우 3명 이하의 UX 디자이너에게 1명의 연구원을 할당하십시오. 당신의 UX 실무자가 T자형으로 알려진 사람이라면, 즉 그녀가 연구, 테스트 및 기타 UX 하위 전문 분야에서도 자격이 있고 탁월하다면 너무 많은 프로젝트에 할당되어 실수로 병목 현상이 발생하지 않도록 하십시오.

측정 결과

고객 만족 없이는 고객이 없을 수 있습니다. 고객 만족도 메트릭을 사용하여 UX 통합을 통한 프로세스 개선이 긍정적인 변화를 가져온 방법을 확인할 수 있습니다.

• 불만 감소
• 더 나은 앱 리뷰
• 더 높은 앱 평점
• 지원 티켓 감소
• 콜센터 호출 감소
• 소셜 게시물의 더 긍정적인 의미
• 더 많은 앱 설치, 더 적은 제거
• AOV(평균 주문 가치) 증가
• 더 높은 전환율

또한 시장 출시 시간 및 수정 간격과 같은 원하는 DevOps 목표를 측정할 수도 있습니다. UX 혁명 전후에 이야기, 프로젝트 및 서사시가 시장에 출시되는 데 얼마나 걸립니까? 개발자 시간 추정치는 추정치의 기반이 되는 UX 디자인을 완성했을 때와 스토리 또는 지금 하고 있는 모든 작업에서 작업할 때 더 정확할 수 있습니다.

UX가 청사진을 제공하고 이를 따르고 있다면 엔지니어링이 갑작스러운 변경과 재구축을 줄여 작업을 덜 하기를 바랍니다. 더 나은 UX 디자인은 더 일찍, 더 적은 수의 수정 사항을 나중에 제공합니다.

Agile UX는 그 이상의 가치를 지닌 투자입니다.

많은 프로젝트 관리자는 UX를 제거하거나 줄일 수 있는 예산선으로 보고, 고용 관리자는 UX 작업을 다른 역할과 결합하는 아이디어에 흥분합니다. 그러나 점점 더 많은 기업들이 훈련되고 경험이 풍부한 UX 전문가가 수행하는 적절한 UX 프로세스에 투자하는 것 외에는 없다는 것을 깨닫고 있습니다.

린 스타트업(Lean Startup)의 저자인 에릭 리스(Eric Ries)는 “아무도 원하지 않는 것을 구축하고 있다면 어떨까요? 그런 경우, 제 시간에 예산에 맞춰 했다면 무슨 상관이겠습니까?” 조직에서 린 방법론을 사용하지 않더라도 경고는 여전히 유효합니다. DevOps가 원하는 결과는 우리가 고객에게 적합한 것을 구축하고, 고객 만족도를 개선하고, 고객 가치가 높은 기능을 개발하는 것을 목표로 할 때 이를 반영합니다.

고객을 알고, 프로세스에 고객을 참여시키고, 고객의 진정한 필요와 선호에 맞게 구축하는 것이 궁극적으로 일정, 예산, 프레임워크 및 도구보다 더 중요합니다. 올바른 아이디어의 올바른 실행을 구축하면 수익이 발생할 것임을 믿으십시오.