프로덕트 디자이너로 일한다는 것은 단순히 화면을 예쁘게 만드는 것을 넘어, 사용자 경험의 핵심을 고민하며 문제를 정의하고 해결책을 설계하는 과정의 연속입니다. 특히 DEVTH*와 같은 B2B 플랫폼에서는 다양한 사용자 그룹과 복잡한 요구사항 속에서 문제를 발견하고 해결해야 하는 능력이 중요하죠. 구름의 DEVTH 디자이너들이 어떤 접근 방식을 사용해 제품을 개선하는지 그 전반의 과정을 소개합니다. 
_{ⓘ DEVTH는 기업과 학교에서 채용과 평가를 위해 사용하는 B2B 코딩테스트 플랫폼입니다.} 

프로덕트 디자이너의 핵심 역할
문제 정의와 문제 해결 

DEVTH 디자이너에게 가장 중요한 덕목은 ‘사용자 중심 사고’입니다. 단순히 사용자 관점에서 생각하는 것을 넘어, 사용자가 겪는 문제를 깊이 이해하고 이를 해결하기 위한 디자인을 고민합니다. 사용자 중심 사고는 문제 정의 능력과 빠른 실행력으로 이어지며 디자이너가 사용자 경험을 지속적으로 개선하도록 돕습니다. 

사용자 중심 사고의 세 가지 축

• 사용자 중심 사고: 사용자의 실제 경험을 면밀히 관찰하며 문제를 정의하고 이를 해결하기 위한 실질적인 설계 방안을 고민합니다. 제품이 단순히 동작하는 것을 넘어 사용자에게 직관적이고 매끄러운 경험을 제공합니다. 
• 문제 정의 능력: 데이터를 분석하고 사용자 인터뷰를 통해 문제의 본질을 구체적으로 정의합니다. 문제가 명확히 정의되어야만 적합한 해결책을 도출할 수 있습니다.
• 빠른 실행력: 설계된 해결책을 빠르게 테스트하고 사용자 피드백을 반영해 개선하는 과정을 반복합니다. 이를 통해 최적의 결과를 만듭니다. 

문제 정의

문제를 정의하는 과정은 제품 개선의 첫걸음이자 가장 중요한 단계입니다. DEVTH 디자이너들은 다양한 방법을 활용해 문제의 본질을 파악합니다.  

• 사용자 인터뷰: 실제 사용자와 인터뷰를 통해 문제를 심도 있게 이해합니다. 특히 DEVTH는 관리자, 감독관, 응시자라는 세 가지의 사용자 그룹을 대상으로 서비스하기 때문에 각 그룹의 피드백을 세밀히 들여다보는 것이 중요합니다. 
• 테스트 시나리오 설계: 사용자가 제품을 사용하는 과정을 구체적으로 설계합니다. 이 과정에서 사용자가 어느 포인트에서 불편함을 느끼는지 관찰합니다. 테스트에서 발견한 페인포인트는 이후 제품 개선 방향성을 설정하는 데 중요한 단서를 제공합니다. 

문제 해결

문제를 정의했다면 이제는 해결할 차례입니다. DEVTH 디자이너들은 문제를 해결하기 위해 다음과 같은 프로세스를 거칩니다.  

• 테스트를 통한 검증: 설계한 해결책이 실제로 효과가 있는지 테스트합니다. 초기 설계 단계에서 모든 문제를 예측할 수 없기 때문에 테스트는 해결 과정에서 필수적인 과정입니다. 
• 지속적인 개선: 테스트 결과를 바탕으로 얻은 피드백을 통해 디자인과 기능을 개선합니다. 이 과정은 궁극적으로 사용자 경험을 한층 더 끌어올리는 데 기여합니다. 

사용자 중심의 시도
사용성 테스트(UT)

DEVTH 프로덕트 디자이너들은 문제를 정의하고 해결하기 위해 ‘사용성 테스트(UT, Usability Test)’를 적극적으로 활용합니다. UT는 사용자가 제품을 실제로 사용하는 모습을 관찰하며 설계된 해결책이 효과적인지 검증하는 방법입니다. 이 과정에서 사용자의 행동 경로 파악, 비언어적 신호 분석, 놓치고 있던 문제 등을 발견할 수 있습니다.  

DEVTH에서는 특히 응시자 그룹의 경험을 개선하기 위해 UT를 진행했습니다. DEVTH는 B2B 플랫폼인 만큼 응시자에게 직접 피드백을 받기 어려운 환경이지만 시험을 치르는 과정에서 겪는 불편함과 방해 요소를 적극 파악하고자 했습니다. 

UT 진행 과정

1. 테스터 모집
‘DEVTH를 처음 사용하는 개발자’와 ‘DEVTH를 한두 번 사용한 경험이 있는 개발자’ 이렇게 두 그룹으로 나누어 테스터를 모집했습니다. 응시자와 가장 유사한 상황을 재현하기 위해 두 그룹으로 나누어 다양한 관점을 수집하고, 예상치 못한 문제를 발견할 가능성을 높였습니다.

2. 테스트 시나리오 설계
UT 시나리오는 <이메일 로그인 → 대기실 입장 → 기기 환경 점검 → 시험실 입장>으로 이어지는 시험 전 과정을 중심으로 설계했습니다. 이 단계는 응시자가 가장 초조함을 느끼는 구간으로, 사용자가 겪는 문제를 확인하는 것이 목표였습니다.

3. 테스트 진행

