# Investigación UX/UI

En el presente documento se indicarán las recomendaciones y/o buenas prácticas con respecto a UX/UI para diferentes interfaces o módulos de sistemas web. Entre estos se encuentran los módulos de autenticación, recuperación de contraseña, mantenedores, asistentes de configuración y editores de configuración. Además de dicha investigación se realizaron diagramas de user-flow para cada uno de los módulos, dichos elementos serán incluídos en los anexos.

Cabe señalar que se entregará toda la investigación, sin embargo, al ser recomendaciones no todas se encuentran aplicadas actualmente en el sistema.

[toc]

## Autenticación

### 18 UX Design Tips for Registration and Login Forms

Referencia: https://uxplanet.org/18-ux-design-tips-for-registration-and-login-forms-f897557358ba

* **Show input field**
Si el login debe ser una tarea prioritaria en el sitio, muéstralo en una sección destacada en vez de los enlaces de login o registrarse. Cómo lo hace Facebook o Twitter (twitter ya no lo hace, pero Instagram si).



* **Email or mobile number instead of Username**
No le pidas al usuario a crear un nombre de usuario hasta que sea realmente requerido. Trata de usar correo electrónico o número celular como nombre de usuario. Los usuarios no quieren pensar en otro nombre. Es más fácil de recordar su email o número de celular que un nuevo nombre.


* **Focus on first field**
Auto enfocar el primer input del formulario. Esto ahorra el tiempo y esfuerzo del usuario para hacer click en el input. Destaca el input.


* **Keep users signed in**
Provee la opción de mantener iniciada la sesión para realizar login más fácil y rápido en sus dispositivos personales.
(solo recordar nombre de usuario, como lo hace Outlook).


* **Placeholders**
No uses placeholder como labels. Placeholders deben transmitir información de formato o descripción del input.


* **Show password to user**
Permite al usuario a ver la contraseña si lo desea. Esto ayuda al usuario a corregir la mala escritura de su contraseña. Asegúrate que por defecto la contraseña esté oculta. Provee un checkbox o toggle para ver la contraseña si el usuario lo desea.


* **Alert if Caps Lock is on**
Deja que los usuarios sepan cuando tienen activada las mayúsculas mientras escriben su contraseña.


* **Authentication for password recovery**
Los usuarios tienden a olvidar sus contraseñas. Asegúrate de proveer el enlace "¿Olvidó su contraseña?" para ayudar al usuario a recuperar su contraseña. Asegúrate que el usuario esté autenticado antes de permitirle reestablecer su contraseña. Algunos de los métodos comúnes para autenticación son, enviar correo o OTP (one time password) al correo electrónico o número de celular registrado, preguntas de recuperación y autenticación por llamada al número celular registrado.


### 16 Innovative UX Practices to Simplify Logins

Referencia: https://uxmovement.com/forms/16-innovative-ux-practices-to-simplify-logins/

* **Don’t put “Forgot Password” near the field. Place it in the login footer.**
Poder el enlace de "¿Olvidó contraseña?" a continuación del input de contraseña es como poner un extintor al lado de la puerta principal. Es importante estar seguro, pero herramientas de ayuda no deberían crear distracción y desorden. Es innecesario posicionar el enlace "¿Olvidó contraseña?" a continuación del input de contraseña cuando puedes ponerlo en el footer del login. Los usuarios lo verán cuando lo necesiten, no cuando no.


### 10 tips for great login page design

Referencia: https://www.invisionapp.com/inside-design/login-page-design/

* **Make it obvious**
No quieres que el usuario ande merodeando por el área de login. Mientras más tenga que estar buscando, más frustrado estará. Mientras más frustrado esté, menos probable que termine logueado.

Un buen ejemplo es el login de Gmail. Todo está en frente y al centro. Sabes exactamente donde necesitas loguearte y qué poner en los campos y si no tienes una cuenta gmail, te permite fácilmente crear una clickeando "Create Account".


