9. abril 2018

Entrevista con Avi Aznar, Diseñadora de Navilo: “Ofrecemos al cliente un know how de cosas que tal vez él desconoce que pueden hacerse o que pueden hacerse de esa manera”

 

Mucha gente puede tener una idea de lo que es el diseño, pero lo asocia a su vertiente  gráfica. ¿Puedes contarnos cuál es la especificidad del diseño de aplicaciones y webs?
Cada vez se impone más la necesidad de que los usuarios no solo vean las cosas bonitas, sino que, para que el mensaje llegue correctamente y para que la función de una app se cumpla de forma óptima, el usuario pueda alcanzar su objetivo de la forma más rápida y más intuitiva posible. No entra en juego solo una cuestión estética, sino que también hay que ver, a nivel estructural, cuál es el flujo de esa aplicación, qué podemos hacer en cada pantalla, a dónde vamos al hacer clic, si podemos retornar en todo momento, que estemos correctamente ubicados, que cuando busquemos una información sepamos dónde podemos encontrarla, etcétera. En definitiva, todo lo que tiene que ver con la llamada UX,  User Experience, y la UI, User Interface.
La función principal de un diseñador de apps es esta. Si la finalidad de mi app es, por ejemplo, “conocer gente”, como puede ser el caso de Tinder, ha de preguntarse ¿qué necesito?  Pues necesito registrarme, poder logarme, tener acceso desde una pantalla principal a una serie de botones, de perfiles, de chats y lo que sea y ubicar esas llamadas allí donde el usuario espere encontrarlas. Además, tenemos que asumir un idioma.  Hay cosas que ya son convenciones y que afectan al diseño, como puede ser una iconografía determinada. Todos sabemos que tres líneas, una debajo de otra, abren un menú, que un muñeco significa un usuario que puede ser un login o un registro, hay ciertos códigos de color –el rojo es siempre una alerta o el verde es que algo ha sucedido y está todo bien- y es importante que el diseñador conozca estos pormenores para no llevar al usuario por caminos erróneos.

¿Os resulta difícil comunicar a los clientes que, sin  descuidar el impacto estético, la UX tiene un relieve fundamental y debe ser prioritaria en todo proyecto?
Obviamente, el cliente siempre quiere una aplicación bonita, lo que no significa que la que tiene en mente lo sea. El gusto de los clientes también es cuestionable y es parte de nuestro trabajo señalarlo.
Dicho esto, muchas veces lo que ocurre es que el cliente, cuando pide una cosa tan sencilla como “crear un login” o una “push notification”, no sabe qué hay detrás de eso. No solo se esconde un cuadrito de texto en el que pones un correo electrónico y una contraseña,  sino que hay una lógica detrás: hay bases de datos, hay llamadas de código, toda una estructura que hace que funcione. Entonces, cuando alguien te dice “ponme un formulario aquí” no sabe el impacto que tienen esas “pequeñas cosas” que él cree tan sencillas. Por eso, para evitar ese problema, nuestro trabajo como diseñadores es también hacer ver al cliente esto de una forma que al principio puede parecer farragosa, pero que acaba por serle muy útil. Y es que al empezar cada proyecto, además del concepto general, hacemos una lista de casos de usos: qué se puede hacer en cada pantalla. Si cogemos el ejemplo de una pantalla de log in, “¿qué puede hacer el usuario cuando entra ahí?” Pues puede 1.introducir un correo electrónico.  2. Introducir una contraseña. 3. Dar al botón de enviar. 4. Recuperar password en caso de que se haya olvidado.
Pero ¿qué pasa si introduzco un correo electrónico que no existe? Pues debería salir un aviso que diga tal cosa. Y como decíamos en nuestro último artículo, todas estas cosas se han de  describir de forma pormenorizada. Así un cliente sabe cuándo una tarea que parece fácil no lo es tanto y, además, nosotros podemos estimar de forma correcta qué tiempo nos va a llevar y qué necesidades tiene de verdad el cliente. Y, claro, que en principio lo que se salga de esos casos de uso no está contemplado.

