Próxima parada: UX Lx

14 de maio de 2012

Logo mais embarco para Lisboa, Portugal, para participar da UX Lx, uma das mais importantes conferências de User Experience da Europa. Tive o privilégio e a honra de ter a minha proposta de apresentação aceita pela equipe organizadora. Será uma apresentação rápida onde vou falar sobre o projeto que realizei em 2011 para o National Bank of Canada pela Yu Centrik. Um projeto cheio de desafios onde tivemos que criar em 6 meses, e a partir do zero, um site para telefones inteligentes e uma aplicação iPhone para dar aos clientes do banco acesso à todas as funções que eles dispõe via web.

A UX Lx começa na quarta-feira, dia 16 de maio, e durante três dias vai apresentar workshops e conferências de profissionais bem conhecidos na nossa área como Bill Buxton, Joshua Porter, Jesse James Garrett e Peter Morville.

Na volta vou postar aqui um resumo dos melhores momentos.

  • Facebook
  • Twitter
  • LinkedIn
  • Email
Categoria: Conferências | Comente

Quem é o responsável pelo design?

16 de abril de 2012

História da vida real: o gerente de TI do cliente para o qual estou trabalhando agora, disse que eu tinha que parar de envolver todo mundo nas atividades de design. Que eu não preciso chamar o pessoal da área de negócios, marketing e o presidente da empresa para as sessões de brainstorm. Que tudo isso era perda de tempo e que eles só querem ver o produto pronto, não precisam participar do processo de criação.

Ele não é o único a pensar assim. Da mesma maneira que algumas pessoas questionam o fato de envolvermos os usuários no nosso processo, outras questionam o envolvimento dos "stakeholders".

Já ouvi, mais de uma dezena de vezes, que nós somos os designers, então devemos, com a nossa experiência, saber o que é bom, o que é ruim e apresentar a melhor solução. E cada vez que ouço isso, a resposta já está na ponta da língua. E ela é simples:

Sim, nós somos os designers e nós somos responsáveis pela solução final. Quando envolvemos os usuários, não é para perguntar como eles gostariam que as coisas fossem feitas, mas sim para observar o seu comportamento perante ao design proposto e como realizam tarefas que esse design propõe facilitar.

Da mesma maneira, quando envolvemos os "stakeholders", não é para que eles nos digam o que fazer e sim para entender que ideia eles fazem do produto, como eles imaginam a solução final. Dessa maneira, quando nossa solução estiver pronta, podemos saber o quão perto ou o quão longe estamos da visão do cliente. Caso estejamos longe, isso nos permite, simplesmente, antecipar a preparação de argumentos que justifiquem a nossas decisões, já sabendo que, de uma certa maneira, eles ("stakeholders") ficarão decepcionados vendo um produto final que não reflete exatamente o que tinham na cabeça inicialmente. O quanto mais preparados estivermos, melhor.

E não só isso, outras pessoas, mesmo não sendo "designers", podem ter boas ideias. Mesmo que seja uma ideia em mil, pode valer a pena.

Como já disse em posts anteriores, design não se faz sozinho e fechado em uma sala. Ouvir os outros, observar reações, compartilhar ideias, é extremamente importante. E convencer os outros de que esta é a melhor maneira de trabalhar, faz parte do nosso dia-a-dia.

 

Você acha que é o gerente de TI tem razão? Deixe um comentário.

  • Facebook
  • Twitter
  • LinkedIn
  • Email
Categoria: Metodologia, Vida de UXer | Comente

O paradoxo da escolha

22 de março de 2012

Uma das coisas que mais impressionam aqueles que têm a oportunidade de visitar os Estados Unidos ou o Canadá é a quantidade de opções que se encontram nas farmácias, supermercados, enfim, no comércio em geral. Quer comprar um leite? Boa sorte, pois não é tarefa fácil. Existem mil e um tipos de leite. É tanta variedade que é normal ficar paralisado sem saber o que escolher.

Pois o livro "The Paradox of Choice" trata exatamente dos efeitos negativos da quantidade de opções existentes no mundo moderno. O paradoxo fica por conta da liberdade de escolha, que nunca na história foi tão grande quanto agora - e que permite, teoricamente, que a gente faça da nossa vida o que a gente quer -, e o stress causado pela obrigação de tomar decisões diárias, tendo sempre uma infinidade de opções muitas vezes confusas e pouco claras.

