SPOT(일명 스팟)은 한국IT경영학회 KUSITMS 31기에서 4월에 시작해서 6월초까지 약 2개월동안 진행한 프로젝트다. 서비스는 현재도 배포되고 있다. SPOT 사용해보기

학회 활동을 하면서 다양한 지역의 사람들과 만나는 일이 잦아졌다. 모임을 만들 때 마다 팀원들이 각각 어느 지역에 거주하는지 조사해야했고, 팀원마다 오는 데에 걸리는 시간도 알아야 했다. 그리고 모두가 만족할 수 있는 장소로 조율해야 했다.

매번 다양한 사람들과의 만남을 위해 중간 지점을 찾아야 했던 우리 팀은 이런 페인 포인트에 집중하여 SPOT 서비스를 기획하게 되었다.

이번 글은 SPOT 프로젝트를 어떻게 만들어 나갔는지 회고하고 정리하고자 한다.

📍 SPOT 서비스 소개

🔗 Behance 링크

1. 모임을 만들고
2. 사람들에게 링크를 공유하고
3. 접속한 사람들은 출발지를 입력하고
4. 장소를 탐색하고, 확정할 수 있는

크게 4개의 플로우 로 이루어진다.

🌟 경쟁 서비스와의 차별점

🤷 그런데 그거, 이미 있는 서비스 아냐?

경쟁 서비스는 생각보다 실제 상황에서 사용하기 어려웠다.

위밋플레이스는 한 사람이 참여자의 출발지를 취합하여 입력해야 했고, 다른 사이드 프로젝트인 Kok은 인원수를 지정한 뒤 모든 참여자가 등록해야지만 중간 지점을 볼 수 있다.

SPOT은 경쟁 서비스의 불편함을 개선했다. 링크로 각자 출발지를 등록할 수 있고, 사람들이 출발지를 입력할 때 마다 중간 지점 결과를 보여준다.

중간 지점을 정하는 것에서 더 나아가, 어느 카페, 어느 장소에서 만날지 고민을 줄여주기 위해 역 주변의 장소를 추천한다.

🗺️ MISSION : 지도 위에 정보 담기

디자이너로서, 좋은 경험을 설계하기 위해 지도 라는 서비스 특성을 잘 이해해야 했다. 출발지와 중간 지점 정보가 담긴 요약을, 많은 색과 요소가 혼재하는 지도 위에 보여줘야 했다.

🤔 고민

• 중간 지점 후보를 어떻게 보여줄 것인가?
• 사람들의 리스트는 어떤 형식으로 보여줄 것인가?
• 장소 추천 버튼은 어디에 넣을 것인가? ...

지도 자체가 많은 정보, 많은 컬러를 사용하고 있어 최대한 그 위에 UI를 덜어내려고 했다. 그러나 보여줘야 하는 정보는 정말 많았다..

✅ 개선 버전

맵 위 요약 정보의와 바텀시트의 용도를 분리하여, 각각의 목적에 맞는 정보들만 남기고자 하였다.

• 맵 위 정보의 목적: 누가 어디서 오는지, 중간 지점은 어디인지
• 바텀시트 정보의 목적: 평균적으로 얼마나 걸리는지, 무엇을 타고 오는지

시각적으로 복잡한 맵 위에서 눈에 띄려면 크기가 커야한다고 생각했었다. 그러나, 좌표가 너무 가까워 정보가 겹칠 수 있다는 문제점이 있었다.

• 따라서 알아볼 수 있을 정도로 전반적 크기를 최소화했다.

🔭 SPOT의 로드맵

SPOT을 만든 땡수팟 팀은 앞으로 서비스 지역을 확대하고, 유저 경험을 개선하며 더 나아가고자 한다. 8월 24일, 정식 런칭을 목표로 더 뜨겁게 달려볼 것이다!

SPOT 서비스 PT 영상

SPOT - 모두를 위한 하나의 SPOT!

29기가 끝나고 벌써 30기가 끝나버렸다. 30기는 29기와 다르게 교육기획팀 운영진으로 활동했다. 운영진으로 큐시즘의 토대를 다지며 정말 많은 것을 배웠고, 정말 다양한 경험을 했다. 저번 글에서는 학회원 관점으로 글을 적었다면, 이번 글에서는 교육기획팀으로서 경험을 공유하고자 한다.

🫢 교육기획팀 지원

교육기획팀에 지원하게 된 이유는, 큐시즘 29기에서 크게 만족하지 못했기 때문이다. 학회원으로 활동하며 운영적으로 아쉬운 부분이 꽤 많았다.

주변 사람들도 아쉬워했지만, 개선의지가 강하지 않았다. 만족하지 못한 상태로 큐시즘을 놓아버리려고 했다.

나도 놓을 수 있었다. 큐시즘이 정말 아쉬웠다. 하지만 그렇게 아쉬웠던 29기 활동을 값지게 만들려면, 이후의 큐시즘을 발전시켜야 한다는 생각이 문득 들었다. 그렇게 큐시즘에 대한 개인적인 불만족은 내가 속한 학회가 더 잘 되길 바라는 마음으로 이어졌다.

많이 힘들 것이라는 건 알았다. 하지만 내가 아니면, 지금이 아니면 안될 것 같았다. 그래서 교육기획팀에 지원하게 되었다.

🧐 문제 정의

내가 왜 만족하지 못했을까, 깊게 생각하고 문제를 정의했다. 자잘한 부분도 많았지만, 가장 크게 느낀 점은 다음과 같다.

💻 프로젝트 진행에 대한 체계 부족

프로젝트 진행에 있어 자유도가 높았는데, 이는 오히려 막막함을 야기했다. 타 파트와의 협업을 기대하고 들어온 학회원들이 많기 때문에 적절하지 않았던 것 같다. 또한 프로젝트의 프로세스를 아는 팀과 모르는 팀은 결과물에서도 격차가 많이 났다고 생각한다. 학회원간 실력 격차를 최소화하는 것 또한 운영진의 역할이기에, 프로젝트의 체계를 만들고자 하였다.

💻 개발자에게 친절하지 않은 학회

밋업 팀의 개발 팀원들은 프로젝트에서 상당히 힘들어 했다. 29기의 프로젝트들은 대체적으로 기획의 피쳐가 컸고, 개발이 늦게 시작되었다는 공통점이 있었다.

디자이너들은 많은 화면을 빠르게 만들어 넘겨야 했다. 개발자들은 개발 자체로도 힘들어하고, 기획자들은 기획이 구현되지 않아 갈등이 있었다.

이러한 현상은 팀 분위기에도 좋지 않은 영향을 끼쳤다.

🤩 솔루션 도출

기획의 피쳐를 조절하고, 개발을 빠르게 시작할 수 있는 환경을 만들기 위한 방안으로 밋업 프로젝트에 스프린트 제도를 도입했다.

⭐️ 스프린트 제도란

밋업 프로젝트의 기간을 2주 단위의 스프린트로 쪼개 진행하는 방법이다. 스프린트가 끝날 때 마다 진행사항을 기록한 보고서를 제출해야 한다.

⭐️ 개발에 빨리 돌입시키기 위한 방안

1. 보고서에 배포 URL이나 깃허브 링크를 제출받아 개발이 늦게 시작하는 일을 방지하고자 했다.
2. 각 팀의 스프린트 보고서를 모든 학회원에게 공개하여, 서로에게 동기부여가 될 수 있도록 했다.

⭐️ 만족감 극대화 시키기

스프린트 제도가 도입되고 개발이 빨라지면서, 밋업 프로젝트 중반에 자문위원에게 서면 피드백과 코드리뷰를 받을 수 있도록 마련하였다.

⭐️ 성과

• 학회원들은 프로젝트가 물 흐르듯이 진행되어 좋았다며 높은 만족도를 보였다.
• 개발이 빨리 시작되어 후반 세션에서 개발된 프로토타입을 가지고 UT를 해볼 수 있었다.

하지만 기획의 피쳐를 줄였다보니 전반적으로 프로덕트의 기획이 많이 아쉬웠다.

🔄 운영진 활동에 대한 전반적 회고

👍🏻 Liked - 좋았던 점

• 운영진이라는 이름 덕분에 학회원들에게 부담없이 다가갈 수 있었다. 학회원으로 처음 들어와 쭈뼛댔던 29기를 생각하면, 운영진 덕분에 더 활발하게 네트워킹할 수 있었던 것 같다.

👎🏻 Lacked - 아쉬웠던 점, 부족한 점

커리큘럼과 프로젝트의 체계를 다 만들고 나니, 운영진의 업무 체계가 많이 아쉬웠다.

• 타 부서의 업무가 잘 공개되지 않아 부서별 이기주의, 즉 사일로 현상이 발생했다.
• 비효율적인 업무 방식으로 운영진들의 리소스가 많이 낭비되었다.
• 인수인계가 운영진이 제대로 이해하고 받아들일 만큼 이루어지지 않았다.
• 신규 운영진들이 적응도 채 하기 전에 업무에 돌입되어 힘들어했다.

그 속에서 정말 많은 일을 처리해준 연진언니와 OB로 함께 고생한 소민이에게 너무 고맙다. 오자마자 힘들게 일도 하고 프로젝트도 열심히 완수하려 노력한 신규 교육기획팀원들에게도 항상 미안하다.

✍🏻 Learned - 배운 점

주변의 문제를 인식하고 솔루션을 도출하는 것, 조직을 이끄는 방법, 좋은 업무 환경을 조성하기 위해 고민하며 정말 많은 것을 배웠다.

• 리소스를 많이 사용한다고 학회원들의 경험이 드라마틱하게 개선되지 않는다.
• 부서 이기주의(사일로 현상)을 해결하기 위해 부서 간 적극적인 관심과 협력이 필요하다.

🙏🏻 Longed for - 앞으로 바라는 것

커리큘럼과 프로젝트의 체계를 어느정도 잡고 나니, 운영 체계를 잡아야겠다는 생각이 들었다. 그래서 TF를 하거나, 인수인계를 잘 해줘야겠다고 생각하고 31기는 할 생각이 없었는데..