En el mundo del diseño tradicional siempre ha sido un inconveniente esa incomprensión de todo lo que supone un cambio y del trabajo que hay detrás. Pese a ser tan metódicos y didácticos, ¿os ocurre a vosotros?
Pues aun así, eso está a la orden del día. El otro día hicimos un workshop en la empresa y esos problemas salen. Pero, sobre todo, lo que cuesta de verdad es diferenciar entre un bug, un error que surge, y un change request, es decir, que primero me pides algo de un modo y luego me lo pides de una forma distinta. Una cosa es que algo no esté correctamente realizado y haya que corregirlo y otra que me pidas una funcionalidad diferente. Ya no entro en la dificultad y tiempo que supone un cambio, que es lo que ocurre en el diseño tradicional del que yo provengo, sino distinguir qué es un cambio y qué es un fallo.

Otro de vuestros trabajos es también documentar de forma exhaustiva los proyectos antes de empezar: ver lo que se cuece en este campo, buscar otras aplicaciones parecidas, estar pendientes del mercado…
Obviamente, cada aplicación y cada cliente es un mundo, pero hay cosas que obedecen a tendencias y hay que estar actualizado. Lo que intentamos es estar a la última. Navilo quiere diferenciarse precisamente en eso: queremos romper, queremos innovar y es fundamental que sepamos en qué mundo vivimos. Por eso, cuando hacemos un análisis de las aplicaciones que son competencia, prestamos mucha atención no solo a lo que hay, sino a lo que no hay. Es decir, ofrecemos al cliente un know how de cosas que tal vez él desconoce que pueden hacerse o que pueden hacerse de esa manera. Porque hay aplicaciones que, tras un tiempo en el mercado, a nivel funcional, están un poco obsoletas. Y eso también hay que saber verlo. Los procesos de análisis implican conocimiento de lo que hay y de lo que se espera que haya y de hacia dónde queremos ir.

¿Y os corresponde evaluar si las expectativas del cliente son ajustadas y realistas, más en un mercado tan competitivo y, en algunos ámbitos, sobrepoblado como el de las aplicaciones?
Aunque eso es más tarea del cliente, y no es exactamente mi ámbito, sí que a veces un cliente te viene con algo que puede ser enorme, que a lo mejor supone una inversión previa espectacular de tiempo, de esfuerzo, de análisis y una de nuestras funciones como consultoría es reorientarlo para que, a lo mejor, enfoque el proyecto hacia algo más pequeño, con funciones más básicas para  luego ir validando, viendo qué funciona, qué es necesario desarrollar e ir configurando un producto más sólido, de una forma más tranquila y desahogada.

A modo de despedida, ¿me puedes anticipar algo sobre las  tendencias que vienen en el sector de las aplicaciones móviles?
Esta pregunta es un poco peligrosa porque las modas van y vienen. Pero bueno, hoy se tienden a simplificar cada vez más los flujos y los procesos y muchas apps se han convertido en mero front-end. No son tanto herramientas en sí como herramientas que se dedican a mostrar cosas que están en otro sitio. Se tiende más a almacenar cosas en la nube y a otro tipo de filosofía que hace algún tiempo. Y, por encima de todo, se busca que el usuario consiga su objetivo en el mínimo tiempo posible, de la forma más fácil posible. Que sepa qué puede y no puede hacer. Vamos, se hace mucho hincapié en la UX. Lo demás es más subjetivo y cuestión de gustos: ahora se lleva mucho el flat design, pero están volviendo otra vez los degradados, los volúmenes, las cosas que se mueven y elementos tan visuales como las animaciones dentro de las aplicaciones, aunque sea en pequeñas cosas.

avi aznar diseñadora de navilo
Navilo