Receio que a dificuldade em explicar User eXperience reflita nosso mal entendimento sobre o tema. Ainda assim tentarei usar uma analogia que pode ser útil.

Pense num bom restaurante que você conhece. Já visitou a cozinha? Deve ser uma bagunça. Mas funciona bem. Tem que ser limpa. As coisas não podem sair errado. Mas para você, cliente, isto é o mínimo. Você não está lá pela cozinha mas sim pela comida. Não só isto! Você está lá pelo ambiente. Você está lá pela conversa. Dependendo do caso, se a comida vier rápido demais pode ser ruim justamente por não dar tempo para um bom bate-papo. No final, no todo, você sabe se teve uma boa experiência. E assim é com qualquer produto.

You can’t really understand what User Experience is, if you don’t understand what people’s experience is.

— BeckNovaes (@BeckNovaes) April 14, 2013

O código de um produto de Software, por exemplo, também tem que funcionar bem. Também tem que ser limpo. Também não pode falhar. Mas para você, usuário, isto é o mínimo. Você não adota um Software pelo código. Você também não adota um Software pela Interface de Usuário. Mas sim porque você tem algum objetivo. Por isso, tudo tem que ser feito com a experiência em mente. No final o usuário terá uma boa experiência se o Software for adequado ao seu modelo mental. Mas observe, isto é bem importante: Não adianta o software pretender ser inovador. Você já ouviu o que as “pessoas comuns” falam do Windows 8? Em sua maioria elas acham ruim! Do ponto de vista da Interface de Usuário é inovador. Mas não é adequado ao seu modelo mental. Eu diria que é radical demais para o momento cujo modelo ainda está atrelado ao próprio Windows tradicional. Se a solução não bate com a expectativa o usuário acaba frustrado. Consequentemente, ele tem uma má experiência.

Experiência é o que as pessoas sentem sobre o que importa para elas. São quais histórias elas contam para as outras pessoas. São as boas memórias que elas mantêm. São os bons sentimentos que elas têm. Não é a usabilidade. Não é a arquitetura da informação. Não é Design de Interação. Não é arquitetura de software. Não é a user interface. Experiência é o todo e não as partes. Acima de tudo, experiência é o que importa para as pessoas, não para nós que fazemos software.

Acima outros dois exemplos de Experiências que ajudam a desmistificar a noção de que isso tem a ver apenas com Interface de Usuário. Na verdade, nem acho que é bom falar de “usuário”.

User is not a good word. It put to much focus on the “how”. We should care about the “why”. How is on the head. Why is on the heart.

— BeckNovaes (@BeckNovaes) April 14, 2013

Existem duas estratégias quando se trata de desenvolvimento de produtos.

A primeira, mais utilizada, é adicionar diversas funcionalidades para justificar o valor que o consumidor deve pagar por ele. O que motiva isto não é necessariamente quem quer vender, mas sim quem quer comprar.

Nós, como consumidores, temos a sensação que estamos pagando bem quando temos algo que, aparentemente, faz um monte de coisa. Se você tiver que escolher entre uma maquina de lavar roupa com um botão Super Dry Wash e outra sem este botão, que custam o mesmo preço, você vai ficar com a primeira mesmo que não saiba para que este botão serve.

Dá pra encarar o manual de instruções?

O problema de adicionar muitas funcionalidades é que raramente é possível ter produtos simples desta forma. O tal do botão Super Dry Wash que nunca é usado pode acabar atrapalhando no dia-a-dia onde você só quer executar a simples tarefa de lavar a roupa. Mas isto você só vai perceber depois e nem vai se dar conta que pagou mais para ter algo que atrapalha.

A segunda abordagem, menos utilizada, é desenvolver produtos simples. Mas aqui temos um problema: é difícil vender bem coisas simples. Embora depois de usar as pessoas apreciem a simplicidade, no momento da compra elas tendem deprecia-las: “não vou pagar tudo isso para algo que só faz aquilo!”

Como o simples geralmente leva a menos funcionalidades aparentes, a única maneira de vender bem é mostrar que estas poucas funcionalidades resolvem o problema como jamais foi visto antes. O consumidor não precisa de 20 funcionalidades medianas (das quais ele só usa 5), ele só precisa de cinco funcionalidades, muito, mas muito boas mesmo!

