Un diseño funcional, bonito y simple está bien.
Pero un diseño funcional, bonito, simple y fácil de maquetar está mucho mejor.
O como dijo Charles Eames:
Los detalles no son los detalles. Los detalles son el diseño.
Habla con tu equipo de maquetación. Seguro que te enseñan cómo mejorar como diseñador.
Preparando un documento de análisis para un cliente, me he encontrado en mi fondo de armario un enlace a las bases de la filosofía UNIX y no puedo dejar de pensar en lo bien que aplican estas reglas al mundo del diseño de interacción.
Las 17 reglas en versión resumida vienen a decir (perdón por la traducción al vuelo):
Regla de Modularidad: Escribe partes simples, conectadas por interfaces simples.
Regla de Claridad: ser Claro es mejor que ser ingenioso.
Regla de Composición: Diseña programas para que se conecten a otros programas.
Regla de Separación: Separa las reglas del funcionamiento; separa los interfaces de los mecanismos.
Regla de Simplicidad: Diseña para la simplicidad; añade complejidad sólo donde sea estrictamente necesario.
Regla de Parsimonia: Escribe un programa complejo sólo cuando sea evidente que no existe otra solución posible.
Regla de Transparencia: Diseña para la visibilidad, para hacer más fácil la inspección y la corrección de fallos.
Regla de Robustez: la Robustez es hija de la transparencia y la simplicidad.
Regla de Representación: Convierte el conocimiento en datos, para que la lógica de los programas pueda ser estúpida y robusta.
Regla de Mínima Sorpresa: En diseño de interfaces, haz siempre lo menos sorprendente.
Regla de Silencio: Cuando un programa no tenga nada sorprendente que decir, no debería decir nada.
Regla de Reparación: Cuando tengas que mostrar un error, falla estridentemente y lo antes posible.
Regla de Economía: el tiempo del programador es caro; consérvalo sobre el tiempo de la máquina.
Regla de Generación: Evita hacer cosas a mano; escribe programas que escriban programas siempre que puedas.
Regla de Optimización: Prototipa antes de pulir. Haz que funcione antes de optimizarlo.
Regla de Diversidad: Desconfía de todo lo que diga “esta es la única forma correcta”.
Regla de Extensibilidad: Diseña para el futuro, porque estará aquí antes de lo que piensas.
El único cambio que creo necesario para añadirlo a mi arsenal de Fundamentos de Diseño es reescribir la regla 13 como “el tiempo del usuario es caro; consérvalo sobre el tiempo del diseñador” (pensando en la Ley de Tesler).
En el mundo de la consultoría existe una especie de tabú hacia ciertos términos. Uno de ellos es problema.
Un consultor te hablará de “oportunidad”, “desafío” o “reto”, pero nunca te dirá “tienes un problema”.
En el mundo del diseño, donde nos gusta llamar a las cosas por su nombre, nos dedicamos a resolver problemas, y para ello una de las habilidades imprescindibles en nuestro arsenal es saber preguntar.
Definición: Cuando en este post digo “saber preguntar”, me refiero a “una colección de técnicas que nos permiten obtener toda la información necesaria para localizar y empezar a resolver un problema de comunicación de forma eficaz”.
Reflexionando sobre mi forma de preguntar, estas son algunas claves que he encontrado, sin ningún orden aparente:
Saber preguntar implica identificar el contexto del problema.
“Contexto” puede ser algo tan obvio como “presupuesto”, o algo tan sutil como la agenda oculta del jefe de nuestro cliente. Yo diría que la gran mayoría de los “imprevistos” en el desarrollo de un proyecto provienen de un contexto poco investigado.
Aunque parezca una obviedad: tu misión es averigüar cuál es el problema en realidad.
No lo que el cliente dice que es el problema.
No lo que el cliente piensa que es el problema (a veces un cliente no dice todo lo que piensa. Por eso preguntamos :).
No lo que el cliente está haciendo o quiere hacer para solucionar su problema.
El problema.
Si no sabes qué quiere conseguir tu cliente, no sabrás si has solucionado su problema.
Para esto vienen muy bien metodologías como el “Effect Management” de inUse, o algo tan simple como un checklist de objetivos.
Preguntas clásicas
¿por qué?
Te servirá para descubrir la motivación de tu cliente. La idea es preguntar por qué ad-infinitum, con la sana intención de encontrar “el momento ¡ahá!”, esto es, el momento en que el cliente decide pasar de la idea a la acción, el momento “detonante” de la decisión de actuar, el origen del proyecto.´
Sólo si eres capaz de ponerte en el papel de tu cliente en el momento de tomar la decisión de contratar a un diseñador, serás capaz de resolver su problema real.
A mi me gusta llamarlo “ver el big bang en directo” :)
¿para qué?
O “qué se supone que tiene que conseguir esta jugada”. Ya sea “más usuarios registrados”, “registro en 5 minutos” o “mejorar la imagen de la marca”.
¿quién lo pidió?
Esto es algo que casi nunca preguntamos, pero es vital. No es lo mismo resolver los problemas de tu cliente que los del jefe de tu cliente.
¿qué quieres conseguir?
Que no es lo mismo que “para qué”. Aquí es donde intentamos detectar si nuestro cliente tiene algún tipo de “agenda oculta” o motivación personal no documentable, por ejemplo “quedar bien con dirección”, “justificar la existencia del departamento”, o “llamar la atención en medios de comunicación”. Por muy marciano que suene, este es el tipo de información que puede convertir un potencial infierno en un proyecto redondo.
Como cierre de este tostón, un apunte breve: obtener información preguntando es tu obligación como (buen) diseñador.
Y así de repente, creo que es todo lo que se me ocurre sobre obtener información. Algún día veremos qué hacer con ella :)
Via Daring Fireball me encuentro un enlace con Los diez mandamientos del diseño de Dieter Rams (para quien no lo conozca, uno de los mayores/mejores diseñadores industriales y de producto que ha conocido el mundo)
Vienen a ser estos:
Con el primer punto no estoy de acuerdo en absoluto (y me consta que no soy el único), pero creo que cumplir (o al menos observar) los otros nueve debería ser un requisito imprescindible de todo el que lleve la palabra “diseñador” en su tarjeta de visita.
Nueva entrega de la serie. Hoy, nuestro fundamento dice:
Diseña para lo más probable, para lo más pequeño, y para lo más salvaje.
Un ejemplo:
Siguiendo con la serie de fundamentos de diseño, el de hoy (que tiene mucho que ver con el anterior) dice así:
Cuando utilices un recurso, usa la mínima cantidad necesaria para que siga expresando tu intención.
Donde “mínima cantidad necesaria” significa “usa los recursos como si te cobraran por ellos”.
Recuerda también que no todos los recursos “cuestan” lo mismo. Personalmente, yo los ordeno como espacio < color < espacio + color < forma < forma + color.
Es decir, que si quiero expresar que dos elementos son distintos primero intentaré separarlos sólo con espacio. Si no es suficiente intentaré diferenciarlos sólo con color. Si aún así no es suficiente, recurriré a espacio + color. Si necesito más expresividad, usaré la clásica línea de separación. Y si aún así no queda claro, el último recurso es la forma + color (por ejemplo: meterlo en una cajita naranja :)
Un corolario de esta norma es esta cita de Antoine de Saint-Exupery:
La perfección se consigue, no cuando no hay más que añadir, sino cuando no hay nada más que quitar.
¡Hasta la próxima!
Cuando estés diseñando algo, expresa claramente tu intención.
Cuando tu intención sea alinear elementos, usa guías y retículas. Ajusta al milímetro, al pixel.
Cuando no alinees, separa tus elementos lo suficiente como para dejar clara tu intención.
Un corolario de este fundamento es el siguiente:
Si un elemento de tu diseño no tiene intención, plantéate si lo necesitas
Y tú: ¿qué fundamentos de diseño quieres compartir? Añádelo a los comentarios (o publícalo en tu blog :)
Equilibra tus márgenes. El 99% de las veces estará bien, y en el 1% de los casos restantes estará medio bien, que es mucho mejor que nada…
…no es su dominio de la tipografía, ni del color, ni de la composición, ni de las herramientas.
La mayor cualidad de un diseñador es saber escuchar.
Ya está, ya lo he dicho.
Preparando mis notas para unas clases que daré próximamente, me doy cuenta de que tengo un mini artículo pendiente de publicar sobre el “diseño para la incertidumbre”: la Regla de 0-1-n.
Es un teorema/principio/hipótesis/regla empírica, que tiene sus raíces en el mundo de la programación. Mi fuente de inspiración fue el Wiki de C2 (una joya de la información, por cierto)
La regla, en su versión diseñosa, viene a decir:
Cualquier elemento de diseño puede existir cero, una, o infinitas veces.
Destripemos la frase un poco:
Cualquier elemento de diseño se refiere a “cualquiera”. Iconos, botoncillos, cajas de texto, elementos de menú…
puede existir cero quiere decir que no existe. Punto pelota. “El site no tiene menú a la izquierda”. “No hay buscador”. “Un post nunca llevará una imagen”
una quiere decir 1, la unidad, sólo uno de ese tipo. “El logo estará arriba a la izquierda”. “La caja de búsqueda estará arriba la derecha”.
o infinitas veces pasando del 1, el resto de los números no significan nada. Si el blog tendrá más de 1 post en portada, debería poder tener 5, ó 20, ó 500.
Un porcentaje muy importante de los problemas de diseño* que me encuentro tienen su raíz en no observar esta regla. No importa que hayas definido que tu portada de periódico tendrá 2 destacados. Mañana sucederán 5 cosas tan importantes que tendrán que destacarlas en portada.
* “diseño” se usa aquí en su acepción más amplia, incluyendo arquitectura de información y HCI.
Mi consejo es bastante simple: el único número al que deberías cogerle cariño es el 1. Los demás no existen. Invierte tu tiempo diseñando sistemas flexibles que admitan crecimiento ilimitado, no en cuadrar pixels para que quepan las 3 promos en el ancho de la columna ;)