Lideranças criativas com background de UX em agências

Carreira de um criativo em agências

Quando comecei a trabalhar com publicidade, a figura do Diretor de Criação da agência era uma.

Normalmente ele tinha trabalhado como Diretor de Arte por muitos anos, depois começou a coordenar um pequeno grupo de criativos, até ir aos poucos assumindo contas e responsabilidades maiores e chegar à posição de Diretor de Criação.

O interessante é que, ao mesmo tempo em que esse profissional percorreu a trajetória vertical (de criativo-chão-de-fábrica até chegar à diretoria criativa), ele também percorreu um caminho horizontal de incorporar o digital ao seu trabalho, à medida em que os meios digitais ganhavam força no país. Afinal, esse cara tinha trabalhado com o tal do “offline” por muitos e muitos anos. E foi ali que ele aprendeu muito do seu método criativo que usa até hoje.

Continuar lendo

Desenhando a experiência do Desenvolvedor

Developer Experience

Jeremiah Lee criou este logo para seu workshop no SXSW. Desenvolvedor, UX e designer, né?

Muito do sucesso do iPhone, Twitter e Facebook está no fato de serem mais do que produtos: são plataformas que permitem outras pessoas criarem negócios baseados em seus serviços (pense na indústria de apps e games entorno do iPhone). Outras empresas começaram a perceber as vantagens nesta abordagem, como a Nike está fazendo com o Fuelband. Assim, não é de se espantar que o seu cliente/empresa decida também seguir este caminho de abrir as portas do produto (seu código) para que outros criem novos produtos a partir dele (se já não o fez).

Contudo, ao abrir suas funcionalidades para que outros utilizem, você está criando também um novo público para o seu produto: os desenvolvedores, afinal eles serão os responsáveis em utilizar o seu código para criar algo novo em cima.  E a necessidade deste público é totalmente diferente da necessidade do usuário final: eles vão querer conhecer as regras do negócio, entender as funcionalidades disponíveis e precisarão de um meio de comunicação dedicado à ele. A decisão por usar um serviço ou o outro pode depender disso.

Da criação desta interface com o desenvolvedor vem a necessidade de pensarmos na experiência do desenvolvedor, termo que conheci assistindo uma palestra do Jeremiah Lee, um desenvolvedor que descobriu a imporância do UX também nesse contexto. A partir desta palestra (e também deste artigo),  fiz essa pequena lista com o papel do UX para a criação desta interface com desenvolvedores:

#1 APIs

A maneira mais comum de disponibilizar seus serviços para desenvolvedores terceiros é por meio de uma API (sigla em inglês para Interface de Programação de Aplicativos). Assim como você se preocupa com a navegação, fluxo e coerência da interface visual do usuário final, as APIs precisam ser pensadas com o mesmo carinho. Isso vai desde escolher a terminologia e o padrão mais adequado (“Nome completo” ou “nome” e “sobrenome”?) até pensar todos os cenários de erros que podem acontecer e a mensagem para cada um. Interessado no assunto? Recomendo a leitura do livro Web API Design (gratuito e em inglês) e também do blog API UX (em inglês).

Continuar lendo

Inscrições abertas para o Interaction South America 2013, em Recife

Nós não costumamos divulgar eventos e cursos aqui no blog, porque tem muita picaretagem é difícil saber se os conteúdos serão proveitosos para os nossos leitores.

Mas esse é evento sério, de gente grande.

Interaction South America 2013

Nos dias 13, 14, 15 e 16 de novembro desse ano, o Recife receberá uma trupe de designers de interação interessados em aprender com profissionais renomados, trocar experiências e conhecer a cidade. São 50 apresentações de artigos acadêmicos, 30 apresentações de cases de mercado, palestras rápidas, palestras longas, mesas redondas e 12 workshops, incluindo 2 ministrados pelo Instituto Nokia de Tecnologia (INdT). A organização é da turma do IxDA Recife.

As inscrições já estão abertas no site >

Uma ferramenta para mapear Consumer Journeys e Personas do seu produto

Smaply

É o que promete o Smaply, como você pode ver no vídeo abaixo:

Incrível, né?

Hmm… não muito.

Apesar de estar ainda em Alpha, testei algumas instâncias da ferramenta aqui na agência e ela realmente ajuda a criar um framework para esse tipo de documentação. Na prática, parece um pouco com um Basecamp, mas focado em documentar o produto do trabalho do time de User Experience e permitir que outras pessoas tenham acesso aos resultados.

Mas cuidado: o Smaply proporciona apenas o template para esses documentos.

E como qualquer template, a ferramenta não é à prova de maus UX Designers. Se você utiliza o Smaply (ou qualquer um desses templates que são facilmente buscáveis no Google) e preenche tudo ali com o que você acha que acontece na experiência do consumidor ao usar o seu produto, você continua fazendo a mesma besteira de sempre.

Pode, sim, economizar algum tempo de documentação, que você gastaria movendo as caixinhas cinzas em um InDesign da vida. Mas achar que isso vai resolver a relevância do seu produto, é inocência demais.

Pesquisa, curiosidade e estratégia. Isso sim pode ajudar.

5 armadilhas de UX e como evitá-las

Armadilha

