Resumen ejecutivo

• Un technical writer escribe la documentación que hace usable un producto técnico: guías de usuario, documentación de APIs, manuales y bases de conocimiento.

• Trabaja con Markdown, Git y el enfoque docs-as-code, además de herramientas de referencia de APIs como Swagger/OpenAPI.

• La IA acelera borradores y revisiones, pero el valor del rol está en entender al usuario, verificar y ordenar la información.

• Es una puerta de entrada a tech para perfiles de redacción, docencia, comunicación y soporte técnico.

Si venís de letras, comunicación o docencia, tech puede parecer un mundo exclusivo de programadores. No lo es. Todo producto de software necesita alguien que explique cómo usarlo, y ahí entra el technical writer. Es un rol con poca difusión en español y una salida concreta para quien escribe bien y tiene curiosidad técnica. Tiene parentesco con otro rol de escritura en tech que ya cubrimos: el UX Writer.

Qué documenta un technical writer

• Documentación de APIs: cómo autenticarse, qué endpoints existen, qué parámetros reciben y ejemplos de requests y respuestas.

• Guías de usuario y manuales: cómo hacer cada tarea en el producto, paso a paso.

• Tutoriales y quickstarts: el camino más corto para que alguien logre su primer resultado.

• Bases de conocimiento y centros de ayuda: artículos que responden preguntas frecuentes y bajan tickets de soporte.

• Release notes: qué cambió en cada versión.

• Documentación interna: procesos de ingeniería, arquitectura, onboarding de developers.

La comunidad Write the Docs mantiene una guía abierta de documentación de software con principios, guías de estilo y flujos de trabajo; es la mejor puerta de entrada para entender el oficio.

Las herramientas del rol

Markdown

El formato de texto más usado para documentación técnica: simple, legible y compatible con casi todas las plataformas.

Git y docs-as-code

El enfoque docs-as-code trata la documentación como código: se escribe en Markdown, vive en un repositorio Git, se revisa con pull requests y se publica automáticamente. Como explica Kong en su guía de docs-as-code, esto permite que developers y writers colaboren con el mismo flujo de trabajo. Herramientas típicas: Docusaurus, MkDocs, GitBook.

Swagger / OpenAPI

El estándar para describir APIs REST. El writer no siempre escribe la especificación, pero sí la lee, la mejora y la complementa con guías.

Otras

Herramientas de capturas y GIFs, linters de estilo como Vale, plataformas de help center (Zendesk, Intercom) y, cada vez más, asistentes de IA.

Cómo usa la IA un technical writer

• Primeros borradores: a partir de una spec o del código, la IA arma una estructura inicial.

• Revisión de estilo: consistencia de términos, voz activa, frases más cortas.

• Ejemplos de código: generar variantes en distintos lenguajes (siempre probándolas).

• Traducción y localización: primer pase que después se revisa.

Lo que no delega: probar cada paso en el producto real, decidir qué necesita el usuario y detectar lo que falta. Una doc con un paso equivocado es peor que no tener doc.

Cómo entrar al rol según de dónde venís

Desde la redacción o el periodismo

Ya tenés la escritura clara. Te falta base técnica: aprendé Markdown, Git y lo básico de cómo funciona una API. Elegí un proyecto open source con documentación floja y mejorala con un pull request.

Desde la docencia

Sabés explicar paso a paso y anticipar dudas: es la mitad del trabajo. Armá un tutorial de una herramienta que uses (por ejemplo, cómo automatizar un formulario de Google) con capturas y ejercicios.

Desde el soporte técnico

Conocés los problemas reales de los usuarios mejor que nadie. Proponé artículos de ayuda para los tickets más repetidos de tu empresa: es la transición interna más natural. Los perfiles de soporte también suelen pasar a testing; lo explicamos en QA Tester: qué hace y cómo entrar.

Qué poner en tu portfolio

• Un quickstart de una API pública (por ejemplo, la de un servicio de clima) con ejemplos probados.

• Una guía de usuario de una app conocida, reescrita con mejor estructura.

• Un pull request de documentación en un proyecto open source.

• Todo publicado en GitHub, con buena presentación: te ayuda esta guía de proyectos de GitHub que consiguen trabajo.

Un día típico (y qué se mide)

Un technical writer puede pasar la mañana en una reunión con producto e ingeniería para entender un cambio de API, la tarde escribiendo el quickstart y corriendo los pasos en un entorno de prueba, y el final del día abriendo un pull request. Lo que se mide suele ser: cobertura de features documentadas, tickets de soporte evitados, tiempo hasta el “first success” de un usuario nuevo y calidad de la doc (feedback, páginas vistas, búsquedas sin resultado).

Si venís de soporte, pedí acceso a las métricas de tickets: es el mejor argumento para priorizar qué documentar primero.

Cursos recomendados de Coderhouse

Para la escritura orientada a producto, el Curso de UX Writing te da criterio de microcopy, voz y tono, muy cercano a la documentación de usuario. Para fortalecer la claridad y la estructura de cualquier texto, sumá el Curso de Copywriting.

CTA: elegí una herramienta que uses todos los días y escribí su quickstart en Markdown, publicalo en GitHub y pedile a alguien que lo siga sin ayuda. Si querés pulir tu escritura para producto, mirá UX Writing en Coderhouse.

Preguntas frecuentes

¿Necesito saber programar para ser technical writer? No para empezar, pero sí entender conceptos técnicos básicos (qué es una API, cómo funciona Git) y poder leer código simple.

¿Qué diferencia hay entre technical writer y UX writer? El UX writer escribe los textos dentro del producto (botones, mensajes); el technical writer escribe la documentación sobre cómo usarlo.

¿Se trabaja en inglés? Muchas veces sí, sobre todo en empresas de producto o remotas para el exterior. Un buen nivel de inglés escrito amplía mucho las oportunidades.

¿La IA va a reemplazar a los technical writers? Cambia el trabajo: menos tipeo y más verificación, estructura y criterio. Quien sepa usar IA y validar su resultado va a tener ventaja.