09. Corrección responsiva del portafolio UX/UI

¿Qué aprenderás?

En este tutorial realizaremos un proceso completo de diagnóstico y corrección responsiva del portafolio profesional UX/UI.

Compararemos nuestro prototipo de Figma con la implementación desarrollada en WordPress.

Identificaremos diferencias de estructura, tipografía, colores, imágenes, navegación y distribución.

Después utilizaremos Blocksy, Gutenberg y Chrome DevTools para localizar las posibles causas y aplicar correcciones.

Finalmente, comprobaremos los resultados y documentaremos los cambios realizados.

Objetivos de aprendizaje

Al finalizar esta lección podrás:

Comprender el propósito de una revisión responsiva integral.
Comparar sistemáticamente un prototipo de Figma con un sitio WordPress.
Distinguir diferencias intencionales de problemas reales de implementación.
Clasificar problemas según su impacto y prioridad.
Construir una matriz de incidencias técnicas.
Inspeccionar elementos HTML y estilos CSS mediante Chrome DevTools.
Diferenciar problemas globales de Blocksy y problemas locales de Gutenberg.
Corregir anchos, contenedores y espacios laterales.
Corregir diferencias de tipografía, color e imágenes.
Reorganizar tarjetas, columnas y botones en pantallas pequeñas.
Verificar encabezado, navegación móvil y footer.
Realizar pruebas antes y después de cada corrección.
Documentar las soluciones aplicadas y sus resultados.

Nivel: Intermedio.
Herramientas: Figma, WordPress, Blocksy, Gutenberg y Google Chrome.
Requisitos previos: Haber completado los tutoriales 01 al 08.
Proyecto: Portafolio profesional de un diseñador gráfico especializado en UX/UI.
Modalidad: Actividad práctica de diagnóstico, corrección y documentación.
Entorno recomendado: Instalación de desarrollo o copia del sitio.
Plugins adicionales: No necesarios para esta actividad.

1. ¿Cuál es el objetivo de este tutorial?

Durante los tutoriales anteriores aprendimos a configurar WordPress, Blocksy y Gutenberg.

También revisamos los fundamentos del diseño responsivo y las herramientas de inspección de Chrome.

Ahora utilizaremos esos conocimientos para resolver un problema frecuente del desarrollo web:

La implementación de un sitio no siempre coincide con su diseño original.

Por ejemplo, podemos encontrarnos con las siguientes situaciones:

Un encabezado ocupa demasiado espacio.
Los títulos son más grandes que en Figma.
Las tarjetas se comprimen en dispositivos móviles.
Una imagen pierde información importante al recortarse.
Los botones quedan demasiado cerca.
El contenido se desborda horizontalmente.
Los colores no respetan la identidad visual definida.
El pie de página aparece desordenado.

¿Qué haremos?

Seguiremos un ciclo de cinco fases:

Comparar.
Diagnosticar.
Corregir.
Validar.
Documentar.

Diferencia entre diseñar y corregir

Diseñar: definir cómo debe funcionar y presentarse una interfaz.

Implementar: construir la interfaz utilizando las herramientas disponibles.

Corregir: identificar diferencias o problemas, comprender sus causas y aplicar soluciones.

Una corrección bien realizada debe resolver un problema sin generar otros.

2. ¿Es necesario que WordPress sea idéntico a Figma?

Figma representa las decisiones visuales y funcionales de nuestro proyecto.

Sin embargo, un prototipo es una referencia de diseño, no una reproducción exacta de todos los comportamientos de un navegador.

Diferencias que pueden ser aceptables

Algunos cambios pueden justificarse por:

Variaciones en el ancho de pantalla.
Diferentes longitudes de texto.
Comportamiento natural del contenido.
Restricciones o características del tema.
Ajustes necesarios para mejorar accesibilidad.
Diferencias entre sistemas de renderizado de fuentes.

Diferencias que debemos investigar

En cambio, debemos revisar situaciones como:

Contenido ilegible.
Elementos superpuestos.
Enlaces que no funcionan.
Desbordamientos horizontales.
Imágenes deformadas.
Navegación que desaparece.
Información importante que queda oculta.

Principio central

Nuestro objetivo es respetar la intención del diseño y mantener una buena experiencia de usuario, no perseguir una coincidencia visual perfecta a cualquier costo.

Si una adaptación mejora la experiencia responsiva, puede ser una decisión válida siempre que esté justificada.

3. Preparar el entorno de corrección

Antes de modificar el portafolio debemos proteger el trabajo realizado.

No conviene experimentar directamente sobre un sitio público si tenemos la posibilidad de utilizar un entorno de desarrollo.

¿Qué debemos conservar?

Una copia de la página actual.
Los valores de configuración importantes.
Una referencia visual del estado anterior.
Los contenidos y enlaces existentes.
El prototipo de Figma utilizado como referencia.

