Arquivo do autor

Fixe o tempo e os custos e reduza o escopo

Segunda-feira, 22 de junho de 2009 por Joca

Recentemente Dov Bigio, Gerente de Produtos de Telecom da Locaweb, postou em seu blog sobre “O triângulo dos projetos“, que explica que dadas as variáveis de um projeto (qualidade, custo e prazo) pode-se fixar no máximo duas delas, e a terceira irá variar. Ou seja, se fixarmos prazo e custo, a qualidade poderá ser menor do que a esperada. Ou se fixarmos a qualidade e o custo, o prazo poderá ser maior que o esperado. Nunca conseguiremos fixar as três variáveis de um projeto.

O pessoal da 37signals prefere manter a qualidade sempre fixa (num patamar alto) e substituiu a qualidade pelo escopo no triângulo dos projetos. Eles também recomendam que devemos sempre fixar prazo e custo de um projeto e sempre flexibilizar o escopo.

Vou explicar como isso faz sentido usando como exemplo um projeto recente que tivemos aqui na Locaweb, o projeto de reescrever o site.


locaweb-antes

site da Locaweb antes do projeto de reescrever o site

Em novembro de 2008 decidimos que já havia passado da hora de termos um novo site que estivesse mais em linha com tudo o que temos estudado sobre experiência do usuário, design centrado no usuário, arquitetura da informação, design de interação e conceitos de web 2.0 com maior participação do visitante do site. Decidimos também o prazo, na primeira quinzena de março de 2009 esse site deveria estar no ar. E o custo também estava fechado: não íamos contratar ou pegar empresatado de outra equipe ninguém a mais para tocar esse projeto.

Tomada a decisão, começamos a desenhar o escopo do projeto. Dentre os vários requisitos do projeto tivemos:

  • navegação simples e intuitiva
  • manter o código bem enxuto
  • aplicar SEO em todo o site
  • minimizar o uso de flash
  • design visual leve, para dar importância à informação contida nas páginas
  • rever a arquitetura de informação de todo o site, revendo todo o conteúdo

Fizemos o planejamento para 6 sprints de duas semanas cada. Numa determinada altura percebemos que não ia dar para fazer tudo para lançar na primeira quinzena de março. Ficamos então pensando se íamos aumentar o prazo ou se podíamos cortar algo do escopo desse projeto.

A entrega de uma projeto é muito importante, tanto para a equipe que trabalhou no projeto, que fica com a sensação de “dever cumprido”, quanto para o cliente do projeto, que irá usufruir dos benefícios de ter o projeto pronto. Com isso em mente, decidmos diminuir o escopo, descobrir alguma coisa que pudéssemos cortar do projeto a fim de entregá-lo no prazo. Dentre as opções de redução de escopo, escolhemos não rever a arquitetura de informação de todo o site, mas apenas das áreas mais importantes.

Com isso conseguimos entregar a tempo e os visitantes do site - principal “cliente” desse projeto - puderam usufruir de seu novo layout e de sua nova organização.

locaweb-depois

site da Locaweb depois do projeto de reescrever o site

De uma certa forma, redução de escopo e redução de qualidade são parecidos, mas têm uma diferença fundamental. Podemos reduzir qualidade de duas formas:

  • fazer tudo o que foi planejado, só que fazer mal feito, ou;
  • fazer menos do que foi planejado, só que bem feito.

Já quando falamos em redução de escopo, não damos margem para interpretação: é sempre fazer menos do que foi planejado, mantendo o trabalho bem feito. E muitas vezes quando fazemos e entregamos menos, percebemos que o menos que entregamos já é suficiente e que o produto final de nosso projeto ficou melhor com menos do que o que foi originalmente planejado.

Então da próxima vez que você pensar em reduzir a qualidade de seu projeto para poder entregá-lo no prazo e dentro do orçamento, pense se não seria melhor reduzir o escopo. Você e seu cliente poderão sair ganhando com a redução de escopo!

10 percepções equivocadas sobre UX

Terça-feira, 7 de abril de 2009 por Joca

Apresentação interessante sobre 10 percepções equivocadas sobre UX. Vale a pena ver não somente pelo slide final, que resume toda a apresentação e que reproduzo aqui para quem não tiver tempo de ver a apresentação toda, mas também por alguns insights e quadrinhos bem curiosos sobre UX.

10misconceptionsaboutux

Veja a apresentação completa (43 slides) no Slideshare.

Menus de navegação do tipo mega drop-down funcionam bem