* **KISS (Keep it simple, stupid)**
Tu página de login debiese ser simple y sencilla para tus usuarios. Por ejemplo, mira el login de instagram. Dos campos con la opción de loguearse con Facebook. Es simple, efectiva y provee una buena experiencia para sus usuarios.


* **Remember your users**
¿Hay algo más frustrante que regresar a un sitio que ya te logueaste antes para encontrarte que debes loguearte de nuevo?
Cuando tu usuario regresa a sitio, asegurate que él ya esté logueado o que ciertos campos ya estén completos para hacer un login más fácil.
Google hace un excelente trabajo en esto. Cuando sea que el usuario necesite loguearse de nuevo en YouTube, Gmail, Google Drive o cualquier otra marca de Google, la información es recordada permitiendo un proceso de login fácil.


### Otros

* **Captcha**
Al tener el usuario o contraseña incorrecto, y para evitar ataques de fuerza bruta a los X internos se obliga a introducir captcha. al usuario.


* **Correo de alerta**
Existen otros sitios que no aplican el método del captcha, pero si alguien intenta entrar a la cuenta envía una advertencia al correo electrónico registrado del usuario. Este mecanismo lo utiliza gmail o facebook.


## Recuperar contraseña

### UX Guide: Password Reset User Flow
Referencia: https://blog.prototypr.io/ux-guide-password-reset-user-flow-bfa35a16e527

* **Give detailed guidelines on creating a password**
En resumen: el formulario debe intregar de antemano una guía de las reglas que debe cumplir una constraseña de acuerdo a lo definido por el sistema.


### 15 rules of user sign-in experience

Referencia: https://uxdesign.cc/15-rules-of-user-sign-in-experience-ae9011d04ee3

* **Send a password reset link and not a system generated password**
Una contraseña generada por sistema añade un paso adicional al proceso reseteo de contraseña. El proceso de reseteo debiese ser simple:
Usuario opta por resetear su contraseña.
Usuario recibe email con un enlace para resetear su contraseña.
Usuario ingresa su contraseña y su confirmación.
Usuario inicia sesión.
Ya se ha verificado la cuenta de usuario (email). No se necesita redigir al login para ingresar sus credenciales nuevamente.

### Sign-In User Flows, Sign-Out and Password Reset: Tips, Inspiration and Examples from FreshBooks

Referencia: https://saaswebsites.com/userflow-articles/sign-in-user-flows-and-password-reset-tips-inspiration-and-examples/

* **Password Reset Form**
El formulario de reseteo de contraseña en la captura de pantalla de debajo aparece cuando el usuario cliquea el enlace "¿Olvidó su contraseña"?. El diseño de la página en sí es similar al login. En este caso, solo el campo necesario es el correo electrónico.
Nota: Aquí destaco que el formulario entrega instrucciones claras de el paso a seguir luego de ingresar el correo electrónico. Además, el formulario da la opción de redigir al login.


* **Password Reset Instructions Notification**
Una vez que el usuario ingrese su clave y presione el botón "restablecer contraseña", ellos sera redirigidos a una pagina con una notificaciones que indica que las instrucciones fueron enviadas a su correo y en caso de que no lleguen las instrucciones al correo por favor contacte soporte. La pagina al final tendrá un botón grande que sera para volver a la pagina del login.


* **New Password Page**
La pagina tendrá el mismo interfaz que el login , y es totalmente normal y un ejemplo de buena practica. Al usuario se le solicita ingresar su contraseña y la confirmación de la contraseña. El botón ahora en vez de entrar al sistema ahora nos dice que resetea y login.


## Mantenedores

### Ideas generales

* 

* 

* 

### Errores de formularios

* 
* 
* 
* 
* 
* 
* 
* 
* 

### Notificaciones

Como idea general las notificaciones o mensajes en productos digitales, nunca deben dañar la experiencia de usuario. Sino contribuir en que que el usuario final logre sus objetivos dentro de la plataforma. Siempre bueno diseñar las notificaciones en una etapa primaria de un proyecto, ya que ayuda bastante con el desarrollo de la misma y el manejo de errores.
Las notificaciones en un principio se califican en tres categorías alta, mediana y de baja atención es decir por niveles de gravedad. teniendo las notificaciones separadas por categoría podemos dividirlas de forma mas especifica y definiendo cuales serán de confirmación , error, mensajes de éxito o indicadores de estados.


