🚖 👌🏻 🍱 Diseño de producto sin diseñador 🥑 👨🏾‍✈️ 😄

He trabajado en KORUS Consulting CIS durante 3 años, y durante este tiempo participé en el diseño de diecinueve servicios B2B. El diseño de interacción generalmente se asocia con Axure, InVision, Moqups, Framer, (inserte su opción favorita), pero mis herramientas son HTML, SCSS y AngularJs. Le diré cómo la práctica habitual de guardar plantillas HTML ha crecido en los almanaques de diseños completos, y cómo un grupo de máquinas tipográficas dirigidas por un director de arte diseñó la interacción con las interfaces de todos los productos KORUS Consulting CIS durante seis años.

¿Y por qué funcionó?

En "Un hospital psiquiátrico en manos de pacientes" en el capítulo "De dónde vienen los diseñadores de interacción", Alan Cooper escribe que las habilidades necesarias son fáciles de encontrar en cualquier participante en el desarrollo. El diseño puede ser realizado por un gerente de proyecto, analista, escritor técnico, comercializador, desarrollador. Es bueno cuando esta función es asumida por un especialista separado, preferiblemente un diseñador. CORO le dio este papel a los codificadores. Pero no de una vez.

Photoshop rechazado

Hasta 2019, no había diseñadores en KORUS. Y hasta 2011, no había nadie para escuchar sobre algo como la experiencia del usuario. Como desarrollador de software que se respeta a sí mismo, la compañía buscó llevar rápidamente el producto al mercado, y los analistas y desarrolladores fueron responsables de la apariencia y el comportamiento de la interfaz. En su mayoría desarrolladores.

Por lo tanto, cuando en 2011 un codificador con las habilidades de un diseñador apareció en la empresa, antes del desarrollo solo se le permitió en las etapas finales.

Un nuevo especialista en lectura (inusual) para KORUS encontró un esquema de desarrollo típico, donde se le permitía mover píxeles y pintar, cuando las características principales ya estaban implementadas. Suena como diseño después del desarrollo. Y esto se describe con gran detalle en el Hospital Psiquiátrico, Sr. Cooper. KORUS podría considerarse un héroe de libro de texto de sus historias.

Photoshop u otro editor gráfico entró en este proceso de desarrollo con dificultad. Desde el principio, confiamos más en el diseño porque es más fácil de editar, especialmente en condiciones de requisitos en constante cambio. Y puedes darle el diseño al desarrollador. Diseñar, componer e inspirar belleza al mismo tiempo es mucho más eficiente. Con este enfoque, dibujar en cualquier editor es un enlace intermedio innecesario, y seguramente muchos habrían estado de acuerdo con eso en 2011.

El rechazo de las herramientas de diseño ayudó a establecer una nueva pista sobre el esquema bien establecido y comenzar un largo camino hacia el diseño correcto de las interfaces. Cuando el tiempo de desarrollo es limitado, el diseño de PSD se convierte en una recomendación, el diseño se parece más a un conjunto de reglas, es más difícil dar la vuelta y olvidarse del caso invisible. O considérelo, basado en sus propias ideas sobre conveniencia.

El diseño también le permite guardar componentes individuales para no perder tiempo la próxima vez, y la primera página HTML con dichos componentes se muestra a continuación:

Se convirtió en el primer bloque para el repositorio del futuro kit en AngularJs. Al principio, se le agregaron formularios impresos y páginas individuales de nuestro servicio de gestión de documentos electrónicos (en adelante, el Correo).

Cuando el repositorio creció, y había muchos más diseños, se llamaba UIKIT y gatito-ninja en el logotipo:

en 2015, nuestra compañía hizo todo lo posible por interactuar con Sberbank, y surgió la cuestión de volver a pintar el servicio. KORUS ha utilizado repetidamente el hecho de que ya hay logros en componentes y estilos: es suficiente cambiar los colores para que coincidan con el estilo corporativo de Beeline, Alfa Bank, etc. Gracias a esta experiencia, el Correo fue repintado en solo una hora.

E imagínense, si al principio el diseñador repinta los diseños gráficos, y luego el diseñador de diseños cambia los estilos. Dos tareas: una solución: ya el diseño en UIKIT.

¿Cómo evitar que hagan "mal"?

Sorprendentemente, durante los primeros 4 años, solo un especialista se ocupó de todas las tareas de diseño. Los desarrollos en UIKIT se guardaron, lo que supone un gran ahorro de tiempo: el diseñador logró conectarse al desarrollo lo antes posible y evitar terribles soluciones de interfaz.

