Facebook Vs Myspace – Quem vence com as novas interfaces gráficas?

Facebook e MySpace são populares sites de redes sociais. Enquanto o MySpace era originalmente o mais popular, o Facebook ultrapassou o MySpace em termos de adesão em 2008. Os perfis do Facebook estão mais próximos das identidades reais do usuário em comparação com o MySpace, mas será que este é o unico motivo para a migração dos usuários?

História do MySpace vs Facebook

Facebook se tornou popular a partir de comunidades universitárias e realmente foi iniciado por um estudante de Harvard, Mark Zuckerberg, em seu quarto do dormitório. O que começou como um site interno da faculdade por diversão se transformou em site de rede social mais aclamado de todos os tempos. Facebook, inicialmente chamado “thefacebook”, iniciado por estudantes de graduação da inscrição de Harvard, Yale, Stanford e Columbia e mais tarde acrescentou mais assinantes de outras escolas, empresas e, finalmente, aberto ao público em setembro de 2006.

MySpace foi iniciado em agosto de 2003, para imitar o outro site de rede social Friendster por uma equipe de funcionários eUniverse. Os primeiros usuários deste site foram os funcionários de eUniverse e depois se espalhou para as massas. Este empreendimento planejado foi logo escalado para o topo da lista de sites de redes sociais.

Os usuários do Facebook vs usuários do MySpace

No início, o MySpace era mais popular entre os estudantes do ensino médio e Facebook entre estudantes universitários. Um estudo recente realizado pela empresa americana Nielsen Claritas, mostrou que o grupo de renda dos usuários do MySpace é mais baixa em comparação com os usuários do Facebook. Outra diferença observada foi a que mais usuários do Facebook estavam inclinados a usar outros sites de redes profissionais como o LinkedIn do que os usuários do MySpace. Em fevereiro de 2010, o Facebook teve cerca de 400 milhões de membros e MySpace tem cerca de 150 milhões de usuários.

A batalha

De qualquer forma as duas empresas não abrem mão do mercado e usam a inovação como motor, por isso novos protótipos de interfaces estão surgindo, confira abaixo as novidades que as redes lançam em breve e de a sua opnião de quem vence essa guerra por mais usuários.

Nova interface My space

 

Nova interface Facebook

Quer saber mais?

http://en.wikipedia.org/wiki/Facebook
http://en.wikipedia.org/wiki/Myspace
http://www.readwriteweb.com/archives/more_proof_facebook_for_the_rich_myspace_for_the_poor.php
http://www.readwriteweb.com/archives/myspace_mail_now_has_over_15_million_users.php
http://www.diffen.com/difference/Facebook_vs_MySpace

Soluções para o monitoramento de interfaces

A fase em que uma interface está em operação é, em boa parte dos casos, a mais longa de seu ciclo de vida. Contraditoriamente, ela tem recebido pouca atenção dos pesquisadores e dos profissionais trabalhando na área. Até pouco tempo, havia pouca oferta em termos de técnicas e de ferramentas para o monitoramento de uma interface em produção.

Mais recentemente, essa lacuna começou a ser preenchida, em minha opinião, devido a três fatores principais:

  1. a preocupação com a experiência do usuário, um fenômeno que vai muito além do uso
    momentâneo do sistema;
  2. as interfaces de uma maneira geral estão muito mais evolutivas, em uma busca constante por satisfazer e criar necessidades;
  3. o desenvolvimento de facilidades de comunicação e de coleta de dados de uso em larga escala e a partir de qualquer lugar no planeta.

Hoje as soluções para o monitoramento de interfaces são mais variadas e numerosas. Os principais tipos de técnicas
são os testes de usabilidade à distância, os diários e os painéis, as pesquisas de satisfação e a web analítica. Já escrevi um artigo sobre a Web analítica orientada à usabilidade. Apresento aqui o que identifiquei de novo, em  relação às outras técnicas.

Um teste de usabilidade à distância nada mais é do que uma observação crítica do uso de um sistema que é apoiada por recursos de comunicação e de captura remota de dados. Os resultados se referem ao desempenho e à satisfação dos usuários.

É importante observar que em um contexto de monitoramento esses resultados têm um perfil diferenciado: eles têm de ser mais objetivos e mais representativos. Eles não precisam ser tão detalhados, uma vez que a interface está “pronta”, ela está sendo apenas monitorada. Mas, para produzir resultados representativos, eles têm de envolver um número maior de usuários, operando os sistemas em seus
ambientes naturais. Em algumas soluções, o moderador está “on-line” e se comunica com o participante, orientando-lhe sobre as tarefas do teste,
puxando conversa sobre suas estratégias e dificuldades e aplicando questionários pré e pós-teste. As conversas e as telas do usuário são capturadas à distância (ex. Morae – Remote participant). Alguns ambientes implementam uma moderação automática, na forma de uma interface do tipo passo a passo, que conduz os participantes nas tarefas e aplica questionários pré e/ou pós testes (ex. UserZoomEthnio,  Loop11,  Morae/AutoPilotCapteria/ZOOMA).