##### Atención Alta
* Alertas (requiere atención inmediata)
* Errores (requiere acciones inmediata)
* Excepciones (anomalías en el sistema, algo no funciono)
* Confirmaciones (Acciones potencialmente destructivas que necesitan confirmación del usuario para seguir).
##### Atención Mediana
* Avisos (no requiere acción inmediata)
* Reconocimientos (feedback cuando un usuario ejecuta una acción)
* Mensajes de éxito
##### Atención Baja
* Mensajes de información (notificaciones pasivas)
* Banderas (normalmente son iconos, demostrando algo nuevo acaba de pasar desde la ultima interacción con el sistema)
* Indicadores de estado (feedback del sistema)

#### Ejemplos de notificaciones

* Notificacion de alerta:

* Notificacion de Reconocimiento:

* Notificación de Confirmación:

* Mensajes de Error (inline message):

## Asistente de configuración (wizard)

### How to Design a Form Wizard And when not to
Referencia: https://medium.com/nextux/how-to-design-a-form-wizard-b85fe1cc665a

* **Es mejor usar Wizards:**
Para una secuencia fija de ingreso de datos que no ocurre frecuentemente.
Para usuarios con poco conocimiento y que necesitan ser guiados a través de un proceso paso a paso.
Para una serie de ingreso de datos dependientes.
Cuando usuarios necesitan alcanzar un objetivo que depende completar tareas y sub-tareas.

#### Form Wizard Best Practices

* **Incorporar un indicador de progreso**


* **Reduce la cantidad de pasos. Entre más pasos incluyas, más grande es la posibilidad de que el usuario se fastidie. Trata de mantener los pasos bajo 10.**


* **Minimiza la posibilidad de navegar fuera del wizard. Esto mantendrá al usuario concentrado en el wizard.**


* **Incluye labels y una breve explicación del propósito**


* **Incorpora botones de acción claros y permite a los usuarios navegar hacia atrás y adelante.**


### Recommendations for Designing Usable Wizards
Referencia: https://www.nngroup.com/articles/wizards/

* **Use wizards for novice users or infrequent processes (e.g., configuration or setup)**
Wizards pueden ayudar a usuarios con poco conocimiento acerca del dominio simplificando el proceso y guiándolos.
Sin embargo, pueden ser un poco molesto si este proceso lo deben realizar frecuentemente o si el usuario posee conocimientos avanzados del dominio y su modelo mental del proceso es diferente al diseñado por el wizard.

* **Communicate a clear mental model of the process**
Mostrar una lista o diagrama de los pasos y destacar el paso actual. Es peligroso que el usuario pierda el contexto, se confunde o no se da cuenta qué tan largo va a ser el proceso. Es mejor indicar cómo es el proceso y cuantos pasos están involucrados.


* **Enforce a clear sequential order of the steps**
No permitas que los usuarios escojan un paso antes de completar los pasos que lo preceden.


* **Allow users to exit the wizard midway and save state. Allow them to resume the process at a later time**
Ocurren interrupciones, y los usuarios debiese tener la capacidad de guardar su trabajo y continuar luego el proceso.

### Dynamic Form or Wizard
Referencia: https://www.nngroup.com/articles/wizards/

Con la prevalencia de de tecnologias de AJAX, las diferencias entre un formulario y un wizard son pocas. Por ejempo, la paginda de ejemplo (Fidelity) le pregunta a sus usuarios si que son clientes de Fidelity, y dependiendo de su respuesta la pagina o le muestra campos de login o un formulario para inscribirse. Segun la definicion de wizard esto seria uno. y no un formulario ya que la pagina agrega campos de forma dinamica dependiendo de una decision.


