1. Ricardo Devis

2. Una Visión Panorámica

3. ¡Acrónimos, Disciplina
s y Círculos!
Según Dan Saffer, el Diseño de
Interacción cae enteramente
en el área del Diseño de la
Experiencia del Usuario
(UX), pero también tiene
intersecciones con la
Arquitectura de la Información
(IA), la Ingeniería de Interfaces
de Usuario (UIE), Factores
Humanos (HT), Ingeniería de
Usabilidad (UE), Diseño Gráfico
(CD), Diseño Industrial (ID!) e
Interacción Hombre-Máquina
(HCI): O sea, se trata de un área
multidisciplinar
que, precisamente por esta
característica, necesita de
criterios claros que permitan
establecer con nitidez sus
lindes. De alguna forma, se
trata de un “best of breed” .

4. Problemas, Trampas y Negocios
Una Lengua Franca

5. 
Buena parte del esfuerzo en la abstracción informática se
ha dado en tratar de superar el gap entre los modelos
reales (el dominio del problema) y los modelos software
(el dominio de la solución… software)
 …sin llegar a conseguirlo (de forma reglada)
▪ “Once upon a time there was a problem… and a software designer and…
oh, well, just there were two problems” [Plinio Smith]

Así que –mayormente– los intentos de especificación de
requisitos han derivado hacia el camino legal.
 Se trata de asegurarse que la solución software implantada es
inatacable (o difícilmente impugnable), desde el punto de vista
jurídico, una vez que el cliente ha firmado una lista de requisitos
funcionales (¿funcionales?)

Se dan, por tanto, diversas trampas que hay que evitar.

6. 
Los ProTecs acostumbran a comenzar sus proyectos con
una fase de descubrimiento de requisitos (usualmente
funcionales), que se plasman en documentos que suelen
forzar a firmar a las empresas, para así determinar de
forma monetariamente clara el alcance de sus trabajos
 Se trata de que el presupuesto se ajuste a la tarificación de tales
requisitos.

Pero no es posible para la empresa valorar la completitud
de tales requisitos, sino sólo (y a veces ni siquiera eso) su
corrección [explicar, explicar].
 Es decir: el documento de requisitos es una condición interna
del proceso de implantación, propia del ProTec, que éste
probablemente deba redactar
▪ …pero no constituye hito alguno para la empresa, que, en cualquier
caso, sólo podrá corregir en él errores obvios, pero no validarlo.

7. 

Sin que se suela renunciar a los requisitos atómicos
funcionales (que a menudo vienen acompañados de
números de referencia, como las piezas de
recambio), los ProTecs sustancian el “análisis” en la
descripción de las secuencias de trabajo (a modo de
“procesos”) que encuentran en el entorno de la
empresa.
Pero de nuevo se da un importante gap: el detalle de
tales procesos sólo tendría sentido si el nuevo sistema
fuera exactamente igual que el anterior (o que la
situación sin sistema informático alguno)
 …pues no son los procesos lo que hay que trasladar al
dominio de la solución, sino su esencia, los objetivos que
los animan. Y esto no son requisitos ni secuencias, claro.

8. 

Los auto-denominados “Métodos Ágiles” (que yo diría
“Métodos Frágiles”) fuerzan a la empresa/cliente a
redactar los “escenarios de negocio” en los que basar
las especificaciones de desarrollo software para
construir los sistemas que les den soporte.
Se trata, sin más, de otro medio de control del límite
de gastos y esfuerzos por parte de los ProTecs, pues…
 La capacidad analítica de las empresas no se evalúa antes
del trabajo
 Los requisitos surgen, de tales escenarios, de forma quasimágica (pues las listas resultantes se basan en la
experiencia y capacidades de su lector informático ).

9. 
El reto reside en que se dé “algo”, escrito o
codificado en un lenguaje que sea inteligible, a la
vez, para la empresas y para el ProTec
 …y que, por tanto, por derivación y
factorización, debería redactar el ProTec.
▪ …y sobre lo que, además, se pueda establecer una
correspondencia con lo que se advenga después
(diseño, software, interfaces, etc.)

Podríamos ya barruntar que tal lengua
franca, por necesidad, habrá de ser el lenguaje
natural.
 Pero… ¿se trata de una forma de especificar los