Para nós, povo de UX, após terminar a leitura do livro, fica a sensação de que daqui para frente vamos sempre pensar duas ou três vezes antes de oferecer uma opção a mais ao nosso usuário e deveremos ter argumentos para dissuadir outras pessoas de fazê-lo.

  • Facebook
  • Twitter
  • LinkedIn
  • Email
Categoria: Livros | Comente

Resumo da Agile UX NYC

6 de março de 2012

No dia 25 de fevereiro aconteceu na School of Visual Arts em Nova Iorque a primeira conferência Agile UX NYC. Um evento simples, se comparado à outras conferências da nossa área. Apenas um dia de palestras, foco em um único assunto principal, sem apresentações em paralelo, sem workshops, sem firulas (brindes, sorteios, etc.) e com um preço bastante razoável. Resultado: uma das melhores conferências sobre UX das quais já participei.

O ponto principal era apresentar possíveis abordagens para o desafio de tornar mais ágil o design da experiência do usuário.

A metodologia "Agile", vinda do mundo do desenvolvimento de software, não significa apenas fazer tudo mais rápido e sim fazer tudo de maneira mais eficiente e adaptada à realidade da tecnologia atual e do mercado competitivo em que vivemos.

Após ouvir as palestras, rever os slideshows e reler as minhas anotações, as conclusões podem ser resumidas em dois pontos principais: como melhor integrar a equipe de UX ao resto da empresa e como melhorar nossas atividades para que sejamos mais eficientes.

Segue um resumo das recomendações mais interessantes:

INTEGRAÇÃO DA EQUIPE AO RESTO DA EMPRESA

- Não basta apenas designers e desenvolvedores trabalharem em modo "ágil". Outros departamentos da empresa precisam também seguir a mesma filosofia e todos precisam se falar para estar alinhados quanto ao produto final esperado (exatamente o ponto que eu havia levantado em um post anterior).

- É preciso entender a linguagem utilizada por outros departamentos para que a comunicação seja mais fácil, e é preciso envolver esses departamentos nas nossas atividades para que eles entendam o que fazemos. Isso permite evitar conflitos e desentendimentos sobre o produto a ser criado e o objetivo a ser atingido.

- Não é realista imaginar que a empresa inteira passará a funcionar em modo ágil de um dia para o outro. É preciso uma pequena vitória de cada vez e, à medida em que os resultados vão sendo positivos e que novas vitórias vão sendo conquistadas, a mudança virá naturalmente.

- A função do designer mudou nos últimos anos. O designer agora é um facilitador, responsável pelo trabalho em equipe, pelo trabalho colaborativo, e faz parte do grupo responsável pelo produto.

- É preciso desmistificar o design. Precisamos acabar com as barreiras de linguagem e de postura entre designers e outras equipes. É preciso ser transparente e aberto à ideias, deixar outros profissionais fazer parte do nosso processo e incentivar o trabalho em grupo (brainstorms, entrevistas, testes, rascunhos de interface, etc). É preciso mostrar como funcionamos.

TORNANDO NOSSAS ATIVIDADES MAIS EFICIENTES

- Testes de usabilidade não devem ser um bicho de sete cabeças. Evite longos relatórios que ninguém vai ler, o que importa são os resultados práticos. Uma planilha no Google Docs com as anotações e as possíveis soluções é suficiente. Testes podem (e devem) ser semanais e os participantes recrutados com bastante antecedência, mesmo que você não saiba ainda o que será testado. Sacrifique "precisão de resultados" por "frequência de realização". Os testes de usabilidade devem ser rápidos e frequentes, e o foco deve ser em resultados que possam ser úteis para o que está sendo desenvolvido agora e não para o que será desenvolvido no futuro.

- Testes de usabilidade não pertencem somente à equipe UX mas, sim, a todas as equipes. Não existe essa separação, todos são parte de um mesmo time. Traga executivos e desenvolvedores para ver como os usuários realmente usam os seus produtos e o que eles realmente precisam no contexto real do seu dia-a-dia. Se eles não podem vir aos testes, coloque-os para falar com usuários pelo telefone e discutir sobre o produto (o Google chama isso de "visita virtual").

- Substitua "exigências de funcionalidade" (requirements) por hipóteses. Hipóteses, por natureza, precisam ser testadas para serem validadas.

