En una oscura práctica de la UPM ETSI Aeronáuticos, el profesor Efrén Moreno enseña un método distinto de concebir el diseño para cumplir unos requisitos funcionales, el llamado Diseño Axiomático de Suh.
Vamos a ver una aplicación simple de la teoría al diseño de un amortiguador de caídas para el Mars Rover de la NASA.
El desastre del diseño: Cuando los detalles eclipsan la simplicidad y la funcionalidad.
Os traigo dos parodias de diseños catastróficos: La señal de Stop y Microsoft rediseña el iPod.
Me reconozco en alguna escena, tanto de la parte del cliente (perdóname, diseñador, por haber pecado!) como del creativo. Y creo que vosotros también encontraréis escenas familiares en el video:
Nadie como Microsoft para comunicar con claridad:
(Lo siento! No recuerdo donde vi estos vídeos..)
¿Qué diseños horribles has visto últimamente? ¡Comenta! (No se admite la web de Renfe, hecha por Accenture)
Tim Brown, director de Ideo, habla sobre cómo un ambiente de juego y desinhibición puede fomentar la creatividad.
Mientras empresas como Google y Pixar apuestan por centros de trabajo amigables, hay muchas otras formas de redescubrir la creatividad.
En la charla, que no tiene desperdicio, Tim conduce varios experimentos con el público. En ellos, descubrimos que, como adultos, rechazamos frecuentemente lo novedoso, lo que se sale de las pautas. Pero, ¿qué pasa cuando es precisamente eso lo que necesitamos?
Juega como un niño: No rechaces ninguna idea, por absurda que parezca. Construye. Invéntate un papel. Respeta las reglas.
Explorar es crear, hacer variaciones de un original, proponer soluciones aunque no tengan sentido en el momento. Es volcar tu creatividad y no filtrar nada.
Construir es interactuar con tu idea. Es darle forma, trabajar sobre un resultado y aprender de él. Los prototipos, aún imperfectos, dan un feedback muy valioso.
Actuar es adoptar una situación. Ver desde los ojos del usuario. No pasar por alto los pequeños detalles.
Me encanta el role-play del paciente, cuando al llevarse una cámara de vídeo a una camilla descubre que durante la mayoría del tiempo el paciente solo ve.. el techo. Hace ver las cosas desde otro punto de vista, ¿no?
También me parece una buena demostración de cómo realizar una presentación, prescindiendo de powerpoint e interactuando con el público.
La mente del principiante está siempre abierta a todas las posibilidades.
Con una inversión de algo más de mil euros por máquina, se han asegurado una clientela satisfecha y que corra la voz. Una forma económica de hacerse oír, de boca en boca y en los medios.
(Aunque creo que esto no cuadraría en un restaurante de paellas!)
El problema de la gente buena, decía Villami, es que les da por hacer cosas dificilísimas. Construir monumentos, evolucionar la ingeniería, hacer aplicaciones web complejas, literatura enrevesada…
Y me acuerdo de Hugh Akston, el filósofo que se retiró para hacer hamburguesas en un bar de autopista. ¿De verdad era tan mala idea?
Hay demasiado talento desaprovechado, cuando las tareas más sencillas (a priori) como llevar un bar o hacer un buen cuchillo se dejan de lado. Imagina el talento de un gran publicista de guerrilla aplicado a atraer gente a un restaurante. O convertir una estancia de hotel en una experiencia, con un público fiel.
Hoy os hablo del proceso de feedback al diseño. Es complicado explicar un detalle en una aplicación como ésta, así que muchas veces es preferible recurrir a las imágenes para explicar un cambio.
Para eso usamos Skitch, un simpático programa para Mac que permite hacer capturas de pantalla, editarlas y publicarlas en una web para enseñar a los demás.
El proceso de edición es sencillísimo, con elementos para señalar y texto para comentar. Las opciones de drag & drop hacen que se integre muy bien con el entorno Apple, y es sencillísimo crear un archivo o publicarlo en la web de Skitch.
Una aplicación web es muy diferente a un programa de escritorio. El código está en nuestro servidor, y esto tiene unas ventajas enormes:
Todos los usuarios tienen la misma versión del programa.
Los datos son guardados con copias de seguridad, y libres de virus.
Podemos aprender de cómo cada uno usa la aplicación, por ejemplo, contando las veces que se hace click en cada elemento.
Los fallos son siempre registrados.
Sobre esto último os quería hablar hoy. ¿Qué alternativas tiene un programa cuando falla?
Fallar estrepitosamente. Esto desconcierta al usuario, que no entiende qué pasa.
Dejar un log de error en el servidor. Es incómodo, porque hay que revisarlos cada día.
Enviar un email al desarrollador. Tedioso, puede recibir cientos y perder el control.
Tener un feed RSS con los cambios. Más cómodo, pero sin demasiado orden.
Usar una aplicación web para gestionar cada error. ¡Como Hoptoad!
Hoptoad es un nombre realmente astuto. En la jerga ferroviaria, significa tren descarrilado. Como usamos Rails para dasarrollar Saiku, tiene sentido que a veces descarrile.
Cada vez que se produce un error, Saiku avisa a Hoptoad y éste guarda un registro del error. Si más usuarios tienen el mismo error, no lo duplica, sino que marca una cuenta de errores de ese tipo producidos.
Una vez identificado por nosotros, el error se corrige y se marca como solucionado en Hoptoad. Y así, nos sentimos más realizados!
Como desarrollador, ¿de qué forma controlas que tu aplicación no descarrile?
Aún no sabes lo que es RSS? Sigue nuestras noticias sin abrir el navegador, usando programas como Feedreader. Tendrás siempre los últimos post sin visitar nuestra web.