requisitos?
▪ No. Los requisitos no sirven. Veamos por qué.

10. Abandono (posicional) de los Requisitos
Abrazo (entusiasta) de los Objetivos

11. 
¿Cómo se determina la funcionalidad necesaria en una
aplicación o paquete software?
 ¿Mediante el análisis funcional? ¡Ja, ja, ja, ja!
 ¿Por medio de conjuros?
 ¿En razón de la experiencia de… ¿los analistas??

Caso de Estudio
 Logitech lanza su primer escáner USB
 Filosofía: soluciones combinadas Hardware (Hw) +
Software (Sw)
 Precio bajo y calidad alta

¿Qué funciones añadir al Sw del escáner?
 Esto es: ¿cómo determinar que debería ofrecerse?
▪ Y “todo” no es una respuesta buena: de hecho NO es una respuesta

12. 
¿Qué criterios son los habituales?
 Según el Gestor
▪ Toda aquella funcionalidad que se nos ocurra.
 Según los Programadores
▪ Toda aquella que sepamos hacer.
 Según el Jefe de Proyecto
▪ Toda aquélla que se haya firmado y no se salga del presupuesto
▪ Y si no cuesta esfuerzo y/o dinero… opina como los programadores.

En resumen…
 Se ponen/ofrecen/habilitan muchas funciones (todas las
posibles) y entre ellas estará la que necesite el usuario.
▪ Se suple la carencia de estrategia con fuerza bruta

13. 
Problema:
 Exhibir demasiada funcionalidad es tan malo como
ofrecer/habilitar/enseñar/poner poca.

Y encima… lo que se haga de más no es gratis.
 Requiere mayor esfuerzo de desarrollo
 El software es más complejo de utilizar
▪ ¿Por dónde empiezo? ¿Y la formación? ¿Y…?
 La funcionalidad útil se ve afectada por la innecesaria
▪ ¿Cuál es el criterio para poner un chat en un sitio Web?
▪ Un buen plato no es mejor por tener más ingredientes
 Los impactos de cada nueva funcionalidad en las ya
existentes son cada vez más difíciles de calibrar y manejar.

14. 
!Un momento, un momento!
 ¡Eso no pasa en los desarrollo software a medida!

En los “proyectos software personalizados” se da una
interfaz entre analistas, diseñadores y programadores.
 Los requisitos/funciones/tareas que debe reflejar y acometer el
programa se establecen en la fase de análisis.

¡Todo arreglado!
 ¿O no?

15. 
Problema de la lista de requisitos como interfaz:
 Falta información vital para el proceso de desarrollo
▪ RF3672: los usuarios tendrán que hacer (sic) login [!???!]
▪ RF6728: el código de cada artículo será único [!???????]
▪ RF8372: el cliente debe obtener una factura si la pide [!!??]

Cuando al diseñador/programador le llega una tal lista
de funcionalidades…
 Frecuentemente piensa que… “Esta funcionalidad puede
hacerse (sic) de varias maneras”
▪ ¿Cuál será la adecuada? ¿La que más proyección tenga?
▪ ¿(Se) Necesitará más flexibilidad?
 Así que el programador/diseñador se encuentra sin
criterios objetivos… para realizar su trabajo.

16. Fabricar una Máquina
que cumpla con los
Siguientes Requisitos:
1.
2.
3.
4.
5.
Que tenga un
motor de
combustión
interna
Cuatro ruedas
Un sistema de
transmisión del
motor a las
ruedas
Todo ello en un
chasis de metal
Que tenga un
volante

17. ¿Qué se perdió en la
lista de Requisitos?
1.
2.
3.
4.
5.
La potencia
necesaria del
motor
El tamaño de las
ruedas
La velocidad
mínima
El número de
pasajeros (??)
Las posibles
adiciones
¡Falta el objetivo
de la máquina!

18. ¡Objetivos!
Objetivo: Cortar el
césped de forma
rápida y cómoda.
Y ahora, con este
objetivo en
mente, todos los
requisitos (que
ahora se entienden
de otra manera)
hallan su contexto
operativo, su
entorno correcto y
los límites de sus
rangos, valores y
calibraciones.

