뛰기 전에 코스를 파악하라
마라톤 선수가 코스를 모르고 뛰지 않듯, 해커톤도 시작 전에 파악해야 할 것들이 있다. 팀이 꾸려졌다고 바로 디자인부터 시작할 수 없다. 좋은 서비스는 좋은 이해에서 나온다.
01. BM을 확실히 이해하기
디자이너가 BM(비즈니스 모델)을 왜 알아야 하냐고 묻는다면, 답은 간단하다. 우리가 만드는 서비스가 어떻게 돈을 버는지, 혹은 어떤 가치를 만들어내는지를 모르면 화면을 그릴 수 없다.
더 본질적으로 들어가면, BM을 이해한다는 건 사용자가 이 서비스를 통해 무엇을 얻으려 하는가를 이해하는 것이다. 사용자는 자신의 목적을 달성하기 위해 시간을, 돈을, 혹은 개인 정보를 지불한다. 그 지불이 합리적이라고 느껴질 때 비로소 서비스를 쓴다. 반대로, 얻는 가치에 비해 치르는 비용이 크다고 느끼면 이탈한다.
디자이너는 이 흐름을 화면 위에 구현하는 사람이다. 버튼 하나, 문구 하나에도 "이게 사용자에게 납득이 되는가?"라는 질문을 던질 수 있어야 한다. 해커톤에서는 특히 더 그렇다. 심사위원들은 아이디어의 실현 가능성과 비즈니스적 타당성을 함께 본다. 예쁜 화면보다, 사용자가 왜 이 서비스를 쓰는지 논리가 보이는 화면이 더 강하다.
기획자와 함께 BM을 먼저 정리하고, 사용자가 얻는 가치와 그에 대한 합리적인 대가가 균형을 이루는지 확인한 뒤, 그것을 기반으로 디자인 방향을 잡자.
02. 타겟 유저를 정확히 이해하기
서비스가 누구를 위한 것인지 모르면 디자인도 방향을 잃는다.
시간이 허락한다면 타겟 유저 인터뷰를 직접 진행해보는 것이 가장 좋다. 주변 지인이 타겟에 해당된다면 바로 연락하고, 아니라면 오픈채팅방에서 모집하는 것도 방법이다. 머릿속에서 상상한 유저와 실제 유저는 생각보다 많이 다르다.
만약 시간이 부족하다면 AI와 함께 유저 페르소나와 저니맵 만드는 아래 글을 참고해보자!유저 저니맵 그려보기
타겟 유저를 어느 정도 파악했다면, 꼭 한 번 유저 저니맵(User Journey Map) 을 그려보길 권한다.
유저 저니맵이란, 특정 페르소나(우리 서비스의 대표 가상 사용자)가 서비스를 처음 인지하는 순간부터 목적을 달성하기까지의 전체 여정을 시각화한 도구다. 각 단계에서 유저가 무엇을 하고, 무엇을 느끼고, 어떤 고통을 겪는지를 한눈에 볼 수 있게 해준다.
예를 들어, "퇴근 후 혼자 밥을 먹는 30대 직장인 지은"이라는 페르소나가 있다면, 그녀가 앱을 처음 발견하는 순간 → 회원가입 → 메뉴 탐색 → 주문 → 배달 대기 → 서비스 재사용까지의 흐름을 그려보는 것이다. 이 과정에서 "왜 이 화면에서 이탈할 수 있는가", "어느 지점에서 불편함을 느끼는가"를 미리 파악하면, 디자인이 훨씬 뾰족해진다.
디자이너의 주 업무는 아름다운 화면을 만드는 것이 아니라, 유저가 목적지까지 막힘 없이 도달하도록 길을 설계하는 것이다. 유저 저니맵은 그 길을 설계하기 위한 지도다. 팀원들과 함께 이 지도를 먼저 그린 뒤에 화면 작업에 들어가자.
03. 레퍼런스 및 경쟁 서비스 공부하는 방법
나에겐 지금 뛰는 코스가 처음 뛰는 코스라도, 누군가는 이미 이 코스를 달렸다. 그리고 앞서 완주한 선수의 기록은 남아있다. 같은 문제를 먼저 풀어낸 서비스들이 있다면 반드시 뜯어봐야 한다.
단순히 UI가 예쁘다 못생겼다가 아니라, 어떤 플로우로 유저를 유도하는지, 어떤 화면에서 핵심 가치를 전달하는지를 분석하는 것이 중요하다.
경쟁사 분석 도표 만들기
경쟁 서비스를 비교할 때 가장 효과적인 방법은 기능 비교 도표를 직접 그려보는 것이다. 각 경쟁사가 보유한 기능들을 나열하고, 우리 서비스와 나란히 놓아보자.
예시 구조는 아래와 같다:
단순히 있다/없다를 체크하는 데서 끝내지 말고, 참고할 서비스와 각 기능의 장단점을 함께 정리해보자. 어떤 기능을 넣고 어떤 기능을 뺐는지에는 이유가 있다. 기능이 많다고 좋은 서비스가 아니다. 어떤 서비스는 기능을 과감하게 덜어냄으로써 오히려 핵심 가치가 더 선명하게 보이기도 한다.
이 과정에서 "우리 솔루션에 꼭 필요한 것은 무엇인가", "오히려 덜어내야 할 것은 무엇인가"를 팀원들과 함께 논의하면 기획이 훨씬 뾰족해진다.
레퍼런스는 Mobbin, Dribbble, 디자이너스 등 다양한 레퍼를 모아둔 서비스들이 있지만, 직접 앱을 설치해 써보는 것이 가장 좋다. 실제로 써봐야 유저가 느끼는 맥락이 보인다.
04. 최소한의 디자인 시스템 구축하기
해커톤에서 풀 디자인 시스템을 만들 시간은 없다. 하지만 최소한의 규칙은 반드시 있어야 한다. 앱이든 웹이든, 아래 항목들은 작업 시작 전에 꼭 정의해두자.
BI 로고 & 파비콘
서비스의 얼굴이다. 해커톤이라도 로고 하나는 만들어야 한다. 발표 자료에, 앱 아이콘에, 브라우저 탭의 파비콘에 들어간다. 정교한 로고가 어렵다면 텍스트 기반 로고라도 서체와 컬러를 명확히 정의해두자.
텍스트 스타일
제목(Heading), 본문(Body), 캡션(Caption) 등 텍스트 스타일을 미리 정의해두면 화면 전체의 통일감이 생긴다. 폰트 종류, 굵기, 크기, 행간까지 세트로 정해두자. 피그마에서 텍스트 스타일로 등록해두면 수정할 때도 한 번에 처리할 수 있다.
컬러 스타일
프라이머리, 세컨더리, 배경, 텍스트, 에러 컬러 정도만 정의해도 충분하다. 타겟 유저와 BI 방향을 기반으로 결정하고, 피그마 컬러 스타일에 등록해두자. 중간에 컬러를 바꿔야 할 때 전체를 일괄 수정할 수 있어 시간이 절약된다.
그리드
화면을 구성하는 보이지 않는 뼈대다. 모바일이라면 4pt 또는 8pt 그리드, 웹이라면 12컬럼 그리드를 기준으로 잡는 것이 일반적이다. 그리드 없이 화면을 그리면 나중에 개발자가 수치를 정리하느라 시간을 낭비한다. 그리드 계산기를 써서 우리 서비스에 알맞은 width값을 찾아보자.
코어 컴포넌트
반복적으로 쓰이는 요소들을 피그마 컴포넌트로 만들어두자. 최소한으로 챙겨야 할 것들은 다음과 같다.
•
헤더: 앱바, 네비게이션 바
•
버튼: Primary, Secondary, Disabled 상태
•
아이콘: 자주 쓰는 아이콘 세트
•
인풋 필드: Default, Filled, Error 상태
•
카드: 콘텐츠 단위 컴포넌트
컴포넌트 네이밍 규칙도 개발자와 미리 맞춰두면 핸드오프 때 혼선이 줄어든다. 디자이너 혼자만 아는 이름으로 만들어두면 협업 단계에서 반드시 병목이 생길 수 있으니 유명한 디자인시스템들을 참고해보자.
G마켓 디자인시스템이 잘 정리되어있으니 참고해보자.
G마켓 디자인 시스템
https://gds.gmarket.co.kr/components
준비가 곧 실력이다
출발 총성이 울리기 전, 코스를 파악하고 장비를 점검하는 시간. 많은 팀들이 이 시간을 아깝다고 느끼고 바로 달리기 시작한다. 그리고 중반쯤에서 흔들린다. 방향을 잃거나, 팀원끼리 다른 그림을 그리고 있었다는 걸 그제야 깨닫는다.
BM을 이해하고, 유저를 정의하고, 경쟁사를 뜯어보고, 디자인 시스템을 세팅하는 것. 이 네 가지는 화면을 한 장도 그리지 않는 시간처럼 느껴지지만, 사실 이 시간이 이후의 모든 작업 속도를 결정한다. 준비된 팀은 막히지 않는다. 판단이 빠르고, 수정이 적고, 핸드오프가 깔끔하다.
해커톤의 승부는 생각보다 일찍 갈린다. 출발 전에 이미 반은 결정되어 있다.
자, 이제 코스를 파악했는가?
