Você já reparou?

Continuando com a minha série de posts questionando a maneira em que fazemos sites (veja o meu post anterior Repensando o “acima da rolagem”), hoje tenho uma nova pergunta para você.

Você já reparou quantos sites hoje informam aos usuários que eles precisam rolar para baixo para ver mais informações?

Aqui separei alguns para você ver:

GoBank

https://www.gobank.com/

Spendee

http://www.spendeeapp.com/

The Future of Airlines

http://www.f-i.com/fi/airlines/

Continuar lendo

Princípios de Design Digital do governo do Reino Unido

Alpha Gov UK

Se você já conhece a história do projeto gov.uk, recomendo pular o próximo parágrafo.

O projeto ficou em Alpha por um tempo e gerou repercussão em todo o mundo. Trata-se de um portal pensado para atender à maioria dos serviços que os cidadãos do Reino Unido possam precisar. Tudo online, muito rápido e fácil de usar. A ideia é que o site se torne o destino único para todos os departamentos do governo em um único lugar. Assim ele não precisa acessar dezenas de sites diferentes para resolver assuntos que, na cabeça dele, se concentram todos na mesma gaveta. Hoje a maioria das melhorias criadas no projeto Alpha já foram incorporadas ao site oficial – e outras aparecerão em uma versão beta.

Há algum tempo, os criadores do projeto publicaram no site uma lista com os princípios de design usados para criar o projeto. Resumi e traduzi alguns pontos aí embaixo. No site oficial tem também alguns exemplos de como os princípios foram implementados (no produto e no processo).

  1. Comece com as necessidades (dos cidadãos, não do governo). O processo de design começa identificando e pensando sobre as necessidades reais dos usuários. Devemos desenhar em torno disso – não em torno do nosso “processo oficial”. Precisamos entender completamente essas necessidades, questionando as informações e não apenas deduzindo coisas. E devemos nos lembrar que o que os usuários pedem não é necessariamente o que eles precisam.
  2. Faça menos. Governos devem fazer apenas o que Governos podem fazer. Se alguém já está fazendo aquilo, link para ele. Se podemos fornecer recursos (como APIs) que ajudarão outras pessoas a construírem coisas – façamos. Devemos nos concentrar no nosso trabalho.
  3. Projete com base em dados. Normalmente, não começamos do zero – as pessoas já estão usando nossos serviços. Isso significa que podemos aprender com o comportamento real das pessoas. Devemos fazer isso, mas precisamos ter certeza que damos continuidade a isso no processo de construção e desenvolvimento, prototipando e testando com usuários reais na web. Precisamos entender o que pretendemos ao usar dados em nosso projeto de design.
  4. Faça o trabalho duro para deixá-lo simples. Fazer algo parecer simples é fácil; fazer algo que seja realmente fácil de usar é muito mais difícil – especialmente quando os sistemas por trás são complexos – mas é isso que devemos fazer.
  5. Itere, depois itere novamente. A melhor forma de construir serviços efetivos é começando pequeno e iterando ferozmente. Lance produtos com um mínimo de funcionalidades o quanto antes, teste-os com usuários reais, passe do modo Alpha para Beta para Live e adicione features e refinamentos baseados no feedback real dos consumidores.
  6. Construa para a inclusão. Design acessível é bom design. Devemos construir um produto inclusivo, acessível e legível. Se tivermos que sacrificar elegância – façamos. Não devemos ter medo do óbvio, não devemos tentar reinventar convenções de web design e devemos definir bem as expectativas.
  7. Entenda o contexto. Não estamos desenhando para uma tela, estamos desenhando para pessoas. Precisamos pensar muito a respeito do contexto em que essas pessoas usarão nossos serviços. Eles estão em uma biblioteca? Eles estão no telefone? Eles estão realmente familiarizados com o Facebook? Eles já usaram a web antes?
  8. Construa serviços digitais, não websites. Nosso serviço não começa e termina no nosso site. Pode começar em um mecanismo de busca e terminar em um dos nossos escritórios. Nós precisamos desenhar para isso, mesmo que não tenhamos controle total sobre a experiência.
  9. Seja consistente, não uniforme. Sempre que possível use a mesma linguagem e os mesmos padrões de design – isso ajuda as pessoas a se familiarizarem com os nossos serviços. Mas quando isso não for possível, precisamos ter certeza que nossa abordagem é consistente. Dessa forma, os usuários terão uma maior chance de deduzir o funcionamento daquilo que eles precisam usar.
  10. Faça coisas abertas, isso só melhora a situação. Devemos compartilhar o que estamos fazendo sempre que possível. Com colegas, com usuários, com o mundo. Compartilhe o código, compartilhe o design, compartilhe as ideias, as intenções e as falhas. Quanto mais gente olhando para o serviço, melhor ele se torna.

