Product talk(여행 앱): 저 여행 가요!✈️ 근데 무슨 앱을 써야 하죠?

Intro

우리 삶에서 여행은 무엇을 의미하나요? 개개인마다 다르겠지만, 아마 새로운 경험이며 휴식일 것입니다. 그러면 그 경험을 극대화하기 위해 준비해야 할 것들이 있죠. 이러한 여행자를 위한 앱은 꽤 많습니다.
이런 상황에서 제가 만약 여행 관련 앱을 만든다면? 고민이 많이 될 것 같다는 생각이 들었어요.

• 너무 많은 앱이 존재하다보니 사용자는 무엇을 선택해야 할지 모를 것 같습니다. 그러면 여기서 제공해야 하는 차별성은 무엇일까요?

  • 이미 숙소, 항공권 예약, 자동차 렌탈, 액티비티 예약, 여행자 커뮤니티 기능까지 한 번에 갖춘 앱들이 많음

  • 편의성? 가격 경쟁의 우위 선점? 여행지에 대한 방대한 정보제공?

• 차별성을 챙기면서도 가져가야 할 가장 중요한 BM은 무엇일까요?

  • 저의 머리에선 광고 또는 중개 수수료밖에 생각나지 않았습니다.....🥹

• 어떤 기능을 통해 락인(Lock-in) 효과를 노릴 수 있을까요?

  • 여행 앱을 사용하는 사용자들은 분명 모두 목적이 있습니다. 그러면 사용자가 좀 더 이 앱에 머물 수 있게 하는 트리거는 무엇이 되어야 할까?

이러한 궁금증을 가지고 글로벌 타겟의 몇 가지 여행 카테고리의 앱들을 탐험 해보았습니다.

• 제가 탐험한 앱은 Tripadvisor / Tripbtoz / Trip.com / Booking.com / Sky Scanner / Expedia 입니다!

그리고 색다른 경험을 제공하는 앱은 어떤 것이 있는지, 경험이 어땠는지 적어보았어요.

1. (내가 생각하는) 여행 앱의 필수 기능 및 경험

• 숙소 및 항공권 예약(Trip.com👍🏻)

  • Trip.com은 이 부분에서 나무랄 것이 없었습니다. 제가 탐험한 앱들 중 가장 많은 기능을 제공하고 있었어요! 이는 편리함과 가격 경쟁 측면에서 확실히 우위에 있는 것으로 보였습니다.

  • 사용자가 검색할 수 있는 옵션도 많았어요.

    

• 여행지에 관한 정보 찾기 및 공유(Trip.com/Tripadvisor👍🏻)

  • 특별하게 눈여겨 본 점들이 있었어요.
    여행지에 관한 정보는 플랜을 짜는데 꼭 필요하죠. 그런 점에서 이제 AI 기능은 필수가 된 것 같아요. 여행 플랜을 짜주는 것에 Trip.com / Tripadvisor 모두 이 기능을 갖추고 있었습니다.

    

2. 그럼, 색다른 경험을 할 수 있었던 앱은?

👍🏻 사용자와의 인터랙션을 통해 앱테크를 내세운 "Tripbtoz"

사용자에게 일방향으로 정보를 제공하는건 당연하다고 생각했습니다. 그걸 위해 사용자는 여행 앱을 켤테니까요. 이런 점에서 사용자와 서비스간의 상호작용이 새로운 기회로 보였습니다.

• ✈️ Tripbtoz 사용자의 주요 경험: 여행 경험 공유 / 게임 → 트립캐시 얻기 → (트립캐시로) 다시 여행 계획

  • 일반적인 여행 앱은 정보 제공 → 정보 누리기(예약, 리뷰 보기) → ETC(공유 등) 순서가 보통인 것 같은데, Tripbtoz는 이 우선순위가 바뀐 것처럼 느껴졌어요.

  • 앱을 실행하면 가장 먼저 뜨는 메인 화면이 Feed라는 점에서 더욱 이점을 느낄 수 있습니다.

  • 여행을 떠날 수 있는 유저를 많이 확보하자는 목표 아래, 색다른 경험을 통해 트립캐시를 제공함으로써 이익 시스템을 사용자와 분배하는 구조를 설계했어요.