Preparar una versión de trabajo

Ingresa al escritorio de WordPress.

Identifica la página del portafolio que revisarás.

Comprueba si estás trabajando en una instalación local, staging o producción.

Si utilizas un sitio de desarrollo, verifica que el contenido actual esté guardado.

Antes de modificar la página, registra una referencia de su estado.

Puedes utilizar una captura de pantalla y conservar los valores principales de configuración.

Si tu instalación permite duplicar páginas mediante una herramienta ya disponible, puedes utilizarla.

No es necesario instalar un plugin de duplicación para realizar este tutorial.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 01. Estado inicial del portafolioCaptura pendiente: página del portafolio antes de iniciar las correcciones.

Resultado esperado:Dispones de una página o entorno donde puedes aplicar correcciones sin perder la versión de referencia.

Recomendación

Trabaja con cambios pequeños y verificables.

No modifiques simultáneamente tipografías, contenedores, colores y columnas si todavía no sabes cuál es la causa del problema.

4. Seleccionar la referencia correcta en Figma

Una comparación será útil solamente si conocemos qué diseño estamos utilizando como referencia.

Durante el desarrollo del portafolio podemos haber creado diferentes versiones de una página.

Por eso debemos identificar la propuesta aprobada o la versión sobre la que trabajaremos.

Elementos de referencia

Revisa en Figma:

Página correspondiente.
Versión del diseño.
Ancho del frame.
Disposición del encabezado.
Distribución del contenido.
Tipografías.
Colores.
Imágenes.
Espaciados.
Versión móvil, cuando exista.

Importante sobre Dev Mode

No es obligatorio utilizar Figma Dev Mode para completar este ejercicio.

Podemos realizar una comparación visual utilizando el archivo de diseño y sus propiedades disponibles.

Si tu cuenta dispone de funciones adicionales de inspección, puedes utilizarlas como apoyo.

Identificar el diseño de referencia

Abre el proyecto del portafolio en Figma.

Identifica la página de Inicio o la página elegida para el ejercicio.

Selecciona el frame de escritorio.

Registra su ancho y los elementos principales.

Si existe un frame móvil, identifica también su ancho.

Revisa si ambos diseños representan la misma versión del proyecto.

Anota las diferencias de contenido que puedan dificultar la comparación.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 02. Prototipo de referencia en FigmaCaptura pendiente: frames de escritorio y móvil del portafolio.

Resultado esperado:Has identificado la versión y las pantallas de Figma que compararás con WordPress.

Documentación oficial

Guide to inspecting — Figma

5. Abrir el sitio implementado

Necesitamos comparar el diseño de Figma con la página real renderizada por WordPress.

No utilizaremos solamente la vista del editor Gutenberg.

La apariencia final puede estar influida por:

El tema Blocksy.
Las configuraciones globales.
Los ajustes de cada página.
Los estilos propios de los bloques.
El contenido.
El tamaño real de pantalla.

Abrir la implementación en Chrome

Abre Google Chrome.

Ingresa a la URL del portafolio en tu entorno de desarrollo.

Selecciona la misma página que revisaste en Figma.

Comprueba que el contenido esté actualizado.

Desplázate desde el header hasta el footer.

Identifica las principales secciones de la página.

Revisa si existen problemas evidentes antes de activar las herramientas de inspección.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 03. Página implementada en WordPressCaptura pendiente: vista completa o parcial del portafolio en Chrome.

Resultado esperado:Visualizas la página real que será evaluada y puedes identificar su estructura completa.

6. Comparar Figma y WordPress

La comparación debe realizarse con criterios definidos.

No basta con observar ambas ventanas y decir que se ven diferentes.

Preparar la comparación

Intenta utilizar un ancho de visualización equivalente al frame de Figma.

Recuerda que el tamaño del navegador, su nivel de zoom y el viewport disponible pueden afectar la comparación.

Cuando utilices Chrome DevTools, ajusta el ancho del viewport de manera explícita.

Tabla de comparación inicial

Elemento	Qué comparar
Header	Altura, logotipo, navegación
Contenedor	Ancho y separación lateral
Hero	Distribución, imagen, título
Tipografía	Familia, tamaño, interlineado
Colores	Fondos, textos y botones
Proyectos	Cantidad y ancho de columnas
Imágenes	Proporción y recortes
Footer	Columnas, enlaces y espaciados

Realizar una comparación visual

Abre el frame de referencia en Figma.

En otra ventana, abre la misma página en Chrome.

Ajusta el viewport del navegador para aproximarlo al ancho del frame.

Compara primero el encabezado y el área principal.

Continúa con los proyectos y el pie de página.

Registra diferencias observables.

Por ejemplo:

El título ocupa tres líneas en WordPress y dos en Figma.
El contenido queda demasiado cerca del borde.
Las imágenes tienen una proporción distinta.
La fila de proyectos no se reorganiza adecuadamente.

