Muy a menudo en una empresa, el diseño depende totalmente del diseñador. Incluso puede cambiarlo de repente por completo, a pesar de los gritos de protesta de los "frentes" y "mobilshchiki". Tenemos una opinión diferente: la cosmovisión interna del diseñador o la visión del desarrollador no deberían afectar en gran medida el producto. El diseño del producto es la parte visible del negocio con el que interactúa el cliente. El diseñador no puede presentar su "Lista de deseos" por sí mismo, debe centrarse en las necesidades de los clientes. Los buenos productos se desarrollan orgánicamente, con la vista puesta en el cliente. Esto se aplica tanto a la saturación funcional como al diseño.
Un diseñador no debe ser portador de requisitos para una aplicación; una empresa debe dictar lo que será. No importa quién trabaje en el diseño de ePayments, tanto el sitio como la aplicación serán hermosos y convenientes, y el estilo no cambiará drásticamente en 180 °. Este principio funciona en beneficio de los desarrolladores frontend y móviles.
Hoy, yo, el diseñador del proyecto Timur, les contaré cómo rediseñamos la aplicación móvil y cómo apareció nuestro sistema de diseño.
Como empezó todo
Cuando llegué al proyecto por primera vez, la aplicación se veía así:
Y antes de eso era generalmente así:
Lo que no me convenía:
1. La aplicación no se ajustó. Inicialmente, teníamos 2 monedas (EUR y USD) y 2 tarjetas (para las mismas monedas). Estaban rígidamente interconectados tanto visual como lógicamente. La sección del dólar es una tarjeta de dólar, etc. Luego se agregó RUB y todo el diseño comenzó a "desaparecer". Para agregar nuevos elementos tenía que usar muletas. EPayments tiene planes para expandir la lista de monedas y necesitábamos descubrir cómo agregarlas sin problemas para el cliente. El comportamiento en todas las pantallas debe ser predecible. Si en una pantalla la lista de monedas se procesó mediante un patrón de comportamiento específico, en la otra pantalla se debe repetir el patrón de trabajar con monedas.
2. Diseño anticuado. La aplicación se veía muy "basura" y dura, quería más aire y menos elementos innecesarios. ¿Por qué necesitamos gradientes y "belleza" si después de 5 minutos los ojos comienzan a cansarse en la aplicación?
3. La diferencia en el diseño. Para iOS y Android, había 2 aplicaciones fundamentalmente diferentes. Si una persona cambia de un sistema operativo a otro, pierde toda la experiencia acumulada del usuario. El propietario de Samsung no pudo decirle al propietario del iPhone cómo realizar la operación.
4. Flujo de trabajo no óptimo. Cuando tuvimos una nueva forma de transferir fondos de la billetera, esta tarea llegó al analista que hizo el mocap. Luego vino a mí y dibujó una pantalla para traducir. Luego, el desarrollador móvil lo convirtió todo en código y lo introdujo en la aplicación. Este es un proceso poco saludable, del cual fue posible arrojar el 80% de los costos laborales. Puede ahorrar mucho tiempo aquí simplemente eliminando al diseñador de la línea de montaje. Si hay elementos de interfaz listos para usar, puede ensamblar ventanas de traducción a partir de ellos.
Diseñando un futuro más brillante
Y así empecé a trabajar. En primer lugar, quería hacer una aplicación fácil de usar. Los servicios financieros generalmente no deberían ocupar a un cliente por mucho tiempo. En él, debe navegar rápidamente, elegir una operación, llevarla a cabo y continuar con su negocio.
Otra constante importante es la amabilidad del desarrollador. Si tenemos un nuevo chip, moneda o servicio, los frentes y los movilizadores no deberían sufrir y agitar todos los estilos. Simplemente agregan una nueva característica que se ve clara y esperada.
Estaba buscando la analogía más simple y me di cuenta de que necesitábamos un constructor de ventanas. Tenemos un conjunto de controles (atrás, adelante, selección de cuenta, introducción de detalles) y reglas para trabajar con ellos (colores, sangrías, tamaños de elementos). En el diseñador, los analistas y los trabajadores móviles pueden hacer nuevas tarjetas de servicio y ventanas modales por sí mismos sin venir a "inclinarse".
Era importante tener en cuenta que el producto se está desarrollando en amplitud. Hoy tenemos 3 monedas, en un año puede haber 33. Hoy damos 15 formas de transferir dinero, mañana serán 115. En la aplicación pueden aparecer entidades completamente nuevas: tarjetas virtuales, compra de acciones u otros servicios.
Descarta los grilletes de limitaciones
Problema : el proyecto tiene un número creciente de elementos: monedas, métodos de transferencia, etc. Muchos elementos están dispuestos horizontalmente, cuanto más haya, más inconveniente será usarlo.
Solución : prevea la expansión por adelantado, elija el posicionamiento conveniente de los elementos.
El principal problema de la versión anterior es el escalado. Entonces, tenemos una pantalla condicional con una resolución de 480 * 720 px. Y horizontalmente hay 3 pestañas con métodos de transferencia de dinero. Bueno, mañana serán 15. ¿Quién en su sano juicio desplazará 15 pestañas a la derecha? ¿O necesita hacerlos de tamaño micro para que pueda ingresar solo con su dedo meñique?
En ePayments, el cliente tiene una billetera con varias secciones de divisas. El elemento más escalable de la interfaz de usuario móvil es la lista. Se puede voltear casi infinitamente hacia abajo con un movimiento completamente familiar. Incluso si de repente hay demasiados elementos, siempre puede ajustar el filtro o buscar.
El límite de conveniencia es de alrededor de 10 monedas o métodos de transferencia. Cuando haya más de ellos, conectaremos el segundo mecanismo, que ahora está en desarrollo: las secciones seleccionadas. El cliente mismo elige qué secciones de moneda son más importantes para él y las marca con un asterisco. O construye su tablero en el constructor, al igual que la pantalla de inicio en Jira.
Además, tenía una "hamburguesa" a la izquierda y una barra de toque en la parte inferior. Las operaciones más importantes las colocamos en el panel inferior. En primer lugar, nos fijamos en el saldo de secciones y tarjetas. Luego puede ir a la recepción o transferencia, ver el historial de transacciones o cambiar la moneda. Todas las cosas menos importantes que puse en la "hamburguesa". Ahora yace, por ejemplo, un programa de afiliados al que se accede con menos frecuencia.
De acuerdo, el problema está resuelto, pase al siguiente.
Mantenemos las diferencias en el pasado.
Problema : las aplicaciones de iOS y Android no son iguales. Su diseño está desactualizado, la interfaz tiene muchos elementos adicionales. Es difícil para el cliente concentrarse, se cansa rápidamente.
Solución : haga las aplicaciones de acuerdo con las pautas, pero con un diseño unificado. Limpiar de gradientes, trabajar en usabilidad.
Como dije, las versiones para Android e iOS eran aplicaciones fundamentalmente diferentes. No hay nada bueno ni para el cliente ni para nosotros. Además, los desarrolladores tuvieron problemas para implementar nuevas funciones y pruebas. Por lo tanto, decidimos llevar todo a una forma.
No puedes hacer aplicaciones idénticas. Google tiene diseño de materiales, Apple tiene interfaces humanas. Pero los elementos básicos los hacemos similares. La cuadrícula, la mayoría de los controles y la disposición de los bloques se volvieron iguales. Los controles responsables de la estructura básica se adaptan a las guías del sistema operativo. La solución más fácil es portar completamente la aplicación. Pero esto es más bien una señal de pereza e ignorancia de los guías. Y las guías están escritas por personas que son muchas veces más inteligentes que nosotros, vale la pena escucharlas.
El primero actualizamos la aplicación en Android. Era más barato en los "puntos de la historia", la mayoría de nuestros clientes usan este sistema operativo. Además, en algún momento tuvimos un desequilibrio en el equipo de desarrollo móvil: había más personas en el equipo de desarrollo de Android y pudimos asignar algunas de ellas para el rediseño. Esta versión se ha adelantado y la versión para iOS ahora se está poniendo al día gradualmente.
Se basa en guías de diseño de materiales y gracias a esto tenemos una aplicación en la que una persona con Xiaomi condicional está familiarizada con todo. Rápidamente aprende cómo enviarle el dinero ganado a una tarjeta bancaria.
Cuando lanzamos el rediseño, comenzamos a recopilar reacciones y críticas constructivas. Primero, hubo una pequeña corriente de negatividad de aquellos a quienes no les gusta el rediseño como fenómeno. Esto es normal y no debe temer. Cada servicio se enfrenta a esto. Luego, todo se calma y puede recopilar información útil.
Al principio, la calificación bajó un poco, luego volvió a 4.6. Hicimos algunos comentarios críticos y las críticas se volvieron buenas y amables nuevamente. A partir de este momento, podría asumir la aplicación para iOS.
Ahora las aplicaciones son bastante similares. Algunas cosas se hacen deliberadamente, no de acuerdo con las pautas, pero la métrica principal es la reacción del cliente. Todo parecía conveniente para los usuarios: la evaluación no cambió, se nos agradeció el rediseño en las revisiones.
El hecho de que las aplicaciones se volvieran similares se reflejó en el desarrollo. Ahora son más fáciles de probar, los casos en Testrail son los mismos. Toda la documentación del caso está duplicada, naturalmente, según enmendada. Por ejemplo, cuando estamos preparando una función en una aplicación de iOS, ya tiene JSON de Android y los desarrolladores no tienen que responder a las solicitudes.
Damos las riendas del gobierno
Problema : el proceso de desarrollo no está optimizado. Cada nueva tarjeta de traducción se dibuja y desarrolla desde cero.
Solución : cree un conjunto de elementos y reglas listos para usar, convirtiendo el proceso en un "diseñador".
La idea del diseñador apareció junto con el rediseño de la aplicación, pero la implementamos un poco más tarde. Como dije, la aplicación no debería depender de mí. Si presentamos una nueva característica, la tarea va del analista a los desarrolladores móviles. Ensamblan una ventana desde los controles terminados, verifican sus estilos, márgenes y todo lo demás, y listo, la ventana está lista. Puedo hacer un ícono, pero mi participación directa debería terminar allí.
Primero, dibujé cada pantalla individualmente. Luego agrupó elementos repetitivos: listas, controles, botones, ilustraciones, pantallas de confirmación, etc. Cuando la aplicación estaba lista, tenía una interfaz de usuario de componentes completa.
Mira los elementos, todos tienen algo similar:
• rumbo
• "volver"
• droplist
• línea para ingresar detalles
• "siguiente"
Hacemos estos elementos de antemano. Además, preparamos guías para colores, sangrías y fuentes. En la salida, obtenemos un constructor en el que el desarrollador convierte el dibujo en la pintura condicional del analista en una ventana de traducción terminada.
Naturalmente, los trabajadores móviles tuvieron que trabajar para convertir un montón de pantallas en un sistema de componentes ordenado. Pero les sucedió después: ya no era necesario ir a Zeplin para el diseño de la pantalla, inventarla y almacenarla en el futuro. Hay componentes, hay una hoja de estilo estricta.
Para resumir
Me gusta lo que hicimos La aplicación se ha vuelto más hermosa, fue apreciada por los clientes. Se ha vuelto más fácil para los frentes y movilizadores trabajar.
Todavía no estamos utilizando plenamente las métricas que muestran cómo ha cambiado el comportamiento del usuario. Así que ahora solo podemos juzgar por las calificaciones y comentarios de los clientes. La calificación se mantuvo igual: 4.6 en Google Play, 4.8 en la AppStore. La mayoría de las críticas negativas se relacionan con el proceso de verificación, les parece a los clientes mucho tiempo. Y en lo positivo, a menudo se elogia la aplicación.
Otra métrica, solo interna: rara vez abro un archivo de boceto con un proyecto móvil. Los desarrolladores están agregando nuevas formas de depositar y retirar sin mí. Esto significa que la interfaz de usuario del componente funciona y pude hacer que el diseño sea sistémico, sin la dictadura del diseñador.
Ahora planeamos llevar el producto a un solo vistazo en diferentes plataformas, incluida la versión de escritorio. Además, planeamos "traspalar" toda la estructura de escenarios de las características en las aplicaciones móviles para que el cliente pase aún menos tiempo en las operaciones. Bueno, al mismo tiempo, abandonaremos la hamburguesa a la izquierda: este es un patrón obsoleto, hay opciones más convenientes.
¿Buscando trabajo?
Estamos buscando empleados para trabajar en una oficina en San Petersburgo. Si estás interesado en fintech, te estamos esperando. A continuación encontrará vacantes y enlaces a las páginas correspondientes de hh.ru.