11 cosas que aprendí durante mi primer año de trabajo como diseñador UX/UI en una casa de software

En realidad, ha pasado más de un año desde que comencé mi primer trabajo como diseñador de UX/UI en una casa de software. Si bien algunas personas piensan que no es el mejor lugar para comenzar su experiencia UX/UI debido a la variedad de proyectos y la independencia requerida, no tuve muchos problemas con eso. Estaba trabajando como asistente de arquitectura para un estudio bastante grande y como “freelance” para una organización estudiantil en relaciones públicas y diseño gráfico.

Sin embargo, no todo fue sol y arcoíris . Me tomó menos de cuatro meses entre la decisión de cambiar de marca y el comienzo de mi primer trabajo y, como resultado, no pude aprender ni comprender todas las áreas necesarias para el puesto. En general, a los jóvenes no se les enseña mucho sobre la importancia de la cooperación entre diferentes equipos en las empresas, principalmente la parte comercial y de ventas del proyecto.

Aquí hay algunos problemas que encontré durante mi primer año en el diseño de UX/UI:

1.MVP y KPI

Estos eran conceptos casi completamente extraños que encontré mientras trabajaba en mi primer proyecto. Es cierto que fue un proyecto interno, pero el trabajo fue casual y pude preguntar a cada participante del proyecto sobre varios temas. Fue entonces cuando conocí a los analistas de negocio y su papel en el proyecto. Aprendí sobre el lado comercial de los productos, que resultó ser la parte más esencial de ellos en las casas de software. Al tener experiencia en una industria anterior, los MVP y los KPI pueden haber existido ocultos bajo otros nombres, pero la determinación práctica de ellos durante los talleres con los clientes fue lo que experimenté aquí.

2. Requisitos comerciales, recopilación de requisitos, confirmación con el cliente, realización de confirmaciones

En mi opinión, esta es la parte más esencial del trabajo de un diseñador de productos. En la empresa, yo era parcial o totalmente responsable de recopilar los requisitos y confirmarlos con el cliente, a veces en sociedad con un analista comercial que penetró suavemente en la estructura del cliente y reunió los requisitos comerciales. En esta etapa, es esencial conocer la industria y los procesos del cliente, explicarle por qué estamos haciendo esto (si no lo sabe) y, de hecho, recopilar constantemente esta información sobre el producto que se está diseñando. Hice esto escribiendo historias de usuarios y criterios de aceptación y riesgos potenciales. Para el cliente, el aspecto visual del producto que nos pide ya es importante en esta etapa, por lo que la forma más atractiva de recoger tales requisitos es hacer maquetas mid-fi, es decir maquetas con contenido parcialmente propuesto. Es importante recordar que esta es una de tantas propuestas que se pueden presentar, por lo que no vale la pena apegarse a tal versión del proyecto. En esta etapa, también debe tener en cuenta la claridad del flujo de información, estableciendo cómo el cliente recopila y confirma los requisitos. Sin cerrar esta etapa, no puede avanzar con el desarrollo debido a los riesgos potenciales: cambiar las decisiones tomadas o agregar nuevos requisitos, lo que afecta el cronograma del proyecto. También sucede que creamos un producto, recopilamos requisitos, tal vez ya estamos en la etapa de aceptación de documentación o incluso de desarrollo, y de repente el negocio (es decir, los usuarios) declara que no entiende el proceso.

3. Estimación del tiempo: subestimación o sobreestimación

El hecho es que la mayor parte del tiempo se dedica a crear maquetas, personalizar bibliotecas existentes o crear bibliotecas personalizadas y redactar documentación. A menudo es muy difícil para los diseñadores novatos estimar el tiempo que dedicarán a esto, y de alguna manera tienen que hacerlo. Varias veces he subestimado el tiempo dedicado a una tarea en particular, y una vez incluso lo sobreestimé, pero en mi opinión, esta habilidad viene con la experiencia. Es bueno tener un cierto margen de tiempo en tal situación; siempre es mejor entregar algo más rápido que tarde.

4. El timón, la vela y el barco: autosuficiencia

Hasta ahora, en mi experiencia, solo he tenido que tomar el control de los aspectos más pequeños de los proyectos, como la coordinación de instalaciones en los techos de habitaciones y pasillos de hoteles o las llamadas partes traseras de la casa. Como diseñador de UX/UI después de que me asignaran oficialmente a mi primer proyecto, era mucho más responsable del producto, ya que era el único diseñador en el equipo del proyecto. Por un lado, esto fue ennoblecedor para mí, pero por otro lado, fue mucha responsabilidad y confianza general por parte de la empresa. Hasta ahora no sé si me convenía, quizás era demasiado pronto para ser el único responsable del producto como una persona con poca experiencia en la industria. Fue una gran prueba para mí, pero que yo sepa, tanto el cliente como el equipo estaban contentos conmigo, así que supongo que logré ejecutar bien estas tareas del proyecto para ese momento después de todo

5. Investigación en la etapa UX, o mejor dicho, la falta de ella

