Vignelli on logo equity

«The notion of a logo equity has been with us from the very beginning of time. When we were asked to design a new logo for the FORD Motor Company, we proposed a light retouch of the old one which could be adjusted for contemporary applications. We did the same for CIGA HOTELS, CINZANO, LANCIA Cars and others. There was no reason to dispose of logos that had seventy years of exposure, and were rooted in people’s consciousness with a set of respectable connotations.

What is new is NOT a graphic form but a way of thinking, a way of showing respect for history in a context that usually has zero understanding for these values.»

— Massimo Vignelli, The Vignelli canon

Tengo en la memoria la reciente visita a Glasgow. Cómo el diseño que Mackintosh hizo para la GSA me pareció una actualización de la Glasgow University: mismos materiales, idénticas ideas básicas sobre la el aprovechamiento de la luz con sus ventanas enormes, pero formas estilizadas para la época. Lo mismo con algunos diseños para muebles. Como Vignelli, el pasado y la continuidad histórica como inspiración.

Diseño y testeabilidad

Todo programador que lleve un tiempo en esto, ha vivido debates sobre «arquitecturas» o «patrones de diseño». Dentro de la serie que he iniciado para hablar de desarrollo de software en una PYME, creo que estos debates tienen un encaje fundamental porque una vez seleccionas tecnología tienes que darle forma de alguna manera. Y esa manera es el «diseño» o «arquitectura» de tu producto.

El «buen diseño»

Lo primero que conviene recordar es que la reducción de los tiempos de producción y mayor calidad de producto es el camino de una PYME para ofrecer el máximo valor posible al cliente. En el mercado, eso te pone en una situación favorable con respecto a tu competencia. Definiremos, pues, como «buen diseño», aquel que se pone al servicio de la producción, que permite aumentar la calidad y reducir los tiempos de desarrollo.

Podemos continuar y definirlo como flexible y mantenible, bello y que hace sentirse orgulloso al que lo crea, etc. Pero el problema no es tanto definirlo, sobre lo que existe mucha literatura, sino cómo se llega a él y cómo se mantiene a lo largo del tiempo. Porque tenemos que reconocer que no es fácil y que existen varios problemas. Para empezar, no existe un diseño universal válido sino que hay tantos como contextos, que las personas, además, insisten en tener diferentes opiniones sobre qué es un «buen diseño» y que ambas cosas se reflejan en el código – lo que fácilmente puede convertir tu producto en una torre de babel ininteligible si no se construye una visión común. Tenemos, además, estructuras de comunicación disfuncionales que provocan diseños sub-óptimos, deuda técnica y requisitos cambiantes que introducen variantes a lo largo del tiempo, rotación de personas en los equipos y distintos niveles de experiencia que dificulta la transmisión de ideas, etc. Es decir, el software, su diseño, se ve afectado por las fuerzas humanas y organizacionales. ¿Cómo podemos ponerlo a salvo? ¿Cómo asegurarnos de que las fuerzas están en equilibrio y el diseño sirve a nuestros objetivos?

Necesitamos salvaguardas que nos permitan calibrar qué es un «buen diseño» y controlar su degradación a lo largo del tiempo, herramientas que nos ayuden a caminar hacia a él y nos orienten.

Los tests como salvaguardas

Michael Feathers, en su libro «Working effectively with legacy code» desarrolla la idea de cómo trabajar con software que está degradado. Cómo, partiendo de código degradado, se puede conseguir un «buen diseño» a partir de las restricciones habituales en el día a día (tiempos limitados, código con altas dependencias, etc). Es un libro por ello interesantísimo porque te cuenta ciertas maneras de cómo llegar a ese buen diseño. Y su principal herramienta son los tests:

«When you start to try pull out individual classes for unit testing, often you have to break a lot of dependencies. Interestingly enough, you often have a lot of work to do, regardless of how “good” the design is. Pulling classes out of existing projects for testing really changes your idea of what “good” is with regard to design. It also leads you to think of software in a completely different way.»

