Algunas personas creen que el diseño es el aspecto, pero cuando se profundiza te das cuenta que es el cómo funciona.
Steve Jobs
Hay mucha bibliografía sobre Steve Jobs, este verano me sorprendió el libro Inside Apple design process during the golden age of Steve Jobs, de Ken Kocienda, que describe los procesos empleados para desarrollar el iPhone. Kocienda fue el responsable del teclado de los iPhone, base de los teclados táctiles que todos usamos hoy día. Hasta leer el libro pensaba que los teclados táctiles eran un simple QWERTY pero para que funcionen existe mucho diseño invisible. Del libro me quedo con tres aprendizajes que me gustaría compartir, demos, equipos pequeños y empatía.
Demos, demos, demos
El proceso creativo se desarrollaba por demos de producto. Demos de las ideas y propuestas que tenían para cada funcionalidad. Las demos podían durar 2 minutos. Cada demo debía mostrar progreso y después de cada demo debía existir progreso. Existía una pirámide de demos que acababan en Steve Jobs. La demo consistía en probar la funcionalidad, no ppt, no presentaciones, no explicaciones. La demo debía ser concreta y específica. En cada demo existía un «decisor» que determinaba ¿Qué ocurre ahora? ¿Se evoluciona? ¿Se descarta? ¿Se muestra a otra persona?. Las demos constantes focalizaban al equipo en hacer un gran producto. Cada demo tenía una expectativa definida: progreso. Las demos producían reacciones, catalizador para decisiones creativas. El libro Becoming Steve Jobs cuenta que cada miembro del consejo tuvo que presentar su propio trailer realizado con iMovie antes de presentar el producto. La cultura de las demos comenzaba mostrando una idea y acababan en las keynote de Steve Jobs.
Para decir SI a las demos decían NO al resto de técnicas: test A/B, mockups, documentos, dibujos en pizarra. Los test A/B solo te ayudan con pequeñas decisiones (color de un botón) y no aportan a las grandes decisiones. Preferían que su conocimiento en diseño decidiera el color o posición de un botón. No me cuentes tu idea, déjame probar la funcionalidad.
El proceso creativo se podía resumir en:
Feedback-> próxima Demo: mejora creativa
Curiosamente este enfoque creativo me resulta similar al usado por Pixar que se explica Creatividad S.A.
Equipos Pequeños
Safari comenzó con 2 personas y lo finalizaron 10 personas. En las patentes del iPhone hay 25 personas. Steve Jobs define Apple, como la Startup más grande del mundo, organizada en equipos pequeños y con responsabilidad individual. Cuando eras seleccionado o elegías hacerte cargo de una funcionalidad concreta firmabas un documento llamado DRI (Directly responsible individual) por el cual te hacías cargo de sacar adelante ese trabajo. En Apple eran expertos en dividir el trabajo en partes. Ken Kocienda responsable del teclado del iPhone apenas vio el dispositivo u otras funcionalidades del mismo. Estuvo durante años focalizado en el teclado y aislado del resto. Para desarrollar y probar sus ideas no lo hizo en un iPhone hasta la fase final, la denominada fase de convergencia. Equipos pequeños, focalizados, responsables y con un objetivo común. Cuando a Ken Kocienda le encargaron hacer el Safari, Steve Jobs personalmente estableció el objetivo o valor del producto, velocidad. Todo lo demás pasaba a un segundo plano la velocidad se convertía en el faro que iluminaba cada compilación. Desarrollaron PLT (Page Load Test) que se ejecutaba con cada compilación, si los tiempos de carga aumentaban tenían que volver a empezar, solo se admitía una compilación que mejorara el PLT. Curiosamente cuando Steve Jobs introdujo Safari en Macworld 2003 lo primero que hizo fue explicar el «valor» de producto, velocidad. La presentación la realizó con los números del PLT. Asombrosa coherencia desde la idea inicial hasta la presentación final del producto.
Equipo pequeño, focalizado, responsable y con un objetivo común.
Empatía
Ver el mundo desde la perspectiva de los demás, creando productos que encajen con sus vidas y necesidades. Cuando una funcionalidad era aprobada, convivían con ella, eran los primeros en usar sus propios prototipos en el día a día. Vivir en el software el tiempo necesario para sentir como encajaba en la vida y se ajustaba a la visión original. En Apple diferenciaban las percepciones iniciales de una demo con su uso continuado. Una funcionalidad podía gustarte el primer día pero no encajar cuando llevabas varias semanas usándolo. Para diseñar buenas experiencias de usuario se centraban en prevenir experiencias negativas. El dilema de un producto es añadir nuevas funcionalidades hasta que su experiencia es negativa, la identidad de Apple es luchar contra ese problema de la industria. Es imposible probar y validar todas las posibilidades para ello confían en su conocimiento en diseño y tecnología para tomar decisiones.
Crear Software 