La historia de un rediseño que cambió el enfoque de desarrollo en ISPsystem.
Me uní a ISPsystem en abril de 2016. En ese momento, la situación con el diseño del producto era la siguiente: las decisiones sobre los productos fueron tomadas por la gerencia y los programadores, no había diseñadores ni diseñadores. La situación del mercado requería productos con "otras interfaces", por lo que la gerencia decidió rediseñar la parte del cliente
BILLmanager . Se suponía que era un globo de prueba, el primer intento de hacer algo con un nuevo diseño.
Fui el único diseñador de UX en la empresa: estudié un producto existente, participé en la investigación de usuarios, me familiaricé con los comentarios de los socios y sus especialistas en marketing. Estas son las prácticas habituales de diseño de productos, teniendo en cuenta los detalles de un producto complejo. El gerente de producto me brindó una gran ayuda, ya que él conocía mejor el producto.
Cada semana mostraba el resultado en forma de prototipos, circuitos, etc. a la dirección de la empresa. Esto es similar a cómo los diseñadores de clientes trabajan con los clientes, con todas las ventajas y desventajas: puede liberarse de la responsabilidad de las decisiones, lo principal es "venderlas" a la gerencia. Pero como ya tenía experiencia en una empresa de productos y la gerencia confiaba en mí en estos asuntos, rápidamente trabajamos juntos en soluciones que desarrollé y convertí en un prototipo.
Los desarrolladores se encuentran con el prototipo
Para agosto de 2016, los prototipos del cliente BILLmanager estaban listos en su forma conceptual. La funcionalidad de la versión anterior del producto se ha transferido completamente a la nueva interfaz, con algunas mejoras. Los prototipos estaban bien desarrollados desde un punto de vista visual, pero quería más, así que pedí un diseño visual a una empresa externa. Sin embargo, nos dimos cuenta rápidamente de que este intento no tuvo éxito, se requirió un trabajo iterativo constante en el componente visual y que necesitábamos un diseñador visual en el personal. En un par de meses, desarrollamos nuestro propio lenguaje visual. De hecho, en ese momento teníamos varias partes del futuro sistema de diseño: un lenguaje visual, elementos y plantillas.
Paralelamente, desde aproximadamente agosto de 2016, los desarrolladores comenzaron a implementar una nueva interfaz. Los chicos consideraron el prototipo como una alternativa a la tarea técnica. Como sucede en esos momentos, las preguntas comenzaron a aparecer en una escala masiva, que se reduce a una sola cosa: ¿hacemos lo que los programadores implementan rápida y simplemente o lo que inventó y diseñó un diseñador? Para resolver rápidamente estos problemas y simplificar la comunicación, hemos creado un equipo de diseñadores y front-end.
Departamento de UX como equipo de diseñadores y front-renders
A mediados del otoño de 2016, se formó un departamento de UX en la compañía bajo mi liderazgo, que consistía en diseñadores de UX, un diseñador visual, licitadores y probadores. Nuestra tarea inmediata era lanzar la cuenta personal del sistema ISP con una nueva interfaz (usamos BILLmanager en casa) para fines de marzo de 2017 y tuvimos dos grupos de problemas. Los desarrolladores predijeron mal el momento de su trabajo, y no entendimos bien cómo construir la interacción entre desarrolladores y diseñadores.
Lo que damos a los desarrolladores
Cuando usa Sketch y Zeplin, la interacción entre diseñadores y desarrolladores es muy simple. Pero teníamos más de 150 páginas en un prototipo interactivo, que aprendimos a usar como alternativa al TK para programadores y una especificación para probadores. No queríamos renderizar las más de 150 páginas con varios estados en Sketch y llegamos a la conclusión de que haríamos esto solo para páginas únicas. Además, todos los elementos deberían haber aparecido en Zeplin: botones, campos de formulario, etc. Después de un tiempo, aprendimos el nombre de tal enfoque: este es un
sistema de diseño basado en el diseño atómico . Todavía está en desarrollo, pero tanto los diseñadores como los desarrolladores ya lo están utilizando. El último en la compañía para el sistema de diseño es el diseñador visual.
Como resultado, suministramos a los desarrolladores dos tipos de artefactos:
- diseños de lo que alguna vez se convertirá en un sistema de diseño en Zeplin (o más bien ya en Figma),
- prototipos de productos, alternativa a TK en forma de HTML generado a partir de Axure.
Al mismo tiempo, el diseñador de UX siempre está listo para decirle a los desarrolladores y evaluadores qué y cómo debería funcionar y verse.
Scrum con diseñadores
En febrero de 2017, decidimos mejorar la precisión de los plazos de previsión e intentamos implementar Scrum. La complejidad de nuestro Scrum es que los miembros del equipo son muy diferentes en términos de competencias y cultura. Los diseñadores no son como los programadores: planificamos nuestras tareas de manera diferente, tenemos diferentes actitudes hacia lo que se considera un buen resultado.
Así es como construimos el proceso:
- los diseñadores corren hacia adelante;
- Existe una cartera de prototipos, elaborada en términos generales, en la que puede ver cómo debería ser todo el producto;
- Al momento de planificar el sprint, los diseñadores proporcionan prototipos y maquetas de la parte del producto que se planea hacer en el sprint. El diseñador de UX detalla y describe estos prototipos hasta el punto en que los desarrolladores pueden establecer y descomponer sus tareas;
- en el momento de la planificación, el diseñador de UX asesora activamente a los desarrolladores y evaluadores sobre qué y cómo debería funcionar;
- en el momento de la planificación, el gerente de producto debe decirle al diseñador de UX qué parte del producto se planea hacer en el próximo sprint para que el diseñador de UX pueda planificar su trabajo.
Los desarrolladores se dieron cuenta rápidamente del valor de un diseñador de experiencia de usuario, que puede abordarse rápidamente cuando no está claro qué y cómo debería funcionar. Los conflictos aún ocurren, pero las prácticas de Scrum, el trabajo en equipo y los objetivos comunes ayudan a superarlos.
¿Qué tiene que ver el probador con él?
El papel del probador en los procesos fue muy importante. Esta es la persona que mejor conoce la funcionalidad del producto. El probador fue la primera persona en mirar los prototipos de un diseñador de experiencia de usuario y proporcionar comentarios rápidamente en términos de cumplimiento y funcionalidad del prototipo. Los prototipos aprobados se convierten en una fuente de conocimiento para el probador sobre cómo debería funcionar el producto. Ambas partes estaban interesadas en una estrecha cooperación.
Como resultado, el equipo lanzó a tiempo la nueva interfaz de la cuenta personal del sistema ISP. Aprendimos a trabajar en Scrum, para predecir el trabajo del departamento de UX como un equipo de front-end y diseñadores. Y para el verano de 2017, enfrentaron un nuevo problema.
BILLmanager es un producto flexible. Y esto es un problema para el diseñador.
Cuando un diseñador dibuja un póster, escribe un libro o hace una portada para una revista, trabaja con información estática. Tiene texto específico, ciertas imágenes y otro contenido.
Cuando un diseñador diseña una aplicación o interfaz de sitio, la información no es estática. Hay información sobre cuáles pueden ser los datos, pero los datos en sí no lo son. Digamos que hay un blog, cada entrada de blog tiene un título, una anotación, una fecha de publicación, una imagen, etc. No hay un título específico, pero se entiende que siempre habrá un título, y la fecha siempre tendrá un formato de fecha. La tarea se ha vuelto más complicada, tenemos tipos de datos, pero no hay datos: necesitamos pensar qué contenido puede ser, qué restricciones pueden y deben imponerse. Lo más probable es que haya menos valor artístico que el póster, pero el diseñador quiere obtener un resultado que sea hermoso, conveniente y comprensible.
En el caso de BILLmanager, el administrador del proveedor de hosting puede cambiar la configuración para que, por ejemplo, para el formulario de pedido de un servidor dedicado, el conjunto de campos pueda ser diferente. En un caso, definitivamente tendremos un procesador, un disco y una memoria, y en el otro, no lo hará (o lo hará, pero, por ejemplo, será un campo), y esto no se puede predecir. En este caso, el diseñador ni siquiera tiene un conjunto de datos fijo, no solo conocemos datos específicos, no conocemos los tipos de estos datos ... y esto complica el trabajo.
Cuando comenzamos a hacer la versión en caja, los evaluadores comenzaron a verificar todas las configuraciones posibles en BILLmanager. Luego quedó claro que, por un lado, los prototipos no son lo suficientemente completos como para cubrir las posibilidades de configuraciones flexibles de BILLmanager. Por otro lado, la arquitectura del producto anterior no era lo suficientemente flexible como para implementar una gran cantidad de ideas de diseño. Desde el otoño de 2017 hasta la primavera de 2018, rediseñamos los prototipos y buscamos compromisos para resolver este problema. Y con algunas restricciones en la configuración, lanzaron una
versión en caja de la parte del cliente de BILLmanager 6 Beta en mayo de 2018.
Departamento de diseñadores de UX
Mientras el departamento de UX estaba resolviendo problemas con la flexibilidad de BILLmanager, la gerencia decidió procesar las interfaces de otros productos de la empresa e implementar Scrum y procesos de diseño en otros equipos. Comenzamos con VMmanager 6, reunimos un equipo de producto completo de participantes de diferentes competencias, autosuficientes para crear un producto: back-end, front-end, probadores, diseñador de experiencia de usuario, gerentes de producto y proyecto. Quedó claro que todos los demás productos serán desarrollados gradualmente por los mismos equipos, y comenzamos una transición gradual a una estructura matricial para gestionar el desarrollo de productos.
En este contexto, el departamento de UX debería haber dejado de ser uno de los equipos de productos. Después del lanzamiento de la parte del cliente de BILLmanager 6 Beta, la mayoría del departamento de UX se convirtió en parte del equipo de BILLmanager y ahora se dedica a resolver problemas arquitectónicos y la versión móvil de la parte del cliente. Al mismo tiempo, comenzamos a trabajar en la formación de un departamento de UX que pudiera trabajar con todos los productos simultáneamente.
Diseñador de experiencia de usuario para cada equipo de producto. Centro de competencia de diseño
ISPsystem tiene cuatro productos complejos. Nos aseguramos de que cada equipo tenga su propio diseñador UX. Esta es la persona responsable del diseño de su producto. Sus responsabilidades incluyen la preparación de prototipos para la planificación de sprint y controlar que todo lo necesario para los desarrolladores esté en la versión perfecta de píxeles. Es el conductor de la política de diseño de la empresa para su equipo. Una de sus tareas es garantizar que el resultado del desarrollo sea un producto que coincida con el diseño.
También tenemos varias personas que forman el centro de competencias de diseño de la empresa. Incluye un diseñador visual. Este centro forma la política de diseño de los productos de la compañía, trabaja en el sistema de diseño. También enseña a diseñadores de UX en equipos, resuelve los problemas de diseño más complejos, enseña a desarrolladores, gerentes de productos y proyectos cómo trabajar con diseñadores de UX e implementa procesos de diseño en equipos Scrum.