La expansión de la cartera de productos condujo naturalmente a la aparición de nuevos diseñadores de diseño. Esto permitió que el ninja de la ballena asignara más recursos, y los diseños se volvieron más interactivos. No es suficiente vincular HTML con enlaces, queríamos más. Se utilizaron JQuery y AngularJs. Los prototipos vivos fueron calificados principalmente por analistas. Puede hacer clic en todos los estados, tomar capturas de pantalla y pegarlas en el TK.

"Hicimos algo similar a BEM, pero no a BEM, y así fuimos a la unificación del diseño en todos los proyectos"

Sin embargo, si todo está claro con el diseñador de diseño, ¿puede el diseñador de diseño simplemente guiarse por pautas y su propia experiencia rica en la composición tipográfica de varios diseños para diseñar algo simple? Los diseñadores de diseño pueden ensamblar la interfaz como diseñador y no esperar a que alguien le diga dónde colocar el botón. Ya han visto este botón en la barra de herramientas muchas veces. Los diseñadores llaman a esto oscuridad. Y KORUS necesitaba casos de vida comprensibles, lo que se llama "diseño natural". Y si recuerdas que los productos de un ecosistema generalmente son similares entre sí, y la unicidad solo los perjudica, entonces mi respuesta es sí.

La llegada de UIKIT ha acelerado el proceso de creación de prototipos. La demostración de diseño en la que se podía hacer clic se utilizó para la preventa, la coordinación de detalles con el cliente antes del inicio del proyecto. Y, por último, los desarrolladores recibieron la información necesaria sobre el comportamiento de la interfaz, para no proponerla directamente en el proceso de codificación.

“Los frentes les facilitaron la tarea. UIKIT en parte me hizo hacerlo bien ".

Interactividad con AngularJs

Fue precisamente ese esquema de trabajo el que llegó a KORUS después de la aparición de UIKIT: surgió la necesidad, se formalizó en los requisitos técnicos, los diseñadores de diseño lo incorporaron inmediatamente en un prototipo web.
Quedaba por obtener un marco de las profundidades de Internet, volver a pintarlo bajo una etiqueta verde e implementarlo en productos para que no solo los botones y encabezados sean uniformes para todos los servicios.

Además de los controles del marco, UIKIT se repone con un conjunto de iconos, widgets, desarrollos y estilos propios.

Si hubo una tarea para un diseño de página similar a algo de nuestros servicios, tomamos la finalizada, cambiamos el contenido a los requisitos, y el contenedor y la lógica permanecieron igual. Se pueden configurar las transiciones entre páginas, se puede hacer clic en todos los botones y campos, podemos mostrar validación, ventanas modales, carga de archivos exitosa. Podemos mostrar la ruta completa del usuario de principio a fin con escenarios positivos y negativos, en la representación de todo el modelo a seguir.

Interfaces uniformes

La reutilización de partes prediseñadas de la interfaz no es nueva para 2015. Incluso hace diez años, los diseñadores de diseño en los estudios web optimizaban sus procesos para no volver a escribir el mismo elemento cada vez. No descubrimos la galaxia, pero esto fue solo el comienzo.

Está claro que cuanto más agregamos diseños a UIKIT, más cubrimos los casos existentes y podríamos aplicarlos aún más para nuevos proyectos.

¿Necesita un nuevo diseño de registro de usuario? Ya tenemos esto: lo adaptamos a las necesidades de la empresa, no dedicamos más de un par de horas y, ahora, el registro está listo para transferirlo a los desarrolladores, pero en un servicio diferente.

¿Necesita una tabla con datos de la empresa? Esta bondad en nuestros servicios a granel: CRTL + C CTRL + V.

Lo más atractivo para el equipo de diseño en esto son los estilos uniformes. Las pautas son tales que nos dictan cómo deberían ser los elementos atómicos de una interfaz. Parece razonable arreglar el estilo de estos componentes y cambiarlo solo como último recurso. No importa cuántos diseños de nuevos productos presentamos en UIKIT, los estilos en los componentes están en un solo lugar. Para las necesidades del proyecto en sí, hay un CSS de producto separado en el que puede personalizar algo.

Bajo la influencia de pautas, optimización y nuestra propia experiencia, siempre tuvimos a mano:

Entradas, botones, desplegables;
Tablas, caras, menús, barras de herramientas;
Formularios, líneas de tiempo, ventanas modales;
Todo el flujo de procesamiento de algún tipo de solicitud de préstamo o la creación de un documento de pago.

De todo esto, ya era posible ensamblar interfaces completas, y gracias a AngularJs, en los diseños, se logró la interactividad de la producción, que era muy popular entre los clientes.