Evita registrar observaciones imprecisas como “se ve mal” o “no me gusta”.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 04. Comparación Figma y WordPressCaptura pendiente: comparación del mismo diseño y un ancho de viewport equivalente.

Resultado esperado:Identificas diferencias concretas entre el prototipo y el sitio implementado.

Recomendación

Mantén el mismo contenido en ambas versiones siempre que sea posible.

Si Figma tiene textos ficticios más breves, una diferencia de altura puede deberse al contenido y no necesariamente al CSS.

7. Crear una matriz de incidencias

Antes de aplicar correcciones necesitamos ordenar los problemas detectados.

La matriz permitirá documentar el proceso técnico y justificar las decisiones.

Estructura recomendada

ID	Problema	Dispositivo	Causa posible	Herramienta	Prioridad
R01	Desborde horizontal	Móvil	Ancho de bloque	Gutenberg	Alta
R02	Título demasiado grande	Escritorio	Tipografía	Blocksy	Media
R03	Imagen recortada	Móvil	Relación de aspecto	Gutenberg	Media
R04	Menú no se abre	Móvil	Configuración de header	Blocksy	Alta

Los casos son ilustrativos. Debes registrar los problemas que realmente identifiques.

¿Cómo definir prioridades?

Alta: afecta el funcionamiento, la navegación o la lectura de contenido importante.

Media: dificulta la experiencia o genera una diferencia visual significativa.

Baja: corresponde a un ajuste visual menor que no impide utilizar el sitio.

Cuidado

Una causa posible es una hipótesis.

No debemos considerarla confirmada hasta revisar el elemento correspondiente.

Registrar y priorizar las incidencias

Crea una tabla de diagnóstico en el medio que utilices para documentar tu actividad.

Registra cada problema con un identificador, por ejemplo R01, R02 y R03.

Describe qué ocurre y dónde se presenta.

Indica el tamaño de pantalla o dispositivo donde lo detectaste.

Anota una posible causa y la herramienta que crees que permitirá corregirla.

Asigna una prioridad.

Comienza con los problemas que afectan el funcionamiento y la lectura.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 05. Matriz de diagnósticoCaptura pendiente: tabla con incidencias, causas posibles y prioridades.

Resultado esperado:Dispones de una matriz con problemas específicos y ordenados según su importancia.

8. Inspeccionar el problema con Chrome DevTools

Antes de modificar WordPress debemos identificar qué elemento está generando el problema.

Para hacerlo utilizaremos Chrome DevTools.

Herramientas principales

Elements: permite inspeccionar la estructura HTML.

Styles: muestra las reglas CSS relacionadas con el elemento seleccionado.

Computed: permite revisar los valores calculados que finalmente utiliza el navegador.

Device Toolbar: permite simular diferentes dimensiones de viewport.

Ejemplo

Si un bloque ocupa más ancho que el disponible, podríamos necesitar revisar:

Width.
Max-width.
Padding.
Margin.
Display.
Overflow.

Estas propiedades pueden indicar por qué se produce un desbordamiento.

Importante

Las modificaciones que hacemos directamente en DevTools son temporales.

Sirven para investigar o probar soluciones.

La corrección definitiva debe realizarse en WordPress o en los archivos correspondientes del proyecto.

Inspeccionar el elemento problemático

Abre la página del portafolio en Chrome.

Activa DevTools.

Selecciona la herramienta de inspección de elementos.

Haz clic sobre el componente que presenta el problema.

Observa el elemento seleccionado en Elements.

Revisa las propiedades disponibles en Styles y Computed.

Identifica posibles valores relacionados con la incidencia.

Puedes realizar un cambio temporal para observar si mejora el resultado.

No confundas esta prueba con una modificación permanente.

Registra tus observaciones en la matriz.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 06. Inspección de estilos CSSCaptura pendiente: elemento seleccionado en DevTools con el panel Styles visible.

Resultado esperado:Identificas el elemento HTML y los estilos relacionados con una incidencia.

Documentación oficial

Inspect mode — Chrome DevTools

CSS reference — Chrome DevTools

9. Identificar si el problema corresponde a Blocksy o Gutenberg

Una vez identificado el elemento, debemos decidir dónde intervenir.

Esta decisión evita realizar cambios innecesarios.

Problemas habituales de Blocksy

Ancho general del sitio.
Espaciado lateral del contenido.
Tipografía predeterminada.
Paleta global.
Header.
Footer.
Estructura predeterminada de páginas.

Problemas habituales de Gutenberg

Columnas de una sección.
Imagen de una tarjeta.
Relleno interior de un bloque.
Distribución de botones.
Fondo de una sección.
Espaciado particular.
Contenido específico de una página.

Pregunta útil