• Gamification 기능을 제공

  • 가상호텔을 키우는 게임을 통해 잼을 획득하고, 이를 트립캐시로 바꿀 수 있어요. 트립캐시는 여행 플랜에 지불해야 하는 머니로 사용할 수 있음은 물론, 게임 아이템도 살 수 있습니다.

• SNS와 유사한 느낌

  • Feed는 인스타그램의 릴스 또는 틱톡 같았다.

  • 예전에 이런 기능이 에어비앤비 앱에도 있으면 좋겠다는 생각을 한 적 있었습니다! 별점을 매기는 평가가 아닌, 생생한 경험을 보고 싶으니까요. 이제 일방적인 정보를 제공하는 서비스는 사용자에게 매력도가 떨어진다는 것을 느꼈습니다.

👍🏻 경험의 일관성을 극대화해서 편안한 Tripadvisor

일단, 이름을 기억해두어야 합니다. Tripadvisor에요!!! 이 앱의 마스코트인 귀여운 부엉이는 다정하고 편안하게 여행 계획 짜는 것을 도와줍니다.

• 이 앱을 써보면서 가장 먼저 인식했던 점은, advisor에 걸맞는 UX writing이었어요.
  키워드보다 동사 형태를 많이 사용했고, 이는 사용자의 입장에서 어떤 것을 해야하는지 더 직관적으로 안내 해주는 느낌이었습니다.

  • ex. Hotel 대신, Stay / Activity 대신, Do와 같은 형태

• 여행의 플랜보다, 경험 자체에 더 초점이 맞춰져있습니다.

  • 숙소를 추천하며 "지금 빨리 이 가격으로 예약해야해~~"가 아닌, 맛집이나 오히려 할 것들에 대한 추천이 메인 화면에 노출되어 있었어요. Tripbtoz와는 또다른 느낌으로 SNS 같다고 생각했어요.

    

• 나만의 여행 테마를 만들고, AI 기능으로 이를 빌드하는데 도움을 줍니다.

  • 날짜와 가는 곳을 입력하고 몇 일 여행인지, 여행의 테마는 무엇인지, 혼자 가는지 등 몇 가지 칩을 선택하면 숙소 및 놀거리 등을 추천해줍니다.

  • Trip.com에서도 똑같은 기능이 있었는데, 거기서는 “좋은 정보를 빠르게 주네!”라는 경험이었다면, Tripadvisor에서의 여행 테마는 제안에 더 가까웠어요. "이런게 있는데, 어떤 것 같아?"같이요!
    친구를 초대할 수 있는 Invite 기능이 있어서 동반자와 여행 계획을 함께 짜는 것에도 유용하게 느껴졌어요.(Invite는 Expedia에도 유사하게 있긴 하더라구요!😆)

    

• 리뷰는 평가 형태가 아닌, 사용자의 '찐 경험 적기'로 유도한다.

  • 리뷰 메뉴에서 왜 리뷰를 작성하면 좋을지, 이 서비스만의 언어로 표현한 점이 일단 친절하다고 느꼈어요. (누군가는 구구절절하다고 느낄 수도?!)

  • 사용자들은 내가 갈 여행지 또는 가보지 못한 여행지에 대한 리뷰를 쓴, 그 사람 만의 가치 있는 경험을 관찰할 수 있습니다.
    이는 과대한 평가가 아닌 자연스러운 경험을 미리 느낄 수 있게 함으로써, 친절한 충고자의 조언을 들은 느낌이에요. 그리고 리뷰를 쓴 사람은 Tripadvisor 내에 나의 여행 히스토리를 기록하는 경험을 누릴 수도 있고요!

3. 이렇게 탐험 해봤으나, 여전한 궁금증들