Mas acontece que resolver o problema como jamais feito antes significa inovar. E como inovar não é nada simples é muito mais fácil seguir o caminho das diversas funcionalidades. Por isso o mercado está cheio de produtos de mil e uma utilidades, inclusive softwares.

Para mim já virou prática: Sempre que me vejo usando um termo para explicar outro termo eu me pergunto: oras, não deveria ser este o nome da funcionalidade?

Beck: Então você clica neste botão para criar um Acesso Rápido na Home.
Usuário: O que é Acesso Rápido?
Beck: É uma espécie de um atalho.

Então propus para o time: Vamos chamar a funcionalidade Acesso Rápido de Atalho.

Beck: Agora na administração tem a funcionalidade de Arquivos Removidos.
Usuário: Para quê serve isso?
Beck: É como se fosse uma lixeira.

Então propus para o time: Vamos chamar a funcionalidade Arquivos Removidos de Lixeira.

- Agora clica no botão Logout para sair – Eu disse para o usuário ao telefone.

Então propus para o time: Vamos chamar a funcionalidade Logout de Sair.

Depois que fizemos as mudanças nunca mais precisamos explicar o que fazia cada coisa.

Nomear os termos numa Interface de Usuário é mais importante do que indica o escasso debate sobre o tema. Esta é uma dica simples mas que realmente pode ajudar:

Como disse meu amigo André Gil estou comendo no prato que cuspi. Já falei muito mal do Slide Share. Eu o considerava como assistir um filme sem audio. Mas hoje vejo diferente. Meu objetivo é explicar algumas coisas da forma mais didática possível e, sinceramente, em tempos de Information Overload, estou cada vez mais resistente em ler textos muito grandes. Por isso este já é meu segundo post com uma apresentação do Slideshare embutida.

São 39 slides que podem ser vistos em menos de 5 minutos. Confio na possibilidade de eu ter explicado melhor em slides do que qualquer texto trabalhado que você levaria mais tempo para ler sem garantia de ter capitado a mensagem principal. A comunicação é uma arte na qual luto para aprimorar.

Os slides mostram a evolução de um produto e procura ensinar apenas uma grande lição: o poder das restrições.

Há 14 anos vejo o mesmo padrão se repetir: as pessoas começam um novo projeto pelo cadastro ou pelo login, perdem um baita tempo nisso e quando chega a hora de implementar a funcionalidade principal tem que fazer as pressas. Resultado: o software fica bom onde não precisa e ruim onde precisa. É preciso inverter esta equação!

Ao que tudo indica as pessoas preferem começar por onde, aparentemente, é mais fácil. Afinal de contas cadastro é algo comum. Parece mais seguro começar por algo que dominamos pois ainda há muita dúvida na funcionalidade principal do sistema. Mas justamente por causa desta dúvida se faz necessário evoluir o software ao longo do projeto. A apresentação abaixo é uma sugestão de abordagem para conseguir isso.

O UX Book Club são comunidades espalhadas ao redor do mundo com o objetivo de desenvolver as habilidades e conhecimentos dos profissionais de Design de Interação, Arquitetos de Informação, especialistas em interação, Designers de interface e áreas afins, através da leitura e discussão de livros sobre User Experience (UX).

http://uxbookclub.org/doku.php

São de interesse do clube assuntos como Teoria do Design, Pesquisa em Design, HCI (Interação Humano-computador), Pesquisa sobre experiência do usuário e processos, negócios relacionados à disciplina do Design, metodologia, usabilidade, ética do profissional de UX, entre outros.

O funcionamento é simples:
Um grupo de pessoas se reúnem na mesma cidade e definem qual o livro que todos irão ler. Após definido o livro, estabelecem uma data para se encontrar e levar dúvidas, apontamentos e tópicos para serem discutidos entre o grupo.
A discussão eleva o conhecimento de todos presentes, gerando profissionais mais capacitados e teoricamente mais experientes nas disciplinas relacionadas ao Design.

Sobre o UX Book Club São Paulo

O UXBookClub São Paulo nasceu no dia 04 de Dezembro de 2011.
O clube é atualmente organizado por Murilo Lima, Nasser Said e Euripedes Magalhães.

DClick

O décimo encontro (primeiro de 2013) do UX Club Book aconteceu ontem dia 27/02/2013 aqui na DClick.
Agradecemos ao Rafael Martinelli e ao Rogério Martinelli (sócios e diretores da DClick) por cederem o espaço para nossas discussões.

