[UX 운영이 만드는 가치] 플랫폼을 통합하고 더 나아가기

매일같이 집을 청소하고 관리하는 것처럼, 변화하는 환경과 사용자의 요구에 맞춰 제품과 서비스를 유지하는 업무를 ‘UX 디자인 운영 업무’ 또는 ‘UX 디자인 유지 보수’라고 합니다. 지난 글에서 고객사와 함께 이룬 결과를 바탕으로 그로스(Growth)의 관점을 더한 운영 업무를 소개했는데요. 이번 글에서는 피엑스디(pxd)가 수행했던 또 다른 운영 프로젝트 사례를 소개하고자 합니다. 복잡했던 서비스 위계를 정리하고, 고객사가 플랫폼을 운영하기 쉽도록 기반을 닦아준 프로젝트죠.

규모가 큰 제조사는 필요에 따라 공장 내 조직에 적합한 업무용 서비스를 직접 만들어 쓰는 경우가 많습니다. 오랜 기간 조직별로 구축한 서비스는 겹치는 기능도 있고 그 사용 방식도 다르죠. 문제는 특정 팀이 만든 서비스를 다른 조직과 공유해야 할 때 드러납니다. 같거나 비슷한 기능이 여러 서비스에 걸쳐 있게 되는 경우가 생겨 어느 서비스의 기능을 이용할지 정해야 하고, 서비스들을 개편하자니 각기 다른 UI/UX를 통합하는 것도 쉽지 않죠. 고객사가 이런 상황을 마주했을 때, 피엑스디가 이를 해결하기 위해 세웠던 목표와 실행했던 방안을 소개하겠습니다.

 

더 편리한 플랫폼을 위한 첫 번째 걸음: 목표 세우기 

제품 설계와 생산에 관한 보안이 중요한 제조사 A(이하 A사)는 결재, 보고, 정보 공유, 파일 관리, 팀 협업 등의 업무를 위해 자체 구축한 여러 서비스를 갖추고 있었는데요. 조직이 신설되거나 새로운 생산 공정이 생길 때마다 임의로 만든 서비스들이어서 조직원들에게 일관된 사용 환경을 제공하지 못하고 있었습니다. 담당 개발자가 다 다르니 사용법부터 기능 구조, 정보 구조, 개발 구조 모두가 제각각이었죠. 기능이 혼재된 서비스를 통합 설계하는 작업이 필요했고, 이를 위해 UX 통합의 목표를 분명히 해야 했습니다. 피엑스디 UX운영팀이 세운 목표는 다음과 같았죠.

서비스 간 위계와 기준 정리

기능이 겹치고 섞인 서비스들의 위계를 정리했습니다. ‘시스템 정비로 구성원의 업무 효율을 높인다.’라는 고객사의 기본 요구 사항을 충족하기 위해서였죠. 업무와 기능 단위로 위계를 다시 정리하고, 더불어 이후에 추가할 기능이나 서비스들이 생길 경우 어떤 기준으로 위계를 정하고 분류, 배치할지 명확히 하고자 했습니다.

일관된 사용 경험 설계 적용

서비스의 기존 사용자뿐 아니라 해당 서비스를 처음 접하는 다른 조직 사용자들의 편의도 함께 고려했습니다. 이를 위해 여러 조직의 업무 서비스를 파악하고 UX적인 공통부분과 상이한 부분을 확인했습니다. 또한 왜 이런 서비스가 만들어졌는지 알기 위해 그들의 업무 프로세스와 협업 문화, 조직 문화를 이해하는 과정이 필요했죠.

유지보수 체계 확립

한 번의 플랫폼 통합 작업으로 프로젝트를 마무리하는 것이 아닌, 앞으로도 산발적으로 만들어질 서비스와 설계 수정에 대해서도 효율적으로 대처할 수 있는 체계를 만들고자 했습니다. 유지보수 체계를 만드는 일의 중요성을 설명하고 프로젝트가 이뤄야 할 목표로 정했습니다.

 

두 번째 걸음: 신속하게 전문가 되기

 조직 자체적으로 특정한 목적을 위해 만든 서비스는 일반인들이 사용하는 서비스와 달리 생소한 정보와 프로세스가 많습니다. 플랫폼을 정비하기 위해선 서로 다른 서비스의 목표와 개념을 이해하는 게 우선이었고, 많은 시간을 할애할 수밖에 없었죠. 특히, 서비스 간 위계를 정리하다 보면 통합뿐 아니라 기능을 분리, 이관, 삭제해야 하는 상황이 생겼습니다. 이런 결정을 주도하기 위해 서비스와 사용자를 충분히 이해하는 전문가의 지위를 갖추는 것이 필요했죠.

저보다 서비스들을 더 잘 이해하시는 것 같네요. 고민도 더 많이 하시는 것 같고요. 이 결정들은 믿고 갈 수 있겠어요.    - 고객사 담당자 

