조직에 더 나은 설계 프로세스 가져오기

게시 됨: 2022-03-10

빠른 요약 ↬ 최근 몇 개의 소프트웨어 프로젝트에 대해 생각해 보십시오. 구체적인 비즈니스 목표, 사용자 요구 충족, 적시에 제품 배송 사이에 균형이 잘 잡혔습니까? 이러한 균형을 유지하기 위한 핵심은 복잡성을 고려하고 설계 문제를 조기에 해결하며 제3자에 지나치게 의존하지 않는 설계 프로세스입니다.

사용자 경험(UX) 디자이너 및 연구원으로서 사용자로부터 가장 많이 듣는 불만 사항은 다음과 같습니다.

"왜 그들은 내가 필요한 것에 대해 생각하지 않습니까?"

실제로 많은 조직에는 사용자와 고객이 필요로 하는 것을 제공하는 전담 팀이 있습니다. 점점 더 많은 소프트웨어 개발자가 고객이 사용하고 이해할 수 있는 인터페이스를 코딩하기 위해 UX 디자이너와 협력하고 싶어합니다. 문제는 복잡한 소프트웨어 프로젝트가 경쟁 우선 순위와 다음에 해야 할 일에 대한 혼란으로 쉽게 수렁에 빠질 수 있다는 것입니다.

그 결과 생산성을 저해하는 불량한 설계가 초래됩니다. 예를 들어, 의료의 효율성은 전자 의료 기록(EMR)에 의해 방해를 받습니다. 이러한 소프트웨어 시스템에 대한 불만은 엄청나게 많습니다. 보스턴에 기반을 둔 피부과 의사이자 예일 의대 졸업생인 Dr. Steven Ugent도 예외는 아닙니다.

2010년부터 Dr. Ugent는 두 가지 EMR 시스템을 사용했습니다. 2010년 이전에는 매일 5시 15분에 즉시 작업을 마쳤습니다. 그와 그의 동료들이 EMR을 사용하기 시작했기 때문에 그는 일반적으로 저녁에 추가로 30분에서 1.5시간을 일합니다. “저는 의료 기록 시스템에 만족하는 의사가 없습니다. 미친 것은 내가 펜과 종이를 사용할 때 훨씬 더 효율적이었다는 것입니다.”

EMR 시스템은 투박하고 유연하지 않으며 사용자 정의하기 어렵습니다. 예를 들어 Ugent는 차트 노트에 사진을 직접 삽입할 수 없습니다. 대신, 그는 두더지 사진이 있는 폴더를 열고 텍스트를 보려면 다른 폴더를 열어야 합니다. 이 설정은 환자를 치료할 때 사진에 크게 의존하는 피부과 의사에게 특히 번거롭습니다.

Ugent는 EMR의 문제를 다음과 같이 간결하게 요약합니다.

“[EMR 시스템]을 설계하는 사람들은 내 작업 흐름을 이해하지 못합니다. 그렇게 한다면 다른 시스템을 설계할 것입니다.”

투박한 소프트웨어에 대한 불만은 의사들만이 아닙니다. 전 세계의 소비자와 전문가들은 비슷한 불만을 제기합니다.

"왜 필요한 것을 찾을 수 없습니까?"

“그들은 왜 그렇게 힘들게 만드는 걸까?”

“단순히 이 제품을 사고 싶은데 왜 로그인을 해야 합니까? 나는 그들에게 돈을 주고 있다. 그것으로 충분하지 않습니까?”

투박한 소프트웨어의 주요 원인은 결함이 있는 설계 프로세스입니다. 이 기사에서는 4가지 디자인 프로세스 문제를 간략하게 설명하고 해결 방법을 설명합니다.

복잡성
다음 방출 증후군
설계 반복을 위한 불충분한 시간
외부 공급업체에 대한 통제권 양도

점프 후 더! 아래에서 계속 읽기 ↓

1. 복잡성

규모, 여러 이해 관계자 및 정교한 코드에 대한 필요성은 대규모 소프트웨어 프로젝트의 복잡성에 기여하는 많은 요인 중 하나입니다.

