作者：Christian Heilmann
编译：庄七
웹 작성은 전문 기술입니다. 종종 사람들이 온라인 기사나 블로그 게시물을 작성할 때 다른 미디어의 규칙을 적용하는 것을 찾게 됩니다. 성공률은 낮습니다.
웹의 텍스트는 고립되어 게시되는 것이 아니라 북마크, 링크 및 참조로 웹 전체에 퍼진다는 점에 유의하세요. 따라서 텍스트를 소화하기 쉽고 인용 가능하며 반복 가능한 덩어리로 분할하고 전체 텍스트 없이도 기사 제목과 파일 제목이 작동하도록 하는 것이 중요합니다.
사실: 이것은 접근성 이점이기도 합니다. 화면 판독기와 같은 보조 기술을 사용하면 문서 전체를 하나의 큰 블록으로 듣는 대신 제목으로 문서를 탐색할 수 있습니다.
간단함은 어리석은 것이 아닙니다
간단한 텍스트를 작성하는 것은 힘든 일입니다. 인상적인 기사를 작성하는 것이 더 쉽습니다. 사람들이 복잡한 단어와 참조를 사용하여 청중에게 인상을 주려고 하는 것을 종종 보게 됩니다. 소설이나 가사를 쓸 때 이것은 좋으며 언어를 가지고 노는 것은 많은 재미가 있습니다. 그러나 웹에서는 특히 개발자 홍보에서 가능한 한 이해하기 쉽게 하는 것이 목표입니다. 간단한 텍스트의 다음 특징을 고려하세요:
-
간단한 용어로 작성하려면 많은 작업과 주제에 대한 철저한 이해가 필요합니다. 간단한 언어로 설명하려면 주제에 익숙해야 합니다. 간단한 언어로 설명할 수 없다면 아마도 당신 자신이 주제를 완전히 마스터하지 못한 것입니다.
-
가능한 한 간단한 용어로 설명하면 가장 넓은 청중층에 도달할 수 있습니다.
-
간단한 어구는 비원어민이 전체 내용을 이해할 기회를 주고 아마도 번역 도구를 사용하여 그것을 유용하게 만들기 위해 시간을 투자할 수 있습니다.
-
짧고 소화하기 쉬운 문장은 읽기 힘들지 않습니다. 처음 보았을 때도 위협적이지 않습니다. 텍스트를 읽기 전에 스캔하는 것은 웹에서 특히 모바일 기기에서 매우 일반적인 패턴입니다.
경고: 그러나 복잡한 것을 간단한 용어로 설명하는 것과 교만하게 들리는 것 사이에는 선이 있습니다. “단순화”의 길을 너무 멀리 가고 있다고 의심된다면 이 문제를 피하기 위해 다른 사람에게 당신의 기사를 보게 하세요. 작성한 내용을 읽고 다시 읽고(중간에 휴식을 취하여) 각 반복마다 더 쉽게 만들어보세요. 실생활의 물체와 시나리오와의 비교는 복잡한 문제를 단순화하는 데 좋습니다.
예: Yahoo의 “Hack Day Open”에서 저는 해커 데이와 오픈 API 개념에 대해 매우 혼란스러워하는 여러 언론인들과 이야기를 나누었습니다. 그 당시에는 이것들이 완전히 새로운 것이었습니다. 저는 이렇게 설명했습니다. “Yahoo가 자동차 회사라면 최신 모델이 여기에서 분해되고 우리는 사람들이 부품을 가지고 노는 것을 허용할 것입니다. 아마 그들은 그것들을 조립하는 멋진 새로운 방법을 찾을 것이고, 그것이 자동차를 더 친환경적이고 효율적으로 만드는 데 필요한 돌파구가 될 것입니다.” *팁**: 온라인으로 작성할 때 저는 자주 사용하는 도구 중 하나가 Hemingway입니다. *hemingwayapp.com에서 시도해볼 수 있습니다. 이것은 텍스트가 필요로 하는 읽기 연령을 나타내는 온라인 편집기입니다. 너무 긴 문장이나 너무 복잡한 단어와 같은 일반적인 문제를 표시합니다.*
간단하고 직접적으로——설탕으로 감싸지 마세요
제목과 소개 텍스트는 블로그의 가장 중요한 부분입니다. 둘 다 향후 이 게시물을 찾기 쉬울 것인지 여부를 결정합니다. 신문은 우리를 캐치프레이즈와 유언을 포함한 재치 있고 재미있는 제목을 쓰도록 훈련시켰습니다. 이것은 재미있지만 이미 신문을 샀다는 것을 알고 읽습니다. 웹 제목은 링크, 북마크 및 소셜 미디어 공유가 됩니다. 따라서 다른 텍스트 없이도 의미가 있어야 합니다. 기술 블로그 게시물의 경우 게시물이 무엇인지 명시하세요——너무 영리해지려고 하지 마세요. 대중 문화 참조는 더 나쁩니다. 왜냐하면 이것들은 다른 문화로 잘 번역되지 않기 때문입니다. 스스로에게 물어보세요: 1분 동안 창의적이고 재치있게 하고 싶습니까, 아니면 몇 달 동안 효과적인 정보를 제공하고 싶습니까?
블로그 게시물은 라디오의 뉴스 항목과 같아야 합니다:
-
모든 블로그의 시작 부분에서 무슨 일이 일어났는지, 어디서 일어났는지, 어떻게 일어났는지 명시하세요.
-
블로그에 있는 내용을 계속 설명하세요.
-
그런 다음 세부 사항으로 들어갑니다.
이것은 혼란을 방지하고 관심 있는 사람들이 더 많은 정보를 얻을 수 있도록 합니다. 소셜 미디어와 모든 곳에서 공유될 때 사람들은 자동화된 방식으로 문서에 링크를 걸고 블로그 제목(HTML의 제목이든 문서의 큰 제목이든)을 사용할 가능성이 높습니다. 제목이 맥락에서 벗어나 의미가 없어 보이면 많은 사람들이 클릭하지 않을 것입니다.
팁: 대부분의 소셜 네트워크에는 링크를 제목과 첫 번째 이미지로 자동 확장하는 링크 미리보기가 있습니다. 이것은 중요하며 활용할 수 있는 강력한 기능입니다. 선택한 소셜 미디어 플랫폼에서 합리적이고 흥미로운 미리보기를 얻기 위해 기사에 필요한 메타 태그를 익히세요.
콘텐츠 길이
온라인 사용을 위한 기술적 글쓰기는 콘텐츠를 짧고 직접적이게 유지하는 것입니다. 사람들은 바쁘고 사실을 알고 싶어합니다.
팁: 좋은 기사를 쓰려면 쓰고, 읽고, 필요 없는 것을 지우고, 다시 읽고, 더 지우고, 반복하세요. 더 이상 지울 수 없을 때 발행 가능한 품질에 도달한 것입니다. 많은 내용을 말해야 한다면 왜 여러 기사로 나누지 않습니까? 이렇게 하면 첫 번째 기사의 끝에서 다음 기사가 며칠 이내에 발행될 것이라고 알릴 수 있으며 블로그에 반복 방문자를 유치할 수 있습니다.
멀티미디어 콘텐츠 추가
가능하다면 블로그에 관련 미디어를 포함하세요. 소개 사진은 눈을 사로잡고 뇌를 유혹하여 무슨 일이 일어났는지 읽게 합니다. 동영상, 오디오 및 슬라이드쇼를 삽입하는 것이 이제 복사 붙여넣기만큼 쉬워졌다는 것은 다행입니다.
멀티미디어를 삽입하면 정보가 소화하기 쉬운 덩어리로 묶입니다. 또한 방문자가 먼저 기사를 스캔하고 나중에 나머지를 읽을(비디오 보기, 팟캐스트 다운로드) 수 있도록 합니다. 또한 읽기가 어렵지만 듣거나 보는 것은 충분히 가능한 사람들을 도울 수 있습니다.
멀티미디어를 삽입할 때 설명 텍스트도 쓰는 것을 잊지 마세요——이미지에는 좋은 대체 텍스트가 필요하고 비디오에는 적어도 표시되는 내용에 대한 설명이 필요합니다.
팁: 텍스트 대체물이나 메모를 제공하면 슬라이드가 훨씬 더 잘 작동합니다. 많은 슬라이드 호스팅 플랫폼이 슬라이드를 위해 HTML 스크립트를 자동으로 생성합니다. 개인적으로 저는 메모로 시작한 다음 이러한 메모를 기반으로 슬라이드를 만들기 때문에 슬라이드에서 링크할 수 있는 HTML 버전이 항상 있습니다.
콘텐츠 구조화
콘텐츠를 구조화하는 것은 매우 중요합니다. 독자가 귀하의 정보를 읽기로 결정하기 전에 기사 구조를 스캔할 수 있는 랜드마크를 제공하는 것은 사람들이 바쁘기 때문에 훌륭합니다.
이것은 계층적 제목 구조를 사용하여 수행합니다. 이것은 또한 화면 판독기와 같은 보조 기술을 사용하는 사람들이 한 섹션에서 다른 섹션으로 빠르게 이동하는 데도 도움이 됩니다. 제목에 ID를 추가하면 사람들이 문서의 특정 부분에 북마크를 추가하고 친구들에게 직접 가고 싶은 곳으로 안내하는 링크를 보낼 수 있습니다.
팁: 제목 개요로 시작하면 훨씬 빨리 작성할 수 있습니다. 기사의 다른 부분을 다른 시간에 작성할 수도 있습니다. 종종 기사의 한 부분에 갇히고 작가 블록에 직면할 때 일시적으로 건너뛰고 더 쉽거나 더 친숙한 다른 부분을 씁니다. 구조화된 기사는 또한 짧은 문장을 사용하는 것을 의미합니다. 한 번에 한 가지 일을 다루는 단락을 의미합니다. 단계별 프로세스를 설명하거나 기존 콘텐츠에 대한 개요를 제공하기 위해 목록을 사용하는 것을 의미합니다. 큰 문서의 경우 사람들이 필요한 곳으로 직접 이동할 수 있는 목차를 제공하는 것도 의미합니다.
콘텐츠에 타임스탬프 추가
“최적 소비 기한”이 지난 음식을 먹으면 아프게 됩니다. 게시물에 타임스탬프를 추가하지 않으면 미래의 기술 기준으로는 해롭더라도 영원히 올바른 것으로 간주됩니다. 그것들은 인용되고——때로는 나쁘게——재인용되고 진실로 받아들여집니다.
예: 제가 웹 개발을 시작했을 때 레이아웃을 위한 테이블은 웹사이트를 구축하는 유일한 방법이었습니다. Netscape3와 IE4 및 기타 “재미있는” 브라우저에서 이러한 테이블을 작동시키려면 많은 트릭을 알아야 했습니다. 저는 이를 어떻게 하는지에 대한 여러 기사를 발표했습니다. 이제 테이블 레이아웃은 웹 개발에 역효과적이며 실제로 렌더링 속도가 더 느립니다. 제 기사에 날짜가 없었다면 사람들은 여전히 관련이 있다고 생각할 수도 있습니다. “CSS 레이아웃은 너무 어렵다”는 모든 기사는 확실히 그렇게 암시합니다. 우리의 기술 환경은 빠른 속도로 발전하고 있습니다. 6개월 전의 “모범 사례”는 이제 “해로운” 것으로 간주될 가능성이 높습니다. 따라서 독자가 문서의 조언을 따르기 전에 문서가 언제 작성되었는지 이제라도 알 수 있도록 하겠습니다.
증명하기 위해 인용
이 섹션의 또 다른 중요한 점은 다른 출처를 인용하고 구축하는 콘텐츠에 링크하는 것입니다. (물론 읽은 후) 다른 출처를 인용함으로써 아이디어와 사실을 검증합니다. 독자들은 당신을 맹목적으로 믿을 필요가 없습니다——비교하여 자신의 결정을 내릴 수 있습니다.
선제적으로 작성
개발자 홍보자로서 기술자와 외부 세계, 그리고 기술자와 자신의 회사 사이의 누락된 연결 고리임을 기억하세요. 이것은 PR을 하는 다른 회사 부서가 수행할 수 없는 작업을 제공합니다. 이를 선제적 글쓰기라고 합니다.
제 말은 제품에 대해 이야기할 때 그것들을 “판매”해서는 안 된다는 것입니다. 대신, 당신의 직무는 개발자들에게 그것들에 대한 관심을 갖게 하고 그들을 당신의 영업 사원으로 만드는 것입니다. 여기의 주요 작업은 일반 판매 피치를 했을 때 받을 피드백을 예상하고 그것이 발생하기 전에 답하는 것——선제적 글쓰기입니다.
설탕으로 감싸거나 부정적인 정보를 숨기려고 하지 마세요：대신 왜 발생하는지, 발생했을 때 무엇을 해야 하는지, 그리고 문제를 해결할 책임이 있는 사람들에게 어떻게 보고해야 하는지를 설명하세요.
사실:* 개발자로서 우리는 몇 년 동안 깨진 약속으로 단단해진 냉소적인 무리입니다. 어떤 제품에 대한 지나친 흥분과 긍정적인 설명은 우리를 “이것을 얻어야 해”라고 생각하게 만들지 않고 오히려 “좋아, 뭐가 문제지?”라는 질문을 유발할 가능성이 더 큽니다.* 이것은 개발자를 사회적으로 부적응한 사람으로 보이게 하며, 클래식한 피치를 하고 부정적인 피드백의 총격을 받는 마케팅이나 PR 담당자에게는 믿을 수 없을 정도로 좌절감을 줄 수 있습니다. 당신의 직무는 이 피드백의 일부를 예상하고 글쓰기에서 그것을 인정함으로써 상황을 진정시키는 것입니다. 이것은 PR 및 마케팅 부서에 대한 어려운 매출이 될 수 있지만, 좋은 점과 나쁜 점에 대해 개방함으로써 미디어에 의해 문맥에서 벗어나 PR 부서에 많은 작업을 주는 많은 혼란스러운 또는 나쁜 피드백을 피할 수 있다고 그들에게 설명할 수 있습니다.
팁: 최근에 PR 부서도 선제적 글쓰기 철학을 채택하기 시작했습니다. 저는 항상 보는 프로세스 중 하나가 다가오는 제품 출시를 위한 “무례한 Q&A”를 만드는 것입니다. 제품 팀은 의도적으로 무례하고 문제가 있는 질문 목록을 만들고 이를 어떻게 처리할지에 대한 워크숍을 개최합니다. 이 질문들이 실제 출시에서 나타나지 않는다면 좋습니다. 그러나 나타난다면 준비가 되어 있습니다. 부정적인 피드백은 많은 경우 몇 가지 범주로 나누어지며, 이 모든 것은 일반적으로 “인터넷 거인” 방식으로 저자를 제시합니다.
사실:* 어떤 사람들은 문제를 일으키거나 “시스템과 싸우기” 위해 부정적인 피드백을 사용하거나 사람들을 불필요하게 토론을 연장하도록 유도하는 트롤이지만 다른 사람들은 반복된 실망으로 인해 무의식적으로 그렇게 합니다. 유지하기 어려운 균형입니다. 진정한 트롤은 단순히 무시하거나 속담처럼 “트롤에게 먹이를 주지 마세요”해야 합니다. 하지만 사람들은 너무 빨리 게시하거나 분노로 인해 “우발적 트롤”이 될 수 있습니다. 부정적인 피드백을 무시하는 것이 유혹적일 수 있지만 때로는 어구가 당신이 해결할 수 있고 해결해야 하는 다른 문제를 암시합니다.* 부정적인 피드백의 몇 가지 범주와 이를 선제적으로 피하는 팁은 다음과 같습니다：
-
이것은 저에게 전혀 작동하지 않습니다：토론 중인 제품이나 데모를 실행하는 데 필요한 환경을 필요한 세부 정보로 정의하세요.
-
이것은 Y 회사의 제품 X와 같습니다：대부분의 경우 이것은 경쟁사 팬입니다. 당신의 제품이 다른 제품과 매우 비슷하다는 점을 언급하고 나열하세요. 둘이 어떻게 다른지 자세히 설명하고 왜 당신의 제품이 단순한 사본이 아니라는 점을 설명하세요. 다른 제품에 대해 알고 있음을 보여줌으로써 과제를 수행했으며 여전히 이야기할 가치가 있다고 생각했음을 증명합니다. 사람들에게 연구를 하지 않았다는 것을 발견하게 하지 마세요.
-
좋지만 저는 절대 사용하지 않을 거예요, 아무도 필요하지 않아요：제품이 어떤 문제를 해결하는지 자세히 설명하세요. 이것이 지금 일반적인 문제가 아니라 미래의 문제라면 사람들이 제품을 어떻게 좋아하는지에 대한 피드백을 요청하세요. 또한 이것은 그들이 이 문제에 직면했을 때 제품이 준비되어 있고 좋다는 것을 보장할 기회라고도 말하세요.
-
당신의 제품 Y가 여전히 망가져 있을 때 왜 이것에 시간을 낭비하고 있습니까?：글쓰기가 기사의 범위를 설정하도록 하세요. 하나의 제품에 대해 자세히 이야기하세요. 운이 좋다면 다른 사람들이 그러한 댓글에 답하고 그것이 주제와 관련이 없음을 지적할 것입니다. 그렇지 않다면 그것이 주제와 관련이 없음을 신속히 답하고 그 사람이 다른 제품에 대한 불만을 털 수 있는 다른 스레드나 토론을 지적하세요.
-
저는 이것을 좋아하지만 테스트할 시간이 없어요：사람들이 간단한 클릭으로 시도할 수 있는 간단한 피드백 메커니즘을 가진 몇 가지 데모와 코드 예제를 준비하고 심지어 간단한 설문조사도 제공하세요.
이들은 전면 공개를 사용하여 나쁜 피드백을 선제적으로 방지하는 방법에 대한 몇 가지 예일 뿐입니다. 더 많은 예가 있지만 이 문제를 다루는 좋은 방법을 찾을 것이라고 확신합니다. 작성한 자료를 잘 보고 나쁜 피드백이 발생하기 전에 예측해 보세요. 더 명확한 정보를 제공함으로써 피할 수 있는 모든 오해는 잠재적으로 또 다른 행복한 고객이 될 수 있습니다.
행동 요청 및 추가 정보
기사를 마쳤을 때 행동 요청으로 끝내는 것이 의미 있습니다. 사용할 리소스, 더 많은 정보를 찾을 수 있는 곳, 그리고 당신이나 작성한 제품 뒤에 있는 팀에 연락하는 방법을 반복해야 합니다.
재인용 출처: 개발자 관계 »
