Designing a data-heavy enterprise application — Part 1

데이터 집약적인 기업용 애플리케이션을 설계하고 검토하는 데 수년을 소비하면서 저는 주류 소비자 제품과 비교하여 기업용 제품을 설계할 때 고려해야 할 몇 가지 구체적인 지침이 있다는 것을 깨달았습니다. 기술적 설계 지침을 의미하는 것은 아니지만 기술적 인 사람들에게는 흥미로울 수 있는 약간의 중복이 있을 수 있습니다. 하지만 이미 엔터프라이즈 애플리케이션을 작업하고 있는 제품 디자이너이거나???? 엔터프라이즈 팀에 합류할 생각을 하고 있다면 이 가이드의 지침을 참고하면 유용할 것입니다. 맥락 이해 그렇다면... 엔터프라이즈 애플리케이션이란 정확히 무엇이며, 왜 이를 특별하게 설계하고, 정보의 양이 왜 그렇게 중요한가요? 우선 Wikipedia에서는 엔터프라이즈 애플리케이션을 개인 사용자의 요구 사항이 아닌 조직의 요구 사항을 충족하는 데 사용되는 컴퓨터 소프트웨어 로 정의합니다 . 당연할 수도 있지만 이는 실제로 조직의 요구 사항이 개별 사용자의 요구 사항(예: 보안, 규정 준수, 비용 제어)과 거의 공통점이 없는 여러 업종에 걸쳐 쉽게 확장될 수 있으므로 기업 애플리케이션과 소비자 애플리케이션 간의 주요 차이점 중 하나입니다. , 확장성 - 여러 부서에 걸쳐, 기존 서비스와의 통합 등 목록은 계속됩니다). 사용했거나 들어본 적이 있는 엔터프라이즈 앱: Hubspot, mixpanel, Salesforce, Zendesk, Stripe, Intuit, Jira, aws 사용했거나 들어본 적이 있는 기업용 앱 또 다른 주요 차이점은 작업하도록 설계된 정보의 양입니다. 경험상 대부분의 기업 제품은 엄청난 양의 데이터를 수집 및/또는 관리합니다. 매년 수백만 건의 입사 지원서를 처리하는 HRMS(예: McDonald's는 전 세계적으로 약 2천만 건의 입사 지원서를 받고 연간 약 200만 건의 고용을 창출함) 또는 매달 수십억 개의 이벤트를 분석하는 ITMS(예: Microsoft는 평균 6,000억 개의 보안 이벤트를 처리함)를 생각해 보십시오. 매월) 등이 있습니다. 이것만으로도 애플리케이션이 속한 전체 생태계의 성능을 고려해야 하기 때문에 설계해야 하는 복잡성 수준이 증가합니다 . "솔루션" 영역으로 넘어가기 전에 엔터프라이즈 제품과 B2C 제품 간의 몇 가지 (관련된) 차이점을 더 강조해 보겠습니다. 걱정하지 마세요. 지금은 이 주제를 자세히 다루지는 않습니다 ????, 하지만 " 구체적인 내용”을 참조하세요. 더 자세한 내용에 관심이 있으신 경우 유용한 리소스를 마지막에 첨부해 두었습니다. 소비재 대부분의 소비자 제품은 한 사용자 그룹의 특정 문제를 해결하고 있으며 주로 유지, 참여, 충성도 및 전환에 중점을 둡니다. 주류 소비자 제품에 대한 일반적인 사용자 여정은 진입점이 제한된 몇 가지 선형 단계와 몇 가지 선택적 사이드 퀘스트(예: 결제하는 동안 계정 세부 정보 설정)로 구성됩니다. 마지막으로, 소비자 제품은 대부분의 경우 (매우) 개인적인 맥락에서 사용됩니다. 예를 들어 자신의 스마트폰을 사용하여 Uber를 찾거나, 친구를 만나러 가는 길에, 비용에 대해 스스로 결정을 내리는 경우 등이 있습니다. 차량 비용을 기꺼이 지불할 의향이 있습니다(자, Uber Black을 이용하세요. 그럴 자격이 있습니다 ????). 해당 응용 프로그램을 바로 사용하고 싶지만 언제든지 따로 보관하거나 다른 것으로 교체할 수도 있습니다. 엔터프라이즈 제품 반면에 엔터프라이즈 제품은 다양한 권한, 책임 및 전문 지식 수준을 갖춘 다양한 사용자 역할을 위한 "일률적인" 솔루션입니다. 이들은 주로 효율성, 내결함성 및 반복적인 사용에 중점을 둡니다. 즉, 직원들이 (반복적인) 작업을 가능한 한 빠르고 저렴하며 오류 없이 완료하도록 돕는 것이 목적입니다. 단일 사용자 여정에는 비선형 작업과 다양한 진입점이 있는 2~3개 이상의 도구에 분산된 100개가 넘는 화면이 쉽게 포함될 수 있습니다. 기업 제품이 사용되는 환경은 종종 복잡하고 열린 공간에서 직원이 사용하는 오래된 하드웨어부터 보정되지 않은 빔머에 이르기까지 고도로 규제되고(예: 은행 및 정부 기관) 스트레스가 많고 비인격적일 수 있습니다. 의사결정실 벽 전체를 덮고 있는 낮은 대비 또는 고품질 디스플레이 매트릭스. 마지막 주요 차이점으로 이 비교를 마무리하겠습니다. B2C 사용자와 달리 기업 사용자는 특정 제품을 사용할지 여부를 선택할 여유가 없습니다. 회사가 사용하기로 동의한 제품을 사용하고 제품을 마무리해야 합니다. 마감일 내에 할당된 작업입니다. 이제 기업 사용자에 대한 공감을 구축했으므로 이에 대해 자세히 살펴보고 그들의 삶을 어떻게 더 쉽게 만들 수 있는지 살펴보겠습니다. 아니면 적어도 시도해 보세요 ???? 데이터 로드 중 엔터프라이즈 애플리케이션에서 수집, 처리 및 관리되는 대량의 데이터를 고려할 때 꽤 많은 문제에 직면하게 될 가능성이 높습니다. 그 중 일부를 극복할 수 있는 방법은 다음과 같습니다. 의도적으로 축소 대규모의 구조화되지 않은 데이터 세트를 로드하는 것은 일반적으로 어떤 목적에도 도움이 되지 않습니다. 즉, 사용자에게 도움이 되지 않으며 확실히 시스템 성능에도 도움이 되지 않습니다. 또한 로드하려는 데이터가 페이지 매김 또는 가상화(예: IT 인프라 맵)를 지원하지 않는 경우 엔지니어링 팀이 생태계의 나머지 부분을 보호하기 위해 설정한 엄격한 제한에 부딪힐 가능성이 높습니다. 이를 극복하려면 각 사용자 프로필에 대해 맞춤형 데이터 세분화 또는 안내된 사용자 흐름을 사용하십시오  . 암시적 필터로 사용할 가장 관련성이 높거나 가장 많이 사용되는 기준을 생각하고 이를 기반으로 구축하십시오. 예를 들어, 시스템의 모든 지원서 목록을 표시하는 대신 사용자에게 관심 있는 지역과 부서에 대한 사전 필터링을 요청하는 것부터 시작하거나 새로 수신된 애플리케이션은 기본 보기로 사용자의 주의를 끌며 거기에서 가져옵니다. 가능하다면 “분할하여 정복하라” 또한 전체 화면을 한 번에 로드하지 않도록 해야 합니다. 이렇게 하면 사용자의 대기 시간이 길어질 수 있습니다. 대신, 화면을 여러 영역이나 섹션으로 나눌 수 있으며 각 영역은 독립적인 로딩 상태를 갖습니다. 이렇게 하면 특정 섹션의 데이터 로드 프로세스가 실패하더라도 다른 영역에는 영향을 미치지 않으므로 사용자는 나머지 인터페이스를 계속 사용하고 해당 특정 문제를 조사하거나 보고할 수 있습니다. 예를 들어, 전체 페이지에 대한 전반적인 로드 상태를 사용하여 전체 대시보드를 한 번에 로드하는 대신 각 위젯에 대한 개별 로드 상태로 나눌 수 있습니다(대부분 어쨌든 서로 다른 API를 사용하고 있을 가능성이 높음). 기대치를 관리하라 특정 작업을 로드하거나 처리하는 데 짧은 시간이 걸릴 것으로 예상되는 경우 (예: 항목 검색) 합리적인 시간 초과 제한을 설정하는 것이 좋습니다. 작업이 지정된 시간 내에 로드 또는 처리를 완료하지 않은 경우 부분 결과(즉, 발견된 항목)를 표시하고 요청한 작업이 예상보다 오래 걸렸음을 사용자에게 알리는 것이 도움이 될 수 있습니다. 한편으로는 부분적인 결과만으로도 사용자가 여행을 계속할 수 있을 만큼 충분할 수 있습니다. 또한 이는 보고 및/또는 조사할 가치가 있는 시스템 내 특정 기술 문제(예: 응답하지 않는 API, 잘못된 통합, 대역폭 할당 등)를 식별하는 데 도움이 될 수도 있습니다. 특정 작업을 로드하거나 처리하는 데 오랜 시간이 걸릴 것으로 예상되는 경우 (예: 보고서 생성) 예상 대기 시간을 사용자에게 미리 알려주는 것이 좋습니다. 이는 정확할 필요는 없습니다(예: "몇 분 정도 걸릴 수 있습니다"). 사용자가 해당 작업을 실행하기로 결정한 경우 작업이 완료될 때까지 해당 페이지에서 기다리도록 강요해서는 안 됩니다. 전역 백그라운드 프로세스 표시기를 사용하세요(애플리케이션 어디에서나 쉽게 볼 수 있고 액세스할 수 있는지 확인하세요). 사용자에게 보류 중인 모든 작업에 대한 정보를 제공하고 그 중 하나가 로드 또는 처리를 완료하면 알림을 보냅니다(브라우저 다운로드 관리자와 유사). 방해하지 마세요… 효율성의 관점에서 볼 때, 현재 작업에 관계없이 엔터프라이즈 사용자를 로딩 상태에 노출시키는 것은 실제로 이상적이지 않습니다. 긴급한 문제를 해결하려고 할 때 모든 시스템 응답을 기다립니다. 이를 우회하고 유동적인 작업 흐름을 만들려면 모든 단계에서 상황에 맞는 접근 방식을 사용하고 스스로에게 물어보세요. 이 작업이 사용자가 기다려야 하는 작업인가요? 대답이 부정적인 경우(예: 레코드 추가/삭제 또는 메시지 전송으로 인해 사용자가 다음 작업으로 넘어가기 전에 시스템 응답을 기다리도록 강요해서는 안 됨) 낙관적 UI 원칙 1을 사용하여 사용자의 작업 효율을 높이는 것을 고려하세요. 속도 및 효율성에 대한 인식: 작업의 성공률이 97~99%인 경우 로드/처리 상태를 건너뛰고 최종 결과를 즉시 표시하며 백그라운드에서 작업을 실행하고 오류가 있거나 다른 일이 발생한 경우 사용자에게 알립니다. 잘못된. 자식은 액션 트리거와 액션 확인 사이에 이전에 삽입되었던 로딩 상태를 걷어차고 있습니다. 출처: Denys Mishunov / Smashing Magazine 사용자가 계속 진행하기 전에 작업이 완료될 때까지 기다려야 하는 경우 앞서 설명한 대로 기대치를 관리하고 짧은 대기 시간에 적합한 로드 상태를 선택하세요. 새 콘텐츠가 로드되는 동안 인터페이스를 차단해야 하는 경우 "스켈레톤"을 사용하여 로드되는 콘텐츠나 다른 로딩 애니메이션에 대한 아이디어를 제공하세요. 하지만 일관성을 목표로 하세요. 새 콘텐츠를 비동기적으로 로드하고 사용자가 전체 화면을 가리지 않고 작업을 계속할 수 있도록 하려면 눈에 보이는 곳에 로딩 바를 찾으세요. 오류 처리 나도 알아요, 종종 이것이 우리의 "할 일" 목록의 마지막에 속하거나, 이것을 완전히 건너뛰고 엔지니어링 팀에 의존하여 처리하는 경우가 있다는 걸 알아요???? 하지만 우리가 염두에 둔다면 이렇게 될 필요는 없습니다. 몇 가지 포인터. Jenni Nadler는 좋은 오류 메시지를 만드는 방법에 대해 훌륭하게 설명했습니다²(아래 예 참조). 메시지 뒤의 구조와 추론이 모두 정확합니다. 좋은 오류 메시지의 구조는 무슨 일이 일어났는지 말하고, 확신을 주고, 왜 그런 일이 일어났는지 말하고, 문제를 해결하도록 돕고, 탈출구를 제공하는 것입니다. 출처: Jenni Nadler / Medium 소비자 제품에서는 잘 작동하지만 엔터프라이즈 애플리케이션에서 오류를 처리할 때 모든 것은 사용자의 역할, 권한 및 작업 컨텍스트에 따라 달라집니다. 예를 들어, 사용자에게 처음에 오류를 볼 수 있는 권한이 있습니까? (드문) 사용자가 특정 정보에 대한 액세스만 허용하는 통합 또는 시스템의 일부에 대한 특정 권한을 갖는 경우가 있을 수 있으며, 여기에는 오류가 포함되거나 포함되지 않을 수 있습니다(보안 또는 규정 준수 이유로). 그러나 사용자가 오류를 볼 수 있는 권한이 충분하지 않은 경우에도 오류가 발생했음을 사용자에게 알려야 합니다. 이 경우 의도적으로 일반화해야 합니다. 오류에 대한 세부 정보를 제공하고 싶지 않다면 "뭔가 잘못되었습니다..."가 가장 대표적인 예이지만 상황과 수준에 맞게 반드시 변경해야 합니다. 귀하가 해당 사용자에게 제공할 수 있는 세부정보입니다. 사용자에게 특정 오류를 볼 수 있는 충분한 권한이 있다고 가정하면 해당 오류의 세부 정보 (예: 오류 코드, 서버 응답, 이유 등) 도 볼 수 있습니까 ? 그렇다면 이러한 세부 사항이 어떤 식으로든 그/그녀와 관련이 있습니까 ? 예를 들어 고급 사용자, 관리자 또는 전체 조직(예: IT 운영)에게 오류 코드와 서버 응답을 표시하여 그들이 현재 문제 해결을 시작하거나 적절한 부서에 전달할 수 있도록 할 수 있습니다. , 그러나 이러한 세부 사항으로 초급 사용자나 기술 부서가 아닌 부서의 구성원을 귀찮게 하는 것은 의미가 없습니다. 오류 메시지에 제공하는 작업 및 표시도 동일한 패턴을 따라야 합니다. 즉, 후속 항목을 사용자 프로필 및 해당 권한과 일치시켜야 합니다 . 이전 예를 기반으로 고급 사용자 및 관리자를 위해 오류 유형에 따라 "문제 보고", "시스템 상태 확인" 또는 "문서 보기" 관련 링크를 포함할 수 있습니다. 초급 사용자나 기술 지식이 없는 직원의 경우 위의 Jenni Nadler 의 예에서 볼 수 있듯이 "재시도" / "다시 로드", "관리자에게 문의" / "지원팀에 문의" 등 보다 친숙한 작업을 사용할 수 있습니다. 데이터 표시 “데이터를 어떻게 표시하나요?” 가장 일반적인 질문이어야 하며 일반적으로 "상황에 따라 다릅니다"라는 가장 일반적인 대답이 함께 제공됩니다. 엔터프라이즈 제품의 경우에도 상황은 다르지 않지만 고려해야 할 몇 가지 일반적인 사용 사례를 확실히 고려할 수 있습니다. 데이터 없음 사용자가 처한 상황에 따라 "데이터 없음" 상태로 이어질 수 있는 시나리오가 많이 있습니다. 그럼에도 불구하고 항상 사용자에게 탈출구를 제공하는 것을 목표로 해야 합니다. "데이터 없음" 상태는 조회 프로세스의 결과입니까? 그런 다음 사용자에게 뒤로 돌아가거나 앞으로 이동할 수 있는 바로가기를 제공합니다. 예를 들어, 일치하는 항목이 없는 필터 조합을 사용했을 수 있습니다. 이 경우 마지막으로 적용된 필터를 자동으로 되돌릴 수 있는 "실행 취소" 옵션을 제공하십시오. 또는 사용자가 특정 항목을 검색했지만 키워드의 철자가 틀렸을 수도 있습니다. 이 경우 몇 가지 유사한 대안(soundex 또는 기타 관련 기준을 기반으로)을 제공하고 계속 진행할 수 있도록 하십시오. 예를 들어 사용자에게 항목을 추가할 수 있는 충분한 권한이 있습니까? 그런 다음 그렇게 할 수 있는 추가 옵션을 제공하십시오. 이전 예에 따르면 사용자가 결과가 없는 특정 항목을 검색하는 경우 앞서 언급한 대안을 제공하는 것 외에도 사용자가 검색한 키워드를 사용하여 새 항목을 추가하는 옵션을 제공할 수 있습니다. 마지막으로 "데이터 없음" 상태는 사람이나 시스템 오류의 결과일 수 있습니다. 이 경우 "오류 처리" 지침을 따르십시오. 오류 메시지나 권한 부족을 대신하여 "데이터 없음" 상태를 사용하지 마세요. 후자의 경우는 잠시 후에 처리하겠습니다. 데이터가 너무 적음 (흰색) 우주… 데이터 집약적인 제품의 성배이자 최후의 개척지입니다. 제대로 사용할 수 있는 경우가 너무 드물기 때문에 이해 관계자가 더 많은 요구 사항을 제시하기 전에 첫 번째 아이디어에 뛰어들어 뭔가를 디자인하고 싶은 유혹을 받을 수도 있습니다 ????. 문제는 대상 페르소나가 사용하는 매체나 장치를 고려하여 좋은 솔루션을 제공하는 것입니다. 이 경우 표시할 데이터가 너무 적기 때문에 4K 모니터부터 다중 모니터 설정에 이르기까지 큰 화면 해상도를 주시해야 합니다. 표시해야 하는 콘텐츠 유형에 따라 항상 Fitts의 법칙³을 고려하세요 . "표적을 획득하는 데 걸리는 시간은 목표물까지의 거리와 크기에 따라 달라집니다." 즉, 목표물이 작을수록, 멀리 배치될수록 명중하기가 더 어려워집니다. 예를 들어, 몇 개의 열과 각 행의 상황별 작업이 테이블 오른쪽에 배치된 테이블이 있는 경우 테이블이 전체 너비에 맞게 늘어나면 이러한 작업을 적절하게 사용하는 인체공학에 영향을 미치게 됩니다. 뷰포트. 전체 화면에 걸쳐 펼쳐진 몇 개의 위젯을 사용하는 대시보드의 경우에도 마찬가지입니다. 대부분의 경우 너비, 간격, 여백 등에 대한 일부 경계나 제한을 설정하는 것이 효과적일 수 있습니다. 다른 경우에는 평소보다 더 높은 값을 가진 여러 중단점에 대해 동일한 화면을 디자인하는 방식을 다시 생각해야 할 수도 있습니다. 데이터가 너무 많습니다. 이전 코너 케이스와는 반대로, 작은 화면 해상도에 너무 많은 데이터를 표시해야 하는 문제에 직면할 수도 있습니다 (일부 기업에서 사용하는 장비의 제조 날짜를 알면 놀랄 것입니다). 제한된 공간에서는 콘텐츠 래핑, 가로 스크롤, 점진적인 공개를 통한 콘텐츠 자르기 또는 이들의 조합 등 몇 가지 옵션이 있습니다. 올바른 방법을 선택하는 것은 상황에 따라 다르지만, 예를 들어 표를 사용하여 분석해 보겠습니다. 콘텐츠를 래핑하면 수직 스크롤이 너무 많이 생성됩니다(예: 각 항목에 대한 긴 설명). 가로 스크롤은 아마도 단일 항목의 모든 세부 정보를 얻기 위해 앞뒤로 많은 시간을 필요로 할 것입니다. 잘라내기가 작동하는 경우도 있지만 콘텐츠를 보거나 복사하려면 추가 작업이 필요합니다(예: 콘텐츠를 발견하려면 '호버' 또는 '클릭' 이벤트 사용, 콘텐츠 복사를 위한 상황별 메뉴 등). 가장 중요하지 않은 열을 테이블 끝으로 밀어넣는 줄 바꿈과 가로 스크롤의 조합은 일부 시나리오에서 작동할 수 있는 반면 줄 바꿈과 잘림(최대 줄 수까지)의 조합은 다른 경우에 잘 작동할 수 있습니다. 요점: 항상 설계에 실제 데이터를 사용하여 이러한 모든 사례, 특히 최상의 시나리오와 최악의 시나리오를 쉽게 발견하십시오. 어떤 방법을 선택하든 대다수를 위해 디자인하고 소수를 별도로 처리해야 한다는 점을 잊지 마십시오. 그에 따라 방법을 선택하십시오. 보호된 데이터 동일한 정보를 읽는 다른 사용자는 다른 권한을 가질 수 있다는 점을 잊지 마십시오. 이 경우 액세스할 수 없는 부분을 숨기는 대신 난독화하는 것을 고려하고 이유를 설명하는 간단한 메모를 추가하십시오. 숨기면 컨텍스트가 깨지고 혼란이 생길 ​​수 있습니다. 예를 들어 Slack은 비공개 채널을 통해 이 작업을 수행합니다(아래 모습 참조). "비공개 채널" 부분을 빼면 더 이상 의미가 없습니다. Slack에서 난독화된 비공개 채널과 가능한 원인을 설명하는 도구 설명입니다. 데이터 형식 이전 사례와 다소 유사하게, 다른 위치의 사용자는 동일한 데이터를 보면서 다른 것을 이해할 수 있습니다. 항상 사용자의 선호도에 따라 표시되는 데이터의 형식을 지정하세요. 사용자가 특정 국가에서 일한다고 해서 반드시 해당 국가에서 사용되는 표준 형식을 자동으로 채택한다는 의미는 아닙니다. 예를 들어, 나는 미국에서 임시로 근무하는 유럽인일 수 있습니다. 이는 킬로미터 대신 마일로, 날짜 형식을 `dd/mm/yyyy` 대신 `mm/dd/yyyy`로 자동 전환한다는 의미는 아닙니다. 미국 숫자 형식을 사용합니다. 전 세계에서 사용되는 다양한 날짜 시간 형식: 미국/필리핀, 호주/인도, 스페인 일부, 동아시아, 기타 국가 및 ISO 8601