어쩌다보니 지금 31기 교육기획팀장이 되었다. 위에서 언급한 부족한 점을 이번에 개선하고자 많은 도전을 하고 있다. 이번 31기는 더 나은 학회원들의 경험과 더불어 더 나은 운영진들의 경험을 위해 노력할 것이다.

💭 review

하기 전에 주저해도, 항상 하고 나면 후회가 되지 않는다. 도전은 마치 실패할 것 같이 느껴진다. 하지만 그 두려움이, 도전을 성공으로 바꾸려는 원동력이 되는 것 같다. 그러니까 무슨 도전이든 결과는 정해져 있는 것이 아니고 내가 만들어 나가는 것이다.

성공의 반댓말은 실패가 아니라 나태함이라는 것을 잊지 말자.

컨퍼런스 행사에 참여하는 것은 거의 처음이었다. 찾아보니 디자인과 관련된 CREATIVE세션은 DAY2에만 진행 예정이었다. 정말 너무 가고 싶었는데, 아이돌 콘서트 티켓팅 실력을 발휘하여 DAY2 입장권 신청에 성공했다!

당일에 도착하니 생각보다 사람이 엄청 많았다.

체험형 부스가 엄청 많았지만, 세션 4개를 다 듣고 오니 대부분의 부스가 끝나 있었다. 치지직 가방 정말 가지고 싶었는데 그저 가지고 있는 사람들을 하염없이 바라만 봐야 했다 🥺

세션은 Track 1과 Track 2 중에 고민했다. Track 1은 프로덕트 디자인과 기획적인 주제였고, Track 2는 브랜딩, CX등 좀 더 비주얼적인 주제였다. 내적 갈등이 심했지만 지금 하고 있는 활동, 그동안 공부해온 것들은 프로덕트 디자인이기에 Track 1을 듣기로 결정했다. 세션들은 굉장히 유익했기에 세션 내용을 기록으로 남기고자 한다.

세션 1 : 지식이 모이는 공간, Next 지식iN

이번 세션에서는 지식인이 그동안 해왔던 고민과, 앞으로의 방향성에 대한 내용으로 진행되었다. 3개의 소주제로 나뉘어 진행되었는데, 내용이 다소 분산되어 있어 종합적으로 적어보도록 하겠다.

🧐 지식iN이란?

지식iN은 무려 22년 전, 2002년에 오픈된 질문 답변 서비스이다. 사용자가 궁금한 내용을 질문하고, 사용자에게 답변을 받는 구조이다.

오늘날에는 위키, 커뮤니티, 트위터, 인스타그램, 유튜브 등 정보 매체의 활성화로 궁금한 정보를 쉽게 찾을 수 있게 되었다.

그럼에도 왜 지식iN이었을까?

우선 지식iN에 올라오는 질문 유형을 분류해보자.

• 정해진 답, 정답을 묻는 질문
• 일상에 대한 고민 또는 이슈에 대한 의견, 조언을 묻는 질문

지식iN은 정답과 의견, 그 경계에 있는 호기심을 채워주기 때문이다. 특히나 고민이나 의견을 묻는 사용자가 많은데, 그 이유는 지식iN의 특성에서 찾을 수 있다.

지식iN은 익명 공간으로서 '느슨한 관계' 를 형성하여, 얼굴을 알고 있는 지인에게 물어보기 어려운 것을 익명 공간에서 보다 편한 마음으로 물어볼 수 있는 것이다.

🪨 AS IS - 기존 지식iN의 문제점

이전까지의 지식iN은 어땠을까? 기본적으로 사용자는 질문이 있을 때 질문하고, 답변자는 답변한다.

그 과정을 자세히 들여다보면, 다음과 같은 문제점들이 있었다.

• 질문자는 답변을 받기 까지 기다려야 했다.
• '질문과 그에 대한 답변'으로만 콘텐츠가 이루어져 사용자는 답변 받기라는 목적을 달성하면 이탈한다.

요약하자면 즉, 💭 사용자들은 궁금할 때에만 방문하고 답을 찾으면 이탈한다.

그렇기에 지식iN은 💡 사용자가 재방문할 동기와 자생력이 부족하다.

💎 TO BE - 지식iN이 앞으로 나아갈 방향성

지식iN은 일회성의 사용 패턴을 지속성으로 바꾸기 위한 솔루션으로 '트렌디함'을 제시했다. 어떻게 하면 지식iN 서비스를 더 트렌디하게 만들 수 있을까?

⭐️ 더 가볍고 더 재밌는 질문답변!

지식iN의 주 사용자층은 10대, 20대, 30대이다. 숏폼 컨텐츠 소비 증가에 따라, 사용자의 콘텐츠 소비 시간은 점점 짧아졌다. 따라서 지식iN은 텍스트 기반의 복잡한 웹 문서 형태에서 빠르게 탐색하고 재밌는 컨텐츠로의 개선이 필요했다. 또한 지식iN은 네이버 검색을 통해 유입이 가장 많이 되는데, 이때 스크롤 당 한 두개의 답변을 보여주는 것이 이탈률을 높였다. 따라서, 웹 문서 구조에서 빠른 탐색이 가능한 피드 UX로 전체적인 개선이 이루어질 예정이라고 한다. 지식iN이 제시한 구체적인 솔루션은 다음과 같다.

1. 정적인 텍스트 질문을 타이포그래피로 시각화하기

2. 더 빠르게 탐색할 수 있는 인터랙션

   • 상하 스크롤로 질문을 탐색하고, 좌우 스크롤로 답변 미리보기를 제공한다.

3. 하나의 정보를 택하는 채택 의 무게를 다중 채택 기능 및 채택 버튼의 시각적 위계 조정을 통해 낮추기

4. 다양한 답변을 탐색하고 작성할 수 있도록, 현재의 한 화면에 한 답변이 들어오는 UI를 간소화시켜 답변 목록을 제공

5. 참여형 질문 유형을 늘리고, 참여에 대한 보상을 강화하여 서비스를 재밌게 즐길 수 있도록 함

📈 가장 빠르고 가벼운 생산

갑자기 등장하고 짧게 소비되는 이슈 키워드에 대해 사용자들이 더 많은 콘텐츠를 생산할 수 있도록 도와야 한다. 예를 들면 최근 방영된 프로그램이나 떠오르는 밈 등 반짝 나타났다 사라지는 트렌드를 반영하는 것이다. 지식iN이 제시한 솔루션은 다음과 같다.

1. 데이터 파싱으로 키워드를 선별한 뒤, AI가 스스로 질문을 생성하여 사용자들이 답변에 참여하도록 함
2. 퀵 에디터를 통해 더 빨리 생산할 수 있도록 도움
3. 관심 키워드 설정 기능으로 개인화된 질문답변 추천

💨 오래된 Q&A 문건에 새 숨결 불어넣기

'MT갈 때 준비물'라던지, '여자친구 100일 선물' 등 시간이 지나도 지속적으로 올라오는 질문들을 어떻게 활용할 수 있을까?

1. 오래된 질문에 최신 답변을 달 수 있도록하여, 지식의 변화와 트렌드의 흐름을 만든다.
2. 하나의 질문에 질답 문건이 다량 생산되면 #메가_키워드 로써 활용할 수 있게 된다.

👥 느슨한 관계를 이용한 주제 중심의 커뮤니티 형성

위에서 언급했던 것 처럼, 지식iN은 익명성이 보장되는 공간으로 사람들이 고민이나 의견을 좀 더 쉽게 표현할 수 있다. 하지만, 사람은 다른 분야에서 활동을 할 때 본인의 질문답변 이력이 허들이 되는 경우도 분명히 존재했다.

1. 식물 전문가 식집사도 언제나 예능 프로그램에 대해 질문할 수 있도록, 또 다른 자아를 뜻하는 '페르소나' 기능을 도입하고자 한다.
2. 관심 설정을 통해 관심사관련 활동에 딥 다이브할 수 있도록 돕는다.

💡 새롭게 탄생한 지식iN의 브랜딩, 뉴잇

뉴잇은 Knew it : 알고 있는 것, New it : 새로운 것을 뜻한다.

일회성으로 만드는 정해진 답, 정량적 정보가 아닌 편안함과 친근함, 정성적인 정보를 전달할 수 있는 플랫폼으로 리브랜딩 전략을 밝혔다.

🛠️ 유지보수의 과정

컴포넌트들을 그때그때 이슈에 대응하여 개선하다보니 화면의 일관성이 떨어진다. 서비스 운영 기간이 오래되면 기능별 시스템 구현 방식이 다르기도 하고, 우선순위에 따라 소외되기 때문에, 일괄 수정이 힘들다고 한다. 따라서 신규 개발 영역과 서비스 전반적으로 통합 개선이 가능하도록, 디자인시스템을 잘 구축해 나가야 한다. 지식iN은 디자인 시스템 구축을 통해 불필요한 고민과 의사소통 및 결정 과정을 줄이고, 새로운 시도를 과감하게 할 수 있는 시간을 확보하고자 한다.

💡 느낀 점

지식iN 세션은 한 페이지에 보여지는 답변의 y축 길이 축소라던가, 사용자의 행동 패턴을 분석하고 인터랙션 단위로 개선하려는 전략이 매우 인상깊었다. 지식iN 팀의 PT는 문제 해결 과정을 세세하게 풀어주었는데, 이 덕분에 '저렇게 개선하고자 했던 이유는 뭐지?' 라는 궁금증이 자연스럽게 해소가 되었다. 프로덕트 디자인에 관련하여 문제해결 과정이 잘 드러나 배운 점이 많았지만, 뿐만 아니라 프레젠테이션 구성을 어떻게 해야 청자들을 설득할 수 있을지 많이 고민해보게 되어 유익했다!

세션 내용도 배운 점도 많아 다른 세션들은 차근차근 업로드 해보도록 하겠다. 크크😁

• 컴포넌트 시스템의 제작 기준으로, 각 컴포넌트를 정의하고 텍스트와 함께 정리한 문서
• 모든 내용은 예시 이미지와 함께 기재한다.

1️⃣ Size

xs sm md lg xl 총 5가지 기준 설정

