2.

- METODOLOGA PARA EL DISEO DE INTERFACES AMISTOSAS

Metodologa

121

M. Martnez, URJC, 2001

2.1.- Introduccin

Metodologa

122

M. Martnez, URJC, 2001

Diseo centrado en el usuario

Factores humanos + Diseo iterativo

Metodologa

123

M. Martnez, URJC, 2001

 Se trata de que los diseadores trabajen CON los usuarios finales. Ayudando a definir qu es lo que va a hacer nuestra aplicacin y cmo. Proporcionando realimentacin sobre los sucesivos diseos, en un proceso iterativo. El diseador debe tratar de: Ver la aplicacin desde el punto de vista del usuario. Entender cmo encaja en el conjunto de las actividades de los usuarios. NO es un proceso centrado en la tecnologa ni en la funcionalidad.

Metodologa

124

M. Martnez, URJC, 2001

 Anlisis Es una parte del anlisis y especificacin de requisitos, pero con una orientacin mayor a los factores humanos, y en contacto con usuarios reales Diseo Se disea la imagen que va a dar la aplicacin vista DESDE FUERA. Posteriormente se disea la estructura interna (mdulos e interfaces software) Implementacin Utilizando herramientas de desarrollo rpido que faciliten la creacin y modificacin de prototipos. Evaluacin No se trata simplemente de comprobar que funciona correctamente, sino de contrastar el diseo.
Metodologa

125

M. Martnez, URJC, 2001

Consideraciones prcticas
En aplicaciones con interfaz grfica, entre el 40% y el 80% del cdigo se dedica a la gestin de la interfaz. Aproximadamente el 25% de las aplicaciones son un fracaso: Excesivo tiempo o coste de desarrollo. No se tienen los suficientemente en cuenta las necesidades de los usuarios. Son difciles de aprender y/o de usar => no se venden o apenas se usan.

Metodologa

126

M. Martnez, URJC, 2001

 El diseo centrado en el usuario puede ser difcil de introducir en la empresa: Poco difundido en Espaa Puede ser difcil entrar en contacto con los usuarios. Muchos diseadores y programadores
Se creen capaces de disear interfaces. Estn acostumbrados a hacerlo. Les resulta molesto introducir modificaciones.

No encaja bien con la metodologa habitual de desarrollo del software.

Ciclo de vida Especificaciones de requisitos y de diseo rgidas.

Ms difcil de planificar. Supone un esfuerzo adicional. Los beneficios que aporta no se observan durante el desarrollo.
Metodologa

127

M. Martnez, URJC, 2001

Algunas estrategias
Implicar al resto del equipo de desarrollo en la preocupacin por la usabilidad. Evaluacin temprana: El coste de corregir un error en la especificacin de requisitos se multiplica por 10 en cada fase. Trabajo en equipo. Primeros prototipos:
sobre papel. sin funcionalidad real

Evaluar inmediatamente los aspectos dudosos. La perfeccin es imposible.

Metodologa

128

M. Martnez, URJC, 2001

 Medidas de usabilidad (t de aprendizaje, n de errores, t para realizar una tarea) NO fijarse objetivos concretos Para comparar alternativas de diseo. Para convencer de la rentabilidad del esfuerzo dedicado a la interfaz. Los manuales y sistemas de ayuda son parte integral de la interfaz => incluirlos en el proceso de diseo.

Metodologa

129

M. Martnez, URJC, 2001

 Integracin con otras metodologas: Hacer prototipos rpidos al principio, como mtodo de anlisis y especificacin de requisitos, despus tirar los prototipos e implementar desde cero.
Problema: Slo se pueden evaluar de forma incompleta. Se pueden dejar los problemas detectados en la aplicacin para la siguiente versin.

Definir al principio la interfaz entre el cdigo que gestiona la interfaz y el resto de la aplicacin. Disear e implementar en paralelo.
Problema: El cdigo de gestin de la interfaz es de baja calidad.

Metodologas de ing. del software que incluyen aspectos de diseo centrado en el usuario. Ejemplo: Proceso unificado.
No incluyen todos los aspectos deseables.
Metodologa

130

M. Martnez, URJC, 2001

2.2- Anlisis

Metodologa

131

M. Martnez, URJC, 2001

2.2.1 Qu informacin buscar?

1) Identificar a los usuarios. 2) Caractersticas de los usuarios y de su entorno. 3) Flujos de informacin. 4) Restricciones al diseo. 5) Anlisis de tareas.

Metodologa

132

M. Martnez, URJC, 2001

Identificar a los usuarios