Quarta-feira, 25 de março de 2009 por Joca

Jakob Nielsen, reconhecido especialista em usabilidade, comentou em seu último artigo que “Menus de navegação do tipo mega drop-down funcionam bem“. Resumidamente, eles permitem o acesso rápido às várias informações em apenas um clique enquanto dão ao usuário uma boa visão de todas as opções disponíveis.

Além dos exemplos do texto, gostaria de dar mais um, extraído do site da Locaweb:

mega-drop-down

Mais um exemplo de protótipo de baixa fidelidade

Quinta-feira, 12 de março de 2009 por Joca

Eu já havia falado aqui no UXBlog sobre protótipos de baixa fidelidade, protótipos ágeis, normalmente rascunhados em papel, que servem para iniciar a conversa sobre uma nova interface.

A 37signals vai mudar a cara do site e a primeira comunicação sobre o tema é exatamente um protótipo de baixa fidelidade:

preview do novo site da 37signals

Veja a comunicação completa no blog deles.

Padrão de uso e interação no New York Times

Segunda-feira, 9 de março de 2009 por Joca

O New York Times é conhecido pela criatividade de sua interface web. Recentemente me deparei com uma novidade muito bacana que me impressionou pela simplicidade. Quem já não se pegou, ao ler um determinado texto na tela do computador, marcando esse texto à medida que se lê? Pois bem, outro dia, lendo um artigo do New York Times na web, acabei fazendo aquele acompanhamento de leitura com mouse, marcando o texto à medida que ia lendo, e qual não foi minha surpresa ao ver um pequeno sinal de “?” aparecer discretamente na tela após a marcação do texto? E ao clicar na interragação, sou direcionado ao sistema de busca do New York Times com os resultados da busca pela(s) palvra(s) que marquei!

New York Times

Resultado da Busca por "pledge"

O designer de interação do New York Times percebeu um padrão de uso:

  • Pessoas costumam marcar o texto na tela à medida que vão lendo.

como foi o meu caso. Ou poderia ser um outro padrão de uso:

  • Pessoas marcam um texto durante a leitura de um artigo se querem copiar e colar esse texto para algum lugar e, normalmente, esse lugar é um mecanismo de busca.

Depois de descobrir o padrão de uso, criaram um novo padrão de interação:

  • Assim que algum texto em um artigo for marcado, dar ao leitor uma opção de pesquisa pelo termo marcado.

Padrões de uso e seus respectivos padrões de interação têm sido tema aqui do UXBlog há algum tempo. Veja mais sobre o tema em:

Calendário da Má Usabilidade

Sábado, 7 de fevereiro de 2009 por Joca

Desde 2005 a NetLife Research, empresa norueguesa especializada em UX, publica anualmente o Bad Usability Calendar, calendário com exemplos de má usabilidade.

O calendário de 2009 está abaixo:


bad-usability-calendar-2009

Vale também conferir os calendários dos anos anteriores.

Interfaces de usuário sensíveis a contexto

Terça-feira, 30 de dezembro de 2008 por Joca

Uma tendência interessante é a de interfaces de usuário sensíveis a contexto. Além dos exemplos citados nesse link, outros bons exemplos são o Basecamp:

basecamp1

Ao passar o mouse sobre o primeiro item aparecem as ações que podem ser feitas nesse item:

basecamp2

Isso deixa a interface mais leve e, ao mesmo tempo, permite invocar as ações quando necessário.

A versão 2.7 do Wordpress implementou esse conceito. Vejam a lista de posts:

wordpress1

E, ao passar o mouse sobre um título de post:

wordpress2

UX ágil

Segunda-feira, 29 de dezembro de 2008 por Joca

Recentemente li dois posts sobre como “encaixar” UX em times que estão usando metodologias ágeis. Um deles é o “Agile UX: Como trabalhar com os designers” do Guilherme Chapiewski que trabalha na Globo.com. O outro é o “Agile UX: como integrar UX e desenvolvimento” do Antonio Carlos Silveira do Yahoo! Brasil.