• 색다른 경험 제공은 돈이 될까?
  → 여행 앱들의 BM은 결국 장소의 정보 노출에 대한 수익 뿐일까?

  • 위에 소개하지 않은 Sky Scanner의 경우는 Hotelscombine과 유사하게 결국 정보불균형 해소에 초점이 맞춰져 있습니다.

  • 색다른 경험을 제공하여 사용자를 유입시키고, 결국 중개 수수료나 고객 DB 공유 수수료가 이런 서비스들의 주요 수익일까요?
    (물론 Tripbtoz의 경우는 위 질문에 대한 답을 어느 정도 해소 해주기는 하지만 여전히 의구심이 드네요.)

  • 사용자는 여행을 가기 전 숙소나 항공권 예약에 대한 결제를 미리 하기 때문에, 이런 기업들은 그 중간에 가지고 있는 현금 흐름이 꽤 중요하다고 하는데요, 적절한지는 모르겠지만 결국 금융 앱(?)에도 가깝다는 생각이 듭니다.

• 어떤 데이터를 볼까?

  • 물론 사용자를 락인 시키는 중요한 기능들을 주의 깊게 볼 것 같지만, 좀 더 사용자의 행동을 면밀하게 분석해서 여행자의 여러 특성을 분류할 수도 있을 것 같습니다.

  • Tripadvisor를 보면서 느꼈던 것은, 리뷰를 쓰는 것에 대한 리워드가 따로 없는 대신(아, 리뷰 업로드를 하면 더 많은 리뷰를 보고 올릴 수 있는 정책은 있습니다!) 이 리뷰에 대한 신뢰성이 리워드를 주는 앱보다 높을 수 있겠다고 추측했어요. 또 이 의도는 사용자로 하여금 '기록'이라는 니즈를 채워주는 것인지도 궁금해졌습니다.

🔍UX Boost: Canva - '좋아요' 기능을 통한 데이터 흐름 및 컨텍스트의 일관성

캔바! 사용 해보신 분들 있나요?✋🏻

솔직히, 저는 디자이너이기 때문에 캔바를 이용하지 않습니다. 그러나 최근에 호기심이 생겨서 PC app을 다운받아 사용해보았어요. 그런데 왠일이죠? 어쩌면, 후에 피그마 이상이 될 슈퍼 앱 같다는 생각까지도 했습니다.

Simple note

• 상업적으로 이용될 수 있는 모든 디자인 템플릿이 존재해서 디자이너가 아니어도 쉽게 커스터마이징 가능하다는게 엄청난 장점입니다. 한국에는 미리캔버스라는 비슷한 서비스가 있습니다.

• 현재 프라이머리 타겟은 디자이너가 아니지만 fancy한 디자인 결과물이 필요한 사용자일 것 같은데요. 저는 여기에 디자인 시스템 형성 기능이 추가된다면 디자이너 사용자까지 타겟을 넓힐 수 있다는 생각이 들었습니다.

• 다른 서비스와의 연결성도 사용성을 높이는데 한몫 한 것 같아요.

• 개인적으로 가장 놀라웠던건 브랜드 키트를 생성할 수 있다는 것이었어요!!!

그러나, 본론으로 돌아가서 제가 오늘 이야기하고 싶은 내용은 마음에 드는 템플릿을 만났을 때 별(좋아요) 아이콘을 누르는 starred 기능입니다.

옵션들을 보고 선택해야 할 때 대부분의 서비스에서 제공하는 기능이죠.

캔바 내에서 정말 많은 템플릿들을 제공하고 있기 때문에, 꽤 중요도가 높은 기능이라 생각됩니다.
사용자는 수많은 템플릿 중 맘에 드는 것들을 여러개 골라두고 최종 선택할 수 있어요.

그렇다면 아래와 같은 행동 흐름이 있겠죠?

• 템플릿들을 살펴본다 → 맘에 드는 몇 가지를 추린다. → 몇 가지를 골라둔 화면으로 이동한다 → 최종 선택 → 작업

위 플로우 그대로 진행해보았어요.

Problems

1. 맘에드는 템플릿을 발견, 별 아이콘을 눌렀어요. 그럼 starred라고 써져있는 토스트가 뜨고 view버튼을 누르면 내가 선택한 템플릿들이 아카이빙 된 화면으로 이동할 수 있습니다.

   

2. Starred된 탬플릿 아카이빙 화면은 아래 사진과 같이 좌측 메뉴의 Project라는 카테고리 내에 속한 것으로 사용자는 인식합니다.

   

3. 그러나 다른 카테고리로 이동했다가 Starred content 화면을 보기 위해 돌아가고자 Project 카테고리로 다시 이동했지만 존재하지 않습니다.

   

