Design System의 가치 : 디자인과 사용성이 복잡한 시스템에 미치는 영향

전통적인 소프트웨어 설계 방법에는 문제가 있습니다. 유용하지도 않고 직관적이지도 않지만 사용성 지침을 충족하는 시스템을 만드는 것은 전적으로 가능합니다. 일반적으로 새로운 기능 목록, 기능 업데이트 및 구성 요소 희망 목록은 주요 이해 관계자 및 대표 사용자로부터 수집되어 요구 사항을 조정하고 사용자에게 적합한 통합 시스템을 만들기 위해 최선을 다하는 재능 있는 개발 팀에 전달됩니다.

이것이 끔찍한 사용자 경험을 가진 소프트웨어가 만들어지는 방식입니다.

이 백서에서는 다른 접근 방식을 살펴보겠습니다. 하나는 위시 리스트가 아닌 사용자 요구에 기반한 일련의 요구 사항에서 시작하고 사용성 분석가와 디자인 전문가가 조기에 협력하여 신속하고 저렴한 모델을 만드는 것입니다. 최종 시스템. 이러한 신속한 "종이" 프로토타이핑 프로세스에는 코드가 필요하지 않으므로 선을 지우는 것만큼 수정하기 쉽습니다. 또한 프로토타입을 사용자 앞에 놓고 요구 사항 수집 중에 생성된 개념적 아이디어와 화면 수준 사용성을 테스트하여 구현된 최종 제품이 사용 가능하고 유용할지 확인할 수 있는 기회도 제공합니다.

자동차, 주택 및 소프트웨어

자동차는 1800년대 후반부터 존재해왔습니다. 그들은 원시적인 내연 기관으로 구동되는 기계화된 마차로 시작되었습니다. 모든 면에서 초기 자동차는 불편하고 신뢰할 수 없으며 위험했습니다. 그러나 그들은 당시의 성숙한 교통수단으로는 할 수 없는 일을 해냈습니다. 그들은 더 멀리, 더 빠르게 갈 수 있었습니다. 그리고 소유주/운영자가 자신의 기계공이자 부품 제작사 역할을 해야 했지만 그것만으로도 충분했습니다.

집은 자동차보다 꽤 오래전부터 존재해 왔습니다. 초기에는 외부 환경으로부터 보호받을 수 있는 공간을 제공하는 것이 가치 있는 주택을 선택하는 데 결정적인 요인이었습니다. 비만 안오고 바람만 불면 충분했어요.

소프트웨어, 특히 엔터프라이즈 소프트웨어는 세 가지 중 가장 최신입니다. 소프트웨어는 자동차나 집과 같은 물리적 대상이 아니기 때문에 특정 형태나 크기에 얽매이지 않는다는 점에서 흥미롭습니다. 그러나 자동차나 주택과 마찬가지로 원시 소프트웨어(그리고 오늘날 인간 상호 작용이 필요한 거의 모든 소프트웨어는 원시 소프트웨어라고 주장하고 싶습니다)가 인상적인 기능 목록을 포함하고 있다면 수용 가능한 것으로 간주됩니다. 누구나 사용할 수 있는지 여부에 관계없이 소프트웨어가 이전 버전(또는 경쟁사 소프트웨어)보다 더 많은 기능을 수행하면 충분합니다.

이 세 가지의 진화를 추적해 보면 분명해지는 것은 처음에는 복잡한 시스템이 공학적 사건으로 존재하기 시작한다는 것입니다. 그들이 일하는 것만으로도 충분합니다. 시간이 지남에 따라 복잡한 시스템은 엔지니어링에서 개인용으로 진화합니다. 이것은 확실히 자동차와 주택에 해당됩니다. 그러나 소프트웨어는 아직 존재하지 않습니다. 그림 1에서 볼 수 있듯이 Don Norman은 1999년 저서 The Invisible Computer에서 이 아이디어를 언급했습니다. 비록 그는 소프트웨어보다는 하드웨어에 관해 이야기하고 있었습니다(Norman, D., 1999: The Invisible Computer 참조).

소프트웨어는 제품 진화의 관점에서 볼 때 젊은 제품입니다. 이것이 왜 여전히 사용하기 어려운지에 대한 많은 부분을 설명하기에 충분할 수 있지만, 이를 받아들일 이유는 아닙니다. 모든 소프트웨어는 수많은 선의의 결정의 결과입니다. 그것은 바로 그것이도록 설계되었습니다. 그것이 문제이다. 모든 제품이 잘 디자인된 것은 아닙니다.

유용성만으로는 충분하지 않습니까?