Há alguns dias li um post muito certeiro do UX Mastery sobre algumas das armadilhas mais comuns para os profissionais de UX. Tais armadilhas acontecem, segundo o artigo, porque muitas empresas e organizações ainda estão lutando para tentar entender a melhor forma de consolidar uma metodologia de trabalho que seja realmente centrada no usuário. Vamos aos cinco pontos:

  1. Aceitar regras de negócio que estão mal definidas antes de começar um trabalho. Muitas vezes nós entramos em um projeto com a missão de transformar as regras de negócio do cliente em um website amigável para o consumidor final. Nesse processo, constantemente nos deparamos com regras e requisitos que são apenas uma confusa lista de afirmações sem base científica ou uma lista de oportunidades não muito bem exploradas. Se os requisitos não estão 100% corretos, você corre o risco de acabar ignorando esse documento e trabalhar na solução que não é a mais apropriada. Um jeito coerente de tentar resolver esse problema é passar por um round de perguntas com o seu cliente e investigar mais sobre os pontos de contato atuais da empresa, e sobre os produtos e serviços que ela disponibiliza. À medida em que sua relação com o cliente amadurece, você pode passar a se envolver mais nas decisões estratégicas de negócios da empresa.
  2. Ficar preso demais à documentacão. É comum, pela própria natureza da nossa profissão, que acabemos nos prendendo demais à documentação daquilo que está sendo criado. Muitas vezes é melhor abrir mão de parte da documentação e começar logo a construir protótipos funcionais do produto. Nesse sentido, rabiscoframes e protótipos de papel podem ajudar bastante a agilizar o processo.
  3. Abrir mão de testes de usabilidade quando não há tempo ou dinheiro. Testes são uma das primeiras coisas que são cortadas do escopo do projeto quando ele precisa ser reduzido (seja por questões de verba ou de tempo). Mas o fato é que pesquisa com usuários não é apenas um complemento. A famosa frase que diz que “qualquer pesquisa é melhor do que nenhuma pesquisa” continua válida. Muitas vezes é preciso cavar tempo dentro do cronograma do projeto e fazer “testes de usabilidade de guerrilha” com amigos e familiares que estejam dentro do perfil pesquisado. Se você tiver real empenho nesse processo, as pessoas ficarão felizes em ajudá-lo com isso.
  4. Cair em discussões subjetivas. Frequentemente nos pegamos em discussões onde as pessoas levam em conta apenas sua própria intuição e experiências anteriores de outros projetos. Uma das soluções para isso é aplicar exercícios rápidos com as pessoas que tomam decisões dentro do projeto (tanto em sua agência/produtora quanto na empresa-cliente). Fazer uma lista de objetivos de negócios e passar para os stakeholders numerarem esses objetivos por ordem de importância é um bom exemplo disso – tudo para tornar as discussões mais racionais e menos subjetivas.
  5. Ser seduzido por modismos de design. Acompanhar as tendências de design (responsive design, carrosséis, botões de compartilhamento e layouts de uma página só) é o caminho mais rápido para mostrarmos ao mercado que estamos na crista da onda. Mas se seguirmos um processo robusto de design, acabamos percebendo que elementos assim têm um motivo para existir e resolvem problemas que nenhuma outra solução consegue resolver. Existe um efeito psicológico que nos dá a falsa sensação que um website bonito é naturalmente mais usável. Por isso devemos tomar cuidado com esses modismos e pensar duas vezes se eles realmente ajudam a resolver um problema de design recebido no brief.

Mais alguma armadilha nessa lista?

Pesquisa etnográfica para times enxutos (apresentação)

Ou “Design Ethnography for Lean Teams”.

Por que pesquisa?

“A verdade mais certeira desse gráfico é que zero usuários traz zero insights.”

Uma apresentação bem estruturada e direta ao ponto: fazer pesquisa com um usuário é melhor do que não fazer com nenhum. Em uma época onde se fala muito sobre Lean UX (em conferências, inclusive), a apresentação procura mostrar como esse tipo de estudo pode acabar sendo muito mais divertido do que aqueles que acontecem formalmente em um laboratório.

Design Ethnography

(Se você estiver lendo esse post via email ou rss e a apresentação acima não abrir, veja-a no blog)

Leia também:

Lean UX: método de trabalho ágil para User Experience Design

O que é Lean Usability?

Escolhendo as métricas certas de UX

Um re-post daqui.

  • Happiness: measures of user attitudes, often collected via survey. For example: satisfaction, perceived ease of use, and net-promoter score.
  • Engagement: level of user involvement, typically measured via behavioral proxies such as frequency, intensity, or depth of interaction over some time period. Examples might include the number of visits per user per week or the number of photos uploaded per user per day.
  • Adoption: new users of a product or feature. For example: the number of accounts created in the last seven days or the percentage of Gmail users who use labels.
  • Retention: the rate at which existing users are returning. For example: how many of the active users from a given time period are still present in some later time period? You may be more interested in failure to retain, commonly known as “churn.”
  • Task success: this includes traditional behavioral metrics of user experience, such as efficiency (e.g. time to complete a task), effectiveness (e.g. percent of tasks completed), and error rate. This category is most applicable to areas of your product that are very task-focused, such as search or an upload flow.