그러나 때때로 간과되는 복잡한 법률과 규정이 있습니다. 예를 들어, 보험은 주 수준에서 엄격하게 규제되어 여러 주에서 운영되는 보험 회사에 복잡성 계층을 추가합니다. 은행과 신용 조합은 규제를 받는 반면 유틸리티는 주 및 연방 환경법을 준수해야 합니다.

FDA 규정의 적용을 받는 의료 제품 및 소프트웨어는 훨씬 더 큰 문제를 제공합니다. 문제는 규제가 불합리한 것이 아니다. 안전이 가장 중요합니다. 문제는 FDA 요구 사항을 충족하는 데 필요한 시간, 예산 및 계획입니다.

의료 분야에서 광범위한 경험을 가진 UX 컨설턴트인 Jeff Horvath 박사는 다음과 같이 설명합니다. “이러한 요구 사항은 테스트 프로토콜 작성, 테스트 설정, 데이터 수집, 분석, 품질 관리 및 우선 연구를 수행할 수 있도록 승인을 받아야 합니다.” 예를 들어, 사용성 테스트의 단일 라운드는 6주(표준 사용성 테스트를 위한 합리적인 시간 프레임)에서 6개월로 점프합니다. 그리고 그것은 한 번의 사용성 테스트를 통해 이루어 집니다. 종종 두 번 이상의 테스트가 필요합니다.

이 수준의 엄격함은 FDA와 협력하는 새로운 회사에 대한 경종을 울립니다. Horvath는 FDA 요구 사항을 충족하는 데 필요한 연장된 일정과 추가 예산에 대한 준비가 되어 있지 않은 고객과 한 번 이상 힘든 대화에 직면했습니다. 어렵지만 필요합니다. Horvath는 "철저한 작업이 필요합니다. 2018년 FDA는 시판 전 제출물의 11%만 승인했습니다.

연구원, 설계자 및 개발자에 대한 요구는 기존 소프트웨어 제품보다 FDA 준수가 필요한 의료 소프트웨어에 대해 더 높습니다. 예를 들어:

UX 연구원은 하루에 1~2회의 사용성 테스트 세션만 수행할 수 있습니다. 표준 소프트웨어의 경우 하루에 5~6개의 세션이 더 일반적입니다.
UX 디자이너는 소프트웨어와 사용자 상호 작용의 모든 측면에 매우 주의를 기울여야 합니다. 한 번의 혼란스러운 상호 작용으로 인해 임상의가 환자의 건강을 위태롭게 할 수 있는 오류를 범할 수 있습니다. 같은 이유로 UI 디자이너는 모든 상호 작용에 충실한 인터페이스를 그려야 합니다.
디자인 및 사용성 테스트를 위한 더 긴 시간 프레임은 개발자의 코딩 노력이 신중하게 계획되어야 함을 의미합니다. 숙련되고 선의의 개발자는 새로운 정보가 제공되는 즉시 코드를 수정하기를 열망하는 경우가 많습니다. 이 접근 방식은 빠른 반복이 잘 수행되는 조직에서 작동할 수 있지만 복잡한 시스템을 설계하고 코딩할 때는 위험이 따릅니다.

복잡성을 관리하지 못하면 Danielle McCray가 출산을 앞두고 있는 Tallahassee Memorial Hospital에 입원했을 때와 같이 치명적인 결과를 초래할 수 있습니다. 그녀의 불편함을 덜어주기 위해 의료 종사자들은 그녀를 환자가 제어하는 진통제인 프로그래밍 가능한 주입 펌프에 연결했습니다.

8시간 후 McCray는 모르핀 과다 복용으로 사망했습니다. 이 비극의 주요 요인은 약물 투여에 사용되는 주입 펌프의 결함이 있는 설계였습니다. 펌프에는 27개의 프로그래밍 단계가 필요했습니다. 보다 직관적인 사용자 인터페이스를 설계하여 이러한 복잡성을 해결하지 못하면 불필요한 죽음을 초래했습니다.

해결책