- Toda decisão de design é uma hipótese e, por consequência, precisa ser validada. Escolha as decisões mais arriscadas, construa o mínimo de produto necessário para que elas possam ser testadas e teste rapidamente, antes que seja tarde demais para voltar atrás.

- As atividades ligadas ao design da experiência devem agora ser feitas de forma mais leve, mais rápida e contínua. Exemplo: podemos começar com "personas" provisórias, com poucos dados, sem muitas informações e, à medida em que os resultados forem chegando, vamos refinando até termos algo mais concreto. O modelo provisório, mesmo incompleto, permite às outras equipes verem como trabalhamos e começarem a ter uma melhor ideia do público-alvo para quem o produto está sendo desenvolvido.

- Conversas com usuários devem ser frequentes, contínuas, e não devem ser encaradas como um momento especial no desenvolvimento de um produto. Essas conversas (ou entrevistas, como costumamos chamar) podem ser feitas em pares ou em grupos. Profissionais de outras áreas podem participar tomando notas e no final da entrevista podem aproveitar para fazer suas próprias perguntas.

- Para funcionar em modo ágil, as atividades devem acontecer em grupos, com períodos de tempo limitados, onde pessoas da equipe de UX devem trabalhar com pessoas de outros departamentos, para que todos sejam envolvidos no processo o mais cedo possível e para que rapidamente possamos determinar a direção a seguir. Todos são capazes de gerar ideias, rascunhar interfaces e criticar positivamente soluções apresentadas.

- É preciso melhorar nosso funcionamento interno, se quisermos ser mais ágeis. Perder menos tempo procurando arquivos com nomes difíceis de decifrar, criando múltiplas versões de trabalho ou enviando arquivos errados. É preciso ter um repositório central onde tudo seja facilmente "encontrável", para que todos os elementos de interface possam ser centralizados e todas as equipes trabalhem sempre com as últimas versões. Devemos otimizar o tempo de todos os envolvidos.

- Designers devem ser alfabetizados em programação. Você precisa ser alfabetizado, mas não precisa ser fluente. É preciso entender como funciona a tecnologia para a qual estamos concebendo as nossas intefaces. No futuro, programar será como ler e escrever. Da mesma maneira que você sabe ler e escrever, mas não precisa ser um escritor de romances profissional, como designer de experiência do usuário você precisa saber programar, para melhor executar o seu trabalho.

- Saber programar facilita a comunicação com os desenvolvedores e, consequentemente, o trabalho em equipe. Diminui a barreira que existe entre desenvolvedores e designers, e o aspecto "nós contra eles". Permite também que você faça diretamente no código, correções que muitas vezes levam mais tempo para ser explicadas do que para ser executadas (ou seja, ganha-se tempo).

Esse foi um resumo rápido dos pontos mais interessantes. Os slideshows estão disponíveis no site da conferência e os vídeos com as apresentações estão no Vimeo. Vale a pena conferir se você quiser mais detalhes.

  • Facebook
  • Twitter
  • LinkedIn
  • Email
Categoria: Conferências, Metodologia | 1 comentário

O cliente e a arquitetura de informação

23 de fevereiro de 2012

De todas as atividades do design centrado no usuário, a arquitetura de informação é provavelmente a que me dá mais cabelos brancos em projetos complexos. Por dois motivos:

1. Muitos clientes são prisioneiros de um modelo mental, de uma visão da organização interna da empresa, da qual não conseguem se livrar.
2. Esses mesmos clientes, muitas vezes, têm dificuldade de entender os diagramas que fazemos para mostrar as propostas de uma nova organizaçãoda informação.

Tentar explicar uma nova maneira de estruturar a informação, mais clara, mais simples e eficiente para o público alvo, além de tentar convencer de que é uma melhor solução, é um trabalho árduo, principalmente em projetos onde o conteúdo é extenso e complexo.

Há alguns anos, decidi que não ia mais apresentar diagramas de arquitetura de informação. Não ia mais usar esses diagramas para explicar a nova organização. A estratégia passou a ser a incluir o cliente em todo o processo de criação da nova estrutura e faze-lo "descobrir", junto à nossa equipe a solução ideal, o melhor caminho a seguir.

Mas como fazer isso?

Dependendo do tipo de projeto, usamos na Yu Centrik uma das 3 atividades abaixo (ou todas as três). Hoje em dia, elas são essenciais no nosso trabalho de arquitetura de informação:

1. Diagrama de Afinidades
2. Card Sorting
3. Testes Rápidos de Arquitetura

Como e quando usamos cada uma dessas atividades?

DIAGRAMA DE AFINIDADES
Quando usar: quando há muitas pessoas envolvidas no projeto e muito conteúdo a organizar. As opiniões, em geral, são divergentes. Você percebe que, simplesmente apresentar o seu trabalho e seus argumentos, não vai ser suficiente para gerar um consenso. Serve como ferramenta de brainstorming mas com um objetivo final bem claro: regrupar a informação.

Como: uma ou mais sessões de trabalho conjunto, com todo o grupo (não mais do que 5 a 7 pessoas). Prepare post-its com o conteúdo do site (ou da intranet, extranet, etc.) e peça a cada pessoa para colar os post-its na parede, de acordo com a sua visão da estrutura, e ir explicando, à medida que for organizando o conteúdo, o seu raciocínio lógico. Os outros só ouvem, devendo respeitar a opinião da pessoa da vez. Todos fazem o exercício, inclusive você.

É surpreendente como esse método de trabalho é revelador e permite às pessoas terem uma nova perspectiva, e se abrirem para novas formas de estruturar um contéudo, que antes elas consideravam inadequadas. O fato de ouvir outras pessoas explicarem aos poucos a lógica de sua organização e de ter que explicar essa sua própria lógica, permite que certas pessoas percebam que a sua perspectiva não é única e infalível e são forçadas, assim, a descobrir (e aceitar) novas soluções.

CARD SORTING
Quando usar: sempre que possível. Envolver usuários reais no processo de criação ou na melhoria da arquitetura de informação é importante, ajuda a abrir os olhos do cliente e a evitar conflitos, mesmo quando o número de pessoas envolvidas no projeto não é grande.

Como: existem livros inteiros sobre Card Sorting, mas a ideia não é entrar em detalhes aqui. Basicamente, usamos dois métodos: poucos usuários, em grupos de 2 ou 3, reunidos "ao vivo" , se possível com o cliente ouvindo as discussões (sem interferir); muitos usuários, à distância, usando ferramentas como OptimalSort ou WebSort, e apresentando resultados estatísticos ao cliente. O cliente pode ver os resultados, à medida em que as respostas vão chegando. Esse segundo método é relativamente rápido e bem mais barato. Em geral, não há muitas discussões a respeito dos resultados e um consenso é obtido rapidamente, uma vez que estamos falando da opinião dos usuários, e não da nossa própria ou do cliente.

TESTES RÁPIDOS DE ARQUITETURA
Quando usar: quando uma primeira versão da arquitetura já está definida, mas ainda existem muitas dúvidas, questões e conflitos sobre a organização, nomes de seções e sub-seções.

Como: em laboratório ou à distância. Não recomendo em laboratório por ser caro, e demorado demais para um teste de AI. O melhor método é fazer um teste à distância usando ferramentas como Treejack ou PlainFrame. Como em um teste de usabilidade, você cria tarefas e as pessoas vão clicando, até acharem a seção/sub-seção onde elas pensam que encontrariam a informação procurada. As ferramentas nos dão o resultado compilado dos caminhos que as pessoas seguiram, do número de acertos e de erros. Mais uma vez, os clientes podem acompanhar a evolução dos resultados à medida em que os testes vão sendo realizados.

Num mundo ideal, uma combinação de Diagrama de Afinidades ou Card Sorting com Testes Rápidos de AI deveria fazer parte de qualquer projeto onde a arquitetura de informação é complexa. É raro que a gente consiga fazer as três atividades. Esses métodos permitem envolver o cliente ao longo do processo, mostrando diferentes pontos de vista, mostrando que existem diferentes soluções para um mesmo problema e facilitando o diálogo e a compreensão de soluções que, sendo apresentadas apenas em forma de diagrama no final do processo, pareceriam sem sentido.

Desde que adotei essa abordagem a etapa de arquitetura de informação deixou de ser uma pedra no caminho e passou a ser uma ferramenta de trabalho em conjunto, que faz aumentar a sinergia das equipes envolvidas, gerando melhores resultados e mais eficiência no trabalho.

  • Facebook
  • Twitter
  • LinkedIn
  • Email
Categoria: Metodologia | Palavra(s)-chave: | Comente