Como o próprio Antonio apontou bem, essa preocupação sobre como integrar UX em um time de desenvolvimento de software que segue alguma metodologia ágil existe desde o início das metodologias ágeis. Alguns posts sobre o tema:

  • Agile Development Projects and Usability: Jakob Nielsen descreve maneiras de garantir que a qualidade da usabilidade não seja ameaçada pela adoção de metodologias ágeis.
  • Agile / Scrum Product Development Process: Marty Cagan propõe uma forma de integrar UX e Scrum.
  • Extreme Programming vs. Interaction Design: Entrevista com Kent Beck e Alan Cooper sobre design de interação e XP. Nessa entrevista, chamada por alguns de “duelo de titãs”, Beck defende o desenvolvimento do design de interação de forma incremental, enquanto Cooper defende que o desenvolvimento de software não deve começar antes de todo o trabalho de design de interação ser concluído.
  • UX Agile: um blog totalmente dedicado à questão de integrar UX aos times de desenvolvimento que usam metodologias ágeis.

Aliás a busca por Agile UX no Google retorna muitas e muitas páginas dedicadas ao tema.

Um exemplo interessante é a apresentação abaixo, da Leisa Reichert que ela apresentou na Web 2.0 Expo Berlin:

Sem dúvida há várias maneiras de se integrar UX e metodologias ágeis e o correto é escolher a maneira que se adapta melhor à sua situação e disponibilidade de recursos (tempo, dinheiro e pessoas).

Contudo, queria adicionar meus 2 centavos a essa conversa. Apesar de ser importante termos especialistas em UX, pessoas que conheçam a fundo sobre arquitetura da informação, design de interação, design visual e todos os temas relacionados à experiência do usuário, acredito que UX deve ser uma preocupação de todas as pessoas do time. Não há razão alguma para o PO e os membros do time não se preocuparem com o tema e deixarem tudo nas mãos de um especialista. E se esse especialista um dia não estiver disponível? Se ele estiver ocupado cuidando de outras coisas? Ou mesmo se não tivermos um especialista em UX no time?

Não estou querendo dizer que UX não é um tema complexo, que requer muito estudo e prática, mas acredito que todos nós devemos conhecer os conceitos básicos de UX.

Vou citar duas situações exemplo que ilustram bem a importância de todo o time se preocupar com UX:

  1. Feedback: imagine que você tem em sua aplicação uma determinada função que não é executada na hora e que pode levar até 2 horas para acontecer. Na interface você implementa o comendo que executa essa função só que não informa o prazo. O usuário certamente vai se perguntar o que aconteceu, se a função foi de fato executada. Um solução é avisá-lo desse prazo logo após o comando ser invocado. O ideal é avisar antes mesmo de ele invocar o comando que executa a função.
  2. Opções: imagine que você está desenvolvendo um formulário de pagamento com opções de pagamento por cartão de crédito. Você recebe o protótipo com um select que permite escolher entre Amex, VISA e Mastercard. Você implementa esse protótipo. Na hora de colocar em produção você recebe a informação de que inicialmente o sistema só irá aceitar Mastercard. Você edita o select e remove as outras opções. A sua interface vai ficar com um select de uma opção só! O correto aqui seria remover o select enquanto houver uma opção só.

Ou seja, não é necessário ser um especialista em UX para ajudar no desenvolvimento e melhoria de UX dos sistemas que seu time cuida. Leia, estude, informe-se, afinal conhecimento nunca é em excesso!

Protótipo: primeira impressão

Sexta-feira, 26 de dezembro de 2008 por Joca

A palavra protótipo vem do grego protos (primeiro) + typos (impressão) e é importante que usemos os protótipos de UX como primeira impressão de nossos produtos e sistemas, como sugere a origem da palavra.


If I can’t picture it, I can’t understand it

Albert Einstein

Na maioria das vezes que pensamos em protótipos de sistemas web, pensamos em protótipos que tenham alguma fidelidade ao produto final e que, se possível, sejam interativos para que possam ser usados em testes de usabilidade.

Existem várias ferramentas para se fazer protótipos. Algumas das mais conhecidas são:

Mas antes de se fazer um protótipo interativo fiel ao produto final, podemos fazer um rascunho de protótipo, algo que sirva como ferramenta para discussão sobre o sistema. E para fazer esse tipo de protótipo não há ferramenta melhor do que lápis e papel! É barato, rápido e muito fácil de usar!!!

Termino esse post com alguns exemplos de protótipos rascunhados no papel, para dar idéia de quão poderosa é essa ferramenta.


Utilidade x usabilidade

Segunda-feira, 15 de dezembro de 2008 por Joca

Fonte: http://flickr.com/photos/jevolella/437838621/

Se facilidade de uso fosse o único requisito, estaríamos todos usando triciclos.

Douglas Engelbart, inventor do mouse

Essa é para não esquecermos que além da usabilidade, devemos sempre pensar na utilidade do que estamos desenvolvendo.