El control de versiones es una habilidad que UX puede aprender para hacer su vida más fácil | Kai Wong | enero 2023

Contenido del Articulo

El hombre se para frente al monitor mientras el resto del equipo observa y comenta.  También hay pegatinas en el tablero en la parte posterior.
Foto de Jason Goodman en Unsplash

El control de versiones para sus prototipos de diseño es una de esas cosas en las que nunca piensa hasta que lo necesita.

El control de versiones es tan importante que muchos ingenieros dedican tiempo y esfuerzo a crear o comprar estos sistemas porque realiza un seguimiento de los cambios en los sistemas y programas.

Esto puede parecer una exageración para fines de diseño, pero cuando lo necesite:

  • Versión reducida para ingenieros,
  • Edición ilimitada para equipos de producto o ejecutivos
  • Uno para cada prueba de usuario y
  • Tu versión de trabajo

Se alegrará de que el software de diseño tenga herramientas de control de versiones.

Pero para comprender este tipo de versiones, hablemos primero del control de versiones.

Control de versiones de UX: componentes, variantes y páginas

Para entender qué es el control de versiones, primero debemos hablar sobre lo que hacen los ingenieros porque lo usan todo el tiempo.

El control de versiones es un concepto que los ingenieros utilizan inherentemente para realizar un seguimiento de los cambios. Sin embargo, cuando se trata del código base de un producto, hay muchas partes que funcionan, y desea asegurarse de saber quién está trabajando en qué para poder realizar un seguimiento del progreso.

El cómic trata sobre diseñadores que nombran cosas bastante mal, incluido
https://www.commitstrip.com/es/2017/09/12/la-version-es-importante/

Si algo sale mal con la versión actual, pueden volver a la versión anterior para que funcione o crear una versión separada para probar una solución diferente.

El diseño de UX necesita adoptar este enfoque a veces, especialmente cuando sus sprints están diseñados en torno a componentes. Afortunadamente, los controles de versión están integrados en muchos programas de diseño en forma de componentes, variaciones y páginas.

Para explicar por qué, hablemos de dos versiones diferentes que quizás ya admita: el espacio de trabajo de diseño y la versión de prueba del usuario.

Espacio de trabajo de diseño de UX y versión más pequeña para pruebas

No siempre pruebas con la misma versión con la que estás trabajando.

Por lo general, desea limitar el diseño que está probando el usuario a cualquier problema sobre el que desee recibir comentarios y algunas alternativas de diseño. Además, si bien puede estar trabajando en diferentes cosas en segundo plano, es posible que no desee ponerlo a disposición del público en general.

Por último, las versiones de prueba de los usuarios suelen ser inamovibles. Por ejemplo, no desea mostrar a los participantes cinco diseños diferentes y puede vincularlos más tarde (especialmente si pregunta sobre diseños alternativos).

Aquí es donde puede usar las herramientas de control de versiones para ayudar. En lugar de recrear completamente el diseño, podemos usar nuestro sistema de versiones:

  • Componentes para hacer plantillas de elementos de diseño
  • Opciones para mostrar diferentes diseños de componentes, y
  • Páginas para tener puntos de referencia completamente separados para diferentes versiones

Aquí uso la terminología de Figma, pero la mayoría de los programas usan términos similares (en Axure, sus componentes, estados y páginas).

¿Por qué pasar por todos estos problemas de control de versiones? Bueno, la respuesta se encuentra al final del proceso de prueba del usuario: recibir comentarios en el próximo diseño.

Para entender esto, necesitamos hablar de los componentes principales.

Uso de componentes maestros en el espacio de trabajo de diseño para facilitar la iteración

En pocas palabras, los componentes maestros son la forma en que puede cambiar rápidamente varios componentes al mismo tiempo. Usarlos puede ahorrarle el dolor de cabeza de cambiar componentes individuales en su proyecto.

Visualización del componente principal y su influencia en otros componentes