각 시스템이 참고했던 서비스와 내부 서비스를 모두 분석했습니다. 그 내용을 고객사 담당자들과 함께 간과한 부분이 있는지 확인했죠. 밀도 있는 분석, 공유, 확인을 통해 해당 서비스 전문가에게 필요한 지식을 빠르게 습득할 수 있었습니다. 고객사 담당자와 동등한 이해도를 가진 디자이너들로 인식되었고 그 신뢰를 바탕으로 프로젝트를 이끌 수 있었다고 생각합니다.

 

 

세 번째 걸음: 숨은 문제점 발견과 서비스 개념 재정립

 여러 서비스를 통합 설계하는 일은 단순히 기능을 재편하는 것에 그치지 않고 각 서비스의 성격을 분석하여 필요한 개념을 재해석, 재규정하는 일까지 필요했죠. 또, ‘이게 불편해요.’, ‘이 기능은 여기가 아니라 저기 있어야 해요.’ 같은 사용자의 목소리에 내포된 욕구가 무엇인지 파악해야 했습니다. 그들의 숨은 욕구를 알아야 문제를 정확히 정의하고 바꿔야 할 요소가 무엇인지 알 수 있기 때문입니다.

예를 들어, ‘검증’ 기능은 제품과 서비스를 검증하기 위한 것이지만, 사용자는 해당 기능을 검증 이력과 보고 자료 확보를 위해 주로 사용한다는 사실을, 인터뷰를 통해 알게 됐죠. 검증 결과를 매번 수동으로 저장하고 보고 시스템에 올리는 과정이 비효율이라 판단했고, 검증과 보고 시스템을 연결해 사용자의 업무 효율을 높였습니다.

비용 처리 시스템의 경우 용어가 직관적이지 않고, 조직마다 용어와 항목을 다르게 사용하고 있는 문제를 발견했습니다. 용어의 사전적 의미와 통용되고 있는 의미를 비교했고 서비스의 기능과 버튼 이름을 재정리했습니다. 이처럼 단순히 ‘다른 조직에서 만든 서비스는 잘 못 쓰겠다.’라는 의견이 내포한 문제를 파악하고자 노력했습니다.

 

네 번째 걸음: 일관성과 유연성을 갖춘 디자인 원칙 관리

 서비스 운영 중에는 고객사의 정책 변경, 사용자 요구사항 변경, 개발 제약 등의 이유로 UX 설계를 수정해야 하는 상황이 자주 발생합니다. 오랜 기간 운영하다 보면, 초기 설계안의 원칙과 다른 화면이 만들어지고 예외 사례가 쌓이면서 정책의 일관성이 떨어지는 경우도 발생하죠. 이런 문제를 방지하려면 프로젝트 초기에 작성한 UI 공통 규칙을 꾸준히 관리하면서 설계 검수 체계를 만들어야 합니다.

 A사의 경우 디자인 시스템까지 구축하기는 어려운 상황이어서, 자체 보유한 웹페이지 저작툴을 활용해 컴포넌트별 가이드라인을 정리하고 기본 템플릿을 제공했습니다. 정책과 UI 규칙을 수정해야 할 때는 수정 전의 내용도 함께 확인할 수 있게 했습니다. 가이드라인을 처음 접하는 사람도 변경 사유를 비롯한 히스토리를 파악할 수 있도록 한 것이죠.

 

다섯 번째 걸음: 조직 간의 의견 조율, 이해관계와 우선순위 조정

 서비스 단위뿐 아니라 세부 기능마다 개발 담당자가 다르고 API가 달랐기에 몇 가지 문제가 생겼는데요. 이해관계가 얽혀 있는 기능이나 페이지는 개발 담당자를 지정하고 작업 진행 요청을 하는 것부터 쉽지 않았습니다. 개발이 가능한지, 개발이 필요한 정도로 의미 있는 통합 작업인지부터 논의하며 설득해야 했습니다.

 이 과정에서 자칫하면 UX 디자인의 의도가 사라진 채 개발 편의만 고려한 결과물이 나올 수 있다고 판단했고, 프로젝트 방향과 디자인 의도를 충분히 반영할 수 있도록 개발자와 긴밀하게 협의해야 했습니다. 이런저런 이유로 개발이 어렵다면 다른 대안을 제시하고 개발 우선순위를 조정했습니다. 유지 보수와 고도화 기간 중 새로운 사항이 산발적으로 생기며 당장의 문제 해결에 집중하다 보면 우선순위에서 밀린 사항의 개발은 또 요원해지기 마련인데요. 이런 사항이 누락되지 않도록 개발팀의 일정을 살피고 적절한 시기를 찾아 지속적인 조율로 결과물을 만들어냈습니다.

이번 플랫폼 통합 프로젝트는 시스템의 특성을 파악하고 협업하는 데 많은 에너지가 필요하다는 것을 다시금 느끼게 해줬습니다. 엉킨 전선을 풀듯 시스템의 복잡한 구조와 조직의 이해관계를 정리하고, 문제점을 찾아 해결하며 플랫폼 통합 업무를 몸으로 익힐 수 있었죠. UX 운영이 할 수 있는 또 하나의 가능성을 찾았다고 생각합니다.

글 최동우(UX 디자이너)

편집 정우재(UX 라이터)