Muerte al Wireframe. ¡Directo a la alta fidelidad!

El diseño UX es una disciplina fascinante. Para hacerlo bien, los profesionales deben estar bien versados ​​en una amplia variedad de temas y habilidades. Para practicar la metodología de diseño centrada en el usuario y crear soluciones innovadoras y fáciles de usar para los desafíos cotidianos de diseño de productos, el oficio y la comprensión de un profesional de UX involucra todo, desde el dibujo básico hasta el diseño narrativo/de viaje y la psicología cognitiva.

Hay una amplia variedad de herramientas utilizadas, artefactos generados y hallazgos descubiertos en el proceso de diseño de UX/UI, y se capturan en una variedad de documentos o incluso en un prototipo. Nuestro artefacto de pan y mantequilla más reconocible es la buena estructura alámbrica.

Los wireframes, generalmente esqueletos monocromáticos de diseños creados para una evaluación rápida, son geniales. Nos permiten traducir los aportes de muchas partes no relacionadas en un documento que todos pueden revisar. Muchas funciones de trabajo diferentes evalúan wireframes; analistas de negocios, gerentes de proyectos, ejecutivos de marketing, todo tipo de diseñadores y desarrolladores, varios otros proveedores y proveedores de servicios, incluso el público objetivo cuando se prueba el producto. El wireframe permite que todos vean cómo se abordarán sus necesidades individuales y le da a todo el equipo la oportunidad de resolver todos los problemas antes de que ocurra cualquier trabajo pesado.

Hay pros y contras, pero en ciertos casos, tiene sentido omitir la fase de estructuración por completo. Se podría ahorrar mucho tiempo manejando la UX y el diseño visual en el nivel de alta fidelidad inmediatamente después del descubrimiento o mientras se prepara para la creación de prototipos. Esto daría a otros la oportunidad de evaluar tanto la funcionalidad como la apariencia del producto al mismo tiempo, desde participantes de pruebas de usuarios hasta clientes y colegas.

Averigüemos por qué los wireframes a veces pueden ser problemáticos, cuándo omitirlos tiene sentido y cómo adaptar un proceso sin wireframe a un flujo de trabajo.

El problema con los wireframes

Ya sea en un entorno de cascada o ágil, el proceso de diseño típico incluye fases de investigación, definición, creación de ideas, creación de prototipos, pruebas e implementación, así como muchos puntos de contacto para la revisión con las partes interesadas a lo largo del camino.

Veamos el proceso de diseño para ver ejemplos en los que el diseño de estructura alámbrica puede ser un cuello de botella:

Razón 1: los clientes no entienden lo que están viendo

El proceso de diseño generalmente comienza con algún tipo de investigación sobre el problema. La investigación documental, las entrevistas con las partes interesadas y las entrevistas con los usuarios son solo algunas de las actividades que se pueden realizar para obtener una comprensión más profunda. Después de la investigación, el equipo de diseño comienza a evaluar una serie de ideas y conceptos para encontrar la mejor solución.

Cuando un concepto está más desarrollado, el equipo de diseño a menudo comparte una serie de esquemas con el cliente durante una sesión de revisión.

El problema es que los wireframes son muy abstractos.

Describen algo que es como la cosa, pero no la cosa real que se construirá. En esta etapa, los wireframes contendrían imágenes de marcador de posición y todo tipo de TK (por venir), FPO (solo para colocación) y TBD (por decidir), como el ejemplo a continuación.

Probablemente haya detalles sobre la funcionalidad, los requisitos comerciales y el manejo de errores que se indicarán en una enorme lista de anotaciones. Por lo general, nunca hay suficiente tiempo para revisarlos con gran detalle, por lo que el cliente tendrá que leerlos por su cuenta.