4. Starred content 화면은 Project가 아닌 Template 카테고리에 속한 것을 확인할 수 있어요.

   

Opinions

1. 사용자가 선택한 데이터는 일관성있는 맥락으로 보여져야 합니다.

   1. 별 아이콘을 눌렀을 때 캔바에서 토스트 메시지를 통해 유도한 화면은 분명 project 카테고리에 속해있었는데, 실은 Template 카테고리 내에 있는 화면이었죠.

2. 모든 정보의 흐름이 좌측에 있는 상위 메뉴들로 이어지는데, 카테고리로 내 화면에서 연관성 있는 화면으로의 이동이 자연스러우면 좋을 것 같다는 생각이 들었어요. 현재는 상 하위 개념이 매우 뚜렷해보여서 다른 테스크를 위해서 좌측 메뉴를 무조건 거쳐야 할 확률이 높습니다.

프로덕트 디자이너로서의, Next journey ➡️

오랜만에 디스콰이엇을 방문했습니다 :) !
디스콰이엇을 쉬고 있는 동안은, 영어 인터뷰를 준비하느라 쉴틈이 없었어요.

1

먼저 기쁜 소식과 동시에 아쉬운 소식을 전하자면,

기쁜 소식은, 1년 반의 여정으로 진행했던 Draw Hatha는 10월 30일자로 런칭을 했습니다. 🎉🎉

(iOS를 사용하고 계시다면, 앱스토어에서 다운로드 가능합니다🙂)

동시에 아쉬운 소식은, 저는 런칭까지만 함께 하고 이제는 저만의 여정을 가려고 합니다.

새로 시작하는 일들이 있는데 제가 한 번에 다 할 수는 없겠더라고요. 그건 욕심인 것 같아요.

아직 제가 갈 길에 대한 확신이 들지 않은 상태라 여러가지를 병행 중이고,

12월 첫째 주 발리로 워케이션을 떠납니다. (돌아오는 일정에 대한 고려는 아직 없습니다 ㅎ.ㅎ)

2

현재 하고 있는 일 & 바로 시작하고자 하는 일은,

1. 예비 창업자 대상, 디자인 멘토링 (*진행 중)

2. 해외 취업 준비(*인터뷰 진행 중)

3. 내 창업 아이템 구상

4. App critic을 한 파트너와 매일매일 유선으로 하고 있는데요, 여기서 얻은 인사이트를 디스콰이엇과 Medium에 각각 한국어와 영어로 아티클로 작성해보고자 합니다.

5. 저의 기획으로 앱을 만들어보기 위해 11월 말부터 플러터 스터디를 시작합니다. (스터디 파트너는 디스콰이엇에서 만난 디자이너분과 함께 💗)

디스콰이엇을 통해 얻은게 너무 많아요! 플러터 스터디 파트너도 그렇고, 디자인 멘토가 된 것도 여기서 저의 아티클을 보셨다고 하네요 :)

앞으로의 저의 여정을 응원해주세요!!!!

감사합니다!😊

링크드인은 A/B 테스트 중??? 여러분은 어떤 것이 더 나은가요???

어제부터 링크드인 모바일 앱이 좀 변경된 것을 캐치했는데요,

오늘 PMC24 멤버인 쟈밋님과 커피챗을 하며 추측하게 되었습니다. ㅎ.ㅎ

제 링크드인 앱(A)과 쟈밋님(B-기존) 것이 다르더라고요. (업데이트를 했는데도요!)

A(테스트 중)

• 포스팅 아이콘이 탑 바로 이동

• 하단 내비게이션에 비디오 탭 추가

B(기존)

• 하단 내비게이션 중앙에 포스트 탭

• 메인 화면에서 비디오로 진입할 수 없음

저는 궁금증이 좀 생겼어요.

1. 가장 중요한 테스크는 포스팅 / 피드 보기 두 가지라고 생각하는데요, 엄지손가락을 정말정말 많이 사용하는 모바일앱에서 굳이 포스팅을 탑 바로 옮긴 이유가 무엇인지 의문입니다.

2. 하단 내비게이션에 비디오 탭이 추가되었는데, 링크드인도 결국 숏폼의 물결을 타는건가 싶었어요.