Esto se vuelve especialmente importante si las pruebas de los usuarios proporcionan comentarios que sugieren cambiar varios elementos de diseño. Si tiene dos archivos separados (como probablemente debería), crearlos con el mismo componente principal le permitirá cambiar rápidamente el diseño.

Si no ha utilizado esta herramienta de control de versiones, puede volver a ejecutarla en el espacio de trabajo Diseño. Sin embargo, esta herramienta puede ayudarlo a iterar más rápido y realizar cambios en consecuencia.

Este ahorro de tiempo se vuelve aún más notable cuando necesita proporcionar versiones a otros miembros del equipo, como ingenieros.

Los ingenieros quieren que el prototipo actúe como una fuente de verdad

Mi ingeniero principal usó una vez esta frase, que tiene mucho sentido para este tipo de versión. Básicamente, lo que los ingenieros quieren es un lugar al que ir para obtener un enlace a lo que necesitan construir.

Sin embargo, surgen problemas cuando te das cuenta de que el diseño funciona idealmente 2 o 3 sprints antes que el ingeniero. Los ingenieros quieren ir al prototipo por lo que construirán este sprint (y posiblemente el siguiente), pero no quieren sorprenderse cada vez que abren un prototipo.

Si esta fuera la misma versión en la que está trabajando UX, no solo cambiaría constantemente, sino que también podría incluir trabajo más allá de lo que planean hacer durante el sprint. Esto se vuelve especialmente problemático si los sprints de trabajo se dividen por componente en lugar de por página.

Para explicar esto, veamos un componente de tabla simple.

Un ejemplo de una tabla con seis columnas: columnas A, B, C, D, E y F. Hay valores extraños debajo de algunas de las columnas.
Un ejemplo de una tabla que el diseño de UX puede desarrollar

Los diseñadores de UX pueden mirar esta tabla con todas las columnas existentes y decidir que está completa. Después de todo, estas son las columnas de información que queremos mostrar al usuario.

Sin embargo, un ingeniero de software podría ver esto y entrar en pánico. ¿Por qué? Es posible que las columnas C, D y F aún no estén conectadas al backend. Cuando ven el prototipo, pueden pensar: “Espera, ¿estoy perdiendo el tiempo conectando estos componentes en el backend (mientras construyo esta mesa)?”

He visto a equipos de ingeniería encontrar soluciones menos que estelares para esto (es decir, imprimir un prototipo y tachar X secciones en las que no han trabajado), pero puede desbaratar cosas como la alineación y el espaciado.

Tabla deformada con varias columnas eliminadas.
Lo que vi hacer a algunos ingenieros para las mesas

En cambio, es mucho más fácil para los diseñadores de UX crear una versión diferente para ellos.

Cree una versión más pequeña para ingenieros:

El primer paso en este proceso es crear una página duplicada para los ingenieros, que es lo primero que ven cuando cargan su archivo Figma. No puedo decirle con qué frecuencia escuché quejas de ingenieros cuando no estaba estructurado de esa manera.

Aquí hay algunas páginas de Figma.  La página de ingeniería está en la parte superior.
Pestaña Páginas de Figma

Desde aquí puede tomar los Componentes que creó en el espacio de trabajo de Diseño y crear Variantes con ellos.

Dos versiones de la tabla que son fáciles de componer: la superior con las columnas incompletas eliminadas y la inferior con todas las columnas.
Dos versiones de la página de la tabla: versión reducida (arriba) y versión completa (abajo)

De esta forma, los ingenieros pueden ver este diseño reducido sin tener que recrear otro componente desde cero. Esto permite a los ingenieros usar esta versión como referencia visual de lo que necesitan construir para ese sprint sin tener que interpretar lo que está construyendo.

Pero esta no es la única versión que puede necesitar.

El equipo de producto quiere hacer un seguimiento del panorama general

