7회. SW 개발자들끼리 제품만들기
Wearable Hackathon
기술만을 강조하다 보면 기술의 함정에 빠지기 쉽죠.
이미 나온 기술이더라도 UX 관점에서 어떻게 조합하느냐에 따라서 사용하기 편리하고 나아가 새로운 개념의 제품이 탄생하기도 합니다. 이런 Needs에 따라 BANG LAB.(www.banglab.com)에서는 최근 인기를 끌고 있는 제품들을 UX 관점에서 토론해 보고 그 결과를 정리해서 공유합니다.
이번 일곱 번째 이야기에서는 완성된 제품이 아닌 해커톤이라는 포맷 안에서 Lean UX로 제품을 만들어가는 과정에 대한 이야기를 준비해 보았습니다.
UX로 마술을 부리는 그 일곱 번째 이야기 시작합니다.
해커톤(Hackathon)이란, 해커(Hacker)와 마라톤(Marathon)의 합성어로 새로운 것에 대한 도전을 즐기는 해커 정신을 가진 다양한 사람들이 짧은 시간 동안 아이디어를 직접 기획하고 프로그래밍하여 프로토타입의 결과물을 만들어 내는 활동입니다.
작년까지 미국에서 큰 상금이 걸린 많은 해커톤이 열렸고, 국내에서도 유수 기업과 단체 등에서 다양한 해커톤을 개최하며 기획자, 디자이너, 개발자에 이르기까지 제품에 이바지하는 다양한 사람들의 참여를 끌어냈습니다. 덕분에 해커톤이란 단어는 다양한 직군의 사람들에게 그리 낯설지 않은 단어가 되었습니다.
이번에 사내에서 열린 Wearable Hackathon을 행사 기획부터 진행까지 전 단계에 힘을 보탰는데, 그중에서도 Ideation workshop을 맡아 진행한 이유가 있습니다. 바로 waterfall 형태의 제품 개발 프로세스에 익숙한 개발자들을 대상으로 하는 행사였기 때문입니다.
일반적으로 제품/서비스를 출시하는 데 거치는 과정을 떠올리며 필요한 일을 뽑아보면 다음과 같은 프로세스로 이루어집니다.
기획(아이디어/콘셉트) → UX 디자인(사용자 시나리오/feature 단위의 요구사항) → 개발(아키텍처 설계/feature 개발) → 테스트 → 출시
기획자가 아이디어를 구체화해 콘셉트를 잡고, UX 디자이너가 사용자 시나리오를 만듭니다. 보통 이 두 조직에서 feature 단위의 요구사항을 도출하는 역할을 합니다. 그다음엔 개발자가 요구사항을 바탕으로 아키텍처를 설계하고, 시나리오 문서를 바탕으로 feature를 개발합니다. 그 후엔 feature를 모아 하나의 제품으로 만든 후 테스터의 검증을 거칩니다. 이렇게 큰 네 단계를 거치고 나서야 비로소 제품이 출시됩니다.
개발자의 날은 SW 개발자가 주로 참석하는 행사로, 제품을 개발하는 여러 단계 중 코드를 만들어내는 활동에 더 많은 비중을 두고 있는 사람들의 모임입니다. 해커톤을 하려면 아이디어를 내는 것부터 콘셉트를 구체화하고, 요구사항을 도출하는 개발 앞단에서 필요한 과정들이 있는데, 아무래도 개발자끼리만 있으면 시야가 좁아지지 않을까 하는 생각이 들었습니다.
그래서 개발자의 날 행사에서는 개발자들끼리 짧은 시간 안에 개발 이전에 필요한 두 가지 과정을 실습하는 "SW 개발자들끼리 제품 만들기"라는 워크숍을 만들게 되었습니다.
1) 내가 구상해온 아이디어를 사용할 사람이 누군지 구체화하는 "persona” 만들기
2) 내 아이디어를 앱으로 만들었을 때 화면 구성이 어떻게 되는지, 어떤 흐름으로 동작하는지 paper prototyping을 통해 구체적인 “시나리오” 작성하기
제가 Lean UX에 대한 관심으로 일을 만들기 시작할 때에도 역시 persona 만들기를 여러 번 하면서 [Tech보다 UX] 잡지를 고안하게 됐습니다.
회사에 있다 보면 항상 솔루션만 내놓는 일이 빈번한데, 왜 그런 솔루션이 나오게 된 것인지 역으로 유추하는 과정을 통해 어떤 needs/pain point에서 비롯되어 이 제품/기능을 만들어야 하는지를 하나의 이야기로 만들어볼 수 있었습니다.
그래서 이번 워크숍을 준비할 때도 persona를 그려보며 준비했습니다.
그 결과로 만들어진 32세 김재동 씨가 제 워크숍의 주요 고객이 되었습니다.
작년에 webOS TV에 들어가는 앱에 paper prototyping 워크숍을 진행하며 빠르게 사용자 시나리오를 그려내는 활동을 했습니다. 일하다 보면 내 머릿속에 있는 생각을 밖으로 꺼내지 않아서 유관부서 사이에 의사소통이 안 되는 경우가 많은데, 기존에 알고 있던 문제점 이외에 잠재된 risk나 미처 생각하지 못했던 issue를 빠르게 도출해볼 수 있었고, 그에 대한 대안을 마련하는 것까지 3시간 만에 완료하며 의사결정에 도움을 주어 그 실효성을 확인할 수 있었습니다.
Persona 만들기와 paper prototyping 작성하기 이 두 가지 활동은 콘셉트 빌딩과 요구사항 도출을 빠르고 쉽게 하는 데 도움을 주었고, 그런 점이 개발자들이 주로 참여하게 될 해커톤과 가장 잘 부합했다고 생각합니다.
이번 Wearable Hackathon에서 진행된 워크숍에서는 wearable watch를 대상으로 다음과 같은 양식으로 persona와 paper prototyping을 전개하였습니다.
해커톤은 아이디어를 제품으로 만들어내는 것을 목표로 1박 2일 정도로 진행하는 것을 보통으로 합니다.
하지만 이번 MC 개발자의 날 웨어러블 해커톤은 오전 2시간 동안 아이디어를 도출하여 구체화하고, 오후 4시간 동안 아이디어를 개발하여 제품을 완성하는 것으로 오전과 오후 세션이 분리되어 진행됐습니다.
그렇게 65명의 참가자가 4~5명씩 한팀이 되어 만들어낸 13점의 결과물입니다.
Persona는 참석자 개인이 하나씩 그렸고, 팀별로 voting을 통해 좋은 아이디어를 하나 선발했습니다. 팀별로 선출한 persona에 대해 paper prototyping을 만들고, 참가자 전원이 팀 별로 만든 내용을 둘러본 후 투표를 진행하여 모든 팀 중에서도 아이디어가 좋은 제품을 뽑는 데에 참여했습니다.
Persona와 paper prototyping은 그림을 잘 그려내는 것이 목적인 활동이 아닙니다.
이전까지는 내 머릿속에만 있는 아이디어를 추상적으로 말로만 전달했던 방식을 눈으로 볼 수 있도록 표현하여 팀원들과 함께 아이디어에 대한 눈높이를 맞추는 방식으로 바꿨습니다. 또, 눈높이를 맞춘 이후 아이디어를 구체화하는 과정을 함께 수행하며 개발을 좀 더 수월하게 시작할 수 있게 되었습니다.
눈여겨 볼 것은, "내가 만들고 싶은 것"에서 끝난 것이 아니고, “우리가 만들어야 할 것"에 대해 충분히 논의했기 때문에 이후에 수행해야 하는 개발 과정이 한결 수월해졌다는 점입니다.
Persona와 paper prototyping을 실제로 수행해보면서 느낀 장점과 기대효과는 우선순위 측면과 사용성 측면으로 구분해 볼 수 있었습니다.
우선순위 측면 : 내가 만드는 제품/feature가 정말로 고객에게 가치 있는 것인가?
Persona - 사용자를 정의하는 것의 의미 : feature가 어떤 pain point와 needs에서 비롯된 것인지 명확히 함
*제품이 제공하려는 기능으로 효과를 보는 고객이 누군지 정확히 정의함
* 제품에 제공될 새로운 기능이나 개선사항이 무엇인지 드러내고 그로 인해 고객이 얻게 될 혜택 가시화하기
Paper Prototyping - 메인 시나리오를 잡는 것의 의미 : 우선순위가 가장 높은 것을 선택 (나무 기둥을 세우는 작업)
*가장 중요한 것 이외의 것들은 예외처리로 간주 함 (예외처리는 나중에 개발하는 것이고, 시간이 없으면 버릴 수도 있다는 의미)
* 기존에는 메인 시나리오와 아닌 것들이 동등한 수준으로 나열되어 우선순위가 잘 보이지 않았으나, 메인이 시나리오 외에 대해서는 뒤에 장면별로 추가하기가 쉽고, 추가된 내용에 대한 우선순위를 부여할 수 있음
* 어떤 이유에 의해 추가된 시나리오를 빼야 하는 경우가 생기면 그에 대한 근거가 되기도 함 (나무의 기둥과 가지라고 생각하면 쉬움)
사용성 측면 : 정말 사용자가 이런 시나리오로 사용하는가?
Persona : 고객을 정의하며 세운 가설이 사실이었는지를 판단
Paper Prototyping :
* 개발 초기에, 코드 한 줄 없이 아이디어나 콘셉트 수준에서도, 누구나, 종이를 가지고, 마치 실제 구현된 시스템인 것처럼, 동작을 시켜볼 수 있음
* 전체적인 그림을 한눈에 볼 수 있음 : 구성한 화면들을 가지고 시뮬레이션하며 이상한 부분은 없는지, 전개한 내용이 적절한지, 더 추가해야 할 내용은 없는지 드러내는 과정을 반복적으로 수행함으로써 사용성 관점에서 검증할 수 있음
* 찾아낸 문제점들에 대한 개선안을 도출하고, 개선안이 기존 대비하여 더 좋아진 부분과 우려되는 부분에 대해 논의할 수 있음
* 테스트 케이스 관점 : 메인 시나리오를 기반으로 예외 케이스를 추가하는 형태로 나열하면 사용성 관점의 테스트 항목 도출이 쉬움
우리가 만들고 시장에 출시하는 제품과 feature는 어떤 pain point와 needs에서 비롯되었을까요?
그렇게 선택되어 제품에 탑재된 feature는 고객에게 어떤 가치를 주고 있을까요?
또 각각의 feature는 어떤 우선순위로 선택되어 제품에 탑재되었을까요?
원본 : http://www.banglab.com/articles/techux-07
1회 보기 : https://brunch.co.kr/@banglab/7
2회 보기 : https://brunch.co.kr/@banglab/8
3회 보기 : https://brunch.co.kr/@banglab/9
4회 보기 : https://brunch.co.kr/@banglab/10
5회 보기 : https://brunch.co.kr/@banglab/11
6회 보기 : https://brunch.co.kr/@banglab/13
