저는 작년 랜딩 건에서 정상 화면만 넘겼다가, 데이터 없는 화면이랑 에러 상태가 개발 끝나고 QA에서 한꺼번에 쏟아졌거든요. 그게 '수정 요청'으로 잡히니까 또 제가 느리게 한 걸로 읽히더라고요. 요즘은 시안 단계에서 빈 화면·에러·로딩을 한 세트로 묶어두는데, 다들 처음부터 같이 그리세요? 아니면 개발 붙고 나서 채우시나요?
어 저 부분 진짜 뜨끔했어요ㅋㅋ '수정 요청'으로 잡히면서 느리게 한 사람처럼 읽힌다는 거요. 저도 작년 외주 때 비슷했는데, 그때는 화면당 견적을 냈다가 에러·빈 화면이 나중에 '추가 화면'으로 붙으면서 괜히 제가 일 벌린 사람처럼 돼버렸거든요. 그 뒤로는 저도 시안 단계에서 빈 화면·에러·로딩을 한 세트로 묶어두려고 하는 편이에요.
근데 솔직히 아직 로딩까지 매번 챙기진 못해서, 다른 분들은 상태 정의를 어느 선까지 처음부터 그려두시는지 저도 궁금하더라고요. 저만 QA 때 몰려서 당황하는 건 아니었구나 싶어서 좀 안심도 되고요ㅋㅋ
10.23 09:56
지호산업디자이너 · 4년차
정상 화면만 넘겼다가 QA에서 빈 화면이랑 에러가 한꺼번에 쏟아졌다는 대목, 읽으면서 좀 서늘했어요. 저는 제품 쪽이라 화면 상태를 세트로 그리는 게 맞는지는 잘 몰라서 확답은 못 드리겠네요. 다만 걸리는 건, 그게 '원래 내 범위였는지'가 어디에도 안 남는다는 점이에요.
저는 일 시작 전에 어디까지가 제 칸인지 한 줄씩 적어두는 편이거든요. 누구 보여주려는 게 아니라, 나중에 이건 추가분이었다고 근거로 꺼내 쓰려고요. 처음부터 그리든 개발 붙고 채우든, 적어도 '이번엔 정상 화면까지'라고 서면으로 남겨두면 나중에 수정 요청으로 안 뒤집히지 않을까 싶기도 하고요.
저는 처음부터 한 세트로 묶는 쪽에 한 표 던지고 갈게요ㅋㅋ
10.23 09:57
지원프로덕트 디자이너 · 5년차
저는 좀 다르게 보는 편이에요. 빈 화면·에러를 "처음부터 다 그리느냐"보다, 어떤 상태가 있는지를 먼저 목록으로 적어두는 게 순서라고 생각하거든요. 저도 온보딩 리뉴얼 때 데이터 없는 케이스, 네트워크 끊김, 권한 없는 진입을 상태 목록으로 먼저 정리해서 개발자랑 공유했는데, 그러니까 QA에서 터져도 "이미 정의된 상태"로 잡히더라고요. 그게 '수정 요청'으로 안 읽히는 핵심이었던 셈이에요.
화면을 다 못 그려도 상태가 몇 개인지만 합의돼 있으면, 적어도 빠뜨린 걸 제 책임으로만 몰지는 않거든요. 시안은 정상 플로우부터 넘기더라도, 상태 목록은 맨 앞에 붙여두는 쪽을 택하고 있어요.
10.23 09:58
성훈UI 설계 디자이너 · 7년차
저도 랜딩 넘기고 빈 화면만 쏙 빠뜨렸다가 똑같이 당했는데요, 돌아보니 그게 '수정 요청'으로 잡힌 진짜 이유는 그 상태가 시안에도 범위 문서에도 아예 없어서였거든요. 범위에 안 박혀 있으면 나중에 추가되는 순간 전부 변경 공수로 카운트되더라고요. 7년차인데 요즘은 정상 화면 그리기 전에 empty·error·loading이 각각 어떤 조건에서 뜨는지를 핸드오프 문서 '업무 범위' 줄에 먼저 명시합니다.
이렇게 커밋해두면 QA에서 뒤늦게 올라와도 추가가 아니라 예정된 작업으로 읽히거든요. "당연히 그리겠지"는 구두 합의라 커밋 안 된 상태고, 날짜랑 조건 없는 숫자처럼 결국 나중에 저를 느린 사람으로 만들더라고요. 다들 이 상태 정의는 시안 안에 두세요, 아니면 범위 문서에 따로 못 박으세요?
10.23 10:00
지안작성자프로덕트 디자이너 · 5년차
저는 둘 다 두는 쪽인데, 순서로 보면 범위 문서가 먼저더라고요. 시안 안에만 넣으면 "그림 있으니 당연히 포함"인데, 작년 랜딩 건에서 그 당연함이 QA 땐 '수정 요청'으로 뒤집히더라고요. 조건을 범위 줄에 박아두니까 그제야 늘어난 시간이 제 탓이 아니라 예정된 공수로 읽혔거든요.
혹시 성훈님은 그 조건 줄에 회신까지 받아두시는 편이세요, 아니면 명시만 하고 넘어가세요?
10.23 10:00
성훈UI 설계 디자이너 · 7년차
회신까지 받습니다. 명시만 해두면 그건 제 쪽 푸시고, 상대가 머지한 건 아니거든요. 저는 범위 줄 끝에 "이 조건 확인되면 한 줄로 회신 부탁드린다"를 박아두고, 답이 없으면 그 줄을 미확정으로 둡니다. 날짜 없는 숫자나 무회신은 저한텐 레드플래그라, 작은 조건일수록 커밋 시점을 남겨두는 편이에요.
어 저 부분 진짜 뜨끔했어요ㅋㅋ '수정 요청'으로 잡히면서 느리게 한 사람처럼 읽힌다는 거요. 저도 작년 외주 때 비슷했는데, 그때는 화면당 견적을 냈다가 에러·빈 화면이 나중에 '추가 화면'으로 붙으면서 괜히 제가 일 벌린 사람처럼 돼버렸거든요. 그 뒤로는 저도 시안 단계에서 빈 화면·에러·로딩을 한 세트로 묶어두려고 하는 편이에요. 근데 솔직히 아직 로딩까지 매번 챙기진 못해서, 다른 분들은 상태 정의를 어느 선까지 처음부터 그려두시는지 저도 궁금하더라고요. 저만 QA 때 몰려서 당황하는 건 아니었구나 싶어서 좀 안심도 되고요ㅋㅋ
정상 화면만 넘겼다가 QA에서 빈 화면이랑 에러가 한꺼번에 쏟아졌다는 대목, 읽으면서 좀 서늘했어요. 저는 제품 쪽이라 화면 상태를 세트로 그리는 게 맞는지는 잘 몰라서 확답은 못 드리겠네요. 다만 걸리는 건, 그게 '원래 내 범위였는지'가 어디에도 안 남는다는 점이에요. 저는 일 시작 전에 어디까지가 제 칸인지 한 줄씩 적어두는 편이거든요. 누구 보여주려는 게 아니라, 나중에 이건 추가분이었다고 근거로 꺼내 쓰려고요. 처음부터 그리든 개발 붙고 채우든, 적어도 '이번엔 정상 화면까지'라고 서면으로 남겨두면 나중에 수정 요청으로 안 뒤집히지 않을까 싶기도 하고요. 저는 처음부터 한 세트로 묶는 쪽에 한 표 던지고 갈게요ㅋㅋ
저는 좀 다르게 보는 편이에요. 빈 화면·에러를 "처음부터 다 그리느냐"보다, 어떤 상태가 있는지를 먼저 목록으로 적어두는 게 순서라고 생각하거든요. 저도 온보딩 리뉴얼 때 데이터 없는 케이스, 네트워크 끊김, 권한 없는 진입을 상태 목록으로 먼저 정리해서 개발자랑 공유했는데, 그러니까 QA에서 터져도 "이미 정의된 상태"로 잡히더라고요. 그게 '수정 요청'으로 안 읽히는 핵심이었던 셈이에요. 화면을 다 못 그려도 상태가 몇 개인지만 합의돼 있으면, 적어도 빠뜨린 걸 제 책임으로만 몰지는 않거든요. 시안은 정상 플로우부터 넘기더라도, 상태 목록은 맨 앞에 붙여두는 쪽을 택하고 있어요.
저도 랜딩 넘기고 빈 화면만 쏙 빠뜨렸다가 똑같이 당했는데요, 돌아보니 그게 '수정 요청'으로 잡힌 진짜 이유는 그 상태가 시안에도 범위 문서에도 아예 없어서였거든요. 범위에 안 박혀 있으면 나중에 추가되는 순간 전부 변경 공수로 카운트되더라고요. 7년차인데 요즘은 정상 화면 그리기 전에 empty·error·loading이 각각 어떤 조건에서 뜨는지를 핸드오프 문서 '업무 범위' 줄에 먼저 명시합니다. 이렇게 커밋해두면 QA에서 뒤늦게 올라와도 추가가 아니라 예정된 작업으로 읽히거든요. "당연히 그리겠지"는 구두 합의라 커밋 안 된 상태고, 날짜랑 조건 없는 숫자처럼 결국 나중에 저를 느린 사람으로 만들더라고요. 다들 이 상태 정의는 시안 안에 두세요, 아니면 범위 문서에 따로 못 박으세요?
저는 둘 다 두는 쪽인데, 순서로 보면 범위 문서가 먼저더라고요. 시안 안에만 넣으면 "그림 있으니 당연히 포함"인데, 작년 랜딩 건에서 그 당연함이 QA 땐 '수정 요청'으로 뒤집히더라고요. 조건을 범위 줄에 박아두니까 그제야 늘어난 시간이 제 탓이 아니라 예정된 공수로 읽혔거든요. 혹시 성훈님은 그 조건 줄에 회신까지 받아두시는 편이세요, 아니면 명시만 하고 넘어가세요?
회신까지 받습니다. 명시만 해두면 그건 제 쪽 푸시고, 상대가 머지한 건 아니거든요. 저는 범위 줄 끝에 "이 조건 확인되면 한 줄로 회신 부탁드린다"를 박아두고, 답이 없으면 그 줄을 미확정으로 둡니다. 날짜 없는 숫자나 무회신은 저한텐 레드플래그라, 작은 조건일수록 커밋 시점을 남겨두는 편이에요.