¿El problema aparece en varias páginas o solamente en un componente?

Si afecta muchas páginas, podría tratarse de una configuración global.

Si aparece solamente en una tarjeta, probablemente debemos revisar su estructura o estilos locales.

Esta regla ayuda a investigar, pero no sustituye la inspección real.

Identificar la herramienta responsable

Selecciona una incidencia de tu matriz.

Revisa si afecta a una página, varias páginas o todo el sitio.

Si corresponde a un problema general, consulta el personalizador de Blocksy.

Si afecta una sección concreta, abre la página en Gutenberg.

Utiliza la Vista de lista para localizar el bloque padre.

Comprueba si existen estilos aplicados directamente a ese elemento.

Registra la herramienta responsable o la causa más probable.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 07. Identificación del origenCaptura pendiente: comparación entre un ajuste global de Blocksy y un bloque seleccionado en Gutenberg.

Resultado esperado:Puedes justificar si una incidencia debe corregirse desde Blocksy o Gutenberg.

Documentación oficial

List View — WordPress

Getting Started with Theme Options — Blocksy

10. Corregir problemas de ancho y contenedores

Uno de los errores más habituales es configurar un ancho incorrecto.

Podemos encontrar páginas demasiado estrechas o contenido que se extiende fuera de la pantalla.

Configuraciones globales de Blocksy

Dentro de Apariencia → Personalizar → General Options → Layout, encontramos controles como:

Maximum Site Width: ancho máximo general.
Content Edge Spacing: separación lateral respecto de los bordes del viewport.
Narrow Container Width: ancho del contenedor estrecho.
Wide Alignment Offset: extensión de contenidos con alineación amplia.

¿Qué debemos revisar primero?

Compara el ancho establecido en Figma con el que utiliza la página implementada.

Después inspecciona los contenedores.

Si el problema afecta a toda la página, revisa Blocksy.

Si afecta solamente a un Grupo de Gutenberg, revisa el ancho de ese bloque.

Corregir un problema de ancho

Selecciona una incidencia relacionada con el ancho del contenido.

Abre la página en Chrome DevTools.

Identifica el contenedor que está generando la diferencia.

Comprueba si utiliza un ancho fijo, un ancho máximo o un espaciado lateral excesivo.

Si el problema es global, abre:

Apariencia → Personalizar → General Options → Layout

Revisa Maximum Site Width y Content Edge Spacing.

Si el problema corresponde a una sección particular, abre Gutenberg y selecciona el bloque contenedor.

Ajusta solamente la configuración que origine el problema.

Vuelve al navegador y comprueba el resultado en escritorio y móvil.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 08. Corrección del ancho del contenidoCaptura pendiente: comparación del contenedor antes y después de corregir su ancho.

Resultado esperado:El contenido utiliza un ancho apropiado sin generar desbordamientos.

Documentación oficial

Layout — Blocksy

11. Corregir problemas de tipografía

La tipografía influye directamente en la lectura y el comportamiento responsivo.

Un título puede ocupar más líneas de las esperadas porque:

La familia tipográfica es diferente.
El tamaño es demasiado grande.
El peso utilizado cambia el ancho visual.
El contenedor es más estrecho.
El texto no coincide con Figma.
Se aplicó una configuración local.

¿Qué debemos comparar?

Propiedad	Pregunta
Font Family	¿Es la fuente correcta?
Font Size	¿El tamaño corresponde al diseño?
Font Weight	¿Se utiliza el peso esperado?
Line Height	¿La separación entre líneas es adecuada?
Letter Spacing	¿La distancia entre letras cambió?
Width	¿El contenedor permite una composición similar?

No debemos modificar el tamaño de fuente sin comprobar también el ancho del contenedor.

Corregir una diferencia tipográfica

Selecciona un título que presente diferencias con Figma.

Comprueba primero que el texto sea el mismo.

Inspecciona el título con Chrome DevTools.

Revisa la familia, tamaño, peso e interlineado calculados.

Comprueba el ancho disponible del elemento.

Si la diferencia afecta a muchos encabezados, abre Apariencia → Personalizar → Typography.

Revisa la configuración del nivel correspondiente.

Si afecta solamente a un título, selecciona su bloque en Gutenberg.

Ajusta la propiedad adecuada.

Comprueba el resultado en diferentes anchos de pantalla.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 09. Corrección de tipografíaCaptura pendiente: comparación antes y después de ajustar un encabezado del portafolio.

Resultado esperado:El texto mantiene una jerarquía coherente, legible y próxima al prototipo.

Documentación oficial

Typography — Blocksy

12. Corregir diferencias de colores

La paleta de colores debe relacionarse con la identidad visual definida en Figma.

Sin embargo, algunas diferencias aparecen porque un elemento utiliza un valor local en lugar de la paleta global.

Ejemplo

Imagina que el color principal del portafolio es azul.