Empatizo por completo con su visión. Sobre los tests hay poco que decir: tener o no tener, that’s the question. Porque tenerlos afecta a la producción a varios niveles:

  • El primer efecto y más obvio es que, tenerlos, reduce los tiempos más inciertos y difíciles de estimar en proyectos de software: el testeo manual que hay que hacer en cada versión y el bugfixing. En gran medida, estos tiempos son los que suelen determinar que un proyecto sea o no rentable.
  • Otro efecto un poco más indirecto es que, para desarrollar software testeable, necesitamos dividirlo en trocitos, evitar y romper las dependencias. Es decir, estamos en la dirección de desarrollar software reutilizable, reducir la complejidad.
  • Quizás un poco más sutiles sean los efectos a nivel personal, pero no menos importantes. Por un lado, aportan seguridad y confianza en tu trabajo a posteriori ya que tienes algo objetivo y automático que te dice que funciona. Pero es que además, durante el proceso, tener feedback continuo te ayuda a enfocar tu trabajo y a mantener tu moral alta a base de pequeñas victorias cotidianas. Y la moral, en tareas creativas, es un factor clave en la productividad.

Conclusiones

Tests y diseño van de la mano. Una vez has sentido sus efectos, tu visión cambia. Aprendes que un buen diseño es un diseño testeable. Porque eso es lo que te va a permitir reducir tiempos de producción y aumentar la calidad de lo que ofreces, ganarte la vida desarrollando software de un modo sostenible, que, al final, es de lo que va todo esto.

Inversión y amortización en la selección tecnológica

Dependiendo del día y la hora, actúo como programador, dueño, o CTO en una PYME. A lo largo de estos años, me he encontrado en varias ocasiones ante la situación de tener que seleccionar tecnología para un proyecto, compaginando los diferentes roles y perspectivas.

Poco a poco, he ido desarrollando «una intuición», una personalidad propia sobre la dirección que nos interesa a la hora de valorar las opciones tecnológicas. La selección tecnológica en una PYME es un proceso que va más allá de lo técnico, tiene componentes sociales, y también económicos. Estos últimos son los que quiero explorar con esta nueva serie con unos cuantos amigos. Se habla demasiado de los beneficios intrínsecos y universales a cada tecnología particular y muy poco de todo lo demás, que posiblemente tenga más influencia en el tipo de relaciones que una PYME puede generar con su entorno.

Inversión y amortización, lo nuevo y lo viejo

Durante la ejecución de un proyecto, van emergiendo ideas que permitirían reducir tiempos o abrir nuevas oportunidades de negocio a medida que el aprendizaje se consolida. Algunas de ellas tienen sentido y unos costes que te permiten ponerlas en marcha de inmediato; otras, requieren más tiempo o maduración. Aunque suelo ser muy comunicativo con estos aspectos (la comunicación es el oxígeno de una compañía con responsabilidades distribuidas como la nuestra) no es hasta que toca pensar un proyecto nuevo en que bajo esas ideas a la práctica y me pregunto: ¿qué es lo más efectivo que podemos hacer en este proyecto para mejorar nuestros procesos y productos? ¿hacia dónde se están moviendo las necesidades de nuestro mercado? ¿necesitamos cambiar algo drásticamente? Este proceso de evaluación continua requiere mantenerse actualizado y es muy necesario para que el cambio no te pille desprevenido, para evitar ahogarse si el mercado en que navegas naufraga:

When heavily invested in a technology, you live in a memetic bubble, which also serves as an echo chamber. Bubbles created by vendors are particularly dangerous because you never hear honest appraisals from within the bubble. But the biggest danger of Bubble Living comes when it starts collapsing, which you never notice from the inside until it’s too late.

― Neal Ford, Build your own technology radar.

En ese proceso de re-evaluación, hay ocasiones en que toca apostar por algo nuevo y soy consciente de lo que eso supone: estamos ante una inversión. Decidimos invertir porque la posibilidad de beneficios pesa más que los costes y riesgos. La promesa puede ser que nos ayudará a acceder a nuevos mercados, fortalecerá nuestra posición frente a la competencia o reducirá nuestros tiempos y costes de producción, entre otras (aunque éstas son las más habituales que me encontrado por el momento). No puedo negar que, como humano y programador, mi pasión por aprender cosas nuevas y «hacer las cosas bien» influye también en mis decisiones.

Sin embargo, noto que, con los años, mi impulso por asignarle a lo nuevo características positivas por defecto, es menor: soy más juicioso. Quiero pensar que he aprendido a valorar el esfuerzo que supone aprender algo nuevo hasta el punto de, no sólo ser productivo, sino poder ofrecer una alta calidad en mi trabajo. Por muy necesaria que sea la prospectiva y mantenerse actualizado, nuestra industria peca con asiduidad de confundirla con dejarse llevar de forma baladí por la novedad, aporte o no. En economía existe un concepto llamado amortización, que viene a decirnos que el valor de algo se extiende en el tiempo y, por lo tanto, va contra el beneficio sustituirlo mientras su valor no está agotado (no está amortizado), a no ser que lo nuevo aporte un valor netamente superior.