실제 응시자들이 시나리오에 따라 제품을 사용하며 느끼는 불편함과 혼란을 실시간으로 모니터링했습니다. ‘소리 내어 말하기’ 기법*을 활용해 사용자의 행동과 생각을 동시에 관찰했습니다. 행동만 보고 기록하기보다 어떤 지점에서 액션을 취하는지도 확인하고자 했으나 모든 순간에서 ‘소리 내어 말하기’가 통하긴 어려운 점 있었습니다. 다만, 예상과 다른 행동이 나타나면 추가 질문을 통해 원인을 분석했습니다. 
_{ⓘ 소리 내어 말하기 기법(Think aloud Protocol)은 참가자가 특정 작업을 수행하는 동안 자신의 생각을 말로써 표현하는 것을 말합니다. 작업을 수행하며 어떤 부분에서, 어떤 감정을 경험하는지 도출하는 방법입니다.} 

4. 테스트 종료
테스트 직후 응시자의 소감을 듣고 설문조사를 통해 가장 어려웠던 점을 구체적으로 정리했습니다. 이를 바탕으로 개선 방향성을 구체화했습니다.

UT를 통해 알게 된 것들
문제점과 해결책

사용성 테스트를 통해 다양한 문제점이 드러났습니다. 특히 응시자 중 절반만이 시험실에 정상적으로 진입하는 점도 발견됐습니다. 상당수의 응시자가 이메일 초대장의 계정 정보를 제대로 확인하지 못해 로그인 과정에서 어려움을 겪었습니다. 또한 기기 환경 점검 과정에서 불명확한 안내와 시스템 오류로 인해 시험실에 진입하지 못하는 문제도 발생했습니다. 이러한 문제는 응시자들이 긴장과 초조함 속에서 제품을 사용하는 현실을 반영한 것이었습니다. 

이 과정에서 디자이너들은 사용성 문제뿐만 아니라 심리적 요인까지 고려해야 한다는 중요한 교훈을 얻었습니다. 단순히 기능적 문제를 해결하는 것을 넘어, 응시자가 느끼는 불안감을 완화할 수 있도록 CS 채널이나 서비스 가이드를 직관적으로 제공하는 것이 중요해 보였습니다. 

UT를 통해 얻은 데이터는 DEVTH 디자이너가 어디에 집중해야 하는지 지표가 됐습니다. 이 데이터를 기반으로 제품 개선 작업을 진행했습니다. 크게 이메일 로그인 가이드 강화, 응시 환경 점검 UX 개선, 심리적 지원 채널을 마련 후 빠르게 개선 작업을 진행해 사용자 경험을 향상시켰습니다. 

결국 중요한 것,
사용자 중심의 제품

프로덕트 디자이너는 문제를 정의하고 해결하는 과정을 통해 사용자 경험을 끊임없이 개선합니다. 구름의 DEVTH 디자이너들은 사용성 테스트를 기반으로 사용자 중심의 인사이트를 도출하고, 이를 바탕으로 빠르게 실행하며 제품을 개선합니다. 

이 과정은 단순히 문제를 해결하는 데 그치지 않고 사용자와 더 깊이 연결된 제품을 만들어가는 데 기여합니다. 앞으로도 구름 DEVTH는 사용자 경험을 중심으로 한 제품 개선을 통해 사용자에게 더 나은 경험을 제공하겠습니다.

 Text Niya, Mindy Edit Daisy Design Dex

사용자 중심의 제품을 함께 만들어 갈
프로덕트 디자이너를 기다립니다.

The post 프로덕트 디자이너가 제품을 개선하는 방법  appeared first on 구름 공식 블로그 (goorm blog).

배움의 이유는 사람마다 다릅니다. 어떤 이는 부족함을 채우기 위해, 또 누군가는 새로운 가능성을 열기 위해 교육을 선택하죠. 부트캠프에 도전하는 사람들도 마찬가지입니다. ‘개발자가 되기 위해서’라는 단순한 답변 뒤에는 각자의 특별한 도전 이유가 숨겨져 있습니다.

구름톤 딥다이브에는 스스로의 부족함을 극복하고, 더 나아가 사용자의 불편함을 해결하기 위해 도전한 사람들이 모여 있습니다. 현재 진행형인 딥다이브 수강생의 성장 이야기를 지금 확인해 보세요.

안녕하세요. 자기 소개를 부탁드립니다. 

이재혁(풀스택 과정 수강생)  안녕하세요. 저는 구름톤 딥다이브 풀스택 과정을 수강 중인 이재혁입니다. 대학에서 데이터 테크놀로지를 전공하고 있습니다. 

이동관(프론트엔드 기반 프로덕트 디자이너 과정* 수강생)  안녕하세요. 저는 경영학을 전공하고 교육 회사에서 사업 기획자로 근무하다가 새로운 도전을 위해 구름톤 딥다이브 프론트엔드 기반 프로덕트 디자이너 과정을 수강하게 된 이동관입니다. 
^{_{*이하 ‘프로덕트 디자이너 과정’으로 표기합니다.}}  

예비 개발자와 프로덕트 디자이너 두 분을 만나게 됐네요. 직무가 서로 다르신 만큼 딥다이브를 선택한 이유도 각기 다를 것 같습니다. 어떻게 딥다이브와 함께하게 되셨나요?

이재혁(풀스택 과정 수강생)  저는 전공자임에도 불구하고 늘 실력에 대한 부족함을 느꼈어요. 주변 친구들 중 뛰어난 실력을 갖춘 이들을 보며 ‘쟤네는 왜 저렇게 잘할까?’라는 생각을 많이 했죠. 알고 보니 그 친구들 대부분이 외부에서 교육을 받고 있었더라고요. 특히 개발 실력이 가장 뛰어났던 친구가 구름 KDT 과정을 수료한 것을 보고 저도 그 친구처럼 더 잘하고 싶어졌어요. 제 목표는 풀스택 개발자지만 프론트엔드 분야에 취약한 상태였거든요. 현업에서 유연하게 일하려면 이 부분을 반드시 보완해야 한다고 판단했고, 그렇게 구름톤 딥다이브에 지원하게 됐습니다.

