NEW 기획 디자인 개발 프로덕트 아웃소싱 프리랜싱

디자인

잘 팔리는 기업용 소프트웨어 디자인하기

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'을 각색하여 작성되었습니다.

댓글 0

요즘IT의 번역글들

이 프로필을 만든 저만 해도 영어가 서툴러 영어로 된 기사는 읽는 게 더딥니다. 그래서 준비했습니다. 읽어볼만한 해외 소식들을 번역해 전합니다. We are the world.

디자인, 산출물 그 이상을 넘어

디자인

이 회사는 디자인에 투자하고 있는 회사일까요?

디자인

애자일은 정말 디자인을 배제하나요?

디자인

평판 관리가 프리랜서 경력에 미치는 영향

프리랜싱

리액트 네이티브 개발자들이 겪는 가장 빈번한 5가지 문제와 해결책

개발

“솔직히 우리가 하는 것은 스크럼이 아닙니다!”

기획

데이터 시각화가 인류를 위기에서 구한 세 가지 역사적 사건

디자인

NFT의 장밋빛 미래는 사실일까?

기획

피그마 토큰으로 디자인 시스템 만들기

디자인

디자이너+개발자 = 슈퍼팀 만들기

기획

1인 개발자로서 테크 스타트업을 운영하며

기획

웹 디자이너가 PX대신 REM을 사용해야 하는 이유

디자인

100개의 스타트업을 멘토링하며 깨달은 성공의 비밀

기획

중화권 앱 UI가 영미권 앱 UI와 다른 점 알아보기

프로덕트

내가 테크 리더로 일하면서 얻은 8가지 교훈

기획

모두가 즐길 수 있는 디자인 검토 회의 만들기

디자인

프로덕트 매니저에서 프로덕트 마스터로

기획

10배 이상 뛰어난 개발자가 되는 법

개발

제품 디자인 관점에서 바라보는 NFT 아바타 열풍

디자인

에어비앤비: 대규모 iOS 앱 개발 생산성을 위해 바꾼 것들

개발

스포티파이: 맞춤형 플레이리스트 개발 비하인드 스토리

개발

프리랜서가 일하게 될 15가지 유형의 프로젝트

프리랜싱

슬랙: 제품 원칙을 통해 다시 태어난 알림 기능

프로덕트

페이팔: 실시간 그래프 데이터베이스 분석을 통해 사기를 방지하는 방법

개발

트위터: 수십억 개의 이벤트를 실시간 처리하기

개발

슬랙: 4가지 애자일 가치와 방법

기획

스퀘어: 모바일 우선을 넘어 웹에서 누리는 모바일앱 경험

디자인

스포티파이: 카피를 언어로 만드는 UX 라이팅

기획

마이크로소프트: 디자인의 미래를 위한 4가지 원칙

디자인

메타: AR/VR 경험까지 고려한 디자인 청사진

프로덕트

슬랙: 훌륭한 마케팅 카피를 위한 5가지 원칙

기획

2022년 UX/UI 디자인 트렌드

디자인

구글: 가변 폰트의 놀라운 활용법

디자인

에어비앤비: 위기 상황에서의 디자인 원칙 5가지

디자인

어떻게 두 명의 인턴이 수백만 개의 코드들을 보호할 수 있었나

개발

Lattice로 마이크로 프론트엔드를 구축하는 법

개발

Cool Cats NFT를 구축하면서 배운 것

개발

웹 컴포넌트가 프론트엔드 프레임워크를 대신할까?

개발

당신이 NFT에 대해 알아야 할 모든 것

개발

우리에겐 이상하지만 개발자들에겐 일상인 일들

개발

Next.js 12에서 주목해야 할 5가지 변화

개발

스벨트 vs 리액트, 누가 더 뛰어날까?

개발

개발자를 위한 iOS 15의 새로운 기능

개발

내가 오픈소스를 싫어하는 이유

개발

프로덕트 매니지먼트 고객 여정 5단계

기획

클럽하우스의 인기는 모두 거품이었다?

프로덕트

데이터 기반 의사결정의 장점

기획

시각 디자인의 폐쇄성 법칙이란?

디자인

사용자 경험(UX) vs 서비스 디자인

기획

프로덕트 매니저는 하루 종일 무슨 일을 할까?

기획

제품 주도 성장은 어떻게 이루어지는가?

기획

UX를 망치지 않는 설득력 있는 배너 디자인

디자인

팝업(Pop-up)으로 불리는 것들에 대하여

디자인

드롭다운(Drop-down)으로 불리는 것들에 대하여

디자인

당신의 생각을 표현하는 새로운 이모지

디자인

