이 커뮤니티 콘텐츠의 사례 표시 방법
이 커뮤니티 콘텐츠 묶음에는 미리 준비한 편집 자료와 만든 교육 시나리오가 포함되어 있습니다. 독자가 어디서 만나든 사례의 성격을 명확히 표시해야 합니다. 자발적인 고객 대화나 특정 해석이 실제 결과를 냈다는 증거로 제시해서는 안 됩니다.
아래 표시 방식은 검토용 초안입니다. 공개 결정을 내리기 전에 사례를 어떻게 구별해야 하는지 설명합니다. Mystilink가 커뮤니티 정책으로 채택했다거나 이 글들이 이미 공개됐다는 뜻은 아닙니다.
독자가 보는 것이 무엇인지 표시하기
가상 연습 스레드는 도입부 가까이에 가상 연습이라고 밝혀야 합니다. 제안 기능을 논의하면 제안이라고 쓰세요. 지원 모의 사례라면 가정한 문제임을 밝힙니다. 각 표시는 다른 질문에 답하므로 구체적으로 구별해야 합니다.
예를 들어 학습 연습이라는 제목의 글에 같은 이미지의 두 해석을 비교하는 학습자가 나올 수 있습니다. 도입부는 토론을 위해 만든 상황임을 밝혀야 합니다. 그러면 여러 실사용자가 독립적으로 같은 일을 겪은 듯 보이지 않으면서 답글에서 다른 방법을 제시할 수 있습니다.
제품 주장은 별도로 상태를 표시해야 합니다. 가상 시나리오에서 살펴본 저장소에 있는 기능을 논할 수는 있지만 출시 빌드에서 이용 가능한지까지 확인되지는 않습니다. 둘 다 독자의 이해에 영향을 주면 시나리오와 기능의 상태를 각각 표시하세요.
신원과 목소리를 정직하게 표현하기
준비한 글에 고객 신원, 전문 자격, 개인 이력을 지어내면 안 됩니다. 누구도 제공하지 않은 경험을 주장하지 않고도 대화체로 교육 자료를 읽기 쉽게 만들 수 있습니다. 편집용 질문으로 "이 불확실성을 어떻게 기록하시겠어요?"라고 묻고, 준비된 응답 예임을 명시한 답글을 붙일 수 있습니다.
의견 차이를 보여 주려 여러 목소리를 쓰면 응답 예시라고 설명합니다. 독립적인 고객이 제공한 것처럼 보여서는 안 됩니다. "몇 년째 사용하고 있어요"라는 답은 실제 이력을 주장하므로, 사실이며 이용 허락이 있는 경우가 아니면 삭제해야 합니다.
실명으로 기여자를 표기할 때는 실제로 기여한 작업에만 이름을 붙입니다. AI의 도움과 편집 책임은 팀이 채택하는 공개 규칙을 따라야 합니다. 콘텐츠 묶음 자체가 회사를 대신해 규칙을 정할 수는 없습니다.
토론과 증거 구별하기
만든 스레드는 방법을 가르칠 수 있습니다. 고객 수요, 만족도, 제품 신뢰성을 입증할 수는 없습니다. 가상 지원 사례는 유용한 보고에 어떤 정보가 필요한지 보여 줄 수 있지만 실제 결함 보고로 세어서는 안 됩니다.
준비한 답글의 동의도 커뮤니티가 견해를 공유한다는 증거는 아닙니다. 편집자는 이런 글을 사용자 합의로 요약하지 않아야 합니다. 나중에 실제 응답을 모은다면 출처와 상태를 준비된 예시와 구분해 둡니다.
가상 해석은 카드 순서를 보존하거나 해석의 범위를 한정하는 법을 보여 줄 수 있습니다. 정확한 예측이라고 설명해서는 안 됩니다. 연습에 나중 결과가 포함되면 그 결과도 만든 것이므로 가상 구성의 일부라는 표시를 유지해야 합니다.
복사되어도 표시가 남게 하기
독자는 미리보기, 검색 발췌, 스크린숏, 인용 답글로 스레드를 접하곤 합니다. 핵심 상태는 예시와 함께 옮겨질 가능성이 큰 글에 넣으세요. 긴 페이지 아래 숨긴 표시는 도입부를 공유할 때 사라질 수 있습니다.
지원 모의 사례라면 "가상 문제 해결 연습" 같은 도입으로 목적을 보여 줄 수 있습니다. 답글 발췌에도 "준비된 응답 예시"처럼 짧은 설명이 필요할 수 있습니다. 색이나 작은 아이콘만을 유일한 상태 표시로 쓰지 마세요.
표지와 캡션도 검토합니다. 작업 공간 그림을 실제로 그러한 것이 아닌데 출시 기능의 스크린숏이라고 설명하면 안 됩니다. 제안임을 표시하고 사적 정보를 재현하지 않는 모형 화면은 유용할 수 있습니다.
실제 자료는 별도 절차로 다루기
나중에 실제 회원이 사례를 제공하면 의도한 용도에 필요한 허락을 받고 신원 식별 정보를 점검합니다. 공개 사용자명만으로 자세한 사연을 마케팅 기사에 다시 실을 허락이 생기지는 않습니다.
원래 기여와 편집 변경의 주체가 드러나게 둡니다. 편집자가 줄일 때도 의미에 영향을 주는 한정은 남기세요. 선택적 인용으로 실패한 경험이 호의적인 추천으로 바뀌어서는 안 됩니다.
팀은 기여자가 수정이나 삭제를 요청할 방법도 결정해야 합니다. 이는 절차 요건의 제안이지 특정 채널이나 응답 약속이 이미 있다는 말은 아닙니다. 책임자가 승인하고 운영할 수 있을 때만 그 세부를 공개하세요.
가져오기 전에 표시 검토하기
편집 검토에서는 모든 제목, 도입, 답글, 이미지 캡션에 암묵적인 경험 주장이 있는지 봅니다. 실제 사용, 개인 결과, 집단 동의를 암시하는 표현을 찾으세요. 적절한 가정 표현은 남기고 모호한 부분은 고칩니다.
그다음 몇 예시를 전체 맥락에서 떼어 봅니다. 미리보기 카드, 복사한 답글, 표지 캡션을 각각 읽으세요. 표시 없는 고객 경험담처럼 보이면 가져오거나 공유하기 전에 글을 고칩니다.
표시는 독자가 자료를 어떻게 사용할지 결정하는 데 도움이 되어야 합니다. 가상 사례가 토론할 방법을 보여 주며 고객에게 실제로 일어난 일의 기록은 아님을 이해하면서도 배울 수 있습니다.