3. 그리고 이 테스트에대한 가설도 궁금하고요.

개인적으로 링크드인에 글을 써보며 나름의 테스팅을 해보는 중인데, 타겟이 다른 소셜 네트워크 서비스에 비해서 명확하다고 생각되거든요.

여러분은 어떻게 생각하시나요?

우리에게 Fit한 "디자인 라이브러리"를 만들면 되죠

"디자인 라이브러리(또는 시스템)는, 확장성, 변화의 여지가 고려되어야 한다고 생각해요."

Opening

Draw Hatha를 만들고 있는 그리디브 팀의 디자이너 이주연입니다! 오늘의 주제는 상당히 많은 고민을 하게 했던 Draw Hatha의 디자인 라이브러리 구축 과정입니다. 라이브러리를 구축하는 방식은 이미 너무 많은 아티클들이 존재하고 있기 때문에, 저희 만의 프로세스를 적어보았습니다.
이미 써 놓은지 오래된 메이커로그임에도, 업로드에 많은 고민을 했던 이유는-

1. 디자이너가 없는 팀의 입장에서, 컴포넌트를 일일이 개발하는 것보다 컴포넌트 라이브러리를 쓰는게 더 효율적일 수 있기 때문입니다.

2. 저희의 라이브러리는 개선의 여지가 남아있기도 하고, 지극히 저희 팀에게만 ‘Fit’ 할 수도 있는 과정이기 때문이에요. 즉, 저희에게 핏한 과정이 다른 분들에겐 아닐 수도 있거든요.

여기서 솔직한 고백을 하나 하자면, 제가 저희 드로우하타의 브랜딩을 ‘미니 브랜딩’이라고 했던 이유도 저희에게 핏한 요소들로 구성되어있기 때문에 BX 디자인의 전문성을 가지고 더 디테일하게 진행하시는 분들에게 ‘누’가 될까봐 걱정되었어요.
그럼에도 제가 용기낼 수 있었던건, 이 라이브러리 세팅이 당연하고 어쩌면 모두가 아는 것일지라도, 디자이너가 없거나 디자인에 대해 막막할 수 있는 메이커 분들도 있지 않을까하는 마음입니다.
그 분들에게 조금이라도 도움이 되고 싶었어요. 기존에 이용할 수 있는 소스가 많긴 하지만, 제품의 확장성을 고려했을 때 ‘제품다움’이 주는 디테일은 결국 좋은 사용자 경험으로 이어질 수 밖에 없다고 생각해요.
개인적으로는 이 방대한 라이브러리야말로 제품의 특성에 따라, 그리고 조직의 상황과 크기마다 달라질 수 있다고 생각합니다. 그래서 저희 만의 (완벽하지 않은) 라이브러리에 대해 이야기 함으로써, 제품의 방향과 확장성에 따라 개선해 나갈 것임을 염두하고 읽어주시면 감사할 것 같아요 :)
완벽한 단계들을 다 쓸 순 없었어요. 그저 가볍게 참고만 해주세요!
오프닝이 역대급 길었네요- 그럼 이제 한 번 보실래요?🥹

라이브러리 구축 먼저하나요? 아님 플로우 설계 먼저 하나요?

어쩌다보니, 저는 0-to-1의 경험을 회사에서도 했고, 드로우하타를 통해서도 하고 있더라고요.
그래서 0-to-1 경험을 반복해서(?) 한 디자이너로서 이 제목의 대답을 일단 말하자면,

“동시에 해야하며, 개발자와의 소통에 따라 우선 순위가 정해질 것입니다.”

라이브러리는 비즈니스 전략적으로도, 사용자를 고려하는 방향성에서도 굉장히 중요한 부분입니다. 그리고 변화에도 신속하게 대응할 수 있게 하죠.

그럼에도, 꼭 지켜야 할 것

1. 아토믹 디자인

아토믹 디자인이라고 아시나요? 화면에 들어가는 모든 요소들을 작은 단위부터 큰 단위로 구성하는 방식입니다. 아토믹 디자인에 관련한 아티클들도 굉장히 많기 때문에, 이 부분은 생략할게요!

2. 컴포넌트 네이밍 규칙 정의하기