O verdadeiro desafio da metodologia “Agile”

5 de fevereiro de 2012

Tem sido muito discutido, nos últimos anos, a integração das equipes de UX e suas metodologias de design centrado no usuário em projetos do tipo Agile. Como fazer para que as nossas atividades se adaptem à velocidade dos projetos nos quais o desenvolvimento do software começa mesmo antes do final do nosso trabalho.

Apesar de toda essa discussão, até hoje não se chegou a uma conclusão formal sobre como modificar a nossa metodologia tradicional para se encaixar nesse novo ritmo. É por isso que estou indo, no final de fevereiro, a NY participar da conferência AgileUX. Vou até lá ouvir e trocar idéias com outros profissionais da área sobre o que tem dado certo e errado nas nossas tentativas de entrar no mundo "ágil".

No entanto, mesmo que se defina a forma ideal de se fazer "experiência do usuário ágil", o buraco na verdade é mais embaixo.

Talvez seja suficiente juntar um design ágil com um desenvolvimento ágil para uma startup. Nessas empresas os homens de negócio, os responsáveis pelo produto, o pessoal de marketing e todos os outros ficam muito próximos das equipes de design e software. Muitas vezes uma única pessoa é responsável por tudo isso e pelas aprovações e decisões estratégicas. O tamanho, a cultura e a própria natureza de uma startup permite uma maior agilidade no processo.

Mas esse definitivamente não é o caso de empresas consideradas os dinossauros da indústria. Em organizações como bancos, seguradoras, governo, entre outras, muitas vezes os processos decisórios internos são tão antigos e incrustados na cultura da empresa que não basta os designers e os programadores serem ágeis. Nenhuma decisão importante é tomada sem que todo um processo hierárquico e político seja seguido. Uma documentação incrivelmente extensa é necessária ao longo de todo e qualquer projeto, e qualquer desvio das normas é considerado falta grave. Além disso, existem pessoas que vivem de criar essa documentação e que são avaliadas por ela. À partir do momento em que se propõe eliminar etapas (e possivelmente pessoas ligadas à essas etapas), cria-se um grande problema dentro de uma organização acostumada a seguir padrões estabelecidos na pré-história do software.

Fazer com que essas organizações, como um todo, se adaptem à metodologia "Agile" é um desafio muito maior do que simplesmente fazer as equipes de UX encontrarem novos métodos de trabalho. Mas existe esperança. Tenho visto muitas equipes aos poucos se abrirem a novas idéias e mesmo tentarem gradativamente integrar uma nova visão de projeto para não perderem o barco. Algumas já entenderam que os dinossauros vão ser extintos mais uma vez...

  • Facebook
  • Twitter
  • LinkedIn
  • Email
Categoria: Metodologia | 1 comentário

Seja o melhor

3 de fevereiro de 2012

Já sei até qual é a pergunta. O que esse livro está fazendo em um blog sobre experiência do usuário e usabilidade? A resposta é simples: esse livro é válido para qualquer área, qualquer que seja o assunto.

Bernardinho descreve como anos de trabalho árduo, de dedicação, de gestão de prioridades e egos, e de intenso foco em objetivos bem definidos levaram aos resultados que todos nós conhecemos.

"Transformando suor em ouro" é um livro sobre liderança, trabalho em equipe, perserverança e busca pela perfeição. Quatro atributos totalmente pertinentes à nossa área de atuação.

Caso você queira ser o melhor naquilo que você escolheu como profissão, esse livro (e outros que vou recomendar aqui) é uma excelente leitura. Caso queira ser apenas mais um, não perca o seu tempo.

  • Facebook
  • Twitter
  • LinkedIn
  • Email
Categoria: Livros | Comente

O Diretor de UX

1 de fevereiro de 2012

Em agosto de 2011 fui entrevistado por uma publicação local chamada Lien Multimédia, dirigida à indústria de mídia interativa no Québec. A conversa girou em torno do que faz um Diretor de Experiência do Usuário (UX), qual a sua função e quais são as tarefas do dia-a-dia. Como está em francês e só assinantes com senha têm acesso ao texto, segue a versão traduzida e atualizada da conversa.

Na verdade, a maior responsabilidade de um Diretor de UX pode ser resumida em uma palavra: comunicação. Essa comunicação ocorre em vários níveis.