Perfil general de los usuarios de la aplicacin a disear. Podemos tener varias categoras, en cuyo caso debe realizarse el anlisis para cada una de ellas. Ejemplos: Para un sistema de matriculacin:
Alumnos que se matriculan por primera vez Alumnos que ya se han matriculado en cursos anteriores.

Para una agenda:

Profesional con citas Secretaria que se ocupa de la agenda de su jefe.

Si no conocemos a priori a los usuarios, o si tenemos un perfil muy genrico, buscar ejemplos de usuarios, tratando de cubrir el mayor rango posible.
Metodologa

133

M. Martnez, URJC, 2001

Caractersticas de los usuarios y de su entorno

Nivel intelectual (nivel de educacin). Conocimientos: Experiencia con ordenadores.
En general. Con sistemas concretos (PC, Unix, etc)

Conocimientos sobre el dominio de la aplicacin (contabilidad, programacin, etc.) Terminologa. Actitud: Disposicin para aprender a utilizar un programa nuevo. Tiempo que estn dispuestos a dedicarle a este aprendizaje. Miedo a los ordenadores.

Metodologa

134

M. Martnez, URJC, 2001

 Frecuencia de uso. Usuarios sin experiencia.

Factores predominantes: Tiempo de aprendizaje y nmero de errores.

Usuarios expertos.
Factor predominante: Velocidad para realizar una tarea.

Usuarios intermitentes. Utilizan la aplicacin varias veces pero con periodos de tiempo largos entre una y otra (Por ejemplo, una vez al mes).
Factor predominante: Nivel de retencin.

Metodologa

135

M. Martnez, URJC, 2001

 Excepcionalmente: Edad Habilidades fsicas y de percepcin. Entorno fsico:

Iluminacin. Posicin fsica. Distancia a la pantalla. Ruido. Etc.

Metodologa

136

M. Martnez, URJC, 2001

Flujos de informacin
De dnde viene y a dnde va la informacin Medio Formato Disponibilidad Es recomendable recopilar toda la informacin posible, ya que detalles como posicin, color, etc., pueden influir en el diseo. Formularios. Todo tipo de documentos relacionados. Aplicacin usada actualmente, si existe.

Metodologa

137

M. Martnez, URJC, 2001

Restricciones al diseo
Coste Fiabilidad Plataformas hardware y software Portabilidad Internacionalizacin Compatibilidad Normas o estndares de interfaz de usuario

Metodologa

138

M. Martnez, URJC, 2001

Normas de interfaz de usuario

Por qu normas?
Portabilidad. Comunicacin entre aplicaciones. Consistencia en la forma de operar (look&feel).

Tipos de normas
Interfaz de programacin (API = Application Programming Interface) Comunicacin entre aplicaciones. Normas de estilo (Style guides)

Metodologa

139

M. Martnez, URJC, 2001

Normas de estilo
oficiales
ISO/IEC JTC 1/SC18/WG 9 User-system interfaces and symbols ISO TC159/SC4/WG5 Software ergonomics and man-machine dialog ECMA TC35 User-system interfaces MIL-STK-1472

Normas de facto
IBM CUA (Common User Access) Microsoft Windows Microsoft Windows User Experience : Official Guidelines for User-Interface Developers and designers, Microsoft Press, 1999 X Window/OSF Motif OSF/Motif Style Guide Addison-Wesley Macintosh Apple Macintosh Human Interface Guidelines Addison-Wesley
Metodologa

140

M. Martnez, URJC, 2001

Anlisis de tareas
Se realiza para cada perfil de usuario que hemos identificado. 1) Actividades generales del usuario. En una empresa, consistira en una descripcin de sus funciones en su puesto de trabajo. Ejemplos: Administrador de producto
Se encarga de las relaciones con los clientes. Establece la poltica de precios. Se encarga de los presupuestos y de las previsiones de ventas futuras.

2) Identificar las tareas del usuario que van a tener algn tipo de soporte en nuestra aplicacin. 3) Descripcin detallada de cada una de estas tareas.
Metodologa

141

M. Martnez, URJC, 2001

Descripcin de tareas
Descomposicin jerrquica en subtareas. Relaciones jerrquicas de: Pertenencia (partes de una tarea, no necesariamente en orden) Distintas maneras de realizar la tarea en funcin de las circunstancias (decisiones). Alternativas que se eligen por preferencias personales(elecciones). Incluye tambin las operaciones que NO realiza la aplicacin (realizadas directamente por el usuario, o con otras herramientas). Incluye tambin tareas y acciones mentales (decidir, elegir) y de percepcin (localizar). Se desarrollan en mayor o menor detalle dependiendo del grado de relacin que puedan tener con la aplicacin.

Metodologa