Durante las revisiones de wireframe, les pedimos a nuestros clientes que se concentren en el concepto que se describe y que evalúen si parece estar resolviendo los problemas comerciales y de los usuarios. Sin embargo, todavía recibimos preguntas sobre cosas que, para nosotros, no parecen estar relacionadas. Los clientes quieren saber si la estructura alámbrica es la "copia final" o si pueden ver ejemplos de las fotos que se mostrarán en la imagen principal, u otra pregunta sobre algo que se manejará en el diseño visual, la creación de prototipos de interfaz de usuario o el desarrollo.

Los wireframes pueden ser demasiado abstractos para que los clientes e incluso las partes interesadas internas los evalúen de manera efectiva. Los wireframes le dicen a la gente cómo va a ser un diseño cuando esté terminado, pero todavía tienen que hacer mucho trabajo mentalmente para que se una en sus cabezas. Nuestros clientes pueden o no ser pensadores visuales, y puede ser demasiado esperar que miren un plano e imaginen un producto o sitio exitoso.

Hubo algunos clientes que solicitaron específicamente revisar los diseños visuales anotados porque es mucho más fácil para ellos conectar los puntos, tener una discusión reflexiva y dar comentarios bien considerados.

Razón 2: no siempre son adecuados para las pruebas de usuario

Con suerte, se han programado algunas pruebas de usuario en el proceso de diseño, ya que es una buena manera de probar todo, desde la viabilidad de un concepto completo hasta el nivel de detalle para mostrar en una transacción.

Una forma típica de probar este tipo de cosas es mediante la creación de prototipos.

Los wireframes pueden, y funcionan, para la creación de prototipos. El equipo de diseño se limita a probar únicamente el flujo y la funcionalidad, y debido a que carece de una capa de diseño visual, los estilos visuales que afectan el comportamiento del usuario pueden ignorarse fácilmente.

¿Es esto sabio? El diseño de UX, visual y de copia se impactan entre sí. Es difícil separarlos y aislarlos en un entorno de prueba. De manera similar a un estudio científico, los resultados de una función probada de forma aislada no pueden controlar ni predecir cómo se comportará en la naturaleza.

A veces, es más efectivo probar todas estas cosas juntas de manera integral.

Caso en cuestión: un producto o servicio multilingüe. Los idiomas pueden tener diferentes gramáticas, alfabetos y anchos de caracteres que podrían afectar el diseño general.

Además, dado que el contenido de la copia afecta la UX, la traducción en sí misma puede afectar la UX.

Por ejemplo, teníamos una tarea en la que debíamos probar algunas arquitecturas de información diferentes debido a que era necesario explicar varios conceptos en el idioma local. No habríamos descubierto el impacto en la redacción y la traducción sin probar la copia real en la interfaz de usuario.

Descubrimos que se necesitaban más palabras para describir conceptos similares en el idioma local y que tendríamos que modificar el tamaño y la forma de los botones globalmente para acomodar la redacción detallada requerida para ese idioma. Sin concentrarnos en los problemas de texto mientras probamos los componentes visuales reales en la interfaz de usuario, no habríamos descubierto que los botones debían ocupar todo el ancho de la pantalla móvil, lo que afectó nuestro diseño de UX en el futuro.

Conclusión clave: tiene sentido preparar interfaces de usuario de alta fidelidad desde el principio, especialmente para un proyecto multilingüe.

Razón 3: Convierten la vida en un infierno para los desarrolladores y el control de calidad

Lo que sucede inevitablemente durante la fase de diseño visual es que todo se mueve. Las imágenes apiladas se convierten en mosaicos. El texto centrado se alinea a la izquierda. Los íconos de activación del acordeón eran + y - , pero ahora son un par de cheurones.

Esta es una parte normal del proceso de diseño visual. Lo que también es normal es que cualquier cambio realizado en el diseño visual no se reflejará en los esquemas porque los esquemas se han "aprobado".