Hablar en estos términos de la selección tecnológica (inversión VS amortización) nos ayuda a enfocar los problema y buscar soluciones.

¿Es posible encontrar el equilibro entre las fuerzas?

Las decisiones tecnológicas no se toman en el vacío, hay un contexto previo, procesos y personas implicados. Necesitamos aprender a reflexionar sobre tecnología no por las cualidades intrínsecas y universales de la misma, sino por las interacciones entre el conjunto de fuerzas en juego. Necesitamos una microeconomía del software, una herramienta que nos ayude a evaluar el equilibro y nos oriente en la toma de decisiones.

En mi experiencia, el equilibro es frágil y complicado de predecir, pues incluye preguntas de difícil respuesta como: ¿cuándo un framework que hemos usado se puede considerar amortizado? ¿cuánto va a retrasar la entrega/proyecto el uso de esta nueva librería? ¿cuándo voy a percibir los beneficios de su implantación? ¿es sensato introducir Node en un equipo de 4 personas donde 3 de ellas no tienen conocimiento web ni javascript previo y el 80% de los proyectos que vas a realizar en los siguientes 2 años son aplicaciones de escritorio?

Pero aunque sea difícil la tarea, una vez sabes que estas fuerzas existen, son fácilmente reconocibles y pensar en clave de oposición entre ellas aporta un inmenso valor en la toma de decisiones. A partir de ese momento, has pasado de ser programador a convertirte en CTO: piensas la PYME como una unidad de producción y estás teniendo en cuenta no sólo tu proyecto o intereses personales sino la evolución de la empresa. Incluyes en tus análisis que, a las finales, esto va de ser rentable para dar de comer a los que la componen.

En esta encrucijada por encontrar el equilibrio, a lo largo de los años, he ido detectando ciertas variables que modulan la intensidad relativa de la inversión y amortización:

Experiencia del equipo

La historia de por qué Disqus usaba Backbone y Django como opción por defecto refleja el tipo de cosas que tienes que preguntarte. La cuestión clave es saber si, además de ti, hay alguien (en tu equipo directo o a salto de subcontratación) que pueda echarte una mano ahora o pueda recoger tu testigo a medio plazo. Si trabajas en una PYME seguramente vas a necesitarla más pronto que tarde ya que esto es como una comunidad donde, si bien hay distribución del trabajo, hay también mucho de pluriespecialismo y colaborar un poco en todo – bien por tamaño del equipo, bien por apurones.

Capacidad de adaptación del equipo

Relacionado con lo anterior, es esperable que la experiencia y capacidades de tu equipo estén alineadas con lo que vendes y produces. Un cambio supone un impacto, un tiempo de aprendizaje de otras capacidades, moverse hacia otras direcciones. El tiempo que le lleva a alguien llegar al punto de ser productivo ante un cambio es muy variable de persona a persona y tiene mucho que ver con su experiencia previa y su pasión por aprender. Algunas empresas lo pueden solucionar cambiando de equipo a golpe de talonario; las que nos definimos como democráticas y aspiramos a crecer horizontalmente, de manera orgánica, debemos tener en cuenta que el impacto del cambio en nuestros tiempos de producción y calidad del producto final no va a ser despreciable.

Acceso e integración de talento

Hoy en día, en España,  si te sales de Java y sus frameworks (Spring, Struts, Wicket) es probable que te encuentres con que los recién licenciados no conocen de qué estás hablando. En las escuelas de informática se está abusando de la concentración en torno a Java, probablemente por la promesa de oportunidades laborales en las «fábricas de software» (que por otra parte se ahorran tiempo de formación porque los nuevos ya vienen de casa aprendidos). En cuanto a gente con experiencia en una tecnología reciente (pongamos por caso Scala, Node), el coste de acceso a ese talento y el riesgo de que se vaya al poco tiempo puede ser prohibitivo para una PYME. Sin duda hay espacio entre tecnologías ampliamente conocidas y otras todavía minoritarias, la cuestión es saber que la decisión tiene impacto en tu capacidad de contratar talento y valorar en qué parte del espacio te conviene estar.

Mercado: oligopolios y efectos red

