- LanguageGuide
- Swift
- lineBreakStrategy
- iPad
- GOF
- CollectionView
- WWDC
- Split View
- UIKit
- DiffableDataSource
- 디자인패턴
- 야곰아카데미
- HIG
- lineBreakMode
- TOSS
- iTerm
- github
- Apple
- 애플사이다
- Human Interface Guidelines
- Keychain
- orthogonalScrollingBehavior
- Combine+UIKit
- 앱개발
- 전달인자 레이블
- UILabel
- Accessibility
- 스위프트
- 애플
- IOS
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- Today
- Total
애플사이다의 iOS 개발 일지
[toss] iOS 개발자를 위한 SIMPLICITY23 리뷰 - 디자이너와 친해지기 본문
toss SIMPLICITY23의 세션을 온라인으로 구경하고 재밌었던 4개 세션을 가져와 봤다.
SIMPLICITY23은 토스의 2023년 디자인 컨퍼런스이다.
토스가 UX 기획에 가장 중요하게 생각하는 원칙인 단순함 (Simplicity)을 따서 네이밍했다고 한다.
크게 5개 카테고리, 총 23개 세션으로 구성되어 있다.
개발자가 디자인 컨퍼런스에 왜 참여해야 할까?
디자인팀의 경험과 노하우를 공유하는 자리인데, 개발자가 참여할 필요가 있을까?
개인적으로 개발자는 디자이너와 긴밀하게 협업하는 위치이므로
디자이너가 마주하는 어려움과 고민을 이해하는 것이 중요하다고 생각한다.
그리고 주로 프로덕트 디자이너에 대한 이야기지만 개발자에게도 도움되는 내용도 많다.
장애물을 만났을 때 어떤 마인드셋을 가졌는지, 문제해결을 위해 구성원을 어떻게 설득했는지 등
일잘러의 태도도 살펴볼 수 있어서 좋았다.
소감부터 먼저 말하자면
토스의 저 세상 문화
처음에는 사실 이런 의문을 가졌다.
'토스가 애플도 아닌데 왜 이런 세션을 열까? 왜 토스만의 고급 정보를 굳이 공개할까?'
그런데 세션을 보고 나니 알겠다.
토스에서 토스 문화를 누리면서 일해보고 싶다는 강력한 동기부여를 받았다.
"문화가 복지다. 유능한 동료가 복지다."라는 말이 잘 맞는 회사인 것 같다.
이렇게 회사 내부적인 이야기를 밖에다가 해도 되나 싶을 정도로
구체적인 문제해결 사례와 토스만의 디자인 원칙을 볼 수 있어서 좋았다.
심지어 성공 사례뿐만 아니라 실패 사례까지 들을 수 있었는데, 실패를 허용하고 적극적으로 시도하는 문화가 정말 좋아 보였다.
혁신 그 잡채
게다가 컨퍼런스의 내용도 좋았지만, 형식 자체도 혁신적이었다.
세션은 디자이너를 인터뷰하는 방식으로 진행되는데
유튜브의 수많은 인터뷰 영상처럼 두 사람을 투 샷으로 잡고, 아래에 자막을 까는 식으로 만든 게 아니라
둘의 대화를 interactive 자막으로 보여주는 팟캐스트 형태로 진행됐는데
내용에 몰입하기 좋았고, 모바일 화면도 같이 나와서 쉽게 이해할 수 있었다. 기획자 천재 아닌가?
"프로젝트를 마친 시점에서 과거의 자신에게 조언을 해준다면?"이라는 질문도 신선했다.
1. 인터렉션, 꼭 넣어야 해요?
문제상황
제품에 인터렉션을 넣으면 UX가 좋아진다는 건 모두 알지만, 구현 비용 때문에 엄두가 나지 않는 게 현실이다.
토스도 인터렉션 디자이너팀은 사실상 작년에 만들어졌고, 대부분의 화면이 정적이다 보니
"구현이 어렵다, 모션이 개발 공수 대비 임팩트가 없을 것 같다"... 등의 부정적인 인식이 많았다고 한다.
*인터렉션 디자인이 궁금하다면?
toss 블로그에 모션, 금융을 즐겁고 쉬운 경험으로 만드는 방법 포스팅으로 구체적인 내용을 더 읽을 수 있다.
해결방법
인터렉션은 단순히 심미적인 기능 (예뻐 보이기만 하는 것!) 뿐만 아니라
애플/구글의 디자인처럼 사용자에게 더 명확한 피드백을 줄 수 있다는 장점이 있는데,
이것을 디자이너가 구성원들에게 적극 어필했다.
첫째로 인터렉션으로 지표를 개선하는 사례를 만들었고, 실제로 이탈률이 감소한 것을 확인했다.
그리고 앱 전체에 영향을 미치는 기능인 버튼의 터치 이펙트를 다듬었다.
예를 들어 버튼이 눌리는 느낌이 나도록 모션을 만든 것이다.
둘째로 공수를 최소화했다.
실제 CollectionView에 모션을 주는 게 아니라 CollectionView 위에 새 레이어를 올리고 모션을 적용해서 한 화면인 것처럼
눈속임 모션으로 공수를 줄였다.
인터뷰이가 안드로이드의 Material 가이드 (= iOS의 HIG 같은 문서)를 통해 이런 아이디어를 생각하게 됐다는 계기까지 공유해 주셨다. 🥺 천재인데 천사임...
안드로이드 쪽에는 관심이 없었는데 나중에 Material 가이드와 HIG를 비교하는 글을 써보면 재밌을 것 같다.
그다음 인터렉션을 재사용하여 공수를 줄였다.
여기서 놀라운 점은 '디자인 시스템'과 비슷하게 '인터렉션 시스템'을 만들었다는 것이다. 진짜 대단하다... 😲
근데 또 여기서 문제는 iOS, 안드로이드, 웹의 용어나 동작 방식이 모두 달랐던 것이다.
그래서 각 플랫폼별 담당자가 모두 모여서 플랫폼 공통 스펙을 만들었다.
복잡한 모션을 표현할 수 있는 공통의 언어를 만든 것이다.
결론적으로 개발자와 디자이너 모두 편해졌다고 한다.
Figma에서 inspect를 열면 바로 Rally 코드를 확인 가능하다. 그저 놀랍다... 사실 이거보고 우리회사는 못쓰겠구나 싶었다.😲
회사의 디자이너분에게 건너들었는데,
토스는 디자인툴로 Figma 대신, 코드 기반의 Framer라는 프로그램을 쓴다고 한다.
커뮤니케이션 측면에서 배운 점
인터렉션 시스템을 빠르게 전파시킨 비결도 있다.
슬랙에 #animate-noti라는 모니터링 채널을 만들어서
다른 구성원들이 인터렉션, 모션, 랠리 관련 단어를 언급할 때 자동으로 알림이 오도록 하고
스레드에 찾아가서 Rally 코드를 쓰면 된다고 직접 안내했다고 한다.
2. 크고 복잡한 제품 과감하게 갈아엎기
문제상황
기존의 '내 문서함' 기능에 너무 특성이 다른 기능 (ex. 주민등본 발급, 관리비 납부, 세금 납부, 건강검진 안내 등)이 엉켜있어서
화면의 복잡도가 높아지고 사용자가 직관적으로 앱을 사용할 수 없게 되는 문제가 있었다.
워크샵만 3번 가고, 몇 개월을 날렸다고 한다.
해결방법
결론적으로는 특정 서류를 접했을 때 사용자가 Main Action이 뭘까? (= 가장 먼저 어떤 행동을 할까?)를 기준으로 3개 종류로 분류했다.
첫 번째는 발급하는 액션 (주민등본 발급), 두 번째는 납부하는 액션 (통신비), 세 번째는 알림과 통지를 받는 것 (백신접종 안내)
그리고 진입점이 필요없는 화면은 과감하게 메뉴에서 제거했다.
예를 들어 보험사 통지서는 특정시점에 가입 유저에게 알림만 주면 되고, 별도의 액션이 없다.
그래서 다시 이 기능을 찾아 들어올 일이 거의 없다.
그런데 여기서 굉장히 정치적인 문제가 생겼다.
문서 기능을 3개 종류로 쪼개고 나니, 더 이상 1개의 진입점으로 고정시킬 수 없게 된 것이다.
근데 기존의 '내 문서함' 진입점은 전체 탭의 상단에 위치하므로 좋은 트래픽을 받고 있었다.
PO 입장에서는 제품을 성공시켜야 하므로 트래픽을 포기하기 힘들었다. ('크로스 액티베이션'이라도 되지 않을까?)
근데 결국 단기적인 지표보다는 사용자 중심으로 기능을 만드는 것에 집중하면
장기적으로 전체적인 제품 성장에 도움이 될 거라는 믿음을 가졌다고 한다.
결론만 보면 당연한 얘기지만, 고민의 과정을 엿볼 수 있어 좋았다.
Product Principle 엿보기
개인적으로 토스는 디자인 원칙이 분명하고, 원칙에 대한 팀원들의 살제 공감도가 높아보였다.
예를 들면 Product Principal의 One thing per on page (한 화면에서 하나를 말해야 한다)가 지켜지지 않는 예
등본 떼기 외에도 성적증명서, 자격증명서 떼기 도 가능한데,
'내 문서함' 네이밍이 너무 제네럴해서, '등본 떼기'로 하니까 이제는 너무 지엽적인 문제가 있었다.
결론적으로 '증명서 떼기'로 바꾸되 '토스 주민센터'라는 카테고리로 표시해서 직관성을 높였는데 반응이 좋았다고 한다.
3. 초등학생도 쓸 수 있는 제품 만들기
문제상황
만 14세 이상을 위한 모바일 금융상품이 없었다.
도입 시 장애물
- 법적 절차가 까다로움
- 유사 프로덕트가 없어서 마켓 핏이 검증되지 않음
- 비즈니스 임팩트가 작음
해결방법
마인드셋
- 어려움을 겪고 있는 유저의 문제를 해결해주는 것이 더 가치있지 않을까?
(이미 모든 서비스를 누리고 있는 만 14 이상 vs. 서비스가 전혀 없는 만 14세 미만)
장점 (구성원을 설득한 논리)
- 나이가 어린 유저를 Lock-in 시키는 효과
리스크
- 자녀의 사생활 보호를 위해 부모에게 사용 내역을 공유하지 않도록 했다.
-> 부모 입장에서는 자녀가 갈취/사기당하는 상황 등이 우려되는 문제가 있다.
-> 토스의 FDS 시스템 (이상 거래를 감지/차단하여 문제 해결)을 고도화한 청소년 전용 FDS 시스템을 구축해서 해결했다. - 용어에 대한 어려움을 느끼지 않도록 최대한 쉬운 용어를 사용했다.
- 자산 -> 지갑, 송금 -> 돈 보내기, 소비 -> 용돈 기입장
MVP 스펙은 어떻게 정했나?
- "만 14세 미만의 유저가 어떤 기능 때문에 가입하고 싶어할까?"를 고민했다.
-> 사용 불가를 알리는 기존 화면을 활용하여 설문을 진행했다.
-> 압도적인 답변이었던 송금만 구현했다. - 출시 후 '토스에게 알려주세요' 메뉴를 추가하여 추가 설문을 진행했다.
-> 1~10위 기능을 모두 배포했더니 유저 만족도가 굉장히 높았다. ('토스는 내가 원하는 걸 만들어준다!')
디자이너가 배운 점
- 만드는 사람과 유저와의 간극이 클 때는 더 적극적으로 유저 보이스를 들어야 한다.
(제품 곳곳에 맥락에 맞는 설문 넣기, 임직원 자녀 또는 리쿠르팅을 통해 어린이 인터뷰하기 등) - 반대의 목소리가 많은 프로덕트는 유저에게 전달할 수 있는 가치를 먼저 파악하는 것이 중요하다.
4. UX 라이팅, 혼자가 아닌 함께 잘 쓰기
사용자들이 서비스를 사용할 때 접하게 되는 단어, 문구들을 설계하는 일입니다. 서비스와 사용자 간 커뮤니케이션을 디자인하는 역할이기도 하죠. (...) 명확성, 일관성, 꼼꼼함, 자기 인식, 사용자 입장에서의 맥락 등을 종합적으로 고려해 결과물을 만들어낼 수 있어야 합니다.
토스에는 UX 라이터가 3명 밖에 없어서(?) 토스의 모든 글을 전부 관리하는 것이 불가능하다.
그래서 동료들의 글쓰기 실력을 향상시키기 위한 고민을 한다.
예를 들어 푸시 메시지를 개선한 사례가 있다.
자유롭게 문제점을 제보하는 #problem-of-toss 슬랙 채널이 있는데,
푸시 메시지에 대해 공통적으로 '다른 푸시들과 조금 느낌이 다르다'는 내용이 많았다.
Writing Principle
토스에는 텍스트 디자인 규칙을 정의한 8가지 Writing Principle이 있는데,
이 원칙을 근거해서 글을 개선해나갔다.
- Universal Words : 모든 사람들이 이해하는 단어를 써야한다. 드라마, 영화 소재, 밈은 사용을 지양한다.
- Suggest than Force : 너무 강한 어조의 문구로 유저에게 공포감을 주지 않는다.
- Predictable Hint : 다음 내용을 짐작 가능하게 쓴다.
이 원칙도 이미 토스 기술블로그의 '토스의 8가지 라이팅 원칙들' 포스트로 정리되어 있다.
ㄷㄷ.... 이 글 자체도 너무 좋다. ✨✨✨
'좋은 에러 메시지를 만드는 6가지 원칙' 포스트도 추천한다.
문제상황
푸시가 투자 콘텐츠로 연결되는 중요한 진입점이므로 자극적인 푸시 문구를 작성했다.
특이한 문구나 이모지를 활용해서 반응률을 높이자. vs. UX가 좋아야 한다.
해결방법
먼저 유저의 의견을 들었는데, 콘텐츠에 이미 부정적인 댓글이 달려있었다.
그래서 UX 라이팅 원칙을 기반으로 증권 콘텐츠 푸시에 대한 가이드라인을 제작했다.
글을 검토하는 포인트
정보와 표현 2가지 차원 (어떤 정보를 담을지, 어떻게 표한할지)으로 나눠서 체크하면 좋다.
- ex. 정보 : 공급자 중심의 밸류는 아닐까? (종목 이름보다 수익률이 얼마인지 소개하는 게 유용하다!)
- ex. 표현 : 상투적인 표현이 아닐까? (오름세로 출발했어요. -> 시작이 좋아요.)
고민한 점
이렇게 개선해서 문구는 좋아졌지만, 반응률이 낮아지지 않을까?하는 우려가 있었다.
동일한 메시지를 정보/표현/문장 형태가 다르게 푸시 문구 실험을 진행했다.
결과적으로 유저가 '9시'라는 시간에 잘 반응한다는 러닝을 얻었다.
이런 식으로 월 단위로 러닝을 정리하고, Winning/Losing 패턴을 공유해서 지표를 높이는 게 가능하다고 구성원에게 어필했다고 한다.
또한 기존 글의 패턴을 파악하여 카테고리별 템플릿을 만들고, Winning 패턴의 디스크립션을 만들어서 둘을 조합해 사용하도록 했다.
MVP 버전의 글로벌 앱을 만들면서
개발자이지만 앱에 들어가는 문구를 함께 고민했었는데, 간단한 메시지도 매번 어렵게 느껴져서 오래 고민했었다.
특히 국내에서 런칭하는 해외 서비스인 만큼
외국인 유저 입장에서는 번역투가 심하거나 맥락에 맞지 않는 단어를 사용하는 등 문장이 매끄럽지 않으면
비즈니스 자체에 대한 신뢰도가 떨어질 수 있다는 생각이 들었다.
지금 재직중인 회사에는 UX 라이터가 없지만, 필요성에 대해 매우 공감하게 됐다.
쓰다보니 필기 노트처럼 됐지만... 🫤
UX에 관심이 많은 개발자라면, 또는 디자이너의 고민을 이해하고 싶다면
관심 가는 세션을 가벼운 마음으로 들어보는 것을 추천한다. (각 섹션은 15분 내외이다!)
- Reference
- toss > Simplicity23 전체 세션보기
- toss careers > Simplicity23, 오늘도 문제를 해결하고 있을 모든 디자이너에게
- 안드로이드의 Material 가이드
- toss feed > 모션, 금융을 즐겁고 쉬운 경험으로 만드는 방법
- toss tech > 토스의 8가지 라이팅 원칙들
- toss tech > 좋은 에러 메시지를 만드는 6가지 원칙
- toss feed > 토스가 금융을 더 쉽게 만드는 또 하나의 방법, UX Writing
- Blog > Lisa - What is UX Wrting?
- Article > ICUNOW - UX 라이팅이란?
🍎 포스트가 도움이 되었다면, 공감🤍 / 구독🍹 / 공유🔗 / 댓글✏️ 로 응원해주세요. 감사합니다.
'프로그래밍 철학' 카테고리의 다른 글
[디자인 패턴] Command - 실행할 작업을 덩어리로 관리할 때 (0) | 2023.07.02 |
---|---|
[toss] iOS 개발자를 위한 SLASH23 리뷰 (7) | 2023.06.18 |
[디자인 패턴] Singleton (0) | 2023.03.26 |
[디자인 패턴] Builder - 초기화 과정이 복잡할 때 (0) | 2023.02.20 |
[디자인 패턴] Abstract Factory - 미리 정해둔 종류로만 객체를 생성할 때 (0) | 2023.01.16 |