HTML

Estructura, texto, enlaces, imágenes y formularios.

<!DOCTYPE html>
<html lang="es">
<head>
  <meta charset="UTF-8">
  <meta name="viewport"
        content="width=device-width, initial-scale=1.0">
  <title>Título de la pestaña</title>
  <link rel="stylesheet" href="css/estilos.css">
</head>
<body>
  <!-- Todo lo visible -->
</body>
</html>

<header>   <!-- cabecera -->
<nav>      <!-- menú -->
<main>     <!-- contenido principal -->
<section>  <!-- parte de un tema -->
<article>  <!-- contenido independiente -->
<aside>    <!-- complementario -->
<footer>   <!-- pie -->

<h1>Título principal (solo uno)</h1>
<h2>Sección</h2>
<h3>Subsección</h3>
<p>Un párrafo con <strong>algo importante</strong>
   y <em>énfasis</em>.</p>

<ul>          <!-- sin orden -->
  <li>Lápiz</li>
  <li>Goma</li>
</ul>

<ol>          <!-- con orden -->
  <li>Abocetar</li>
  <li>Digitalizar</li>
</ol>

<a href="contacto.html">Contacto</a>
<a href="https://web.com" target="_blank"
   rel="noopener">Externo</a>
<a href="#seccion">Ir a una sección</a>
<a href="mailto:hola@correo.es">Escríbeme</a>

contacto.html     → misma carpeta
img/foto.jpg      → entrar en una carpeta
../index.html     → salir una carpeta
../img/logo.png   → salir y entrar en otra

<img src="img/cartel.jpg"
     alt="Cartel del festival de jazz"
     width="800" height="1200">

<figure>
  <img src="…" alt="…">
  <figcaption>Pie de foto</figcaption>
</figure>

<form>
  <label for="correo">Correo</label>
  <input type="email" id="correo"
         name="correo" required>

  <button type="submit">Enviar</button>
</form>

CSS: lo básico

Cómo se escribe CSS, cómo se seleccionan los elementos y la base que debe tener toda hoja de estilos.

selector {
  propiedad: valor;
  otra-propiedad: valor;
}

/* Comentario */

p           { }   /* todos los párrafos */
.tarjeta    { }   /* class="tarjeta" */
#cabecera   { }   /* id="cabecera" */
h1, h2      { }   /* varios a la vez */
nav a       { }   /* los a dentro de nav */
a:hover     { }   /* ratón encima */

color: #576F6F;           /* hexadecimal */
color: rgb(87, 111, 111);   /* RGB */
color: rgba(0,0,0,0.5);   /* con opacidad */

font-size: 1.5rem;   /* 1.5 × 16px */
width: 50%;          /* del contenedor */
height: 100vh;       /* alto de ventana */

*, *::before, *::after {
  box-sizing: border-box;
}

body {
  margin: 0;
  font-family: Arial, sans-serif;
  line-height: 1.6;
}

img {
  max-width: 100%;
  height: auto;
  display: block;
}

Cajas y texto

El modelo de caja, los bordes, fondos y sombras, la tipografía, las variables y las transiciones.

.caja {
  width: 300px;
  padding: 20px;      /* interior */
  border: 2px solid;  /* borde */
  margin: 30px;       /* exterior */
}

.contenedor {
  max-width: 1100px;
  margin: 0 auto;     /* centrar */
}

.tarjeta {
  background: #FFFFFF;
  border: 1px dashed #DEDBD2;
  border-bottom: 3px solid #576F6F;
  border-radius: 8px;   /* 50% = círculo */
  box-shadow: 0 4px 12px rgba(0,0,0,0.1);
}

body {
  font-family: "Inter", sans-serif;
  font-size: 1rem;      /* mínimo 16px */
  line-height: 1.6;     /* interlineado */
}

h1 {
  font-weight: 700;
  letter-spacing: -0.02em;
}

p {
  max-width: 65ch;      /* líneas legibles */
}

/* Definirlas */
:root {
  --color-principal: #576F6F;
  --fuente-titulos: Georgia, serif;
}

/* Usarlas */
h1 {
  color: var(--color-principal);
  font-family: var(--fuente-titulos);
}

.boton {
  background: #576F6F;
  transition: background 0.3s ease;
}