16 dicas para uma boa User Interface

Dicas para uma boa interface

Tente agrupar funções similares ao invés de fragmentar a UI

Segundo o GoodUI.org, essas são as 16 dicas para uma boa interface:

  1. Tente um layout de uma única coluna ao invés de múltiplas colunas.
  2. Tente dar um presente ao invés de tentar fechar negócio logo de cara.
  3. Tente agrupar funções similares ao invés de fragmentar a UI.
  4. Tente fazer seus argumentos virem de outras pessoas, ao invés de falar de você mesmo.
  5. Tente repetir o seu call-to-action ao invés de mostrar uma única vez.
  6. Tente distinguir o que é clicável e selecionável do que não é.
  7. Tente recomendar ao invés de mostrar várias opções com o mesmo peso.
  8. Tente deixar o usuário desfazer, ao invés de pedir confirmação para tudo.
  9. Tente focar em um público principal, ao invés de tentar agradar a todos.
  10. Tente ser direto ao invés de ser indeciso.
  11. Tente mais contraste ao invés de similaridade.
  12. Tente mostrar onde seu produto é feito, ao invés de deixá-lo genérico.
  13. Tente menos campos de formulários, ao invés de querer pedir tudo de uma vez.
  14. Tente mostrar as opções, ao invés de escondê-las.
  15. Tente sugerir que há rolagem na página ao invés de deixar ela escondida.
  16. Tente manter o foco ao invés de afogar o usuário em links.

O projeto foi criado por Jakub Linowski, um designer que trabalha especificamente com otimização de performance de interfaces.

Para ver a lista completa com exemplos ilustrados: GoodUI.org.

Leia também: 10 dicas básicas sobre Responsive Design

Flat or not?

Flator Not flat

We need to move beyond the superficial conversation about styles and incremental adjustments to boldly invent the next frontier of interface design. by John Maeda @ Wired

Ok, concordamos com isso, mas nem só de conteúdo, clicks, contexto, mapas e afins vive o arquiteto de informação. Visual também conta no nosso cinto de utilidades, e ultimamente tem caído na boca do povo o tal Flat Design.

Flat or not?

Falamos aqui no blog do tal do Flat Design. Mas o que mais se fala é sobre a nova cara do iOS7, que veio com todas as piadas como anexo. Calma, eu não disse que esse estilo iOS7 é o tal do flat, mas que ele segue uma linha parecida e que ele está sendo super (mal) falado – o que nos faz pensar a respeito. Neste post há uma linda explanação sobre o assunto.

Acredito que a grande questão está (sim) na comparação do que era o visual do iOS e no que está se tornando e não somente “how it works”. Uma palavra feia mas que tem um resultado lindo é o tal do Skeuomorphism (explicando de maneira simples, é a representação gráfica de algo físico com todas as características como textura, volume, forma, luz e etc.)

Pessoalmente o que me encanta nas aplicações para o iPad (por exemplo) são as interfaces lindas, cromados, couro, vidro, coisas reais no mundo digital com funcionalidades excelentes. Por exemplo o visual do Find My Friends.

Acho muito bacana ver minha agenda ou painel real dentro do meu tablet.

Mas ao mesmo tempo adoro quando o Google me apresenta um layout simples como o menu da câmera no Android Jelly Bean:

Google

Opa, mas aí já se percebe outra coisa: o que importa nessa etapa? Uma beleza magnífica ou uma utilização eficiente (sem ser feio, claro!).

Chegamos no ponto certo.

Realmente “o que importa” é muito mais do que “como se apresenta”, e por isso vamos jogar algumas coisas sobre estes dois estilos gráficos.

Seguem pontos positivos e negativos:

 Skeuomorphic

(Não vamos tão fundo, mas alguns dizem que pode ser Realismo)

Prós:

  1. Facilmente reconhecido. Remete a algo real que já conhecemos no “mundo real”.
  2. Apelo visual (agradabilidade) mais acentuada.
  3. Captura a atenção do usuário para os detalhes e a realidade, trazendo assim, um experiência mais prolongada e agradável.
  4. Os designers amam tudo que o skeur pode oferecer. Afinal, é lindo mesmo.

Continuar lendo

Pequenas mudanças de design não existem

Pequenas mudanças de design

Conta o time da Intercom em seu blog sobre quando eles decidiram alterar a quantidade máxima de caracteres que um usuário poderia submeter na hora de escrever um review sobre um álbum em um site de música.

Parece uma mudança simples, certo?

Colocar um limite de 140 caracteres na hora de escrever um comentário.

Só parece.