기업에서는 문제가 있는 화면을 사용성 전문가에게 전달하여 잘못된 디자인 문제를 해결하려고 합니다. 엄격한 테스트와 오랜 지침 준수를 통해 전체적인 사용성은 확실히 향상될 수 있습니다. 그러나 복잡한 시스템을 다룰 때 시스템을 설계한 후 사용성을 높이는 것은 질병보다는 증상을 치료하는 것과 비슷합니다. 이를 염두에 두고 다음 섹션에서는 이 섹션을 시작하는 질문에 대한 답변을 제공합니다.

유용성만으로는 충분하지 않습니다

새로운 시스템 설계에 접근하는 방법에는 여러 가지가 있습니다. 첫 번째에서는 주요 이해관계자와 대표 사용자로부터 새로운 기능, 기능 업데이트 및 구성 요소 희망 목록이 수집됩니다. 그런 다음 이 목록은 요구 사항을 조정하고 사용자에게 적합한 통합 시스템을 만들기 위해 최선을 다하는 재능 있는 개발 팀에게 전달됩니다. 이것이 바로 끔찍한 소프트웨어가 만들어지는 방식입니다. 왜? 개발자는 사용성 분석가나 디자이너가 아니며 두 가지 작업을 모두 수행하도록 요청받고 있기 때문입니다.

두 번째로, 사용자 연구 책임자는 주요 이해관계자 및 대표 사용자와 협력하여 두 그룹의 요구 사항과 요구 사항을 결정합니다. 이로 인해 보다 적절한 요구사항 세트가 생성됩니다.

이것은 엄청나게 강력합니다. 사용자나 이해관계자 모두 일반적으로 즉각적인 위시리스트 이상을 볼 수 없으며 사용자에게 원하는 것을 제공하는 점진적인 개선과 사용자에게 필요한 것을 제공하는 혁신 간의 차이는 숙련된 요구 사항 도출에 있습니다. 이 새로운 시스템은 뛰어난 요구 사항을 기반으로 하지만 화면 레이아웃, 상호 작용 모델 및 데이터 시각화(즉, 디자인 문제)와 같은 문제는 여전히 핵심 역량이 디자인이 아닌 역할에 의해 결정되고 있습니다.

세 번째에서는 사용자 연구 책임자와 디자인 전문가가 협업하여 요구 사항을 수집하고 사용자가 꿈도 꾸지 못했던 방식으로 작업을 완료할 수 있도록 혁신적인 지원 방법을 만듭니다. 너무 유토피아적인 것 같나요? 이는 사실이며 이해관계자, 사용자 또는 팀 구성원으로서 이러한 "디자인 프로세스"에 참여할 수 있다면 이는 아름다운 일입니다. Indigo.Design과 같은 최신 디자인-코드 시스템은 진정한 UX 디자인 개발 협업을 촉진하는 데에도 도움이 됩니다.

사용자 조사 담당자가 최종 사용자 자신도 자신에게 필요한 것이 무엇인지 항상 알지 못한다는 사실을 발견하는 것은 드문 일이 아닙니다.

적절한 사례는 다음과 같습니다. 많은 금융 회사의 거래 현장에서는 기본적으로 거래자의 머리를 감싸는 각도로 단일 받침대에 4개의 모니터가 2개씩 장착된 거래자의 워크스테이션을 보는 것이 드문 일이 아닙니다. 모니터에서는 일반적으로 스프레드시트, 선 그래프, 스크롤, 깜박임 및 색상이 지정된 데이터 포인트가 복잡하게 혼합된 것을 볼 수 있습니다. 거래자는 데이터 표시 방법을 크게 제어할 수 없으며 단순히 다른 소스에서 데이터를 스트리밍하고 있다고 가정할 수 있습니다. 그러나 한 금융회사의 트레이더에게 “데이터가 화면에 표시되는 방식을 누가 통제하나요?”라고 묻자 그 트레이더는 “우리는 그렇습니다. 우리는 데이터와 데이터 표시 방법을 완벽하게 제어할 수 있습니다.”

중요한 정보가 강조 표시되거나 "이것들이 하루 종일 깜박이지 않도록 하세요"와 같은 간단한 정보를 보고 싶다고 말할 것이라고 생각할 수도 있습니다. 그러나 이 거래자가 자신의 업무를 더 쉽게 만드는 데 도움이 되는 것이 무엇인지 물었을 때, 그는 자신이 가진 프로세서가 4개의 모니터만 실행할 수 있기 때문에 더 빠른 프로세서를 원한다고 말했습니다. 더 빠른 프로세서를 사용하면 6개를 가질 수 있습니다.”

그 대답을 생각해보면 사용자 관점의 한계를 깨닫게 됩니다. 그것이 그들의 성과를 향상시켰을까요? 경험이 많은 트레이더의 경우 아마도 어느 정도 점진적인 개선이 이루어졌을 것입니다. 하지만 그것은 그들에게 필요한 것이 아니었습니다.