En secreto, diré que realizamos una demostración para un cliente un par de veces en UIKIT, porque tuvimos un banco de pruebas justo antes de la demostración.

Circuito de trabajo

Pasó el tiempo, el inspirador ideológico y creador de UIKIT se convirtió en director de arte, había cada vez más proyectos. ¿Quién continuará con este gran trabajo: diseñar interfaces en HTML utilizando la funcionalidad ya desarrollada? Diseñadores de diseño, por supuesto.

Decir que los diseñadores de diseño estaban muy contentos con la posibilidad de trabajar en estrecha colaboración con los analistas y pensar de forma independiente a través de la usabilidad es un pequeño truco. Aún así, todos (¿yo?) Me acostumbré al hecho de que el diseñador de diseño es un especialista que recibe un diseño de un diseñador, lo corta y lo convierte en una página web. El diseño de interacción agrega en algunos lugares un trabajo mecánico una responsabilidad inusual, aún no estudiada. Pero nos ayudó la presencia de una persona que constantemente revisaba nuestro trabajo, sugirió cómo hacerlo bien. Y no solo pronunció, sino que se refirió a fuentes autorizadas, para que también los leamos y cometamos menos errores. El director de arte constantemente señaló algunas leyes de Fitts, luego las reglas de la escritura comercial o el formato del texto, enfatizando los elementos ... Nos resistimos, pero absorbimos la información.

Hoy podríamos poner dos botones verdes uno al lado del otro; mañana no lo hicimos porque lo sabíamos: el botón con la acción de destino debería ser uno por página.

Hoy, todas las entradas estaban atascadas en el mismo ancho, mañana haremos el campo para el TIN exactamente para el contenido. Entonces, el usuario lee mejor cuánto tiempo se esperan los datos de él.

El proceso se puso en marcha. Los diseñadores de diseño recopilan interfaces, basándose en los requisitos comerciales de los analistas, coordinan sus decisiones con el director de arte y las entregan al desarrollo.

Crecimos como diseñadores, aprendimos a tomar decisiones, fomentamos nuestra independencia para ampliar la gama de tareas en las que no se requiere una inmersión profunda del director de arte.

En algún lugar de esa tubería apareció GitLab, una revisión del diseño, mejorando la visualización usando js.

Si el diseñador de diseño se enfrentaba a una tarea difícil y no estándar, el director de arte se conectaba y ayudaba a encontrar una solución. En ese momento él mismo diseñó el concepto de nuevos productos.
Proporcionamos 2-3 opciones para nuestra comprensión del problema, y él eligió una y dijo cómo podría mejorarse. De vez en cuando, simplemente dijo "ok", y nos alegramos de entender que habíamos acertado. Sin embargo, a veces no recibimos suficientes comentarios para comprender cómo nuestra solución es conveniente y comprensible para los usuarios, e incluso si el director de arte lo tiene claro. La duda nos hizo intentar una y otra vez interpretar los requisitos de varias maneras.

Nuestro líder tenía su propia opinión sobre esto. Dijo que de esta manera nos hizo pensar. Cada uno a su manera evaluó el proceso. Pensé que me estaba ahorrando a mí y a él tiempo. Como, déjame mostrarte tres opciones a la vez para no caminar tres veces. Una especie de prueba A / B / C en la artillería para mí.

Aunque, por supuesto, hemos aprendido mucho (solo mira cómo este diseñador de diseño cita libros de diseño).

Como comprenderá, en este proceso no hay lugar para una reflexión detallada sobre los análisis UX y UX. Aunque con una herramienta así probaría y probaría. Se utilizó lo que el director de arte originalmente puso en el diseño en la etapa de creación de prototipos. Todas las nuevas características ya han sido inventadas y descritas por partes interesadas, gerentes y analistas. No codificadores. Esto fue un inconveniente, porque no siempre pudimos explicar de manera concluyente por qué la solución ya inventada por el negocio no es adecuada.

En la salida, el tipografista recibió alguna descripción en Confluence del analista, como esta:

:
:
: « »
« » checkbox .
tooltip .

Incluso se aplicó un mocap impersonal en los cuadrados de la Basílica a la tarea para mostrar la posición y el propósito de los elementos en la página.

A veces recibimos tareas de analistas con la siguiente redacción:

aunque UIKIT ingresó a la pila de herramientas de la compañía, sin análisis de UX no hubo argumentos de peso contra la toma de decisiones de interfaz, excepto por la última palabra del director de arte. Pero nuestro camino hacia la interacción perfecta continuó.