Agora dá uma olhada na lista de questões, preocupações e novas decisões que precisaram ser tomadas depois que surgiu a ideia de fazer essa primeira mudança:

  • O que acontece quando o review tem mais de 140 caracteres? Nós simplesmente bloqueamos a digitação, ou mostramos uma mensagem de erro pro usuário?
  • Se mostramos uma mensagem de erro, onde ela aparece na interface?
  • O que diz a mensagem de erro?
  • Quem vai escrever a mensagem de erro?
  • Como nós explicamos para o usuário o porquê de estarmos limitando a quantidade de caracteres?
  • Qual vai ser a aparência dessa mensagem de erro? Esse estilo de mensagem já existe? Se não, quem fica responsável por desenhá-la?
  • A mensagem é controlada server-side ou client-side?
  • Se for client-side, quem escreve o JavaScript? O JavaScript mostra o mesmo tipo de mensagem que o código server-side?
  • Se não, qual o novo estilo?
  • Como esse estilo se comporta sem JavaScript?
  • Como fazemos com que essa nova validação de 140 caracteres seja tanto client-side quanto server-side?
  • Nós colocaremos algum contador de caracteres?
  • Quem vai desenvolver esse contador de caracteres?
  • Nós podemos usar alguma solução pronta disponível na web?
  • Se sim, quem vai testar essa solução nos browsers que damos suporte em nosso site?
  • Onde o contador de caracteres será exibido na tela? Qual a aparência desse contador?
  • O estilo permanece sempre o mesmo ou ele muda quando o contador chegar a zero?
  • Quando chegar a zero, bloqueamos a digitação ou começamos a mostrar números negativos para que o usuário saiba o quanto ele passou da conta?
  • O que acontece quando ele cola um texto na caixa que é maior do que 140 caracteres? Nós deixamos ele editar depois, ou simplesmente cortamos o texto no meio? Ou exibimos uma mensagem de erro especial nesse caso?
  • E o que acontece com os reviews que já foram escritos no site e já possuem mais do que 140 caracteres?
  • O review vai aceitar caracteres especiais?

Como eles mesmos dizem no blog, “como UX Designer, você precisa ter um bom entendimento dessas implicações todas que vêm junto com a sua ‘pequena decisão de design'”.

E a lição do ano, para encerrar o post:

Scope grows in minutes, not months. Look after the minutes, and the months take care of themselves.

Pequenas e corajosas decisões de design

Snapchat

O Snapchat (aquele aplicativo que envia mensagens com fotos e vídeos que se auto-destróem depois de alguns segundos e que já é sensação entre os usuários mais jovens) resolveu acabar com aquela história de ter um “modo fotografia” e um “modo vídeo” na hora de capturar algo com a câmera do smartphone.

O botão para capturar é um só: esse grande círculo transparente na parte inferior da tela.

Você toca uma vez para tirar uma foto.

Você toca e segura para capturar um vídeo.

Continuar lendo

O que o botão Voltar do iOS7 perdeu

Botão "Voltar" do iOS

“Se você me perguntar, aquele botão Voltar, que esteve com a gente desde o lançamento do iPhone, foi o melhor design de botão Voltar de todos os tempos. A maioria dos botões Voltar, como aqueles nos navegadores desktop, são simplesmente um ícone em formato de seta com um texto que diz ‘Voltar’. Se você quer saber para onde o botão vai te levar, você normalmente precisa pressionar e segurar para que ele revele uma lista de páginas que você visualizou recentemente.

O botão Voltar pré-iOS7 consolidava essas coisas todas em um único shape que termina em formato de seta do lado esquerdo, e abrigava uma descrição em texto de onde esse botão levaria você. Ele praticamente fazia 3 coisas em um único elemento. Primeiro, ele visualmente sinalizava que você se moveria de volta, então mesmo que você não lesse o texto no meio dele você ainda reconhecia a função daquele botão imediatamente. Segundo, se você lesse o que ele dizia, ele ainda te dava o título da tela anterior, sem precisar que você pressionasse e segurasse o botão para revelar essa informação. E finalmente, ao contrário do novo botão Voltar do iOS7, ele era explícito em relação a que área você poderia pressionar e onde; a área de toque era visivelmente delimitada pelo formato do botão, e fazia isso sem precisar empurrar o título da página atual para a direita (que frequentemente acontece no iOS7).

E tão importante quanto,o visual do antigo botão Voltar era agradável. O lado esquerdo do botão não era uma seta convencional – os ângulos dessa seta eram levemente arredondados, suavizando o formato do elemento o suficiente para sugerir que o processo de Voltar seria suave e instantâneo.”

Traduzido daqui.

Sobre os detalhes que muita gente esquece de notar.