La pagina de Microsoft tambien cambia la informacion en la pantalla a medida que el usuario ingresa informacion pero, en este ejemplo, los campos de ingreso se mantienen igual, mientras los mensajes de error o la explicaciones aparezcan mientras el usuario ingresa datos. Por end tecnicamente este no es un Wizard si no mas bien un formulario, ya que los pasos del procesos no son modificados por acciones tomadas por el usuario, aunque el formulario nos entrega feedback dinamico mientras el usuario va rellenanando con informacion.


### Wizards Muestran Menos Informacion en la Pagina
Referencia: https://www.nngroup.com/articles/wizards/

Ya que los Wizards separan procesos complejos en varios pasos, la mayoria de las veces los wizards son mas simples y contienen menos campos ademas de menos informacion. La simplicidad de una pagina tiene varios beneficios:
* Usuarios terminan siendo menos agobiados por el proceso. un formulario largo puedes ser abrumadora y los usuarios puedes sobreestimar la cantidad de trabajo que involucra llenar un formulario muy extenso.
* Menos esfuerzo cognitivo en completar el proceso. La mayoria de la informacion en un formulario termina siendo irrelevante, y todavia los usuarios tendrian que analizar y filtrar los campos. Con un wizard, los campos se despliegan dependiendo de la informacion ingresada anteriormente por el usuario y tienen mas probabilidad de ser importante mas no una distraccion para el usuario.
* Los usuarios se equivocarian menos. Con un formulario muy complejo, usuarios podrian ignorar ciertas partes ademas de tener errores en el ingresa de informacion al formularios. O, puede evitar entregar informacion importante.
* Cada paso tiene mas espacio en la pantalla. Cuando un formulario complejo es separado por pasos cada paso tiene su propia pagina, por ende hay mas espacio para cada formulario en ese paso. los objetivos pueden ser mas grandes , la informacion puede entrar en una sola pantalla (no sera casi necesario usar el scroll), y explicaciones pueden ir al lado de los campos de texto.

### El Camino Mas Corto Para Cada Usuario
Referencia: https://www.nngroup.com/articles/wizards/

Para algunos usuarios el camino para completar un proceso puede rapido y simple, mientras para otros puede ser tedioso y complicado. Si el proceso es bifurcado dependiendo de la entrada de datos del usuario y el bifurcado es transparente para el usuario, entonces el usuario no necesitar ir por un paso que no le implica. Por ende, en un wizard bien diseñado, la gente solo vere los pasos y informancion relevante para su situacion.

Por ejemplo, si un usuario no tiene una tarjeta de credito ellos no veran los campos de ingreso de datos de la tarjeta de credito si no la del medio de pago que le acomode.

### Cuando Un Wizard No es de Ayuda
Referencias: https://uxplanet.org/wizard-design-pattern-8c86e14f2a38

Se debe usar este patron muy cuidadosamente. Seprando un proceso en pasos mas pequeños no siempre entrega mejores experiencias de usuario:

* Cuando la tarea no es compleja
* Cuando el usuario es muy avanzado: A veces los wizards ara usuarios mas avanzados puede ser molestoso ya que encuentran que tiene limites y es muy rigido. Es muy comun que los wizards intenten ayudar en tareas que el usuario ya sabe hacer. un tip para esto es dar una opcion entre un wizard simple o uno avanzado.


### Buenas Paracticas para Wizards
Referencias: https://uxplanet.org/wizard-design-pattern-8c86e14f2a38

Cuando diseñando un wizard, hay buenas practicas que podemos aplicar:
* Mantener los pasos a un minimo: La parte dificil de diseñar un wizard es mantener un balance entre el tamaño de la pagina y la cantidad de pasos. Es absurdo tener un wizard de 2 pasos y uno de 10 pasos ya que puede ser abrumadora para el usuario. Idealmente, el proceso debiese tener entre 3-5 pasos.
* Mantener el proposito del wizard claro: En cada paso, usuarios necesitan entener claramente lo que el wizard esta pidiendo. Un wizard debiese proveer informacion concisa para que un usuario tome una decision actuar sobre esas decisiones. Si no esta claro, usuarios se pueden quedar atascado. Hay dos cosas que son escenciales para que el wizard quede mas claro:
* Una etiqueta de wizard clara y concisa.
* Una explicacion breve en al primera pantalla.
* Quitar elemeentos del interfaz inecesarias.
* Indicar claramente donde esta el usuario dentro del proceso.