Con el tiempo, pudimos encontrar un lenguaje común y dividir las áreas de responsabilidad por la calidad y usabilidad de la interfaz.

En total, todo el proceso de creación de un diseño de producto se veía así:

- , UIKIT. , , , ;
, . , -, , . ;
El diseñador de diseño tomó el borde del nuevo proyecto y lo completó, lo puso bajo una tarea técnica más detallada. Si al principio el cliente quería completar la solicitud en un paso, y luego en dos, el diseñador de diseño lo implementó fácilmente. En el futuro, el diseño podría cambiar más allá del reconocimiento, y desde la versión original solo había estilos que, en principio, no cambiaron. Todo esto se discute gradualmente, paso a paso, con el director de arte. En la primera etapa, el prototipo se asignó de dos días a un par de semanas, luego el desarrollo podría continuar durante años. En tales proyectos, nuestro gerente ocasionalmente "incursionó" con un rediseño para compensar el aumento de la masa crítica de características y repensar la interfaz de una manera nueva.

Al equipo de UIKIT le llevó 2 años llegar a este proceso.

Demostración visual

En todas las etapas, el diseño está disponible para la demostración al cliente y al equipo. Esta es una de las ventajas más fuertes de UIKIT.

¿Qué podría ser más conveniente y comprensible para el cliente que seguir el enlace y hacer clic en el diseño usted mismo, observar el comportamiento de la interfaz? Puede evaluar y corregir los textos, que luego pasan a producción. A veces, el diseño realizado por el cliente cambió la idea de la tarea, podía entender que su idea no era viable y aceptar los cambios. Si en palabras estaba seguro de que su cuestionario con 150 campos encajaría fácilmente en la interfaz, entonces en el diseño vio claramente que requería mejoras. Lo más importante, lanzar este perfil en UIKIT es barato.

Un pequeño ejemplo:

primer requisito indiscutible y final:

compromiso visto en el proceso:

Alguien puede notar que Axure, Figma, Marvel tienen todas las ventajas de UIKIT descritas por mí ... Pero algunas de ellas no existían en la etapa de selección de tecnología, otras fueron rechazadas como un vínculo adicional entre el diseño y el diseño.
UIKIT es una oportunidad para ensamblar ni siquiera un prototipo, sino una interfaz de producto lista para usar, que luego el front-end entrará en funcionamiento.

Reconocimiento de la empresa

Para 2020, UIKIT tiene 38 maquetas de proyectos existentes, de los cuales 13 están en desarrollo. Esta es una vasta experiencia de cuatro años, en la que puede encontrar miles de soluciones de diferentes especialistas, desde el director de arte hasta el probador. Todos ellos obedecen las reglas generales de css y construcción de páginas.

Con el tiempo, necesitábamos conectar nuevos complementos, organizar varios soportes para UIKIT (nuestro interno para el desarrollo actual y externo para la versión fija, que entrará en desarrollo), agregar versiones de estilos, comenzar a importar el paquete de estilos en artifactory y nexus, y luego facilitar el paquete npm Transferencia de archivos multimedia a CDN. Luego cambiamos a SASS. Una colección de diseños de sitios aparentemente ordinarios se convirtió en un proyecto completo con sus implementaciones, actualizaciones del equipo y una discusión activa de mejoras futuras. Es decir, nuestro proyecto, que al principio solo era una ayuda para la creación rápida de prototipos, se convirtió en un producto completo con sus procesos inherentes.

UIKIT fue del agrado de clientes, analistas, desarrolladores, y luego los evaluadores también lo apreciaron.

Un buen día, recibí solo una pregunta histórica del equipo de desarrollo de nuestro cliente:

“¿Cuándo son los diseños en la ballena? Son mucho más convenientes que los requisitos ".

Para mí, como diseñador de diseño, esta frase halagada. Pero mejor no lo hagas, lee los requisitos.

Hasta este momento trascendental, el equipo de UIKIT obstinadamente acudió al reconocimiento del instrumento incluso entre colegas. El valor comercial del proyecto era cero, lo que significa que su desarrollo recaía completamente en las máquinas de escribir. Además de las tareas actuales, continuaron optimizando su trabajo. Me gusta ver cuánto ha crecido nuestro kit ninja a lo largo de los años, no inferior en poder a la Figura moderna, sino gracias al diseño terminado y a superarlo.

Mi próxima historia será sobre los detalles técnicos del diseño usando UIKIT, sobre cómo una vez que nuestro circuito ha sobrevivido y qué pasos tomamos para desarrollar.

Diseño de producto sin diseñador