• 각 컴포넌트를 세트로 사용했을 때 Height 값의 통일성 유지 목적 ⭐️ 컴포넌트는 Height를 기준으로 제작할 것을 권장

2️⃣ Style

Fill : 컴포넌트의 Fill 및 Border 값

• border width, style을 함께 기재한다.

Radius : 컴포넌트 모서리 반경 값

Box Shadow : Shadow 값

• x/y 좌표, blur 값, rgba(또는 HEX코드와 Opacity값)을 함께 기재한다.
• layer 단계별로 구분한다.

3️⃣ Icon Component Size

Size : 아이콘 크기

• width/height px값을 기재한다.

Touch Size : 터치 영역을 포함한 크기

• 마찬가지로 width/height px값을 기재한다.

4️⃣ Component Container

✅ 기재사항

• 아이콘의 정렬 위치로 구분
• 요소 간 Padding 값

5️⃣ UI Component

✅ 기재사항

• 컴포넌트 종류(button, input 등)로 구분
• 컴포넌트 size
• Height, FontSize, Padding

6️⃣ UI Component Interaction

UseCase별 액션에 대한 디자인에 대해 서술한다.

✅ 기재사항

• UseCase로 구분
• 디자인 요소 값 Font Color Border Color Background Color Box Shadow
• 디자인 의도 및 기대효과

7️⃣ Help Text

Text Field 하단에 노출되는 문구에 대해 서술한다.

✅ 기재사항

• FontSize
• Margin 위치 및 값

컴포넌트 코어 시스템의 필요성

1. UI의 일관성 유지

• 같은 규칙으로 컴포넌트 코어 시스템을 구축하면, 화면 크기별 & UI 전반의 일관성을 유지할 수 있다.

2. 다른 부서와의 협업 용이

• 특히 UseCase별 인터랙션 정리는 개발자에게 용이하다.

3. 신규 디자이너에게 가이드 제공

• 디자인 의도와 규칙이 기재되어 있어 신규 디자이너가 적응하기 쉽다.
• 클라이언트에서 추후 디벨롭할 것을 고려하여 가이드를 넘겨주어야 한다.

💬 참고문서 https://www.remain.co.kr/page/designsystem/component-core.php

📞 우리 지금 만나 당장 만나!

큐시즘 29기가 끝나자마자 같은 팀이었던 프론트엔드 개발자에게 프로젝트 회의 중에 나왔던 아이디어를 가지고 개발해보자고 제안했다. 이 프로젝트를 하고 싶었던 이유는 링크로 공유되는 서비스 특성상 WEB이라는 플랫폼이 탁월했기 때문이다.

기획이나 고민하는 데에 시간을 너무 많이 쓰지 말고 빠르게 개발하는 것을 목표로, 또한 애자일 방법론을 활용한 프로세스로 진행했다. 화면 단위 개발을 마친 후 백엔드 개발자를 영입했다. 얼마 전 디자이너 한 명을 더 영입하여 우만당만 팀은 큐시즘 29기 출신 4인 팀이 되었다.

👇🏻 아래 링크에서 원타임을 사용해볼 수 있다! https://www.onetime-with-members.com/

👍🏻 Liked - 좋았던 점

ALL TIME 동기화

• 우만당만팀 개발자들은 소통이 빠르고 일 처리도 빠르다! 프로젝트 이슈가 생기면, 별다른 회의 스케줄 없이 카톡으로 이슈를 공유하고 바로바로 해결하는 편이다.
• 카톡으로 공유되는 이슈들의 볼륨이 크지 않고, UX와 최적화를 전제로 논의하다보니 의견 충돌로 매몰되는 일은 없었다.

강박과 부담없는 프로젝트

• 팀원들과 어떤 이야기든 매우 편하게 이야기 할 수 있는 분위기라서 소통에 있어 스트레스를 받지 않았다.
• UX에 대한 고민이 많아졌을 때, 특정 이슈에 매몰되지 않았다. 개발자들도 수정과 개선에 거리낌이 없었기에 완벽한 UX로 넘겨야 한다는 강박없이 진행할 수 있었던 것 같다.

모두가 한 마음 한 뜻으로

• 타인에 의해서 만들어진 팀은 모두가 공동의 목표에 공감하기란 쉽지 않다. 일정 조율 서비스에 있어 직접 페인포인트를 느꼈던 사람들과 함께하니 프로덕트에 몰입하기 쉽고, 더 재미있었던 것 같다.
• 모두가 있는 톡방에서 개발, 디자인에 상관없이 모든 이슈에 대해 논의를 하니 디자이너인 나 또한 개발 현황이 어떻고, 함께 고민해볼 수 있었다.

열심히 논의하는 우만당만팀 사진으로 마무리

👎🏻 Lacked - 아쉬웠던 점, 부족한 점

Too Comfortable 💤

• 시간이 지날수록 일이 많아지면서 원타임 작업이 후순위로 밀리게 되었다. 나는 하고자 한다면, 어떤 상황에서도 무엇이든 해낼 수 있다고 생각한다. 결국 원타임 우선순위가 밀리게 된 것은 내가 초심을 잃었기 때문이다. 팀원들에게도 정기회의를 통해 프로젝트에 긴장감을 주자고 제안했다. 다음 스프린트 부터는 처음 프로젝트를 시작했던 마음가짐으로 임할 것이다.

신경쓰지 못한 브랜딩

• 빠르게 개발하는 것을 목표로 하다 보니 그래픽에 많이 신경쓰지 못했다. 이벤트 페이지의 배경 그라디언트도 마음에 들지 않고, 공유하기 버튼도 마음에 들지 않는다. 그래픽에 좀 더 신경써서 완성도를 좀 더 높이고 싶다.

✍🏻 Learned - 배운 점

애자일 방법론

• 귀에 딱지가 붙도록 들었지만 제대로 애자일 방법론을 활용해본 적은 없었다. 이점이 무엇인지도 크게 와닿지 않았었다. 이번 원타임에서 눈 딱 감고 해봤는데, 빠르게 진행되는데도 부담은 적고 효율은 올라가서 너무나도 좋았다.

오래 고민한다고 해서 정답이 나오는 것은 아니다

• UX를 그렇게 고민고민해서 디자인해도, 사용자들은 생각보다 다른 부분에서 불편함을 느끼기도 하고 디자이너의 의도를 못알아채기도 한다. 그렇다고 아예 고민하지 말라는 것은 아니지만, 지나치게 길어진다 싶을 땐 목적이 무엇이었는지 다시 생각해본 뒤 심플하고 단순하게 가는 것이 좋은 것 같다.

혁신적인 아이템보다 유용성에 집중하자

• 기획이 아무리 장황하고 그럴듯 해 보여도, 사용자들은 막상 사용하지 않을 수 있다.
• 문제를 해결할 수 있는 아이템이어도, 서비스의 사용 동기를 이끌지 못할 수 있다.
• 해당 문제를 해결하기에 IT 프로덕트라는 수단이 적절하지 않을 수 있다.
• 서비스 기획에 있어 도메인과 플랫폼의 성격을 잘 고려해야 한다.

존재하지 않는 서비스만이 차별성을 갖는 것은 아니다

• 원타임은 사실 경쟁 서비스가 굉장히 많았다. 그럼에도 프로젝트를 하게 된 이유는 경쟁 서비스들마다 각각의 장점이 존재했고 묘하게 아쉬웠다. 모든 장점을 모아서 하나의 프로덕트로 만들고, 묘하게 느껴진 그 아쉬운 점들을 모두 개선하니 실 사용자에게도 반응이 좋았다.
• 존재하지 않는 서비스를 기획하기 위해 기능을 불필요하게 추가하면서 방향성을 잃어버린 서비스들을 많이 봐왔다. 시중에 없는 개념을 만들어 내기란 대학생 수준에서는 힘들다고 생각한다. (산업 전반에 대한 깊은 이해가 있어야 하기 때문) 시중에 있는 것을 약간만 비트는 것만으로도 차별성이 되며 충분히 시장에서 경쟁력을 가질 수 있다고 생각한다.

🙏🏻 Longed for - 앞으로 바라는 것

🔥 서비스 운영 경험을 잘 살려보자

• 프로덕트를 기획하고 만들고 디자인하고 개발하는 것은 누구나 시간만 있다면 경험할 수 있다. 하지만 서비스를 운영하고 개선하고 유지보수하는 경험은, 유효 사용자가 있어야만 가능하다. 그렇기에 원타임 서비스의 퍼블리싱에 집중하고 싶다.
• 원타임은 점진적으로 개선되고 업데이트되고 있다. 이를 기록하고, 사용자에게도 공지할 수 있도록 릴리즈 노트를 작성해볼 것이다.

💭 review

기회는 찾는 사람에게 온다는 말이 있다. 성장하고자 하는 열정은 원타임이라는 새로운 배움의 장을 찾게 해주었다. 이러한 기회는 앞으로 없을지도 모른다. 그렇기에 더욱 원타임에 몰입하고, 제대로 해보고 싶다. 앞으로 업데이트 될 기능들과 사용자의 반응, 그리고 개선 후의 반응이 매우 기대된다.

나를 아는 것은 중요하다. 특히, 나의 '디자인 스타일'을 정립해 나가는 것은 디자이너를 꿈꾸는 사람들에게 주어진 필수 과제라고 할 수 있다. 내가 좋아하는 디자인은 무엇이고, 어떤 부분이 나의 시각을 자극하는지 정리해보며 나의 디자인 추구미를 알아보려고 한다!

💘 그라디언트와 그레인

❓왜 심미적으로 느껴질까?

• 그라디언트를 활용하여, 컬러의 변화가 점진적으로 이루어진다.
• 단색만 사용할 경우 플랫한 감성을 전달하는데, 그라디언트를 통해 입체감 한 스푼을 더했다.
• 그레인 텍스쳐가 점진적인 색 변화를 매력적으로 보이게 도와준다.
• 플랫한 디지털 그래픽을 그레인 텍스쳐를 통해 현실감과 입체감 한 스푼을 더했다.

💘 블러와 글래스 모피즘