Pessoal também comentou “Muito legal essa agência em que você trabalha” e ficou meu comentário,  ”Não somos agência”.

A DClick não é uma agência mas também não é uma software house, nós da DClick desenvolvemos softwares com foco na experiência do usuário, desenvolvemos Web e Mobile apps para grandes empresas, com soluções inteligentes, temos um time focado em UX, o qual esteve quase todos presentes no encontro, que é responsável por criar estudos e soluções (quer seja em Sketchings, Fluxogramas, Wireframes, etc) para dar andamento nos desenvolvimentos das apps.

Com poucos anos de vida a DClick já foi referência no uso de Flex no Brasil, mas nunca ficamos limitados a tecnologia, hoje utilizamos os melhores recursos do mercado, quer seja tecnologias nativas ou frameworks, o que for melhor para o produto final.

Para nós foi um prazer receber o grupo e poder ajudar no compartilhamento do conhecimento de UX aqui em SP.

Continue Lendo

O ciclo sem fim

Se você é um desenvolvedor de web apps, já deve ter dito ou ouvido “Putz, mais porque outro??”, “Mais do mesmo??”, ou então, “Eu não aguento mais estudar” quando o assunto se trata de frameworks de javascript.

Provavelmente dentro de cada empresa de desenvolvimento que utiliza javascript, terá alguém hoje que vai dizer coisas deste tipo, ou pelo menos pensar isso, ainda que não diga. Eu mesmo, confesso ter pensado isso várias vezes.

Continue Lendo

Esse ano de 2013 eu tive a oportunidade mais uma vez de viajar com o pessoal da DClick, como ganhador do prêmio do Agon, o incentivo que temos na empresa para levar profissionais a eventos da área que acontecem nos EUA.

Em 2011 escolhemos a Adobe MAX, o prêmio de 2012 foi adiado para janeiro de 2013, para podermos participar da CES, o maior evento de tecnologia que acontece em Las Vegas.

Passamos dez dias em Las Vegas, foi realmente fantástico, estávamos em 4 membros, Rafael Martinelli (diretor), Henrique Marino (gerente de projetos), Bruno Sales (desenvolvedor e membro do time de produtos), e eu Eduardo Horvath (líder do time de UX).

Continue Lendo

Receio que a dificuldade em explicar User eXperience reflita nosso mal entendimento sobre o tema. Ainda assim tentarei usar uma analogia que pode ser útil.

Pense num bom restaurante que você conhece. Já visitou a cozinha? Deve ser uma bagunça. Mas funciona bem. Tem que ser limpa. As coisas não podem sair errado. Mas para você, cliente, isto é o mínimo. Você não está lá pela cozinha mas sim pela comida. Não só isto! Você está lá pelo ambiente. Você está lá pela conversa. Dependendo do caso, se a comida vier rápido demais pode ser ruim justamente por não dar tempo para um bom bate-papo. No final, no todo, você sabe se teve uma boa experiência. E assim é com qualquer produto.

You can’t really understand what User Experience is, if you don’t understand what people’s experience is.

— BeckNovaes (@BeckNovaes) April 14, 2013

O código de um produto de Software, por exemplo, também tem que funcionar bem. Também tem que ser limpo. Também não pode falhar. Mas para você, usuário, isto é o mínimo. Você não adota um Software pelo código. Você também não adota um Software pela Interface de Usuário. Mas sim porque você tem algum objetivo. Por isso, tudo tem que ser feito com a experiência em mente. No final o usuário terá uma boa experiência se o Software for adequado ao seu modelo mental. Mas observe, isto é bem importante: Não adianta o software pretender ser inovador. Você já ouviu o que as “pessoas comuns” falam do Windows 8? Em sua maioria elas acham ruim! Do ponto de vista da Interface de Usuário é inovador. Mas não é adequado ao seu modelo mental. Eu diria que é radical demais para o momento cujo modelo ainda está atrelado ao próprio Windows tradicional. Se a solução não bate com a expectativa o usuário acaba frustrado. Consequentemente, ele tem uma má experiência.

Experiência é o que as pessoas sentem sobre o que importa para elas. São quais histórias elas contam para as outras pessoas. São as boas memórias que elas mantêm. São os bons sentimentos que elas têm. Não é a usabilidade. Não é a arquitetura da informação. Não é Design de Interação. Não é arquitetura de software. Não é a user interface. Experiência é o todo e não as partes. Acima de tudo, experiência é o que importa para as pessoas, não para nós que fazemos software.

