잘 팔리는 기업용 소프트웨어 디자인하기
UX 디자인을 다루는 기업 캡티브디자인(Captive design)이 디지털 매체 미디엄(Medium)을 통해 발표한 글입니다. 작성자인 마이클 티렐(michael Tyrell)은 캡티브디자인에서 사용자와 비즈니스를 위한 가치를 창출하기 위해 소프트웨어, 콘텐츠 및 시스템을 설계하고 있습니다. 본문은 기업용 소프트웨어 디자인에 대해 자세히 설명하고 있어 기업용 디자인에 관심이 있으시다면 흥미롭게 읽을 만한 글입니다.
저는 그린하우스(Greenhouse)라는 회사에서 수많은 기업들이 사용할 수 있는 채용 관련 소프트웨어를 디자인했던 경험이 있습니다. 대상 기업들은 몇 명으로 시작한 스타트업에서부터 임직원의 수가 1만 명이 넘는 대기업들까지 다양했으며, 채용을 담당하는 부서의 구조와 특성은 모두 상당히 달랐습니다. 회사가 창립된 이후 처음으로 채용을 하는 기업들도 많았고, 채용을 전담하는 부서와 프로세스를 이미 갖추고 있는 기업들도 있었습니다.
이렇게 다양한 상황을 단 하나의 제품으로 처리하도록 디자인한다는 것은, 저에게는 신선하면서도 짜릿한 도전이었습니다. 일반적인 소비자들을 위한 제품을 만드는 것과 기업용 소프트웨어를 만들 때의 상황과 목표가 매우 다를 수 있다는 것도 금세 알게 되었습니다.
우리가 만드는 소프트웨어는 잘 팔려야 합니다. 하지만 그러한 제품(특히 기업용 소프트웨어)이 갖춰야 하는 기능이 겉으로 잘 드러나지 않는 것이라면, 잘 팔리는 제품을 만들기란 쉽지 않습니다. 이런 특성으로 인해서 다음과 같은 2가지의 어려움이 발생합니다.
1. 기업들의 다양한 프로세스를 이미 출시되어 있는 소프트웨어를 통해서 지원할 수 있도록 디자인하는 것
2. 새로운 고객들이 소프트웨어를 통해서 얻고자 하는 것들이 무엇이며, 우리가 만드는 소프트웨어는 그들이 원하는 것 중에서 무엇을 해결해줄 수 있는지를 일일이 알아내는 것
이러한 상황이 간단하지 않다는 것을 보다 잘 이해하려면, 일반적인 소비자들을 위한 제품과 기업용 소프트웨어를 만드는 방식이 어떻게 다른지를 간단하게 살펴보는 것이 좋을 것 같습니다.
①소비자들의 경험 vs 기업들의 경험
성공적인 소비재 상품은 특수한 용도에 집중되는 경향이 강하며, 이를 통해서 관계가 더욱 활성화되기도 하고 이용 방식이 바뀌기도 합니다.
소비자를 대상으로 거두는 성공의 대부분은 그 제품의 단순함과 특수한 용도 때문인 경우가 많습니다. 그러한 제품의 단순한 사용 방식과 그것이 제공하는 가치는 이해하기 쉽습니다. 한 가지 문제에만 집중해서 내놓은 제품들이 많은 사람들의 관심을 끌게 되는 것입니다.
소비자용 제품들의 어려운 점은 그러한 제품을 만들기 위한 아이디어를 얻어내는 것입니다. 그런 제품을 만들기 위한 과학기술만큼이나, 소비자들의 기존 습관을 바꾸거나 행동 방식을 바꾸어야 하기 때문입니다. 반면에 성공적인 기업용 제품은 보편화된 용도로 만들어지는 경우가 많으며, 기존의 습관을 바꾸는 것이 아니라 기업들에게 판매해서 수익을 창출하는 것을 추구합니다.
소비자들의 관심을 끌어야 하는 것이 아니라, 기업들이 소프트웨어를 구입하거나 이용료를 내도록 해야 하기 때문에 아주 다른 상황이 만들어지게 됩니다. 기업들은 각자의 운영 방식이 있고, 웬만해서는 변화를 원하지 않습니다. 소프트웨어도 그런 상황에 맞춰서 구입합니다.
좀 더 일반적으로 말하자면, 기업들이 겪는 문제를 정확히 파악하고 그에 대한 해결책을 제시하는 것이 좋습니다. 우리는 기업들이 가진 기존의 운영 방식을 보다 쉽고 빠르게 만들며, 협업은 더욱 강화할 수 있는 소프트웨어를 만들어야 합니다. 그리고 새로운 소프트웨어를 도입하는 과정에서는 조직 내부의 각 개인들의 습관에는 변화가 요구될 수도 있지만, 기업의 운영 방식 자체를 완전히 새로운 방식으로 변화시키는 소프트웨어를 만들어서는 안 됩니다. 아무리 사소한 변화라고 하더라도 기업들에게는 비용이 들고, 제대로 적응하지 못해서 실패할 위험성도 있습니다. 그리고 그렇게 변화하기 전보다 오히려 사정이 더욱 나빠질 수 있는 가능성도 매우 큽니다.
간단히 말해서 대부분의 기업들은 조직의 변화가 필요한 소프트웨어를 돈을 주고 구입한다는 생각을 좋아하지 않습니다.
즉, 기업용 제품의 경우에는 다른 무엇보다도 서로 다른 다양한 조직의 업무를 지원하는 것이 소프트웨어의 역할입니다. 기업들은 서로 각자 운영되는 방식이 다릅니다. 단 하나의 제품으로 그런 모든 상황을 지원하기 위해서는 아주 특별한 고려가 필요합니다. 그런 제품이 목표로 겨누고 있는 시장의 주요 고객인 기업들은 각자 규모도 다르고, 조직의 구조와 문화도 모두 다릅니다. 그렇게 기업들이 천차만별이라는 것은, 각자가 필요로 하는 소프트웨어도 모두 조금씩은 다르다는 것을 의미합니다.
그러기 위해서는 보편적으로 사용될 수 있도록 디자인을 할 필요가 있습니다. 즉, 원래는 특정한 용도로 만들어진 것이라도 다양한 프로세스를 지원할 수 있어야 합니다.
기업용으로 디자인하기 위해서는 우리가 판매하고자 하는 기업들이 가진 다양한 워크플로우(workflow, 업무의 흐름)에 맞게 디자인을 해야 합니다. 기업용 소프트웨어를 판매한다는 것은 주로 기업들의 업무를 탐색하고 그러한 프로세스에 맞게 만드는 것입니다. 즉, 현재의 업무 방식을 파악하고, 그러한 프로세스를 개선하거나 지원하기 위해서 소프트웨어가 가진 기능들을 잘 맞춰 주어야 합니다.
잠재적인 고객들이 “여러분 회사의 제품은 그 일을 할 수 있나요”라고 물을 때마다, 그 현장에 있는 영업 직원들이 최대한 자주 “그렇다”고 대답할 수 있어야 합니다. “못 합니다”라고 대답하는 경우가 많다면, 절대로 계약을 성사시킬 수 없습니다.
그리고 미래의 상황을 염두에 두고 디자인하고 개발해야 합니다.
여러분이 소프트웨어를 판매하고자 하는 기업들의 유형은 시간이 지나면서 얼마든지 바뀔 수 있습니다. 업계도 바뀔 수 있고, 시장의 변동에 따라서 달라질 수 있습니다. 이렇게 상황이 바뀌면, 여러분이 현재 만들고 있는 제품에도 기능적으로 새로운 요구사항들이 제기됩니다. 그렇기 때문에 그러한 변화에 맞춰서 좀 더 일반화시키거나 규모를 확장할 수 있어야 합니다.
②사례 연구: 채용 작업에 대한 승인 프로세스 구성하기
기업들의 워크플로우가 다양하다는 점을 고려해서, 저희 그린하우스에서 만든 모든 기능들은 좀 더 보편화할 필요가 있었습니다. 즉, 충분히 달라질 수 있는 상황들을 염두에 두고, 우리가 만들어야 하는 것과 만들지 말아야 할 것, 그리고 그러한 다양한 워크플로우를 지원할 수 있는 통합된 환경을 어떻게 디자인할 것인지를 고민해야만 했습니다.
이에 대한 실제 사례로, 저희 그린하우스에서 채용 관련 승인 프로세스를 만들었던 방법을 자세히 살펴보도록 하겠습니다. 이제부터 소프트웨어의 기능들이 다양한 워크플로우를 지원하는 방식은 무엇이고, 디자인의 관점에서 그러한 기능이 얼마나 잘 동작하는지, 그리고 우리가 만든 제품의 단점들이나 절충했던 부분들은 무엇인지를 살펴보겠습니다.
승인 워크플로우란 무엇인가?
채용 절차는 수많은 기업들과 부서에서 이루어지고 있습니다. 그러한 과정에서 어떤 사람들에게는 절차가 진행되는 과정을 알려야 하고, 새로운 자리를 만들거나 어떤 사람에게 일자리를 제안하려면 사전에 승인도 받아야 합니다. 소프트웨어를 통해서 승인 워크플로우(approval workflow)를 갖춰 놓으면, 기업들은 채용 절차를 체계적으로 운영할 수도 있고, 누가 어떤 단계에서 승인을 내렸는지를 확인할 수 있습니다.
대상 기업들의 다양성을 고려해서 디자인하기
기업들이 승인 프로세스를 지원하는 소프트웨어에서 기대하는 것들은 아주 다양합니다. 예를 들자면 이런 것들입니다.
기업 A: “저희 회사는 규모가 작습니다. 저희는 채용 담당자들이 평소에 우리 회사의 내부에서 주고받는 대화를 기반으로 자리도 만들고 채용 공고도 게시하고 있다고 생각합니다. 채용 계약을 할 때는 저희 CEO에게 구두로 보고를 하고 승인을 받은 다음에 연봉과 스톡옵션 등을 제시하곤 합니다.”
기업 B: “저희는 채용하고 싶은 역할이 몇 개 있기는 하지만, 실제로 어떤 역할을 채용할지는 쉽게 결정하지 못합니다. 그래서 저희의 채용 담당자들이 전략적으로 결정을 해서 그들이 원할 때 채용 공고를 냅니다. 하지만 채용 계약을 하고 연봉을 제시할 때는, 사전에 CEO와 재무 책임자의 승인을 기다려야 합니다.”
기업 C: “저희는 채용 공고를 내기 전에 무조건 회사의 인사책임자, CEO, CFO의 결정을 기다려야 하지만, 채용에 대한 최종적인 판단은 채용 담당자가 주어진 예산의 범위 내에서 결정한다고 생각합니다. 애초에 계획했던 것보다 연봉이 높다면, 그런 채용 계약을 하기 전에는 재무팀에서 최소한 한 명 이상이 승인을 내려야 합니다.”
초기의 연구개발 과정에서는 저희 그린하우스의 공동 창업자이자 제품 책임자인 존 스트로스(Jon Stross)가 기존에 협업하던 기업들은 물론이고 잠재적인 고객들과도 함께 대화를 하면서 이러한 연구 및 탐색 프로세스를 이끌었습니다. 이러한 대화를 통해서 우리가 디자인하는 제품이 지원해야 하는 사항들이 다음처럼 다양하다는 것을 알 수 있었습니다.
1. 승인이 필요한 사항
2. 관련된 사람들
3. 승인 요청의 순서
4. 개인의 독자적인 승인인지, 아니면 단체/그룹의 논의를 통한 승인인지
5. 예외 처리
6. 대리 승인
7. 채용 절차를 변경할 수 있는 사람
8. 위의 모든 상황에 대해서 각 기업 및 부서별로 서로 다른 다양한 상황들
1. 승인이 필요한 사항
승인이 필요한 사항은 각 기업들마다 서로 다릅니다. 그리고 같은 회사 내에서도 규모가 커지고 조직이 복잡해지면서 서로 달라지는 경우도 많습니다. 우리는 이러한 승인에는 주로 다음과 같은 세 가지의 유형이 있다는 것을 확인했습니다.
A) 채용 절차의 진행에 대한 승인
B) 채용에 대한 정식 승인
C) 채용 계약 내용에 대한 승인
A) 채용 절차의 진행에 대한 승인
조직 내에서 필요한 일자리 채용의 상태를 “논의 중”이던 것에서 “채용 진행”으로 변경하기 위해 필요한 승인입니다. 이렇게 상태를 변경하는 것이 일반적으로 채용 프로세스의 시작을 알리는 경우가 많습니다. 이렇게 하면 해당 일자리에 대한 지원자를 받을 수 있고, 채용 공고를 온라인에 올려서 공개적으로 지원 서류를 받을 수도 있습니다.
사례 예시: “저희 회사의 웹사이트에 채용 공고를 올리려면, 사전에 반드시 저희 인사책임자가 알아야 합니다.”
B) 채용에 대한 정식 승인
채용에 대한 정식 승인은 해당 채용을 진행해도 된다는 사실상의 청신호입니다. 그리고 이러한 결정은 회사의 재무책임자와 인사책임자가 해당 직위에 대한 인건비를 예산에 편성하고 조직도에도 포함시킨 다음에 나오는 경우가 많습니다.
이러한 승인 절차는 인사팀이 채용 프로세스를 시작할 수 있도록 승인하는 단계와, 조직 내에서 공식적인 승인 절차가 진행되는 동안 최종 후보자를 가려내는 단계로 각각 구분할 수 있습니다. 이러한 정식 승인이 이루어질 때쯤 되면, 인사팀에서는 면접을 하거나 스카우트를 제안하기 위해서 관심을 갖고 있는 후보자들의 명단을 이미 갖고 있을 수도 있습니다. 일단 채용에 대한 정식 승인이 내려지면, 인사팀은 새로운 자리를 만들거나 개별 후보자들에게 스카우트를 제안할 수도 있습니다. 정식 승인이 내려지기 전이라면 이런 기능들을 사용할 수 없어야 합니다.
사례 예시: “저희 회사의 채용 담당자들은 때로는 미리미리 채용 업무를 진행하는 경우도 있습니다. 그건 상관없지만, 재무책임자가 해당 직책을 예산에 편성하기 전까지는 정식으로 진행할 수는 없습니다.”
C) 채용 계약 내용에 대한 승인
인사팀이 채용하고 싶은 후보자를 최종적으로 가려냈다면, 다음에는 계약 내용을 제안해야 합니다. 여기에는 연봉이나 업무 개시일 등이 포함되어 있습니다. 이 과정에서는 조직 내의 다른 사람들이 면접 내용을 검토하고 계약 내용을 협의한 다음에, 후보자에게 그 내용을 전달하게 됩니다.
사례 예시: “모든 신규 채용의 최종적인 승인은 저희 CEO가 내립니다.”
2. 관련된 사람들
채용 관련 소프트웨어가 지원해야 하는 기능들 중에서도 가장 차이점이 크게 나타나는 부분은, 각 기업들이 채용 관련 승인을 내리는 사람을 각자의 상황과 단계에 맞게 지정할 수 있게 해야 한다는 것입니다. 어떤 단계에서는 승인을 내리는 사람이 전혀 없을 수도 있고, 조직 내의 관련된 부서에 근무하고 있는 여러 사람들의 협의를 거치는 경우도 있습니다.
3. 승인 요청의 순서
임직원 한 명 이상의 승인이 필요한 경우, 그러한 요청은 순차적으로 이루어질 수도 있고, 동시에 진행될 수도 있습니다. 규모가 큰 조직의 경우에는 특정한 순서를 거쳐야 하는 경우도 있고, 또는 그러한 요청이 요청되고 나면 누군가의 승인이 내려진 다음에만 다음 순서의 사람에게 해당 요청이 전달되는 일종의 “상향식” 시스템을 갖고 있는 경우도 있습니다. 예를 들자면, 채용 담당자가 승인을 하고 나서야 재무부서에서 관련 예산과 연봉을 승인할 수 있는 기업들도 있습니다. 그렇지 않은 기업들에서는 정해진 순서와는 관계없이, 지정된 그룹의 인원이 모여야 하는 경우도 있습니다.
이런 절차와 관련된 기능을 통해서 사용자들은 승인 요청을 동시에 보내야 하는지, 아니면 순차적으로 보내야 하는지를 선택할 수 있어야 하고, 그러한 순서를 지정하고 편집할 수도 있어야 합니다.
사례 예시: “관련 부서에서 채용이 필요하다고 요청하지 않는 이상, 저희도 경영진에게 그러한 요청을 내리지는 않습니다.”
4. 그룹의 승인
규모가 큰 기업들에서는 주어진 요청을 승인하는 책임을 여러 사람들이 함께 맡고 있는 경우가 많습니다. 예를 들자면, 재무부서에서 신규 채용에 대한 승인을 내렸다는 사실은 그 팀의 누구든 전달할 수 있지만, 그러한 내용은 부서 전체의 논의 결과인 경우가 많습니다.
이러한 기능을 구현할 때는 어떠한 승인 “단계”에서든 다양한 사람들에게 승인 권한을 부여할 수 있어야 하며, 프로세스를 계속 진행하기 위해서 필요한 인원이 몇 명인지도 지정할 수 있게 해야 합니다. 그리고 해당 그룹에 속하는 한 명이 결정 내용을 전달할 수도 있고, 그룹 내의 몇 명의 사람들이 함께 결정을 내릴 수도 있어야 합니다.
사례 예시: “논의해야 할 것들이 많기 때문에, 저희는 함께 협업합니다. 그리고 시간과 상황에 따라서, 각자 다른 사람이 저희 재무팀을 대신해서 결정 내용을 전달합니다.”
5. 예외 처리
최종적인 연봉은 후보자가 면접 과정을 거친 다음에야 제시되기 때문에, 실제 연봉은 애초에 승인이 이루어졌던 것과 다른 액수의 범위에서 결정되는 경우가 많습니다. 그리고 해당하는 연봉이 처음에 승인받은 범위에 들어 있어야만, 재무팀과 다시 한번 논의를 거칠 필요가 없습니다.
하지만 때로는 채용 절차를 거치면서 예외적인 후보자가 올라올 수도 있고, 채용 담당자는 원래 승인받은 범위를 넘어서서 연봉을 제시하고 싶어질 수도 있습니다. 이런 상황에서는 재무팀의 승인이 필요하게 됩니다.
예외적인 상황에 대한 승인은 채용 절차에서 이렇게 변동이 발생하는 경우를 위한 것입니다. 제시하는 연봉이나 보너스가 사전에 승인받은 범위를 벗어나게 된다면, 시스템이 예외 상황을 표시하고 그러한 연봉을 허가할 수 있는 권한을 가진 담당자에게 승인 요청을 보내야 합니다.
사례 예시: “이번 채용에 대해서는 연봉을 최대 10만 5000달러까지 제시해도 좋습니다. 만약 그 이상이 필요하다면 저에게 알려 주시기 바랍니다.”
6. 대리 승인
여러 명의 사람들로 구성된 팀을 지원하기 위해 만든 디지털 플랫폼들이 그렇듯이, 채용과 관련한 협업도 때로는 어쩔 수 없이 오프라인에서 이루어져야 하는 경우가 있습니다. 이런 경우, 그러한 프로세스를 최대한 빠르게 진행시키는 것이 중요한 채용 담당자라면 필요한 승인을 구두로 얻을 수도 있을 것입니다. 즉, 권한을 가진 사람이 시스템에 로그인해서 승인을 처리하지 않고도 프로세스를 진행할 수 있게 해야 합니다.
“대리 승인”은 채용 담당자들이 바로 이런 일을 할 수 있게 해 줍니다. 누군가에게 관련 내용을 말로 전달한 다음에, 그 내용은 그린하우스의 시스템에 공식적인 기록으로 남기는 것입니다. 그러면 시스템에서는 해당 단계를 “승인”으로 표시하며, 채용 프로세스는 계속해서 진행됩니다. 그리고 시스템에는 실제로 승인을 내린 사람이 누구인지도 기록됩니다.
사례 예시: “로그인해서 승인을 해달라고요? 그 채용 건은 진행해도 된다고 이미 말씀드렸잖습니까…”
7. 채용 절차를 변경할 수 있는 사람
영향력을 가진 고위층의 관리자들이 이러한 워크플로우를 변경할 수 있다는 사실을 고려하면, 이렇게 공식화된 전체 프로세스 상에서 “보이지 않는” 또 하나의 계층이 존재하고 있을 수도 있습니다.
이런 경우, 시스템의 메인 담당자는 조직 내에서 이러한 워크플로우를 살펴보고 다시 구성할 수 있는 사람이 누구인지를 지정할 수 있어야 합니다. 그리고 다른 사람들을 대신해서 승인을 내릴 수 있는 사람이 누구인지도 선택할 수 있게 해야 합니다.
8. 각 기업 및 부서별로 맞춤형으로 설정할 수 있는 워크플로우
마지막으로, 조직의 규모가 커지고 복잡해질수록, 이러한 승인 프로세스에 참여해야 하는 사람들의 구성이 각 기업과 부서에 따라서 달라질 가능성도 더욱 커지게 됩니다.
따라서 이러한 시스템은 채용 절차를 새로 진행하는 기능은 기본으로 제공하면서, 각 기업과 부서에 따라서 다양한 방식과 조합으로 승인 프로세스를 직접 구성할 수 있게 해야 합니다.
③내용 정리: 다양한 시나리오를 지원해야 한다
지금까지 살펴본 많은 워크플로우들은 다수의 기업에서 사용할 수도 있고, 한 군데에서도 사용하지 않을 수도 있습니다. 하지만 그렇게 다양한 부분들을 전부 고려해서 구현해 놓으면, 채용 프로세스에 따라서 달라질 수 있는 수많은 상황들을 지원할 수 있는 아주 강력하면서도 유연한 시스템이 만들어지게 됩니다. 앞에서 살펴봤던 사례들을 되짚어보면서, 그런 각각의 상황을 지원할 수 있는 시스템이 어떤 것인지를 살펴보겠습니다.
기업 A: “저희 회사는 규모가 작습니다. 저희는 채용 담당자들이 평소에 우리 회사의 내부에서 주고받는 대화를 기반으로 일자리도 만들고 채용 공고도 게시하고 있다고 생각합니다. 채용 계약을 할 때는 저희 CEO에게 구두로 보고를 하고 승인을 받은 다음에 연봉과 스톡옵션 등을 제시하곤 합니다.”
기업 B: “저희는 채용하고 싶은 역할이 몇 개 있기는 하지만, 실제로 어떤 역할을 채용할지는 쉽게 결정하지 못합니다. 그래서 저희의 채용 담당자들이 전략적으로 결정을 해서 그들이 원할 때 채용 공고를 냅니다. 하지만 채용 계약을 하고 연봉을 제시할 때는, 사전에 CEO와 재무 책임자의 승인을 기다려야 합니다.”
기업 C: “저희는 채용 공고를 내기 전에 무조건 회사의 인사책임자, CEO, CFO의 결정을 기다려야 하지만, 채용에 대한 최종적인 판단은 채용 담당자가 주어진 예산의 범위 내에서 결정한다고 생각합니다. 애초에 계획했던 것보다 연봉이 높다면, 그런 채용 계약을 하기 전에는 재무 부서에서 최소한 한 명 이상이 승인을 내려야 합니다.”
④UX에서의 고려사항
그렇게 만든 UI는 중요한 역할들을 담당하지만, 그럼에도 몇 가지의 단점들이 존재합니다. 지금까지 우리는 UI가 지원할 수 있는 다양한 워크플로우를 살펴보았습니다. 그럼 이제부터 UI가 원하는 대로 잘 동작했던 사례들을 찾아보고, 절충했던 부분들도 살펴보도록 하겠습니다.
강점
다양한 상황을 지원한다
저희가 만든 UI는 승인 과정에서 활용되는 다양한 워크플로우를 지원하도록 구성할 수 있으며, 그렇게 다양한 과정들은 단일한 환경으로 통합할 수 있었습니다.
현재의 구성 상태를 알려준다
이 UI는 또한 현재의 구성 상태를 사용자들에게 아주 잘 알려주고 있습니다. 중요한 정보들은 전부 기본 설정에 의해서 표시되고 있습니다. 이를 통해서 각각의 기업과 부서들이 승인 과정을 어떻게 구성했는지를 볼 수 있습니다. 워크플로우의 각 단계별 세부사항에 대해서도 마찬가지입니다. 즉, 채용 프로세스가 몇 단계로 구성되어 있는지, 누구에게 승인이 요청되고 있는지, 어떠한 순서에 의해서 이루어지고 있는지, 예외적인 상황이 발생할 경우에는 별도의 승인이 요청되고 있는지 등을 알 수 있습니다.
구성 설정이 쉽다
마지막으로, 저는 우리가 만든 인터페이스가 대체적으로 사용하기 쉽다고 말할 수 있습니다. 일단 어떤 개념을 기반으로 만들어졌는지를 이해하고 나면, 드래그 앤 드롭(drag and drop, 마우스로 끌어다 놓기) 방식으로 승인 순서를 변경하는 등, 여기에 있는 UI 요소들을 실행하는 것이 상당히 직관적입니다. 관리자가 자신이 설정을 구성하고자 하는 것이 무엇인지를 알고 있다면, 아주 쉽고 빠르게 작업을 수행할 수 있습니다. 즉, 회사 전체와 부서에 걸쳐서 조직 전반의 기본 구성을 쉽게 설정할 수 있습니다.
단점
표준화되지 않은 맞춤형 UI 요소들
이러한 접근 방식의 가장 커다란 단점은 표준화되지 않은 UI 요소들을 사용한 인터페이스라고 할 수 있습니다. 이러한 맞춤형 UI 요소들은 그 사용법을 배우기가 힘들게 만들며, 더욱 중요한 것으로는 이러한 시스템을 구축하고 유지하는 작업이 더욱 어렵고 시간도 훨씬 더 많이 소요된다는 것입니다.
물론 지금까지 살펴본 내용을 고려해 보면, 이러한 상황에서 표준화된 UI 요소들을 사용한다는 것은 쉽지 않았을 것입니다. 구성 설정에 있어서 모두 동일한 수준까지 지원하는 경험을 디자인한다는 것은 더욱 어려웠을 것이고, 구성 설정과 승인 상태를 표시하는 것에 있어서도 모두 동일한 환경으로 디자인한다는 것도 아주 어려웠을 것입니다. 다만, 이렇게 표준화되지 않은 요소들을 사용해서 얻는 혜택이 표준화된 UI를 구축하는 데 드는 추가적인 비용보다 더욱 중요했습니다.
이러한 시스템의 기본 개념을 완전히 전달하지 못했다
이 시스템이 가진 인터페이스의 사용법을 익히는 것과, 그 이면에 있는 기본 개념을 이해한다는 것이 매우 어렵습니다. 설정을 변경할 때는 그 과정이 소프트웨어 내에서 다수의 다른 사용자들에게 노출되었는데, 그것도 신규 채용 절차를 만들거나 스카우트를 하는 경우에만 그랬습니다.
이런 모든 점들은 시스템의 사용법을 배우는 것을 훨씬 더 어렵게 만들었습니다. “시스템을 사용하면서 어떤 문제가 생긴다면, 앞으로는 그렇게 하지 않는다”는 시행착오를 통한 학습 방식이 이번 사례에서는 적용되기가 힘든 것입니다.
또한 어떤 기능 위로 마우스를 가져가면 그에 대한 설명이 뜨기는 했지만, 추가적인 설명이 없었기 때문에 여러 가지의 다양한 승인 방식들의 차이에 대해서 이해하기가 어려웠습니다. 그리고 어떤 워크플로우가 승인이 완료되고 나면, 해당 기능의 처음 단계로 페이지가 이동하는 문제가 있었습니다.
⑤결론
복잡하지만 전략적인 결정
저희의 인터페이스가 가진 이러한 단점들은 결코 그냥 지나칠 수 없는 것이지만, 그래도 이번 사례에서는 그것이 올바르게 절충했던 것이었다고 생각합니다. 이러한 시스템은 중요한 것이긴 하지만, 자주 사용되는 것은 아니기 때문입니다. 그리고 이러한 승인 워크플로우는 한번 만들어지고 나면, 웬만해서는 변경되지 않습니다.
그리고 이러한 환경 설정을 담당하는 사용자들은 일반적으로 시스템 관리자들인 경우가 많은데, 그렇기 때문에 그들은 조금은 복잡한 기능이라고 하더라도 더욱 많은 시간을 투자해서 세부적인 사항들까지도 배우려는 성향이 강합니다. 그리고 그들은 이러한 프로세스를 구현하는 과정에서 저희의 계정 관리자로부터 충분한 지원을 받고 있기 때문에, 승인 워크플로우를 적절하게 설정하는 데 있어서도 도움을 받고 있습니다. 결국, 시스템을 배우기 쉬운 것보다는, 기능의 완전성과 인터페이스 상에서 현재의 설정 상태를 보여주는 것이 훨씬 더 우선시 되었습니다.
더욱 확대된 환경을 기대하며
이러한 승인 워크플로우는 기업들이 경험하는 더욱 큰 영역들에 비하면 아주 작은 부분에 불과합니다. 그래도 채용 절차를 진행한다는 것은 어려운 일이고, 그러한 절차를 지원하는 도구들은 아무리 사용하기 쉽다 하더라도 복잡할 수밖에 없습니다.
마지막으로 기업 내의 수많은 프로세스에서 소프트웨어가 지원할 수 있는 기능들은 여러 다양한 수준에서 존재하고 있다는 점을 강조하고 싶습니다. 즉, 채용 승인 워크플로우와 같은 1페이지 분량의 작업이 될 수도 있지만, 어떤 워크플로우에서는 여러 개의 페이지가 필요한 경우들도 있습니다.
> 이 글은 'Designing Enterprise Software that Sells'을 각색하여 작성되었습니다.
©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.
