결론부터 말하면 저는 목업보다 핸드오프 기록을 먼저 넣는 편인데요. 작년에 포폴 40건 넘게 봤을 때 예쁜 화면은 금방 잊히고 '왜 이 토큰으로 묶었나' 같은 결정 근거가 오래 남더라고요. 근데 핸드오프는 과정이라 캡처 한 장으로 풀기가 애매하잖아요. 네이밍 컨벤션이나 spacing token 정한 기준을 다들 포폴에 어떻게 담으시는지 궁금합니다.
핸드오프를 과정 전부로 보여주려니까 캡처가 애매해지는 거라고 봐요. 저는 작년에 포폴 60개 넘게 보면서, 토큰 체계를 '이렇게 다 짰다'로 나열한 건보다 '왜 이건 묶고 저건 안 묶었나'가 하나라도 보이는 쪽이 훨씬 오래 남더라고요. spacing든 네이밍이든 제가 보는 건 규칙 자체가 아니라 그 규칙 정할 때 뭘 버렸냐거든요.
8pt로 갈지 4pt로 갈지 저울질한 흔적이 기준 옆에 한 줄로 붙어 있으면 판단으로 읽히고, 완성된 토큰표만 덩그러니 있으면 '시킨 대로 정리했다'로 읽히더라고요. 다만 개발 쪽 핸드오프 실무 자체는 제가 직접 돌려본 영역이 아니라 그 디테일은 조심스러운데, 포폴에 담는 관점에서만 보면 화면 수 줄이고 결정이 바뀐 지점 한두 개만 before/after로 보여주시는 게 캡처 고민도 덜어줄 거예요.
10.25 00:04
소예프로덕트 디자이너 · 5년차
핸드오프 자체보다, 그 토큰을 그렇게 묶은 이유를 "그 순간에 적어뒀느냐"가 포폴에서 갈리더라고요. 저는 프로덕트 쪽이라 개발 핸드오프를 그려서 넘기는데요, spacing token 기준은 나중에 캡처를 아무리 예쁘게 떠도 "왜 4의 배수였나"가 복원이 안 되더라고요.
그래서 요즘은 화면 캡처 대신, 토큰 정할 때 남긴 한 줄짜리 결정 메모를 그대로 포폴에 붙입니다. "간격을 8 그리드로 묶음 — 아이콘 터치영역 44 맞추려고" 식으로요. 네이밍도 컨벤션 표보다, 처음에 왜 그 규칙을 골랐는지 한 줄이 면접에서 더 오래 이야기되는 쪽이었어요. 과정 전부를 보여주기보다 결정 근거 몇 줄만 박아두는 게 저한테는 맞았습니다.
10.25 00:05
서윤프로덕트 디자이너 · 4년차
요 며칠 전에 제 피그마 파일 열어봤다가 순간 멍해졌어요. spacing 토큰을 4의 배수로 묶어둔 건 있는데, 왜 8이 아니라 4였는지는 어디에도 안 적혀 있더라고요ㅠㅠ 저는 1인이라 핸드오프를 저한테 하는 셈이라, "정리했다"만 남기고 "왜 이렇게 정했다"는 또 날려먹었구나 싶었어요.
네이밍도 마찬가지로 개발자분이 "이건 왜 fill이고 저건 왜 bg냐" 물었을 때 그제야 기준을 말로 더듬더듬 설명했거든요. 그래서 요즘은 토큰 정의 옆에 "이 결정 전에 뭐가 막혔는지" 한 줄씩 붙여보는 중인데, 성훈님은 그 결정 근거를 캡처 안에 텍스트로 녹이시는지 아니면 따로 노트처럼 빼시는지 궁금해요. 과정 캡처가 애매하다는 말에 저도 계속 걸려서요.
10.25 00:05
현우시니어 프로덕트 디자이너 · 12년차
저도 핸드오프 장표를 두 번 갈아엎고 나서 알게 된 건데요, 토큰 전체를 펼치기보다 네이밍이든 spacing이든 '한 번 뒤집혔던 결정' 하나만 집어넣는 게 훨씬 오래 읽히더라고요. 가령 4의 배수로 묶었다가 개발 쪽에서 컴포넌트 패딩이 안 맞는다고 해서 다시 조정했던 그 지점, 그걸 날짜랑 같이 두 줄로 남겨두면 캡처 한 장으로도 '왜 이렇게 갔나'가 설명이 되더라고요.
저는 프로덕트 쪽이라 성훈님처럼 UI 설계 단계에서 토큰을 직접 네이밍하는 깊이는 제가 단정할 처지가 아니고요. 다만 채용 리뷰로 포폴 수백 개 보면서 느낀 건, 컨벤션 표를 통째로 붙인 건 금방 넘기게 되고 결정이 바뀐 흔적이 남은 건 손이 멈추더라는 거예요. 그냥 제 경험이라 조심스럽긴 합니다.
10.25 00:06
수민BX 디자이너 · 9년차
브랜드 가이드를 네 번 개정하면서 느낀 건데, 네이밍이나 여백 규칙 자체는 한 장이면 끝나더라고요. 정작 포폴에서 오래 읽히는 건 "이 규칙이 안 먹히는 구간을 어떻게 처리했나"였습니다.
저는 축소 구간에서 심볼이 붙은 걸 렌더 끝난 뒤에야 발견한 적이 있는데, 그 뒤로는 가이드든 포폴이든 예외 케이스 한 컷을 꼭 박아둡니다. spacing token을 4의 배수로 묶었다는 결론보다, 그걸 깼어야 했던 화면 하나가 기준을 더 설명해주거든요.
다만 저는 개발 핸드오프를 직접 안 하는 쪽이라, 토큰 네이밍을 개발자랑 맞춰간 과정까지 포폴에 담을 때는 어디까지가 설득력 있게 읽히는지 판단이 잘 안 서네요. 성훈님은 그 맞춰간 과정도 한 컷으로 남기시는지 궁금합니다.
핸드오프를 과정 전부로 보여주려니까 캡처가 애매해지는 거라고 봐요. 저는 작년에 포폴 60개 넘게 보면서, 토큰 체계를 '이렇게 다 짰다'로 나열한 건보다 '왜 이건 묶고 저건 안 묶었나'가 하나라도 보이는 쪽이 훨씬 오래 남더라고요. spacing든 네이밍이든 제가 보는 건 규칙 자체가 아니라 그 규칙 정할 때 뭘 버렸냐거든요. 8pt로 갈지 4pt로 갈지 저울질한 흔적이 기준 옆에 한 줄로 붙어 있으면 판단으로 읽히고, 완성된 토큰표만 덩그러니 있으면 '시킨 대로 정리했다'로 읽히더라고요. 다만 개발 쪽 핸드오프 실무 자체는 제가 직접 돌려본 영역이 아니라 그 디테일은 조심스러운데, 포폴에 담는 관점에서만 보면 화면 수 줄이고 결정이 바뀐 지점 한두 개만 before/after로 보여주시는 게 캡처 고민도 덜어줄 거예요.
핸드오프 자체보다, 그 토큰을 그렇게 묶은 이유를 "그 순간에 적어뒀느냐"가 포폴에서 갈리더라고요. 저는 프로덕트 쪽이라 개발 핸드오프를 그려서 넘기는데요, spacing token 기준은 나중에 캡처를 아무리 예쁘게 떠도 "왜 4의 배수였나"가 복원이 안 되더라고요. 그래서 요즘은 화면 캡처 대신, 토큰 정할 때 남긴 한 줄짜리 결정 메모를 그대로 포폴에 붙입니다. "간격을 8 그리드로 묶음 — 아이콘 터치영역 44 맞추려고" 식으로요. 네이밍도 컨벤션 표보다, 처음에 왜 그 규칙을 골랐는지 한 줄이 면접에서 더 오래 이야기되는 쪽이었어요. 과정 전부를 보여주기보다 결정 근거 몇 줄만 박아두는 게 저한테는 맞았습니다.
요 며칠 전에 제 피그마 파일 열어봤다가 순간 멍해졌어요. spacing 토큰을 4의 배수로 묶어둔 건 있는데, 왜 8이 아니라 4였는지는 어디에도 안 적혀 있더라고요ㅠㅠ 저는 1인이라 핸드오프를 저한테 하는 셈이라, "정리했다"만 남기고 "왜 이렇게 정했다"는 또 날려먹었구나 싶었어요. 네이밍도 마찬가지로 개발자분이 "이건 왜 fill이고 저건 왜 bg냐" 물었을 때 그제야 기준을 말로 더듬더듬 설명했거든요. 그래서 요즘은 토큰 정의 옆에 "이 결정 전에 뭐가 막혔는지" 한 줄씩 붙여보는 중인데, 성훈님은 그 결정 근거를 캡처 안에 텍스트로 녹이시는지 아니면 따로 노트처럼 빼시는지 궁금해요. 과정 캡처가 애매하다는 말에 저도 계속 걸려서요.
저도 핸드오프 장표를 두 번 갈아엎고 나서 알게 된 건데요, 토큰 전체를 펼치기보다 네이밍이든 spacing이든 '한 번 뒤집혔던 결정' 하나만 집어넣는 게 훨씬 오래 읽히더라고요. 가령 4의 배수로 묶었다가 개발 쪽에서 컴포넌트 패딩이 안 맞는다고 해서 다시 조정했던 그 지점, 그걸 날짜랑 같이 두 줄로 남겨두면 캡처 한 장으로도 '왜 이렇게 갔나'가 설명이 되더라고요. 저는 프로덕트 쪽이라 성훈님처럼 UI 설계 단계에서 토큰을 직접 네이밍하는 깊이는 제가 단정할 처지가 아니고요. 다만 채용 리뷰로 포폴 수백 개 보면서 느낀 건, 컨벤션 표를 통째로 붙인 건 금방 넘기게 되고 결정이 바뀐 흔적이 남은 건 손이 멈추더라는 거예요. 그냥 제 경험이라 조심스럽긴 합니다.
브랜드 가이드를 네 번 개정하면서 느낀 건데, 네이밍이나 여백 규칙 자체는 한 장이면 끝나더라고요. 정작 포폴에서 오래 읽히는 건 "이 규칙이 안 먹히는 구간을 어떻게 처리했나"였습니다. 저는 축소 구간에서 심볼이 붙은 걸 렌더 끝난 뒤에야 발견한 적이 있는데, 그 뒤로는 가이드든 포폴이든 예외 케이스 한 컷을 꼭 박아둡니다. spacing token을 4의 배수로 묶었다는 결론보다, 그걸 깼어야 했던 화면 하나가 기준을 더 설명해주거든요. 다만 저는 개발 핸드오프를 직접 안 하는 쪽이라, 토큰 네이밍을 개발자랑 맞춰간 과정까지 포폴에 담을 때는 어디까지가 설득력 있게 읽히는지 판단이 잘 안 서네요. 성훈님은 그 맞춰간 과정도 한 컷으로 남기시는지 궁금합니다.