이동관(프로덕트 디자이너 과정 수강생)  처음에 디자인을 잘 모를 때는 단순히 ‘무언가를 그리는 일’이라고만 생각했는데 프로덕트 디자인은 사용자 경험을 설계하고 프로덕트를 기획하는 과정이더라고요. 제가 원하던 커리어였죠. 이전에 다른 부트캠프에 자비로 참여한 경험이 있는데 비용 부담이 꽤 컸습니다. 구름톤 딥다이브는 국비 지원 교육이지만 실제 비용으로 환산하면 2천만 원 이상의 가치가 있는 과정이에요. 커리큘럼을 확인했을 때 그 이상의 값어치를 느꼈습니다. 

딥다이브 과정을 수강하며 배움의 터닝포인트가 있었나요? 그 경험이 두 분께 어떤 영향을 미쳤는지도 궁금합니다.

이재혁(풀스택 과정 수강생)  아이러니하게도 가장 힘들었던 점이자 결과적으로 가장 좋았던 점은 학교 공부와 딥다이브를 병행한 거예요. 다행히 마지막 학기라 비교적 여유가 있었지만 딥다이브에서 배운 내용이 전공 과목에 직접적인 도움을 주었죠. 예를 들어 데이터베이스나 CS 과목에서 배운 이론을 딥다이브 프로젝트를 통해 직접 구현해 보니 개발이 더 재미있게 느껴졌어요. 이론과 실무를 균형 있게 배우고 있다는 생각이 들었고 학교 수업과 딥다이브 경험이 긍정적인 순환을 만들어냈습니다.

또 풀스택 과정에서는 프론트엔드와 백엔드, 그리고 클라우드 분야까지 경험할 수 있어요. 클라우드도 직접 접해보니 자연스럽게 그 분야에도 관심이 생기더라고요. 풀스택 과정의 큰 장점은 여러 분야를 경험하며 개발자의 시야를 넓힐 수 있다는 점이라고 생각해요. 아직 학생이지만 이렇게 이론과 실무를 모두 배우게 된다면 더 넓은 시야를 가진 개발자로 성장할 수 있지 않을까란 기대감도 들어요.

이동관(프로덕트 디자이너 과정 수강생)  처음 디자인 작업을 하면서 웹 서비스의 작동 원리를 이해하게 됐어요. 버튼 하나를 누르는 간단한 동작에도 얼마나 복잡한 프로세스가 숨어 있는지 알게 됐죠. 데이터베이스와의 상호 작용까지 고려해 보는 이 경험이 이후에 개발자나 기획자와 협업할 때 큰 자산이 될 거라는 생각이 문득 들더라고요. 프로덕트 디자인은 단순히 화면을 그리는 것이 아니라, 설계와 기획의 관점에서 사용자 경험 전체를 설계하는 과정이라는 걸 깨닫게 됐던 그때가 기억에 남습니다. 

딥다이브는 다양한 팀 프로젝트를 진행하는데요. 팀원들과의 협업 경험은 어떠셨나요?

이재혁(풀스택 과정 수강생)  딥다이브에서 제가 가장 크게 배운 것은 ‘협업하는 법’이에요. 저는 네트워킹 시간과 스터디 문화를 정말 좋아하는데요. 함께 공부하는 수강생들과 서로의 공부 방법을 공유하고, 일주일 동안의 배움을 회고하면서  자신을 되돌아보는 습관이 생겼어요. 이런 회고 과정이 제가 더 나은 개발자로 성장하는 데 중요한 발판이 되어주지 않을까 싶어요. 

풀스택 개발자는 프론트엔드부터 백엔드, 클라우드까지 다룰 수 있어야 해요. 하지만 기술뿐 아니라 소통과 협업 능력이 필수라고 생각해요. AI가 코딩을 도와줄 수는 있어도 사람들과 함께 일하며 문제를 해결하는 능력은 대체할 수 없으니까요. 딥다이브는 이러한 소통 능력을 배우기에 좋은 환경이에요. 

이동관(프로덕트 디자이너 과정 수강생)  딥다이브의 팀 프로젝트는 정말 특별한 경험이에요. 팀에는 디자인, 기획, 개발이 익숙한 사람도 있고, 모든 것이 처음인 사람도 있어요. 하지만 이런 다양한 배경을 가진 사람들이 함께 배우고 서로 도와가며 성장합니다. 모자란 부분을 채워주고 함께 고민하며 해결책을 찾는 팀워크를 경험하면서 자연스럽게 팀 커뮤니케이션의 중요성을 배우고 있어요. 

두 분 모두 ‘개발자’와 ‘프로덕트 디자이너’라는 목표가 있으실 것 같아요. 교육 과정을 수강하며 스스로의 성장 가능성을 발견하신 순간이 있나요?

이재혁(풀스택 과정 수강생)  딥다이브를 하면서 가장 크게 느낀 점은 세상에 정말 열심히 사는 사람들이 많다는 거예요. 저보다 더 열정적으로, 악착같이 배우는 분들을 보면서 스스로 더 분발해야겠다는 자극을 많이 받았어요. 스터디와 팀 프로젝트를 함께하며 ‘나도 더 열심히 해보자’라는 다짐이 자연스럽게 생겼습니다.