❓왜 심미적으로 느껴질까?

• 블러를 통해 앞, 뒤에 있는 오브젝트를 분리하여 입체감을 더했다.
• 그림자 등의 블러 효과를 통해 플랫한 그래픽에 자체에 입체감을 더했다.

💘 플랫한 Vector 일러스트레이션

❓왜 심미적으로 느껴질까?

• 기하학적인 도형과 배치가 현실에서 손으로는 만들 수 없는 쉐입이기 때문이다.
• 깔끔하고 정돈되어, 주제부를 확실하게 강조할 수 있다.
• 직관적이어서 정보 전달 미디어에 장점이 있다.

✅ 향후 디자인 전략

레퍼런스를 보고 분석하다 보니, 기하학적인 플랫 그래픽에 입체감이 더해졌을 때 매력적으로 느껴지는 것 같다. 그 이유는, 기하학적인 플랫 그래픽은 디지털로만 구현할 수 있고, 입체감은 '현실 세계'의 개념이기 때문에 그 둘이 만났을 때 일어나는 모순이 새롭게 느껴지기 때문이다.

앞으로, 나의 강점인 기하학적 플랫 그래픽에 그레인 효과와 블러를 적극 사용하여 밀도 높은 그래픽 작업을 해보고 싶다.

💭 Overview

반려동물 관련 사업을 하고 있는 FitPet사와 연계하여, 반려동물의 보험료를 비교해주는 서비스 '스마트커버인슈어런스'의 UXUI 개선과 견적서 자동화 개발을 주제로 프로젝트를 진행했다.

✅ R&R

• 디자인 리드, UX설계, UI디자인
• 디자이너는 총 2명이 배정되었고, 다른 디자이너는 그래픽과 브랜딩을 맡았다.
• 이번에도 PM을 맡았다.

👍🏻 Liked - 좋았던 점

1. 분위기 메이커

• 이번에는 분위기를 잘 이끌어보자는 마음에 PM을 하게 되었다. 그래서 처음부터 엄청 적극적으로 이야기 나누고 진행하고, 밈 짤을 만들고 사용하면서 분위기를 좋게 만드려고 노력했다. 또 힘들어하는 개발자들 독려하기도 했다. 사람이 잠도 못자고 힘들면 외부요인을 탓하기 쉽상인데, 독려하는 말을 많이 해준 덕분에 스트레스를 덜어준 것 같았다. (하지만 정말로 해소되었는지는 모른다..) 적어도 분위기는 좋게 이어갔던 것 같다.

2. 빠른 소통

• 이전에 연락을 잘 안본다는 주변의 평이 있었는데, 이번에는 정말 회사에서 근무하면서도 연락을 보려고 했고 새벽까지 할 일이 많지도 않은데 프론트와의 소통을 위해 깨어있었다. 안그래도 부족했던 일정을 그나마 차질없게 진행할 수 있지 않았나 싶다.

👎🏻 Lacked - 아쉬웠던 점, 부족한 점

과연 좋은 PM이었는가? 하면 절대 그렇다고 할 수 없을 것 같다.

1. 미숙했던 프로젝트 스케줄링

PM이었지만, 디자인 업무를 혼자 담당하다보니 뒤로 갈수록 PM 역할을 제대로 하지 못한 것 같아 아쉬웠다. 29기 기업프로젝트 회고

고 했는데 이번에도 PM맡아놓고 스케줄링을 제대로 못해서 프론트엔드가 힘들어 했다..

2. 꼼꼼함과 센스의 부족

• 디자인을 넘겨드리는 과정에서 꼼꼼함과 센스가 부족했던 것 같다. 특히 늦게 넘겨드리기도 했고, 피그마 정리도 깔끔하지 못했다.
• 에러케이스나 기타 모달이 등장하는 부분과 모달의 모바일뷰까지 꼼꼼하게 드리지 못해서 프론트분이 계속 요청을 해주셔야 했다.

✍🏻 Learned - 배운 점

이번에 프론트엔드 실력자분과의 소통 과정에서 굉장히 많은 것을 배웠다.

✅ 폰트 시스템은 16px 기준 medium으로 설정하기

• 프론트분이 폰트 시스템 디자인토큰명을 친절하게 알려주셨다. 개발자와 협업을 한 두번 해본 것도 아닌데 생각보다 많은 피드백이 있었다. 디자인 시스템은 많이 찾아봤지만 정보가 잘 알려져있지도 않고, 학문이 아닌 실무 중심이라 내용도 기업마다 상이하다. 최대한 그 정보들을 융합해서 나름대로 폰트 시스템을 구축했으나, 구식의 방식이라는 것을 알게 되었다. 이쪽 분야는 변화가 빨라서 빠르게 따라가는 것이 확실하게 중요하다는 것도 느끼게 되었다. 또 정답은 어디에도 없으며, 토큰명은 특히 개발자에게 맞춰야한다는 사실도 알게 되었다.

✅ 최소 바디 컨테이너 사이즈는 1080px(padding 별개)

• 양옆 마진 값을 설정해서 작없을 했었는데, 최소 바디 컨테이너 사이즈를 기준으로 작업해야한다는 것을 알게 되었다. 처음부터 반응형 뷰가 아닌 이상 마진을 설정하기보다 최소 디바이스 화면을 기준으로 바디 컨테이너 사이즈를 지정하는 것이 더 많은 화면에 대응할 수 있다.
• 지금까지 1920px으로 작업을 했었는데, 어차피 최소 바디 컨테이너 사이즈가 정해져 있으므로 노트북에서 가장 정확하게 확인할 수 있는 1440으로 작업해야겠다고 생각했다.

✅ 반응형 규칙을 세우고 브레이크 포인트를 확실하게 하기

• 태블릿 뷰를 만들지 않기 위해 PC뷰 header를 사용하려다보니 최소 컨테이너 크기보다 줄어들었을 때 문제가 발생했다. 헤더가 고정되어 좌우가 핏하게 줄어들지 않는 문제였다.(1080 이상에서는 마진값만 줄어듦)
• 반응형 규칙을 세우지 않고 디자인을 하다 보니 화면별 변수에 각각 대응해야해서 수정 작업과 추가 소통이 엄청나게 많았다.

✅ 이미지는 프레임을 씌워 일정한 크기로 맞추기

• 다양한 바리에이션으로 이미지 소스가 대체되거나, 반응형에 대응하다보니 소수점이 나오는 이미지들은 프레임을 씌워 소수점을 없애고, 일정한 크기로 작업해두어야 개발 시 오류가 적어진다.

✅ 디바이스 해상도에 따라 보여지는 크기도 달라진다.

• 한 프론트엔드 개발자의 화면에서는 비율이 굉장히 크게 나와서 혹시 디자인의 문제인가 싶었다. 하지만 다른 프론트엔드 개발자에게 물어보니, 큰 화면에서는 잘 보인다고 줄이면 오히려 안보일 것 같다고 말씀해주셨다. 결론은 지금 하던대로 Keep going 하면 된다.

🙏🏻 Longed for - 앞으로 바라는 것

🔥 디자이너 실력차 극복 및 팀원 리드에 대한 지속적인 고민 필요

• UXUI를 혼자 맡아서 타 부서와 소통이 잦고 작업량도 있어서 조금 정신없고 힘들었던 것 같다. 나름대로 나머지 디자이너를 UXUI 작업을 시키면서 피드백하고 상호성장하는 그림을 원했는데.. 일단 당장 시간이 없기도 하고 다른 디자이너분도 아예 한 가지 업무에 집중하기를 바라는 것 같았다. 디자인 실력차 극복은 정말 .. 많은 시간과 노력이 필요한 것 같다.

🔥 개발 업무 스케줄링을 위한 진행상황 숙지 필요

• 기간이 짧다보니 개발자들은 개발하느라 진행상황을 잘 공유해주지 못했다. 하지만 스케줄링에 문제가 있었던 것도, 진행상황을 잘 공유받지 못해서인 것 같다. 계속 물어보고 확인해서 조율을 했어야한다고 생각한다.

💭 review

길다면 길고 짧다면 짧은 시간이었지만 우리 팀원들이 다 너무 좋은 사람들이고, 한 명도 빠짐없이 다음에 함께하고 싶고 그렇다. 특히 백엔드 프론트엔드🫣

큐시즘 2회차로서 느끼는 점은 좋은 과정을 위해 노력하다보면 자연스럽게 결과물이 좋게 나오고, 설령 미흡한 결과가 나왔더라도 그것은 속도의 차이일 뿐 결코 나쁜 결과가 아니라는 것이다.

큐시즘은 하면 할수록 더 애정이 깊어지는 것 같다. 힘들어하는 학회원을 보면 괜히 미안하고 죄책감이 들기도 한다. 이 부분은 소프트 스킬적으로 아는 사람이 잘 이끌고 독려하는 것이 최선책이 아닐까 싶다.

🏘 부동산 담보 대출

: 부동산을 담보로 대출을 실행하는 것.

• 일반적으로 완공된 건물, 토지
• 부동산은 가치변동이 상대적으로 적음
• 권리사항이 등기부등본에 기재되어 담보로서 안정적 ➡️ 금융기관에서 가장 선호하는 담보

📄 담보 인정 비율 LTV(Loan To Value ratio)

: 담보 가치 대비 대출 비율, 부동산을 담보로 했을 때 대출 가능한 금액의 비율.

• 금융기관이 대출 규모를 결정할 때 고려하는 수단
• 담보의 기준 식가 아닌 시가의 일정 비율을 기준으로 결정됨
• LTV가 낮다 = (대출 금액 < 담보의 가치) ➡️ 부실이 발생해도 경매를 통해 원리금을 안전하게 회수할 수 있음

📍 동일한 담보로 타 금융권에 대출을 신청할 경우

• 채무자가 돈을 빌린 순서대로 우선순위가 매겨짐 원리금 확보 시 선순위 권리를 가진 채권자가 먼저 회수 이 과정에서 남은 원리금이 없다면 후순위 채권자들은 투자금을 회수하지 못할 수 있음 ➡️ P2P회사를 통한 부동산 후순위 담보 상품 투자는 원금 손실이 발생할 수 있음