El menú utiliza ese color, pero los botones de una sección aparecen con otro tono.

En ese caso, no necesariamente debemos modificar toda la paleta.

Podría ser suficiente con revisar los estilos particulares de los botones.

¿Dónde revisar?

Blocksy: General Options → Colors.

Gutenberg: configuración de color del bloque seleccionado.

Consideración importante

Los colores globales pueden heredarse de manera distinta según el componente.

Un bloque con estilos propios puede mantener su color aunque cambie la paleta general.

Corregir una inconsistencia de color

Selecciona una incidencia relacionada con los colores.

Revisa el valor definido en Figma.

Identifica el elemento correspondiente en WordPress.

Si la diferencia afecta a todo el sitio, revisa General Options → Colors.

Comprueba la paleta global y las asignaciones de colores.

Si afecta solamente a un botón o bloque, abre Gutenberg y selecciona ese elemento.

Revisa si tiene un color local asignado.

Utiliza una referencia global de la paleta cuando resulte apropiado.

Comprueba que el texto mantenga suficiente contraste con el fondo.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 10. Corrección de coloresCaptura pendiente: comparación de valores de color en Figma y Blocksy o Gutenberg.

Resultado esperado:Los colores del portafolio respetan la identidad visual y mantienen suficiente contraste.

Documentación oficial

Colors — Blocksy

13. Corregir imágenes recortadas o deformadas

Las imágenes son especialmente importantes en un portafolio UX/UI.

Un recorte incorrecto puede ocultar una parte relevante de un proyecto.

Problemas posibles

Relación de aspecto diferente.
Uso de Cover cuando no corresponde.
Ancho o alto fijados incorrectamente.
Imagen de origen con proporciones diferentes.
Punto focal mal ubicado.
Archivo de baja calidad.

Cover y Contain

Cover permite llenar el área disponible, pero puede recortar la imagen.

Contain permite mostrarla completa, aunque puede dejar espacio libre.

No existe una opción correcta para todos los casos.

¿Qué conviene hacer?

Compara la intención del diseño original.

Una imagen de presentación puede necesitar conservarse completa.

Una fotografía decorativa puede admitir cierto recorte.

Corregir la presentación de una imagen

Selecciona una imagen que no coincida con el prototipo.

Abre la página en Gutenberg.

Utiliza la Vista de lista si necesitas identificar el bloque correcto.

Selecciona el bloque Imagen o el componente que contiene la fotografía.

Revisa su relación de aspecto.

Comprueba las opciones de escala y recorte disponibles.

Si el bloque utiliza Cover, evalúa si esa presentación es adecuada.

Ajusta el punto focal cuando exista esa opción.

Comprueba que la imagen no se deforme.

Revisa también el texto alternativo cuando la imagen comunique información.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 11. Corrección de una imagenCaptura pendiente: tarjeta de proyecto con imagen antes y después de ajustar el recorte.

Resultado esperado:La imagen conserva una proporción apropiada y muestra la información importante.

Documentación oficial

Image Block — WordPress

Cover Block — WordPress

14. Corregir tarjetas y columnas en móvil

Las composiciones con varias columnas requieren una revisión especial.

Un diseño puede funcionar perfectamente en escritorio y presentar dificultades en un teléfono.

Problemas habituales

Tres columnas demasiado estrechas.
Botones fuera de su contenedor.
Títulos cortados.
Imágenes comprimidas.
Espacios laterales excesivos.
Orden de lectura incorrecto.

Herramienta principal

El bloque Columnas de Gutenberg incorpora la opción Stack on mobile.

Cuando está habilitada, las columnas se reorganizan verticalmente en pantallas pequeñas.

Consideración importante

La reorganización de columnas no resuelve necesariamente problemas de padding o elementos que utilizan anchos fijos.

Debemos revisar el contenido de cada columna.

Corregir la distribución de tarjetas

Abre la página de proyectos en Gutenberg.

Selecciona el bloque padre Columnas mediante la Vista de lista.

Revisa el control Stack on mobile.

Comprueba que esté activado cuando la composición requiera apilar columnas.

Observa la distribución de las tarjetas en móvil.

Revisa cada columna para detectar anchos o espaciados particulares.

Comprueba que los títulos, párrafos e imágenes permanezcan visibles.

Ajusta los elementos que generen problemas.

Después prueba la página en Chrome DevTools con diferentes anchos.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 12. Corrección de columnas responsivasCaptura pendiente: tres tarjetas en escritorio y distribución vertical corregida en móvil.

Resultado esperado:Las tarjetas se reorganizan y mantienen una lectura clara en móvil.

Documentación oficial

Columns Block — WordPress

15. Corregir márgenes, rellenos y espaciados

Una composición puede presentar problemas aunque todos sus bloques estén correctamente organizados.

