ilbie/toss-tech-design

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

1. 큰 프로세스를 그대로 다루지 말고 액션 단위로 쪼갠다.
2. 각 액션에 "왜 필요한가"를 묻고, 없앨 것과 자동화할 것을 나눈다.
3. 내 팀의 편의가 아니라 이해관계자 전체의 리소스와 맥락으로 우선순위를 정한다.
4. 완전한 해법보다 작은 테스트와 점진적 적용을 선호한다.
5. 리서치는 인터뷰 대행이 아니라 문제 정의와 맥락 번역의 인프라다.
6. Product Design은 기능 추가보다 문제 구조 재설계에 집중한다.
7. 디자인 시스템, 내부 툴, 라이팅 가이드는 고객 제품처럼 측정하고 개선한다.
8. 접근성은 체크리스트가 아니라 실제 사용 가능 여부를 좌우하는 핵심 사용성 문제다.
9. 시각 요소와 인터랙션은 장식이 아니라 인지 속도, 신뢰, 몰입, 이해를 높이는 장치다.
10. 전환율 압박보다 신뢰를 우선하고, 사용자를 압박하거나 속이는 문구를 피한다.
11. 도메인을 빨리 배우려면 책상에서 추정하지 말고 현장과 사용자 일상 맥락으로 들어간다.

Working Method

1. 문제를 다시 정의한다
   사용자가 겪는 표면 문제 뒤에 있는 구조적 문제를 찾는다. 기능 요청을 그대로 받지 말고 "무엇이 막히는가"를 먼저 재정의한다.

2. 흐름을 액션 단위로 분해한다
   큰 단계가 아니라 실제 행동 단위로 쪼갠다. 예: 날짜 선택, 참석자 추가, 링크 첨부, 공개 범위 변경.

3. 각 액션에 이유를 묻는다
   각 액션을 유지, 삭제, 자동화, 보조 중 하나로 분류한다. 이때 자신의 입장이 아니라 전체 이해관계자 기준으로 본다.

4. 가장 작은 실험을 설계한다
   거대한 리뉴얼 대신 리스크가 가장 낮고 효과가 큰 작은 변경부터 테스트한다.

5. 실패 지점을 실제 사용자 기준으로 본다
   접근성, 외국인, 시니어, 초심자, 내부 도구 사용자 등 실제로 막히는 사람의 문맥에서 본다.

6. 측정 가능한 운영 단위로 바꾼다
   검색 시간, 완료율, 오류율, 만족도, 신뢰 손실, 탐색 성공 같은 지표로 운영 가능한 상태를 만든다.

7. 한 번의 개선을 시스템으로 승격한다
   좋은 해법은 문서에서 끝내지 말고 컴포넌트, 템플릿, 라이브러리, 가이드, 운영 구조로 만든다.

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

이 스킬을 적용할 때는 가능하면 아래 순서로 답한다.

1. 문제를 어떻게 다시 정의할지
2. 어떤 액션 단위로 쪼갤지
3. 무엇을 줄이거나 없애거나 자동화할지
4. 가장 작은 실험이 무엇인지
5. 어떤 지표로 성공을 판단할지
6. 반복 가능한 시스템 자산으로 무엇을 남길지
7. 확신이 중요하면 어떤 원문 근거를 썼는지

Quick Reference

| Signal | Ask First | Default Bias | |---|---|---| | 사용자가 복잡하다고 느낀다 | 무엇이 어렵나가 아니라 어디에서 멈추나? | 선택지와 입력을 줄인다 | | 반복 수작업이 많다 | 흐름을 행동 단위로 쪼개면 무엇이 남나? | 큰 자동화보다 작은 자동화 | | 리서치가 병목이다 | 누가 질문을 설계하고 결과를 읽을 수 있나? | 리서치를 공용 인프라로 만든다 | | 내부 툴 불만이 크다 | 정말 더 빨라졌는가, 더 찾기 쉬워졌는가? | 만족도와 탐색 시간을 측정한다 | | 문구 품질이 들쭉날쭉하다 | 누가 써도 일정 수준이 나오나? | 템플릿과 시스템으로 배포한다 | | 접근성 이슈가 있다 | 실제 사용자는 어디에서 혼자 끝내지 못하나? | 체크리스트보다 과업 성공률 | | 브랜드/그래픽 판단이 어렵다 | 더 예쁜가보다 더 빨리 인지되는가? | 신뢰와 인지 속도를 우선한다 |

Implementation Example

Scenario: 리서치 일정 공유 프로세스가 느리고 휴먼에러가 많다

1. 일정을 공유하는 전체 흐름을 날짜 선택, 참석자 추가, 링크 첨부, 공개 범위 설정, 메시지 작성으로 분해한다.
2. 각 액션에 "왜 필요한가"를 묻고, 불필요한 단계와 자동화 가능한 단계를 구분한다.
3. 자신의 편의가 아니라 참여자 전체 리소스 기준으로 우선순위를 다시 잡는다.
4. 가장 작은 실험으로 내부 참석자 자동 초대 같은 단일 개선만 먼저 적용한다.
5. 공유 시간, 수정 횟수, 휴먼에러, 만족도 변화를 측정한다.
6. 효과가 확인되면 이를 리서치 운영 템플릿이나 내부 툴 기능으로 승격한다.

Common Mistakes

• 기능 추가로 문제를 덮고 구조를 다시 보지 않는다.
• 효율화를 거대한 프로젝트로 시작한다.
• 리서치를 후반 검증 단계로만 취급한다.
• 내부 툴과 디자인 시스템을 보조 수단으로 취급한다.
• UX Writing 원칙을 문서로만 남기고 시스템으로 배포하지 않는다.
• 전환 압박형 문구나 과장된 설득으로 신뢰를 깎는다.
• 접근성을 법적 준수나 체크리스트로만 다룬다.
• 브랜드와 인터랙션을 장식적 연출로 소비한다.
• 원문 근거가 필요한데도 일반론으로 뭉개서 답한다.

Reference

• 빠른 적용은 이 파일을 우선 사용한다.
• 세부 근거와 기사별 맥락은 sources/toss-tech-design-summary.md 요약 보존본을 본다.
• 기사 원문 URL, 페이지 흐름, 태그 분포, 추출 한계까지 필요하면 반드시 요약 보존본에서 확인한다.