Los clientes a menudo no tienen conocimiento del punto de realizar una investigación de UX en la etapa de diseño (y si lo saben, ¡agradezca a su departamento de ventas por un cliente tan informado!). Esta es la desventaja general de las casas de software. En las empresas de productos, a partir de mis conversaciones en reuniones y conferencias, quedó claro que, lamentablemente, este tampoco es el estándar cuando se trata del proceso de diseño. Sin embargo, siempre vale la pena realizar la presentación al cliente sobre la investigación de UX y presentar por qué es importante y cuánto puede ahorrar tiempo. El primer ejemplo desde la orilla: estaba desarrollando un producto cuyo proceso comercial era bastante complicado de entender, como resultó, no solo para mí, porque los usuarios no lo entendieron bien. Junto con el cliente, tuvimos que volver a la etapa de levantamiento de requisitos, reunirlos nuevamente después de aprender más sobre el proceso, mejorar las maquetas y continuar con el desarrollo. Esto podría haberse evitado si hubiéramos tenido un momento para crear prototipos de las maquetas y realizar pruebas de usabilidad con futuros usuarios (empleados de uno de los equipos del cliente). Incluso entonces, habríamos identificado los problemas que surgieron mucho más tarde.

6. Creación de documentación

Este es realmente un trabajo necesario para que el cliente lo verifique. Para crear la documentación de UX, utilicé el artículo detallado de Autentika sobre la preparación de la documentación (https://autentika.pl/blog/po-owocach-uxa-poznacie-czyli-moment-przekazania-projektu-do-wdrozenia/en polaco).

Me fue muy útil para crearlo, pero no fue suficiente al 100%. Los diagramas de proceso en el producto que estaba creando en ese momento eran MUY complicados, así que acudí a los analistas por una razón y, con su ayuda, creé una especificación de caso de uso y requisitos de proceso más detallados con criterios de aceptación. Por supuesto, ahora haría esa documentación de manera un poco más diferente, pero en ese momento estaba bastante satisfecho con ella.

7. ¿Metodologías? ¿Existen? (No)

La mayoría de las casas de software intentan trabajar de manera iterativa, con un enfoque individual para el cliente. Es difícil planificar procesos de libros en tales situaciones, especialmente porque rara vez se realiza una investigación de tablero a tablero porque “no hay tiempo” o trabajas como un único diseñador. En última instancia, la metodología de diseño se basa en Agile, pero los marcos son bastante similares entre sí y se pueden dividir en etapas de Descubrir, Definir, Diseñar, Desarrollar y Entregar/Implementar (como una 5D extendida con una etapa de Double Diamond) .

8. Entender al cliente

Este es el núcleo de la cooperación con el cliente a nivel de diseño de la aplicación. A menudo, los clientes (especialmente de las industrias que no son de TI) no saben qué es UX, de qué se trata, qué problemas puede eliminar en las primeras etapas del proyecto. Un buen ejemplo de mi experiencia sería cuando estaba presentando maquetas de baja fidelidad para completar los requisitos comerciales. La reunión también incluyó al equipo de marketing del cliente, que estaba muy inseguro... sobre el diseño de las maquetas de baja fidelidad. Como no todos estaban en la misma página, volví a hablar sobre el hecho de que las maquetas solo tenían la oportunidad de hablar sobre la funcionalidad y cómo debería funcionar el producto. Desafortunadamente, esto no impidió que marketing comentara sobre los tipos de letra utilizados en las maquetas, lo que no tuvo relación con el diseño de la aplicación en ese punto del proyecto . Al final, el tema se resolvió bastante rápido y se entendió, pero el mismo hecho de que no fue así indica que el tema de UX es completamente desconocido en las empresas. Vale la pena hacer una breve presentación al cliente al comienzo de la etapa de diseño con una discusión sobre cómo trabajamos, qué presentaremos y en qué medida necesitamos información del cliente. Y, por supuesto, por qué le vale la pena.

9. Trabajar con desarrolladores

A menudo, los desarrolladores tienen muy buenos aportes cuando se trata de soluciones y hacen preguntas muy técnicas y lógicas, lo que muchas veces me dio un buen tema para pensar en una solución. Sin embargo, a veces proponen soluciones que son más simples para ellos y no necesariamente buenas desde el punto de vista del usuario, por lo que aquí es necesario equilibrar adecuadamente qué vale la pena posiblemente proponer cambiar y dónde vale la pena detenerlos y explicar las decisiones tomadas.

10. API, JSON, LDAP, orquestadores y otras palabras extrañas

Estos son conceptos clave para el desarrollo de aplicaciones que, como UX, debes conocer porque los desarrolladores y toda la comunidad de TI los utilizan. Conózcalos y podrá hablar mejor con los ingenieros. No sabe — pregunte, preferiblemente al principio, aunque para mí, la comprensión de estos conceptos llegó solo después de revisar la documentación de implementación que estaban creando los desarrolladores — los diagramas de comunicación interna de la aplicación permitieron entender mucho cuando se trata de su marcha.

11. Trabajar en sprints, proyecto diario, planificación de sprints y retro(spec)

Son reuniones valiosas que dan control total sobre lo que está pasando en el proyecto. Los Project Managers son importantes aquí, interviniendo cuando es necesario (por ejemplo, cuando el cliente intenta cambiar los arreglos), así como los Scrum Masters si estamos trabajando ágilmente (casi todos los proyectos).

Como puede ver, estas fueron muchas cosas que aprendí cuando me uní a TI. Espero que los encuentre interesantes y tal vez esta lista sea útil para aquellos que están considerando su carrera en UX/UI o incluso para las personas que trabajan en esta industria.