142

M. Martnez, URJC, 2001

 NO se deben reflejar decisiones de diseo ni sobre la funcionalidad en este anlisis. Cada tarea, subtarea: Aparece como verbo-substantivo(s). Siempre que sea posible, se expresa el objetivo (QU se hace, pero no CMO) P.ej. localizar en lugar de buscar. Al menos para las ms significativas, pedirle al usuario un ejemplo concreto, con datos concretos.

Metodologa

143

M. Martnez, URJC, 2001

 Aadir informacin que pueda influir en el diseo, como:

Frecuencia de uso. Tareas que se realizan al mismo tiempo. Si puede ser interrumpida por causas externas para retomarse ms tarde. Posibles errores. Requisitos de usabilidad especiales.

Se puede llegar a hacer un diagrama de flujo, pero es muy laborioso.

Metodologa

144

M. Martnez, URJC, 2001

Ejemplo
Tarea: Coger un tren de cercanas. T1: Llegar a la estacin. T2: Averiguar la hora de salida del tren. Partes: T2.1 Encontrar el tablero de trenes de salida. T2.2 Buscar en el tablero el tren deseado. T2.3 Anotar mentalmente la hora de salida y el andn.

Metodologa

145

M. Martnez, URJC, 2001

T3: Comprar el billete. Partes: T3.1 Encontrar la taquilla. T3.2 Guardar cola ante la taquilla. T3.3 Al llegar a la taquilla, indicar el destino. T3.4 Averiguar el precio del billete. T3.5 Poner el dinero para pagar el billete. T3.6 Recibir el billete y el dinero sobrante.

Metodologa

146

M. Martnez, URJC, 2001

T4: Si el tiempo hasta la salida del tren es demasiado largo, esperar hasta la hora de salida. Partes: T4.1 Decidir si el tiempo es demasiado largo. T4.2 Elegir el lugar donde esperar. T4.3 Esperar hasta la hora decidida . Alternativas: T4.3.1 Esperar en el vestbulo. T4.3.2 Esperar en la cafetera. T4: Llegar al andn. T5: Subir al tren.

Metodologa

147

M. Martnez, URJC, 2001

2.2.2. Cmo obtener la informacin

Visitar el lugar de trabajo del usuario. Observar a los usuarios mientras trabajan. Recopilar todo tipo de documentos relacionados con las actividades de los usuarios. Entrevistar a los usuarios y a otras personas relacionadas con ellos. E. no estructuradas E. estructuradas. E. semi-estructuradas. Pedirle que rellene un cuestionario. Si estn utilizando actualmente una aplicacin, pedrsela. Preparar conjuntamente un prototipo. Si es posible, utilizar medios de grabacin (vdeo, audio, fotos)
Metodologa

148

M. Martnez, URJC, 2001

Entrevista semiestructurada
El entrevistador lleva preparada una lista de preguntas, para asegurarse de que recoge toda la informacin relevante, pero permitiendo la conversacin espontnea, e improvisando nuevas preguntas segn la informacin recibida. Ejemplos de preguntas: Por qu haces esto? (objetivo) Cmo lo haces? (Para identificar subtareas. Aplicar recursivamente) Por qu no lo haces de esta otra manera? (Proponiendo una alternativa. Para obtener la justificacin)

Metodologa

149

M. Martnez, URJC, 2001

 Cules son las precondiciones para hacer sto? Cules son los resultados de hacer esto? Puedo ver los resultados de tu trabajo? Puede producirse algn error al hacer esto? Qu haces para descubrir y corregir este error? Adaptando las preguntas a la actividad.

Metodologa

150

M. Martnez, URJC, 2001

2.2.3 Decisiones sobre funcionalidad

El cliente NO SIEMPRE tiene razn. No sabe bien lo que quiere. No es consciente de qu puede hacerse y qu no con un computador. No es consciente del coste y/o dificultad de implementacin. El computador es una herramienta, el objetivo es: Facilitar la labor del usuario. Aumentar la productividad. La automatizacin puede cambiar la naturaleza de las tareas del usuario.

Metodologa

151

M. Martnez, URJC, 2001

 Alternativas: Mantener las tareas, pero proporcionando ayuda a la mente. Ejemplo: Alarmas electrnicas. Usar la tecnologa para hacer visible lo invisible. Ejemplo: Presentaciones grficas de funciones matemticas o procesos fsicos. Mantener las tareas, pero automatizndolas en todo o en parte. Ejemplo: Procesadores de textos. Cambiar la naturaleza de las tareas. Ejemplo: Bsqueda de informacin en el Web.

Metodologa

152

M. Martnez, URJC, 2001