해결책은 복잡성을 인정하고 해결하는 것입니다. 이 점은 논리적으로 들립니다. 그러나 위에서 설명한 것처럼 복잡한 FDA 규정은 종종 회사 리더를 놀라게 합니다. 거부가 작동하지 않습니다. 계획에 실패하면 조직이 2018년 FDA가 거부한 시판 전 제출의 89%에 빠질 가능성이 높습니다.

사용성 테스트를 수행할 때 사용자 경험 연구자는 FDA 규정과 관련된 복잡성을 관리하기 위해 세 가지 단계를 수행해야 합니다.

중재자(사용성 테스트를 실행하는 사람)는 매우 주의를 기울여야 합니다. 예를 들어, MRI 스캔에서 기술자가 관련 소프트웨어를 사용하는 동안 엄격한 단계를 따라야 하는 경우 사회자는 참가자가 편지의 지침을 따르는지 확인하기 위해 주의 깊게 관찰해야 합니다. 그렇지 않은 경우 작업은 인터페이스 디자인과 관련 문서 모두 수정이 필요함을 의미하는 실패로 평가됩니다.
중재자는 마감 통화도 추적해야 합니다. 예를 들어, 참가자는 처음에 순서가 잘못된 단계를 수행하고, 실수를 발견하고, 적절한 순서에 따라 복구할 수 있습니다. FDA는 이것을 거의 실패로 간주하고 중재자는 이를 보고해야 합니다.
사회자는 참가자의 지식도 평가해야 합니다. 그녀는 올바른 순서를 따랐다고 믿습니까? 이 믿음이 정확합니까?

2. 차세대 증후군

복잡성을 인정하지 못하는 한 가지 요인은 우리가 차세대 신드롬이라고 부르는 나중에 고치는 사고방식입니다. 소프트웨어 버그는 "다음 릴리스에서 수정할 것"이기 때문에 문제가 되지 않습니다. 품질과 안전보다 속도를 강조하면 어려운 문제 해결을 미루기가 너무 쉽습니다.

제품 설계 및 개발에 관련된 모든 사람은 다음 릴리스 증후군을 해결해야 합니다. 두 가지 예가 요점을 알려줍니다.

우리는 클라이언트의 의료 추적 소프트웨어에서 심각한 설계 결함을 발견했습니다. 회사는 이러한 문제를 해결하지 않고 소프트웨어를 출시하기로 결정했습니다. 당연하게도 고객들은 불만을 품었습니다.
미국에 본사를 둔 대형 신용협동조합을 대상으로 사용성 테스트를 진행했습니다. 참가자들은 노련한 금융 고문이었습니다. 테스트 결과 혼란스러운 상태 아이콘, 목적이 불분명한 버튼, 참가자가 중요한 데이터를 표시하지 못하게 하는 거의 숨겨진 링크를 비롯한 심각한 디자인 결함이 드러났습니다. 사용자가 그것을 보지 못한다면 그것은 거기에 있지 않다는 것을 기억하십시오. 결과를 보고했을 때 응답은 "다음 릴리스에서 수정하겠습니다."였습니다. 예상대로 웹 응용 프로그램은 잘 수신되지 않았습니다. 사용자의 응답은 다음과 같습니다. "변경할 생각이 없다면 왜 우리에게 앱 검토를 요청했습니까?"

해결 방법: Fix-It-Next-Time 사고 방식을 거부하십시오.

해결책은 지금 심각한 설계 문제를 해결하는 것입니다. 간단하게 들립니다. 그러나 결정권자들이 확고한 "나중에 고치기" 사고방식을 바꾸도록 어떻게 설득할 수 있습니까?

핵심은 성취에 대한 대화를 제품 제공에서 창출된 가치로 옮기는 것입니다. 예를 들어, 사용자 연구를 기반으로 디자인을 수정하는 데 시간이 걸리는 팀은 더 나은 고객 반응을 볼 수 있고 시간이 지남에 따라 고객 충성도가 증가할 수 있습니다.

의사 결정자에게 사용자 연구와 매출 증가, 긍정적인 고객 경험 간의 직접적인 연관성을 보여주기 위해 정량적 데이터를 사용하여 사례를 강화합니다.