.boton:hover {
  background: #21231F;
}

Layout

Colocar los elementos en la página: en fila, en retícula o superpuestos.

.contenedor {
  display: flex;
  /* eje principal */
  justify-content: space-between;
  /* eje cruzado */
  align-items: center;
  gap: 16px;
  /* saltar de línea */
  flex-wrap: wrap;
}

.padre {
  display: flex;
  justify-content: center;
  align-items: center;
  min-height: 100vh;
}

.galeria {
  display: grid;
  grid-template-columns: 1fr 1fr 1fr;
  gap: 12px;
}

.destacado {
  /* ocupa 2 columnas */
  grid-column: span 2;
}

.tarjeta {
  /* el padre: referencia */
  position: relative;
}
.etiqueta {
  /* el hijo: encima */
  position: absolute;
  top: 12px;
  right: 12px;
}

header {
  /* se queda arriba */
  position: sticky;
  top: 0;
  z-index: 10;
}

Responsive

Que la web se adapte a cualquier pantalla.

<meta name="viewport"
      content="width=device-width, initial-scale=1.0">

/* 1. Primero, el móvil */
.galeria {
  display: grid;
  grid-template-columns: 1fr;
}

/* 2. Después, pantallas más grandes */
@media (min-width: 600px) {
  .galeria {
    grid-template-columns: 1fr 1fr;
  }
}

.galeria {
  display: grid;
  grid-template-columns:
    repeat(auto-fit, minmax(200px, 1fr));
  gap: 12px;
}

Cuando algo no funciona

Antes de nada: no hagas como Enjuto Mojamuto, que en cuanto algo deja de funcionar da por hecho que se ha roto internet entero. Casi nunca es internet. Casi siempre es una de estas cosas:

• ¿Has guardado el archivo? Y después, ¿has recargado el navegador forzando la descarga (Cmd + Mayús + R o Ctrl + F5)? El navegador a veces muestra una versión antigua.
• ¿La ruta es correcta? Mayúsculas, tildes, espacios, la carpeta, el ../. Una imagen o un CSS que no cargan casi siempre son una ruta mal escrita.
• ¿Has cerrado todas las etiquetas y llaves? Un } olvidado en CSS anula todas las reglas que vienen después.
• ¿Falta un punto y coma al final de una declaración CSS?
• ¿El selector coincide con el HTML? ¿Le falta el punto a la clase (.tarjeta) o la almohadilla al id (#cabecera)? ¿Está bien escrito el nombre?
• ¿Otra regla gana a la tuya? En el inspector, panel Estilos, las reglas que pierden aparecen tachadas.
• ¿Usaste comillas tipográficas (“ ”) en lugar de rectas (")? Pasa si copias código de Word o de algunas webs.
• ¿Has pasado el HTML por el validador y el CSS por el validador de CSS? Te dicen qué falla y en qué línea.
• ¿Y si has probado todo lo anterior? Levántate, bebe agua y vuelve a mirarlo con calma, o pregunta a un compañero: explicarle el problema en voz alta muchas veces basta para encontrarlo. Y tranquilidad: nadie ha roto nunca internet por olvidarse un punto y coma.

Gestalt

La Gestalt («forma» en alemán) es una corriente de la psicología que nació en Alemania a principios del siglo XX. Estudió cómo percibimos: nuestro cerebro no ve elementos sueltos, sino que los agrupa y organiza automáticamente para darles sentido. Su idea central: el todo se percibe de forma distinta a la suma de sus partes.

Probablemente ya conoces estos principios del diseño gráfico. Aquí nos fijamos en cómo se aplican en una pantalla: casi todas las decisiones de espacio, color y agrupación de una interfaz se explican con ellos.

Leyes de UX

Las leyes de UX son principios, la mayoría salidos de la psicología, que explican cómo usamos las interfaces. No son reglas matemáticas, sino tendencias muy comprobadas que ayudan a tomar decisiones de diseño y a justificarlas ante un cliente o un equipo. La web Laws of UX las recoge todas, en español.

Idea clave: estas leyes son la mejor herramienta para defender tus decisiones de diseño. «Lo he hecho más grande porque me gusta» es una opinión; «lo he hecho más grande y lo he acercado al pulgar por la ley de Fitts» es un argumento.

Jerarquía visual

La jerarquía visual es el orden en el que el ojo recorre una página: qué se ve primero, qué después y qué al final. En una web, la gente no lee: escanea en busca de lo que le interesa. Una buena jerarquía hace que encuentre lo importante en un par de segundos.

El contenido es el mismo. En la segunda versión, el título destaca por tamaño y peso, la fecha pasa a un segundo plano y el botón se reconoce como acción. Se entiende de un vistazo.

Las herramientas de la jerarquía

• Tamaño: lo más grande se ve primero.
• Peso y estilo: la negrita y las mayúsculas pequeñas separan niveles sin cambiar el tamaño.
• Color y contraste: lo más contrastado atrae la mirada; los textos secundarios, en un gris más suave.
• Posición: lo de arriba a la izquierda se ve antes (en idiomas que se leen de izquierda a derecha).
• Espacio: un elemento rodeado de espacio en blanco destaca más.
• Agrupación: lo que va junto se lee como una unidad (proximidad y región común, en Leyes del diseño).

Truco: la prueba de los ojos entrecerrados. Mira tu diseño entornando los ojos, o desenfócalo en Figma o Photoshop: lo que sigues distinguiendo es lo que domina la jerarquía. Si es lo importante, vas bien. Si todo pesa igual, o lo que destaca es un adorno, hay que reajustar.

Idea clave: la jerarquía funciona por contraste. Si todo es grande, nada es grande. Usa pocos niveles (tres o cuatro en una pantalla) y que la diferencia entre ellos sea clara.

Retículas en web

La retícula que usas en editorial funciona igual en pantalla, con una diferencia: en web no sabes el ancho del lienzo. Por eso las retículas web son fluidas: las columnas se estiran o se encogen con la pantalla, y el número de columnas cambia entre móvil y escritorio.

La retícula de 12 columnas

Es la más usada en web porque 12 se divide entre 2, 3, 4 y 6: permite composiciones de dos mitades, tres tercios, cuatro cuartos o combinaciones como 8 + 4.

• Columnas: en escritorio, 12; en tableta, 8; en móvil, 4.
• Medianil (gutter): el espacio entre columnas, normalmente entre 16 y 32px.
• Márgenes: el espacio a los lados de la página, para que nada toque el borde de la pantalla.
• Ancho máximo: en pantallas muy grandes, la retícula deja de crecer (por ejemplo, a 1200px) y se centra. Si no, las líneas de texto serían larguísimas.

De la retícula a CSS Grid

La retícula que dibujas en Figma se traslada casi literalmente a CSS con Grid, que viste en Programación I:

.contenedor {
  display: grid;
  grid-template-columns: repeat(12, 1fr);   /* 12 columnas */
  column-gap: 24px;                         /* medianil */
  max-width: 1200px;
  margin: 0 auto;
  padding: 0 24px;                          /* márgenes laterales */
}

.principal { grid-column: span 8; }   /* ocupa 8 de 12 */
.lateral   { grid-column: span 4; }   /* ocupa 4 de 12 */

/* En el móvil, todo ocupa las 12 columnas */
@media (max-width: 700px) {
  .principal, .lateral { grid-column: span 12; }
}

El sistema de 8 puntos

Muchos equipos de diseño usan medidas que son múltiplos de 8 (8, 16, 24, 32, 48, 64…) para todos los espacios: márgenes, rellenos, separaciones. Como un ritmo vertical en editorial, da coherencia sin tener que pensar cada medida, y encaja bien con la mayoría de tamaños de pantalla. En CSS se guarda como variables:

:root {
  --espacio-1: 8px;
  --espacio-2: 16px;
  --espacio-3: 24px;
  --espacio-4: 32px;
  --espacio-6: 48px;
  --espacio-8: 64px;
}

Fíjate: Figma tiene una opción para crear retículas de columnas en cada marco (Layout grid). Diseñar con la misma retícula que luego programarás hace que pasar del diseño al código sea mucho más fácil.

Patrones de lectura

Los estudios con seguimiento de la mirada (eye tracking) muestran que, en pantalla, recorremos las páginas siguiendo unos caminos bastante previsibles. Los dos más conocidos tienen forma de letra.

Patrón en F

En páginas con mucho texto (artículos, resultados de búsqueda, listados), leemos la primera línea casi entera, después una parte de la segunda, y luego bajamos por el margen izquierdo leyendo sólo el principio de cada línea. Por eso:

• Pon lo importante al principio: en los títulos, en los párrafos y en los elementos de las listas.
• Usa subtítulos, listas y negritas para que el texto se pueda escanear.
• Empieza los títulos y enlaces con las palabras que dan información («Horario de tutorías», no «Aquí puedes consultar el horario de tutorías»).

Patrón en Z

En páginas con poco texto y mucha imagen, como una portada o una página de presentación, la mirada va de arriba a la izquierda (el logotipo) a la derecha (el menú), baja en diagonal por el contenido central y termina abajo a la derecha. Por eso es un buen sitio para la llamada a la acción principal.

Ojo: los patrones de lectura describen lo que pasa cuando el diseño no guía la mirada. No son una plantilla obligatoria: con una buena jerarquía visual puedes llevar la atención adonde quieras. Úsalos para entender cómo leerá la gente tu página y para no esconder lo importante donde nadie mira.

Patrones de interfaz

Un patrón de interfaz es una solución probada a un problema que aparece una y otra vez: cómo moverse por una web, cómo mostrar una colección de elementos, cómo pedir confirmación. No hace falta inventar cada vez cómo funciona un menú: la gente ya sabe usar los patrones habituales (ley de Jakob), y usarlos hace tu interfaz más fácil de entender.

Truco: antes de diseñar un componente, mira cómo lo resuelven otras webs y aplicaciones. Galerías como Mobbin recogen capturas de interfaces reales ordenadas por patrón, y los sistemas de diseño de grandes empresas, como Material Design (Google), explican cuándo usar cada componente.

Estados de los componentes

Un botón no es una imagen fija: cambia según lo que pasa. Cada uno de esos cambios es un estado, y diseñarlos todos es lo que hace que una interfaz responda. Es la retroacción (feedback): la interfaz confirma que ha recibido la acción.

En CSS, cada estado tiene su pseudoclase, como viste en Programación I:

.boton {
  background: #576F6F;
  color: white;
  transition: background 0.15s, transform 0.1s;
}

.boton:hover {                /* ratón encima */
  background: #475B5B;
}

.boton:focus-visible {        /* seleccionado con el teclado */
  outline: 3px solid #C0812E;
  outline-offset: 3px;
}

.boton:active {               /* mientras se pulsa */
  transform: scale(0.97);
}

.boton:disabled {             /* no se puede usar */
  background: #C9CBC4;
  color: #6B6D67;
  cursor: not-allowed;
}

De Figma al código: en Figma, los estados se diseñan como variantes de un mismo componente (propiedad «Estado» con los valores normal, hover, foco…). Si en el diseño sólo existe el estado normal, al programarlo tendrás que inventarte el resto. Diseña siempre, como mínimo, normal, hover, foco y desactivado.

Formularios

En un formulario, quien visita la web deja de sólo mirar y empieza a interactuar con ella: escribe un mensaje, se inscribe en un curso, hace una compra. Por eso es también uno de los puntos donde más gente abandona: cada campo que sobra o cada error mal explicado es una razón para dejarlo a medias.

Buenas prácticas

• Pide sólo lo imprescindible. Cada campo debe justificar su existencia.
• Etiquetas visibles, encima del campo. El texto de ejemplo dentro del campo (placeholder) desaparece al escribir: no sustituye a la etiqueta.
• Una sola columna. Se recorre de arriba abajo sin dudar qué va después.
• El tamaño del campo, acorde al dato: un código postal no necesita el ancho de un mensaje.
• Marca lo opcional (o lo obligatorio, lo que sea menos), siempre con texto.
• Errores junto al campo, explicando cómo arreglarlos. «Falta la @» ayuda; «Campo no válido» no. Y no sólo en rojo: añade texto o un icono.
• El botón dice lo que hace: «Enviar mensaje», «Crear cuenta». No «OK» ni «Enviar» a secas si puede ser más claro.
• En el móvil, el teclado adecuado para cada dato, con el type correcto del <input> (Programación I, Tema 3).

Accesibilidad visual

Diseñar de forma accesible es diseñar para que todo el mundo pueda usar tu interfaz: personas con baja visión, daltonismo, temblor en las manos o, simplemente, alguien que mira el móvil a pleno sol. La mayoría de las decisiones de accesibilidad visual se toman en la fase de diseño, no al programar.

Contraste

Las pautas internacionales de accesibilidad (WCAG) piden una relación de contraste mínima entre el texto y su fondo. Pruébalo con el comprobador:

El ejemplo empieza con el gris azulado claro de esta web sobre su fondo: es bonito, pero no llega para un texto. Por eso en la web ese color sólo se usa para detalles, nunca para párrafos.

No depender sólo del color

Alrededor de 1 de cada 12 hombres (y muchas menos mujeres) tiene algún tipo de daltonismo, y además el color se pierde en pantallas malas o al imprimir en blanco y negro. Si algo se comunica con color, comunícalo también de otra forma:

Lo mismo con los enlaces: si sólo se distinguen del texto por el color, márcalos además con subrayado.

Tamaños

• Texto: al menos 16px para leer. Y que la página siga funcionando al ampliarla al 200 %.
• Zonas táctiles: todo lo que se pueda tocar, de unos 44 × 44 px como mínimo recomendado, con espacio entre una zona y otra (ley de Fitts).

Otros puntos

• Foco visible en todo lo interactivo (apartado de estados).
• Nada de texto dentro de imágenes: no se puede ampliar ni traducir, y los lectores de pantalla no lo leen (salvo en el alt).
• Movimiento con moderación, y respetando la preferencia de reducirlo.

Idea clave: la accesibilidad no es un añadido para unas pocas personas. Un buen contraste, botones grandes y errores claros hacen la interfaz mejor para todo el mundo. Y en muchas webs públicas y de empresas, en Europa, además es obligatoria.

Auto Layout y Flexbox

Si has usado Auto Layout en Figma, ya sabes Flexbox: son la misma idea con otros nombres. Un marco con Auto Layout coloca sus elementos en fila o en columna, con un espacio entre ellos y un relleno alrededor, y se adapta a su contenido. Exactamente lo que hace display: flex.

.boton {
  display: flex;               /* Auto Layout */
  flex-direction: row;         /* dirección: horizontal */
  gap: 8px;                    /* espacio entre elementos: 8 */
  padding: 12px 20px;          /* relleno: 12 vertical, 20 horizontal */
  align-items: center;         /* alineación: centrada */
  width: fit-content;          /* ancho: Hug */
}

El diccionario

.tarjeta {
  display: flex;
  flex-direction: column;      /* Auto Layout vertical */
  gap: 16px;
  padding: 24px;
}

.tarjeta .titulo {
  width: 100%;                 /* Fill container (en vertical) */
}

.fila .elemento {
  flex: 1;                     /* Fill container (en horizontal) */
}

Fíjate: las versiones recientes de Figma incluyen también un Auto Layout en cuadrícula, que equivale a CSS Grid. La lógica es la misma: lo que construyes con filas, columnas y espacios en Figma se traduce casi palabra por palabra a CSS.

Idea clave: diseña con Auto Layout siempre que puedas. Un diseño hecho con elementos sueltos colocados a mano se traduce mal al código (acaba lleno de posiciones absolutas que se rompen en el móvil). Un diseño hecho con Auto Layout ya está pensado como en CSS.

Restricciones y responsive

En Figma, cada marco tiene un ancho fijo. En la web, no. Hay dos herramientas de Figma que ayudan a pensar en cómo se adaptará el diseño.

Restricciones (constraints)

Indican a qué lado del marco se «engancha» un elemento cuando el marco cambia de tamaño. Se parecen a position: absolute con top, right, bottom y left:

Úsalas para elementos superpuestos (una etiqueta sobre una imagen, un botón flotante). Para todo lo demás, mejor Auto Layout, igual que en código usamos Flexbox y Grid antes que position.

Mínimos y máximos

Los marcos con Auto Layout admiten ancho mínimo y máximo: equivalen a min-width y max-width. Un bloque de texto con ancho máximo es lo que en CSS hacemos con max-width: 65ch.

Un marco por tamaño de pantalla

Como Figma no tiene media queries, el diseño responsive se muestra con varios marcos: uno por cada punto de ruptura. Al programar, cada cambio entre un marco y otro se convierte en una media query.

• Móvil: unos 375–390px de ancho.
• Tableta: unos 768px.
• Escritorio: 1280–1440px.

Truco: diseña primero el marco del móvil, igual que en CSS escribes primero los estilos del móvil (mobile first). Y prueba a estirar tus marcos en Figma: si al cambiar el ancho todo se descoloca, al programarlo pasará lo mismo.

Variables y estilos

En Figma, los estilos y las variables guardan las decisiones que se repiten: los colores de la marca, los estilos de texto, los espacios, las sombras. En CSS, eso mismo son las variables CSS (las custom properties que viste en Programación I). Si en Figma están bien organizadas, el CSS casi se escribe solo.

:root {
  /* Colores (variables de color de Figma) */
  --color-fondo: #F7F6F2;
  --color-texto: #21231F;
  --color-acento: #576F6F;

  /* Espacios (variables numéricas de Figma) */
  --espacio-s: 8px;
  --espacio-m: 16px;
  --espacio-l: 32px;

  /* Efectos (estilo de efecto de Figma) */
  --sombra-tarjeta: 0 4px 12px rgba(0, 0, 0, 0.1);
}

/* Estilos de texto de Figma → una regla por estilo */
.titulo-1 { font-size: 2.5rem; font-weight: 700; line-height: 1.1; }
.cuerpo   { font-size: 1rem;   font-weight: 400; line-height: 1.6; }

/* Modo «Oscuro» de las variables de Figma */
@media (prefers-color-scheme: dark) {
  :root {
    --color-fondo: #171815;
    --color-texto: #EDEBE4;
    --color-acento: #A5BEBE;
  }
}

Idea clave: pon a tus variables de Figma los mismos nombres que tendrán en CSS, y con nombre de función (color/fondo, color/acento), no de aspecto (verde, gris claro). Así diseño y código hablan el mismo idioma, y un cambio en la paleta se aplica igual en los dos lados.

Inspeccionar y exportar

Leer las medidas

Al seleccionar un elemento, Figma muestra sus medidas, colores y tipografía en el panel de la derecha. Con el modo para desarrolladores (Dev Mode) o la pestaña de inspección, según tu tipo de cuenta, ves además el CSS correspondiente.

• Distancias: selecciona un elemento y mantén pulsada la tecla Alt (en Mac, Option) mientras pasas el ratón por encima de otro: Figma muestra la distancia entre los dos.
• Tamaños de texto: Figma los da en píxeles. Para pasarlos a rem, divide entre 16: 24px son 1.5rem.
• Colores: cópialos en hexadecimal y guárdalos como variables, no los repitas por todo el CSS.

Ojo: el CSS que genera Figma sirve de pista, pero no lo copies tal cual. Suele traer anchos y altos fijos, posiciones absolutas y medidas en píxeles que en una web real se rompen al cambiar el tamaño de la pantalla. Úsalo para consultar valores (colores, tamaños de letra, radios, sombras) y escribe tú la estructura con Flexbox y Grid.

Exportar imágenes e iconos

El nombre de la capa será el nombre del archivo: ponlo ya en minúsculas, sin espacios ni tildes (icono-descarga.svg), como en Programación I.

Antes de pasar a código

Una lista para revisar tu archivo de Figma antes de empezar a programar:

• Los marcos y componentes usan Auto Layout.
• Los colores, textos y efectos están guardados como estilos o variables, con nombre de función.
• Hay un marco para el móvil y otro para escritorio, como mínimo.
• Los componentes tienen sus estados (hover, foco, desactivado…).
• Las capas tienen nombres claros, no «Frame 247» ni «Rectangle 12».
• Las imágenes e iconos que se van a exportar están marcados para exportar, con el formato adecuado.

El proceso de diseño

UX (user experience, experiencia de usuario) es todo lo que siente y vive una persona al usar un producto: si encuentra lo que busca, si le resulta fácil, si confía en él. La UI (la interfaz) es una parte de esa experiencia: lo que se ve y se toca. La UX abarca también lo que pasa antes y después.

El diseño de experiencia parte de una idea sencilla: no diseñamos para nosotros. Lo que a quien diseña le parece evidente puede no serlo para quien usa la web. Por eso el proceso se basa en conocer a las personas y en comprobar las ideas con ellas, en lugar de en suposiciones. Es lo que se llama diseño centrado en las personas.

El doble diamante

Es uno de los esquemas más usados para explicar el proceso. Tiene dos fases, y en cada una primero se abre (se exploran muchas posibilidades) y después se cierra (se elige):

• Descubrir: investigar sin prejuicios, hablar con personas, observar.
• Definir: resumir lo aprendido en un reto concreto.
• Desarrollar: generar y probar soluciones.
• Entregar: quedarse con la mejor, pulirla y lanzarla.

El primer diamante sirve para asegurarse de que se diseña lo correcto; el segundo, para diseñarlo bien.

Design thinking

Otra forma muy extendida de describir el mismo proceso, en cinco fases:

1. EmpatizarConocer a las personas para las que diseñas: qué necesitan, qué les cuesta, cómo usan lo que ya existe.
2. DefinirConvertir lo aprendido en un problema concreto: «quien visita el portfolio no encuentra cómo contactar».
3. IdearGenerar muchas soluciones posibles antes de quedarte con una.
4. PrototiparConstruir versiones rápidas y baratas de las mejores ideas: bocetos, wireframes, prototipos en Figma.
5. EvaluarProbarlas con personas reales, aprender de lo que falla y volver a la fase que haga falta.

Idea clave: el proceso no es una línea recta, sino un ciclo. Lo normal es que una prueba con usuarios te haga volver a idear, o incluso a redefinir el problema. Cada vuelta mejora el diseño: por eso se habla de diseño iterativo.

Usuarios y personas

Antes de diseñar hay que entender para quién. La investigación con usuarios no tiene por qué ser compleja ni cara: lo importante es salir de las suposiciones y escuchar a personas reales.

Técnicas de investigación

Personas

Una persona (en inglés se usa la misma palabra) es un personaje ficticio que resume a un grupo de usuarios reales: sus objetivos, sus frustraciones y su contexto. Sirve para que todo el equipo tenga presente para quién diseña, y para decidir con preguntas concretas: «¿Lucía encontraría esto desde el móvil?».

Ojo: una persona debe basarse en lo que has descubierto investigando, no en lo que imaginas. Una persona inventada sólo sirve para confirmar lo que ya pensabas.

Mapa de empatía

Ayuda a ponerse en el lugar de la persona usuaria ordenando lo que has observado en cuatro zonas: qué dice, qué piensa, qué hace y qué siente.

Viaje de usuario (user journey)

Describe paso a paso el recorrido de una persona para conseguir un objetivo (por ejemplo, desde que busca a alguien que le diseñe la web hasta que le encarga el trabajo), con lo que hace, lo que siente y los problemas que encuentra en cada momento. Los puntos donde aparecen problemas son las mejores oportunidades de diseño.

Wireframes y prototipos

Primero, la estructura

Antes de dibujar pantallas conviene decidir qué contenido habrá y cómo se organiza: es la arquitectura de la información, que se suele representar con un mapa del sitio. Una técnica útil para hacerlo es la clasificación de tarjetas (card sorting): escribes cada contenido en una tarjeta y pides a varias personas que las agrupen y pongan nombre a los grupos. Así descubres cómo esperan encontrar las cosas.

De menos a más detalle

Las ideas se prueban primero con poco detalle, porque cambiar un boceto cuesta minutos y cambiar un diseño acabado cuesta días. Es lo que se llama fidelidad:

• Baja fidelidad: bocetos a mano. Rápidos, para explorar muchas ideas y decidir la distribución.
• Media fidelidad (wireframe): la estructura de cada pantalla en grises, con cajas y textos de relleno. Sin colores ni tipografías definitivas, para que la conversación se centre en la organización y no en el aspecto.
• Alta fidelidad (prototipo): el diseño con su aspecto final y, a menudo, interactivo: en Figma se pueden unir las pantallas para que, al pulsar un botón, se pase a la siguiente, como si fuera la web real.

Idea clave: un prototipo no es el producto final, es una pregunta: «¿funciona así?». Su objetivo es poder probar una idea con personas antes de dedicarle el tiempo de diseñarla al detalle y programarla.

Test con usuarios

Por mucho cuidado que pongas, sólo sabrás si un diseño funciona viendo a otras personas usarlo. Un test de usabilidad consiste en pedir a alguien que haga tareas concretas con tu prototipo o tu web mientras observas.

Cómo hacer un test sencillo

1. Prepara tareas realistas: «Busca un proyecto de identidad y escribe a la autora para pedir presupuesto». No le digas dónde pulsar.
2. Pide que piense en voz alta: que diga lo que ve, lo que espera y lo que le confunde.
3. Observa sin ayudar. Es lo más difícil: si se atasca, apúntalo en lugar de explicarle. Ese atasco es justo lo que buscabas.
4. Haz preguntas neutras: «¿Qué esperabas que pasara?» en lugar de «¿A que se entiende bien?».
5. Apunta qué ocurre: si consigue la tarea, cuánto tarda, dónde duda y qué comenta.

No hacen falta muchas personas: con unas cinco ya aparecen la mayoría de los problemas importantes. Es más útil hacer varias rondas pequeñas, corrigiendo entre una y otra, que una sola ronda grande.

Evaluación heurística

Cuando no hay usuarios disponibles, se puede revisar el diseño comparándolo con unos principios de usabilidad (heurísticas). Los más conocidos son los diez de Jakob Nielsen:

1. Visibilidad del estado del sistema. La interfaz informa de lo que está pasando (cargando, enviado, error).
2. Relación con el mundo real. Usa palabras y conceptos que la gente conoce, no jerga técnica.
3. Control y libertad. Se puede deshacer, volver atrás o cancelar.
4. Coherencia y estándares. Lo que es igual se ve igual y funciona igual, y se respetan las convenciones.
5. Prevención de errores. Mejor evitar el error que explicarlo después.
6. Reconocer mejor que recordar. Las opciones están a la vista; no hay que memorizarlas.
7. Flexibilidad y eficiencia. Atajos para quien ya sabe usarla, sin complicar a quien empieza.
8. Diseño estético y minimalista. Cada elemento que sobra le resta protagonismo a lo importante.
9. Ayudar a reconocer y corregir errores. Mensajes claros, que digan qué ha pasado y cómo arreglarlo.
10. Ayuda y documentación. Si hace falta, ayuda fácil de encontrar y centrada en la tarea.

Idea clave: los problemas que encuentra un test no son un fracaso, son información. Cada problema detectado en un prototipo es uno que no sufrirá nadie en la web publicada.

Para trabajar

Los programas que usarás en las prácticas de las distintas asignaturas, y algunas alternativas gratuitas.

Código

El editor para escribir el código y los validadores para comprobar que no tiene errores.

Imagen

Para editar fotos y dibujar en vectorial, como en Medios Informáticos I.

Diseño de interfaces

WordPress

Para crear sitios web con WordPress, como en Medios Informáticos II.

Fíjate: WordPress.org es el programa, que se descarga y se instala; WordPress.com es una empresa que te lo da ya instalado en sus servidores, con un plan gratuito muy limitado y planes de pago. Con el de .org tienes control total sobre tu web.

Aprender a programar

Referencias para consultar y cursos para practicar HTML, CSS y JavaScript. Las dos primeras son las que más vas a usar.

Diseño y UX

Para profundizar en experiencia de usuario, interfaces y accesibilidad.

Inspiración

Para ver qué se está haciendo, encontrar referencias y no partir siempre de cero.

Tipografías e iconos

Recursos gratuitos para usar en tus webs. Revisa siempre la licencia de cada uno.

Imágenes

Fotografías libres para tus maquetas y una herramienta para optimizarlas.

Color

Para crear paletas y comprobar que se leen bien.

Fíjate: en el apartado de accesibilidad visual de Recursos tienes también un comprobador de contraste integrado en esta web.

Programación creativa

Para explorar el código como herramienta de expresión, no sólo para hacer webs.

Términos de la A a la Z

No hay ningún término con esa búsqueda. Prueba con otra palabra o consulta el glosario de la UOC.

Para profundizar: el glosario del Design Toolkit de la UOC recoge más términos de experiencia de usuario y diseño de interacción.