가장 똑똑한 소프트웨어 엔지니어에게 배운 10가지 교훈

개발

성공적인 UX 프로젝트를 위한 가장 중요한 질문

디자인

2021년, UI 디자이너가 모바일 앱에서 흔히 저지르는 실수

디자인

IT 매니저가 되는 방법과 성공하기 위한 요소

기획

슬랙(Slack) 같은 앱을 만들려면 비용이 얼마나 들까?

개발

아웃소싱이 이토록 인기를 얻게 된 이유는?

아웃소싱

마케터가 UX 관련 역량을 키워야 하는 이유

기획

미니멀리즘 디자인의 핵심적인 요소들

디자인

새로운 소프트웨어 개발사가 필요하다는 7가지 신호

아웃소싱

2021년을 이끌어가는 프론트엔드 개발 트렌드 5가지

개발

PM을 성장시키는 학습 프레임워크

기획

UI 카피라이팅, 어떻게 써야 하나요?

기획

트렌드 예측: 경쟁에서 앞서는 방법

기획

제품 사고(product thinking)의 힘

기획

인하우스 vs 아웃소싱, 소프트웨어 개발 어떻게 하나요?

개발

그림을 못 그리는 사람도 쉽게 와이어프레임 그리는 방법

기획

스타트업 기업들에게 아웃소싱이 중요한 이유

아웃소싱

제품과 기능, 성공적으로 종료하는 방법 (下)

기획

제품과 기능, 성공적으로 종료하는 방법 (中)

기획

제품과 기능, 성공적으로 종료하는 방법 (上)

기획

UX 디자이너에게 반드시 필요한 12가지 스킬

디자인

패스워드 없는 세상이 오고 있다

개발

디자이너를 쉽게 잃는 방법 10가지

디자인

프론트엔드 코딩 작업에 영감을 줄 8가지 아이디어

개발

구글이 아웃소싱을 하는 이유: 아웃소싱 성공사례 5가지

아웃소싱

일 잘하는 PM이 되기 위한 로드맵 도구 5가지

기획

이제는 말할 수 있다! 아웃소싱에 대한 오해 11가지

아웃소싱

디자인 트렌드, 모던 미니멀 스타일의 UI 가이드

디자인

MVP 개발을 아웃소싱으로 해도 될까요?

개발

온보딩 효과를 높이는 '좋은' 귀차니즘 3가지

기획

게임처럼 즐겨라, 게임화 기법 TOP3

기획

시니어 소프트웨어 엔지니어는 어떻게 일할까?

개발

프로덕트 매니저가 글을 잘 써야 하는 이유

기획

2030년엔 사라질 수도 있는 프로그래밍 언어 5가지

개발

고객들이 언제나 옳은 것은 아니다

기획

유저 스토리는 무엇인가?

기획

고객 성공을 위한 14계명

기획

8px 그리드의 시대가 끝나고, 4px 그리드의 시대가 열릴까?

디자인

모바일 앱은 더 이상 스타트업에게 좋은 아이디어가 아니다

기획

과연 구글의 UX 강좌는 도움이 될까요?

디자인

프로덕트 매니저 여러분, ‘소비자의 요구사항 수집’을 그만두십시오

기획

고객 여정과 경험 지도의 차이점

기획

내가 AI 업계를 떠난 이유 5가지

기획

모달윈도우(팝업)를 디자인할 때 생각할 9가지 원칙

디자인

대기업 vs 중소기업, B2B SaaS 스타트업을 위한 시장은?

기획

내가 개발 인터뷰에서 면접자에게 감동한 이유

개발

HTTP의 새로운 메서드, 서치(SEARCH)에 대하여

개발

세상의 모든 프로덕트 디자이너를 위한 5가지 심리학 원칙

디자인

2021년 테스트 자동화 트렌드 리포트 (下)

개발

2021년 테스트 자동화 트렌드 리포트 (上)

개발

아마존과 스포티파이는 어떻게 사용자를 유지하고 측정할까?

기획

UX 디자이너라면 필수적으로 알아야 할 5가지 법칙

디자인

앵귤러 vs 리액트, 2021년의 승자는?

개발

2021년, SaaS 스타트업 시작을 위한 놀라운 아이디어 10가지

기획

디지털 제품 관리에서 B2B와 B2C 사이의 차이점은?

기획

빠르게 실행할 수 있는 ‘제품 요구사항 문서(PRD)’ 만들기

기획

더 나은 제품을 위한 프로덕트 메트릭스 가이드

기획

노 코드(No Code) 트렌드로 프로그래머들은 일자리를 빼앗길까?

개발

넷플릭스의 플랫폼: 코스모스(Cosmos)에 대하여

