독자에게 과정을 설명하려고 가상의 사례를 만들 수 있습니다. 문제는 그 예시가 실제 고객의 경험이나 확인된 성과처럼 읽힐 때 생깁니다. 사례를 제시하기 전에 실제 기록을 바탕으로 하는지, 이해를 돕기 위한 가정인지 먼저 표시해야 합니다.
실제 사례라면 공개 동의와 개인정보 보호를 확인합니다. 이름을 지웠더라도 날짜, 지역, 독특한 사건을 조합하면 특정인을 알아볼 수 있습니다. 사진과 대화 인용은 각각 사용 허락이 필요한지 검토하고, 편집으로 결과를 바꿔 보이게 하지 않습니다. 한 사례의 경험을 모든 사람에게 적용되는 규칙으로 일반화하지도 않습니다.
가상의 예시는 '예를 들어' 또는 '가상의 상황'이라고 밝힙니다. 예약 변경 방법을 설명한다면 임의의 날짜와 제품을 사용해 순서를 보여 줄 수 있습니다. 하지만 실제 운영과 다른 예외를 만들어 절차처럼 안내해서는 안 됩니다. 예시 안의 숫자와 조건도 독자가 현재 가격이나 마감 시각으로 오해하지 않게 구분합니다.
본문에서는 예시 전후로 공식 기준을 분명히 합니다. '이 상황에서는 이렇게 진행한다'고 설명한 뒤 실제 신청자는 어떤 정보를 확인해야 하는지 적으면 예시의 범위가 드러납니다. 의료나 법률처럼 개인별 판단이 필요한 분야는 가상의 사례에 확정적인 결론을 붙이지 않습니다.
예시가 여러 글에서 복사되어 쓰인다면 그 예시의 전제가 각 글의 서비스와 맞는지 다시 확인합니다. 단어만 바꾼 같은 이야기는 독자의 이해를 돕지 않습니다.
발행 후에도 예시는 점검해야 합니다. 정책이 바뀌면 실제 사례의 설명이나 가상 절차가 낡을 수 있습니다. 운영자가 예시의 출처와 목적, 수정일을 기록하면 새 담당자가 무엇을 검토해야 하는지 알 수 있습니다.