Finalmente, puede haber otra versión que se le pedirá que cree para realizar un seguimiento del panorama general. La situación más común que he visto para esto tiende a ser una de dos situaciones:

  • Los ingenieros quieren reducir/reducir funciones temporalmente, pero el Producto quiere mantenerlas en alguna parte.
  • El producto quiere una visión de futuro, nueve meses después Diseño para pensar

Estas versiones son mucho más progresistas, asegurando que lo que hemos reducido a corto plazo no se pierda a largo plazo.

Estas no deberían ser características exclusivas creadas simplemente por sentarse aquí: es probable que esta versión esté incompleta, y está bien. Sin embargo, dependiendo de su equipo de producto, es posible que deba trabajar un poco para modelar una visión potencial (incluso si no está finalizada).

En Articulating Design Solutions, Tom Green lo describe como “una visión ilimitada del futuro”. A veces, el equipo de desarrollo (o los ejecutivos) quieren imaginar el futuro con una característica determinada y se le pedirá que modele algo.

Por ejemplo, puede ser que la “barra de búsqueda” no solo admita la búsqueda por nombre: puede vincularse a una base de datos para encontrar personas según el SSN, la dirección u otras cosas.

Sin embargo, el ejemplo más común es con funciones de corte: un ingeniero dirá: “Suena genial, pero no podemos manejarlo ahora”, y el producto dirá: “Está bien, volvamos a esto más tarde, porque queremos Esta característica. ”

En tales casos, esta será la versión en la que vivan estas ideas. Tal vez sea necesario completarlo y conectarlo, pero la similitud general de la idea vivirá allí.

Esta es una de las mejores cosas con las que una organización de control de versiones puede ayudarlo.

El control de versiones garantiza una transición fluida y un seguimiento del “progreso”.

Si bien mantener estas diferentes versiones de un diseño puede ser un poco complicado, este esfuerzo tiene muchos beneficios.

Primero, la transición de UX a trabajo de ingeniería se vuelve mucho más manejable. Cuando un equipo ve la diferencia entre la versión Engineering Sprint del diseño y la versión UX 2 Sprints Later del diseño, se vuelve más fácil entregarlo a los ingenieros con menos preguntas. También les da a los ingenieros una idea de lo que está por venir, lo que significa que no es probable que se sorprendan.

Otro beneficio importante que ofrece es la visibilidad del trabajo de UX y la visualización del progreso en la cartera de pedidos.

He trabajado con muchos nuevos propietarios y gerentes de productos, por lo que he tratado con personas que no están familiarizadas con la escritura de historias de usuarios (y cómo UX puede encajar en la acumulación de Agile). El control de versiones ayuda con ambos.

Las versiones publicadas muestran el progreso que UX está logrando en el espacio de diseño, así como la capacidad de vincularse a un componente visual con historias de usuarios. También le permite al equipo de desarrollo alejarse y ver cómo las diferentes historias de usuario se relacionan e interactúan entre sí.

Finalmente, ayuda al UX a organizar sus proyectos de manera consistente. Es mi culpa que tengo demasiados nombres que suenan similares, lo que significa que hacer un seguimiento de la última versión puede ser difícil.

Entonces, si siente que está haciendo malabarismos con varios archivos de diseño diferentes para sus proyectos, considere usar las herramientas de control de versiones que podría tener su diseño. Esto no solo puede proporcionar las vistas especializadas que cada miembro de su equipo necesita, sino que también puede ahorrarle muchos dolores de cabeza al mantener la coherencia de sus proyectos.

Kai Wong es diseñador sénior de UX, escritor de diseño y colaborador del boletín Data and Design. Su nuevo libro electrónico gratuito, Profesional de UX persistentete enseña cómo convertirte en un candidato de UX más atractivo y encontrar el trabajo de UX de tus sueños.

Previous post Marketing indirecto: definición, tipos y ejemplos
Next post Conceptos básicos de la plantilla de calendario de redes sociales

Deja una respuesta