Por ejemplo, una tarjeta puede ocupar demasiado espacio porque tiene un relleno interior excesivo.

Conceptos que debemos diferenciar

Padding: espacio interior de un elemento.

Margin: espacio exterior.

Block Spacing: separación entre bloques hijos en un contenedor compatible.

Ejemplo

Supongamos que una tarjeta utiliza un padding lateral muy grande.

En escritorio puede verse correctamente.

En móvil, ese mismo valor puede dejar poco espacio para el texto.

Pregunta importante

¿El espacio proviene del contenedor padre o de uno de sus bloques internos?

La Vista de lista y DevTools nos ayudarán a identificarlo.

Corregir espacios excesivos

Selecciona una incidencia de espaciado.

Inspecciona el elemento en Chrome DevTools.

Revisa el modelo de caja y los valores de padding y margin.

Identifica si el espacio pertenece al bloque padre o a uno de sus hijos.

Abre la página en Gutenberg.

Selecciona el bloque correspondiente desde la Vista de lista.

Busca el apartado Dimensiones.

Modifica el valor que origina el problema.

Comprueba el resultado en escritorio y móvil.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 13. Corrección de espaciadosCaptura pendiente: modelo de caja y resultado antes y después de ajustar padding o margin.

Resultado esperado:La sección presenta separaciones equilibradas y mantiene suficiente espacio para el contenido.

Documentación oficial

Dimension Settings Overview — WordPress

Entry Content — Blocksy

16. Corregir botones y elementos interactivos

Los botones deben ser fáciles de reconocer y utilizar.

En una pantalla pequeña pueden presentarse problemas como:

Botones demasiado anchos.
Elementos muy juntos.
Textos que ocupan varias líneas.
Botones superpuestos.
Enlaces sin destino válido.

¿Qué debemos verificar?

Etiqueta: describe la acción de manera comprensible.

Destino: conduce a la página correspondiente.

Contraste: permite identificar el control.

Distribución: se adapta al ancho disponible.

Separación: evita que los botones queden amontonados.

Corregir la distribución de botones

Abre la página en Gutenberg.

Selecciona el bloque padre Botones.

Revisa sus opciones de distribución.

Comprueba la orientación y separación entre botones.

Identifica si algún botón tiene un ancho definido que genere problemas.

Ajusta la configuración disponible según el diseño.

Comprueba el texto y el destino de cada enlace.

Revisa el resultado con un viewport estrecho.

Verifica que los botones puedan seleccionarse mediante teclado.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 14. Corrección de botonesCaptura pendiente: botones antes y después de ajustar su distribución móvil.

Resultado esperado:Los botones tienen una distribución clara, funcionan y no se desbordan en móvil.

Documentación oficial

Buttons Block — WordPress

17. Revisar el header y la navegación móvil

El encabezado debe mantener su funcionalidad en diferentes tamaños de pantalla.

Un problema de navegación puede afectar directamente el uso del sitio.

Elementos que revisaremos

Logotipo.
Menú de escritorio.
Trigger móvil.
Off Canvas Area.
Menu – Mobile.
Separaciones.
Contraste.
Funcionamiento de los enlaces.

Problemas posibles

El menú móvil no se abre: debemos revisar el Trigger y el área Off Canvas.

El logotipo ocupa demasiado espacio: debemos comprobar su altura y la configuración de la fila.

Los enlaces no aparecen: debemos verificar la asignación del menú.

Los elementos se superponen: debemos revisar la estructura y los espacios disponibles.

Corregir una incidencia del header

Abre el personalizador de Blocksy.

Ingresa a Header.

Revisa la vista de escritorio y la configuración del menú principal.

Después cambia a la vista móvil.

Comprueba que Logo y Trigger estén correctamente ubicados.

Revisa el contenido de Off Canvas Area.

Verifica que Menu – Mobile tenga el menú correcto.

Ajusta el tamaño, espaciado o visibilidad del elemento que genere la incidencia.

Abre el sitio real y comprueba que la navegación funcione.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 15. Corrección de navegación móvilCaptura pendiente: header móvil y panel Off Canvas después de corregir una incidencia.

Resultado esperado:La navegación funciona correctamente en escritorio y móvil.

Documentación oficial

Header Builder Elements — Blocksy

Trigger — Blocksy

El pie de página debe mantener sus contenidos organizados en pantallas pequeñas.

Al reducir el ancho disponible, las columnas pueden necesitar una distribución vertical.

¿Qué revisaremos?

Cantidad de columnas.
Orden de lectura.
Espacios entre bloques.
Información de contacto.
Enlaces de navegación.
Redes sociales.
Copyright.
Contraste de texto y fondo.

Importante

No debemos ocultar información importante solamente porque el dispositivo sea pequeño.

Primero debemos buscar una distribución más apropiada.

Corregir la distribución del footer

Abre Apariencia → Personalizar → Footer.