✅ 투자 전 확인할 사항

부동산 담보 종류

• 대단지 아파트는 다른 부동산에 비해 수요가 많고 거래가 활발하여 환금성이 좋음
• 인터넷으로 쉽게 시세를 확인할 수 있고 시세가 다른 부동산에 비해 정확 ➡️ 담보의 가치를 가늠하거나 경매에 넘어갔을 때 가격을 예측하기 수월
• 같은 아파트라도 층수에 따라 가격이 다르므로 잘 확인할 것

LTV

• LTV가 충분히 낮은가?
• 담보물의 가치가 하락해도 원금 손실을 방지할 여유있는가? ➡️ 경제 위기에 따라 가치가 하락할 수 있으므로 LTV에 여유가 충분한지 확인할 필요
• LTV가 90% 이상인 상품은 추천하지 않음
• 담보물의 가치가 올라갈 가능성이 높다면, LTV가 높더라도 투자 고려

저당권 순위

• 등기부를 확인하여 권리 설정 여부 확인
  • 어느 금융권을 거쳐 왔고, 권리 순위가 몇 위인가?
  • 권리 관계가 복잡하게 얽혀있다면 다시 생각해볼 필요

부동산 담보 입지

• 담보로 잡힌 부동산의 주변 환경이 어떤지 등기부 주소와 지도를 바탕으로 확인
  • 담보 주변 환경이 충분히 좋다면 담보의 가치가 떨어질 가능성이 낮음

💬 담보

• 채무자가 돈을 빌리기 위해 채권자에게 맡기는 대상물 ➡️ 채무자가 원리금을 상환하지 못하면, 채권자는 담보를 현금화하여 원리금을 일부 회수

💬 경매

• 채무자가 대출금을 상환하지 못한 경우 법원을 통해 담보를 처분하는 절차 ➡️ 여러명의 입찰자 중 가장 높은 가격을 제시한 사람에게 담보를 매각하여 원리금을 일부 회수

💬 저당권

• 부동산 담보 대출 시 해당 담보물에 대해 채권자에게 발생하는 권리
  • 부실이 발생할 경우, 별도로 소송하지 않고도 저당권에 의해 법원에 경매 신청 가능
  • 담보물의 등기부에 순서대로 기록되며, 다수의 저당권이 설정된 경우 순위는 등기 설정을 먼저 한 순서대로 결정
  • 매각대금에서 대출금을 다른 채권보다 우선해서 변제받을 수 있음

2. 매출 담보 채권

📈 매출 채권 담보 대출

: 재화나 용역을 판매하여 수령할 자금을 담보로 대출을 실행하는 것

• P2P 금융권에서는 부동산 ABL과 구분하여 매출 채권으로 표기
• SCF 선정산 서비스는 대출자가 소셜커머스 플랫폼을 통해 제품을 판매하면 일정 기간 이후에 판매 대금을 정산 받기 때문에, 시차를 해소하기 위함

💸 확정 매출 채권 vs 장래 매출 채권

확정 매출 채권 : 납품을 완료하여 매출이 확정된 채권

장래 매출 채권 (P2P 매출 채권 상품) : 과거 매출 기록을 기반으로 미래에 발생할 것으로 상정한 매출 채권

• 실제로 발생하지 않은 매출이 담보
• 납품을 완료하지 못하면 실제 매출이 발생하지 않음 ➡️ 사실상 대출자의 신용을 담보로 대출하는 셈

✅ 투자 전 확인할 사항

P2P 회사에서 대출자로부터 원리금을 강제로 상환하는 시스템을 구축했는가?

• 대출 기간동안 사업장에서 발생하는 카드 매출에서 대출금을 먼저 제외한다는 계약
• P2P회사와 대출자 공동명의로 매출 계좌를 설정하는 등

그렇다고 확정 매출 채권이 되는 것은 아니니 보수적으로 접근할 필요가 있음

💬 ABL(Asset-Backed Loans, 자산담보부대출)

• 현재 보유 자산과 재고 자산, 매출 채권 등을 담보로 대출을 해주는 상품

3. 전자어음 담보 채권

💰전자어음 대출

: 중소기업과 소상공인으로부터 전자어음을 담보로 실행되는 대출

• 전자어음에 적힌 만기일에 어음을 발행한 회사가 대출금을 상환하지 않으면, 해당 법인은 당좌거래정지를 통해 부도로 처리됨 ➡️ 매우 낮은 연체율(부도율)

• 재무적으로 안정적인 기업들이 전자어음을 발행

• 법무부 감독, 금융결제원 관리, 실물이 아닌 전자문서로 발급되어 위조나 변조가 불가

• P2P회사는 어음을 발행하는 법인의 재무 정보와 상황 능력을 심사하여 상품을 만듦

✅ 투자 전 확인할 사항

전자어음을 발행한 법인의 건전성 확인

• 해당 법인이 파산할 경우 약정한 금액을 돌려받지 못함
• 법인의 재무 상태표, 손익계산서, 당좌비율, 부채비율 확인

💬 어음

• 발행한 법인이 미래 특정 시점에 일정 금액을 상환하겠다고 기록한 증권

💬 당좌비율

• 법인이 보유하고 있는 현금성 자산을 처분했을 때 단기 채무(유동 부채)를 갚을 수 있는지 평가하는 비율
  • 당좌비율이 100% 이상이어야 재무 상태가 안정적
  • 100% 미만일 경우 기업이 보유한 현금성 자산보다 만기 1년 내로 돌아오는 채무가 더 많음

💬 부채비율

• 법인의 부채 총액을 법인자본으로 나누어 계산한 비율
  • 부채 비율이 낮은 회사일수록 안정적

4. 개인/법인 신용 채권

👤 개인/법인 신용 대출

: 별도의 담보 없이 대출자의 신용 정보만을 바탕으로 실행되는 대출

• 대출자의 신용 등급(NICE, KCB), 대출 목적, 자산 및 부채 현황 등의 정보를 기반으로 대출금 상환 능력을 판단하여 대출 여부 결정
• 신용의 경우 경기에 큰 영향을 받지 않아 변동성이 적음
• 상품 수가 많아 소액 분산 투자 가능
• 이자에 대한 세금은 원단위를 버리고 청구되어 절세 효과를 누릴 수 있음

😧 개인 회생으로 인한 손실

• 개인에게 자금 문제가 빈번하게 발생, 연체를 대수롭지 않게 생각 등 ➡️ 채무자가 개인 회생을 신청하면 원리금 회수 절차가 중단되고 채무가 일부 탕감되어 원리금 손실 발생

✅ 투자 전 확인할 사항

대출자의 신용 정보만으로 상환 능력을 판단하기 어려움

• P2P회사에서 제공하는 포트폴리오 상품에 투자하기
• 포트폴리오를 구성하여 소액 분산 투자하기

다수의 대출자를 모집하고 평가하는 리소스가 듦

• 신규 P2P 회사 보다는 업력이 있는 회사를 중심으로 투자하기

💬 DTI (Debt To Income, 총부채상환비율)

• 대출자의 연간 총 소득에서 연간 부채 상환액이 차지하는 비율
  • 대출 받고자 하는 사람의 소득을 기준으로 상환 가능성 가늠
  • 해당 비율이 낮으면 상환 능력이 높다고 볼 수 있음

참고 P2P투자 상품의 종류(1): 부동산 후순위 담보 채권 P2P투자 상품의 종류(2): 매출 담보 채권 P2P투자 상품의 종류(3): 전자어음 담보 채권 P2P투자 상품의 종류(4): 개인/법인 신용 채권

Peer to Peer, 개인과 개인을 연결한다는 의미로 제도권 금융기관을 거치지 않고 개인 간의 금융거래를 말한다. 투자자들이 차입자(대출자)에게 직접 돈을 빌려주고 대가로 이자를 받는 제도권 외 금융이다.

🔄 P2P 프로세스

출처 : 데일리인사이트

1. 차입자가 대출을 신청
2. P2P 회사에서 차입자의 정보를 수집하여 평가
3. 담보를 확인하고 해당 상품을 투자자에게 공개
4. 투자자들이 투자 결정 후 입금
5. P2P 회사에서 해당 금액을 차입자에게 전달
6. 차입자는 대출 기한이 되면 원금과 이자를 P2P 회사에 상환
7. P2P 회사는 상환액에서 수수료를 제외한 뒤 투자자에게 전달

P2P 서비스의 특징

💰 투자자

• 수익률이 높다 예금·적금 상품 금리 : 연 35% P2P투자 상품 금리 : **연 615%**

• 투자 원금을 보장하지 않는다 차입자가 약정한 기간 내에 대출을 상환하지 못할 경우, 리스크는 투자자가 지게 됨 ➡️ 따라서 투자자가 판단할 수 있도록, 차입자에 대한 정보를 투명하게 공개

• 중도 취소가 불가하다 투자를 시작하면 투자 상품의 상환 날짜까지 투자를 취소할 수 없음 중도 상환이 아니라면 중간에 원금을 인출할 수 없음

• 자산 관리에 유리하다 P2P대출 채권이 전통적인 금융 자산(주식, 채권, 부동산)과 상관관계가 적음 주식보다는 편리하고 안정적인 수익을 기대할 수 있음

💸 차입자

• 낮은 신용등급자에겐 비교적 대출 금리가 낮다 카드사·캐피탈사 신용대출 금리 : 11.63% ~ 27.27% P2P투자 상품 금리 : 6~15% ➡️ 기존 제2금융권에서 받은 고금리 대출을 갚기 위한 목적으로 사용하기도

• 투자자의 접근성이 높다 자산운용사 부동산 펀드는 소액 투자금을 가진 개인들이 접근하기 어려운 사모투자 위주 P2P는 소액으로도 투자를 할 수 있어 쉬운 부동산 간접 투자 수단이 됨

🩵 들어가며