En ciertos mercados, las opciones tecnológicas tienden a la concentración. En mi caso -sistemas de información geográfica y web- en el stack tecnológico pesan mucho lenguajes como javascript, python y java, con esos lenguajes puedes hacer casi cualquier cosa: desde un plugin para una aplicación de escritorio a una web con servicios de geolocalización. Si buscas sinergias con otras empresas, necesitas integración con otros proyectos, quieres usar librerías existentes o simplemente reaprovechar conocimiento en este sector, conocer Ruby es menos valioso y te abrirá menos puertas que los 3 anteriores. Un economista puede reconocer fácilmente esta situación como efectos red del ecosistema (número de empresas participando, librerías existentes, disponibilidad de foros de consulta, etc). Los efectos red tienen más impacto en el éxito de una tecnología que su belleza o calidad técnica superior. Es la razón por la que PHP y Javascript ganaron la web a principio de siglo, a costa de Perl que tenía el dominio en los 90.

Nivel de indirección y reaprendizaje de la tecnología

Uno de los mayores costes del desarrollo de software es el re-aprendizaje. Al cambiar de tecnología no sólo se pierde código, sino también conocimiento. Apostar por una solución más cercana a los estándares -o con menos conocimiento específico, llamémosle magia- facilita que pierdas menos cada vez que te cambies, aunque puede ser más costoso al inicio ofrecer lo mismo que con otras soluciones con más magia. Por ejemplo, una tecnología como Backbone te habilita a usar los estándares (al final casi sólo te ofrece una manera de organizar tu código Javascript), sin embargo Angular o React te proponen el aprendizaje de una serie de idioms propios a cambio de la promesa de la rapidez de desarrollo.

Volatilidad y adaptación al cambio de la tecnología

Ligado a lo anterior, se puede decir que una opción tecnológica puede estar más preparada que otra para adaptarse al cambio. Una base de código que, por ejemplo, esté basada en Backbone es potencialmente más flexible a la hora de integrar novedades tecnológicas que otra que siga los idioms de React. Esta última tendrá que esperar a que en React se integren los cambios de los estándares o aparerezcan plugins que lo hagan – dependiendo del tamaño del ecosistema alrededor de React esto puede ser más rápido o más lento. Una situación de volatibilidad hace que el período de amortización de una tecnología pueda ser anormalmente corto, lo que afecta a tu capacidad de generar beneficio si tienes que cambiarla al poco tiempo de empezar a usarla. Pueden existir zonas del código y el proyecto con alta estabilidad (no hay ni se esperan novedades tecnológicas) mientras que otras tienen una alta inestabilidad. Lo importante es detectar dónde te interesa no casarte con nadie porque todo está en ebullición y  dónde es seguro además de recomendable hacerlo porque el período de amortización es estable y la reducción de costes es real, no sólo una promesa.

Amortización esperada de la tecnología

Esto tiene que ver con el cálculo de los beneficios esperados. Influyen cosas como lo que estimes que vas a trabajar con esa tecnología en el futuro (no es lo mismo que, durante los siguientes años, estimes un reparto de trabajo de 90% en productos web y 10% en proyectos móviles que un ratio de 60% para aplicaciones de escritorio y 40% en web). Si lo que esperas es crecer mucho en un área determinada, tendrás más espacio para amortizar la inversión porque tendrás más oportunidades de reutilizar el conocimiento y código que has hecho. El alcance de las inversiones tecnológicas deben ir acordes también con tus expectativas de negocio y evoluciones estratégicas.

Margen de inversión

En una PYME no es muy habitual poder dedicar 3 meses a realizar prototipos un poco complejos con varias tecnologías. Habitualmente los tiempos son muchos más reducidos y necesitas sacar trabajo adelante. Es importante que sepas el tiempo que tienes para equivocarte y salir del apuro cumpliendo con las entregas de un proyecto, porque eso va a ser principalmente tu margen de inversión. Aquí importa no sólo el tiempo de duración del proyecto, sino también la incertidumbre que lo rodea: estabilidad de los requisitos, conocimiento previo del dominio, confianza con el cliente para negociar reducciones de alcance o retrasos, etc. También influirá tu compromiso a la hora de solucionar los marrones donde te has metido. Por ejemplo, parece claro que el margen de inversión que tiene un proyecto de 1 mes con alta incertidumbre en cuanto a requisitos, es mucho menor que otro de 12 meses donde conoces perfectamente el dominio y los riesgos que existen.

En mi experiencia, estas variables modulan la intensidad de la inversión o amortización y, dependiendo de la elección en que te encuentres, unas pesan más que otras. Por ejemplo, a la hora de seleccionar un lenguaje y ecosistema para un nuevo proyecto, el mercado de referencia (y sus efectos red) así como la composición de tu equipo son 2 de las variables que me parecen más importantes. Sin embargo, a la hora de seleccionar una librería concreta, el nivel de indirección y volatilidad del ecosistema suele tener más peso en mis decisiones.