정해진 정답은 없으나, 제품의 특성과 개발 상황에 맞게 정해주시면 될 것 같아요. 보통은 컴포넌트 네임부터 시작하고, 그림과 같이 Property를 나눕니다!

'미니 브랜딩'과 '와이어프레임' 덕에, 초반에 구축할 수 있었던건?

1. 미니 브랜딩 덕분에, Color 세팅을 먼저 할 수 있었어요.

와이어프레임(설계)이 완료되고, Key Feature의 Flow가 나오면 본격적인 제품 디자인 단계(?)로 넘어갑니다. 저희의 경우는 이전에 브랜드 디자인이 되어있었기 때문에, Primary Color나 앱 자체의 무드는 정해져있었어요.

• 그래서 가장 먼저, Primary / Accent / Greyscale과 같은 기본적으로 필요한 Color Palette는 구축할 수 있었습니다. 특히, Grey scale은, 시작점이 어느 컬러냐에 따라 미세하게 톤이 달라지기 때문에 이 부분도 나름대로 연구했어요.
  

• 그리고 하나의 스크린에 일관성있는 컬러들을 조합하기 위해서는, 단계적인 컬러들이 필요했습니다. 그래서 Primary Color를 통해, HSL 값을 피그마에서 일정한 단위로 조정하며 명도에 따른 단계를 나누었어요.

  

이렇게 컬러를 일관성있게 만들어두면, 다른 컬러를 막 믹스하지 않아도 경우의 수가 많아집니다.

2. 와이어프레임 덕분에, Typography / Grid / Primary, Secondary Button 세팅을 먼저 할 수 있었어요.

저희는 (high-fidelity에 가까운) 와이어프레임을 통해, 플로우와 인터랙션 방식을 초반에 디테일하게 세팅하며 시작했습니다. 물론 제품 디자인 단계에서 변경된 부분도 많아요. ㅎ.ㅎ
(와이어프레임 빌드업은 상황에 따라 달라질 수 있다고 생각합니다. 해도 된다, 안해도 된다는 말씀드리기 어려울 것 같아요.)

1. 와이어프레임에 들어간 Text들을 통해, Typography를 구성했어요. 처음에는 가짓수가 많지 않았는데 점점 많아졌어요. 또 여기서 하나의 포인트가 있는데, 처음엔 Heading / Subheading을 구분했었어요. 근데 개발자 입장에서 컴포넌트 이름이 길어져서 불편하다고 하시더라구요.
   그래서 Type1,2,3…이런식으로 표기했고, 그 안에서 굵기에 따라 T3-1,2,3…이렇게 구분했어요.
   저 스스로 Type 1~3까지는 Heading이고 Type 4~5까지는 Subheading이라는 룰을 지키려고 했습니다. 그러나 이 부분은 명확성이 떨어져서 변경할 여지가 큰 것 같네요 :)

1. Grid는 Strict하게 가져가고 싶진 않았어요. Column > Margin 16px을 기본으로 잡았고, Gutter > 8px로 한다는 룰을 정했습니다.

2. 온보딩 플로우부터 필요했던 프라이머리 버튼을 세팅했어요! 그리고 color의 Greyscale 기반으로 Secondary버튼도 동시에 세팅했습니다.

   

자, 이제부터는 동시 진행입니다!

동시 진행의 기준들을 간략하게 적어볼게요. 존재하는 제품의 라이브러리 재구축이 아닌, 제품 빌드업과 동시에 라이브러리를 구축하는 것임을 잊지말아주세요.ㅠ_ㅠ

1. Key Feature에 포함되며, 많이 반복되는 중요한 컴포넌트 우선입니다.

이걸 어떤 기준으로 잡아요? → 만들고 있는 제품 설계를 보시면 알거에요! 또는 개발적으로 먼저 디자인되어야 하는 화면이 될 수도 있을 것 같아요. 저희는 메인 피쳐인 '기록하기' 화면부터 시작했습니다. 그 중에서도 상태의 분류가 되어야 하는 'Chip'부터 시작했어요. 저희의 경우는, ‘가입 후 정보설정~기록하기’까지 사용자가 칩을 통해 기록을 해야 하거든요.

2. 특정 화면에 귀속되지 않는, 템플릿을 구축합니다.