Acima outros dois exemplos de Experiências que ajudam a desmistificar a noção de que isso tem a ver apenas com Interface de Usuário. Na verdade, nem acho que é bom falar de “usuário”.

User is not a good word. It put to much focus on the “how”. We should care about the “why”. How is on the head. Why is on the heart.

— BeckNovaes (@BeckNovaes) April 14, 2013

Existem duas estratégias quando se trata de desenvolvimento de produtos.

A primeira, mais utilizada, é adicionar diversas funcionalidades para justificar o valor que o consumidor deve pagar por ele. O que motiva isto não é necessariamente quem quer vender, mas sim quem quer comprar.

Nós, como consumidores, temos a sensação que estamos pagando bem quando temos algo que, aparentemente, faz um monte de coisa. Se você tiver que escolher entre uma maquina de lavar roupa com um botão Super Dry Wash e outra sem este botão, que custam o mesmo preço, você vai ficar com a primeira mesmo que não saiba para que este botão serve.

Dá pra encarar o manual de instruções?

O problema de adicionar muitas funcionalidades é que raramente é possível ter produtos simples desta forma. O tal do botão Super Dry Wash que nunca é usado pode acabar atrapalhando no dia-a-dia onde você só quer executar a simples tarefa de lavar a roupa. Mas isto você só vai perceber depois e nem vai se dar conta que pagou mais para ter algo que atrapalha.

A segunda abordagem, menos utilizada, é desenvolver produtos simples. Mas aqui temos um problema: é difícil vender bem coisas simples. Embora depois de usar as pessoas apreciem a simplicidade, no momento da compra elas tendem deprecia-las: “não vou pagar tudo isso para algo que só faz aquilo!”

Como o simples geralmente leva a menos funcionalidades aparentes, a única maneira de vender bem é mostrar que estas poucas funcionalidades resolvem o problema como jamais foi visto antes. O consumidor não precisa de 20 funcionalidades medianas (das quais ele só usa 5), ele só precisa de cinco funcionalidades, muito, mas muito boas mesmo!

Mas acontece que resolver o problema como jamais feito antes significa inovar. E como inovar não é nada simples é muito mais fácil seguir o caminho das diversas funcionalidades. Por isso o mercado está cheio de produtos de mil e uma utilidades, inclusive softwares.

Para mim já virou prática: Sempre que me vejo usando um termo para explicar outro termo eu me pergunto: oras, não deveria ser este o nome da funcionalidade?

Beck: Então você clica neste botão para criar um Acesso Rápido na Home.
Usuário: O que é Acesso Rápido?
Beck: É uma espécie de um atalho.

Então propus para o time: Vamos chamar a funcionalidade Acesso Rápido de Atalho.

Beck: Agora na administração tem a funcionalidade de Arquivos Removidos.
Usuário: Para quê serve isso?
Beck: É como se fosse uma lixeira.

Então propus para o time: Vamos chamar a funcionalidade Arquivos Removidos de Lixeira.

- Agora clica no botão Logout para sair – Eu disse para o usuário ao telefone.

Então propus para o time: Vamos chamar a funcionalidade Logout de Sair.

Depois que fizemos as mudanças nunca mais precisamos explicar o que fazia cada coisa.

Nomear os termos numa Interface de Usuário é mais importante do que indica o escasso debate sobre o tema. Esta é uma dica simples mas que realmente pode ajudar:

Como disse meu amigo André Gil estou comendo no prato que cuspi. Já falei muito mal do Slide Share. Eu o considerava como assistir um filme sem audio. Mas hoje vejo diferente. Meu objetivo é explicar algumas coisas da forma mais didática possível e, sinceramente, em tempos de Information Overload, estou cada vez mais resistente em ler textos muito grandes. Por isso este já é meu segundo post com uma apresentação do Slideshare embutida.

São 39 slides que podem ser vistos em menos de 5 minutos. Confio na possibilidade de eu ter explicado melhor em slides do que qualquer texto trabalhado que você levaria mais tempo para ler sem garantia de ter capitado a mensagem principal. A comunicação é uma arte na qual luto para aprimorar.

Os slides mostram a evolução de um produto e procura ensinar apenas uma grande lição: o poder das restrições.

