🎵 자세한 포트폴리오
Meissa Platform: 다채널 데이터를 고려한 확장성 있는 메뉴 구조 개선
Billie
👍
3
다채널 데이터를 고려한 확장성 있는 메뉴 구조 개선
Meisa는 드론 데이터뿐만 아니라,
다채널, 다유형의 데이터(IoT, BIM, 360파노라마 이미지, 영상, CCTV 등)를 통합해
새로운 인사이트를 제공하는 통합 솔루션이 되겠다는 비전이 있습니다.
이런 방향을고려해 제품 구조 개선을 리드했습니다.
Behance에서도 포트폴리오를 확인하실 수 있습니다.
차례
1.
프로젝트 개요
2.
제품 핵심가치 재정의
3.
문제 정의, 솔루션 제안
4.
결과물
5.
프로젝트 문서 공유
6.
프로젝트 결과 분석
7.
회고
1. 프로젝트 개요
회사: (주)메이사
프로젝트 기간: 2021년 6월 — 2021년 11월
타겟 유저: 건설 현장 소장, 현장 직원, 본사 직원, 건설사 소속 연구소 직원
참여 인원: PO (1), Product Designer (본인 1), FrontEnd Engineer (2), BackEnd Engineer (2)
역할: 협의 주도, 와이어프레임, 상세 기획, 디자인 제작, QA
기여도: 기획 50%, 디자인 100%
배경
메이사는 스마트 건설 플랫폼을 개발/판매하는 스타트업입니다.
스마트건설 분야 종사자들의 '통합' 솔루션에 대한 니즈가 수면 위로 올라오고 있습니다.
각 대기업(종합건설사)들이 새로 도입하고 R&D하려는 기술 분야가 점점 다양해졌습니다.
이로 인해 다양한 기술을 적용한 제품이 만들어지면서 현장 사용자들은 사내솔루션과 추가로 이용하고 익혀야 하는 채널이 너무 많아지는 문제를 만납니다.
각 건설사들이 통합을 논의하는 ‘스마트안전협의회’가 2022년 창립되기도 했습니다.
이 협의회는 건설 솔루션 통합/표준화를 목표로 하고 있습니다. 국토교통부, 정부와도 연계되어 진행될만큼 국내 건설업 분야 내에서 중요한 문제입니다.
메이사는 다채널로 수집된 데이터들을 한 곳에 결합, 고객들에게 새로운 인사이트와 가치를 제공하겠다는 비전과 미션을 수립하게 됩니다.
그에 맞게 제품 안에서 새로운 데이터 분류 기준을 제안할 필요가 생겼습니다.
그런데 앞으로 나아가고자 하는 저희를 방해하는 장애물이 있었으니...
내부적
당시 기능개발 시 심각한 병목현상 발생
제품팀의 업무 비효율 발생
외부적
제품 첫 인상의 전달 어려움
파편화된 건설 데이터와 솔루션
목표 달성을 위해서는 이런 장애물을 먼저 타파할 필요가 있었습니다.
목표
1.
통합 솔루션이 되기 위한 토대를 마련하자!
2.
이를 방해하는 내외부적 장애물을 없애자!
실행
1.
데이터 구조 재분류
2.
기능별 중요도에 따라 재배치
3.
사용자의 중복 업무 삭제
2. 제품 핵심가치 재정의
MVP 버전의 핵심 가치 화면 [현장상황 상세], 그중 가장 확실한 반응을 얻은 도면 오버레이 기능을 사용한 화면
드론 촬영 사진으로 현재의 현장을 볼 수 있는 현장상황 상세 화면을 기준으로, 기존 유저들이 어떤 가치를 느낀 것인지 재분석, 가치를 재정의했습니다.
다음은 제가 제품의 핵심 가치를 재정의한 과정입니다.
1.
고객은 어떤 문제와 어려움을 겪고 있었나?
드넓은 공사 현장의 특성 상, 그동안 우리 고객들은 현장 내부에서도 공사 진척도를 한눈에 빠르게 파악하기 힘들었습니다.
2.
그것이 왜 문제인가?
공사 진척도공사 일정 수립 = 공사 기간 = 으로 연결됩니다.
그래서 공사 중 문제를 파악하고 공사기간을 줄이는 것이 메이사 고객의 가장 큰 목표입니다.
그러나, 1번 문제 때문에 정확한 공사 일정 수립이 어렵고, 설계와 어긋난 부분을 뒤늦게 파악하는 경우가 많았습니다.
3.
문제를 어떻게 해결해주었나?
메이사는 드론을 통해 취득한 (좌표 값을 가진) 현황 지도 데이터를 제공합니다.
고객(또는 잠재고객)은 이미 디지털로 설계된 (좌표 값을 가진) 설계 도면 데이터를 갖고 있습니다.
이를 오버레이 기능을 통해 현재미래 계획 을 직관적으로 확인할 수 있게 합니다.
4.
그래서 메이사가 고객에게 제공한 핵심가치는 무엇인가?
현황 데이터계획 데이터의 직관적인 비교를 통해, 고객의 시간과 비용을 줄일 수 있습니다.
그래서 제품에 있던 기능 중, 도면 오버레이 기능이 고객들에게서 가장 큰 반응을 얻을 수 있었습니다.
핵심 가치를 제공하는 지도 화면(현장상황 상세)은 각각의 데이터가 레이어처럼 동작합니다.
사용자들이 가장 크게 느낀 가치는 육안으로 설계와 다른 점을 파악해서, 공정 진척도를 관리할 수 있다는 점이었습니다.
→ 이를 바탕으로 더 다양한 이슈와 정보를 지도에서 한눈에 볼 수 있게 확장하고자 했습니다.
목표를 방해하는 장애물
하지만 당시 구조를 유지하며 더 많은 데이터 종류를 추가하게 되면, 내외부적으로 문제가 생길 것이 분명했습니다.
엔지니어 분들만으로 구축했던 MVP 배포 후, 계속된 새 기능 추가로 ‘경험 개선’을 해보지 못한 상태였습니다.
코드 상으로도 하드코딩 비중이 높았고,
DB 구조 통일성, 프론트엔드 구조 (=UI구조) 통일성이 없었는데요.
계약 권한, 사용자 권한에도 기조를 정한 적이 없어서 사소한 기능을 추가할 때에도 논의를 많이 했습니다.
영업팀에서 고객에게 우리 제품을 알릴 때, 제품의 핵심 가치를 이해시킬 때 언어적 설명이 매우 많이 필요했습니다.
다양한 니즈가 있는 사용자들이 많은 정보를 빠르고 정확하게 스캔하기에 힘들어질 것으로 예상되었습니다.
3. 문제 정의, 솔루션 제안
장애물 1: 병목현상
Why? 병목현상이 왜 생기고 있을까?
겉으로 보이지 않는 코드 부분은 하드코딩 비중이 정말정말 높은 상황이었습니다.
코드 통일성이 떨어지는 건 백엔드는 물론, 프론트엔드 코드도 마찬가지였어요.
컴포넌트 사용률이 매우 낮았고, 디자이너 없이 만들었던 UI를 대부분 유지하고 있었거든요.
겉으로 보이는 화면에는 데이터들이 분류 기준 없이 개발 순서대로 나열되어 있었어요.
이 두 가지 문제가 서로 영향을 끼치고 있었어요.
Why? 이렇게 된 근본적인 원인은 뭐지?
PMF를 찾은 뒤에도 저희는 권한이나 디자인에 대한 기조를 정하지 못한 채, 새로운 기능을 계속 붙여가며 달리고 있었습니다.
이제는 모든 것을 그때그때 협의해서 정하지 말고, 기본적인 기조를 협의해서 이후 리소스도 절약하고 확장성 있는 제품을 만들어야 한다는 공감대를 형성할 수 있었어요.
솔루션
사용 목적에 따라 다양한 건설 데이터들의 카테고리를 나누자.
통일성이 가장 필요한 정책의 기조를 정하자.
당시 제가 제안한 데이터 기준은 4가지였습니다.
1.
기본 데이터
주기적으로 촬영한 드론 데이터
2.
지도 도구
지도 위에 그림으로 표시하는 벡터 데이터
3.
비교 데이터
현재와 비교할 미래 계획을 담은 데이터
사용자들이 가장 크게 가치를 느낀 데이터가 속한 카테고리입니다.
공정 진척도 파악 목적으로 비교를 위해 업로드하는 데이터들을 묶었습니다.
4.
현황 데이터
드론 데이터 외로도, 현장 내 이슈를 더 알 수 있는 데이터
당시 다채널 데이터를 지원하고자 했지만, 앞으로 어떤 데이터를 가져올 수 있을지, 어떤 데이터가 임팩트가 강할지 알 수 없었기 때문에 이런 변수를 감안한 카테고리를 만들었습니다.
추후 의미있는 기능들이 붙게 된 후, 이 안에서도 카테고리를 분리해보자는 협의를 진행했습니다.
또 통일성이 가장 필요한 정책은
1.
프로젝트 권한에 따른 데이터 CRUD 기준,
프로젝트 권한
사용 가능한 기능
최고 관리자
프로젝트 내 모든 기능 [CRUD] 가능 + [프로젝트 자체 C, D] 가능
관리자
프로젝트 내 모든 기능 [CRUD] 가능
일반 사용자
일부 기능 [CRUD] 가능, 대부분의 기능 [R] 가능
방문자
대부분의 기능 [R] 가능
*CRUD: Create, Read, Update, Delete