19. Planteamiento de
Problemas
Pasar por todos los
puntos trazando
cuatro líneas
rectas… sin levantar
el lápiz del papel.

20. Problema de Límites
Los límites
son, usualmente, só
lo autolimitaciones.

21. Extensión de
Problemas
Pasar por todos los
puntos (sin levantar
el lápiz del papel)
trazando…
1.
2.
Una sola línea
recta
Una sola línea
recta… ¡por un
solo punto!

23. 
Resolución General de Problemas:
 “The overly strict limits are a block in the mind of the solver […]. A
solution is sensitive to the proper isolation of the problem. In
general the more general de problem can be stated the more room
is available for conceptualization”
James L. Adams [Conceptual BlockBusting]

Los objetivos, como criterios clave, son la forma de
plantear los problemas que permite un mayor rango de
soluciones
 …y no un mayor rango de opciones [explicar].
▪ Requisito (malo): exigencia de identificación de usuarios
▪ Objetivo (razonable): evitar la desaparición de información
▪ Implementación (plausible): que nada se borre [versionamiento]
▪ Si se evita el requisito y se hace caso al objetivo, la implementación se centra en el
problema en sí, y no en una de sus funcionalidades posibles (opción de “login”).

24. ¡ID! ¡Sorpresa!
En definitiva…
1.
2.
3.
Es difícil determinar la
funcionalidad que debe ser
construida y exhibida en
una aplicación.
Es tan malo pasarse como
quedarse corto.
Los requisitos no son
suficientes.
tachán,
tachán,
tachán,
tachán
El Diseño de Interacción
(ID: Interaction Design)

26. Modelado mediante Personas, Objetivos y Escenarios
Un Ejemplo Práctico

27. 
Al final… ¡Tiene que haber un programa!
 Por tanto obtener una codificación es un objetivo

¿Qué se necesita, entonces, en las fases de desarrollo?
 Un planteamiento del problema que permita soluciones efectivas
▪ Las [Personas + Objetivos] son ese planteamiento

El analista tiene que descubrir, pues…
 Quién es el usuario y cuáles son sus necesidades fundamentales

28. Y… ¿Entonces…?
No se trata de renunciar
a los requisitos
formales, sino de
superar el “gap mágico”
que se da entre estos y
la solución final, pues es
cierto que parece darse
una suerte de milagro
entre lo que se requiere
y lo que se obtiene.
Las herramientas para
obtener resultados que
puedan ser trazados
son: personas, objetivos
y escenarios. Veámoslas.

29. Personas
Objetivos
Escenarios

30. 
Persona
 “Una persona es la descripción precisa de un
usuario y de lo que quiere lograr” [Alan Cooper]

Modelo
 “Esquema teórico de un sistema o de una realidad
que se elabora para facilitar su comprensión y el
estudio de su comportamiento” [DRAE]

Ejemplo
 v = e / t [Algún griego]

31. 
En informática ya se utilizan modelos
 Pero... ¿por qué no modelar también los usuarios?
▪ Si es el objetivo de todo sistema ¿cómo no estudiarlo y
comprenderlo?

Los modelos se utilizan para estudiar, en un
determinado contexto (en razón del que se construye
el modelo) el objeto que constituye la base del
modelado [¡Uf, cuánto repetir la raíz “modelo”!, ¿eh?]
 Así, por ejemplo, un CrashTest Dummy es un modelo de
una persona en el contexto de un accidente (de
automoción), que permite estudiar su evolución y
reacciones en tal contexto.

¿Qué me tiene que decir un modelo de una Persona?

32. 
Problemas a resolver para y por el analista:
 ¿A quién entrevista el analista cuando el usuario no está
accesible?
▪ Paquetes Software o Sitios Web
 Aunque pueda entrevistar al usuario…
▪ ¿Qué la va a responder éste cuando se le pregunte si quiere la
funcionalidad X?

Ventajas de un modelo del usuario
 Sustituye al usuario cuando NO se le puede preguntar qué
necesita
 Sustituye al usuario cuando se le puede preguntar qué
necesita
▪ Ojo, que el usuario sigue siendo imprescindible…

33. 
¿Qué debe tener el
modelo?

 Nombre

Nombre
 María Excel
