Redacción técnica que la gente puede seguir de verdad
Gjethe escribe documentación técnica para software, productos y procesos internos: guías de usuario, artículos de centros de ayuda, referencias de API y guías para desarrolladores, documentación de incorporación, notas de versión, procedimientos operativos estándar y bases de conocimiento. Nuestros redactores trabajan junto a los desarrolladores, prueban lo que documentan y publican en herramientas como GitBook, Docusaurus, Mintlify, Notion, Confluence o su servicio de atención, en inglés, albanés o alemán.
- Primera consulta gratuita
- Presupuesto por escrito para su proyecto
- Pagos fraccionados por hitos, con flexibilidad
De un vistazo
- Types
- Guías de usuario, documentación de API, centros de ayuda, SOP
- Platforms
- GitBook, Docusaurus, Mintlify, Notion, Confluence
- Formats
- Markdown, MDX, OpenAPI, HTML
- Idiomas
- Inglés, albanés, alemán
Definition
Qué es la redacción técnica?
La redacción técnica es el oficio de explicar cómo funciona algo o cómo hacer algo, con claridad y exactitud, para un lector concreto como un cliente, un desarrollador o un empleado.
La documentación es parte del producto. Cuando falta o es errónea, los clientes abren tickets de soporte, los desarrolladores abandonan su API y los nuevos empleados hacen las mismas preguntas cada semana. Una buena documentación se escribe para un lector a la vez, se prueba con el producto real y se mantiene actualizada a medida que cambia el producto.
¿Para quién es?
Empresas SaaS
Centros de ayuda y guías de incorporación que reducen los tickets de soporte y aceleran la adopción.
Productos de API y para desarrolladores
Referencias y guías que permiten a los desarrolladores integrarse sin escribirle.
Empresas de hardware e industriales
Manuales, guías de puesta en marcha y procedimientos de mantenimiento que se pueden seguir con seguridad.
Equipos en crecimiento
Procedimientos internos y documentos de incorporación que preservan cómo se hace el trabajo.
Qué está incluido y qué se queda usted
Qué incluye
- Auditoría de la documentación y análisis de carencias
- Arquitectura de la información y navegación
- Guías de usuario y artículos prácticos
- Artículos de centros de ayuda
- Referencia de API a partir de su OpenAPI o de su código
- Guías de inicio rápido y tutoriales para desarrolladores
- Notas de versión y registros de cambios
- Procedimientos operativos estándar
- Capturas de pantalla, imágenes anotadas y diagramas sencillos
- Guía de estilo y plantillas para futura documentación
Lo que recibe
Se entrega al final. Suyo para siempre.
- Documentación publicada en su plataforma
- Archivos fuente en Markdown o MDX en su repositorio
- Una guía de estilo de la documentación
- Plantillas para nuevos artículos
- Una lista de mantenimiento ligada a su proceso de publicación de versiones
¿Qué documentación necesita?
| Lector | Qué necesitan | Formato típico |
|---|---|---|
| Cliente nuevo | Ponerse en marcha y llegar al primer resultado | Guía de primeros pasos |
| Cliente existente | Hacer una tarea concreta | Artículos de ayuda basados en tareas |
| Desarrollador | Integrar rápido y gestionar los errores | Referencia de API y guía de inicio rápido |
| Administrator | Configurar, proteger y gestionar | Guía de administración |
| Empleado | Hacer un proceso siempre de la misma manera | Procedimiento operativo estándar |
Probamos lo que documentamos
La forma más rápida de encontrar lagunas en la documentación es seguirla. Nuestros redactores recorren cada guía en una cuenta de prueba o sandbox, anotan dónde difieren el producto y las instrucciones y plantean preguntas a sus desarrolladores antes de publicar.
Para las API, llamamos a los endpoints, comprobamos los ejemplos de solicitudes y respuestas y nos aseguramos de que se explican los mensajes de error. Los ejemplos que no funcionan son una de las principales razones por las que los desarrolladores abandonan una integración.
Documentación como código
Para los productos de desarrolladores, la documentación suele vivir mejor junto al código: Markdown o MDX en su repositorio, revisado en pull requests y publicado automáticamente con herramientas como Docusaurus, Mintlify o GitBook. Así los documentos llevan versiones junto con el producto y las actualizaciones forman parte de cada publicación.
Para los centros de ayuda al cliente, la propia plataforma del servicio de atención suele ser el lugar adecuado, de modo que los artículos puedan enlazarse desde las respuestas de soporte y buscarse desde el producto.
Documentación que los asistentes de IA pueden leer
Los clientes preguntan cada vez más a ChatGPT, a Claude o a su propio bot de soporte cómo usar su producto. Unos encabezados claros, una tarea por artículo, requisitos previos explícitos y ejemplos exactos hacen la documentación más fácil de citar correctamente para estas herramientas. También podemos publicar un índice llms.txt de sus documentos para que las herramientas de IA encuentren las páginas adecuadas.
Señales de que su documentación necesita trabajo
- Soporte responde cada semana las mismas preguntas de cómo hacer algo
- Las capturas de pantalla muestran una versión antigua del producto
- Los desarrolladores piden ejemplos en las llamadas comerciales
- Los nuevos empleados aprenden los procesos preguntando por ahí
- Nadie es responsable de actualizar la documentación tras una publicación
- La búsqueda en su centro de ayuda rara vez encuentra la respuesta
Notas de versión que los clientes leen
Las notas de versión suelen escribirse para el equipo que construyó la función. Los clientes quieren saber qué ha cambiado para ellos, si tienen que hacer algo y dónde aprender más. Escribimos notas de versión que empiezan por el beneficio, explican cualquier acción necesaria y enlazan al artículo de ayuda actualizado.
Para los productos de desarrolladores, mantenemos además un registro de cambios preciso: versiones, cambios que rompen compatibilidad, funciones obsoletas y pasos de migración, para que los integradores puedan actualizar sin sorpresas.
Cómo funciona la redacción técnica, paso a paso
Cada paso tiene un resultado claro que puede revisar. Los plazos se acuerdan en su presupuesto.
- 1
Audit
Revisamos la documentación existente, los tickets de soporte y las analíticas para encontrar lagunas.
- 2
Estructura
Lectores, temas y navegación acordados antes de escribir.
- 3
Escribir y probar
Borradores escritos siguiendo cada paso en el producto.
- 4
Revisión
Revisión técnica por su equipo y edición después para dar claridad.
- 5
Publicar
Publicada en su plataforma con plantillas para futuros artículos.
- 6
Mantener
Actualizaciones opcionales ligadas a su proceso de publicación de versiones.
Herramientas y qué determina su presupuesto
El precio depende de su proyecto y se acuerda en su presupuesto. Esto es lo que lo hace variar.
| Factor | Por qué importa |
|---|---|
| Número de artículos o páginas | Más temas significan más investigación, redacción y revisión. |
| Profundidad técnica | La documentación de API y para desarrolladores necesita más pruebas que las guías de usuario. |
| Acceso a expertos | Las respuestas rápidas de su equipo mantienen eficiente el trabajo. |
| Visuals | Las capturas de pantalla, las imágenes anotadas y los diagramas añaden tiempo de producción. |
| Idiomas | Cada idioma adicional necesita traducción y revisión. |
| Configuración de la plataforma | Configurar una nueva plataforma de documentación añade trabajo inicial. |
| Área | Tools |
|---|---|
| Plataformas de documentación | GitBook, Docusaurus, Mintlify, ReadMe, Confluence, Notion |
| Centros de ayuda | Zendesk Guide, Intercom Articles, Help Scout Docs, HubSpot Knowledge Base |
| API | OpenAPI, Postman, Swagger UI, Redoc |
| Visuals | Snagit, Figma, Excalidraw, Mermaid |
Errores habituales que evitar
Lo que vemos fallar con más frecuencia y cómo lo evita un buen proyecto.
Escribir para todos a la vez
Una página para principiantes y expertos no sirve a ninguno. Escriba para un lector por página.
Documentar funciones en lugar de tareas
La gente llega con una tarea que hacer. Organice en torno a lo que quiere lograr.
Ejemplos que no funcionan
Los fragmentos de código rotos destruyen la confianza más rápido que la falta de documentación.
Sin responsable tras el lanzamiento
La documentación se queda obsoleta en pocas versiones a menos que actualizarla forme parte de la publicación.
Preguntas frecuentes
¿Entienden sus redactores los productos técnicos?
Sí. Nuestros redactores trabajan con desarrolladores a diario, leen código y API y prueban lo que documentan en el propio producto.
¿Pueden escribir documentación de API a partir de nuestro archivo OpenAPI?
Sí. Usamos su especificación OpenAPI como fuente de la referencia y añadimos en torno a ella guías, ejemplos y explicaciones de los errores.
¿En qué plataformas publican?
GitBook, Docusaurus, Mintlify, ReadMe, Confluence, Notion y bases de conocimiento de servicios de atención, o Markdown simple en su repositorio.
¿Pueden documentar procesos internos?
Sí. Redactamos procedimientos operativos estándar y guías de incorporación entrevistando a las personas que hacen el trabajo y probando los pasos.
¿Traducen documentación?
Escribimos en inglés, albanés y alemán, y podemos producir otros idiomas a través de traductores profesionales.
¿Pueden mantener nuestra documentación actualizada después de cada versión?
Sí. Podemos revisar las notas de versión y actualizar las páginas afectadas como parte de un acuerdo continuo.
¿Usan IA para escribir documentación?
Podemos usar IA para esquemas iniciales o resúmenes, pero cada página la redacta, prueba y revisa una persona frente al producto real.
¿Cómo se presupuesta la redacción técnica?
Se presupuesta según el número de páginas, la profundidad técnica, los elementos visuales y los idiomas, tras revisar lo que ya existe.
¿Pueden trabajar a partir de grabaciones de pantalla y llamadas con nuestros desarrolladores?
Sí. Las grabaciones breves o las llamadas con quienes construyeron una funcionalidad suelen ser la forma más rápida de empezar, y las convertimos en guías estructuradas y probadas.
¿Escriben textos dentro del producto, como tooltips y mensajes de error?
Sí. El microcopy está muy ligado a la documentación, y mantener una redacción coherente entre el producto y la documentación ayuda a los usuarios.
¿Pueden migrar nuestra documentación a una nueva plataforma?
Sí. Trasladamos y reestructuramos el contenido existente, corregimos enlaces rotos y configuramos redirecciones para que las URL antiguas sigan funcionando.
Servicios relacionados
Redacción técnica por sector
Haga su producto más fácil de usar.
Cuéntenos qué necesita. Recibirá una valoración honesta, un plan claro y un presupuesto por escrito. La primera consulta es siempre gratuita.
- Qué ocurre después
- 1Usted nos cuenta qué necesita
- 2Nos proponemos responder en 24 horas con preguntas
- 3Recibe un presupuesto por escrito para su proyecto