2.
디자인 통일성과 컴포넌트 활용 등이었습니다.
디자인 통일성을 위한 액션은 당시 프론트엔드를 담당하고 계시던 E님께서 Material UI라는 프레임워크를 제안해주셨는데요. (이하 MUI) MUI는 Google에서 나온 Material Guide를 바탕으로 만들어진 리액트 프레임워크입니다.
기존에는 100% 커스텀으로 운영되던 디자인을 MUI를 통해 효율적으로 통일성 있는 시스템을 구축하고, 추후 유지보수도 편하게 하자는 의도였죠!
저도 처음 접해보는 방식이었지만 빨리 효율적인 시스템을 구축해야 하는 상황이었기 때문에 제안을 받아들여 함께 이 프레임워크를 공부하고 에셋을 적용해볼 수 있었습니다. MUI에 아이콘, 피그마 컴포넌트 파일 등 많은 에셋이 바로 활용 가능한 상태로 제공되는 게 큰 장점이었습니다.
우리 제품이라서 필요한 특이한(!!!) UI들이더라도 기존 MUI 컴포넌트를 베이스로 커스텀하는 식으로 사용할 수 있었습니다.
장애물 2: 기능 발견, 제품 이해가 오래 걸린다.
당시 영업팀, 신규입사자 분들 등 제품을 이해하거나 이해시키는 것이 오래 걸린다는 의견이 많았습니다.
초반에는 저도 그랬었고, 신규입사자 분들은 대부분 건설 도메인에 대한 이해도가 없는 상태이기 때문에 더 그럴 것이란 생각을 했었는데요.
영업팀 분들도 고객을 대상으로 제품을 설명할 때 힘들다며, 비슷한 내용을 호소하셔서 자세히 들여다보게 되었습니다.
Why? 왜 그렇게 생각하셨지?
언어적인 설명이 더 많이 필요하다.
제품이 제공하는 핵심가치가 직관적이지 않다.
Why? 왜 그렇게 된 거지?
우리가 어필하고 싶은 기능별 중요도와 화면 상 위계가 다르게 되어있다!
저희는 PMF를 찾은 이후, '도면'과 관련된 기능을 가장 중요하게 생각하고 움직였습니다.
그런데 제품을 처음 보는 사람들이 이런 핵심 가치를 눈치채기는 어려웠는데,
저는 당시 화면에서 일반적인 기능(보기 전환, 지도도구 추가)이 지나치게 많은 공간과 주목성을 가지고 있기 때문이라고 정의했습니다.
솔루션
중요도 낮은 기능은 덜 강조하자.
해당 프로젝트를 통해서 사용자들이 가장 자주 사용하고, 가장 필요로 하는 기능을 잘 찾을 수 있게 하고자 했습니다.
일단 기능별로 저희가 강조하고 싶은 정도를 정렬해봤고, 재정비가 필요한 기능들을 도출해봤습니다.
대표적인 기능이 2D↔3D 뷰 전환을 하는 기능, 다운로드, 지도 도구를 추가하는 기능들이었습니다.
화면 상단에 가장 크고 진하게 되어있지만 PMF를 찾은 이후부터는 그저 일반적인 기능들이었죠.
이런 기능들은 좀더 작게, 주목성을 덜 가지는 컬러를 적용해 다시 디자인했습니다.
4. 결과물
2D ↔ 3D 뷰 전환 버튼의 디자인, 배치 변경
2D와 3D뷰를 메이사가 제공한다는 사실은 더이상 가장 강하게 강조될 필요는 없어졌으므로, 눈에 덜 띄게, 하지만 상단에서 먼저 선택해 원하는 뷰를 고를 수 있게 변경했습니다.
데이터 선택 외 기능들을 상단 바(Top Bar)로 이동
날짜별 비교, 공유, 인쇄, 다운로드처럼 올라간 데이터를 활용하는 기능들은 사용자에게 2차적인 가치를 제공하는 것이므로 따로 상단 바에 분리하여 배치했습니다.
지도 도구 추가 버튼을 지도 영역에 배치
지도에서 직접 클릭해서 추가하는 데이터이므로, 지도 영역에서 바로 클릭할 수 있도록 해 마우스 이동을 줄이고자 했습니다.
카테고리에 대한 설명
새로 적용된 데이터 분류법은 사용자에게 처음 제시된 구조입니다. 분류 기준이 궁금한 사용자는 세부 정보를 찾아볼 수 있도록 툴팁으로 설명을 제공했습니다.
그룹핑 개선을 위한 아코디언 컴포넌트 활용
개선이 필요했던 데이터별 인지적 그룹핑을 위해, 대분류 카테고리 사이에 여백을 두고, 중분류를 접고 펼칠 수 있는 아코디언 컴포넌트를 활용해 개별 파일이 바로 밑에 리스트업 되도록 기획했습니다.
컴포넌트 제작
Material Design Guide를 바탕으로 만들어진 프레임워크인 Material UI(v.4)를 기반으로 컴포넌트를 커스텀하여 제작하고 개발에 적용했습니다. 데이터 유형에 따라 각각 다른 기능이 있으므로 데이터별 UI/기능 차이에 대한 전달이 중요했기에 케이스에 따른 예시를 모아 커뮤니케이션하기도 했습니다.
5. 프로젝트 문서 공유
솔루션 1을 배포한 다음, 저희 팀이 이렇게 오랜 시간을 들이는 이유, 기대효과, 진척상황에 대해서 전사적으로 공유할 필요가 있겠다고 생각해서 문서를 작성해 공유하기도 했습니다.
내부적으로는 이 프로젝트가 제일 가치가 큰 화면을 리모델링 해야 한다는 뜻으로 [안방 인테리어]라고 부르고 있었고, 그동안 하고 있던 것들, 솔루션 1에서 이룬 것들과 솔루션 2를 통해 이루고자 하는 것들도 설명드릴 수 있었습니다.
6. 프로젝트 결과 분석
💬 사용자 피드백
👷‍♂️
외부 사용자
각 솔루션을 배포한 뒤 따로 설문이나 인터뷰를 진행하진 않았지만, 국내사업 팀장님을 통해 들은 외부 피드백을 모아볼 수 있었습니다. (시행사 현장 관리자, 시행사 본사 관리직원)
메이사를 구매하려고 했었는데, 리뉴얼 이후에 공무팀(구매팀)을 설득하기가 좀더 편해진 것 같아요.
기능은 더 많아졌지만 정리 정돈은 잘 되어 있어 좋아요.
제품 초반부터 메이사 제품을 써왔는데, 솔직히 말해서 이제 좀 그럴싸해졌다고 느껴요. 진짜 ‘제품’이 되었다는 느낌?
도면을 계속 업로드하지 않아도 돼서 좋아요.
회사에서 메이사를 구독해 효율이 올랐다고 실적을 좋게 평가받았어요.
글씨가 많이 작아졌더라고요. 원래 쓰던 지도 도구나 도면 파일이 이제 잘 안보여요.
👨‍💼
팀 내 사용자
사내 기술지원팀, 영업팀, 국내사업 팀장님 등 내부 목소리를 직접 들어볼 수 있었습니다.
앞으로 기능을 많이 추가하게 될텐데, 그 전에 정리해둬서 정말 다행이라고 생각했어요.
고객들 앞에서 기술 시연할 때, 데이터별로 위치나 기능을 설명하기가 편해졌어요. 화면을 보여주자마자 첫 인상에서 직관적인 가치 제안을 할 수 있게 되었기 때문이라고 생각해요.
배포 6개월 이후 기준으로 제품 팀의 기능 대응 속도나 들어가는 리소스는 체감 30% 감소했어요.
디자인 개선에 따른 코드의 통일성과 확장성도 체감 50% 정도 좋아졌어요.
🧑‍⚖️ 결론과 인사이트
이 프로젝트는 내부, 외부 사용자들에게 대체로 만족감을 주었다고 판단했는데요.
제품 확장을 위한 데이터 카테고리 제안, 핵심가치 직관성을 키워야 한다는 가설이 맞았던 것이라고 생각했습니다.
7. 회고
🥰 좋은 결과와 과정에 대한 회고
디자인 구조 개선에 따른 코드 구조 통일, 글로벌화를 대비한 확장성 있는 구조 구축을 할 수 있었습니다.
기존엔 기능이 새로 추가되는 대로 UI를 나열하다보니 사용자의 목적에 따른 기능 그룹핑, 권한 분리가 제대로 이루어지지 않아서 레거시가 많이 쌓였고 유지보수가 힘들었습니다. FrontEnd에서는 프로젝트를 통해 지난 2년간 쌓인 레거시의 약 90%를 정리하며, 확장성을 고려한 코드로 보완할 수 있었습니다.
디자인, 즉 프론트엔드 구조가 개선되면서, 앞으로 어떤 기능 요청이 와도 ‘어디에 어떻게 붙이면 되겠다’는 식으로 좋은 위치를 구상할 수 있게 되어서 정말 좋다는 피드백을 들을 수 있었습니다.
문제 해결을 위한 태도를 배웠습니다.
아직 혼자서 디자인을 할 때였고 잘하고 싶은 마음이 정말 컸지만, 일을 잘
마무리하기 위해서 프로의 태도를 지녀야겠다고 생각했습니다.
제가 생각했던 프로의 태도는 일의 퀄리티는 제가 할 수 있는 최선을 다해서 책임지는 것은 당연하고, 그 과정이 완벽하지 않고 부족하더라도, 심각한 문제 없이 어떻게든 완수하는 것이었습니다. 그러기 위해서라도 주변에 도움을 많이 요청해야겠다고 생각했습니다. 어떻게든 이 문제들을 해결하려면 여기저기 들쑤시고 다녀야 일이 진행될 거라고 생각했습니다. 저에게 이 문제를 해결하라고 맡겨주신 것은 그렇게 하라는 허락을 받은 거라고 생각하면서요.
역할 확장과 성장을 이룰 수 있었습니다.
기존 화면은 디자이너 없이 만들어진 구조와 디자인이 적용되어 있었습니다. 그래서 잘 몰랐던 각각의 파일 유형, 기능, 정보 구조 개발의 의도를 알아가며 제품에 대해 훨씬 더 잘 알게 되었고, 어떻게 하면 이 문제를 함께 해결할 수 
있을지 팀원들과 더 깊은 소통을 자주 할 수 있었습니다. 완벽하기보다는 원래 되던 기능이 안되는 경우 없이 잘 작동하는 구조를 
설계하려고 했고, 덕분에 동료들과의 협업을 많이 시도하고 때론 이끌 수도 있었습니다.
이때 스스로 생각하는 제 역할(프로덕트 디자이너)과 동료들이 생각하는 제 역할의 교집합이 커졌다는 것을 체감할 수 있었습니다.
개인과 팀 전체가 학습하는 소중한 시간이었습니다.
이 프로젝트는 「3.0」 또는 「안방 인테리어」라는 이름으로 불리며 오랜 시간 진행되었습니다. 모든 제품의 데이터가 모이는 제품이라서 거의 대부분의 API와 파일을 건드려야했고, 그래서 각 제품 담당자들과의 커뮤니케이션도 매우 중요했습니다.
그래서 저를 비롯한 팀원 모두가 많은 문제를 마주하고 해결해가며 완성한
프로젝트였고, 그렇기 때문에 제품과 팀에 대한 애정이 더욱 깊어지기도 
했습니다.
Subscribe to 'billieyoung'
안녕하세요, 프로덕트 디자이너 김신영입니다.
Subscribe
👍
3
Billie
Meissa 브랜드 아이덴티티 디자인
프로젝트 개요 회사: (주)메이사 프로젝트 기간: 2021년 5월 — 2021년 6월 (1개월) 참여 인원: Product Designer (본인) 디자인 기여도: 100% 역할: 프로젝트 기획, 리드 프로젝트 배경 메이사는 스마트 건설 플랫폼을 개발/판매하는 회사로, 국내 유일 드론 영상 분석 기술을 갖춘 곳입니다. 드론으로 촬영한 2D 이미지를 정합하여 고해상도 지도로 활용하거나 3D로 모델링 된 가공 데이터를 제공합니다. 2020년, (주)카르타에서 (주)메이사로 사명을 변경하면서 새로워진 비전과 미션을 반영하고자 Brand Identity를 업데이트할 필요가 있었습니다. Meissa Vision 단순 변환 데이터 제공을 넘어 loT, BIM, 360워크스루, CCTV 등 다채널로 수집된 데이터 결합하여 고객들에게 새로운 인사이트와 가치를 제공하겠다 1. Symbol 기존에는 로고 이미지와 상관 없이 원하지 않아도 ‘드론'이 주로 강조되는 경향이 있었습니다. 기존 로고는 일부러 건설사들처럼 두껍고 우직한 이미지를 만들어서 건설 산업의 회사라는 걸 알리려는 의도였다고 해요. 메이사로 로고를 바꾸게 된 시점에는 ‘기술 회사' 느낌을 더 강조하고 싶다는 니즈가 생겼습니다.
Billie
MeiDay: 신규 제품 고객 인터뷰 진행과 MVP 기획안 변경
신규 제품 고객 인터뷰 진행과 MVP 기획안 변경 현장 근로자의 위치를 웹에서 실시간으로 확인할 수 있는 안전 위치 공유 서비스 (구 MeiDay, 현 Meissa Guard)의 MVP를 구축했습니다. 인터뷰를 진행하면서 가설을 검증하고 고객의 진짜 페인포인트를 찾고 솔루션을 도출했습니다. 인사이트를 팀원들과 공유하고 MVP 기준을 바꾸면서 변경을 주도하는 과정을 경험했습니다. 차례 프로젝트 개요 초기 가설과 컨셉안 고객 인터뷰 결과물 프로젝트 회고 1. 프로젝트 개요 회사: (주)메이사 프로젝트 기간: 2022년 4월 — 2022년 5월 타겟 유저: 건설현장 안전관리자, 건설본사 안전팀, 건설현장 근로자 참여 인원: PO (1), Product Designer (본인 포함 2), FrontEnd Engineer (1), BackEnd Engineer (2), Flutter Engineer (1) 역할 및 기여도: 고객 인터뷰 및 솔루션 도출, 디자인 룩앤필 제작 (70%) 와이어프레임, 플로우 기획 (50%) 방향성 변경 이후에는 메인 디자이너 교체하여, 상세 디자인 대응 및 QA 파트를 서포트
Billie
Meissa Platform: 이슈 관리 기능 제안, 인터뷰를 통한 가설 검증
Meissa Platform: 이슈 관리 기능 제안, 인터뷰를 통한 가설 검증 건설은 프로젝트 기간이 길고, 의사소통 이해관계자가 많습니다. 메이사는 스마트건설 솔루션이 주 제품으로, 건설의 다양한 업무를 디지털화합니다. 현장에서 메신저로만 이슈를 관리할 때 생기는 어려움을 해소하고자 했습니다. 고객의 요구가 명확한 B2B 제품이지만 고객의 요청이 아닌, 팀 내부에서 고객의 문제를 파악해 [문제정의, 가설수립, 검증, 피드백] 사이클을 진행한 프로젝트였습니다. Behance에서도 포트폴리오를 확인하실 수 있습니다. 차례 프로젝트 개요 배경 상세 문제, 가설, 솔루션 결과물 현장 인터뷰, 인사이트 프로젝트 결과 분석 프로젝트 종료 이후 개선 이터레이션 회고 마치며 1. 프로젝트 개요 회사: (주)메이사 프로젝트 기간 기능 논의와 제작: 2022년 8월 — 2022년 11월
👍
3