Os estudos de caso disponíveis no site de UserZoom, em particular, se referem a testes à distância envolvendo entre 200 e 1.200 participantes espalhados por diversos países. Outras ferramentas apenas capturam a imagem e o som dos testes (ex. UserflyWebnograph e OpenHallway).
Os usuários recebem instruções por e-mail sobre as tarefas a executar, e a ferramenta captura as interações por meio de scrips instalados nos sites sendo testados. Nenhuma facilidade de moderação ou de análise de dados é fornecida. Já os “click-tests” são versões bastante simplificadas de
testes à distância nas quais o usuário é convidado apenas a clicar sobre a opção que lhe parece a mais indicada para alcançar o objetivo que lhe é
proposto (ex. Usabila Chalkmark).

As técnicas de diários e painéis destinam-se especificamente à coleta de dados sobre a utilização dos sistemas (quantas vezes, quando e durante quanto tempo) e de comentários com as explicações e as emoções experimentadas por um grupo de usuários pré-cadastrados. Essa coleta pode ser feita apenas uma vez, em um determinado instante no tempo, ou repetida várias vezes, durante um período de tempo. FiveSecondTest é uma solução de “painel instantâneo”, na qual os usuários visualizam uma página durante 5 segundos e em seguida respondem perguntas formuladas pelos projetistas, apresentadas automaticamente pelo sistema.

O OpenDiary e o Diary.com são exemplos de ferramentas podendo apoiar a técnica de diários, na qual os participantes são instruídos a
registrar seus comentários imediatamente após a realização de suas tarefas, ou a intervalos regulares, ou ainda no final do dia.

Os painéis mais abrangentes vão exigir alguma instrumentação nos ambientes dos próprios panelistas, de modo que passem a coletar dados sobre a sua configuração e informações sobre o uso dos sistemas. Já os painéis de curta duração estão focados na realização de tarefas e
coletam informações sobre dificuldades e problemas ocorridos. Os de longa duração (semanas ou meses) são menos focados em tarefas específicas e mais na forma como os participantes usam um sistema (duração de uma sessão de uso, duração dos intervalos intra e entre sessões, existência de trabalho em paralelo). Eles permitem identificar, em particular, as variações no estilo de uso dos sistemas que ocorrem naturalmente com o tempo, ou devido a alguma mudança no ambiente do usuário. Uma extensão interessante de diários e painéis é a técnica de “living labs” (The PlaceLab), que se refere ao monitoramento de comunidades de uso e não apenas de usuários individuais.

As pesquisas de satisfação dos usuários estão em geral a serviço de testes de usabilidade, diários e painéis, mas elas podem também ser realizadas isoladamente. Por meio desse tipo de técnica busca-se identificar, de maneira padronizada e sistemática, a
satisfação dos usuários em relação a uma interface ou sistema. O desenvolvimento dos instrumentos de pesquisa caracterizou-se inicialmente pela
busca das melhores perguntas a colocar aos usuários e, mais recentemente, pela busca da melhor forma e do melhor momento para obter suas respostas.

Em sua evolução, surgiram questionários com questões sobre aspectos gerais (SUS) e específicos (SUMI e QUIS)
para interfaces em geral e para tipos específicos de interfaces (MUMMS – multimídia e WAMMI – Web). As pesquisas de satisfação já
foram enviadas pelo correio normal, depois pelo correio eletrônico e hoje elas estão disponíveis em páginas Web específicas (SurveyMonkey).
Elas também estão incorporadas às interfaces dos sistemas sendo monitorados (KeySurveyOpinionLab). Kampile é uma solução que convida o usuário a dar sua opinião sobre uma interface em momentos críticos, quando ele completa uma tarefa ou ao contrário, quando parece
tê-la abandonado. 4QSurvey.com implementa um tipo de pesquisa em dois momentos, num primeiro, para identificar o propósito do usuário e, no segundo, para obter a sua satisfação em relação a esse propósito. É interessante notar que essa ferramenta produz também um tipo especial de medida da eficácia dos usuários.

Para concluir e para justificar este artigo, recorro a uma evidência. Cada vez mais, tudo está em evolução. Não só as interfaces, mas também os contextos, os ambientes, os usuários e as comunidades. É mais do que evidente a necessidade de monitoramento de todos esses
aspectos. Apresentei aqui cerca de 20 soluções que podem apoiar iniciativas de monitoramento de interfaces. Imagino que muitas outras existam e
espero ansioso pelas contribuições de vocês.

Por: Walter de Abreu Cybis
Fonte: Imasters

 

O que podemos entregar além da arquitetura da informação