프로덕트

비즈니스와 애자일 조직은 어떻게 친해질 수 있을까요?

기획

효과적인 제품 전략 세우기: 다수의 전략적 트랙(MuST) 활용

기획

1년 만에 이메일 마케팅 효과를 극대화했던 방법

기획

솔루션 아키텍트를 위한 팁: 아키텍처 다이어그램의 5가지 유형

개발

새로운 맥 OS ‘빅서’에 대한 UX 디자이너의 생각

디자인

디자인 트렌드, 뉴모피즘의 정석

디자인

스스로 학습하는 UI/UX 디자이너가 되기 위한 2021년 로드맵, 3편

디자인

스스로 학습하는 UI/UX 디자이너가 되기 위한 2021년 로드맵, 2편

디자인

2021년 모바일 UX 트렌드 10가지

디자인

스스로 학습하는 UI/UX 디자이너가 되기 위한 2021년 로드맵, 1편

디자인

앱 설정 기능의 UX를 개선하는 효과적인 방법

디자인

다크모드 UI 디자인의 원칙

디자인

온라인 고객 경험을 개선하기 위한 5가지 방법

기획

신생 스타트업에서 일하는 프로덕트 매니저를 위한 현실적인 조언

기획

웹 개발자와 소프트웨어 개발자의 차이는 무엇인가요?

개발

랜딩 페이지 디자인을 개선하는 13가지 꿀팁

디자인

오프라인 비즈니스가 온라인에서 존재감을 가져야 하는 이유 5가지

기획

상향식 가격 책정 및 패키징 정책: 사용자 여정을 가이드로 활용하기

기획

B2B 제품의 UX, 그것은 숨겨진 영역인가요?

기획

상단 내비게이션 vs 사이드 내비게이션, 어느 것이 더 나을까?

디자인

자동완성 검색 기능 UX 설계를 위한 8가지 팁

디자인

프로덕트 매니저는 전문적인 IT 기술을 갖춰야 하나요?

기획

실리콘밸리 51개 기업들이 말하는 프로덕트 매니저의 역할 9가지

기획

아웃소싱에 대한 모든 것

아웃소싱

앱 디자인 가이드, 사람들이 즐겁게 사용할 수 있는 앱을 만드는 법

디자인

처음부터 완제품이 아니라 ‘MVP’를 만들어야 한다

기획

플러터 vs 리액트 네이티브 vs 네이티브, 성능이 더 우수한 것은?

개발

스타트업 프로덕트 매니저로 성장하는 법, 30-60-90일 플랜

기획

당신의 두뇌는 진보하고 있다: 성취감을 위한 3가지 전략

기획

디자이너들을 편하게 해주는 HTML/CSS 마법 10가지

디자인

코딩의 미래는 ‘노 코드(No Code)’이다

개발

내가 엔지니어링 매니저로 일하면서 저지른 실수들

개발

내가 롬 리서치(Roam Research)를 좋아하는 이유와 실제 사용법 (下)

기획

내가 롬 리서치(Roam Research)를 좋아하는 이유와 실제 사용법 (上)

기획

프로그레시브 웹 앱(PWA)이란 무엇이며, 왜 필요한가?

개발

PWA vs 네이티브 앱, 어떤 것을 선택해야 할까?

개발

UI 디자인에 여백을 활용하는 8가지 팁

디자인

마이크로소프트와 링크드인의 새로운 시도, 프리랜서 마켓에 도전장을 던지다

기획

토마스넷은 왜 가입자 수를 폭발적으로 늘려준 테스트 결과를 거부했을까?

기획

파이어베이스(Firebase)란 무엇인가? 파이어베이스 심층 탐구 : 하편

개발

파이어베이스(Firebase)란 무엇인가? 파이어베이스 심층 탐구 : 중편

개발

파이어베이스(Firebase)란 무엇인가? 파이어베이스 심층 탐구 : 상편

개발

업워크(Upwork)가 조사한 요즘 가장 인기 좋은 개발 기술 15가지

개발

일자리 산업이 휴먼 클라우드(human cloud)에 적응하는 방법

기획

팬데믹 이후 세계에서의 디지털 가속화는 어떤 모습일까?

기획

같은 분야를 다룬 글들을 권해드려요.

요즘 인기있는 이야기들을 권해드려요.

일주일에 한 번!
전문가들의 IT 이야기를 전달해드려요.

[구독하기] 버튼을 누르면 개인정보 처리방침에 동의됩니다.

일주일에 한 번! 전문가들의 요즘IT 이야기를 전달해드려요.

[구독하기] 버튼을 누르면 개인정보 처리방침에 동의됩니다.