드디어 약 4개월간의 학회 활동이 끝이 났다. 분명 첫 프로젝트 시작이 어제 같은데.. 벌써 3개의 프로젝트를 완수했다니 믿기지 않는다😐 큐시즘에서 다양한 사람들과 프로젝트를 하며 겪은 경험을 회고해보려고 한다! 프로젝트 회고가 처음이라 미숙하지만~ 쓰다보면 익숙해지겠지~ 디자인 결과물에 대한 회고는 다음에 작성해보도록 하겠다.

💜 기업프로젝트 - Code;it (2/18 ~ 3/10)

💭 Overview

코드잇 기업과 연계하여 타겟층이 개발자 직군인 서비스를 기획하고 디자인하여 프로토타입까지 산출해야하는 프로젝트를 큐시즘에 들어와서 처음으로 진행하게 되었다. 시간이 짧은 탓에 우리 팀은 거의 격일마다 회의를 진행했다.

✅ R&R

• UX설계, UI디자인, PT디자인, 서비스 소개 영상 제작
• 디자이너는 나 혼자 배정되었고, 기획자 4명(4명 중 1명은 중도탈퇴)과 함께 진행헀다.
• PM을 맡았다.

👍🏻 Liked - 좋았던 점

• 회의하면서 기획자들의 창의적인 역량과 관점을 제대로 느낄 수 있었다.
• 기획자들이 피그마를 수월하게 사용하지 못해 비효율적으로 작업하는 것이 느껴져서 2시간 가량 피그마 강의를 기획자들에게 해줬었다. 지금까지도 그 강의가 도움이 많이 되었다고 해줘서, 앞으로 기획자들에게 피그마 팁을 프로젝트 초반에 알려주면 좋을 것 같다.

👎🏻 Lacked - 아쉬웠던 점, 부족한 점

• PM이었지만, 디자인 업무를 혼자 담당하다보니 뒤로 갈수록 PM 역할을 제대로 하지 못한 것 같아 아쉬웠다.
• PM으로써 기획자들의 발산하는 아이디어를 잘 수렴시키고 하나의 방향성을 가져갔어야 했는데, 뭔가 잘 안되었던 것 같아 아쉽다. 좀 더 아이디어를 정리하고 다방면에서 분석했으면 좋았을 것 같다.

✍🏻 Learned - 배운 점

• 컬러의 경우 코드잇 측에서 제공해준 디자인 시스템을 활용했다.
• 라이트모드와 다크모드가 나눠져 있었고, 각 컬러의 매핑까지 정리되어 있었다.* 이는 디자인을 하고 컬러만 라이트/다크로 바꿀 상황에서 매우 용이하게 활용되었다. 앞으로 라이트/다크 모드를 모두 디자인할 때에는 매핑까지 구축해야 한다는 것을 알게되었다.

  🙏🏻 Longed for - 앞으로 바라는 것

• 상을 받지는 못했지만, 아무래도 기획과 디자인까지만 프로덕트가 나오다 보니 기획적인 측면을 많이 채점하셨던 것 같다. 기업에서 어떤 부분을 고민하고 있는지를 도중에 잊어버렸던 것 같다. 앞으로 다른 프로젝트에서도 클라이언트의 목적을 잘 분석한다면 좋은 결과를 얻을 수 있을 것이다!

  💭 review

• 혼자 디자인하느라 체력적으로 힘들었지만, 정말 기억이 왜곡될 정도로 좋은 기획자들과 함께해서 너무 좋았던 프로젝트다! 이 팀원들과 큐커톤이나 밋업 때 다시 만나지 못해 아쉬웠다.

💚 무박2일 큐커톤 - Dopame! (4/5 ~ 4/6)

💭 Overview

점심부터 다음날 오전까지, 하나의 프로덕트를 기획부터 개발까지 구현하는 큐커톤 행사에 참여하게 되었다. 29기에서는 트렌드코리아의 키워드를 사전에 알려주고, 당일에 주제 키워드를 알려주는 방식으로 진행되었다. 우리 팀은 행사 전날 피그잼에 각 키워드에 대한 아이디어를 간단하게 적어 공유했다.

✅ R&R

• UX설계, UI디자인, 브랜딩 디자인 디자인은 나 포함 디자이너 3명이서 작업했다. 시간이 없는 터라 키비주얼이나 디자인 컨셉만 다같이 짜고, 디자인 작업은 따로 역할을 정하지 않고 남아있는 업무를 알아서 맡아서 하는 식으로 유동적이게 진행했다. 다만 디자인 피드백을 많이 주고, 기획팀과 UX관련 논의를 많이 하다보니 얼떨결에 암묵적 디자인 리드가 되었다.

👍🏻 Liked - 좋았던 점

• 개발까지 짧은 시간 안에 구현해야 하다보니 기획에서 쳐내는 것이 많을 수 밖에 없었다. 하지만 오히려, 기획을 쳐내고 핵심 기능(MVP)만 남기니까 디테일한 디자인에 더 집중할 수 있었고 무엇보다 개발이 빠르게 진행되어 완성도가 올라갔다는 점이 좋았다.

👎🏻 Lacked - 아쉬웠던 점, 부족한 점

• 암묵적이지만 디자인 리드로써 부족했던 점은, 아무래도 결과만을 생각했다는 점이다. 할 일이 많고 시간이 없다보니, 소통 시 생각을 많이 들이지 못했던 것 같다. 디자인 피드백이나 수정 요청을 설득이 아니라 일방적으로 지시했다. → 물론 결과물이 디자이너에게 최우선이겠지만, 여기는 회사가 아니라 배움을 목적으로 운영되는 '학회'다. 디자인 역량이 부족한 팀원들에게 배울 기회를 내쳐버린 것 같아 아쉬웠다.

✍🏻 Learned - 배운 점

• 기획자들이 할 일이 정말 많았다. 발표도 해야하고, 서비스 제안을 위한 근거 자료도 찾고, 서비스에 들어가는 데이터를 일일이 백엔드에게 넘겨줄 뿐만 아니라 전체적으로 디자인과 개발이 자신들의 방향과 맞게 흘러가고 있는지 확인을 해야하기 때문이다. 개발을 같이 배우는 학과라서 개발단 프로세스는 잘 알고 있었지만 기획자의 구체적은 프로세스는 알지 못했었다. 이번 29기 큐커톤을 통해 기획자의 업무가 구체적으로 무엇인지, 어떤식으로 흘러가는지를 알게 된 것 같다.

🙏🏻 Longed for - 앞으로 바라는 것

• 큐커톤을 한 번 해보며 느낀 것은.. 정말 체력적으로 너무 힘들다는 것이다. 다른 팀원들은 중간 중간 잠을 잤지만, 나는 욕심이 너무 많고 결과물에 만족되지 않아 끝까지 거의 쉬지 않고 작업했었다. 다음엔 워라밸을 챙기면서 좀 더 효율적인 디자인 프로세스는 무엇일지 고민해볼 것이다.

💭 review

• 결과는 대상을 받았다! 프론트 개발자가 1명인데, 진짜 쉬지도 않고 작업해주셔서 고생많았다고 칭찬을 엄청 했었다.

💛 밋업 프로젝트 - univfit (3/24 ~ 5/25)

💭 Overview

아이템은 기획 파트 학회원분들이 아이디어를 발제하고 투표를 받아 득표 상위권 아이디어들로 선발했다. 다시 아이디어를 구체적으로 발표한 뒤 질의응답 시간을 가진 후 개인 역량과 우선순위에 맞춰 팀 빌딩이 이루어졌다.

✅ R&R

• UX설계, UI디자인, 모션그래픽 나를 포함한 2명이서 디자인을 맡게 되었다. 다른 팀원이 4주 동안 여행을 가셔서 주로 내가 다른 파트와 소통을 해야했기 때문에 디자인리드를 자연스럽게 맡게 되었다. 작업은 아무래도 여행 스케줄 때문에 팀원분이 먼저 만드시면 내가 다시 수정하는 방식으로 진행할 수 밖에 없었다.

👍🏻 Liked - 좋았던 점

• 슬랙을 처음으로 사용했는데, 디스코드보다 소통이 용이해서 다음에도 쓸 것 같다. 조금 불편하면 디스코드를 슬랙처럼 쓸 수 있도록 설정하여, 채팅과 음성 회의 모두 디스코드에서 할 수 있도록 할 것이다.
• 피그마에서 플로우대로 화면을 정리해 보았는데, 실제로 프론트 팀원분이 보기 편하다고 하셔서 앞으로도 그렇게 정리를 할 것 같다.
• 다른 팀들은 캐릭터나 브랜딩적인 요소를 많이 첨가했는데, 사실 그러한 감성 전달이 필요하기보다 좀 더 컴팩트하고 편리함, 심플함을 전달하고자 로고도 간결하고 캐릭터도 넣지 않았다. 처음엔 퀄리티가 떨어져보일까 걱정이 되었지만, 오히려 더 깔끔하고 학사모 심볼도 서비스를 인지하기에 직관적이라는 평가를 받았다.

👎🏻 Lacked - 아쉬웠던 점, 부족한 점

• 기획한 기능들이 짧은 시일 내 구현하기 방대하고, 또한 서비스의 방향성도 가져가지 못했다는 피드백을 받았다. 사실 디자인할 때에도, 기능이 많다보니 화면도 많아지고 결국 화면 구현에 급급하여 작은 디테일을 챙기지 못해 아쉬웠다. → 앞으로는 기획을 컴팩트하게 덜어내고 mvp를 빠르게 만들어 테스트하는 빌드로 진행할 것이다.
• 기획자가 넘겨준 와이어프레임은 플로우나 사용성을 고려한 화면이 아닌 기능 중심의 화면이었다. UX를 다시 설계하는 것은 생각보다 리소스도 많이 들고 생각을 많이 하기에 골치 아픈 일이었다. → 할 일이 조금 많아지더라도 프로젝트가 루즈해지는 것을 방지하기 위해 디자이너가 와이어프레임을 함께 작업하는 것이 효율적인 방안인 것 같다.

✍🏻 Learned - 배운 점