A medida que os projetos aumentam, a inserção de profissionais que desenham a experiência do usuário e os desafios se tornam mais dramáticos, nada melhor do que uma boa dose de entregáveis, para que o design do projeto fique muito bem alinhado e entendido por todos da equipe, incluindo o cliente!

  • Análise heurística:

É uma análise que trata de um conjunto de “boas praticas” de usabilidade que um site deve conter. Jakob Nielsen criou um conjunto bastante robusto e realista, no qual observamos alguns pontos que podem definir se o site está acessível, ou não:

  1. Visibilidade do estado do sistema;
  2. Correspondência entre o sistema e o mundo real;
  3. Controle e liberdade do usuário;
  4. Consistência e padronização;
  5. Prevenção de erros;
  6. Reconhecimento, em vez de lembrança;
  7. Flexibilidade e eficiência de uso;
  8. Projeto estético e minimalista;
  9. Recuperação de erros;
  10. Ajuda e documentação;
  11. Controle e liberdade do usuário.
  • Análise de requisitos:

Consiste em conversas com o cliente/usuário sobre as diretrizes do projeto e com o objetivo de conhecer as funcionalidades do sistema no qual será desenvolvido. É nesta fase, também, que ocorre a maior parte dos erros, pois a falta de experiência dos clientes, ou usuários, faz com que eles nem sempre tenham saibam quais as funcionalidades que o software terá.

  • Analise de acessibilidade:

Consiste, basicamente, em uma análise para verificar o nível de acessos facilitados do site/portal. Se ele está disponível e acessível via web a qualquer hora, local, ambiente, dispositivo de acesso e por qualquer tipo de visitante/usuário. Também pode apontar se os usuários podem acessá-lo de diferentes sistemas operacionais e, principalmente, se podem ser acessadas por todos, independentemente de capacidade motora, visual, auditiva, mental, econômico, social ou cultural.

  • Análise de métricas:

É o olhar do arquiteto de informação sobre as métricas do projeto. Analisar os números de acesso, navegação e interação e encontrar soluções para melhora. Se a taxa de rejeição de determinada tela está alta, talvez ela seja o seu próximo alvo de melhorias de design e usabilidade.

É uma lista do que vai ser usado para medir se o seu projeto/design/redesign atingiu os objetivos do cliente. Número de visitas? Número de seguidores no Twitter? Porcentagem de pessoas que compartilham seu conteúdo? Nessa hora, vale uma boa conversa com o pessoal de Data Intelligence para definir quais métricas são importantes e possíveis de serem mensuradas. Sem essas métricas, fica difícil calcular o retorno sobre investimento (ROI) do projeto.

  • Análise hierárquica dos objetivos:

Avaliar a importância relativa de diferentes alternativas, no que diz respeito a múltiplos atributos (quantitativos ou qualitativos:

  1. Identificar os elementos do problema;
  2. Determinar objetivos;
  3. Estabelecer a hierarquia;
  4. Determinar prioridades.
  • Análise qualitativa e quantitativa:

Análise de interface qualitativa descobre o comportamento do usuário durante a navegação. Por exemplo: descobrir que todo usuário clica no logo quando quer voltar para a home, ou que os usuários de uma determinada seção do site são predominantemente mulheres. Já as análises quantitativas permitem, como no focus group, mensurar opiniões de grupos sobre o produto.

Os resultados não são apenas “este produto agrada” ou “este produto não me agrada”; mas sim os motivos dessas opiniões. Pode ser informação valiosa no desenvolvimento do projeto e depois de sua implantação.

Esses dados permitem redefinir as seções privilegiando as informações de acordo com o público, ou definir premissas para um determinado projeto. Onde antes só considerávamos os browsers e as resoluções de tela, hoje podemos ir muito além, considerando também o perfil do usuário.

  • Testes de usabilidade:

São roteiros criados a partir dos fluxos existentes no protótipo, ou site, e testados a partir de usuários, para que possamos enxergar os pontos fortes e melhorar o site. É possível ajustar para que a entrega esteja bem alinhada e com usabilidade eficiente.

Observar as pessoas interagirem com o resultado do projeto permite um olhar bastante claro e realista sobre as telas e sua forma de interação com o usuário. O resultado desses testes ajuda na defesa de alguns conceitos envolvidos no projeto (quer seja pelo cliente, ou equipe), desalinhados com o entendimento e necessidade do usuário.

  • Eye tracking:

Último grito da modernidade, o mapeamento do olhar do usuário sobre a interface auxilia na definição de pontos de interesse sobre conceito, layout, navegação e modelo de interação, com dados realistas para ajustar as informações da tela, para que sejam mais atraentes ou fáceis de encontrar.

O entregável é um relatório que mostra quais pontos da tela foram mais olhados pelos usuários, em um heatmap, que mostra em cores quentes as áreas mais visualizadas da interface. O custo de realização dos testes de eyetracking é mais alto do que os testes de usabilidade, pois são necessários equipamentos especiais para monitorar o movimento do olho do usuário.

  • Teste de stress de navegação:

É uma técnica de simulação usada para determinar o comportamento de um produto digital em diferentes cenários.

  • Design participativo:

A proposta do Design participativo é valorizar a participação de usuários durante o processo de desenvolvimento de produtos e serviços. Através de oficinas e ferramentas colaborativas, os usuários participam ativamente da definição das características do que está sendo projetado.

  • Documento URL:

Sugestão de URLs amigáveis para as telas.

  • Grids:

São linhas que demarcam a diagramação do conteúdo. Eles são parentes bem próximos das réguas e das métricas e sua principal função é sustentar a padronização da diagramação, facilita a leitura e torna a navegação híbrida e intuitiva.

  • Wireframe:

É a planta baixa do site; o seu esqueleto. O resultado de pesquisas onde pode ser encontrados todos os elementos em cada tela e suas disposições e orientações. O intuito é mostrar a hierarquia das informações, das telas e o fluxo de navegação que irá existir.

Importante relembrar para os desavisados que o wireframe deve ser apresentado em tons de cinza, não há neste momento níveis de escalas ou posicionamento de elementos gráficos, o que significa que o designer tem toda a liberdade de criar um layout diferente do wireframe, desde que sejam respeitadas as organizações textuais e hierárquicas das telas.

  • Mashups:

São reproduções de uma ideia que mais se aproximam da realidade. Em tamanho real, ou aproximado, mas que não precisam reproduzir, necessariamente, suas funções.

  • Fluxograma:

É um sitemap com QI acima da média, onde são organizadas hierarquias das informações e seus fluxos. Dessa forma, é mais fácil compreender a transição das informações em cada tela. Fluxogramas são fundamentais para o olhar realista do projeto, pois além de se compreender os caminhos, ainda permitem encontrar fluxos mais objetivos para a visualização de determinadas seções ou telas.

  • Protótipo:

É uma variação dos wireframes, mas com links e interações entre as telas. Você pode clicar e navegar entre elas, como se estivesse navegando no produto final. Pode ser usado com diversos objetivos: desde ser exibido em um teste de usabilidade, até fazer com que o público interno do projeto (desenvolvedores, gerentes de projeto, designers, cliente) visualizem mais facilmente como determinada peça vai funcionar.

  • Sitemap:

É um organograma que agrega todas as páginas que o site/portal irá conter. Este documento especifica as várias telas e geralmente é produzido no início do projeto – e refinado durante todas as etapas, conforme as demandas posteriores.

  • Vocabulário controlado:

É um instrumento de controle terminológico que estabelece a forma de representar os assuntos que compõem um conjunto de áreas do conhecimento, tornando possível maior coerência entre os termos indexados.

  • Documento de taxonomia:

De forma mais genérica, podemos dizer que taxonomia é uma classificação. Porém, a taxonomia trata de uma estrutura de organização baseada na hierarquia – vai do geral para o específico, do maior para o menor, do menos complexo para o mais complexo. Meios de Transporte > Terrestres > Automóveis > Carros.

  • Inventário de conteúdo:

Quando o projeto, seja ele novo ou já existente, e o conteúdo informativo são grandes, se faz necessário ter um controle global destes textos que serão gerados para o site. Consiste em um mapeamento de todas as páginas (previstas ou existentes) e todos os conteúdos de cada uma.

Assim, conseguimos ver holisticamente todo o conteúdo, o que trará uma facilidade em organizar as informações (taxonomias, vocabulário controlado, etc). Assim, ficará mais fácil retirar o conteúdo duplicado, que é muito comum em sites com grande volume de informações.

  • Definições de conteúdo (globais/ locais):

Definições de posicionamento e ocorrência de informações dentro do site/sistema.

  • Modelo conceitual:

Normalmente é usado para representar uma visão macro de como um produto funciona (do ponto de vista conceitual) – sem a necessidade de entrar em detalhes sobre cada funcionalidade. Pode ser um gráfico, um parágrafo de texto ou um fluxograma – o importante é mostrar de forma simples como o produto irá funcionar. Geralmente é apresentado nas fases iniciais do projeto, para garantir o alinhamento entre as áreas.

  • Definições de objetivos:

É o resultado gerado da analise de métricas.

  • Benchmark:

É a observação e o estudo de projetos que tenham semelhança, quer seja em comportamento ou conteúdo, com o projeto que vamos desenvolver. É a analise dos pontos positivos e negativos para que sejam considerados no momento em que iremos criar o “jeitão” das telas e seus comportamentos.

Benefícios bacanas de um benchmark:

  1. Novo olhar sobre conceitos e padrões – o que pode trazer novidades bem focadas e pertinentes com a proposta;
  2. Permite que o conhecimento sobre o mercado e sobre o cliente seja amplificado e consequentemente, do projeto também;
  3. Facilita a identificação das áreas críticas;
  4. Permite um olhar realista ao traçar objetivos.
  • Card sorting:

Esta é um técnica interessante, com a qual podemos entender um pouco do fluxo mental do público do projeto. Pequenos cartões com as categorias de determinada tela são entregues para um número de pessoas. O objetivo é que o usuário organize um fluxo que considere prático e simples, de acordo com seu entendimento.

Nesse momento, onde pode acontecer (e deve!) uma conversa entre ele e o arquiteto de informação, é possível entender os motivos deste modelo de classificação e depois de todas as escolhas é feito uma análise onde os fluxos mais indicados pelos usuários serão aplicados na tela.

  • Focus group:

É uma discussão entre um grupo, geralmente pequeno, sobre o “produto” que está sendo desenvolvido. O custo geralmente é baixo, é rápido de organizar e pode trazer resultados interessantes focados diretamente no consumidor final.

  • Mapas mentais:

É o nome dado para um tipo de diagrama voltado para a gestão de informações, de conhecimento e de capital intelectual. Auxilia a compreensão dos problemas e é utilizado como ferramenta de brainstorm.

  • Cenários:

São descrições de situações hipotéticas, em que são colocadas pessoas que interessam ao projeto. Essa técnica é usada de várias maneiras. Alguns utilizam para auxiliar numa decisão crucial de projeto, ou para avaliar as características, outros para demonstrar as características do artefato projetado em uso e etc.

O cenário pode ser escrito formalmente, servindo como documentação de projeto, ou ser criado enquanto se discute questões a respeito do projeto. O que se segue a essa frase é um cenário: “suponha que o usuário faça isso, então…”.

Em um projeto simples, os cenários não precisam ser necessariamente oficializados. Eles podem surgir no meio de conversas da equipe, ou apenas na mente do designer. O mais importante é estar colocando à prova o jogo de cintura da aplicação. Isso se torna especialmente importante nos momentos tensos da aplicação: formulários complexos, negociações financeiras, tratamento de erros e etc.

  • Orientações de design:

Verificar com o DA o desenvolvimento das telas, no que se refere às diretrizes de AI e possíveis ajustes necessários durante o projeto.

  • Orientações de funcionalidade:

Verificar com a equipe de modelagem o desenvolvimento das telas, no que se refere às diretrizes de AI e possíveis ajustes necessários durante o projeto.

  • Orientações de acessibilidade:

Verificar com a equipe de implantação e modelagem o desenvolvimento das telas, no que se refere às diretrizes de AI e possíveis ajustes necessários durante o projeto.

  • Ecossistema:

Quando um projeto é formado por diversas peças (um site, um aplicativo mobile, uma página no Facebook, um banner, um hotsite etc.), é um mapa detalhado de como esses diversos ambientes conversam entre si. Para onde você quer levar cada usuário e por quê? Qual o caminho que você espera que ele percorra?

  • Roadmap:

É um plano de ação; um roteiro; um passo a passo para o desenvolvimento de um projeto que precise de fases nas entregas, ajudando a coordenar e planejar os avanços. Além de deixar claras as datas, ajuda também a enxergar o conjunto de tecnologias que podem ser aplicadas para o projeto.

  • Personas:

Se a premissa é cada projeto tem um público alvo a atingir, as personas são formatos para entender e enxergar melhor o usuário da solução web. É uma descrição que pode ser detalhadíssima ou mais simples, com o intuito de personificar um usuário do publico alvo. Esta pessoa de “mentirinha” ajuda o alinhamento das expectativas tanto do cliente, quanto da equipe, sobre recursos e funcionalidades que devem estar contidas no projeto e na avaliação do produto. Criando sua pessoa, é bacana conter:

  1. Nome para facilitar a associação com pessoas reais;
  2. Características e razões para que o site seja importante para ele. Um histórico da persona, em relação às suas expectativas com o projeto;
  3. Cenários para ambientar as condições em que a persona vai interagir com o site;
  4. Características de comportamento quer sejam emocionais ou sociais, que sejam comuns ao publico representado pela persona, hábitos, linguagem e motivações.
  • Mood Board:

Geralmente é um documento elaborado com ajuda do time de cultural insights, planejamento e/ou design, e procura reunir referências visuais do que se espera do site. Ajuda os designers a definirem qual linha visual devem seguir no projeto, baseado no universo de referências dos usuários.

  • Caso de uso/Documento de especificação e mensagem de sistema:

É o detalhamento de todos os cenários de uso e regras de funcionamento do sistema. Utilizados em projetos que possuem muitas variações de uso, esses documentos normalmente são escritos por um tecnólogo, que conta com a ajuda e validação do arquiteto de informação para levantar todas as situações possíveis.

É importante prever soluções e mensagens (de sucesso ou de erro) para cada uma delas, para garantir que a conversa com o usuário seja consistente e eficaz, independente do cenário em que ele se encontra.

  • Teste A/B:

São testes comparativos entre duas ou mais soluções para uma mesma tela, ou tarefa. O modelo clássico funciona da seguinte forma: metade dos visitantes vêem a versão A da tela, metade vêem a versão B, durante certo período de tempo. No final, mede-se e compara-se a desempenho de cada uma das versões – e a melhor delas é implementada para 100% dos visitantes. Testes A/B podem acontecer de forma sucessiva e constante, para que o produto evolua sempre.

Agora é estudar o cliente e seguir criando sets de entregáveis muito personalizados. Bons projetos!

Por: Iris Ferrera disponível em:
http://imasters.com.br/artigo/23529/usabilidade/o-que-podemos-entregar-alem-da-arquitetura-da-informacao

Palestra Inovação centrada no usuário em BH IxDA

Neste mês de Julho teremos a 23ª edição do Encontro IxDA em Belo Horizonte, desta vez receberemos a visita do Paulo Melo, User Experience Business Mananger no C.E.S.A.R em São Paulo.

Teremos uma palestra e logo em seguida um bate papo informal com todos os participantes.

Inovação centrada no usuário
Criando os produtos que a sua vovó vai usar e você vai ficar feliz em comprar.
Com a necessidade de inovar se tornando cada vez mais urgente nas agendas das organizações, investir apenas na inovação de base tecnológica mostrou-se uma estratégia com limitações claras.
Neste cenário, um paradigma de inovação cada vez mais popular é a chamada Inovação Centrada no Usuário. Nesta perspectiva, o processo de inovação se dá a partir da inspiração nos hábitos e contextos do consumidor. A Inovação Centrada no Usuário parte da premissa de que inovações devem ser geradas de forma a serem baseadas no entendimento do usuário, solucionar problemas e atender demandas identificadas em um contexto social específico.

Sobre Paulo Melo
Psicólogo e mestre em Psicologia Cognitiva pela UFPE.
Em 2010, ele concluiu o doutorado profissional em User-system Interaction na University of
Technology Eindhoven (Holanda).
Profissionalmente, Paulo atuou como Designer de Interação e Especialista em Usabilidade no CESAR e CSIRO
(Austrália). Nos últimos anos, ele tem atuado na área de Experiência do Usuário (UX), onde trabalhou pelo CESAR Sul, Philips e In/situm. Ao longo de sua experiência profissional, Paulo participou de projetos ligados a jogos para aparelhos celulares, acessibilidade, aplicações médicas, TV digital, sistemas de informação e design de produtos. Atualmente Paulo é gerente de negócios para projetos em UX no CESAR em São Paulo. Além disso, Paulo tem dado aula sobre design, usabilidade e inovação na Faculdade Anhanguera, Universidade Positivo e CESAR.Edu.

Data: 11 de Julho
Horário: 19 às 22h
Local: Restaurante Take http://www.takebh.com.br/
Mapa Aqui
Programação: 40 minutos de palestra e na sequência um bate papo informal aberto a perguntas.

O evento é gratuito sendo obrigatório somente a consumação mínima de R$ 15,00 por pessoa, lembrando que na quarta-feira é dia de rodada dupla de chopp.
A quantidade de lugares disponível no espaço é limitada, então confirme sua participação no evento criado no grupo IxDA-BH no Facebook:
Facebook ou envie um e-mail para contato@ixdabh.org.
Abraço e esperamos todos de BH por lá 🙂

Mobile first | Arquitetura de Informação

Mobile first

Posted on junho 4, 2010 by Fabricio Teixeira

Luke Wroblewski defende em seu blog a ideia do “Mobile First”.

A ideia é simples e o argumento também: desenhe sua solução primeiro para mobile, depois para desktop. Esse exercício forçará o seu poder de síntese ao máximo e, ao transportar para a versão desktop do site, você já terá limado o excesso de conteúdo.

Segundo ele, o excesso de informação em grande parte dos sites se dá porque é relativamente fácil adicionar conteúdo na versão desktop.

“O mobile não deixa espaço para nenhum conteúdo de relevância duvidosa. Você precisa saber o que realmente importa. Para fazer isso você precisa conhecer bem os seus usuários e o seu mercado.”, afirma Luke.

Ele ainda dá um exemplo de site construído dessa forma:

Web first

Mobile first

Luke W. ainda lança outros argumentos para essa metodologia “mobile first”:

O mercado mobile está explodindo. A quantidade de usuários que transfere dados pelo celular triplicará até 2013.

A versão mobile te força a ter foco. Afinal, são apenas 320 pixels de largura para você brincar.

Mobile expande suas capacidades técnicas: GPS, user orientation, multi-touch, acelerômetro etc.

Os argumentos são interessantes, mas penso que não é sempre que vale a pena começar desta forma.

E você? Acha que funciona?

viaMobile first | Arquitetura de Informação.

Formulários

de Silvia Melo

 

Eu já havia achado exagero do James Kalbach escrever um livro apenas sobre navegação. O que dizer então de uma publicação dedicada a formulários?  “Web Form Design: Filling in the Blanks” é o novo livro de Luke Wroblewski, um dos diretores de Design do Yahoo!, ex-Ebay e fundador da LukeW Interface Designs.

Luke mostra como o formulário é crucial nas interações online. Em um processo de checkout, por exemplo, um cadastro mal desenhado pode acabar com a venda.  Nas comunidades virtuais ele é um verdadeiro portal de entrada – apenas no MySpace cerca de 150 milhões de usuários começaram seu relacionamento preenchendo essas caixinhas quadradas. E são os formulários que permitem hoje toda a colaboratividade que existe na web – para colocar um vídeo no You Tube ou compartilhar um link no Del.icio.us é inevitável o preenchimento deles.

O autor disponibilizou no Flickr todos os prints utilizados no livro. Pela loja da Rosenfeld Media é possível comprar a versão digital da publicação por um preço camarada (US$ 19 ou cerca de R$ 33) e, o melhor ainda, sem longas esperas nem custo de frete.

Interface à prova de erros

de Silvia Melo

 

Há menos de duas semanas recebi um desafio relâmpago: adaptar o monte seu carro da Fiat para o Big Brother Brasil. Os participantes do programa seriam submetidos a uma prova de resistência e o vencedor premiado com um novo Siena, podendo customizá-lo com a versão, cor e opcionais desejados.

Tendo em vista o curto espaço de tempo para a interação com a ferramenta e o desgaste físico e emocional do usuário, definimos a principal missão do projeto: criar uma interface à prova de erros. Para isso seguimos alguns caminhos:

  • Fluxo único: Não incluímos as opções de “voltar” e de “refazer escolhas” para que o usuário não levasse muito tempo no processo de configuração do carro
  • Menos texto, mais imagens: Só foram mantidas no processo de escolha as informações essenciais. Detalhes sobre itens de série e outras disponíveis no monte seu carro online foram eliminadas em nosso paredão
  • Movimento: as animações do veículo em 3D foram um importante recurso na ferramenta. Além de permitirem que o carro fosse visto de todos os ângulos também sinalizaram a transição entre os passos da montagem do veículo, que entrava e saía da tela a cada avanço
  • Opções reduzidas: Enquanto no monte seu carro do portal da Fiat o usuário escolhe entre mais de 30 opções de versões, cores e acessórios, aqui elas foram reduzidas para menos da metade. Os opcionais foram agrupados em quatro temas, simplificando a escolha – conforto, estilo, tecnologia e segurança
  • Noção de valor: Como o preço do produto não seria exibido e as imagens das versões eram muito similares, atribuímos algumas noções de valor na apresentação. A versão 1.8, por exemplo, foi chamada de “Potência que impressiona”; a Tetrafuel de “Tecnologia a toda prova”
  • Bonito no vídeo: Diego Araújo, coordenador de Design da AgênciaClick e diretor de arte do projeto, concebeu a ferramenta em uma linguagem própria para a TV. Mas ao testar a ferramenta no display que seria utilizado no programa, uma surpresa – o fundo cinza não ficou bem na tela. Na véspera da entrega, foi ele quem acabou passando por uma verdadeira prova de resistência, trocando o fundo de toda a interface para a cor preta em tempo recorde (espero que ele também ganhe um Siena!)
Apple

Eu quero um pônei – ou o processo de design da Apple

de Silvia Melo

AppleQuando a Apple diz alguma coisa é melhor prestar atenção. Na SXWS Interactive, encerrada no último dia 11, o gerente sênior de engenharia Michael Loop deixou escapar algumas informações sobre o processo de design da empresa. Protótipos de altíssima fidelidade e prazo (muito prazo) são alguns dos diferenciais na construção de produtos tão certeiros.

Hellen Walters, da Business Week, destacou alguns dos “segredos” revelados por Loop:

  • Mockups perfeitos – Apesar de demandarem muito trabalho, tempo e dinheiro eles “eliminam toda a ambigüidade”. Mas todos esses custos na fase inicial diminuem os ajustes lá na frente, o que acaba equilibrando a equação
  • 10 para 3 para 1 – Para qualquer feature são apresentados inicialmente 10 mockups totalmente diferentes, desenhados sem nenhuma restrição criativa. Destes são selecionados os 3 melhores. E aí o trabalho começa de verdade, já que serão gastos meses no desenvolvimento para finalmente se chegar ao nº 1
  • Brainstorm x reunião de produção – Semanalmente são realizadas duas reuniões bem antagônicas: um brainstorm criativo totalmente livre e outra “pé no chão”, onde as idéias malucas são colocadas à prova.
  • “Eu quero um pônei” – É como se fosse uma reunião de briefing, onde o líder do projeto lista todos os desejos e necessidades em relação ao produto. Nas palavras de Loop, “Eu quero um pônei! Quem não quer? Um pônei é deslumbrante!”

Algumas razões para cair de amores pelos protótipos navegáveis

Se você, assim como eu, nasceu na década de 70, provavelmente já teve contato com uma máquina de escrever. Este, que foi o principal instrumento de trabalho dos profissionais de comunicação durante muito tempo, forçava os usuários a escrever de forma doentiamente planejada, na maioria das vezes pressionados pelo medo de errar. Realocar uma frase em outro parágrafo significava ter que bater novamente toda uma página – 1.400 toques a mais (considerando uma lauda de 20 linhas com 70 toques cada) e cerca de 10 minutos perdidos (no caso de um datilógrafo mediano). O editor de texto, com os recursos de apagar, copiar e colar causou uma verdadeira revolução na vida de milhões de pessoas, sobretudo de escritores e de jornalistas.

Vejo uma revolução bem parecida para os arquitetos de informação com a chegada dos programas que geram protótipos (e/ou wireframes) navegáveis em HTML. Nessa lista incluo o Axure, o iRise e o OmniGraffle, entre outros que listarei adiante. Não é mais necessário dedicar tempo e esforços para organizar slides, fazer ajustes em um grande volume de telas ou até mesmo publicar centenas de comentários sobre o fluxo de navegação. A preocupação agora é com o que realmente interessa – o design centrado no usuário.

Ok, o assunto não é novo. Mas como é cada vez mais recorrente alguém me perguntar sobre as vantagens deste tipo de protótipo vou pontuar algumas delas. Mais do que vantagens, são verdadeiras razões para cair de amores por estes softwares:

Experiência de navegação – Este item vem no topo da lista porque acredito que é aqui onde está o maior ganho do protótipo em HTML. Por ser todo navegável ele simula realmente o que acontece a cada clique, resultado que víamos somente depois que o projeto já tinha passado pelo design e pela interface.

Dimensionamento do projeto – Fica bem mais fácil entender quais são as telas-tipo (ou templates) com o uso dessas ferramentas. No Axure, por exemplo, é possível acessar com facilidade a lista de páginas e até mesmo gerar um mapa (também navegável) a partir dela.

Componentização – O bom arquiteto tira proveito disso. Não é preciso desenhar novamente um fluxo de “enviar por e-mail” ou de “cadastro” a cada projeto que eles aparecem na matriz de escopo. Os softwares para desenvolvimento de wireframes permitem a criação de verdadeiras bibliotecas de padrões, que podem ser reaproveitadas com o mínimo de ajustes em outros trabalhos. Isso também dá uma grande agilidade na execução do protótipo.

Documentos mais enxutos (ou o fim do trabalho escravo) – Em um passado não muito distante cheguei a criar wireframes em PowerPoint com mais de 2.000 slides para simular fluxos e cenários diversos – uma documentação burra, pesada e de eficácia totalmente discutível que ainda me causava algumas lesões por esforços repetitivos.

E o cliente? – Pelas minhas estatísticas esta é a pergunta número 1. Devo ressaltar que só tenho tido resultados positivos. Os clientes não só estão compreendendo melhor a proposta como também estão aprovando mais rapidamente os trabalhos, com solicitações de ajustes cada vez menores. Alguns clientes inclusive já pediram (e pagaram!) para que documentações feitas inicialmente em PowerPoint fossem convertidas para HTML.

Fácil aprendizado – Quando a diretoria da empresa em que trabalho autorizou a compra do Axure ficamos com receio de demorar a aprender o software. Esse medo foi dissipado já no primeiro dia de uso da ferramenta – medo seria ter que voltar a usar o PowerPoint. O suporte do Axure, por exemplo, é muito bom: no site da empresa há tutoriais e um blog que realmente convida o usuário a compartilhar críticas e sugestões. Muitas melhorias já foram feitas partir delas.

Designers e programadores menos irritados – Abrir um wireframe em Visio ou PowerPoint era, para os desenvolvedores, uma experiência semelhante a de ler “Os Sertões”, de Euclides da Cunha, em mandarim. Além de chato, muitas vezes o documento gerava uma série de dúvidas que simplesmente travavam o trabalho, a maioria delas referente ao fluxo de navegação. Por não conter libraries, os documentos em Visio e Powerpoint também traziam erros de consistência e muitas páginas escapavam da revisão, aumentando a incidência de erros. Para os programadores, um grande recurso destes programas é a geração da especificação técnica.

Reaproveitamento de código – Aqui vale a pena fazer um alerta: protótipo é protótipo, código é outra coisa. Não encare este tipo de documento como um avanço na etapa do desenvolvimento. Os recursos de programação dessas ferramentas são limitados e geram códigos feios, sujos e gigantes, para não ser mais explícita.