이때 또 깨달은 점은 저는 ‘하나를 지독하게 끝까지 파고드는 사람’이라는 거예요. 한 가지에 꽂히면 그걸 완전히 이해하려고 깊게 파고들죠. 이게 속도만 붙으면 나중에는 여러 분야에도 적용될 수 있을 거라고 믿어요. 발견한 제 강점을 토대로 그동안 쌓아온 개발 지식과 딥다이브의 경험까지 더해지면 풀스택 개발자로서 더 큰 무기를 갖게 될 것 같습니다.

이동관(프로덕트 디자이너 과정 수강생)  저는 이전까지 배움을 따로 기록하는 사람이 아니었어요. 하지만 딥다이브를 시작하면서 ‘구름 EXP’에 배움 일기를 작성하기 시작했죠. 처음에는 조금 귀찮기도 했지만 강사님이 늘 기록의 중요성을 강조하셨거든요. 하루를 돌아보며 ‘무엇을 배웠는지’, ‘아쉬웠던 점은 무엇인지’, ‘팀 활동에서 느낀 점은 무엇인지’를 정리하다 보니 어느덧 한 달 넘게 하루도 빠짐없이 기록을 남기고 있어요. 

이 기록이 쌓이면 포트폴리오로서도 큰 도움이 될 뿐만 아니라 제 개인적인 성장에도 큰 영향을 줄 것 같아요. 하루를 되돌아보며 회고하는 과정에서 저 스스로 더욱 성실해졌고, 삶을 채우는 방법이 이전과는 많이 달라졌다는 걸 느낍니다. 

지금까지 경험한 딥다이브를 한마디로 정의한다면 어떻게 표현할 수 있을까요? 그 이유도 궁금합니다. 

이재혁(풀스택 과정 수강생)  딥다이브는 ‘자신감의 근원’이에요. 처음 시작할 때만 해도 제 실력에 대한 의심이 있었어요. ‘내가 과연 해낼 수 있을까?’라는 생각이 떠나지 않았죠. 하지만 달라진 저를 발견했어요. 단순히 기술을 익히는 것을 넘어 성장하고 있다는 확신을 딥다이브에서 얻게 됐거든요. 긍정적인 경험들이 점점 쌓이면서 스스로에 대한 믿음과 자신감이 생겼습니다.

이동관(프로덕트 디자이너 과정 수강생)  딥다이브는 ‘자신을 개선하는 기회’예요. 교육 과정명처럼 깊이 있게 학습하는 환경을 경험하고 있어요. 사용자 경험을 개선하는 법을 배우고 있지만, 정작 가장 크게 개선되는 건 저 자신이더라고요. 제 실력, 경험, 그리고 생각하는 방식이 모두 발전하고 있어요. 제품을 업그레이드하듯 저도 더 나은 버전의 나로 나아가고 있다는 느낌을 받습니다.

교육 과정을 마치고 이루고 싶은 목표가 있다면요?

이재혁(풀스택 과정 수강생)  제 목표는 제너럴리스트와 스페셜리스트를 모두 아우르는 풀스택 개발자가 되는 거예요. 여러 분야를 이해하고 다양한 역할을 해낼 수 있는 유연함을 갖추되, 한 분야에서는 깊이 있는 전문성을 가진 사람이 되고 싶습니다. 지금 배운 기술과 경험을 바탕으로 차근차근 성장해 나갈 계획이에요.

이동관(프로덕트 디자이너 과정 수강생)  딥다이브를 통해 제 목표가 더 명확해졌어요. 이전에는 심미성에 집중한 디자이너를 꿈꿨다면, 이제는 사용자 경험과 비즈니스 임팩트를 모두 고려하는 디자이너가 되고 싶습니다. 사용자에게 프로덕트의 진짜 가치를 전달할 수 있는 사람이 되는 게 목표예요. 비즈니스와 사용자 관점에서 균형 잡힌 시각을 갖추기 위해 꾸준히 배우고 실력을 쌓아 나가려고 합니다.

딥다이브를 선택함에 앞서 고민하고 계신 분들이 있으실 것 같아요. 지금의 경험을 토대로 선배 플레이어로서 전해주실 수 있는 조언이 있으실까요?

이재혁(풀스택 과정 수강생)  딥다이브를 고민하고 있다면 우선 도전해보세요. 저도 처음에는 제 실력이 부족하다고 느껴 망설였지만 딥다이브에서 그런 걱정들이 해소됐어요. 기술적으로 성장하는 건 물론이고, 저 자신에게도 믿음과 자신감이 생겼거든요. 부족하다고 느끼는 분들이라면 이 과정에서 열정을 쏟아부어 보는 것만으로도 큰 성장의 기회를 얻을 수 있을 겁니다. 힘들고 어려운 순간도 있지만 그만큼 값진 결과를 얻게 될 거예요.

이동관(프로덕트 디자이너 과정 수강생)  많은 분이 국비지원 교육에 대해 의심하거나 ‘내가 직접 돈을 내지 않았으니 열심히 하지 않아도 되지 않을까?’라고 생각할 수도 있어요. 하지만 저는 다르게 생각해요. 딥다이브가가 얼마나 큰 기회인지 깨닫고 마치 내가 직접 비용을 지불했다는 마음가짐으로 임하고 있어요. 이 교육이 단순히 ‘공짜 기회’가 아니라 내 커리어를 위한 ‘값진 투자’라고 생각한다면 더 큰 성과를 얻을 수 있을 겁니다.

Interviewee leejaehyuk, leedonggwan Edit Daisy Design Bea

개발자, 프로덕트 디자이너를 꿈꾼다면
지금 딥다이브와 함께하세요.

The post 구름톤 딥다이브 수강생 후기｜예비 개발자와 프로덕트 디자이너의 성장 노트 appeared first on 구름 공식 블로그 (goorm blog).