Selecciona la fila principal del footer.

Activa la vista móvil.

Revisa la distribución de columnas.

Busca los ajustes de Columns Layout.

Comprueba que los contenidos se organicen de forma comprensible.

Ajusta los espacios entre columnas y widgets cuando sea necesario.

Revisa también el orden de los enlaces y la visibilidad de las redes sociales.

Abre el sitio en Chrome y comprueba el resultado.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 16. Corrección del footer móvilCaptura pendiente: footer reorganizado verticalmente en un teléfono.

Resultado esperado:El pie de página mantiene una lectura ordenada y todos sus enlaces funcionan.

Documentación oficial

Footer Row Options — Blocksy

19. Validar cada corrección

Una modificación no debe considerarse terminada solamente porque mejore el aspecto del sitio.

Necesitamos comprobar que realmente resuelva el problema identificado.

Ciclo de validación

Registrar el problema original.
Identificar su causa.
Aplicar una corrección.
Revisar el resultado.
Comprobar otras pantallas.
Registrar la evidencia.

¿Por qué probar otras pantallas?

Porque una modificación puede mejorar el diseño móvil y provocar una diferencia inesperada en escritorio.

Por ejemplo, reducir un tamaño de fuente global podría resolver un título demasiado grande en móvil, pero modificar todos los encabezados del sitio.

Regla de trabajo

Cada cambio debe verificarse en el contexto donde apareció el problema y en otras vistas relevantes.

Comprobar el antes y después

Selecciona una incidencia que hayas corregido.

Abre nuevamente el sitio en Chrome.

Configura el mismo ancho de viewport utilizado al detectar el problema.

Compara el resultado con la evidencia inicial.

Comprueba que la diferencia haya sido resuelta.

Después revisa la página en otros anchos.

Utiliza como referencia:

360 píxeles.
390 píxeles.
768 píxeles.
1280 píxeles.

Verifica que los elementos cercanos sigan funcionando.

Si la corrección generó otro problema, regresa a la configuración responsable y vuelve a evaluarla.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 17. Comparación antes y despuésCaptura pendiente: incidencia original y resultado corregido al mismo ancho de viewport.

Resultado esperado:Puedes demostrar que la corrección resuelve la incidencia sin introducir problemas evidentes en otras vistas.

Importante

Los anchos propuestos son dimensiones de prueba.

No representan obligatoriamente los breakpoints de Blocksy o Gutenberg.

Además, la emulación de Chrome DevTools es una aproximación; cuando sea posible, complementa el trabajo con pruebas en dispositivos reales.

20. Documentar el resultado final

La documentación es una parte importante del trabajo técnico.

Nos permite explicar qué problema encontramos, cómo lo investigamos y por qué seleccionamos una solución.

Matriz final de correcciones

ID	Problema	Causa confirmada	Corrección	Resultado
R01	Desborde horizontal	Padding excesivo	Ajustar Grupo	Resuelto
R02	Título muy grande	Estilo local	Ajustar Encabezado	Resuelto
R03	Imagen recortada	Escala Cover	Revisar escala	Resuelto
R04	Menú móvil inactivo	Configuración de Trigger	Ajustar Header	Pendiente

Los valores anteriores son ejemplos ilustrativos.

Estados sugeridos

Pendiente: problema identificado que todavía no ha sido corregido.

En proceso: se está investigando o aplicando una solución.

Resuelto: la corrección fue aplicada y comprobada.

Justificado: diferencia respecto del prototipo que se conserva por una razón documentada.

Evidencia antes y después

Para cada incidencia importante, conserva:

Referencia visual inicial.
Descripción del problema.
Configuración modificada.
Resultado final.
Ancho de pantalla utilizado.
Observaciones de validación.

Completar el informe de correcciones

Regresa a la matriz creada al comenzar la actividad.

Selecciona cada incidencia.

Registra la causa confirmada después de realizar la inspección.

Describe qué configuración modificaste.

Indica si utilizaste Blocksy, Gutenberg u otra herramienta pertinente.

Incorpora las evidencias antes y después.

Registra el estado final de cada problema.

Si una diferencia se mantiene intencionalmente, explica la razón.

Revisa que las capturas y los registros correspondan a la misma página y a anchos de pantalla comparables.

Captura pendienteAquí incorporaremos una captura real del procedimiento.

Figura 18. Registro final de correccionesCaptura pendiente: matriz de incidencias completada con resultados y evidencias.

Resultado esperado:Dispones de una matriz final que explica los problemas, las soluciones y los resultados verificados.

21. Errores frecuentes durante la corrección

Modificar varias opciones al mismo tiempo

Problema: no sabemos qué cambio resolvió o generó una incidencia.

Recomendación: aplicar correcciones pequeñas y comprobarlas por separado.

Corregir desde Blocksy un problema particular

