성공 상태

상태를 그릴 때 실패하는 쪽은 챙기고 성공하는 쪽은 비워 두는 일이 잦았습니다. 로딩 상태와 오류 상태는 시안에 들어가는데, 잘 끝났을 때는 원래 화면으로 돌아가면 된다고 보고 아무것도 그리지 않습니다.

그러면 사용자가 끝났는지 확신하지 못한 채 같은 일을 다시 합니다. 초대 메일을 보내고 화면에 아무 변화가 없으면 버튼을 한 번 더 누르고, 초대받은 사람은 같은 메일을 두 통 받습니다.

비워 둔 자리가 아깝다는 문제도 있습니다. 한 가지를 막 끝낸 사람은 다음 행동을 받아들일 준비가 가장 잘 되어 있는데, 그 자리에 아무것도 없으면 목록으로 돌아가 멈춥니다.

얼마나 크게 알릴지가 먼저입니다. 세 단계로 갈립니다.

1. 짧게 뜨고 사라지는 확인입니다. 3초쯤 떴다 없어지는 알림에 저장했다는 말을 담는 식이고, 놓쳐도 다시 확인할 방법이 있는 결과에 씁니다.
2. 되돌릴 기회를 함께 주는 알림입니다. 문서를 지운 직후에 삭제했다는 말과 실행 취소를 나란히 띄웁니다.
3. 화면 전체를 쓰는 성공 화면입니다. 결제 완료나 가입 완료처럼 한 흐름이 끝나고 다음 흐름으로 넘어가야 하는 자리에 씁니다.

담을 것은 셋입니다. 무엇이 끝났는지를 대상까지 넣어 적고, 결과를 확인할 경로를 주고, 다음 행동 하나를 제안합니다. 저장했다는 말보다 2026 계획을 팀 문서에 저장했다는 말이 낫습니다.

막다른 길로 끝내지 않습니다. 확인 버튼 하나만 있는 성공 화면은 사용자를 그 자리에 세워 두고 다음을 스스로 찾게 만듭니다. 제안할 다음 행동이 없다면 그 흐름의 성공은 전체 화면이 아니라 짧은 알림으로 충분한 경우입니다.

서버 응답을 기다리지 않고 성공을 먼저 보여 주는 옵티미스틱 UI를 쓸 때는 실패했을 때 되돌리는 처리를 함께 만듭니다. 보여 준 성공을 조용히 지우면 사용자는 자기가 한 일이 남았는지 아닌지 모르는 상태가 됩니다.

"초대 보낸 뒤에 아무 표시가 없어서 두 번씩 보내고 있습니다."

성공 상태가 비어 있어 재시도가 생긴다는 보고입니다.

"여기 성공 화면에 다음 행동 하나 넣죠. 공유가 자연스럽습니다."

끝난 자리를 다음 흐름의 입구로 쓰자는 제안입니다.

"저장했다고만 띄우지 말고 어디에 저장됐는지 같이 적어 주세요."

대상을 적어 확인하러 가는 일을 없애자는 요청입니다.

페이지덱의 첫 문서 만들기 흐름에 이 상태가 없었습니다. 문서를 만들면 편집 화면으로 바로 넘어가고 아무 말도 하지 않았습니다. 민서가 만든 직후에 짧은 알림으로 저장 위치를 알리고 그 옆에 공유 버튼을 붙였습니다. 첫 문서를 만든 사람이 그 주에 공유까지 가는 비율이 19퍼센트에서 31퍼센트로 올랐습니다.