구름IDE 스쿼드에서 진행한 A/B 테스트에 함께한 덕분에 데이터 기반의 디자인을 좀 더 이해하게 되었습니다. 제가 프로덕트 디자인을 하며 데이터를 어떻게 경험했는지 그 과정을 공유해보겠습니다.

ⓘ A/B 테스트 : 두 요소 중 어떤 것이 더 좋은 효율을 내는 지 일정한 시간을 두고 비교해보는 방법론

A/B 테스트를 한 이유

우리 팀의 목적 중 하나는 더 많은 사람이 구름IDE를 사용하는 것입니다. 이를 위해 그로스 마케터가 데이터를 분석하여 임팩트가 큰 문제를 정의하고 가설을 도출하게 되죠.

우리는 신규 유저의 퍼널 중 이탈률이 가장 높은 메인 페이지의 CTA 버튼 클릭률을 개선하는 것이 MAU 성장이라는 목표 달성에 큰 임팩트를 줄 것이라 정립했습니다. 이렇게 5개월에 걸친 구름IDE CTA 버튼 클릭률 개선 A/B 테스트 대장정이 시작되었습니다.

테스트 여정

첫 번째 테스트 : 문구 VS 문구

메인페이지는 왜 이탈률이 높았을까요? 신규 유저는 왜 아무런 액션 없이 이탈했을까요? 저희는 메인페이지에 도착했을 때 사용자가 처음 마주하는 메시지의 설득력이 약하다고 판단했습니다. 그래서 세운 가설은 다음과 같습니다.

‘구름IDE를 직관적으로 설명했을 때 CTA 버튼 클릭률이 상승할 것이다.’

그 결과, CTA 버튼 클릭률이 2% 상승했습니다. 5% 상승이 목표였기 때문에 더 공격적인 가설 하에 추가 테스트를 계획했죠.

두 번째 테스트 : 문구 VS 문구+이미지

구름IDE를 더 직관적으로 보여주기 위해 이미지를 추가했습니다. 실제 서비스 경험을 예상할 수 있도록 구름IDE의 콘솔과 에디터 이미지를 토글로 보여줬죠.

‘이미지를 사용하여 구름IDE를 설명하면 직관성이 높아져 CTA 버튼 클릭률이 상승할 것이다.’

두 번째 테스트는 첫 번째 테스트보다 실험군 간 차이가 크기 때문에 당연히 결과도 드라마틱하게 개선될 거라 기대했습니다. 하지만 결과는 예상과는 달랐어요. 시각적인 정보를 추가한 실험군이 더 낮은 CTA 버튼 클릭률을 기록했죠.

세 번째 테스트 : 컨셉

테스트 결과가 기대보다 부진했던 탓에 약간의 답답함을 느꼈습니다. 그래서 세 번째 테스트에서는 두가지 변화를 주어 돌파구로 삼으려 했죠.

먼저, A/B 테스트를 MVT 테스트로 변경했습니다. MVT 테스트는 다변량 테스트로 불리기도 하는데요. A/B 테스트는 2개의 실험군을 비교하는 반면 MVT 테스트는 여러 실험군을 동시에 테스트할 수 있어 테스트 시간을 단축할 수 있다는 이점이 있죠.

그리고 테스트 주제를 바꿨습니다. 이전과 다른 관점으로 도출한 가설이 필요하다고 생각했거든요. 이전 테스트에서는 세부 요소를 개선하는 방향이었다면 이번엔 구름IDE를 잘 설명할 수 있는 컨셉 자체를 찾고자 했죠.

1) 컨셉 도출

유저의 행동 동기를 유발할 수 있는 소구 포인트에서 세가지 컨셉을 도출했습니다. 기존안을 포함하여 총 네가지 컨셉안으로 테스트를 설계했습니다.

컨셉 A. 대조군 ‘기존안’

컨셉 B. 서비스 기능 강조 ‘편리한 에디터 UI’

컨셉 C. 서비스 가치 강조 ‘고객 사례’

컨셉 D. 서비스 지표 강조 ‘글로벌 데이터’

2) 컨셉을 반영한 디자인

이제 프로덕트 디자이너인 제가 가장 깊은 고민을 하는 순간입니다. 대조군 외 3가지 컨셉을 각각 어떻게 표현해야 할까요?

컨셉 B. 편리한 에디터 UI

B 컨셉은 에디터 UI의 편리성을 강조하는 데 집중했습니다. 에디터 화면에 시선이 가도록 부수적인 디자인 요소는 제거했어요.

컨셉 C. 고객 사례

C 컨셉에서 디자인으로 표현하고자 했던 메시지는 ‘구름IDE를 사용하면 이런 결과물을 만들 수 있어요!’였습니다. 이를 위해 이제까지 구름IDE에서 제작된 멋진 프로젝트를 나열해서 유저의 상상력을 자극했어요.

컨셉 D. 글로벌 데이터

D 컨셉에서는 다양한 국적의 사람들이 사용하고 있는 세계적인 서비스라는 점을 강조하기 위해 지구를 모티브로 활용했습니다. 구름IDE가 달성한 숫자를 직관적으로 노출하고 신뢰를 줄 수 있도록 무게감 있게 디자인했습니다.

3) 테스트 결과

이제 테스트를 위한 준비는 모두 끝났습니다. 자체 디자인 QA를 했을 때 서비스 가치를 소구한 C안이 가장 큰 개선을 보일 거라 예상했는데요, 예상과는 다르게  D안이 가장 높은 CTA 클릭률을 보였습니다. 기대를 했던 C안은 대조안 대비 약 -28%가 개악된 반면, D안은 약 7%나 개선되었죠.

