공사중! Research Note Researchers: Shinyoung Kim(Billie), Jen, Han Research Date: August 29th, 2022

goming goming은 칸반 보드 형식의 생각 관리 앱입니다. 저만의 자잘한 고민들을 한꺼번에 관리하는 방식을 칸반 보드 스타일의 앱으로 풀어낸 컨셉 프로젝트입니다. 프로젝트 개요 개인 프로젝트 프로젝트 기간: 2023년 6월 저는 제가 운영하는 1인 비공개 카페에서 고민을 털어둡니다. 카페 게시판 중 고민을 임시 저장해두는 저장소 [고민들 일단 임시 저장] 게시판이 있고, 그 중 해결된 고민이 생기면 그런 고민들을 옮기는 저장소 [해결한 고민들이 오는 곳] 게시판이 있습니다. 카페 게시글로 관리해도 괜찮지만, 가끔 휴대폰에서 빠르게 관리하고 싶다는 생각이 들어 '메모' 앱을 사용해봤지만 텍스트를 일일이 적고 지우고 복사하고 붙여넣는 과정이 번거로웠습니다. '노션' 앱은 제 고민들을 관리하기에는 기능이 너무 많고 무거웠습니다. 다른 노트테이킹 앱들도 마찬가지였습니다. 카페 게시글로 관리할 때 불편했던 점과 니즈를 추려봤습니다. 해결되지 않은 고민과 이미 해결된 고민을 한눈에 보고 싶다 해결되었다고 생각한 고민을 다시 고민하게 될 때가 있음 해결되지 않은 고민을 해결된 고민으로 한번에(쉽게) 옮기고 싶다 네이버 카페에서 옮기려면 '글 진입 > 수정 > 게시판 변경'을 해야함 회사에서 자주 쓰는 칸반 보드처럼 손쉽게 바꿀 수 있다면 얼마나 좋을까, 해서 만들어 보았습니다. goming은 뭘 고민하고 있었는지도 잊을 만큼 고민이 많은 분들을 위해 태어났어요. goming은 칸반 보드 형식의 생각 관리 앱이에요. 저만의 자잘한 고민들을 한꺼번에 관리하는 방식을 칸반 보드 스타일로 풀어낸 컨셉 앱 프로젝트예요. 꾹 눌러서 잡고 놓으면 끝. 참 쉽죠? 적어둔 고민을 해결했다면 해결 칸으로 옮기기만 하면 돼요. 고민을 적기도, 수정하기도 쉬워요. 추가 버튼만 누르면 바로 기록 시작! 이미 작성한 카드를 누르면 내용 확인도 완전 가능. 멤버십 결제도 앱에서 한번에! 초기에 함께하신다면 한 번만 결제해서 평생 쓸 수 있는 얼리버드 멤버십 어때요?