A medida que uno avanza y toma experiencia se van haciendo más claras éstas y otras variables, aparecen nuevas, otras se reinterpretan. Lo importante es reconocer las fuerzas, no dejarse llevar por los análisis universalistas y pensar el impacto de las decisiones desde un contexto determinado: el tuyo.

La importancia de la selección tecnológica en una PYME

Este post fue el inicio de una serie que consolidó en un ensayo sobre el desarrollo de software en una PYME.

Un post reciente de Manuel me hace retomar una serie que tenía a medio escribir y que fui dejando de lado por la agitación del día a día: la importancia de la selección tecnológica en una PYME.

La idea central de la serie es que las decisiones tecnológicas no se dan en el vacío y tienen impacto en otras áreas de la empresa: la contratación y evolución del equipo, la capacidad de generar relaciones con otras empresas o la comercialización y el acceso a trabajos y proyectos. Habitualmente las discusiones tecnológicas gravitan en torno a aspectos intrínsecos al lenguaje (sintaxis, el tipado, etc), dejando de lado factores extrínsecos pero quizás más determinantes en el tipo de relaciones que la empresa puede establecer.

Una PYME debe conocer su espacio en el mercado y eso, parcialmente, pasa por hablar de tecnologías de otra manera: con un lenguaje y visión económica. Con un ojo en el negocio y otro en la técnica.

Por eso os propongo un reto: escribir un post semanal durante 3 semanas relacionado con la selección tecnológica en una PYME.

Posts de la serie:

IDEO y el diseño

IDEO es una consultoría que ha tenido un gran impacto en el diseño industrial de nuestra generación: desde el diseño del primer portátil hasta el primer ratón para el Lisa y el Macintosh. También es el lugar donde se generó el término diseño de interacción.

applemouse_hero_626px

Repasando una de las entrevistas a David Kelley, uno de los fundadores y reputado diseñador industrial, me ha llamado la atención ciertas ideas comunes que he visto en otras compañías como Pixar y sus pelis.

¿Qué perfil tiene un buen diseñador?

«Successful design depends on a design mindset: one that is open to possibilities and ready to take risks in a creative leap into possibilities that are not yet defined and whose consequences are not yet visible.»

Según Kelley, un buen diseñador sería un disidente, se siente cómodo en considerar ideas que a priori parecen locas o sinsentido: es pues alguien que debe tener confianza en sí mismo y amigos – un entorno que acepte su naturaleza y propicio al desarrollo de la idea. Es alguien también sin miedo a exponerlas ante otros por “el que pesarán”, ya que compartir es un método de obtener feedback y mejorarla. Finalmente, debe tener una cierta mirada abierta sobre el mundo, con una disposición continua a aprender, a no estancarse en lo que ya sabe:

People who are good inventors—good designers—don’t mind saying, “How about following this path, which doesn’t yet exist?” Most people have trouble doing that; they preface everything they say in a brainstorm with “This idea may be stupid, but here it is.”They are afraid that someone else will think that their leap is stupid.

Successful designers just send out their vision to the world; and then, when somebody else builds on it, that’s okay. They’re not protective of their ideas because they’re so used to having ideas. A creative designer has an idea a minute. Publicizing an idea is a way to improve on the idea—someone else can build on it, expand it.If you’re fluent with ideas, as most design people are, you don’t have to be fearful.You don’t protect your one good idea because your afraid you’ll never have another good one.

The other point about making the leap is being able to keep seeing a problem from new perspectives. Anybody who has a strong filter on the world forces everything to fit that filter. In our product-design courses, we assign exercises where you take an object and look at it backward, or you draw it from an ant’s point of view, or see it as material. For example, think about a computer monitor. It is just plastic with a piece of glass.Maybe I could do something completely different with it.

A central tenet of design is that you have to avoid stereotyping—the designer has to continue to say, “That’s interesting! Look at that!” That skill is hard to teach. All you can do is to give people the experience, and to let them extrapolate from it. A good designer has always had substantial experience.If you ask designers “What’s design?” they can’t tell you. But a designer who has had experience knows what design is.

De la organización del trabajo