Problema: un cambio global modifica páginas que estaban funcionando correctamente.

Recomendación: identificar primero si el problema se origina en el tema o en un bloque.

Corregir desde Gutenberg un problema global

Problema: terminamos repitiendo los mismos ajustes en muchas páginas.

Recomendación: revisar las configuraciones globales cuando el comportamiento se repite en todo el sitio.

Buscar una coincidencia visual perfecta

Problema: podemos introducir configuraciones rígidas que funcionan solamente en un ancho de pantalla.

Recomendación: respetar la intención del diseño y priorizar su comportamiento responsivo.

No comparar el mismo contenido

Problema: las diferencias pueden deberse a textos o imágenes diferentes.

Recomendación: verificar los contenidos antes de interpretar la causa.

Utilizar solamente la vista previa de WordPress

Problema: podemos pasar por alto diferencias que aparecen en el navegador real.

Recomendación: comprobar los resultados en Chrome DevTools y, cuando sea posible, en dispositivos reales.

Olvidar los enlaces y elementos interactivos

Problema: el sitio puede verse correcto, pero no funcionar adecuadamente.

Recomendación: comprobar navegación, botones, menú móvil y contacto.

No documentar las correcciones

Problema: perdemos información sobre las decisiones realizadas.

Recomendación: completar la matriz y conservar evidencias antes y después.

22. Actividad práctica: corrección integral

Ajustando el diseño responsivo del portafolio UX/UI

Esta actividad aplica el ciclo completo de comparación, diagnóstico, corrección, validación y documentación.

Objetivo

Mejorar la implementación responsiva de una página del portafolio profesional y justificar las correcciones realizadas.

Parte A. Comparar

Abre el diseño de Figma y la página correspondiente en WordPress.

Revisa:

Header.
Hero.
Tipografía.
Colores.
Proyectos.
Imágenes.
Espaciados.
Botones.
Footer.

Parte B. Registrar

Identifica las diferencias que requieren revisión.

Completa una matriz con:

Identificador.
Elemento afectado.
Descripción.
Dispositivo.
Prioridad.
Posible causa.
Herramienta de corrección.

Parte C. Diagnosticar

Utiliza Chrome DevTools para inspeccionar los elementos.

Comprueba las propiedades que podrían explicar cada problema.

Determina si la solución corresponde a:

Blocksy.
Gutenberg.
El contenido.
Otra configuración del proyecto.

Parte D. Corregir

Aplica las modificaciones necesarias.

Prioriza los problemas que afecten la navegación, legibilidad y distribución responsiva.

Evita realizar modificaciones sin una justificación.

Parte E. Validar

Comprueba cada corrección.

Realiza pruebas con diferentes anchos de viewport.

Observa si los cambios afectan otras partes de la página.

Parte F. Documentar

Completa la matriz final.

Registra:

Problema detectado.
Causa confirmada.
Herramienta utilizada.
Corrección realizada.
Resultado.
Evidencia inicial y final.

Resultado esperado

Una página del portafolio con mejor comportamiento responsivo y un registro claro de las decisiones técnicas realizadas.

Casos de práctica sugeridos

Si no encuentras suficientes problemas en tu implementación, puedes realizar un ejercicio controlado sobre una página de prueba.

Por ejemplo:

Crear una tarjeta con relleno horizontal excesivo y corregirlo.
Desactivar Stack on mobile para observar el problema y restaurarlo.
Aplicar una relación de aspecto inadecuada a una imagen y corregirla.
Modificar un color local y volver a vincularlo con la paleta del proyecto.
Desorganizar temporalmente el espaciado de un conjunto de botones y corregirlo.

No realices estas modificaciones en una página pública.

La finalidad es comprender cómo se manifiesta cada problema y qué herramientas permiten resolverlo.

Evidencia de aprendizaje

El registro del trabajo puede incluir:

Capturas iniciales.
Matriz de incidencias.
Ejemplos de inspección con Chrome DevTools.
Capturas posteriores a las correcciones.
Comparación con Figma.
Conclusiones sobre las decisiones aplicadas.

Esta actividad complementa los contenidos de la Unidad III. Los criterios formales de evaluación deben consultarse en la pauta oficial de la asignatura.

23. Lista de verificación

Lista de verificación

Marca las actividades que hayas completado.

Tu progreso0 de 18 completados

24. Documentación oficial

Puedes utilizar estas referencias para profundizar en las herramientas abordadas durante el diagnóstico.

Próximo tutorial

En la siguiente lección realizaremos la verificación final y revisión de accesibilidad del portafolio UX/UI.

Comprobaremos navegación, jerarquía de encabezados, legibilidad, contraste, imágenes, enlaces y funcionamiento en diferentes dispositivos.

También revisaremos cómo identificar problemas que requieren una nueva corrección antes de considerar finalizada la implementación.