문구 문제인지 흐름 문제인지부터 정합니다. 파일은 그다음에 엽니다.
리뷰에서 나온 한 문장
“좀 더 직관적으로 갔으면 좋겠고, 톤도 우리 같지 않아요 — 2번 스텝만 간단하게 안 될까요?”
디자인 리뷰 14분 지점 · 들은 그대로 붙여넣었습니다
온보딩 2번 스텝, 버튼 하나만 남깁니다. 담당은 디자인, 오늘 안에.
#142 · 2번 스텝까지만 손댑니다. 전체 개편은 4분기로 미뤘습니다.
기록이 쌓이면 내가 어떻게 판단하는지까지 배웁니다.
제품 화면
회의에서 나온 말이 19초 뒤에 이렇게 남습니다.
지난 리뷰에서 나온 말을 그대로 붙여넣기만 하면 됩니다. 정리는 D:bo가 합니다.
정리 완료 · 0:19기록 #142
기준
‘직관적으로’가 문구 문제인지 흐름 문제인지부터 정합니다. 2번 스텝은 그 다음입니다.
액션
온보딩 2번 스텝 — 주요 동작 하나로 줄입니다. 담당: 디자인, 오늘.
기록
범위는 2번 스텝까지. 전체 개편은 4분기 리서치로 보류.
이후 3회 재사용회의 메모든 Figma 코멘트든 클라이언트 메일이든 상관없습니다. 돌아오는 형태는 같습니다.
회의에 봇을 부르지 않습니다붙여넣기만 하면 됩니다스프린트가 끝나도 기록은 남습니다
개인화
기록만 쌓이는 게 아닙니다. 내가 판단하는 방식을 배웁니다.
처음에는 누구나 공통 기준으로 시작합니다. 판단이 쌓이면 그 자리를 내 기준이 채웁니다.
- 판단 20건, 2~3주쯤이 분기점입니다. 이때부터 근거의 절반이 내가 내린 판단에서 나옵니다.
- 나머지 절반은 계속 공통 기준입니다. 접근성처럼 누구에게나 통하는 원칙이 있어서 0까지 내려가지 않습니다.
3인 팀이 9주 동안 내부에서 쓰며 측정한 값입니다. 외부 코호트 검증은 2026년 9월에 시작합니다.
누적 판단 건수공통 기본값에서 나온 근거
- 0첫날에는 근거가 전부 공통 기본값입니다.
- 20근거의 절반이 내 기준으로 넘어옵니다.
- 30이 지점에서 멈춥니다. 공통 원칙은 공통으로 남습니다.
회의록으로는 안 되는 이유
회의록에는 말만 남습니다. 결정은 남지 않습니다.
무슨 말이 오갔는지는 잘 적힙니다. 그런데 무엇을 고칠지는 아무도 적어두지 않습니다.
피드백 · 회의록만 있을 때
‘좀 더 직관적으로’가 그대로 적혀 있습니다. 그걸 보고 움직일 수 있는 사람은 없습니다.
피드백 · D:bo가 있을 때
문제 제기인지 취향인지 갈라줍니다. 먼저 확인할 기준도 같이 나옵니다.
수정 범위 · 회의록만 있을 때
전체를 갈아엎는 건지 화면 하나만 고치는 건지 적혀 있지 않습니다. 결국 회의를 또 잡습니다.
수정 범위 · D:bo가 있을 때
무엇을 반영하고 무엇을 미룰지 작업 전에 적힙니다.
결정 이유 · 회의록만 있을 때
며칠만 지나도 왜 그렇게 정했는지 아무도 기억하지 못합니다.
결정 이유 · D:bo가 있을 때
그때의 이유가 남아서 다음 회의에서 바로 꺼내 씁니다.
2주 차
같은 말을 두 번째 들으면, 이미 정해둔 답이 나옵니다.
비슷한 피드백이 들어오면 지난번 결론부터 꺼내줍니다. 논의가 0에서 시작하지 않습니다.
두 번째부터가 진짜입니다. 같은 걸 다시 정하지 않게 되고, 그만큼의 시간이 작업으로 돌아옵니다.
지금 참고되는 결정 기록
‘직관적으로’는 문구가 아니라 흐름 문제 — 온보딩에서 두 번 확인함.#142 · 3회 재사용
이 클라이언트에게 프리미엄은 장식이 아니라 여백과 절제.#131 · 2회 재사용
톤 관련 지적은 반증 전까지 문구 문제로 본다. 팔레트는 유지.#118 · 4회 재사용
무엇을 판단하나
파일을 열기 전에, D:bo가 먼저 판단하는 네 가지.
코멘트 하나든 40분짜리 회의든 같은 기준으로 읽습니다.
- 01
문제인가, 취향인가
고쳐야 하는 것과 그냥 그렇게 하고 싶은 것을 갈라냅니다.
문제만 일이 됩니다. - 02
이건 누가 정할 일인가
누구의 판단이 필요한지, 잘못 갔을 때 무엇을 잃는지 짚습니다.
누구에게 물어야 할지 헤매지 않습니다. - 03
무엇부터 정해야 하는가
작업이 시작되기 전에, 열어두면 흔들릴 질문 하나를 앞에 놓습니다.
바로 움직일 수 있는 기준 한 문장. - 04
왜 그렇게 정했는가
결과만이 아니라 그렇게 정한 이유를 남기고, 다음에 다시 꺼내 읽습니다.
다음 판단이 여기서 시작합니다.
베타
내가 판단하는 방식을 가르쳐 보세요.
이번 라운드는 디자이너 개인을 위한 자리입니다. 내가 어떻게 판단하는지를 D:bo에 가르치고, 나와 같은 결론을 내는지 확인해보는 과정입니다.
이런 분을 찾습니다
디자이너 한 명이면 됩니다. 프로덕트, UX, 브랜드, 프리랜서 모두 좋습니다. 팀의 허락을 받을 필요도 없습니다.
참여하면 받는 것
- 일반 모델이 아니라 내 판단을 학습한 에이전트
- 내 기준이 실제로 얼마나 일관적인지 확인
- 베타 기간 무상 사용, 끝나면 쌓인 기록 전부
저희가 부탁드리는 것
- 2주 동안 실제 업무에서 판단 열 건 정도
- 에이전트가 나와 다르게 판단한 지점 알려주기
- 일정이 되면 마지막에 짧은 인터뷰 한 번
얼리 테스터 신청 →
구글폼으로 연결됩니다. 10분 정도 걸리고, 신청은 계속 받고 있습니다. 확인 후 개별로 연락드립니다.
자주 묻는 질문
궁금한 것부터 풀고 가세요.
D:bo는 정확히 무엇인가요?
디자인 팀의 판단을 기록해두는 도구입니다. 리뷰나 Figma, 클라이언트 메일에서 나온 말을 붙여넣으면 판단 기준과 할 일, 그렇게 정한 이유를 정리해서 돌려줍니다.
할 일 관리 도구와 무엇이 다른가요?
할 일 앱은 작업만 남깁니다. D:bo는 그 작업을 왜 그렇게 하기로 했는지를 남깁니다. 먼저 정해야 했던 것, 일부러 미룬 것, 시작할 때까지 답이 없던 질문이 함께 기록됩니다.
어떤 피드백을 넣을 수 있나요?
정리하지 않은 텍스트를 그대로 넣으면 됩니다. 회의 메모, Figma 코멘트, 메신저, 클라이언트 요청 다 됩니다. 원문은 결정 옆에 그대로 남습니다.
도입 전에 테스트해볼 수 있나요?
지난 리뷰에서 나온 피드백 다섯 개만 넣어보세요. D:bo가 잡아낸 기준이 팀이 회의에서 도달했을 기준과 같은지 보면 판단이 섭니다.
제 판단 기준을 어떻게 학습하나요?
기록한 판단이 다음 판단의 근거가 됩니다. 처음에는 공통 기본값에 기대지만 기록이 쌓이면 팀의 기준이 그 자리를 대신합니다. 판단 20건, 2~3주쯤이면 근거의 절반이 팀에서 나옵니다.
저희 데이터는 어떻게 되나요?
입력한 데이터는 고객 소유입니다. 조직별로 나눠서 저장하고, 삭제를 요청하시면 학습된 페르소나에서 그만큼도 함께 지웁니다.