D안은 CTA 클릭률 뿐만 아니라 이후 전환 행동에서도 개선된 추이를 보였습니다. 특히 한국 대비 외국에서 2배 이상의 개선율을 보인 점을 의미있게 해석했는데요, 각 언어권의 컨셉 수용 정도를 파악할 수 있었습니다.

결과적으로 각 언어권 별 CTA 클릭률, 이후 전환 행동 지표를 종합적으로 분석하여 D안이 가장 좋은 안이라 판단할 수 있었습니다.

테스트를 하며 배운 점

A/B 테스트도 MVT 테스트도 언제나 답은 아닙니다. 단번에 의미 있는 결과를 내기란 어렵기도 하고요. 유저 입장에서 고민했지만 제 생각과 유저의 생각이 다를 수 있음을 테스트를 하며 경험했습니다. 그럼에도 프로덕트 디자이너가 데이터를 기반으로 디자인하는 것에는 분명한 장점이 있습니다. 이번 글에서 주로 다룬 CTA 클릭률 외에도 퍼널 내 행동 세부 지표를 보며 내가 만든 디자인에 대한 확신을 데이터를 보며 쌓아갈 수 있으니까요.

구름은 히트맵, 리코딩 등 다양한 기능을 활용하여 테스트를 고도화하고 있습니다. 앞으로도 꾸준한 실험을 통해 더 좋은 서비스를 만들겠습니다.

함께 할 프로덕트 디자이너를 찾습니다

구름에서는 데이터 기반으로 의사소통하는 것을 중요하게 생각합니다. 이를 위해 Google Analytics, Amplitude, Hackle, Smartlook 등 다양한 데이터 툴을 활용하고 있습니다. 함께 데이터를 기반으로 구름 서비스의 사용성을 개선할 디자이너를 찾고 있어요. 아래 채용 공고에 많은 관심 부탁드립니다.

Text Judy Edit Ian Design Lily

The post 프로덕트 디자이너의 A/B 테스트 적응기 appeared first on 구름 공식 블로그 (goorm blog).

지난 1월 구름에 입사 후 벌써 5개월이 지났는데요. 5개월이라는 기간 중 무려 3분의 1이 넘는 시간을 들였던 구름 UX 라이팅 가이드라인 제작 프로젝트가 마무리되고 있어 2달간의 여정을 나누고자 글을 쓰게 되었습니다!

이 프로젝트는 저의 입사 동기인 프로덕트 디자이너 사이안(참고)과 함께 진행했고, 뉴비 디자이너인 저희를 위해 디자인팀과 커뮤니케이션팀에서 많은 도움을 주셨습니다.

발단

구름 디자인팀은 매일 사내에서 자체 제작한 StandUp&Prosper을 통해 디자인과 관련해 공유하고 싶은 좋은 글이나 자료를 공유하는 문화를 가지고 있는데요. 몇 개월 전부터 부쩍 UX 라이팅에 대한 아티클 공유가 활발해지고 있었습니다.

이 과정에서 점차 UX 라이팅이 디자인팀에 스며들어가며… 결국! 시작하게 되었습니다!

본격적인 시작에 앞서

본격적인 UX 라이팅 가이드라인을 확립하기에 앞서 필요성과 우리의 현 상황을 확인하기 위해 전체 서비스 문구를 점검하는 과정을 거쳤습니다. 구름은 여러 서비스(EDU, DEVTH, LEVEL, IDE)를 운영하고 있기 때문에 각 서비스 별로 쓰인 모든 문구를 일일이 확인하기란 꽤나…어려운 일이었는데요.

다행스럽게도 저희에겐 뛰어난+친절한 개발자분들이 계셨습니다!

요청한지 10분도 안 돼 서비스의 모든 문구를 보기 좋게 모아주신 믿.쓰.마(믿고 쓰는 마크) 마크와 갓호세 감사의 박수() 드립니다!

모인 문구들을 바탕으로 우리 서비스를 점검한 결과 서비스 내 어조의 일관성 부족과 잘못된 표현의 사용으로 브랜드 경험을 저해하고 있다는 결론이 나왔습니다.

UX 라이팅의 필요성을 확인 후, 이러한 문제를 해결하기 위해 본격적으로 2달간의 여정을 시작했습니다!

구름의 보이스톤 만들기

1. Brand Core Value

구름 서비스 전체에 적용될 가이드라인을 만들어가는 첫 과정으로 우리 브랜드만의 목소리를 만드는 시간을 가졌습니다.

저희는 린브랜딩 방법을 참고해 브랜드 코어 밸류를 정리하는 작업을 진행했고, 3가지 코어 밸류를 도출했습니다.

구름은 ‘모두가 개발자가 된다’라는 미션 아래 개발 생태계를 가꿔나가고 있습니다. 그리고 이러한 구름이라는 브랜드를 설명할 수 있도록 코어 밸류를 설정했습니다.

2. 구름을 대표할 Persona

앞선 과정으로 정리한 구름의 이미지에 딱 맞는 퍼소나를 만들고, 이를 통해 구름의 목소리를 부여하고자 했습니다.

구름의 코어 밸류를 퍼소나 퍼스낼리티로 구체화하는 과정을 통해 완성된 구름의 퍼소나를 소개합니다! (짜잔)

개발 잘하는 편안한 선배가 필요하다면, 구름으로

3. 구름의 목소리, Tone of Voice

보이스톤 설정의 마지막 단계! 드디어 구름의 보이스톤입니다.

‘개발 잘하는 편안한 선배’라는 구름의 퍼소나가 가진 세 가지 키워드(Friendly, Supportive, Tech-savvy)를 통해 구름의 목소리를 부여했습니다!

구름 서비스 전체에 적용될 우리의 목소리가 정해진 감격의 순간이었습니다…!

원칙(Principles) 세우기