Há 14 anos vejo o mesmo padrão se repetir: as pessoas começam um novo projeto pelo cadastro ou pelo login, perdem um baita tempo nisso e quando chega a hora de implementar a funcionalidade principal tem que fazer as pressas. Resultado: o software fica bom onde não precisa e ruim onde precisa. É preciso inverter esta equação!

Ao que tudo indica as pessoas preferem começar por onde, aparentemente, é mais fácil. Afinal de contas cadastro é algo comum. Parece mais seguro começar por algo que dominamos pois ainda há muita dúvida na funcionalidade principal do sistema. Mas justamente por causa desta dúvida se faz necessário evoluir o software ao longo do projeto. A apresentação abaixo é uma sugestão de abordagem para conseguir isso.

O UX Book Club são comunidades espalhadas ao redor do mundo com o objetivo de desenvolver as habilidades e conhecimentos dos profissionais de Design de Interação, Arquitetos de Informação, especialistas em interação, Designers de interface e áreas afins, através da leitura e discussão de livros sobre User Experience (UX).

http://uxbookclub.org/doku.php

São de interesse do clube assuntos como Teoria do Design, Pesquisa em Design, HCI (Interação Humano-computador), Pesquisa sobre experiência do usuário e processos, negócios relacionados à disciplina do Design, metodologia, usabilidade, ética do profissional de UX, entre outros.

O funcionamento é simples:
Um grupo de pessoas se reúnem na mesma cidade e definem qual o livro que todos irão ler. Após definido o livro, estabelecem uma data para se encontrar e levar dúvidas, apontamentos e tópicos para serem discutidos entre o grupo.
A discussão eleva o conhecimento de todos presentes, gerando profissionais mais capacitados e teoricamente mais experientes nas disciplinas relacionadas ao Design.

Sobre o UX Book Club São Paulo

O UXBookClub São Paulo nasceu no dia 04 de Dezembro de 2011.
O clube é atualmente organizado por Murilo Lima, Nasser Said e Euripedes Magalhães.

DClick

O décimo encontro (primeiro de 2013) do UX Club Book aconteceu ontem dia 27/02/2013 aqui na DClick.
Agradecemos ao Rafael Martinelli e ao Rogério Martinelli (sócios e diretores da DClick) por cederem o espaço para nossas discussões.

Pessoal também comentou “Muito legal essa agência em que você trabalha” e ficou meu comentário,  ”Não somos agência”.

A DClick não é uma agência mas também não é uma software house, nós da DClick desenvolvemos softwares com foco na experiência do usuário, desenvolvemos Web e Mobile apps para grandes empresas, com soluções inteligentes, temos um time focado em UX, o qual esteve quase todos presentes no encontro, que é responsável por criar estudos e soluções (quer seja em Sketchings, Fluxogramas, Wireframes, etc) para dar andamento nos desenvolvimentos das apps.

Com poucos anos de vida a DClick já foi referência no uso de Flex no Brasil, mas nunca ficamos limitados a tecnologia, hoje utilizamos os melhores recursos do mercado, quer seja tecnologias nativas ou frameworks, o que for melhor para o produto final.

Para nós foi um prazer receber o grupo e poder ajudar no compartilhamento do conhecimento de UX aqui em SP.

Continue Lendo

O ciclo sem fim

Se você é um desenvolvedor de web apps, já deve ter dito ou ouvido “Putz, mais porque outro??”, “Mais do mesmo??”, ou então, “Eu não aguento mais estudar” quando o assunto se trata de frameworks de javascript.

Provavelmente dentro de cada empresa de desenvolvimento que utiliza javascript, terá alguém hoje que vai dizer coisas deste tipo, ou pelo menos pensar isso, ainda que não diga. Eu mesmo, confesso ter pensado isso várias vezes.

Continue Lendo

Esse ano de 2013 eu tive a oportunidade mais uma vez de viajar com o pessoal da DClick, como ganhador do prêmio do Agon, o incentivo que temos na empresa para levar profissionais a eventos da área que acontecem nos EUA.

Em 2011 escolhemos a Adobe MAX, o prêmio de 2012 foi adiado para janeiro de 2013, para podermos participar da CES, o maior evento de tecnologia que acontece em Las Vegas.

Passamos dez dias em Las Vegas, foi realmente fantástico, estávamos em 4 membros, Rafael Martinelli (diretor), Henrique Marino (gerente de projetos), Bruno Sales (desenvolvedor e membro do time de produtos), e eu Eduardo Horvath (líder do time de UX).

Continue Lendo