Cuando se aprueban todas las imágenes, es hora de entregar todo a los desarrolladores. En la mayoría de los casos, recibirán un conjunto de wireframes detallados y anotados y un conjunto de hermosos diseños visuales junto con una guía de estilo. Ahora depende de ellos hacer una referencia cruzada entre estos dos documentos y darle vida.

Esta es un área donde el proceso de diseño realmente puede fallar. Damos a los desarrolladores demasiados documentos para consultar y dejamos que ellos determinen qué información tiene prioridad. Esto aumenta la cantidad de tiempo necesario para las llamadas de soporte y el control de calidad, lo que naturalmente afecta el tiempo que se tarda en lanzar un producto o una actualización al mercado.

¿Por qué no dar a los desarrolladores un documento preciso que incluya todo? La mayoría de los clientes también apreciarían una copia para usar como referencia completa para el trabajo.

La solución: Saltarse los wireframes

Claramente, hay ocasiones en las que es necesaria una fase de estructura alámbrica completa y otras en las que no. Incluso hay momentos en los que ir directamente a la alta fidelidad supera por completo la fase de estructura alámbrica.

Podría considerar omitir la fase de estructura alámbrica si alguno de estos es cierto:

Hay material de referencia sólido en su lugar.

Eche un vistazo al trabajo existente en su lugar. Es posible que ya haya referencias de IU detalladas disponibles. Si está realizando actualizaciones en un sitio web existente o agregando una nueva característica a una aplicación existente, busque en el sitio web y la aplicación actuales para encontrar patrones y estilos para reutilizar.

Sería aún mejor si tuviera acceso a los archivos fuente del trabajo existente. Es posible que algunas funciones y elementos se hayan perdido en la traducción, por así decirlo, durante el proceso de desarrollo, y podría consultar el archivo fuente para ver cómo debería haberse hecho esa función.

Además de (o en ausencia de) un producto o sitio existente, verifique si existe una guía de estilo o una biblioteca de patrones. Es posible que el cliente ya haya pagado por algunos trabajos de diseño visual y de marca, y estos recursos podrían reutilizarse nuevamente para su proyecto.

Utilice tantos estilos y patrones como pueda encontrar para que sus resultados de alta fidelidad sean lo más precisos posible.

Ha programado una gran cantidad de prototipos y pruebas iterativas en el camino.

Ahórrese un poco de esfuerzo durante las semanas de creación de prototipos y pruebas. Si configura su documento con cuidado la primera vez y hace un uso inteligente de los estilos, patrones y símbolos repetidos, puede realizar fácilmente actualizaciones incrementales en alta fidelidad y publicarlas directamente en su flujo de trabajo de creación de prototipos. No se necesita estructura alámbrica.

Como gran ventaja, puedes matar dos pájaros de un tiro. Puede obtener comentarios visuales y de UI junto con sus comentarios de UX y realizar todos estos cambios de una sola vez.

Los participantes de su prueba son muy literales.

Así como sus clientes y compañeros de trabajo a veces pueden requerir ejemplos concretos, también lo puede necesitar el público objetivo de su proyecto.

Un trabajo reciente me hizo diseñar pantallas financieras para un público objetivo con bajo nivel de alfabetización. La comprensión de lectura no fue el único problema: los conceptos abstractos a menudo eran muy difíciles de abordar. Este público objetivo normalmente necesitaba discutir conceptos financieros usando ejemplos concretos; de lo contrario, no pudieron seguir realmente la conversación.

Para comprender los conceptos financieros, los participantes de la prueba en esta audiencia necesitaban sentir que realmente estaban realizando transacciones. Y para entender cómo funcionaba el producto, necesitaba verse y sentirse como una aplicación real.

¡Olvídate de los wireframes para una audiencia como esta! Terminará pasando mucho tiempo explicando qué son, y su audiencia no se centrará en las tareas, ni en cómo se sienten acerca de ellas porque no pueden relacionarse con el uso de algo tan desconocido en sus vidas.

Su cliente tiene tiempo y/o presupuesto limitado.

