파일 권한 요청은 짧은 흐름이지만 신뢰에 큰 영향을 줍니다. 요청자는 무엇을 요청하는지 알아야 하고, 소유자는 판단할 맥락이 필요하며, 승인 전부터 접근할 수 있는 것처럼 보이면 안 됩니다. UX 디자인 협업 환경에서 요청 상태를 정의하고 공개 파일, 요청한 역할, 승인된 역할, 만료·거부된 요청의 경계를 테스트하세요.

접근 요청의 대상을 정확히 이름 붙이기
파일에 여러 역할이 있다면 ‘접근 요청’만으로는 부족합니다. 요청하는 파일이나 워크스페이스, 역할, 필요한 이유를 명시하세요. 뷰어와 편집자는 결과가 다르므로 제출 후 별도 대화상자에 역할을 숨기지 않습니다.
| 요청 상태 | 보여 줄 사실 | 허용할 다음 작업 |
|---|---|---|
| 요청 전 | 현재 접근 권한과 선택 가능한 역할이 분명하다. | 역할을 선택하고 요청을 보낸다. |
| 대기 중 | 요청 역할, 수신자, 전송 시간이 보인다. | 정책이 허용하면 취소하거나 요청을 수정한다. |
| 승인됨 | 부여된 역할과 적용 범위가 명확하다. | 허용된 범위에서 파일을 연다. |
| 거부됨 | 검토자의 비공개 메모를 노출하지 않고 거부를 알린다. | 소유자에게 연락하거나 허용되면 다른 역할을 요청한다. |
| 만료됨 | 이전 요청을 더 이상 실행할 수 없다. | 현재 역할과 이유로 새 요청을 보낸다. |
요청, 알림, 소유자 검토, 결과 배너에서 같은 역할 이름을 사용하세요. 한 화면에서만 ‘편집’을 ‘기여’로 바꾸면 권한이 바뀌었는지 혼란을 줍니다.
제출 전에 범위 보여 주기
요청을 보내기 전에 그 역할로 할 수 있는 일과 없는 일을 보여 주세요. ‘전체 접근’보다 ‘이 파일을 편집할 수 있음’이 구체적입니다. 댓글, 내보내기, 공유가 포함된다면 도움말에 숨기지 말고 결정 화면에서 설명합니다.
- 요청 대상인 파일, 프로젝트, 워크스페이스를 식별한다.
- 현재 접근 권한과 요청 역할을 나란히 보여 준다.
- 누가 요청을 받고 어떤 맥락을 보게 되는지 설명한다.
- 소유자의 판단에 도움이 될 때만 선택적 이유를 받는다.
- 접근 권한이 바뀌었다고 주장하지 않고 요청 전송을 확인한다.
이유는 짧고 작업 중심으로 작성합니다. ‘결제 프로토타입을 검토하고 구현 메모 남기기’가 ‘접근 필요’보다 신호가 큽니다. 모든 검토자가 읽는 입력란에 민감한 정보를 강제로 쓰게 하지 마세요.

소유자가 추적할 수 있는 결정 만들기
소유자 검토 화면은 누가 요청했는지, 무엇을 하려는지, 역할이 어디에 적용되는지 답해야 합니다. 승인과 거부는 요청 옆에 두되, 파일 설정과 같은 다른 변경과 분리하세요. 소유자가 역할을 바꾸면 확인과 알림에 최종 역할을 표시합니다.
| 소유자의 질문 | 보여 줄 근거 | 피할 실패 |
|---|---|---|
| 누가 요청했나? | 정책이 허용하는 이름, 계정, 조직 맥락. | 잘린 라벨만 보고 신원을 모른 채 승인한다. |
| 무엇이 필요한가? | 역할, 파일 범위, 이유. | 파일 작업에 워크스페이스 전체 권한을 부여한다. |
| 다음에 무엇이 일어나나? | 적용 시점, 알림, 되돌릴 수 있는지. | 권한 업데이트가 대기 중인데 성공을 표시한다. |
| 나중에 다시 볼 수 있나? | 결정 기록과 현재 역할. | 요청을 삭제해 감사 흔적을 잃는다. |
경쟁 상태와 반복 요청 다루기
두 소유자가 하나의 요청을 처리하거나 다른 곳에서 권한이 바뀌는 중 요청이 제출될 수 있습니다. 서버의 최신 결정을 기준으로 삼고 충돌을 조용히 덮어쓰지 말고 설명하세요. 요청자가 대기 화면을 보는 동안 승인되면 역할과 상태를 함께 갱신합니다.
오래된 화면에 가두지 않으면서 중복 요청을 막습니다. 대기 중이면 역할과 수신자를 포함한 ‘이미 요청함’을 보여 주고, 취소·거부·만료되었거나 의도적으로 교체된 뒤에만 새 요청을 허용합니다. 뷰어에서 편집자로 바꿀 때 기존 요청을 수정하는지 새 결정을 만드는지 알려 주세요.
거부와 오류 상태에서 개인정보 보호
거부 메시지는 비공개 사유나 관련 없는 파일의 존재를 공개하지 않고 허용된 다음 경로를 설명해야 합니다. ‘소유자가 이 역할을 승인하지 않았습니다’처럼 표현하세요. 계정이 중지되었거나 파일이 삭제되었거나 소유자가 없어서 보낼 수 없다면 입력한 이유를 보존하고 적절한 지원 경로를 제공합니다.
서버가 요청을 수락하기 전에 성공 토스트를 사용하지 마세요. 지원된다면 안정적인 요청 ID와 함께 대기 상태를 표시하고, 결과가 불명확한 동안 같은 요청을 반복 전송하지 못하게 합니다.
역할별 접근 계약 테스트
요청자, 소유자, 기존 협업자의 화면을 행렬로 정리하세요. 뷰어 요청, 편집자 요청, 거부, 만료, 검토 중 역할 변경, 소유자 삭제, 다른 탭에서 받은 권한 업데이트를 테스트합니다. 각 경로에 지금 할 수 있는 일과 다음 결정 뒤의 결과를 적습니다.
Pixso에서 요청자와 소유자 화면을 대기·승인·거부·충돌 경로로 연결하세요. 각 프레임에 역할과 파일 범위를 남겨 시각 스타일뿐 아니라 결정을 비교할 수 있게 합니다. ‘요청 전송’과 ‘접근 권한 부여’를 혼동하기 어려운 프로토타입을 만드세요.
화면이 아닌 동작을 전달하기
최종 프레임에 역할 정의, 상태 전이, 알림 문구, 개인정보 제한, 서버 오류 복구를 기록합니다. 요청 제출, 결정, 접근 사용처럼 안전하게 측정할 이벤트를 정하고 비공개 이유의 본문은 기록하지 않습니다. 모든 전환에서 정확한 설명과 복구 가능한 다음 단계를 남겨야 권한 흐름이 신뢰를 얻습니다.