## Editores de configuración

### Designing a better ‘Settings’ screen for your app

Referencia: https://uxdesign.cc/designing-a-better-settings-page-for-your-app-fcc32fe8c724

* **Group your categories**
La mejor forma de hacer más accesible los ajustes es agrupándolos por categorías. Intenta mantener el número de categorías bajo.


* **Prioritise the Categories**
Después de haber agrupado las categorías lo siguiente que debes hacer es priorizarlas. Imagina tener la categoría "Acerca de" que no es nada más que el número de versión y detalles del desarrollador (es una categoría poco utilizada). Pon las categorías más usadas o importantes al principio o arriba.


* **Destructive Items at Last**
Tener un ítem negativo (cerrar sesión o eliminar, etc) arriba de tu página de ajustes no es recomendado. El número de veces que el usuario cerra sesión o elimina datos va a ser mínima. Tener estos items tan accesibles arriba del menú de ajustes reducirá la visibilidad de otros más esenciales.


* **Essential Items at Top**
Imagina que hay un cambio importante en privacidad y términos y el usuario necesita revisarlo. Esta acción deberá ser puesta arriba para atraer más la atención.


### How to Improve App Settings UX
Referencia: https://www.toptal.com/designers/ux/settings-ux

* **Group Categories**
Cuando una aplicación tiene muchos ajustes, puede ser difícil para el usuario encontrar lo que necesite. La solución es agrupar los ajustes en categorías. Por ejemplo, Shopify tiene una larga lista de ajustes, pero ellos lo tienen ordenados por categoría que son más fáciles para navegar.


* **Evitar usar nombre con jergas**
Las jergas generan que los usuarios busquen contexto fuera del panel de ajustes. Los ajustes son mejor descritos con lenguaje plano que indica la funcionalidad. Evitar nombres técnicos que le dan al gusto a los equipos de marketing, pero confunden al usuario final.


# Tecnologías front end

En este apartado se detallan cada una de las tecnologías aplicadas en el front end de la aplicación.

## Typescript

TypeScript es un lenguaje de programación libre y de código abierto desarrollado y mantenido por Microsoft. Es un superconjunto de JavaScript, que esencialmente añade tipos estáticos y objetos basados en clases.

## React JS

React es una biblioteca Javascript de código abierto diseñada para crear interfaces de usuario con el objetivo de facilitar el desarrollo de aplicaciones en una sola página.

## Material UI

Framework para generar componentes de React para un desarrollo web más rápido y sencillo. Basado en Material Design (Google).

# Anexos

[Diagramas User-Flow](https://hqb-my.sharepoint.com/:f:/g/personal/fernando_perez_hqb_cl/Ep0WQb-LCH5Etvr48i22rEwB_cj_siLPVQ2AfTCBvvxdrg?e=UcuoAk)

[Código fuente maquetas](https://hqb-my.sharepoint.com/:f:/g/personal/fernando_perez_hqb_cl/EswYu4mEazVDjBv6SJk7D5wBQ4LyVgh9BIyK8PflctWlgw?e=DyuPGY)

[Demo Autenticación y Recuperación contraseña](https://hqb-my.sharepoint.com/:f:/g/personal/fernando_perez_hqb_cl/Evisb_XJ9HZHhxLKaBscjpMBXXboxp1CcPi_0I3pRhNwBQ?e=squhUh)

[Plantillas de correos](https://hqb-my.sharepoint.com/:f:/g/personal/fernando_perez_hqb_cl/EkdpPT-F6kpGj_ZTxe759tcBd0sRUBg0K9Qg1lePAgrAHQ?e=o5gDSe)