Es raro tener el tiempo, los recursos y el presupuesto a su favor. A menudo puede encontrarse tratando de reducir el alcance y el precio, o luchando para ver dónde puede escatimar y ahorrar y aún así brindar un gran servicio a su cliente.

Si tiene un cliente que no puede pagar (o que no es probable que compre) un trabajo completo de UX, ¿puedo sugerirle que reduzca el tiempo de creación de esquemas? Cree algunos internamente si es necesario, pero mantenga el proyecto en movimiento para su cliente. Pruebe diseños reales y tangibles y haga que su cliente reaccione al trabajo real.

Cómo matar la fase de estructura metálica

Esta parte es bastante subjetiva, ya que dependerá de tu flujo de trabajo personal y de las necesidades específicas de tu cliente.

Dicho esto, esta es una "plantilla" de proceso que inicialmente podría intentar adaptar a su flujo de trabajo y luego modificar a medida que tenga más práctica trabajando de esta manera.

Paso 1: Comience con su proceso habitual de investigación y descubrimiento.

Entrevistas, observaciones de campo, investigación de escritorio, análisis competitivos, sea lo que sea que haga normalmente (o tenga programado hacer), complete esta fase como lo haría normalmente.

Paso 2: Dibuja un poco a lo largo del camino.

Mientras realiza la investigación, probablemente obtenga algunas ideas para diseños y patrones útiles, flujos atractivos y similares. Grábelos como lo haga normalmente. Me gusta hacer bocetos en miniatura en mi cuaderno, con notas escritas al lado. Es posible que prefiera dibujar en una pizarra o tomar capturas de pantalla de patrones de interfaz de usuario interesantes. Cualquier cosa que te ayude a recordar buenas ideas, hazlo.

Paso 3: Prepara tu documento de alta fidelidad

Abra la herramienta de diseño de su elección y configure su documento correctamente. Elija algunos tamaños de mesa de trabajo y comience a crear formas, grupos y símbolos repetibles.

Tómese el tiempo para guardar la paleta de colores de la marca como muestras individuales, cree y organice estilos de letra y cree sombras paralelas y filtros estándar que pueda aplicar en todas las formas según sea necesario.

Dedique mucho tiempo a hacer que sus símbolos sean perfectos. Es posible que tenga un botón que, dependiendo de su estado, podría tener cuatro colores diferentes. Utilice anulaciones de símbolos, si puede, para que pueda aplicar fácilmente diferentes colores y etiquetas de texto según sea necesario.

Si se utilizan iconos personalizados, guárdelos como símbolos individuales en una mesa de trabajo cuadrada (o en la forma que sea adecuada). De esa manera, será fácil para usted escalarlos hacia arriba y hacia abajo mientras mantiene el espacio y la alineación adecuados.

Paso 4: Comienza a diseñar.

Su primera ronda puede ser un poco difícil a medida que se acostumbra a trabajar de esta manera y ver dónde se mantiene su guía de estilo (y dónde no). Además de crear soluciones para patrones que aún no tienen un estilo definido, espere hacer algunos ajustes para obtener todos los estilos correctos.

A lo largo de este proceso, vaya con una buena "dirección de copia" o con una copia real si la tiene. No haga títulos que digan: "El título de la página va aquí". Dale al espectador una idea de lo que pasaría aquí si fuera real.

Del mismo modo, no cree una lista de nombres que digan John Smith con el número de teléfono 555-1212. Use un generador de listas aleatorias o un complemento para hacer diferentes nombres y números, o cree cualquier conjunto de datos que necesite mostrar. Esto puede parecer excesivo, pero le permite resolver problemas con el diseño y el ancho de los caracteres, y ayuda a su espectador a comprender que esas cinco entradas son todas diferentes.

Paso 5: Sepa cuándo dejar de diseñar.

