고정 헤더 영역
상세 컨텐츠
본문
Team AWESOME season ① 순록(Soon:log)
팀 어썸은 사이드프로젝트 모임입니다.
마케터, 디자이너, 개발자, 기획자 등 다양한 직군의 사람들이 모여 새로운 서비스를 만들며 배우고 성장합니다.
시즌 1 순록은 2019년 5월부터 12월까지 진행된 어썸의 첫 번째 프로젝트입니다.
01. 팀 빌딩 – 회사일 말고도 더 재밌는 것을 해보고 싶어요!
02. 팀 운영 – 소규모 팀 운영 방법 & 아이디어 선정과 구체화
03. 답은 나왔는 데...무언가 이상한 고객 여정 맵, 무엇이 문제였을까?
04. 점점 눈으로 보이는 서비스! 기능 정의와 브랜딩
05. 팀 어썸의 첫 번째 서비스 'Soon: log'을 소개합니다.
설문조사와 페르소나를 통해 도출한 문제점을 바탕으로 최종 서비스 기능 정의를 시작했습니다.
주요 문제는 크게 3가지로 나눠 볼 수 있었습니다.
우리가 발견한 문제점, 우리가 해결해보자!
문제정의 - 도대체 무슨 문제가 있길래, 우리는 왜 이 서비스를 만들어야 할까?
1. 정확하게 중요한 순간에 촬영하기 힘든 사진 촬영
: 세미나를 듣다 보면, 발표자의 PT 화면을 찍어야 하는 상황이 있습니다. 강의 도중 쉽게 볼 수 있는 상황입니다. 두 손을 번쩍 이리로 움직여보기도 하고, 저리로 움직여보기도 하면서 해당 화면 촬영을 시도합니다. 다시 자료를 더 선명하게 찍기 위해 확대도 하고, 줄여가며 최적의 환경을 세팅하죠. 그러나, 그 촬영 초점을 맞추는 과정을 거치다, 중요한 화면을 놓치기 일 수입니다.
2. 수기 필기와 노트북 타이핑 기록, 어느 하나 완벽하게 기록하기는 힘이 듭니다.
발표자의 말 속도가 너무 빠르거나, 담고 싶을 발표자의 말이 너무 길 경우, 원하는 내용을 필기하는 것이 쉽지 않습니다. 수기 필기는 물론, 노트북 타이핑도 쉽지 않죠. 더군다나 노트북의 경우, 위치의 영향을 많이 받습니다. 긴 시간 발표가 진행되는 경우, 배터리 연결을 할 콘센트가 필요합니다. 들고 다니기 무거운 짐이 되기도 하죠. 필기를 하는 도중 뒷부분의 내용을 따라가지 못하는 경우도 생깁니다.
3. 목소리를 직접 담는 녹음은 어떨까요? 그럼, 언제부터 얼마나 녹음을 해야할까요?
종종 강의 전체를 녹음하는 경우도 발견할 수 있었습니다. 그러나, 설문 조사 결과 실제 녹음한 파일을 다시 듣는 경우는 현저히 떨어졌습니다. 실상, 1시간이 넘는 긴 시간의 녹음을 다시 듣는 것이 쉽지 않기 때문이죠. 중요한 내용이 기억나더라도, 해당 지점으로 찾아서 듣는 것도 고역입니다.
우리가 최종적으로 도출한 3가지 문제에 대해 팀원들과 공유하며, 모두의 공감을 얻었습니다. 이 부분이 가장 중요하다고 생각합니다. 본격적인 기능을 정의하기 전, 문제 인식을 정리하고, 확실히 모두의 이해가 필요합니다. 실제, 문제 정의를 하는 과정에 있어서 항상 같이 모여서 회의를 하고 일을 진행했지만, 문제 정의가 이상하게 다르게 되는 경우가 발생했기 때문입니다.
정확한 문제 정의를 하는 단계를 거치고, 이제 공동의 목표인 문제 해결을 위해 머리를 모았습니다. 우리 팀이 주목한 것은 인공지능이었습니다. 최근, 인공지능 오픈 API가 공개되면서 실제 어느 부분까지 구현이 가능한 지 판단이 가능했습니다. '인공지능 오픈 API'를 검색해보면 많은 정보가 나오지만, 주로 아래 사이트(공공 인공지능 오픈 API, DATA 서비스 포털, http://aiopen.etri.re.kr/)를 이용했습니다.
위 사이트에서 언어처리, 음성 지능, 시각 지능, 대화처리 등 현재 수준에서 가능한 인공지능 기술을 만나볼 수 있습니다. 이 기술을 이용해 문제를 해결해보려 거듭 고민했고, 우리는 조금씩 정답을 찾아갔습니다.
서비스 정의 - 우리의 서비스는 이 해결책으로 사람들의 어려움을 해결해줄 거야!
1. 사진 촬영? 어차피 자리는 늘 고정! 그 최적 모드를 고정해주자!
사진 촬영 기록의 문제점을 다시 한번 살펴보겠습니다.
빠르게 찍고 싶은 장면을 찍어야 하는데, 최적 촬영 환경 설정까지 걸리는 시간이 너무 길다는 것입니다. 심지어 사진을 찍고 다시 카메라 앱을 켰을 때 다시 이 과정을 반복해야 한다는 문제도 있죠. 이를 해결하기 위한 첫 번째 방법으로 첫 번째 초기 설정값에 주목했습니다.
세미나의 경우, 한 번 자리에 앉으면 발표가 끝날 때까지 그 자리가 자신의 자리가 됩니다. 즉, 다시 말하자면, 처음 사진을 찍은 그 환경 설정 그대로 찍을 가능성이 높다는 것이죠. 그 자리를 고정값으로 잡았습니다. 한 번 초기 설정으로 찍은 그 세팅값을 기억하는 것이죠. 두 번째 해결 방식은 스캐너 앱을 주목했습니다. 스캐너 앱은 자동으로 문서의 모서리를 인식해 문서를 인식하고 해당 내용을 스캔하는 방식입니다.
같은 원리를 발표자의 PT 화면에 도입했습니다. 발표 환경의 특성상, 좀 더 선명한 발표자료 화면을 만들기 위해 PT 화면을 밝게, 주변 환경을 어둡게 만듭니다. 마치 스캐너처럼 해당 화면 인식을 찍을 때마다 빠르게 가능합니다. 이 방식을 통해 사진 촬영 순간을 더욱 단축시키고자 했습니다.
2. 필기, 결국 중요한 부분만 해주면 되는 것 아닌가? 그 중요한 부분만 판단할 수 있다면...
수기 필기든, 노트북 필기는 원하는 내용을 원하는 형태로 깔끔하고 정확하게 적기엔 불가능한 부분입니다. 발표자의 발화 속도, 내용에 따라 크게 달라지는 부분이니까요. 필기에 집중하느라 다른 내용을 흘려보낼 수 있다는 것도 문제였습니다. 이는 사람의 힘으로 해내기 힘든 부분일 수도 있다고 판단했습니다.
어렵지 않게, 음성인식을 텍스트로 바꿔주는 인공지능을 보신 적 있으실 겁니다. 쉽게 OK구글, 지니, 시리, 빅스비 등 AI 인공지능들이 대표적입니다. 우리는 이 기능을 통해 발표자의 필기를 대신하고자 했습니다.
모든 내용을 전부 텍스트 변환할 수는 없기에 기준이 필요했습니다. 언제 발표자의 말을 중요하다고 판단해서 텍스트로 바꿔줄 것인지, 해당 텍스트 문장을 전부 다 바꿔줄 것인지 그것이 아니라면 어떤 기준으로 몇 문장을 전해줄 것인지 등에 대한 고민이 필요했습니다.
그 기준을 사진 촬영 순간으로 잡았습니다. 그 부분이 중요하다면, 해당 장표 사진 촬영을 할 것이고 그 기점을 중요한 순간으로 판단하기로 했습니다. 변환 내용은 모든 텍스트 데이터를 스마트폰이라는 환경에서 확인을 할 수가 없기 때문에, 가장 많이 언급된 키워드를 중심으로만 보여주기로 했습니다. 추후 키워드와 사진을 통해 해당 상황을 기억해내 다시 볼 수 있게 하기 위함이죠.
그럼 어떤 방식으로 다시 볼 수 있게 할 것인가에 대한 답은 녹음을 통해 찾았습니다.
3. 디폴트 상황은 녹음은 필요한 상황만! 옵션이 풀 전체 녹음!
녹음의 문제는 언제 어떤 중요한 말이 나올지 몰라 항상 강의 전체 시간을 녹음한다는 것이었습니다. 여기서 오는 문제는 해당 데이터 용량이 부담스러울뿐더러, 실제 복습에도 부정적인 영향을 준다는 것이죠. 해결을 위해서는 중요한 부분만 녹음을 해야 할 필요가 있었습니다. 녹음의 전제는 전체 녹음이 아닌 중요 부분 녹음이 되어야 합니다.
이 기준도 역시 사진 촬영에 있었습니다. 해당 서비스를 시작하면, 녹음은 기본적으로 계속 진행되나 사진 촬영(중요 부분을 알리는 행위)이 없다면 서비스 중단 시, 녹음(음성) 데이터는 전부 지워집니다. 반대로 사진 촬영이 생긴다면, 해당 시점을 기준으로 녹음 파일 중 전후 15초, 총 30초의 녹음 기록을 저장합니다.
즉, 사진 한 장의 순간에 발표자의 음성이 들어가게 되는 것이죠. 기록은 이 음성 데이터를 텍스트화 하며 기록됩니다. 이 단계를 모두 거친다면, 용량 부담도 줄어들고 녹음 기록도 원하는 부분만 찾아볼 수 있습니다. 물론, 전체 녹음을 옵션으로 제공해, 원한다면 원본 데이터 녹음 그대로 저장할 수도 있습니다.
정리하자면, 사진 촬영이 중요 상황임을 알리는 트리거가 됩니다. 이 트리거를 발동시켜 필기와 녹음이 동시에 작동하게 되는 것이죠. 결과적으로 이용자는 사진 촬영 한 번으로 해당 상황의 사진, 텍스트 기록, 음성 데이터를 보유하게 됩니다. 이제 데이터가 모여 정보가 된 것이죠. 이 서비스 형태는 이용자가 해당 정보를 리마인드 하기 위한 편의를 제공하게 됩니다.
서비스의 길과 지도를 그리자! 서비스 플로우와 와이어 프레임
서비스의 주요 기능이 결정되었으니, 해당 기능을 서비스에 얹기 위해 서비스 플로우를 그리고 와이어프레임 그리는 작업에 들어갔습니다. 사용자가 우리의 기능을 고려함에 있어 어려움을 겪지 않아야 하니, 많은 고민이 필요했습니다. 흔히 이야기하는 UX, UI를 고민하는 단계입니다.
팀원들과 같은 화면을 보며 공유할 수 있는 서비스 플로우 서비스로 니로(https://miro.com/)를 선택했습니다. 조금 느리긴 하나 대시보드를 통해 공유가 가능하고, 작동법이 쉬워 금방 익히고 시작할 수 있다는 점이 장점입니다.
이처럼 우리가 만들어야 하는 각각 페이지 전부를 서로 연결해 플로우를 구성했습니다. 논리적으로 해당 루트가 맞는지, 이용자가 불필요하게 헤매는 부분은 없는 지를 고민했습니다. 마케터로서 매우 흥미로운 작업이었습니다. 실제 서비스의 흐름을 고민한다는 점에서 마치 고객이 되어 찾아가는 점이 흥미로웠습니다.
어찌 보면, 마케팅 퍼널을 지나가는 고객의 모습을 그려보는 것 같기도 합니다.
와이어프레임 작업은 어도비 XD를 활용했습니다. 무료로 이용이 가능했고 동시 작업이 가능해 팀원 간의 협업이 수월하게 진행되었습니다.
서비스 플로우를 그리고 와이어프레임을 그려보는 경험은 신선했습니다. 아마, 제가 스터디를 하지 않았다면 해당 툴을 사용할 일도 없었을뿐더러, 직접 서비스의 흐름에 고민해 볼 경우는 거의 없었겠죠. 이 프로젝트를 진행하며, 고객 경험에 대해 많은 고민을 해봤다는 점이 만족스러웠습니다. 결국, 마케팅도 고객의 마음을 읽고 행동을 고민하는 것이기에, 어찌 보면 일맥상통한 것 같다는 생각도 들더군요.
우리 서비스의 이름, 느낌은 무엇이 좋을까?
와이어프레임 작업까지 마치고, 본격적인 디자인 작업에 들어가기 전 우리 서비스의 모습에 대해 고민했습니다. 어떤 모습으로 고객에게 보여줘야 할지를 결정하는 것이기에 팀원 간의 의견을 모으고 결정하는 것이 중요했죠. 흔히 이러한 과정을 BX라고 부릅니다. 브랜드 이미지를 나타내는 모든 것을 결정하는 단계죠. 이미지를 통해 하나의 공통된 가치와 느낌을 만들어 내는 것이 주요했습니다. BX, 어썸은 이런 방식으로 진행했습니다.
BX(Brand eXperience)을 정하는 팀 어썸의 방법
이 서비스가 가진 주요 키워드는 '신속, 정확, 정리'였습니다. 이 3가지 키워드를 주축으로, 우리 서비스가 남들에게 어떤 모습으로 보이길 원하는지 나이브하게 이야기했습니다.
이처럼, 떠오르는 내용을 전부 이야기했습니다. 그리고 다시 해당 키워드 중 맘에 드는 키워드를 뽑았고, 단순히 키워드로 표현하기 어려운 부분은 핀터레스트에서 이미지를 찾아 공유했습니다. 그 결과, 아래처럼 정리가 되기 시작했습니다.
이후부터는 디자이너 팀원의 역량이 크게 발휘했습니다. 지금까지 팀원들이 주고받은 대화를 바탕으로 도출한 내용을 이미지로 표현하기 시작했습니다. 최종 결과물은 마지막 5편에서 소개해 드리도록 하겠습니다.
서비스 이름도 매우 중요했습니다. 이 모든 내용을 담기 위해 머리를 맞대고 고민했습니다. 딱딱하지 않고, 특정 이미지가 떠올랐으면 좋겠다는 의견이 있어서 이름과 로고 표현 방식 고민이 길게 이어졌습니다. 아이디어라는 것이 참 신기한 게, 어느 순간 머리가 딱 울리는 이름이 떠오르더라고요. 우리 서비스의 이름은 '순간 기록: soon : log '입니다.
우리 서비스의 모든 특징을 다 담은 좋은 이름이라고 생각합니다. 서비스 기능 정의, 서비스 플로우, 와이어 프레임 그리고 브랜딩, 디자인까지 이제 모든 과정을 거쳤습니다. 이 프로젝트의 결과는 디자이너 모임, '프롬 디자이너'를 통해 발표를 진행하며 마무리했습니다.
마지막 5편에서는 서비스 소개와 회고로 마무리하도록 하겠습니다. :)
'딴짓 > 시즌 1 - Soon:log' 카테고리의 다른 글
| 05. 팀 어썸의 첫 번째 서비스 'Soon: log'을 소개합니다. (0) | 2020.08.21 |
|---|---|
| 03. 답은 나왔는 데...무언가 이상한 고객 여정 맵, 무엇이 문제였을까? (0) | 2020.07.21 |
| 02. 팀 운영 – 소규모 팀 운영 방법 & 아이디어 선정과 구체화 (0) | 2020.04.05 |
| 01. 팀 빌딩 – 회사일 말고도 더 재밌는 것을 해보고 싶어요! (0) | 2020.03.22 |
댓글 영역