Toast / Modal Dialogue/Tooltip과 같은, 특정화면에 귀속되지 않고 어디든 등장가능한(?) 템플릿들을 구축했어요.

3. 화면 전환 인터랙션 방식을 정의했습니다.

기본적으로, 뒤로가기와 닫기 버튼이 포함된 Top bar Container 영역을 정의했다고 보시면 됩니다. 이건 문서와 함께 라이브러리에 제공했어요.

그리고, 이제부터는 위에 설명했던 모든 항목에 더 많은 것들이 추가되고 변경되는 프로세스를 반복합니다. ^^

그럼 Draw Hatha는, 앞으로 뭘 개선할건가요?

앞으로 Draw Hatha의 디자인 라이브러리가 개선되어야 할 점들은,

• 현재 라이브러리에 없는 요소들도 있어서 추가해야 합니다 ^^;

• 컴포넌트 하나하나를 일일이 다 라이브러리에 넣어두기보다는, 한 종류의 컴포넌트가 확장성있게 사용되도록 할 수 있는 방향을 고려하고 수정해야 할 것들이 있습니다.

• 각각의 컴포넌트와 템플릿에 대한 가이드를 정확하고 디테일하게 제공해야 합니다.

• 문서(정책과 같은 것들..)와 함께 제공되는 컴포넌트들은 문서 링크도 함께 연결해서 모두가 보기 편리하게 합니다.

갈길이 머네요….. 개발자분들과도 상의가 필요할 것 같고요.

혹시 모르는 컴포넌트 이름이 있다면..?(참고 사이트 링크 첨부)

그리고 저는 프로덕트 디자이너로 일해오면서 많이 느꼈던 부분인데요, 서로가 컴포넌트에 대해 지칭하는게 다르더라구요. 그리고 각 클라이언트마다 비슷한데? 다른 가이드로 사용되는 것들도 많구요. 또 제가 모르는 것도 있거든요.

그래서 그럴 때 제가 자주 참고하는 사이트를 넣어둘게요! 이걸 보면 더더욱 아실거에요. 회사마다 다르게 구성된 시스템과 또 같은 컴포넌트도 어떻게 구성되었느냐에 따라 붙인 이름이 다르다는 것을요 ㅠㅠ

사이트 링크: Designsystem surf

Closing

클로징을 하면서도 이거 맞나 싶지만 ㅎㅎ 꼭 기억하세요! 디자인 라이브러리에 답은 없습니다.
저희는 모바일 앱 사용자를 위한 디자인이기 때문에 반응형을 고려하지 않았는데요, 반응형을 고려한다면 Strict하지 않은 선에서 확장성 있는 설계를 고려해야 했을거에요.
결국 우리에게 맞는 'Fit'의 기준을 세우는게 라이브러리라고 생각합니다!
저희의 예시와 기준이, 제품을 빌드하시며 디자인에 대해 고민이 되는 분들에게 도움이 되었길 바라요 :)

회고 아닌 회고

어제는 랜딩페이지에 집중하고 뻗었던 것 같아요. 회고하려 했지만 머리가 돌아가지 않았습니다. ㅎㅎ

디스콰이엇 PMC 24를 하는동안 어쩌면 이게 아니면 하지 않았을 아티클도 작성해보고, 팀원들의 몰랐던 모습(?)도 알게 되었어요.
그리고, 프로덕트 하나를 완성하기까지 그 과정은 생각보다 단순하지 않고,
마케팅을 위해, 또 다른 기회를 발견하기 위해 고군분투 하는 다른 메이커분들을 보며 저에게는 또다른 세상이 펼쳐졌어요.
일단 하고보는 제 성향에 겸손함을 한 스푼 추가해야 하지 않을까 하는 성찰도 있었습니다.

무엇보다, 저희 프로덕트의 브랜딩이 나름대로 잘 딜리버리 된 점이 뿌듯했어요.
프로덕트의 사용성도 중요하지만, 일단 알려져야 그 사용성도 검증할 수 있다고 생각합니다.

우리 앱이 알려져서 좋았고, 제 아티클들을 즐겨주셔서 또 감사했어요.

그러나 아티클은 계속 쓸 생각입니다! 헤헷.