구름의 보이스톤이 정해진 다음 해야 할 일은 UX 라이팅을 위한 원칙을 세우는 것이었는데요.

결정된 보이스톤에 각각 상응하는 3가지 원칙을 정하고 각 원칙 별로 세부 사항을 정리해나갔습니다. 결정된 원칙의 일부는 아래와 같습니다.

01. 친절하게 쓰기

구름은 사용자들이 서비스 내에서 존중받는 느낌을 받도록 최선을 다합니다. 또한, 다소 어렵게 느낄 수 있는 ‘개발’에 대한 부담을 덜고 누구나 편하게 시작할 수 있도록 친절함을 유지합니다.

02. 누구나 이해하기 쉽게 쓰기

구름은 개발자가 되어가는 여정을 함께 하기 위해 이해하기 쉽게 이야기합니다. 사용자들이 개발 여정을 포기하지 않고 이어갈 수 있도록 전문가가 아닌 이들도 이해할 수 있는 직관적인 표현을 지향합니다.

03. 신뢰할 수 있게 쓰기

구름은 교육부터 채용, 실제 개발과 구축을 위한 전문 서비스를 제공하고 있습니다. 우리가 제공하는 서비스를 통해 변화를 만들어나갈 사용자들이 믿고 사용할 수 있도록 신뢰할 수 있는 목소리를 유지합니다.

상황별 구체화하기

큰 원칙이 정해진 후 상황별 가이드라인을 구체화해 저희가 세운 원칙이 혼란 없이 서비스에 잘 적용될 수 있도록 했습니다.

가이드라인 공유

이렇게 UX 라이팅 가이드라인이 완성된 후 공유를 위해 가이드라인이 정리된 피그마 링크와 그간의 내용을 정리한 회의록을 노션에 공유했습니다.

또 CDO 제이슨이 추진한 구름 디자인 시스템(GDS) 세미나를 통해 UX 라이팅 가이드라인을 설명함으로써 더 효과적으로 전사에 공유할 수 있었습니다.

서비스별 가이드 적용

UX 라이팅 가이드라인 제작과 공유까지 완료됐다면 이제 대장정이 끝났다고 생각할 수도 있지만, 완성된 가이드에 맞춰 전체 서비스 문구를 다듬는 과정이 필요했습니다.

이때 앞서 전체 문구를 점검할 때 사용한 스프린트 시트를 활용해 서비스 별로 문구를 수정했습니다. 여기까지가 현재의 진행 상황입니다. 기왕 글을 시작한 김에 이후의 계획도 살짝 나눠보자면 아래와 같습니다.

1) 수정한 문구를 크로스체크 후 전체 사이트에 반영
2) A/B 테스트를 통한 검증 단계를 거쳐 추후 가이드라인 업데이트에 반영

마치며

UX 라이팅 가이드라인을 통해 각 직군별 구르미들이 일하는 방식에도 차이가 생겼는데요. 우리가 구름 서비스를 만들어 가는데 바뀐 점은 이렇습니다!

디자이너

시안마다 다르게 쓰여있어 어떻게 작성할지 혼란스럽던 문구를 작성하는 기준이 생겼어요. 알맞은 문구 작성을 위해 다른 시안을 찾아보던 시간을 줄일 수 있어 효율적이에요!

개발자

UI 텍스트 수정을 해야 할 때 디자이너에게 요청하지 않고도 가이드 문서를 보고 직접 텍스트를 작성할 수 있어 작업 프로세스가 간단해졌어요!

마케팅 매니저

사용자를 향한 일관적인 태도(=곧 언어) 중요하다는 사실을 다시 한번 리마인드 할 수 있었던 시간이었습니다.

구름의 UX 라이팅 가이드라인을 만들어가며 저희가 내린 결론은 이 가이드라인은 절대적인 법칙보다는 ‘사용자를 향한 구름의 태도’라는 것입니다. 그래서 구르미들은 이 가이드를 구름이 더 구름다울 수 있도록 우리의 정체성과 지향점을 지켜줄, 우리가 지켜야 할 태도로 여기고 있습니다.

레퍼런스

UX 라이팅 가이드라인을 만드는 데 좋은 참고 자료를 제공해 주신 분들께 감사를 전합니다!

• RIDI Design System UI 텍스트 작성 가이드
• 강남언니 UI 텍스트 가이드라인 제작기
• Spoqa Writing Guide

구름의 가치를 같이 만들어나갈
뉴-구르미들을 찾고 있어요

The post 구름 UX Writing 가이드라인 제작기 appeared first on 구름 공식 블로그 (goorm blog).

안녕하세요. 사이안(Cyan)입니다. 파란색과 동물, 혼술을 좋아하는 2X살 주니어 디자이너죠.

1편에서와 마찬가지로 푸릇푸릇한 뉴-구르미로서 그 역할을 톡톡히 해내고 있는 중입니다. 가끔은 너무 시끄러워서 꾸중 아닌 꾸중을 듣기도 하죠.

2편에서는 그간 겪었던 재미있는 업무 썰을 풀어보려고 해요. 이번 편도 재미있게 감상하셨으면 좋겠습니다.

얼마만큼 구르면(?)
선배 구르미처럼 될 수 있나요

사실, 프로덕트 디자이너로서 개발자 구르미와 협업하는 일은 결코 쉽지 않았어요.
구름 서비스 중 구름IDE의 프로덕트 디자인을 맡게 되었는데, 온보딩을 들으면 들을수록 제가 그동안 배웠던 영역과는 너무나도 먼 미지의 세계로 들어가는 것 같았죠.