▪ El identificador único de la
“persona”, que nos permite
referirnos a ella de forma
inequívoca
Descripción
 María trabaja de secretaria en
el Departamento de
Expediciones. Ha estudiado
algo de Office y es
administrativa. No usa
Internet pero es capaz de
hacer hojas de cálculo
complejas con fórmulas y
gráficos en cuestión de
minutos.
 Descripción
 Objetivos (motivación y
razón)

Objetivos
 Mantener informado a su
superior sobre desviaciones
en el volumen de los envíos

34. 
¿De donde se extrae la información de una
Persona?
 Entrevistas con usuarios (se avisó)
 Estudio de sistemas existentes
 Procedimientos, etc.

La idea es recabar toda la información que se
pueda y con ello formar el modelo de los
usuarios
 Una vez hecho esto se extrae/deduce el resto de la
información a partir del modelo
▪ Es el matiz diferencial con un análisis clásico

35. 
¿Hasta donde describir una Persona?
 Hasta que permita la empatía
▪ Empatía: "Identificación mental y afectiva de un sujeto
con el estado de ánimo de otro" [DRAE, otra vez]

ID es el Método Stanislavsky del Diseño
 Y… ¿dónde ensaya? (esto, es ¿dónde se utilizan las
personas?
▪ En las Reuniones de Diseño

36. 
Reuniones de Diseño [Antes]:




Diseñador 1: ¿Y si el usuario quiere imprimir esto?
Diseñador 2: No creo que quiera imprimir eso
Diseñador 1: Pero a lo mejor alguien quiere imprimirlo
Diseñador 2: Yo creo que no.
▪ [Repetir esta discusión en cada reunión hasta el final del proyecto]

Reuniones de Diseño [con Personas]:
 Diseñador 1: ¿Y si el usuario quiere imprimir esto?
 Diseñador 2: El usuario se llama María y a María eso no le sirve para
nada. Lo haría con el Excel.
 Diseñador 1: Pero a lo mejor le sirve a otro usuario
 Diseñador 2: Pero estamos diseñando para María.
▪ [Fin de la discusión y a tomar unas cervezas]

La Persona es un ente al que se invoca para atajar los “¿Y si…?”

37. El Usuario Elástico
Otro objetivo de las
personas es evitar el
problema del “usuario
elástico”
El software se escribe,
en vez de para
personas, para este
legendario usuario
elástico… que no
existe!!
Debería ser el software
el que se adaptara a las
necesidades del usuario
Normalmente es al
usuario al que se le
estira para que
encaje en la
funcionalidad

41. Personas
Objetivos
Escenarios

42. 
La parte fundamental del modelo de un usuario
(Persona) son los objetivos
 Los objetivos son los que motivan a las personas “a
hacer las cosas”
▪ Por ellos se sabe qué cosas harán y cuáles no

Los objetivos son las motivaciones para que las
personas desarrollen requisitos
 Por tanto la única forma de saber qué requisitos se
necesitarán implementar es averiguar sus objetivos

¿Cómo se sabe si un diseño es un buen diseño?
 ¿Cómo comenzar entonces un desarrollo sin
considerar personas y sus objetivos?

43. 
¿Cómo saber si hemos encontrado un requisito o
un objetivo?
 Un objetivo es una condición final
▪ Un requisito es un medio para conseguir un objetivo
▪ Objetivo: viajar a Vitoria
▪ Requisitos: comprar un coche, lavarlo, echar gasolina, echar
aceite, pagar seguro.
 Los objetivos permanecen, los requisitos cambian
▪ Los requisitos tienen que ser planteados (y re-planteados) en
función de la tecnología disponible
▪ Si se tiene una lista de requisitos uno se suele limitar a
optimizarlos en vez de replantearlos

44. 
Objetivos Finales
 Representan las expectativas de una Persona a la hora de
interactuar con un producto
▪ Encontrar el mejor precio
▪ Generar las facturas
▪ Dar la situación de la empresa

Objetivos Personales
 Son objetivos que tiene toda Persona. Por tanto a veces no es
necesario explicitarlos (por generales), pero mi consejo es que sí
se detallen expresamente (pues en ciertos entornos, como por
ejemplo las redes sociales, son determinantes)
▪ No sentirse estúpido
▪ No cometer errores
▪ Divertirse (o al menos no aburrirse).

45. 
Durante la fase de
análisis se extraen los
objetivos finales
 Deben ser cumplidos para
que el usuario vea al
producto como algo útil
▪ Pero deben cumplirse
obligatoriamente también
los objetivos personales para
que el producto tenga éxito

La esencia del ID es
plantear una interacción
que cumpla los objetivos
finales sin violar los
objetivos personales

46. Personas
Objetivos
Escenarios

47. 
Finalmente hay que llegar a concretar la funcionalidad que
tendrá cada sistema.
 Los requisitos no desaparecen; se entregan igualmente… pero
en un diferente contexto: el de los objetivos

Los escenarios son la herramienta para averiguar las
requisitos necesarios para cumplir con los objetivos de las
personas
 “Un escenario es una descripción concisa de una Persona usando
una aplicación para cumplir uno o más de sus objetivos”

¿Cómo se crean los escenarios?
[Alan Cooper]
 Poniéndose en el papel de una Persona se coge uno de sus
objetivos y se busca la forma más directa de conseguirlo
▪ Debe interpretarse el papel intentado pensar cómo él y teniendo en
cuenta sus habilidades, capacidades y posibilidades.

48. 
Un escenario es a la vez generador de
requisitos y filtro para desestimarlos
 No tiene sentido un requisito que no venga de un
escenario
 No tiene sentido un escenario que no sea la forma
más sencilla de lograr un objetivo

Norma Fundamental para la Obtención de
Escenarios
 “No presuponer ningún sistema ni herramienta”

49. 
Tipos de escenarios
 Diarios
▪ Son los más importantes ya que son los se realizan con mayor
frecuencia
 Necesarios
▪ Son el resto de las acciones que deben ser realizadas para
cumplir los objetivos (mantenimiento, medidas
correctivas, etc.)

En función de ello habrá que implementar la
solución más…
 Eficaz
 Sencilla

50. 
Veamos un ejemplo de ID
 Logitech lanza su primer escáner USB
 La filosofía de esta compañía es lanzar soluciones
combinadas Hardware + Software
 Gama media/alta con muy buen precio

¿Qué funciones añadir al Software del escáner?
 Lo primero que hay que hacer es…
▪ …Quitar toda funcionalidad
▪ No hay personas ni objetivos así que no tiene sentido plantear
alternativas de diseño que no se pueden validar
 Comenzar identificando personas…

51. VÍCTOR WEBITO
CARLOS ESTUDIANTE
Es un chico de 25 años que ha
montado una pequeña
empresa en su casa para crear
sitios Web.
 Sus conocimientos técnicos
son los justos para construir
sitios Web pequeños. No es
un artista gráfico pero utiliza
imágenes para formar la
estética de sus sitios Web. El
escáner le permite obtener
imágenes de calidad
media, algo suficiente para la
Web.


Universitario de 20 años que
necesita escribir
frecuentemente trabajos o
informes que debe presentar
en clase .
 Sus conocimientos son los
básicos que le permiten usar
el Word (o similar) para
escribir las prácticas, sin
demasiadas florituras. Utiliza
el escáner para mejorar sus
trabajos con imágenes de
libros o fotografías.

52. INOCENCIO GRÁFICO


Profesional free-lance que
comienza en el negocio de
diseño gráfico (un
novato, en definitiva).
No puede hacer una gran
inversión por lo que
nuestro escáner le servirá
durante el inicio de su
carrera.
EXPERTO DELAMUERTE

Un diseñador gráfico
profesional queda
rechazado como Persona

53. 
Ni Víctor ni Carlos (programador y universitario) están
interesados en manipular imágenes
 Su objetivo no es escanear imágenes con calidad
profesional y, por tanto…
▪ No quieren tratar con resoluciones y demás pamplinas de
configuración del escáner
▪ Quieren encontrar sus imágenes rápidamente y colocarlas en los
documentos destino

Inocencio si que quiere…
 Controlar los aspectos del escaneado
▪ Conoce las resoluciones y la representación del color
 Manipular la imagen de forma avanzada
▪ Filtros, máscaras, manipular colores, etc.
▪ Sin embargo… por ello precisamente no va a utilizar nuestro software.

54. 
En cuanto a la resolución del escaneado
 Victor y Carlos no saben lo que es eso
▪ Sería mejor no enfrentarles con esa decisión
 Inocencio sabe manejar las resoluciones
▪ Pero... ¿con qué objetivo?

En definitiva los objetivos (comunes) son:
 Poder cambiar el tamaño de la imagen
 Insertarla en otro programa

55. Sin
herramientas
Acceso
directo a los
programas
No pregunta
dónde guardar
la imagen

56. 
Objetivos cumplidos
 Eliminar completamente la configuración del escaner
 Evitar tener que colocar y buscar las imágenes por el
sistema de ficheros
 El programa está orientado a insertar las imágenes en
otros programas

Resultado
 En las evaluaciones fue calificado como el software
más práctico de escaneado
 Fue el producto de Logitech que menos llamadas de
soporte recibió
 Fue en el que menos se invirtió en desarrollo

57. Casos de Uso, Usabilidad
Diseño Gráfico, Producción Cinematográfica

58. 
Generalmente se utilizan los casos de uso para
documentar la funcionalidad ya establecida del sistema
 Cuando se diseña un caso de uso habitualmente se hace con la
segmentación funcional en mente
 El interior que pasa a ser el origen de todo en vez de una
consecuencia
▪ Va hacia atrás

Podría utilizarse en el mismo sentido que el ID
 Pero los actores tienen poca entidad y dependen de la visión
funcional que se tenga del sistema
▪ Altas, bajas, modificaciones...

Las últimas propuestas en construcción de Casos de Uso
proponen una tendencia hacia el ID.

59. 
La usabilidad es un complemento del diseño de
interacción, pero no es suficiente sin éste
 Los tests de usabilidad con usuarios pueden mostrar
la eficacia de un usuario para realizar requisitos
propuestas
▪ Pero no sirven para demostrar si esas requisitos son las que
realmente cumplen los objetivos

La usabilidad es “no hacer perder tiempo al
usuario”
 El ID es no hacer perder tiempo a los desarrolladores y
al cliente.

60. 
El Diseño de Interfaces sigue estando al final del
ciclo de vida
 La estética es cuestión de gusto
▪ La estética atrae al usuario; el ID lo captura

El problema del diseño de interfaces es que
asume que hay Personas por un lado y código
por otro.
 Su misión es que se comuniquen

El objetivo del Diseño de Interacción no es
diseñar pantallas.
 Pero se sirve de ellas para calibrar la consecución de
los objetivos

61. Preproducción
Escribir Guiones
Storyboards
Casting
…
Producción
Rodar
Actores se
emocionan
Gritar “corten”
Repetir toma
…
Personas y
Diseño
Objetivos
(componentes)
Escenarios
Programar
requisitos
Paper
Prototyping
Especificaciones
Post-Producción
Montaje
Banda Sonora
Promoción
…
Cierre
Documentación
Pruebas
Formación
Mantenimiento
…

62. 



¿Dónde están los pasos para obtener
Personas?
¿Cómo se obtienen entonces las Personas?
¿Qué supone pasar al ID?
Si al final depende de las personas ¿Por qué
usar el ID?
 Porque el esfuerzo de análisis es similar pero se
obtiene un resultado más fácil de
validar, simplificar y comunicar a desarrollo
▪ Documentación que aporte valor

63. 

Catálogo de Personas y
Objetivos
Descripción de
Escenarios

 Paper Prototyping
 Invocaciones, Notificacion
es
 Entidades y Relaciones
 Diagrama de clases
 Diagramas de secuencia
 De Interacción con el
Sistema
▪ Textual
▪ Prototipos [en papel] de las
pantallas
 De Interacción entre

▪ Requisitos para otros lotes
Manuales del usuario
 Extraídos, en buena
Subsistemas
▪ Diagramas de Secuencia de
Invocaciones y
Notificaciones
Especificación de
Subsistemas
medida, de los escenarios


Guías de Administración
del Sistema
Guías de Instalación

64. Reflexión Ponente/Asistentes
Debate Final

66. 











Requisitos
Análisis
Objetivos
Personas
Escenarios
Interacción
Ejemplos
Aplicaciones
Prototipos
Funciones
Entregables
Libros