프로젝트 개요 회사: (주)메이사 프로젝트 기간: 2021년 5월 — 2021년 6월 (1개월) 참여 인원: Product Designer (본인) 디자인 기여도: 100% 역할: 프로젝트 기획, 리드 프로젝트 배경 메이사는 스마트 건설 플랫폼을 개발/판매하는 회사로, 국내 유일 드론 영상 분석 기술을 갖춘 곳입니다. 드론으로 촬영한 2D 이미지를 정합하여 고해상도 지도로 활용하거나 3D로 모델링 된 가공 데이터를 제공합니다. 2020년, (주)카르타에서 (주)메이사로 사명을 변경하면서 새로워진 비전과 미션을 반영하고자 Brand Identity를 업데이트할 필요가 있었습니다. Meissa Vision 단순 변환 데이터 제공을 넘어 loT, BIM, 360워크스루, CCTV 등 다채널로 수집된 데이터 결합하여 고객들에게 새로운 인사이트와 가치를 제공하겠다 1. Symbol 기존에는 로고 이미지와 상관 없이 원하지 않아도 ‘드론'이 주로 강조되는 경향이 있었습니다. 기존 로고는 일부러 건설사들처럼 두껍고 우직한 이미지를 만들어서 건설 산업의 회사라는 걸 알리려는 의도였다고 해요. 메이사로 로고를 바꾸게 된 시점에는 ‘기술 회사' 느낌을 더 강조하고 싶다는 니즈가 생겼습니다. 당시 새로 설정된 제품 목표를 바탕으로 메이사 심볼을 제작했습니다. 기존 [드론 데이터] + [BIM], [CCTV], [360도 파노라마 이미지], [실시간 위치] ... 등등 더 다양한 유형의 건설 현장 데이터를 Meissa Platform 안에 ‘융합'하여 생기는 인사이트와 가치를 전달하겠다는 의미를 담게 되었습니다. 메이사에서 제공하고자 하는 '융합'은 일반적인 '통합'과 다릅니다. 건설에는 매우 다양한 데이터와 문서가 필요하지만, 정작 한 곳으로 잘 모이지 않고 각각 다른 솔루션을 사용하며 비효율을 감내하고 있습니다. 메이사는 이러한 문제를 해결하기 위해 다양한 데이터를 융합하여 생기는 인사이트를 제공하고자 합니다. 그래서 우리 플랫폼에 다양한 데이터가 모이는 장면을 상상한 시안이 최종 채택되었습니다. 채택 이후에 알게된 것 아주 많은 시안이 나왔었지만 결국 CARTA 당시 심볼과 적절한 유사성(육각형, 청록색 ...)이 있는 시안으로 채택되었습니다. CARTA 고객사, 인지하던 회사들이 금방 연결해서 기억할 수 있는 장점도 있었겠다 싶어요. 2. Typefaces 언어에 따라 쓰는 폰트가 달라요. 국어 문서 : Pretendard 일어 문서 : Pretendard JP 영어 문서 : Eloquia 2-1. 영어용 글꼴 - English : Eloquia Eloquia라는 Grotesk(그로테스크) 계열의 유료 글꼴을 쓰고 있습니다. 메이사는 건설사를 대상으로 한 B2B 기업이므로 이성적, 논리적인 수렴형 메시지를 담은 기업입니다. 따라서 중립적이고 이성적인 인상을 줄 수 있는 Grotesk 계열이면서도, 지나치게 차갑고 딱딱한 분위기를 내지 않게 하기 위해서 Geometirc의 대중적인 특징도 함께 품은 글꼴을 최종 선택했습니다. Geometric 계열에는 대표적으로 Google Sans나 삼성 Sharp Sans가 있습니다. 이런 글꼴은 대중적이고 친근한 느낌이 강한데, 제목이 아닌 본문과 같은 줄글에서 사용하게되면 눈이 금방 피로해지기 때문에 여기 저기 통일하여 사용하기 까다로운 경향이 있습니다. 저는 작업 효율성(타부서와의 커뮤니케이션 미스 줄이기, 적절한 폰트 찾는 시간 줄이기 ...)을 위해 로고부터 본문까지 다 커버 가능한 서체를 원했습니다. 저희가 주고 싶은 이미지는 이성적, 논리적인 수렴형 메시지에 가깝습니다. 근데 너무 차갑고 딱딱한 분위기는 또 안된다고 생각했어요. 그래도 고객들에게 우리가 만든 서비스가 금방 잘 쓸 수 있을 것처럼 다가오면 좋겠다는 마음도 있었거든요. → Eloquia는 Grotesk 계열 글꼴 중에서도 Geometric의 성격을 어느정도 품고 디자인 되었기 때문에, 제 고민을 해결해줄 수 있었습니다. Display(제목용이라고 생각하셔도 무방)와 Text(본문용이라고 생각하셔도 무방)용 글꼴 구분이 잘 되어있고, 돈을 주고 사는 만큼 두께도 다양하여 확장성까지 있다고 생각했어요. 2-2. 국어/일어용 글꼴 - Korean(, Japanese) : Pretendard (, JP) Pretendard라는 무료 글꼴을 사용하고 있습니다. 원래는 Noto Sans KR을 쓰고 있었지만 부족함이 많았어요. 한글, 숫자, 영문 디자인이 서로 조화롭지 않았어요. 기본 자간이 넓어서, 매번 자간을 수정해줘야 하는 추가작업이 필요했어요. 영문 폰트를 Eloquia로 정한 얼마 뒤, 국내에서Pretendard라는 디자이너들의 고충을 해소해줄 무료 폰트가 배포되었어요. 한글, 숫자, 영문 디자인이 훨씬 조화로웠어요. 숫자/영문 디자인이 영문 글꼴로 지정했던 Eloquia와 잘 맞아떨어졌어요. Web에 적용했을 때, Window 환경에서도 글자를 판독할 수 있는 정도가 Noto Sans와 비슷했어요. (그 전에 Spoqa라는 글꼴을 적용했을 때는 엄청 심하게 깨졌었고, 판독성에 큰 영향을 미쳤거든요) 3. Colors Point Color Point Color라고 부르지만, 실제로는 Main Color, Primary Color 등 사용하는 용어는 정해져있지 않아요. 청록색이 인쇄나 안좋은 모니터로 보는 UI에 쓰기엔 모호하고 어려운 부분이 있는데도 유지하기로 했어요. 일단 로고만 바뀌는 게 아니라 사명까지 한 번에 바뀌는 것이기 때문에, 어느 정도 이전 로고에서 보여주던 컬러를 유지하는 게 좋겠다고 합의했었거든요. 이미 디자인된 플랫폼 디자인이 청록색에 맞춰서 되어있기 때문에 (물론 컬러 코드 바꾸면 되는 거기야 하지만… 공수가 더 들 수밖에...) 대응 리소스를 줄일 수 있는 방안이기도 했어요. CARTA 로고를 디자인했던 디자이너의 의도대로, 신뢰를 나타내는 컬러로도 적당하다고 판단했고요. Light 모드에서는 #00ACC1, Dark 모드에서는 #26C6DA를 사용해요. Background Color 포인트 컬러인 청록색을 받쳐주던 남색Navy을 블랙Black으로 변경했어요. 원래 청록색은 완전한 파란색/초록색의 옆에 있어야 더욱 청록처럼 보이는 경향이 있고, 그래서 남색을 같이 썼었거든요. 엔젤스윙, Xite cloud를 비롯한 경쟁사부터 + (특히 한국이 그런건지...) 기업 로고로 파란색을 너무너무너무 많이 쓰는 경향이 있어서, 조금이라도 다르게 하고 싶은 마음도 있었어요. Grey Color 회색조 컬러는 가벼운 사용경험을 위해서 Cool Grey 계열을 사용합니다. 4. Elements (Products) 제품의 특징에 따른 결정 메이사는 건설현장의 다양한 데이터를 보여줘야 하는 특징이 있는데요. → 그래서 한 화면 안에서 많은 정보들을 보여줄 때 사용자가 부담을 덜 수 있는 방향을 고민하게 되었고, → 각 정보들끼리의 그룹핑이 잘 되게 하기 위해 카드 UI/디자인을 적극적으로 활용하게 되었습니다. Card UI는 보통 한꺼번에 많은 정보를 보여줘야 할 때, 각 정보들 간 구분이 잘 될 수 있도록 Card 안에 묶어주는 디자인 형식입니다. 그래서 Apple에서도 iOS 14와 macOS 11 (Big Sur) 버전부터 적극적으로 활용하고 있는 스타일이기도 하여 채택하고자 했습니다.

