Applying Toss Tech Design
Overview
토스 디자인을 "예쁘게 만드는 일"이 아니라 문제 정의, 리서치 운영, 내부 툴, UX Writing, 접근성, 브랜드, 신뢰까지 포함한 운영 기술로 다룬다.
이 스킬은 sources/toss-tech-design-summary.md 요약 보존본의 핵심 원칙을 빠르게 적용하기 위한 실행 가이드다. 세부 근거가 필요하면 이 요약 보존본을 직접 인용하고, 확신이 낮으면 일반화보다 요약 보존본 근거를 우선한다.
When to Use
- 금융, 결제, 인증, 온보딩처럼 인지 부담이 큰 흐름을 설계하거나 리뷰할 때
- 리서치를 일회성 검증이 아니라 운영체계로 바꾸고 싶을 때
- 반복 수작업, 레거시 워크플로우, 내부 툴 비효율을 구조적으로 줄이고 싶을 때
- UX Writing, 에러 메시지, 가이드라인을 개인 역량이 아닌 시스템으로 만들고 싶을 때
- 접근성, 외국인, 시니어, 스크린리더 사용자처럼 실제 실패 지점을 다시 설계해야 할 때
- 브랜드, 그래픽, 인터랙션을 장식이 아니라 인지, 신뢰, 몰입 문제로 다뤄야 할 때
Do not use this skill when:
- 토스의 시각 스타일만 흉내 내고 싶을 때
- 문제 정의 없이 화면 미감만 손보는 작업일 때
- 원문 근거 없이 "토스라면 이럴 것" 같은 추측을 하고 싶을 때
Core Principles
- 큰 프로세스를 그대로 다루지 말고 액션 단위로 쪼갠다.
- 각 액션에 "왜 필요한가"를 묻고, 없앨 것과 자동화할 것을 나눈다.
- 내 팀의 편의가 아니라 이해관계자 전체의 리소스와 맥락으로 우선순위를 정한다.
- 완전한 해법보다 작은 테스트와 점진적 적용을 선호한다.
- 리서치는 인터뷰 대행이 아니라 문제 정의와 맥락 번역의 인프라다.
- Product Design은 기능 추가보다 문제 구조 재설계에 집중한다.
- 디자인 시스템, 내부 툴, 라이팅 가이드는 고객 제품처럼 측정하고 개선한다.
- 접근성은 체크리스트가 아니라 실제 사용 가능 여부를 좌우하는 핵심 사용성 문제다.
- 시각 요소와 인터랙션은 장식이 아니라 인지 속도, 신뢰, 몰입, 이해를 높이는 장치다.
- 전환율 압박보다 신뢰를 우선하고, 사용자를 압박하거나 속이는 문구를 피한다.
- 도메인을 빨리 배우려면 책상에서 추정하지 말고 현장과 사용자 일상 맥락으로 들어간다.
Working Method
-
문제를 다시 정의한다
사용자가 겪는 표면 문제 뒤에 있는 구조적 문제를 찾는다. 기능 요청을 그대로 받지 말고 "무엇이 막히는가"를 먼저 재정의한다. -
흐름을 액션 단위로 분해한다
큰 단계가 아니라 실제 행동 단위로 쪼갠다. 예: 날짜 선택, 참석자 추가, 링크 첨부, 공개 범위 변경. -
각 액션에 이유를 묻는다
각 액션을유지,삭제,자동화,보조중 하나로 분류한다. 이때 자신의 입장이 아니라 전체 이해관계자 기준으로 본다. -
가장 작은 실험을 설계한다
거대한 리뉴얼 대신 리스크가 가장 낮고 효과가 큰 작은 변경부터 테스트한다. -
실패 지점을 실제 사용자 기준으로 본다
접근성, 외국인, 시니어, 초심자, 내부 도구 사용자 등 실제로 막히는 사람의 문맥에서 본다. -
측정 가능한 운영 단위로 바꾼다
검색 시간, 완료율, 오류율, 만족도, 신뢰 손실, 탐색 성공 같은 지표로 운영 가능한 상태를 만든다. -
한 번의 개선을 시스템으로 승격한다
좋은 해법은 문서에서 끝내지 말고 컴포넌트, 템플릿, 라이브러리, 가이드, 운영 구조로 만든다.
Domain Lenses
- Research Ops: 리서처 개인의 병목을 줄이고, 팀 누구나 적절한 질문을 설계하고 결과를 읽을 수 있게 만든다.
- Product Design: 더 많은 선택지보다 더 적은 고민, 더 적은 입력, 더 쉬운 다음 행동을 만든다.
- Internal Tools / Design Systems: 내부 도구도 고객 제품처럼 KPI, 만족도, 탐색 시간, 확장성을 기준으로 개선한다.
- UX Writing: 좋은 문장은 취향이 아니라 시스템이다. 템플릿, 원칙, 작성 허들 감소, 팀 합의 구조를 설계하고, 사용자를 압박하거나 속이는 문구를 피한다.
- Accessibility / Inclusion: 별도 모드 추가보다 기존 정보 구조, 읽기 순서, 상태 전달, 입력 방식 자체를 다시 설계한다.
- Brand / Graphic / Interaction: 예쁨보다 인지 속도, 신뢰, 중립성, 상태 이해, 몰입을 높이는 방향으로 판단한다.
- People / Culture: 역할과 문화도 선언이 아니라 기준, 피드백, 온보딩 구조로 설계한다.
Execution Modes
- Quick mode:
Core Principles와Quick Reference만 사용해 빠른 방향을 제시한다. - Deep mode:
Domain Lenses와 원문 근거를 함께 사용해 구체적인 실행 방안을 만든다. - Audit mode:
sources/toss-tech-design-summary.md까지 확인해 근거, 한계, 적용 범위를 명시한다.
Output Contract
이 스킬을 적용할 때는 가능하면 아래 순서로 답한다.
- 문제를 어떻게 다시 정의할지
- 어떤 액션 단위로 쪼갤지
- 무엇을 줄이거나 없애거나 자동화할지
- 가장 작은 실험이 무엇인지
- 어떤 지표로 성공을 판단할지
- 반복 가능한 시스템 자산으로 무엇을 남길지
- 확신이 중요하면 어떤 원문 근거를 썼는지
Quick Reference
| Signal | Ask First | Default Bias |
|---|---|---|
| 사용자가 복잡하다고 느낀다 | 무엇이 어렵나가 아니라 어디에서 멈추나? | 선택지와 입력을 줄인다 |
| 반복 수작업이 많다 | 흐름을 행동 단위로 쪼개면 무엇이 남나? | 큰 자동화보다 작은 자동화 |
| 리서치가 병목이다 | 누가 질문을 설계하고 결과를 읽을 수 있나? | 리서치를 공용 인프라로 만든다 |
| 내부 툴 불만이 크다 | 정말 더 빨라졌는가, 더 찾기 쉬워졌는가? | 만족도와 탐색 시간을 측정한다 |
| 문구 품질이 들쭉날쭉하다 | 누가 써도 일정 수준이 나오나? | 템플릿과 시스템으로 배포한다 |
| 접근성 이슈가 있다 | 실제 사용자는 어디에서 혼자 끝내지 못하나? | 체크리스트보다 과업 성공률 |
| 브랜드/그래픽 판단이 어렵다 | 더 예쁜가보다 더 빨리 인지되는가? | 신뢰와 인지 속도를 우선한다 |
Implementation Example
Scenario: 리서치 일정 공유 프로세스가 느리고 휴먼에러가 많다
- 일정을 공유하는 전체 흐름을 날짜 선택, 참석자 추가, 링크 첨부, 공개 범위 설정, 메시지 작성으로 분해한다.
- 각 액션에 "왜 필요한가"를 묻고, 불필요한 단계와 자동화 가능한 단계를 구분한다.
- 자신의 편의가 아니라 참여자 전체 리소스 기준으로 우선순위를 다시 잡는다.
- 가장 작은 실험으로 내부 참석자 자동 초대 같은 단일 개선만 먼저 적용한다.
- 공유 시간, 수정 횟수, 휴먼에러, 만족도 변화를 측정한다.
- 효과가 확인되면 이를 리서치 운영 템플릿이나 내부 툴 기능으로 승격한다.
Common Mistakes
- 기능 추가로 문제를 덮고 구조를 다시 보지 않는다.
- 효율화를 거대한 프로젝트로 시작한다.
- 리서치를 후반 검증 단계로만 취급한다.
- 내부 툴과 디자인 시스템을 보조 수단으로 취급한다.
- UX Writing 원칙을 문서로만 남기고 시스템으로 배포하지 않는다.
- 전환 압박형 문구나 과장된 설득으로 신뢰를 깎는다.
- 접근성을 법적 준수나 체크리스트로만 다룬다.
- 브랜드와 인터랙션을 장식적 연출로 소비한다.
- 원문 근거가 필요한데도 일반론으로 뭉개서 답한다.
Reference
- 빠른 적용은 이 파일을 우선 사용한다.
- 세부 근거와 기사별 맥락은
sources/toss-tech-design-summary.md요약 보존본을 본다. - 기사 원문 URL, 페이지 흐름, 태그 분포, 추출 한계까지 필요하면 반드시 요약 보존본에서 확인한다.