• 생각보다 개발자들이 봐야하는 문서가 너무 이곳저곳에 퍼져있고, 굉장히 불편함을 야기한다는 것을 알게 되었다. 예를 들면 기능명세서는 노션에 있고, 화면 설계서는 피그마에 있고. 개발자들은 왔다갔다 하지 않고 하나만 보면서 개발하기를 원하는 것 같았다. → 이를 해결하기 위해서는 아무래도 피그마에서 UI와 함께 기능 설명을 붙여놓는 것이 현재로써는 제일 최적의 방안이 아닐까 싶다.

🙏🏻 Longed for - 앞으로 바라는 것

• 프로젝트에 열정이 생기기 위해선, 이 프로젝트든 팀이든 애정이 있어야 한다는 것을 알게 되었다. 그렇게 애정을 통해 열정이 생기고, 그 열정으로 만들어진 프로덕트는 완성도가 높다. 앞으로의 프로젝트에도 팀원들이 프로젝트와 팀에 애정을 느낄 수 있도록, 여러 방안을 찾아 시도해볼 것이다!

💭 review

• 다사다난했지만 무사히 잘 끝나서 다행이라고 생각이 든다. 끝나고 나니 다음 기수는 좀 더 잘할 수 있을 것 같다는 자신감과 좀 더 잘 해볼걸하는 아쉬움이 남는다.

🩷 마치며

큐시즘의 좋은 점은 크게

• IT분야의 다양한 사람들과 네트워킹할 수 있다.
• 잘하는 학회원들을 보고 자극받고 동기부여 된다!
• 짧은 기간안에 다른 직군들과 협업하는 프로젝트를 무려 3개나 할 수 있다.

다양한 인맥을 쌓고 단기간에 성장할 수 있다는 것이 정말 최고의 장점인 것 같다.

큐시즘 사람들은 학회와 학회원들에 대한 애정이 깊어 보였다. 결과물도 중요하지만, 이러한 경험은 큐시즘이 아니면 겪지 못할 것 같다. 그래서 30기 운영진을 꼭 하고 싶다. 애정을 가지고 의미있는 경험도 하고, 더 열심히 해서 좋은 프로덕트도 만들고 싶다! 운영진이 되지 못하더라도, 큐시즘에 있다면 지금의 나보다 더 발전할 수 있을 거란 확신이 든다.

💪🏻30기도 화이팅하자!🔥

1. 명확성, 직관성, 자명함 (clarity, obviousness, self-evidence)

• 혼동하지 않고 바로 이해할 수 있는 이름
• 약어를 쓰더라도, 바로 어떤 것을 의미하는지 파악할 수 있어야 함

2. 조직적 일관성 (consistency & organization)

• 명칭은 일정한 순서와 규칙을 지니고 있어야 찾고 사용하기 쉬움
• 동일한 객체에 대하여 동일한 명칭을 적용

3. 접두사와 접미사의 활용 (prefixes & suffixes)

• 서로 다른 타입의 디자인 요소를 구분하기 위하여 접두사, 접미사 활용
  • 예) button - btn, label - lbl 축약하여 명칭의 앞 뒤에 붙임

4. 카멜 케이스나 케밥 케이스와 네이밍 규칙

• 명칭을 만들 때 스펠링 적용에 있어서 특정 스타일을 표시해야 함

5. 상호배제성 (uniqueness)

• 중복 사용으로 인한 충돌을 방지하기 위해 상호배제된 네이밍을 사용함

6. 버전 관리 (version control)

• 숫자나 날짜를 표기하여 각 디자인의 이력을 추적하고, 최신 버전의 디자인을 사용할 수 있도록 함

7. 문서화 (Documentation)

• 디자인 시스템에 대한 문서화를 지속적으로 업데이트하여 새로운 팀원이 빠르게 적응할 수 있도록 함

💡효과적인 디자인 시스템 구조화 방법

1. 알파벳 순서로 분류

2. 디자인 원자에 맞는 분류 - 텍스트 스타일, 폰트, 컬러, 버튼, 아이콘 등

3. 사용 목적에 따른 분류 - 탐색 (Navigation) : 사이트나 어플리케이션으로 이동하는 요소 - 양식 (form) & 인풋 (input) : 버튼, 텍스트 박스, 체크 박스와 같이 양식에서 사용되는 요소 - 미디어 요소 : 이미지, 비디오, 갤러리와 같은 멀티미디어 컴포넌트 - 표시 (indicator) & 알림 (notification) : 진행 바(progress bar), 오류 메시지, 알림 등 - 페이지 구조 : 헤더, 푸터, 사이드바와 같은 페이지의 구조적 요소

4. 콘텐츠 타입에 따른 분류 - 텍스트 콘텐츠 : 제목, 문단, 인용 등의 요소 - 멀티미디어 콘텐츠 : 이미지, 비디오, 아이콘과 같은 요소 - 목록 : 숫자 목록, 글머리 기호와 같은 목록과 관련된 요소 - 표 : 표의 스타일과 디자인 요소 - 양식 : 인풋, 버튼, 드롭다운 등의 요소

5. 디자인 복합성에 따른 분류 - 기본 요소 : 버튼, 텍스트 필드와 같은 간단한 컴포넌트 - Compound 요소 : 카드, 패널 등 여러 기본 요소들을 조합하여 만든 디자인 컴포넌트 - 페이지 : 다양한 컴포넌트와 디자인 요소를 포함하여 완성된 페이지

6. 사용 맥락에 따른 분류 - 홈페이지, 프로필, 블로그와 같이 특정 사용 맥락에 따른 단위로 묶는 것

✅Naming Convention 네이밍 컨벤션

• 스네이크 케이스 : html class 명으로 주로 사용

  • 단어 사이 띄어쓰기 대신 언더바 사용
  • 예) snake_case

• 케밥 케이스 : html class 명으로 주로 사용

  • 단어 사이 띄어쓰기 대신 하이픈(-) 사용
  • 예) kebab-case

• 카멜 케이스 : html id 명, JS의 함수 명명으로 주로 사용

  • 단어 사이 띄어쓰기 대신 대문자로 표기
  • 예) camelCase

• 파스칼 케이스 : JS의 객체 명명에 사용

  • 단어의 시작을 모두 대문자로 표기
  • 예) PascalCase

• 헝가리언 표기법

  • 단어의 접두어를 사용하며 표기
  • 예) strName (str -> string)
  • 예) btnStart (btn -> button)
  • 예) bBusy (boolean -> b)

✅ICON 네이밍

💡Basic Principle

1. 제작한 아이콘들에 대해 일반적, 규칙적, 범용적 네이밍 시스템을 사용하자.

• 이미지 파일들의 이름이 관련 있는 것 끼리 디렉토리 내에서 그룹핑 되도록!

2. 논리적이고 예측 가능한 직관적인 명칭을 붙여주자

• 아이콘의 기능이 아니라 형태에 맞춰서 이름을 붙이자.
• 그 아이콘이 다른 곳에서는 다른 요소로 재활용 될 수 있음

3. 아이콘에도 효율적인 관리가 필요하다

• 밀도는 다르지만 이미지는 같은 아이콘 파일은 동일한 이름을 사용하자.
• 저장 시 밀도별 리소스 디렉토리에 각각의 경로로 저장되어 충돌이 일어나지 않음(안드로이드 스튜디오 한정)

4. 디자인 팀 단위, 프로젝트 단위의 명명 규칙을 설정하면 누구나 따라야 한다.

• 일관성 있는 네이밍 룰 : 시스템이 커지더라도 아이콘의 속성과 해당 에셋이 어디에 사용되는지 쉽게 알 수 있음
• 비정형적, 추상적, 외우기 어려운 전문 용어는 피하자 : 커뮤니케이션에 혼선을 가져옴
• 임시 이름은 사용하지 말자 : 배포 이후 네이밍 변경은 번거로움

5. 좋은 네이밍 규칙은 디자인 리소스를 아낄 수 있다!

How to❓

기본적인 규칙

• 미국식 알파벳 소문자 a-z, 언더바, 숫자 0-9가 유효하다.
• 아이콘 이름의 첫 글자는 숫자가 될 수 없다.
• 확장자에도 대문자를 사용하지 않는다.
• 공백을 사용할 수 없다.
  • AOS : 언더바(_) 사용
  • iOS : 하이픈(-) 사용
• 에셋 이름은 앱/화면 전체에서 고유해야 한다.
  • 크기가 다른 두 개의 add 버튼이 있을 경우, 같은 네이밍으로 지정할 수 없다.
  • 두가지 이름을 붙여 다양한 밀도에 대응하자.

네이밍 규칙의 구조

• 🔴 asset type : What? 이 리소스는 무엇인가?

  • 예) icon - ic, button - btn, image - img, background - bg

• *🔴 namespace *: Where? 논리적으로 속한 위치

  • 여러 화면에서 사용되는 아이콘은 namespace를 따로 붙이지 않는다.
  • 구체적인 하위 클래스에 속하는 아이콘에만 location에 해당하는 namespace를 추가한다.
    • 예) 내비게이션 - 'ic_navi_xxxx.png'
    • 예) 런쳐 - 'ic_launcher_xxx.png'
    • 예) 탭바 - 'ic_tab_xxxx.png'

• 🟡 root : 에셋의 고유 이름

  • 해당 아이콘을 가장 잘 설명할 수 있는 명사
  • 구체적이고 특징적인 묘사 or 메타포로 네이밍
    • 예) arrow, check_box, chevron, error, cancel, radio_btn, star 등

• 🔵 suffix : 🔴영역과 🟡명사의 조합으로 이름을 만들었으나, 동일한 이름이 이미 다른 아이콘에 사용되어 충돌하는 상황에 부가적으로 한정자(qualifier)를 추가

  • direction : 모든 방향을 지닌 것들을 추가
    • 예) right, left, up, down, horiz, vert
  • shape : 아이콘의 고유 형태에 대한 구체적인 언급이 필요할 때
  • outline : 축약하여 o만 붙이기도 함. filled가 디폴트일 때 예외 케이스에서 아웃라인만의 아이콘이 필요할 경우 (iOS처럼 아웃라인이 디폴트일 경우 생략)
  • status : control status에 대한 묘사가 필요할 때
  • color : black, white, pink, gray500 등 외의 다른 특별한 설명이 필요하다면 HEX코드로 표기
  • size : 구체적인 dp값, small/medium/big 또는 @2x, @3x 등