신규 제품 고객 인터뷰 진행과 MVP 기획안 변경 현장 근로자의 위치를 웹에서 실시간으로 확인할 수 있는 안전 위치 공유 서비스 (구 MeiDay, 현 Meissa Guard)의 MVP를 구축했습니다. 인터뷰를 진행하면서 가설을 검증하고 고객의 진짜 페인포인트를 찾고 솔루션을 도출했습니다. 인사이트를 팀원들과 공유하고 MVP 기준을 바꾸면서 변경을 주도하는 과정을 경험했습니다. 프로젝트 개요 회사: (주)메이사 프로젝트 기간: 2022년 4월 — 2022년 5월 타겟 유저: 건설현장 안전관리자, 건설본사 안전팀, 건설현장 근로자 참여 인원: PO (1), Product Designer (본인 포함 2), FrontEnd Engineer (1), BackEnd Engineer (2), Flutter Engineer (1) 역할 및 기여도: 고객 인터뷰 및 솔루션 도출, 디자인 룩앤필 제작 (70%) 와이어프레임, 플로우 기획 (50%) 방향성 변경 이후에는 메인 디자이너 교체하여, 상세 디자인 대응 및 QA 파트를 서포트 프로젝트 배경 건설업 사고사망자 수는 최근 10년간 변화가 없었고, 사고로 사망할 확률이 타산업에 비해 4.3배 높습니다. 그리고 건설 안전 제도에 대한 사회적, 국가적 요구 수준이 보다 높아졌습니다. 기존 건설 산업계 내 안전 관리 기술에 대한 필요성이 대두되어 [안전] 관련 솔루션과 기술에 돈을 더 투자하고자 하는 움직임이 생기고 있었습니다. 목표 근로자 위치와 현장 이미지, 지도를 함께 볼 수 있는 방안 개발 관리자가 근로자 상태, 안전을 쉽게 확인할 수 있는 제품 개발 실행 가설 수립 및 열린 질문을 통한 인터뷰 인터뷰 해석을 통한 현재 구상 중인 기능의 타당성 검토 현재 고려하지 못했던 니즈 파악 → 추가 기능 백로그화 차례 프로젝트 개요 최초 컨셉안 고객 인터뷰 결과물 프로젝트 회고 최초 컨셉안 건설 현장은 수많은 근로자들의 정보를 관리해야 하는데, 수기로 하는 곳도 많고 그나마 디지털화된 곳은 로컬 엑셀 파일을 계속 업데이트하며 관리하는 상황입니다. 그래서 웹 기반 솔루션(SaaS)이 나온다면 고객사들이 반가워할 거라고 생각했었죠. 건설사들이 근로자들의 어떤 정보들을 수집하는지 조사해 컨셉안을 제작했습니다. 이름과 휴대폰 번호는 기본이고, 생년월일 같은 개인 정보도 필요합니다. 고령의 근로자인지 확인하기 위해 나이를 알아야 하거든요. 위급 상황을 대비한 추가적인 건강 정보도 필요한데, 성별이나 혈액형, 혈압 등등의 정보도 포함합니다. 안전관리를 위한 서비스인만큼 혈액형 같은 비교적 민감한 개인정보까지 필요한 거죠. 본래 이런 정보들을 근로자들이 종이 서류로 제출하고, 관리자들이 엑셀에 옮겨 적거나 폴더로 끼워 관리하는데, 이런 과정도 저희가 간편화할 수 있을 거라고 생각했습니다. 고객 인터뷰 인터뷰 진행 일시: 2022. 4. 8. 장소: K건설 본사 3층 인터뷰어: 프로덕트 디자이너 1명, PR담당자 1명, 영업팀장 1명 인터뷰이: K건설 스마트건설팀 과장 2명, 대리 1명 가설 1 건설 현장, 본사는 근로자 개인/건강정보를 모두 수기로 관리하고 있다. 기록과 관리, 연락이 편리한 소프트웨어 솔루션이 있다면 도입을 원할 것이다. 파악한 사실 1 개인정보 보안 문제로, 일부러 소프트웨어를 사용하지 않는다. 가설 2 건설 현장 근로자 안전 교육 시간을 이용해 앱 다운로드, 회원가입을 가이드하는 과정은 간편할 것이다. 파악한 사실 2 근로자 안전 교육 시, 회원가입 가이드 과정이 힘들다. 관리자의 이중작업 (직접 눌러가며 도와줘야 함) 외국인 근로자 (소통 어려움, 번역기술 부족) 인터뷰를 하고 보니, 기존 컨셉은 MVP로 제안하기엔 너무 복잡했습니다. 특히 근로자별 정보를 많이 갖고 있어야 관리자들의 이중작업이 줄어들 거라고 생각했기 때문에, 근로자가 앱을 설치한 뒤 가입하는 과정이 다소 어려워진 상태였습니다. 프로젝트(본인이 속한 현장) 번호 입력/인증 회원가입을 위한 휴대폰 번호 입력 이름, 생년월일, 성별, 국적, 혈액형 등... 앱을 사용하기 위해 입력해야 하는 정보들이 굉장히 많을 수밖에 없는 거죠. 젊은 내국인들은 금방 할 수 있겠지만, 새로운 앱이 낯선 고령 근로자나 외국인 근로자들에게는 큰 장벽이 되는 과정이었습니다. 그래서 결국 앱 설치와 회원가입을 위해 관리자들의 이중작업이 더 늘어나는 상황이 예상됐고요. 새로운 솔루션 도출 저희가 처음 세웠던 가설과 실제로 알게 된 고객들의 프로세스가 매우 다르다는 걸 알게 되었고, 회원가입을 최소한의 정보로, 최대한 쉽게 단순화하는 방향으로 솔루션(기획)을 완전히 바꿔야겠다는 결론을 도출했습니다. 결과물 Before 보안을 고려해서 프로젝트(현장) 관리자에게 프로젝트 고유 번호를 공유 받아 입력해야 했습니다. 휴대폰 번호를 인증해야 했습니다. 또 글로벌을 고려하여 국가를 선택할 수 있게 했었습니다. 인증 후 입력할 프로필 정보를 실제 기록과 유사하게 구성했습니다. 기본: 이름, 휴대폰 번호 건강상 필요한 추가정보: 생년월일, 성별, 국적, 혈액형 ... After 본인이 일할 프로젝트(현장)별 고유 해시코드로 제공된 QR 이미지를 현장에 출근할 때 인식하여 체크인할 수 있게 변경했습니다. 회원가입에 필요한 정보를 이름, 휴대폰번호로 줄이고 취약 근로자 여부는 버튼형으로 제시해 선택이 쉽도록 했습니다. 그러면서 메이사 플랫폼에서 다양한 정보를 관리할 수 있게 하려던 기능도 자연스럽게 없어졌고, 근로자 위치를 기록하고자 하는 니즈를 확인하기 좋은 형태로 출시할 수 있었어요. 그 다음으로 필요한 위험구역 설정, 대피 알림, SOS 기능 같은 건 우선순위를 낮추어 진행할 수 있었구요. 지금(2024년 기준)은 위험구역 설정, 대피 알림까지 구현이 된 상황입니다! 프로젝트 회고 잘한 점 기획 컨셉을 많이 제안해두고 이미 디자인을 시작했었지만, 인터뷰 후 기획 방향을 바로 바꾸기로 협의하고 화면에 반영한 속도가 매우 빨랐습니다. 실제 개발이 들어가기 전에 기획 변경을 훨씬 가볍게, 빠르게 진행했기 때문에 리스크를 덜 수 있었습니다. 아쉬운 점 인터뷰 일정이 연기되어, 이미 기획을 많이 진행한 뒤에야 가설을 검증할 수 있던 점이 아쉬웠습니다. 전화 인터뷰 등으로 좀더 부담이 적은 방식을 고려해보게 되었는데, 물론 그러기 위해서는 이렇게 주요 고객과 직접 만나 라포를 형성하는 과정이 선행되는게 좋다는 생각도 들었습니다.