Comunicação com o cliente
A comunicação com o cliente é fundamental para o sucesso de qualquer projeto. É preciso entender o escopo do projeto, as necessidades do cliente e as restrições (de orçamento, de tempo e tecnológicas). Saber quem é seu público-alvo, conhecer os estudos que já foram feitos sobre o assunto e entender os objetivos do negócio. É preciso também que o cliente entenda exatamente o que é o nosso trabalho, o que iremos (e, muito importante, o que não iremos) fazer, quando e como. É preciso gerenciar as expectativas do cliente durante todo o projeto. É preciso estar em comunicação constante para evitar mal entendidos, falsas promessas e, assim, antecipar qualquer tipo de problema com aquele que está pagando pelo trabalho. E, claro, é preciso comunicar de forma efetiva o resultado do que está sendo produzido.

Comunicação com a equipe
A função do Diretor de UX é filtrar e transmitir para equipe que vai trabalhar no projeto toda a comunicação com o cliente: mastigar a informação, digerir, dosar, priorizar tarefas e separar o relevante do irrelevante para otimizar o trabalho dos talentos do time. Também faz parte discutir sobre as características dos usuários do produto, os detalhes da solução de design, as tarefas escolhidas para um teste de usabilidade e tomar decisões quando forem necessárias. E mais, estar em comunicação constante com o gerente de projeto e/ou o gerente da conta sobre a evolução do trabalho é tarefa crucial nesse processo todo.

O Diretor de UX é um facilitador do trabalho da equipe e, facilitar, significa saber se exprimir claramente. Uma boa comunicação é essencial para dirigir bem a sua equipe, apontar erros, soluções, fazendo na hora certa críticas e elogios.

Comunicação dentro da empresa
É fundamental que a empresa onde você trabalha saiba o que está acontecendo no projeto. As coisas estão andando bem? O cliente está pedindo mais do que foi contratado? A equipe está produzindo como esperado? Existe alguma coisa que está acontecendo hoje e que vai causar no futuro um atraso nas entregas? A comunicação com outros diretores, vice-presidentes e o presidente é essencial para que a empresa se sinta com controle sobre o projeto, para que saiba quando deve faturar, quando a sua equipe vai ser liberada para novos projetos e quando pode comemorar o fim de mais um projeto bem sucedido.

Importantíssimo: uma preocupação permanente e imprescindível é ter a certeza, o tempo todo, de que tudo o que você está dizendo, fazendo e até pensando, está sendo bem compreendido por todo mundo! De nada adianta você comunicar tudo o que precisa ser dito e as pessoas à sua volta não estarem entendendo exatamente o que você diz. Você não pode simplesmente presumir que as pessoas entenderam, você precisa estar certo disso. Repita quando for preciso, desenhe se necessário, use body language, enfim, qualquer coisa vale...

É claro que essa comunicação tem que vir recheada de liderança, visão do produto, conhecimento no assunto e conhecimento do usuário. Sem isso, nem o cliente e nem a equipe vão ter confiança em você e no que você comunica. E, obviamente o usuário final vai sofrer as consequências.

Comunicação com os usuários
E, por último, o resultado do trabalho de um profissional de UX é, direta ou indiretamente, a comunicação com aquele que dá o nome ao seu cargo: o usuário final do produto. Dependendo da envergadura do projeto, dos prazos e da equipe disponível, não é incomum ver o Diretor de UX metendo a mão na massa. Entrevistas com usuários, testes de usabilidade, diagramas de arquitetura, wireframes, tudo isso é uma forma de comunicação com o usuário do produto.

Além disso, a interface de um produto interativo, seja um website, uma aplicação iPhone ou a tela de GPS, nada mais é do que um meio de comunicação entre o dispositivo, a empresa que fornece o conteúdo ou presta o serviço e seu usuário final.

100%
Bem, não é difícil concluir que essas tarefas ocupam 100% do meu dia. Telefonemas, reuniões, sessões de brainstorm, discussões com a equipe, apresentações, design, grupos de discussão, testes… e, qualquer coisa além disso é feita nas horas fora do escritório.

Diferentes tipos e tamanhos de empresa podem determinar variações no dia-a-dia de um Diretor de UX mas a comunicação sempre será um atributo chave e sempre será a sua função mais importante.

  • Facebook
  • Twitter
  • LinkedIn
  • Email
Categoria: Vida de UXer | Comente