Hay algunos detalles de los que no debes ocuparte en este momento porque realmente llevarán demasiado tiempo. Tal vez sea elegir la imagen exacta para entrar en un héroe o diseñar un ícono personalizado para indicar un estado de descarga. Estos son algunos casos en los que puede optar por utilizar una imagen o icono de marcador de posición y probar imágenes o iconografía reales en una fecha posterior.

Tendrá que hacer la llamada sobre lo que es apropiado aquí, ya que dependerá de los objetivos del proyecto, así como de qué tan avanzado esté con él.

Tenga en cuenta que puede depender de lo que necesiten los participantes de la prueba de usuario para evaluar correctamente el trabajo. Para el público objetivo con bajo nivel de alfabetización que mencioné anteriormente, nada era demasiado detalle. Para cada participante, hice una variante del prototipo con su nombre real y número de teléfono para que la aplicación realmente se sintiera como "suya". Cuanto menos tenían que asumir, más fácil les resultaba seguir y mejores eran mis resultados.

Paso 6: Disfrute de comentarios y resultados de pruebas de alta calidad.

Publique sus diseños directamente en la herramienta de creación de prototipos que elija y llévelos al campo para probarlos. Ahora puede recibir comentarios sobre algo más que la funcionalidad. Puede descubrir posibles problemas visuales, como problemas con el contraste de color o la legibilidad, y puede descubrir problemas con la dirección de copia o la traducción. También puede descubrir los sentimientos positivos o negativos que los usuarios pueden tener sobre la apariencia o la marca.

Estas son todas las cosas sobre las que probablemente iba a recibir comentarios de todos modos cuando llegara a la fase de diseño visual. ¿Por qué no obtener todos esos comentarios ahora? Algunos de los comentarios sobre las imágenes podrían afectar directamente a la UX, y viceversa, por lo que es bueno resolver todo esto al mismo tiempo, si es posible.

Terminando

Sin duda, hay muchos casos en los que es necesaria una fase completa de estructura alámbrica para el éxito del proyecto. Un diseño complejo, como una aplicación web receptiva, necesita un enfoque separado y dedicado a los wireframes. Se ahorraría tiempo y dinero resolver todos los requisitos comerciales, los casos extremos y el manejo de errores en la etapa de estructura alámbrica, de lo que sería si ya se hubiera conceptualizado y aplicado una capa visual completa.

Sin embargo, en los casos correctos, pasar directamente a la alta fidelidad puede mejorar su proceso:

• Mejorar la retroalimentación de las partes interesadas . Los clientes, desarrolladores, otros diseñadores y participantes de la prueba del público objetivo pueden ver exactamente lo que obtendrán, lo que les permite brindar comentarios de mayor calidad.
• Acelere su flujo de trabajo de creación de prototipos . Sus diseños no solo estarán listos para probarse de inmediato, sino que también puede obtener comentarios sobre varias cosas a la vez: la UX, la copia y las imágenes.
• Entregar un único documento a clientes y desarrolladores . Elimine la necesidad de hacer referencias cruzadas y verificar una variedad de documentos para comprender cómo debería funcionar un botón. Esta también es una excelente manera para que su cliente discuta el trabajo con sus partes interesadas internas para obtener aún más comentarios.
• Ahorre tiempo y dinero . ¡Y eso es casi siempre algo bueno!

Pruebe este enfoque la próxima vez que tenga un proyecto en el que tenga algunos materiales de diseño existentes para consultar, o en el que supondrá una gran diferencia para su audiencia si el trabajo es de baja o alta fidelidad.

• • •

Lectura adicional en el blog de diseño de Toptal:

• eCommerce UX: una descripción general de las mejores prácticas (con infografía)
• La importancia del diseño centrado en el ser humano en el diseño de productos
• Los mejores portafolios de diseñadores de UX: estudios de casos y ejemplos inspiradores
• Principios heurísticos para interfaces móviles
• Diseño anticipatorio: cómo crear experiencias de usuario mágicas