Meissa Platform: 이슈 관리 기능 제안, 인터뷰를 통한 가설 검증 건설은 프로젝트 기간이 길고, 의사소통 이해관계자가 많습니다. 메이사는 스마트건설 솔루션이 주 제품으로, 건설의 다양한 업무를 디지털화합니다. 현장에서 메신저로만 이슈를 관리할 때 생기는 어려움을 해소하고자 했습니다. 고객의 요구가 명확한 B2B 제품이지만 고객의 요청이 아닌, 팀 내부에서 고객의 문제를 파악해 [문제정의, 가설수립, 검증, 피드백] 사이클을 진행한 프로젝트였습니다. Behance에서도 포트폴리오를 확인하실 수 있습니다. 프로젝트 개요 회사: (주)메이사 프로젝트 기간 기능 논의와 제작: 2022년 8월 — 2022년 11월 인터뷰 기획 및 진행: 2022년 12월 — 2023년 3월 타겟 유저: 건설 현장 관리자(공사, 안전, 감리), 협력업체별 대표, 골프장 잔디관리팀 참여 인원: PO (1), Product Designer (본인 1), FrontEnd Engineer (1), BackEnd Engineer (1) 역할: 프로젝트 목표 협의 주도, 킥오프 오퍼레이션 와이어프레임, 플로우 기획, 상세 디자인 대응, 테스트 케이스 작성 및 QA 참여 고객 인터뷰 및 솔루션 도출 → 팀원들에게 공유 기여도: 기획 50%, 디자인 100% 배경 메이사는 드론 데이터 기반 스마트건설 기술로 IoT 등 더 다양한 데이터까지 관리하는 ‘건설 통합 솔루션’이 되고자 합니다. 드론으로 촬영한 이미지를 정합해 2D 고해상 지도와 3D 모델링 데이터를 제공합니다. 건설 현장 업무는 다양하게 처리되지만 메신저(카카오톡)를 통해 이미지를 전송해 작업 지시와 보고를 하는 모습을 가장 흔하게 볼 수 있었습니다. 또 이를 컴퓨터로 다운로드해 보고서로 옮겨서 만든 한글 파일로 본사 보고가 오가는 과정이 있는데, 이 과정은 회사와 관계 없이 전체적으로 띠는 양상이라는 것을 알게 되었습니다. 건설은 1년에서 2년이 기본적인 장기 프로젝트입니다. 특히 이해관계자가 많고 커뮤니케이션이 까다로워 이슈를 추적하고 관리할 때 메신저만으로는 어려운 점이 있고, 그런 어려움을 메이사가 해결해주고자 했습니다. 목표 작업 추적에 용이한 구조 생성 대화 및 파일 히스토리 기록 실행 이슈 위치 정보 제공 스레드로 이슈 관리 파일 첨부 및 댓글 기능 차례 프로젝트 개요 배경 상세 문제, 가설, 솔루션 결과물 현장 인터뷰, 인사이트 프로젝트 결과 분석 프로젝트 종료 이후 개선 이터레이션 회고 마치며 배경 상세 건설 현장에서는 현장 이미지를 [카카오톡]으로 주고 받으며 일하고 있었습니다. 채팅만으로는 이슈를 관리하는 데에 어려움이 있을 것 같았고, 이미지와 함께 이슈를 어떻게 하면 잘 관리하게 도울 수 있을까 고민하게 되었는데요. 저희 서비스가 생기기도 전부터 사랑을 받던 [동산보드판]이라는 앱이 있습니다. 아주 간단한 기능만으로 10년 동안 계속 인기를 끌었던 이 앱은 현장 상황(이미지)을 간단하게 공유해서 지시/보고 과정을 간결화 해줄 수 있는 서비스가 꼭 필요하다는 뜻이라고 생각했습니다. 초기 요청 그리고 이런 배경을 알게 되어 기능을 담당하게 된 당시 PO는 건설 현장과 신규 사업인 골프장 잔디관리 현장이 다양한 이슈 관리를 이미지 공유, 수기로 하고 있으니 이를 우리 제품 안에서도 해결할 수 있도록 해주자고 기능을 요청하셨습니다. [건설 작업 일보]라고 현장에서 건설 작업을 실시, 작업 내용을 기록해서 보관하는 문서가 있는데, 앞으로는 그런 것도 저희 제품에서 해결하면 좋을 것 같다. 우리가 진출 예정인 ‘골프 잔디관리’ 분야도 엑셀, 수기로 작업일지를 관리한다고 하는데 같이 해결할 수 있겠다. 당시 담당 PO가 요청하신 기능은 이런 형식이었습니다. 우리 제품에서 이미 제공하는 [위치 도구] 하위에 이미지를 추가할 수 있게 하는 것이었죠. 하지만 킥오프 후, 정말 좋은 해결책인지 고민되었습니다. 기능 발견 가능성이 낮아보였습니다. 뎁스가 4단계나 되는데 강조하고픈 기능을 너무 깊이 숨겨두는 게 아닐까? 최소한 검증을 해볼 수 있는 형태로 눈에 띄게 가치가 제안되어야 하지 않을까? 사용자들이 [위치 도구]를 보고 ‘이런 이슈들을 관리하면 좋겠다’고 자연스럽게 연상할 수 있을까? 기대하는 사용성이 모호했습니다. 타겟 유저의 익숙한 프로세스인 [작업일보]를 완전히 대체할 수 있을만한 임팩트를 목표로 해야하는 걸까? 얼마나 구체적인 이슈들까지 우리 제품에서 커버할 수 있을까? 그래서 대표적인 관계자 분들과 캐주얼한 논의해봤을 때, 모두의 생각이 달라 회의를 진행해보자는 결론에 도달했습니다. 이는 프로젝트 방향을 변경하는 계기가 되었습니다. 다시 회의를 진행하면서 각자가 바라는 방향과 실현가능성을 애기해보고 프로젝트 목표와 수단을 다시 협의하고자 했습니다. 방향성 재논의 1. MVP에 모바일은 꼭 필요하다! [동산보드판]이 10년 넘게 사랑받은 이유는 휴대폰으로 공유까지 가능하기 때문이었다. 모바일 없는 이슈 관리는 앙꼬 없는 찐빵! 이중작업만 늘어나 타겟 유저들이 도입하지 않을 것. 그렇지만 당장 개발 가능한 모바일 인력이 없다! → 모바일은 무조건 해야 한다! 웹 먼저 하지만 앱을 곧 배포할 것을 약속 파일 업로드/공유가 쉬워져야 타겟 유저들의 유입이 생기고, 임팩트도 클 것! 제품팀 인력과 개발 환경을 고려해 웹 먼저 배포하지만, 모바일은 꼭 필요하다는 것에 동의. 2. 건설, 잔디 관리에 모두 적용 가능한 범용적 기능을 먼저 배포한 후에 특화하자! 골프장 잔디 관리 MVP에도 들어가면 좋겠는데, 그럼 지금은 범용적인 기능 먼저 해두고 나중에 뾰족하게 만들어 가자. → ‘범용적인 기능부터' 먼저 진행하자. 엑셀, 수기로 관리하는 일들을 인터넷/디지털 환경에서 관리할 수 있게 성공적으로 전환 카톡 커뮤니케이션, 보고서 작성하던 프로세스를 메이사에서 커뮤니케이션, 자동 보관되도록 이슈 보고/관리 프로세스 간편화 3. 검증을 어떻게 할 수 있을까? 개발 전, 데스크 리서치 말고도 좀더 검증을 해보고 싶은데 도저히 기간이 안될까? 사전/사후 검증은 현장 인터뷰가 가장 좋을 것 같다. → 배포 이후 얼마든지 검증 인터뷰 가능! 회의 시점이 잔디 관리 솔루션 출시일이 정해졌던 시기, 이슈 관리 기능의 마감 기한도 정해진 셈 배포를 먼저 한 후에 검증은 얼마든지 할 수 있도록 협의 목표와 범위 재설정 논의를 거쳐 프로젝트 목표와 범위를 다음과 같이 다시 설정하게 되었습니다. 문제, 가설, 솔루션 문제 건설 프로젝트는 다양한 이해관계자가 참여해 커뮤니케이션 복잡도가 높습니다. 현장 내에서만 해도 소장, 안전관리자, 감리자, 협력업체별 팀장, 인력반장, 공무팀이 있죠. 여기에 시행사 본사의 담당자와 발주처, 개별 근로자들까지 합친다면 소통해야 할 주체가 엄청나게 많아지기도 합니다. 게다가 메신저로만 이슈를 관리할 때는 많은 사람을 친구로 추가하거나 관리해야 한다는 문제가 생깁니다. 단체방 참여자 수도 300명이 넘어갈 때가 있고요. 참여해야 하는 채널 개수가 20개에 육박하기도 하고, 카카오톡은 대화용 메신저이기 때문에 Thread 기능이 없어서 중요한 정보를 놓칠 확률이 높습니다. 지시할 때 위치가 텍스트, 사진으로만 설명되는 점도 직관적이지는 않다고 판단했고, 2주 이미지 보관 제한으로 히스토리 보관을 따로 해야하는 이중작업/보고의 어려움도 있습니다. 가설, 솔루션 가설 1 카카오톡의 단점들을 해결해주는 제품을 선택할 것이다. 솔루션 1 이슈별 실시간 대화로 상태를 추적하고 증거 보관까지 한번에 해결해주자. 위에 나열한 카카오톡에서 업무 관리를 할 때 생기는 페인포인트들을 저렴하게 해결하는 솔루션을 알게되면, 선택할 거라는 가설을 세웠습니다. 저희 제품에 이슈별로 데이터를 올리고 공유하고 대화할 수 있게끔 한다면, 그리고 따로 이미지를 저장하거나 보고서를 작성할 필요 없이 히스토리가 저장되어 언제든지 열람만 해도 된다면 좋을 거라고 생각했어요. 가설 2 위치를 텍스트로 설명하기 때문에 공유받은 사람이 직관적으로 알 수 없다. 솔루션 2 위치 정보를 시각적으로 제공해서 추가적인 설명을 줄이자. 건설 현장 사용자들은 참고할 수 있는 이미지, 증거 이미지 등을 카카오톡으로 전송한 뒤에 그에 대한 보충 설명을 텍스트 메시지로 전송하는 방식으로 소통하고 있었습니다. 메이사는 언제든지 현장 전체를 한눈에 볼 수 있는 고해상도 지도를 제공합니다. 그 위에 이슈 지점을 표시하고 업무에 필요한 메시지나 이미지를 확인, 댓글로 소통할 수 있다면 위치에 대한 추가적인 설명을 줄일 수 있다고 생각했습니다. 이 기능을 만들 때 참고했던 것은 Notion과 Figma의 '코멘트' 기능이었습니다. Notion은 특정 텍스트, 블록을 선택해서 댓글을 달거나 페이지 자체에 댓글을 남길 수 있습니다. Figma는 좀더 우리 서비스와 비슷하게 모든 방향으로 이동이 자유로우면서도 원하는 위치에 마커를 표시한 뒤 댓글을 남길 수 있죠. 둘다 [완료] 처리를 할 수 있고, 완료된 댓글도 볼 수 있는 보기 옵션이 있습니다. 결과물 이슈 정보 입력 이슈별로 정보를 입력할 수 있는 화면입니다. 이슈를 나타내는 대표 이미지를 선택하고 이슈에 대한 이름과 설명을 추가해 생성할 수 있습니다. 이슈 생성/완료 시 안내 생성되고 완료될 때 안내 문구가 추가되도록 하여 생성일시, 완료일시, 그 동작을 수행한 유저의 이름과 직책이 가 함께 기록 되도록 했습니다. 댓글 정보 댓글 작성자의 이름, 소속 회사, 직책 정보가 한 박스 안에 표시되어야 하는데, 카카오톡에서는 많은 이해관계자를 알아보기 위해 이름 란에 모두 정보를 넣게 되어 이름이 길어지는 단점이 있었습니다. 이를 보완하고자 위계를 다르게 디자인했습니다. 내 댓글 다른 사용자가 작성한 댓글과 시각적인 차이를 위해 이름 옆에 뱃지를 추가했습니다. 내 댓글 수정 Slack 메시지 디자인을 참고해 디자인했습니다. 본인이 작성한 댓글만 수정과 삭제가 가능하고, 수정할 때는 취소와 저장 버튼이 충분히 눈에 띌 수 있도록 하고자 했습니다. 댓글 입력창 텍스트 입력 길이에 따라 유연하게 변하도록 디자인했습니다. 추후 개발될 모바일 앱 구현을 고려해, Slack 모바일 앱과 카카오톡 앱의 입력창을 가장 많이 참고했습니다. 현장 인터뷰, 인사이트 1차 배포 이후, 편의성을 위해 관리자용 앱(전 Meissa Lite)을 제작할 예정이었기 때문에, 앱 기획을 시작하기 전에라도 인터뷰를 진행해서 더 좋은 방향을 설정하고자 했습니다. 인터뷰 기획 시 《꼭 필요한만큼의 리서치》, 《7가지 코드》 도서를 참고해 프로세스를 기능 담당 PO에게 제안했고, 문서를 만들어 공유했습니다. 특히 《7가지 코드》에서 MVP 대신 제안한 RAT(최고위험가설) 개념을 적용하여 가설을 새로 세워보기도 했습니다. 1개월 동안 최대한 많은 데이터를 수집해보려고 했지만, 인터뷰 일정을 잡는 것 자체가 예상보다 어려워 (사업팀의 협조 필요, 인터뷰할만한 고객사 스크리닝 필요) 인터뷰 간 텀이 약 3주에서 1개월로 길어져 예상했던 프로세스를 변경해 진행했습니다. 기존 작업 프로세스에 대한 가설, 작업 지시와 보고 과정을 자세히 파악하는 질문이 주된 내용이었고, 가장 가치를 많이 느끼시는 기능들을 확인하고 피드백을 직접 받는 시간도 포함했습니다. 가설 1, 건설 현장 인사이트 건설 현장 고객들은 이미 카카오톡의 한계를 알고 있기 때문에, 훨씬 다양한 용도에 맞는 다양한 제품을 조합해 사용하고 있었습니다. 사내 솔루션 사용 현장은 가점을 얻는 등 저희가 예상치 못했던 더 다양한 제약을 알게 되기도 했습니다. 하지만 카카오톡의 한계를 느껴 무전기, 네이버 밴드 등 적극적으로 해결책을 찾아 보완하고 있다는 점은 저희가 제대로 된 문제를 찾은 게 맞다는 의미이기도 했습니다. 고객이 불편하다고 말만 하지 않고, 실제로 해결해보려고 행동한 것이라는 점에 있어서 그렇습니다. 가설 2, 건설 현장 인사이트 현장 인터뷰를 기획하면서 만든 최고 위험 가설이 들어맞은 내용입니다. 저희는 저희가 제공할 수 있는 '위치'에 대한 시각적인 정보가 유용할 것이라고 생각했지만, 현장 외부에서 보고를 받는 경우를 제외하고는 그리 좋은 포인트는 아니었습니다. 건설 현장에는 위치가 잘 바뀌지 않는 '시설물'들이 있는데, 현장 내부에서는 위치를 얘기할 때 그 시설물을 기준으로 말하기 때문에 그리 위치 파악이 힘들지 않다는 거죠. 현장에서 일한지 얼마 안된 근로자들은 어떡하냐는 질문을 던지자, 어차피 그런 근로자들은 관리자가 직접 동행해서 지시하신다더라구요. 결국 이슈 위치 시각화는 건설현장에서 큰 의미가 없었습니다. 프로젝트 결과 분석 건설 현장과 골프장 인터뷰를 함께 해본 결과, 건설에서 틀렸던 가설이 잔디 관리에서는 맞는 등 다른 양상을 보였습니다. 이슈 관리 기능은 건설보다 골프장 잔디관리 고객에게서 가능성을 볼 수 있었습니다. 건설 프로젝트는 그 시간이 아무리 길더라도 0에서 1을 만드는 것이고 끝이 있습니다. 골프장 잔디 관리는 끝이 없는 유지보수 성격이 강한 곳입니다. 농사 짓는 일을 생각하면 좀더 쉬울 것 같네요. 농장을 가꾸는 사람은 '농사일지'를 꾸준히 작성합니다. 그래야 내년, 내후년, 그 후에도 비슷한 시기에 어떤 일이 있었는지 과거를 돌아보며 미래를 예측할 수 있기 때문입니다. 골프는 건설과 필요한 데이터가 비슷해보여도 고객의 목적이 이렇게 완전히 다르기 때문에 다른 반응을 보일 수밖에 없다는 사실을 통해 B2B 제품에서 항상 강조하는 '고객이 완수하고자 하는 일(Jobs To Be Done)'의 중요성을 새삼 깨닫게 되기도 했습니다. 프로젝트 종료 이후 개선 이터레이션 저희는 건설 현장보다 골프 잔디관리 현장에서 가능성을 확인했기 때문에 골프 잔디관리, 코스관리 팀을 인터뷰하며 필요한 기능들을 점진적으로 보충했습니다. 면적 이슈 추가 골프 잔디 관리에서는 위치를 콕 집어 설명하는 것보다 [이 '영역'의 잔디에 OO관리를 하라]는 지시가 필요했습니다. 그래서 점 뿐만 아니라 [면적]으로도 이슈를 추가할 수 있는 기능을 배포했습니다. 면적 이슈에 대한 식생지수 계산, 비교 골프장 솔루션에서는 잔디의 식생지수를 퍼센티지로 관리합니다. 드론으로 촬영한 이미지 전체로만 가능했던 식생지수를 특정 구역 지수를 확인할 수 있도록 했습니다. 특정 구역 지수를 최대 9개 날짜까지 비교할 수 있는 기능까지 제공했습니다. 빠른 이슈 생성 휴대폰에서 타이핑하지 않고도 빠르게 이슈를 생성할 수 있도록 했습니다. 필수값을 해제한 이슈 종류인데, 음성인식(STT)기술로 마이크를 사용하거나 사진만으로도 생성할 수 있는 이슈 타입을 추가 지원했습니다. 작업 일지 (예정) 1년 전 오늘, 10년 전 오늘 등의 현재, 미래 시점에 필요한 작업을 추천받을 수 있도록 작업 일지를 디지털화하여 저장하는 프로세스를 제안하고자 합니다. 회고 건설에 대해 가설을 세웠지만 많이 틀렸다고 생각했습니다. 이슈 관리나 커뮤니케이션 복잡성 면에서 문제를 맞게 찾았다고 생각하지만, 가설과 솔루션을 도출할 때 헛다리를 많이 짚었다는 생각이 듭니다. 최고위험가설(RAT) 중에 맞은 것들이 몇 가지 있었습니다. 인터뷰를 통해 다시 알게 된 업무 프로세스는 우리가 생각했던 것보다 훨씬 체계적이었고, 다양한 차원의 제약이 있었습니다. (본사 압박 등) 모바일 앱이 출시된지 꽤 지났지만, 활성 사용자가 매우 적은 상태입니다. 고객들이 제품의 Beta 기능은 신뢰를 하지 않아 사용해보지도 않는다는 사실을 인터뷰를 진행하면서 알게 되었습니다. 무엇이 잘못 된 걸까? 사전검증을 하지 않고 속도에만 집중했습니다. 사용자들의 업무 프로세스를 데스크 리서치로만 확인해보고 개발에 뛰어들었습니다. 이후 저는 관성적으로 사용자가 아닌 개발을 위한 방향과 공수를 먼저 생각한 게 가장 큰 문제라고 정의했습니다. 데드라인이 있다는 이유로 아이디어를 먼저 간단하게라도 검증해보려고 하지 않고, 개발에 대한 생각을 했던 것입니다. 사내 리서치 문화가 없었습니다. ‘그때 왜 그렇게 생각했을까’ 돌이켜 보았더니, 사내 리서치 문화가 전혀 없었고, 그 중요도에 대한 공감대도 없다는 사실을 새삼 깨닫게 되었습니다. 문제 의식을 공유하고 함께 해결책을 모색해 봐야겠다 《린 고객 개발》이라는 책을 읽고, 회고하며 생각을 정리할 수 있었습니다. 이 책을 읽고 우리 팀은 그동안 ‘낭비를 줄이기 위한’ 액션을 딱히 시도하지 않았다는 걸 깨닫게 되었습니다. 특히 개발에 드는 낭비 자원이요. 다양하게 문제를 생각해봤지만 서로에 대한 이해와 공감이 필요한 영역이다보니 혼자서는 할 수 없었습니다. 그래서 국내사업 팀장님(하OO 님)과 PO 챕터 리드 (김OO 님) 두 분을 각각 1:1로 만나서 제가 정의한 문제들을 설명하고 해결책을 함께 논의해보면 좋겠다고 말씀드렸습니다. 두 분은 흔쾌히 이런 얘기를 꺼내주어 고맙다며 응하셨습니다. 〈김김하〉라는 회의를 3개월 정도 진행하며 서로의 페인포인트와 개선점을 총체적으로 논의하고 제안할 수 있었습니다. 저희는 카드소팅 방식을 통해서 논의해서 문제점을 크게 세 가지로 나눌 수 있었는데, 내부에 리서치 문화/공감대가 없어 고객에 대한 이해를 충분히 하지 못하며 양질의 데이터를 수집할 수 없다는 것이었습니다. 원인 파악과 액션 플랜 도출을 위해 제가 읽었던 《린 고객 개발》과 《7가지 코드》라는 도서의 내용 일부를 함께 읽거나 공유하고, 다양한 MVP 검증 방법을 소개해 우리에게 맞는 방식이 있을지 대화하기도 했습니다. ✅ 액션 플랜 수행 문제점이 많지만 그 안에서도 우선순위를 나눠봤습니다. 위 문제점 중 1번과 2번이 가장 시급한 문제라고 생각해 각각을 해결하기 위한 당장 실행 가능한 일이 무엇인지 논의하고 도출할 수 있었습니다. 회의 내용을 바탕으로, 경영진에 리서치 문화에 대한 필요성을 강조하고 요청 2023년 4월, 회의를 마무리한 뒤 경영진에 미팅을 요청해 내용을 공유, 합의했습니다. 건설 프로젝트 이해관계자들 간의 관계를 다시 파악, 도식화해서 전사에 공유 2023년 5월 19일, 전사 공유 세션에서 PO 챕터 리드 김OO님이 해당 도식과 내용을 공유했습니다. 국내사업팀 OKR에 제품 팀원과 함께 현장 인터뷰를 진행하는, 적극적으로 돕는 목표를 추가 2023년 1–2분기 중 현장 인터뷰를 8회 이상 진행할 수 있었습니다. 💪 그 외의 노력들 온보딩 문서의 고객/사용자 정보 업데이트 새로 입사하신 분들께 보여드렸던 고객 설명을 바꿨습니다. 좀더 정확한 최신의 정보를 보기 쉽게 도식화한 이미지가 생겼으니까요. 아직도 건설이 낯설었던 사원들과 신규 입사자들에게 이전보다 좋은 가이드가 되었다는 평가를 받았습니다. Meissa Scan 제품 개발 전, 사용자 니즈와 리스크 요소 조사 당시 회사에서 드론으로 취득하는 실외 데이터 뿐만 아니라, 360 파노라마 이미지를 통해 실내 데이터를 수집할 수 있는 새로운 제품(앱)을 만들어 출시하고자 했습니다. 아직 사내에서 그 기술 가능성을 확인 중일 때, 인터뷰를 통해 위험 요소를 알아보고자 했습니다. 실내 데이터 취득이 필요하긴 하지만, 취득 주체의 모호함과 모든 건축 동을 돌아다녀야 하는 수고로움이 너무 크다는 문제를 알 수 있었습니다. 이렇게 인터뷰 후 ‘수집의 용이성’이 가장 중요하다는 것을 알게 되어 360 이미지가 아닌, ‘360 영상 수집'으로 MVP 방향을 변경해서 기술 가능성 확인을 다시 하게 되었습니다. 토공물량표 기획 전, 타겟 유저 확인 및 협의 D사와의 계약에 묶인 기능 요청이었는데, 기획을 시작하기 전 국내사업팀장님과 PO를 포함한 회의를 요청하여 타겟을 확실히 하고자 했습니다. 알고보니 D사에서 요청한 형식은 [건축] 현장에서 진행하는 토공사에 필요한 것이었고, 보통 [토목] 현장에서 만들고 보고하는 토적표와는 다르다는 걸 알게 되었습니다. 사전에 타겟을 다시 짚고 넘어가고자 했기 때문에 기능에 대한 네이밍과 가치 제안을 건축 현장으로 맞추어 진행할 수 있었습니다. 마치며 그래도 의미 있던 점이 있다면... 대기업 건설사 대상의 건설 B2B 솔루션을 4년 간 기획하고 디자인하며 크게 느꼈던 점은 저희 서비스는 다른 서비스들에 비해 고객의 요구의 수가 적지만 요구마다 강하고 명확하게 들어오는 편이라는 것입니다. 요청 기능들에 대한 설명을 구체적으로 적은 PPT 파일을 주시는 고객사도 많은데, 정말 친절한 형태이지만 제품팀 입장에서 고객이 기존 업무 프로세스에서 정확히 어떤 페인포인트가 있는지 또는 왜 얼마나 필요한지 파악하기 쉬운 형태와는 멉니다. (ex. 이 기능이 이런 식으로 필요하니 이 위치에 추가해주세요) 분석에서 많은 부분을 차지하는 것은 대량의 정보를 이해해서 기본 패턴을 파악 하고 거기에 대해 조치를 취하는 것이다. 그러나 초기 단계의 B2B 스타트업은 패턴이라고 할 만한 게 없고 고객만 있다. 《린 분석》 도서에 있던 표현을 빌리자면, 그런 상황이 당연하다는 생각이 들기도 합니다. 이렇게 고객사의 까다로운 요청을 하나씩 검토하고 기본 지식을 이해하는 시간이 훨씬 더 많이 소요되는 환경이지만, 이번 이슈 기능은 제품팀이 먼저 고객들의 패턴과 페인포인트를 파악하고, 고객들에게 솔루션을 제안했다는 데에 의미가 있다고 생각합니다. 만약 다시 시작할 수 있다면... 매몰비용이 커지기 전에(실제로 개발을 하기 전에, 기획도 하기 전에!) 컨셉에 대한 가설을 더 검증해보려고 했을 것 같습니다. 컨셉 이미지를 가지고 사전 전화 인터뷰, 현장 인터뷰 등 고객의 목소리를 더 적극적으로 수집했다면 배포 이후에 인터뷰를 통해 알았던 본사 차원의 제약 같은 것들도 적은 노력으로 확인할 수 있었을 것 같습니다. 그랬다면 프로젝트를 아예 다르게 이끌 수도 있지 않았을까요. MVP로 앱을 직접 만들지 않고 오히려 메신저를 더 잘 사용할 수 있도록 도와주는 형태였다면, 또는 우리가 메신저를 적극 활용하는 형태였다면 어땠을까요? 예를 들면 챗봇을 통해 작업 지시를 받고 보고하면, 자동으로 히스토리까지 보관되게 해서 관리자들도 편하게 히스토리 열람을 할 수 있는 형태로요. MVP로써도, 서비스로써도 가장 좋은 수단이었을 지도 모르겠다고 생각하며 회고를 마친 기억이 납니다.