데이터를 사용하여 연구 및 설계 개선 사항을 특정 비즈니스 목표에 연결(큰 미리보기)

가치를 재정의하는 것은 실제로 고객과 회사의 장기적 이익에 더 나은 서비스를 제공하는 새로운 우선 순위를 설정하기 때문에 프로세스 개선입니다. McKinsey는 Business Value of Design에서 다음과 같이 보고합니다. 물리적, 디지털 및 서비스 디자인 간의 내부 장벽을 허물고 있습니다."

3. 디자인 반복을 위한 불충분한 시간

다음 릴리스 증후군과 관련하여 연구 결과 또는 변화하는 비즈니스 요구 사항을 기반으로 디자인을 반복하기에는 시간이 충분하지 않습니다. "우리는 그럴 시간이 없다"는 개발자와 제품 소유자의 공통된 후렴구입니다. 애자일 환경에서 작업하는 디자이너는 개발 팀을 "지키지 않도록" 해야 한다는 압박을 자주 받습니다.

개발 속도가 빨라지고 소프트웨어가 출시됩니다. 우리는 모두 혼란스러운 전화 앱, 투박한 의료 기록 소프트웨어, 위에서 언급한 재정 고문을 위한 번거로운 사용자 인터페이스에 이르기까지 그 결과를 보았습니다.

솔루션: 디자인 스파이크

하나의 솔루션은 코딩 세계에서 나옵니다. Damon Dimmick은 "큰 그림 UX를 애자일 개발에 적용"이라는 기사에서 "디자이너가 복잡한 UX 문제에 집중할 수 있는 시간의 거품"인 디자인 스파이크에 대한 아이디어를 제공합니다. 일시적으로 일반 스프린트를 대신하여 스크럼 프레임워크에 맞습니다.

설계 스파이크는 다음과 같은 몇 가지 이점을 제공합니다.

이를 통해 UX 팀은 전체론적 문제에 집중하고 단일 스프린트 내에서 때때로 강조되는 세부적인 디자인 문제에 얽매이는 것을 피할 수 있습니다.
복잡한 UX 질문을 높은 수준에서 탐색할 수 있는 기회를 제공합니다. 필요한 경우 UX 디자인 팀은 더 큰 UX 문제를 해결하기 위해 언제든지 디자인 중심적 사고에 참여할 수 있습니다.
디자인 스파이크를 채택함으로써 UX 팀은 애자일 프로세스에서 개발 팀이 사용하는 것과 동일한 유연성을 활용하고 표준 스크럼 스프린트에 항상 맞지 않는 디자인 문제에 집중하는 데 필요한 시간을 할애할 수 있습니다.
디자인 결정에 영향을 받지 않을 것 같은 개발을 진행할 수 있습니다.

당연히, 디자인 반복은 종종 사이트, 앱 또는 소프트웨어 제품에 대한 코드의 특정 부분에 영향을 미칩니다. 이러한 이유로 디자인 스파이크 동안 디자인 스파이크의 영향을 받을 가능성이 있는 코드는 앞으로 나아갈 수 없습니다. 그러나 Dimmick이 분명히 말했듯이 이 "지연"은 재작업을 피함으로써 시간을 절약할 수 있습니다. 지금 코드를 작성하고 팀이 수정된 디자인에 동의한 후 몇 주 후에 다시 작성하는 것은 의미가 없습니다. 간단히 말해서 일부 코딩을 연기하면 실제로 시간과 예산을 절약할 수 있습니다.

4. 공급업체에 지나치게 의존

복잡성을 해결하고, 다음 릴리스 증후군에 저항하고, 반복할 시간을 허용하는 것은 효과적인 디자인 프로세스에 필수적입니다. 많은 회사에서 또 다른 고려 사항은 소프트웨어 공급업체와의 관계입니다. 이러한 공급업체는 개발에서 중요하고 심지어 중요한 역할을 합니다. 그러나 그들에게 너무 많은 레버리지를 부여하면 자신의 제품을 제어하기가 어렵습니다.

