Eu ouvi e vi o vídeo de "Happy" do Pharrell mais do que deveria, comi sorvetes gourmet (achei meio mais ou menos...) e ouvi a palavra "fuck" mais vezes do que em todas as outras conferências que fui antes somadas. Como todo bom design, a principal preocupação da conferência foi com a experiência do usuário - ou, no caso, dos participantes. Porém caiu na armadilha que muito design cai: esqueceu o objetivo expresso de uma conferência - a transferência de conhecimento. Um dos participantes resumiu ao comentar "eu não aprendi nada de novo hoje".
Sem dúvida houveram momentos marcantes. George Lois - o publicitário responsável por denunciar o julgamento do boxeador "Huricane" Carter para o grande público nos anos 60 - falando de design perigoso. John Maeda estava lá despertando os designers para as oportunidades geradas pelo novo dinheiro no Vale do Silício "vocês precisam faz muito dinheiro, pois as coisas realmente interessantes não darão dinheiro".
Por outro lado, as ideias apresentadas tiveram pouco tempo para ser aprofundadas. O consenso entre os organizadores parece ser a ideia de que design é uma arte, não uma ciência. Por outro lado, houve um bate papo sobre algoritmos como designers. É uma questão reconhecida por eles mesmos como fundamental, mas pouco debatida. Ideias como testes A/B, teste de guerrilha e análise de padrões foram pouco exploradas, ou nem ao menos mencionadas.
Double Tony Fadell
Foi impressionante ver 13 apresentações em apenas 5 horas, mas a impressão que eu tive é que elas foram parte de um diálogo que já rolava na comunidade local, através de outros eventos e grupos de interesse. Começou com o CEO da Nest, Tony Fadell falando de design para a casa conectada. Tony não acredita no surgimento de padrões para internet das coisas, argumentando que as pessoas compram produtos, e os que forem bem sucedidos serão aperfeiçoados para comunicar entre si quando fizer sentido. Ele falou um pouco do estilo de liderança dele. Eu não gostaria de trabalhar com o Tony.
As próximas duas sessões foram curtinhas. Na primeira, sobre visualização de dados da Amazon, a coisa mais interessante que ouvi do Marc Maleh foi que para projetos de visualização, os dados são a pauta. A seguinte, "O Que Bruce Lee Pode Ensinar Sobre Design" foi a mais inspiradora do dia. O ensinamento de Bruce Lee para mim foi de ter um "estilo sem nenhum estilo": deixar o projeto ditar o que deve ser feito. Acho que tem bastante a ver com a abordagem ágil da ThoughtWorks.
Na sequencia, "inovação disruptiva" na Coca-cola e na Target foi um debate entre executivos de design das duas empresas. A facilitadora não conseguiu inspirar respostas interessantes. O ponto alto: descobri que a Coca só não está presente em dois países do mundo: Cuba e Coreia do Norte. O único artigo da Fast Company sobre este assunto parecia propaganda paga da Coca. Me nego a linkar.
Depois do Intervalo teve um debate com o âncora da CBS Charlie Rose. O painel todo era bom, discussões interessantes que eu fiquei sem contexto por realmente não assistir TV. Ouvi o suficiente sobre "infotainment" e "news business" para confirmar que informar a população é uma preocupação secundária para esse jornalismo. O John Maeda foi o primeiro grande nome do design que eu reconheci no evento. Ele teve pouco tempo para dar o recado dele, mas eu gostei muito da abordagem pragmática: "Custa mais caro incorporar design no processo" e "não precisa ficar rico no Vale do Silício, mas tem que entender que é o objetivo fim por lá". Logo depois teve algo sobre o figurino no Game of Thrones que realmente não me marcou.
A próxima sessão tinha a proposta mais instigante, debatendo se algorítimos podem ser designers. As painelistas propuseram que algorítimos podem ser úteis para fazer experimentos rápidos, mas que são uma ferramenta, ainda precisam de um ser humano definindo os parâmetros. Apesar de argumentarem que alguém tem que criar o algorítimo, também lamentaram que ao automatizar parte do design, uma parte do processo criativo é perdido. Me pareceu haver um pouco de preconceito em relação ao trabalho criativo dos desenvolvedores. Isso também toca na questão de design como arte (neste caso talento teria precedência sobre execução) ou como ciência (que significa que precisaria saber fazer boa ciência para fazer bom design). Minha opinião: A não ser por fatores sociais (peer pressure, conformidade, etc.), acreditar que bom design exige um "talento" especial, parece algo um pouco pretensioso. Designers gostam do trabalho de outros designers por que eles pertencem ao mesmo grupo social, tem as mesmas referências e incentivos para gostarem das mesmas coisas. Bom design voltado pelo usuário só pode ser validado por evidências.
A seguir 3 sessões com muito pouco conteúdo interessante (bastidores de "Happy" do Pharell, Design na Starwood Hotels e sorvetes) antes da última sessão com pesos-pesados da indústria debatendo os designs mais perigosos do mundo. A estrela era o lendário George Lois, mas isso era bom e ruim, os outros painelistas deferiam muito a ele, e o debate foi lento. Yves Behar deu uma boa dica na hora de propor um design "perigoso": invista tempo atraindo o cliente com uma ideia antes de mostrar o design resultante. Isso vai fazê-lo mais propenso a comprar a ideia e correr o risco. E esse foi o fim da parte "onsite" do evento - ao menos para mim...
A seguir, a conferência oferecia "off-site experiences" - visitas guiadas a organizações interessantes no mundo do design. Eu escolhi o tópico de Escuta Criativa, ministrado na IDEO. Foi muito interessante ouvir técnicas para derivar insights a partir de entrevistas. Para começar, foi uma sessão mais longa, que permitiu aprofundamento na questão. Ainda assim, faltou tempo! As 4 técnicas descritas foram:
Creative Listening Kit
Talvez os maiores insights vieram não do que estava planejado, mas da participação da audiência. Ao ouvir gravações de entrevistas com usuários, ficou claro que ouvir revela mais que ler ou ver um vídeo das entrevistas ("a voz não mente"). As técnicas apresentadas também levantaram a necessidade de empatia com o ouvinte quando utilizamos jargão de um domínio específico. Muitas vezes tomamos alguém por incapaz de entender, quando na verdade estamos usando jargão que inviabiliza o entendimento.
Foi um dia intenso, mas ironicamente um dia leve. Não fui forçado a pensar demais, não tive que tomar decisões difíceis ou providenciar nada. Mas também não aprendi tando quanto gostaria. É pouco para um conferência, mas bom para o primeiro dia de férias...
Feature Injection sounds harder than it really is. To try and address that, I started calling it Value Injection. Here's what Value injection seems to come down to:
This is the idea that we should dig for the value of the features being discussed and try to look at the desired output in order to identify what needs to be done. It is not a new concept on itself, but it is something that I don't see done on a regular basis. To achieve that we can ask our clients "Why this is important to you" until we identify how this helps the client increase profit, reduce cost, protect revenue or fulfil the company's mission. It is not only a matter of continue to ask until we know exactly why the client wants a given feature (although it helps), but it means that when we identify the value, then we start to build from the output. For example:
A client comes to us asking us to add mandatory gender and race fields in the employee records of their HR system. After questioning the reasons for this requirements we learn that this is necessary to so the company can report on average salaries for historically discriminated groups. Therefore we start by providing a way to output average salary for employees, identifying that race and gender should be attributes of employee and providing this additional calculation. In the process, we may realise, for instance, that gender information is already available in other systems in the organisation, and that the legal requirement for race requires only a self-reported attribute of "belong to racial minority", making the initial requirement for fields much simpler, and providing the actual solution to the problem instead.
It looks like this is actually easier to apply if the customer starts by articulating the perceived required solution than if they start with the most "desirable" stance of articulation business value, because if you start by the stated business value, the success will depend on how well that was initially framed by the client.
Whenever you are starting a new project, there are plenty of knowns, plenty of unknowns and without making them explicit, we are exposing ourselves to risk. Once we understand what is the problem that needs to be solved, we can use examples to stretch our understanding of the domain.
For instance, in the example above, we may have a simple domain of employees. It looks awfully simple for a real-world problem, so we may inquiry who is responsible for achieving the diversity targets. The client promptly answers "the department managers, obviously", that would indicate we need to have a parent department for an employee and it should have at least one manager. We may continue to enquiry whether a department with no manager exists ("it doesn't", they tell us), if an employee is only assigned to one department at a time ("yes. An employee could be lent to another department, but it still counts on the original department average". We make a note and move on) and what about contractors ("Well.. contractors make it a bit more complicated...". Which prompt us to probe a little bit more on that).
The idea here is be even more minimalistic than the regular "very little upfront analysis" and actually get our hands dirty on a working skeleton even before we do any analysis at all. Maybe use Excel or ask a developer to put something really simple and very wrong together, so the client can look at it and criticise it. People usually have trouble with "blank canvases", but usually have no difficulty showing what exactly you did wrong. Leverage that in order to promote learning.
When building this skeleton, focus on enabling the capability rather than making it look right. User experience will change with feedback, so delaying commitment to how it looks will keep the cost of changing the interface low until we settle on one.
A bit of history: The title of this post was suggested by Simon Bond after James Martin, Antony Marcano and Andy Palmer's concerns that "Feature Injection" does not really represent what the practices mean. Hopefully it will help re-set the thinking about this subject a little bit, as I think the term represent something more obscure and complex in people's minds then it really should be. Note that most of the ideas discussed here are my understanding of the matter and not based in anything James, Anthony, Andy or Simon may think of it.