구름IDE는 클라우드 기반의 통합 개발환경이지만, 제가 사용해 본 거라곤 플레이그라운드의 Swift 코드밖에 없어서 구름IDE의 사용성을 개선할 수 있을지 걱정이 많았어요.
처음으로 들어간 회의에서는 여기가 정녕 한국이 맞는지 귀를 의심했습니다.

'오늘 오전에 Mongo DB Atlas 엑세스 권한 이슈가 있어서...'
'XX는 다시 레디스 리팩토링 브랜치로 돌리려고 하는데...'
'ide-core 핫픽스 열닫하겠습니다...'

저만 빼고 모두 완벽하게 이해하고 있다는 사실이 제일 괴로웠어요. 마치 제2 외국어로도 써본 적 없는 러시아로 교환학생을 떠났다가 의도치 않게 로컬 학생들과 점심을 먹는 느낌이었달까요?

어찌어찌 개발 용어는 몰라도 디자인은 할 수 있었어요. 진짜 문제는 디자인 용어와 방식도 무척 생소했다는 거죠. 부트스트랩, 스토리북, CSS코드들, 디자인 토큰, em, rem… 모르는 것 투성이었습니다.

아마 사수인 제이슨의 귀에서 피가 나기 시작한 것도 이때부터였던 것 같아요. 거의 두 달은 넘게 물어보고 또 물어봤습니다. 가끔은 너무 죄송스러워서 그만 물어보고 싶었지만 멈출 수 없었어요. 뒤돌아보면 모르는 게 생기던 시절이었습니다.

그래도 격려와 조언을 아끼지 않은 선배 디자이너 제이슨과 헤일리 덕에 조금씩 구름 서비스를 어떤 방식으로 개선해야 하는지 감을 잡을 수 있었어요. 지금은 회의 내용도 어느 정도 이해할 수 있고 디자인 검수도 혼자서 척척 할 수 있게 되었습니다. 최근에는 사내 세미나에서 동료 디자이너 디디와 함께 UX Writing에 대한 발표도 진행했어요. 모두 인상 깊게 들어 주셔서 굉장히 뿌듯했습니다.

짧은 시간 동안 많은 것을 배우고 성장한 만큼 조만간 1인분 하는 디자이너가 될 수 있을 거라 믿고 있습니다. 아직 선배 구르미들을 따라가려면 한참 멀었지만요.

1X1 미팅이 기다려지는 이유

일 년에 4번, 분기가 돌아올 때마다 가장 기다리는 날이 있습니다. 바로 C레벨 구르미와 1X1(일대일)미팅을 하는 날이에요.

믿지 못하시는 분들도 계시겠죠? 직장 선배와 단 둘이서 면담을 한다는 건 많은 용기가 필요한 일이죠. 심지어 그 상대가 회사의 수장이라면 더더욱이요.

솔직히 저도 웨인(CEO)에게 1X1 미팅을 신청했을 때 걱정을 안 한 건 아니었습니다. ‘뭘 여쭤봐야 하지? 일 못 한다고 꾸중 듣는 건 아닐까?’하면서 점심 시간 전까지 노트에다 빼곡히 위기 상황 대응 리스트를 만들었어요.

대망의 점심 시간. 조마조마한 제 심정을 알고 있다는 듯 웨인이 먼저 점심 약속을 잊지 않고 디엠으로 연락해주셨어요. 뿐만 아니라 제가 가장 먹고 싶었던 생선 구이 집도 골라주셨습니다.

1X1 미팅을 진행하면서 웨인과 정말 많은 이야기를 나누었어요. 회사를 운영하면서 느낀 점과 인생 선배로서 꿀팁 등을 공유해 주셨습니다. 웨인이 먼저 솔직하게 말해 주니 저 또한 사회 초년생으로서 궁금했던 점이나 불안한 점을 가감 없이 물을 수 있었어요.

업무 이외에도 평소에 서로가 가지고 있던 생각이나 가치관, 지향점에 관한 대화를 주고 받았고 정신적으로 한 발자국 더 가까워진 느낌이 들었습니다.

한시간 반이라는 시간이 쏜살같이 지나가고 익숙한 사무실로 돌아왔죠. 그때부터였을까요. 제가 1X1 미팅 매니아가 된 게?

입사 후 현재까지 무려 5번 정도 1X1을 진행했습니다. 일하면서 속이 답답할 때, 선배 구르미의 위로나 조언이 필요할 때, 혹은 단순히 친해지고 싶은 구르미가 있을 때 쑥스럽지만 슬쩍 가서 여쭈었어요. ‘저랑 밥 한 끼 하실래요?’ 마음씨 착한 선배 구르미들 모두 흔쾌히 받아들여 주셨습니다. 이 자리를 빌려 진심으로 감사의 말씀을 드립니다.

성장은 계속된다

이 글을 적고 있는 지금까지도 하루가 다르게 성장중이에요. 사회 초년생을 넘어 멋진 시니어 디자이너가 되는 그 날을 향해 열심히 달리고 있습니다. 가끔은 힘들 때도 있지만 뜨거운 해를 가려 주는 구름이 있기에 땀을 식히고 다시 출발할 수 있는 것 같아요.

어쨌든 이 글을 읽고 계시는 여러분이 계시는 걸 보면 나름 잘 적응했다고 볼 수 있지 않을까요? 구름 혹은 시끄러운 사이안이 궁금하다면 뉴-구르미가 되는 길은 활짝 열려있으니 언제든 지원해 주시길 바라요.

그럼 구름에서 봅시다 안녕!

구름의 가치를 같이 만들어나갈
뉴-구르미들을 찾고 있어요

The post 신입은 처음이라… 뉴 구르미 Cyan의 일기⛅️ – 2편 appeared first on 구름 공식 블로그 (goorm blog).