물론 우리는 동료와 공급업체를 존중하고 합리적인 요구를 해야 합니다. 그러나 그렇다고 해서 대형 금융 회사에서 재직하는 동안 발생한 모든 레버리지를 포기해야 한다는 의미는 아닙니다.

이 회사에서 UX 디자이너로 일하면서 종종 다음과 같은 역학을 접했습니다.

매니저 : “에릭, 우리가 사려고 하는 이 클레임 소프트웨어를 평가할 수 있습니까? 우리는 그것이 의도한 대로 작동하는지 확인하고 싶을 뿐입니다.”

나 : "네, 예비 조사 결과를 이번주 말까지 보내드리겠습니다."

매니저 : "훌륭합니다"

다음 주:

매니저 : “리뷰 감사합니다. 기존 청구에 대한 번호를 찾기 어려움, 읽기 어려운 텍스트가 너무 많은 화면, 새 청구를 처리할 때 이전 화면으로 돌아가는 어려움의 세 가지 심각한 문제를 발견한 것으로 나타났습니다. 그것은 우려스럽다. 이러한 문제가 생산성을 저해할 것이라고 생각하십니까?”

나 : “예, 이러한 문제로 인해 클레임 센터에서 스트레스와 처리 시간이 증가할 것이라고 생각합니다. Janet의 팀과 함께 했던 이전 작업에서 클레임 센터 담당자가 이미 높은 스트레스를 받고 있음을 보여주었기 때문에 상당히 걱정스럽습니다.”

매니저 : “알아서 정말 다행입니다. 방금 수표를 보냈습니다. 문제가 배송되기 전에 공급업체에 문제를 해결해 달라고 요청하겠습니다.”

나 (속으로 비명을 지르며): "Nooooooooooooo!"

이 선의의 관리자는 정확히 잘못된 일을 했습니다. 그는 수표를 보낸 후 변경을 요청했습니다. 공급업체가 요청한 변경 사항을 적용하지 않은 것은 놀라운 일이 아닙니다. 왜 그럴까요? 그들은 돈을 가지고 있었다.

이 시나리오는 그 회사에서 반복적으로 발생했을 뿐만 아니라 UX 경력을 통해 목격했습니다.

해결책

해결책은 분명합니다. 공급업체 제품이 고객 및 비즈니스 요구 사항을 충족하지 않고 요청한 변경 사항이 범위 내에 있는 경우 공급업체가 변경할 때까지 비용을 지불하지 마십시오. 정말 간단합니다.

결론

이 글에서 우리는 품질 설계 및 해당 솔루션에 대한 4가지 일반적인 장벽을 식별했습니다.

복잡한 규정 및 표준
해결책은 연구 및 반복 설계를 위한 현실적인 일정과 충분한 예산을 고안하여 복잡성을 인정하고 해결하는 것입니다.
나중에 수정하겠다는 약속과 함께 버그가 있는 소프트웨어 배송
해결책은 다음 릴리스 증후군을 피하고 심각한 문제를 지금 해결하는 것입니다. 조직 내 가치의 의미를 재정의하여 의사 결정자를 설득하십시오.
설계 반복을 위한 시간 부족
해결책은 애자일 개발 프로세스에 설계 스파이크를 포함하는 것입니다. 이러한 시간의 거품은 일시적으로 스프린트를 대신하여 디자이너가 복잡한 UX 문제에 집중할 수 있도록 합니다.
공급업체에 지나치게 의존
솔루션은 변경 사항이 원래 프로젝트 범위 내에 있는 한 공급업체가 요청한 변경 사항을 만들 때까지 최종 지불을 보류하여 레버리지를 유지하는 것입니다.

네 번째 솔루션은 간단합니다. 처음 세 가지는 쉽지는 않지만 기존 설계 프로세스에 직접 적용할 수 있기 때문에 구체적입니다. 그들의 구현에는 대규모 개편이나 수백만 달러가 필요하지 않습니다. 더 나은 경험을 제공하기 위한 노력이 필요합니다.