네이밍 예시

⭐디자인 토큰이란

색상, 애니메이션, 간격, 글꼴 등을 설명하는 디자인 변수.

• 구체적으로 시각적 디자인 특성을 저장하는 것

디자이너 간 효율적인 작업 뿐만 아니라 통일된 규칙의 디자인 토큰으로 개발자와 원활하게 소통하기 위함

• 개발단계에서 일관성과 변경효율성을 높일 수 있음

디자이너들은 스네이크 방식, 개발자들은 헝가리언 표기법과 카멜방식을 선호

📃참고

디자인 시스템 명명 규칙 네이밍 컨벤션(Naming Convention) - 스네이크/ 케밥/ 카멜/ 파스칼/ 헝가리언 표기법 아이콘에 제대로 된 이름 붙여주기 디자인 시스템 만들기-디자인 토큰(1)

⏩다음편 예고

LINE 디자인 시스템 뜯어보기

2학년을 끝내고 맞이한 겨울방학. 나는 우연히 큐시즘 공고를 보게 되었고, 망설이다 신청을 놓치게 된다..

당시 뭐라도 해보자는 마음으로 서비스디자인학회 Cresol에 지원했고, 9기로 1년동안 활동하며 구현단 보다는 기획단에서 디자이너들과 UX를 심도 깊게 공부했다.

마침내 또 다시 찾아온 겨울방학.. 예전의 우유부단한 나는 없으리라. 인스타그램에 리크루팅 공고가 올라오자마자 노션을 켜고 서류 준비를 했다.

📃서류 면접

서류면접 질문은 그렇게 어렵지 않았다. 평소 디자인에 대한 신념과 철학을 가지고 있어서인지, UXUI 소학회를 운영해본 경험이 있어서 그런지, 아님 둘다.

내용을 어떤 형식으로 풀어나갈지는 네카라쿠배 등 대기업에 제출한 자소서를 참고하면서 썼다.

1. 큐시즘 지원 동기를 포함해 자신에 대해 소개해주세요. (700자 이내)

• 이 문항에서는 우선 '내가 어떤 디자인을 하는 사람인지'와, 그와 관련하여 큐시즘에서 무엇을 하고 싶은지를 연관지어 작성했다.
• 인적사항을 나열하기보다 내가 어떤 디자인을, 어떤 이유로 추구하고 있고, 그 역량을 더 키우기 위해 큐시즘에 지원했다는 식으로 풀어나갔다.
• 좀 더 다른 사람들과 차별화 하기 위해 컨셉화, 셀프 브랜딩했고 그를 나머지 문항에도 적용하여 읽는 사람들로 하여금 나를 쉽게 파악할 수 있도록 했다.

2. 본인의 디자인 역량을 가장 잘 보여줄 수 있는 프로젝트와 이에 대해 자세하게 작성해주세요. (1000자 이내)

• 디자인 역량을 쓰라고 했을 때 무엇을 써야할지 조금 고민이 됐다. "어차피 포트폴리오도 볼거고, 그리고 디자인 잘하는건 어차피 기본이잖아?" 그래서 UX적인 측면, 눈에 보이지 않는 부분을 오히려 적기로 했다.
• 보통 디자인이라고 하면 눈에 보이는 부분만 생각하기 쉽상이다. 그런 부분을 꼬집고, 오히려 UI가 아닌 UX 설계를 통해 문제를 해결한 경험을 작성했다.

3. 사용 가능한 디자인 툴과 수준(상/중/하)를 상세히 적어주시고, 작업 포트폴리오 링크를 첨부해주세요

• 여기서 단순 툴 이름과 수준을 상, 중, 하로만 나타내기엔 아쉬움이 있었다. 운영진을 여러번 하면서 사람마다 생각하는 숙련도 기준이 다르고, 또 웬만하면 중인데 상으로 체크하는 경우가 많았기 때문이다. 그래서 각 툴마다 어떤 기능을 활용해서 어떤 작업까지 했는지를 1~2줄 정도 추가로 작성해서 제출했다.
• 노션으로 급하게 템플릿 받아서 가장 보여주고 싶은 프로젝트 4개를 선정해서 넣었다.

4. 디자이너로서 IT서비스 관련 프로젝트에 참여했던 경험을 구체적으로 말씀해주세요. (1000자 이내)

• 여기도 마찬가지로 심미적인 부분보다는 협업에 있어 디자이너의 역량을 보여주려고 했다.
• 이 파트는 위에서 말했던 셀프 브랜딩을 잘 설명할 메인 프로젝트 경험을 하나 고르고, 서브 프로젝트 경험을 하나 덧붙여서 신빙성을 높였다.
• 나의 경우에는 나 제외 개발자들과 프로젝트를 했던 경험을 메인으로, 디자이너들만 있는 프로젝트를 서브로 활용했다.

5. 지금까지 했던 활동/ 하고 있는 활동 내역을 기간 및 단체와 함께 자세하게 적어주세요.

• 이 문항은 길게 적으면 한 눈에 보기 어려울 것 같아 간단하게 작성했다. 내가 무엇을 했는지 알 수 있도록 역할과, 대회 같은 경우는 결과도 추가하여 작성했다.

6. 다음학기 계획 및 스케줄과 마지막으로 하고 싶은 말을 자유롭게 적어주세요.

• 일단 쓰라는 대로 계획과 스케줄을 작성했다. 솔직히 말하면 하는거 더 많은데 거짓말했다.. ㅋ 그래도 수습 가능할 정도라 괜히 솔직하게 썼다가 못미더운 구석을 만들기 싫었다.
• 포트폴리오로 이미 디자인적 역량은 봤을거고, 협업 경험도 위에서 말해놨고, UX관련해서도 적어놨으니 마지막으로는 다루지 않았던 책임 및 열정과 마지막으로 나를 한 번 더 어필하는 글을 썼다.
• 마지막 한 방으로 내 이름을 언급하여 기억에 남도록 했다.

👥대면 면접

면접은 대면으로, 관악구에서 이루어졌다. 1차 서류 합격 통보를 전날 23:30 쯤 받아서 진짜 급하게 준비해야 했다. 큐시즘 유튜브도 정독하고 사이트도 정독하고 온갖 준비를 다했다. 그러나.. 준비했던 예상 질문에서 단 하나도.. 나오지 않았다.

면접 장소에 도착하니 OT와 학회비 관련 안내를 해주시고, 대기했다. 면접관 분들은 3명이었고, 면접은 다른 한 분과 함께 봤다.

기억나는 것만 적어보면

• 자기소개

  • 엄청 긴장해서 자소서에 썼던 셀프 브랜딩 내용대로 말했다.. 더듬어서 망했다고 생각했다.

• 다른 디자이너와 함께 작업할 때, 키 비주얼이 겹친다면 어떻게 할 것인지

  • 이 부분도 당황했다. 상대방의 디자인 의도를 들어보며 서비스의 가치와 컨셉과 부합하는지 먼저 확인하고, 내 의견을 고집하기보다 절충안을 찾아갈 것이라고 답했다.

• 협업할 때 보통 리더인지 팔로워인지

  • 머릿속에 말할 거리가 너무 많아서 오히려 답을 제대로 못했던 질문이다. 이 부분은 어느 면접이든 자주 나와서 메뉴얼을 만들어두는게 좋을 것 같다.
  • 거시적으로 바라보고 다른 파트의 이야기를 잘 듣고 설득한다는 장점이 있어 리더를 많이 하고 스케줄 관리도 잘한다고 했다. 너무 긴장해서 순서도 이상하게 말했다. ㅋㅋ..

• 디자인 시스템이 왜 필요하다고 생각하는지

  • 클래스 101에서 디자인 시스템의 필요성 강의를 미리 들어놨던 과거의 내 자신을 칭찬하겠다. ㅋ
  • 디자인 시스템을 좀 더 제대로 구축하고 싶은 생각을 항상 하고 있어서 쉽게 답했다. 개발자와의 협업, 효율적인 디자인, 사용자가 혼란스럽지 않게 하는 디자인 등.. 면접 끝나고 '디자이너가 아닌 다른 사람이 봐도 이해하고 설득될 수 있는 디자인 규칙' 이라고 추가로 대답할걸 생각했다.

• 나만의 디자인하는 방식이 있다면

  • 여기서 더블다이아몬드 프로세스를 언급했다. 그러나 실무에서는 사용자 리서치를 짧게 해야한다고 했고, 개발자와 함께하는 특성상 와이어프레임과 정보구조도를 신경써서 정한다고 답했다.

• GUI와 UX 둘 중에 어디에 더 자신있는가

  • 서류에도 개발 공부 경험을 적어놨고 그런 셀프 브랜딩을 했었기 때문에.. 구현단에서 많이 해봐서 GUI는 자신 있으나 UX가 조금 약하기 때문에 다양한 방법론으로 리서치 해보고 있다고 했다.

• 텍스트로 된 기획서를 보고, 시각화 가능한가

  • 여기서 모션그래픽 소학회 얘기를 꺼낼 줄은 상상도 못했다. 모션그래픽 소학회에서 항상 아이디어를 생각하고 추상적인 상상을 직접 그래픽으로 표현해 본 경험이 있고 또 많아서 자신있다고 답했던 것 같다.

• 디자인 시안을 정하는 방식 (질문 기억 안남 주의)

  • 디자인 컨셉을 먼저 생각하고, 떠오르는 아이디어를 다양하게 직접 그려본다고 했다. 시간을 두면서 다음날에 봐도 괜찮은지 확인한다고 했다. 이 부분은 사실 잘 기억 안난다.

뭐든 답변은 구구절절 길게 하는 것 보다는 명료하게 정리해서 말하는게 좋은 것 같다.

이 외 질문은 기억이 나질 않는다.

💙결과

결과는 최종 합격!!🥹 열심히 준비한게 너무 뿌듯한 순간이었다. 앞으로의 활동도 너무 기대되고, 사람들이랑도 많이 친해지고 싶다.