En IDEO, el trabajo se hace por equipos. Ciertamente hay gente con mayor capacidad que otros para dar el salto creativo, pero ese proceso se da en una comunidad: entre iguales que no tienen miedo a decir lo que piensan ni a que se “apropien de su trabajo”. Principalmente en los inicios del proyecto, existen sesiones de brainstorming donde puede participar quien lo desee. La decisión y responsabilidad es del que inicia el proceso.

Successful design is done by teams. Creative leaps might be taken by individuals, but design thrives on the different points of view found in teams.You want a multidisciplinary team, what we call x-func (cross-functional). You want different brains working on the problem. Otherwise, the person with the power, or the person who speaks the loudest, sets the direction for the whole design.You have to keep a broad perspective at the beginning; you have to be uncomfortable with the fact that you’re not moving forward in a straight line toward the goal (and, project managers do want to move forward!); you have to feel comfortable with exploring.

In a company such as IDEO, where you have many creative people, when someone has a great idea, nobody ends up knowing whose idea it was. It’s not branded as George’s idea. Either nobody knows whose idea it was, because of all the discussion that took place, or everyone thinks it was his or her own idea.Either perception is equally good, and both happen frequently.

In our company, the person who owns the solution is the person who posed the question. If I’m the one who says, “Let’s create a new toaster,” I own everything that happens, because I initiated the discussion. In most cases, the clients are the owners, because they pose the question. You can hold a brainstorm on any subject you want, any time. Just send out a message that says, “I’m holding a brainstorm at 2:00. Will you come?” And everybody comes. You’d think everybody would say, “Oh, I’m too busy.” Not true: People know that they are going to need you to come to their brainstorm tomorrow. So the culture requires you to participate in other people’s problems.

You eventually get to the point where you look forward to the brainstorm for two reasons. One is that sessions are genuinely interesting. It’s like reading a book or reading the encyclopedia—you learn about a new subject. The other reason is that it’s not your problem. The guy who’s got the toaster problem has the client; he has to get the design done on time; he has to make that leap that makes us so uncomfortable. The other designers come in totally relaxed, totally free to generate ideas in the toaster area, because it’s just fun. They’re helping, and the only pressure on them is that they want to help their peer.

A diferencia de Pixar, que es una compañía de producto, IDEO es una compañía de servicios. Como consultoría sufre pues la tensión entre aceptar ciegamente lo que el cliente pide o tomar parte en la definición del problema para llegar a una mejor solución. La resolución de este conflicto es curiosamente similar a la de Pixar: inicialmente, el rango de opciones es amplio y se exploran alternativas (sesiones de brainstorming, prototipado, etc). A medida que el proyecto avanza, entra en otras fases de producción donde la capacidad de tomar otros caminos es menor debido a los costes.

Say that a company comes in and says “We want you to design a new toaster.” And I say “We’re going to study bread crisping in its generic sense.” They say, “Look, I told you just to design a toaster. Get going.” They think that the world of what a toaster could be is small. But we might say, “Look, our job is to begin by looking at the history of bread. “Maybe we want to see whether they had a better way to make toast in Renaissance France or on the Space Shuttle. We don’t want just to design the curlicues on the side of the client’s next toaster. Maybe what we’re going to find from looking at this history is that the best solution is to put more curlicues on the side, but I always say: “Think about how much more comfortable you’re going to feel that we are doing the right thing if we do a broad search and then narrow down.”

Breadth takes extra effort at the beginning, but that’s the best time—right at the outset of the product development process—to take a step back to see the situation. The design part of the product process takes a small portion of time. The next steps after design have 10 times the cost, time, effort, and emotional stress. Then, manufacturing incurs 10 times that. So time invested at the beginning isn’t wasted; we make up the cost in later stages easily, by doing the design right.

Published
Categorized as All, Radar

The design trilogy

Estos días he sacado un rato para ver los documentales que Gary Hustwitt publicó en su The design trilogy.

helvetica
objectified

urbanized

El primero, Helvetica, es una ventana a la evolución, modas y debates del diseño gráfico en los últimos 50 años a través de una de las tipografías más usadas de todos los tiempos. Objectified explora los objetos que nos rodean y el trabajo de los diseñadores industriales. Por último, Urbanized glosa los temas fundamentales que articula nuestra unidad básica de convivencia: la ciudad – transporte, vivienda, ciudades post-industriales, planificación y participación urbana, etc.

Todos ellos siguen el formato entrevista, con un buen balance entre «las estrellas del campo» y desconocidos con cosas interesantes que decir. Ligeros, entretenidos y nada fáciles de hacer. Me parece que funcionan muy bien como divulgación en varios temas centrales a los que somos como sociedad: recomendables.