닷닷 아카이빙 #8 프로덕트 개발 방향을 구체화하기 위해서는
안녕하세요, 닷닷의 기획 담당 으니입니다. 그간 저희 브런치를 꾸준히 응원해 주시던 분들도 계셨었는데, 면목없게도 한 달이 넘어가는 잠수(!)라는 꼬리표와 함께 다시 인사를 드리게 되었어요. 그렇지만 이런 것이 우당탕탕 얼레벌레 굴러가는 사이드프로젝트의 묘미가 아닐까요? 하는 뻔뻔스런 질문과 함께 ^^; 포스팅을 이어가고자 합니다.
툭툭 털고 일어나 다시 닷닷 프로젝트를 굴려볼 때가 되었지요. 지난 포스팅에서는 기획을 할 때 팀원 또는 외부인을 설득할 근거를 짜 나가는 방식(Why)에 대해서 다루었어요. 이번 브런치 글에서는 어떤 식으로 구체적인 프로덕의 모양을 만들어가고(What), 또 어떻게 팀원들과 소통하면 좋을지(How) 참고하실 수 있도록, 기존의 아이디어가 구체화된 과정을 담아 보겠습니다.
닷닷은 저희처럼 조직 기반 없이 뭐라도 해 보려고 드릉드릉 사부작사부작하는 이들을 위한 서비스를 준비하고 있지요. 어찌저찌 머리를 굴리다 보니 기록 플랫폼으로 방향성이 잡혔습니다.
우리, 주니어들이 병행하고 있는 여러 프로젝트에서 스쳐가는 단상들을 그때그때 기록하게 하자.
+ 동료들의 피드백도 휘발 없이 함께 누적할 수 있도록 도와주자.
그래서 소위 ‘갓생 사는’ 대학(원)생 및 사회초년생과의 인터뷰와 자료조사를 통해서 기획 근거와 필요한 기능들을 구체화하고, 러프한 항목 형태로 정리하여 1차적으로 팀원들과 이야기를 나눴어요.
대강의 핵심적인 기능을 정의한 뒤 첫 번째로 봉착한 문제는 ‘그럼 어떤 화면에 담아야 할까?’ 였어요. ‘기록’ 행동을 담을 수 있는 UX가 천차만별이었고, 또 디자인 컨셉에 따라서도 화면 구성이 바뀔 여지가 많았기 때문에 기능 정의와 화면 구성 각 과정의 사이가 상대적으로 멀리 떨어져 있었던 거죠. 서비스 종류에 따라 다르겠지만, 경험상 기능이 정의되면 화면 레이아웃이 쉽게 잡히는 경우도 왕왕 있었거든요. 반대로 생각하면 화면 디자인 측면에서 자유롭게 시도해 볼 여지가 많은 상황이기도 했지만요.
그날 이후 디자이너 YY와 만나 스케치 형태로 브레인스토밍을 해 보기도 하고, 레퍼런스도 찾아보고… 메타포 중심으로 UX를 풀어가 볼까? 그렇다면 어떤 메타포를 사용할 수 있을까? 같은 큰 질문에서부터 작디작은 사용성 측면까지의 질문이 오갔어요. 워낙 가능성이 열려있다 보니 YY가 리서치한 디자인 사례들을 갖고 포지셔닝 맵을 구성할 수 있을 정도였죠.
디자인과 함께 진행을 하려다 보니 오히려 진척이 점차 더뎌지기 시작했고, 이때쯤 서비스 구조를 보다 구체화한 자료의 필요성을 느낍니다. 작업을 하다 보니 IA*와 Flow Chart를 합친 듯한 모양새가 되었는데, 회의 당시에도 팀원들이 차트만 봐서는 구조를 이해하기 힘들다는 피드백을 주기도 했더랬지요… (아련) 정보가 누락된 부분 없이 한 장에 담아내겠다는 생각이었는데, 지금에 와선 IA는 IA대로, flow는 flow대로 (선형으로 따라갈 수 있게) 분리하는 편이 훨씬 나았겠다는 생각을 합니다.
보통 아예 화면 스케치 형태로 이 작업이 진행되기도 하는데, 저희는 화면 레이아웃이 나오지 못하고 있던 상황이었기 때문에 IA 위에 화살표가 달라붙게 되었다고 봐 주시면 되겠네요.
*IA는 Information Architecture의 줄임말로, 흔히 ‘정보구조도’라고 번역됩니다.
아쉬운 부분이 많지만, 어쨌든 각 화면과 행동 단위로 기능이 쪼개진 만큼 팀원들과 서비스의 완성된 모습에 대해서도 좀 더 얘기할 거리가 많아지게 된 것이죠. 이에 발맞춰 YY 측에서도 디자인 컨셉 시안이 하나둘 나오면서, 기능의 목록에 불과했던 프로덕트가 조금씩 ‘앱’의 모양새를 갖춰가기 시작합니다.
이제 기획자와 디자이너에게 남은 일은 우리의 백, 프론트 개발자가 본격적인 작업에 착수할 수 있도록 실제 화면과 이를 설명하는 기능 명세서를 제작해 주는 일입니다. 분량상 이 과정은 다음 포스팅에서 다루어 보도록 할게요.
그럼 여기까지 읽어주신 모든 분들께 감사드리며, 2023 계묘년 새해 복 많이 받으시길 함께 기원합니다!