사용자 조사: 사용자에게 필요한 것이 무엇인지 이해하기

사용자의 작업을 관찰하면 사용자에게 필요한 것이 무엇인지 분명해집니다. 왜 특정 조치를 취했는지, 왜 특정 순서에 따라 조치를 취했는지 설명하도록 요청하면 명확해집니다. 사용자가 달성하려는 것이 무엇인지 이해하면 혁신이 가능해집니다. 한 작업에서 거래자는 특정 금융 상품을 매수할지 아니면 매도할지 결정하려고 했습니다. 이를 위해 그는 특정 통화가 서로 어떻게 거래되고 있는지, 통화 간의 변화율이 시간이 지남에 따라 원하는 방향으로 추세를 이루고 있는지, 그리고 이것이 통화 간의 역사적 변화율과 어떻게 비교되는지에 관심이 있었습니다. 변화율, 변화율의 변화율, 변화율의 과거 비교 등이 있습니다. 이 정보를 표현하는 방법에는 여러 가지가 있습니다. 한 가지 방법에는 모니터 6개 상당의 스프레드시트와 선형 차트가 포함됩니다. 또는 디자이너는 변화율 데이터를 한 눈에 시각화하는 3가지 새로운 방법을 만들 수 있습니다(왜냐하면 디자이너는 이것이 매우 능숙하기 때문입니다). 사용자는 이러한 용어로 생각할 수 없습니다. 솔직히 대부분의 유용성 분석가도 마찬가지입니다.

나는 사용성과 디자인 전문가 간의 협업에 의존하는 디자인 프로세스의 구현을 통해 더욱 진화된 소프트웨어의 생성이 가능하다는 사례를 제시했습니다. 소프트웨어 개발과 관련된 위험도 줄일 수 있다면 어떨까요? 위험으로 인해 일반적으로 비용이 발생하므로 사용자 경험과 디자인을 통해 소프트웨어 개발 비용을 줄일 수 있다면 어떨까요? 소프트웨어 개발의 가장 두드러진 두 가지 모델을 살펴보기 전에 또 다른 일화를 고려하는 것이 유용할 것입니다.

두 해리의 이야기 - 또는 최종 결과가 기대를 충족시키지 못할 수 있는 이유

소프트웨어 개발의 어려움을 더 잘 설명하기 위해 해리포터 책과 사랑에 빠진 어린 소년의 경험과 책을 큰 화면에서 보았을 때의 반응을 고려해 보겠습니다. 첫 번째 해리포터 영화가 개봉되었을 때, 이 소년들은 이미 첫 세 권의 책을 읽었고 영화를 보고 싶어했습니다. 그러나 줄을 서서 티켓당 10달러를 지불하고 탄산음료, 사탕, 팝콘을 구입하고 90분 동안 해리포터의 모험을 지켜본 후 흥미로운 일이 일어났습니다. 그들은 그것을 좋아하지 않았습니다.

이사가 마음에 들지 않는 이유를 물었을 때 그들은 책과 같지 않다고 말했습니다. 아무래도 각본을 쓴 사람도, 감독도, 배우도, 아이들이 머릿속으로 만들어낸 '영화'와는 비교할 수 없을 것 같았다. 그래서 영화는 실망스러웠다.

이것이 바로 전통적인 소프트웨어 개발 방식의 문제입니다. 코딩은 프로젝트에 참여한 모든 사람이 모든 사람의 욕구, 요구 및 욕구의 총합을 포함하는 산문 기반 요구 사항 문서가 말한 욕구, 요구 및 욕구를 올바르게 포착한다는 데 동의할 때 시작됩니다. 이는 소프트웨어를 생성할 수 있는 세 가지 방법 중 첫 번째입니다(앞서 설명). 이해관계자(및 사용자)는 사용 가능한 시스템을 만들기 위해 개발자에게 의존할 뿐만 아니라, 이미 마음속에 만든 시스템과 일치하는 시스템을 만들기 위해 개발자에게 의존하고 있습니다! 필연적으로 몇 달 후 막이 걷히고 알파 릴리스가 공개되었을 때 팀은 자신이 구상한 시스템을 찾기 위해 고군분투합니다. 이어 "내가 기대했던 게 아니다"라는 변종이 이어진다. 내 영화 사례와 이 소프트웨어 개발 사례의 유일한 실제 차이점은 소년의 아버지가 40달러만 썼다는 것입니다. 소프트웨어 프로젝트는 커피에 그보다 더 많은 돈을 썼습니다.

오늘날 두 가지 주요 소프트웨어 설계 프로세스는 Waterfall과 Agile입니다. 각 모델은 소프트웨어가 수행해야 하는 작업을 설명하는 요구 사항에 대한 산문 기반 설명으로 시작됩니다. 각각은 "위험 가능성"(내 용어) 0으로 시작합니다. 이는 개발 단계 초기에는 모두가 자신감을 갖고 행복하다는 뜻입니다. 나쁜 일은 일어나지 않았으며 모두가 최종 제품에 대한 공통 비전을 공유한다고 믿습니다. 그런 다음 개발이 시작되고 위험이 증가하기 시작합니다. 왜? 왜냐하면 제품의 최종 형태가 팀의 각 구성원이 갖고 있는 비전에서 벗어나게 만드는 결정이 내려지기 때문입니다. 개발팀의 잘못인가요? 절대적으로하지. 그들은 자신이 좋아하는 일, 즉 코드를 시도하면서 디자인 결정을 내려야 하는 불편한 위치에 놓였습니다. 그래서 시간이 지날수록 위험은 점점 더 커집니다.

그림 2와 3에서 볼 수 있듯이 이는 프로젝트가 Waterfall 방법론을 따르든 Agile 방법론을 따르든 상관없이 발생합니다. 폭포수는 빌드가 완료될 때까지 결과를 사용할 수 없기 때문에 둘 중 더 문제가 많습니다. Agile은 빌드를 짧은 스프린트로 나누어 이 문제를 해결하려고 합니다. 그러나 이는 분리된 기능 부분에 대한 보기만 허용하므로 팀은 해당 기능이 더 큰 전체 내에서 어떻게 작동할지 상상해야 합니다.

두 프로세스 모두 개발 프로세스가 완료될 때까지 팀이 최종 시스템의 모습, 작동 방식, 다른 시스템 및 기타 기능과 상호 작용하는 방식을 볼 수 없습니다. 둘 다 초기 개발 비용이 높습니다. 이미 코드에 구현된 디자인 결정을 변경하는 데는 훨씬 더 많은 비용이 듭니다. 사용자가 그러한 시스템을 받아들일 가능성은 적습니다.

반면에 그림 4에 표시된 디자인 프로세스는 사용성 분석가와 디자인 전문가의 기술을 조정하고 이 문제를 해결합니다.

더 나은 요구 사항 세트(Waterfall 또는 Agile 방법에 대한 입력이 될 수 있음)를 만드는 것 외에도 유용성 및 디자인 전문가는 최종 시스템의 빠르고 저렴한 모델도 만듭니다. 일련의 빠른 스케치, 와이어프레임 및 화면 모형을 통해 팀은 모든 사람이 모여서 질문하고 동의할 수 있는 전체 시스템에 대한 보기를 제공할 수 있습니다. 이러한 신속한 프로토타이핑 과정에는 코드가 필요하지 않으므로 선을 지우는 것만큼 수정하기 쉽습니다. 또한 프로토타입을 사용자 앞에 놓고 요구 사항 수집 중에 생성된 개념적 아이디어와 화면 수준 사용성을 테스트할 수 있는 기회도 제공합니다. 버그가 해결되고 모든 사람이 최종 제품에 대한 공통된 이해를 공유하면 개발 팀이 작업을 시작할 수 있습니다. 그리고 요구사항 외에도 해당 요구사항의 최종 시각적 형태를 구체적으로 보여주는 디자인도 있습니다. 따라서 코딩이 시작되기 전에 개발 위험이 최소화되고 개발 프로세스 전반에 걸쳐 상대적으로 일정하게 유지됩니다.

좋은 디자인은 요구 사항을 발견하고 정의하는 연구 기반의 반복적인 프로세스입니다. 이를 통해 사용자가 원하는 것 외에도 달성해야 하는 것이 무엇인지 이해할 수 있습니다. 이를 통해 조기 합의, 수정 및 사용자 테스트가 가능합니다. 그것은 빠릅니다. 그것은 저렴합니다. 그것은 사용 가능하고 직관적이며 아름답고 영감을 줍니다. 위험을 줄입니다. 이는 점진적인 개선보다는 혁신을 제공합니다. 이는 기존 소프트웨어 개발 방법에 적합합니다. 확장 가능하고 지원 가능합니다.

소프트웨어는 무한히 변형 가능한 제품입니다. 그것은 절대적으로 무엇이든 성형될 수 있습니다. 원자재 가용성, 운송 물류 또는 공장 지원에 대해 걱정할 필요가 없습니다. 그것이 설계된 그대로 될 것입니다. 필요한 것은 그것을 훌륭하게 만들고자 하는 열망과 과정뿐입니다.

자원

노먼, D. (1999). 보이지 않는 컴퓨터: 좋은 제품이 실패할 수 있는 이유, 개인용 컴퓨터는 너무 복잡하고 정보 기기가 해결책인 이유. MIT 출판사.