Experiência do Usuário (Locaweb)

Recentemente precisei fazer uma pesquisa com ex-clientes de um produto da Locaweb, pois gostaríamos de saber por que eles haviam deixado de usá-lo. Eu tinha um problema nas mãos, pois ex-clientes não costumam falar. Eles estão frustrados, furiosos ou simplesmente não lembram mais.

Como eu poderia motivá-los a responder uma pesquisa online?

Decidi abordá-los de forma pessoal e informal. Primeiro, no e-mail que convidava-os a participar do questionário, em momento algum citei o termo “pesquisa”. E mais: apresentei-me, dei meu nome e um e-mail para maiores informações, disse o que fazia na Locaweb e por que estava entrando em contato. Então pedi que eles respondessem às perguntas publicadas em uma página do site. A idéia foi me comunicar com eles como uma pessoa que trabalha na Locaweb e que gostaria realmente de receber ajuda, fazê-los entender que não era um setor de atendimento que faz pesquisas de satisfação.

Dusty Users

Isso coincidiu e fechou com as idéias que li no livro “Designing the moment“  (Robert Hoekman Jr.) sobre “Dusty Users” ( clientes que cadastram-se para usar um serviço, mas não vão adiante).  Entre as soluções propostas para resgatar a atenção desses usuários, o autor fala sobre o tom amigável e bem humorado com que se pode abordar esses clientes e obter informações.

“So what do we do about this as designers? If our goal is to keep users interested and engaged what can we do to nudge these sleepers awake and get them moving again? (…) The things that really make us pay attention are personal. (…) they are personal messages focused around our needs that create a genuine connection”

“Most important, the messages we send out should be written using a human voice, not with stiff, corporate marketing fluff filled with buzzwords and catch phrases. These messages should be conversational. They should be focused entirely on the recipient, not on us.”

E, casualmente, logo depois da pesquisa enviada recebi newsletters de dois serviços que havia assinado por curiosidade, e que agora estavam me enquadrando como uma dusty user. Vejam o exemplo do Usabilla.com:

Hello,

Not so long ago you’ve created an account at Usabilla.com.
I’m very curious if you’ve already been able to set up your first test and would love to hear about your experiences.

We’re currently running a large number of very exciting test cases for a variety of clients (see http://usabilla.com/references ). We’ve also been working on different demo cases to give you some ideas on how you could use Usabilla for different types of usability tests. You can find an overview of these cases at our blog: http://blog.usabilla.com/?cat=87 . We recently started a Facebook group, which we would like to use to discuss news, demo cases, and to learn from your stories: http://bit.ly/usabillafb .

Please let me know if you got any questions, tips, ideas, or need help to set up a test.

Kind regards,

Paul Veugen
Usabilla.com

Resultados

Ok, e sobre os resultados? Foram ótimos. A participação na pesquisa correspondeu a 7,8% do total de e-mails enviados com sucesso e a 60% dos cliques únicos no link da pesquisa. Isso ficou acima do que esperávamos em função das características do perfil convocado e também ficou acima da média das nossas outras iniciativas em pesquisa. Vejam o gráfico com o percentual de cliques no link da pesquisa (em relação ao total de visualizações únicas da mensagem):

Não ignore o feedback!

Outro resultado interessante, e que toca num ponto importante sobre esse tipo de abordagem: recebemos mais de 200 e-mails válidos (anti-spam e auto-reply não foram contabilizados) com clientes expondo seus motivos e agradecendo pelo contato. Esse feedback é importante, pois traz dados qualitativos sobre a questão da pesquisa. Porém, uma vez que você se apresenta aos seus clientes de forma tão próxima, você deve comprometer-se a atendê-los se eles solicitam a tréplica do contato.

Pense, primeiramente, se você terá tempo para ler as mensagens enviadas (Dica: programe uma hora do seu dia de trabalho para ler os e-mails e respondê-los). Considere que alguns (ou muitos) clientes verão nesse contato uma possibilidade de suporte do produto. Se pedirem ajuda, encaminhe as mensagens para a equipe responsável pelo suporte e informe a origem do contato. Se possível, envie você mesmo um e-mail respondendo que encaminhou o pedido ao suporte e que assim que possível a pessoa será atendida. Se for algum tipo de ajuda que você mesmo pode prestar, responda e agradeça.

De qualquer maneira, não deixe que os clientes percam a fé no seu contato, não utilize a abordagem pessoal como um método vazio. Faça isso porque você se importa com a opinião dos usuários do seu produto, porque se importa com eles.

Boa sorte nas pequisas!

Com o objetivo de medir a eficiência das interfaces e sistemas, utilizamos inúmeras técnicas de avalição, entrevistas e testes de usabilidade. Mas sabemos que nem sempre um projeto tem tempo e verba suficientes para aplicarmos todos esses métodos.

Um dos recursos que podemos utilizar como um guia de boas práticas desde a fase de desenvolvimento da interface são as 8 Regras de Ouro de Ben Shneiderman e as 10 Heurísticas de Nielsen, normalmente usadas como referência em técnicas de avaliação.

Jacob Nielsen descreve a avaliação heurística (uma das técnicas de avaliação) como um método rápido, barato e fácil de avaliar o design de uma interface. Este método deve dispor de 3 a 5 especialistas que farão suas avaliações individualmente, que depois serão comparadas gerando um relatório. Os problemas encontrados serão classificados em níveis de gravidade e tabulados. Dessa forma é possível conseguir uma visão geral dos problemas mais graves e que devem ser corrigidos prioritariamente.

Para ganharmos tempo e adotarmos um padrão de qualidade, podemos adotar esses princípios desde a fase em que estamos desenhando os fluxos, interfaces e interações. Certamente o produto será muito mais eficiente ao cliente e, ao mesmo tempo, poupará inúmeros ajustes que só seriam descobertos na fase de avaliação.

Abaixo, seguem as 8 Regras de Ouro de Ben Shneiderman e as 10 Heurísticas de Nielsen. Baseado nelas, você pode refinar seu próprio checklist para desenvolvimento ou avaliação e ter entregas rápidas com qualidade.

8 Regras de Ouro de Ben Shneiderman

1. Mantenha a consistência
Sequências consistentes de ações devem ser usadas em situações similares. Use terminologia idêntica em prompts, menus e telas de ajuda. Comandos devem ser utilizados da mesma maneira ao longo da interface.

2. Ofereça atalhos aos usuários experientes
Ao mesmo tempo que a frequência de uso de uma interface aumenta, o desejo do usuário é reduzir o número de interações e aumentar o compasso da interação. Abreviações, teclas de função, comando ocultos e facilidades de macros ajudarão o usuário mais experiente.

3. Ofereça feedbacks informativos
Para cada operação do usuário deve haver algum tipo de feedback do sistema. Ofereça respostas discretas quando as ações são frequentes ou de menor importância e respostas com maior prioridade para ações incomuns ou mais importantes.

4. Apresente as etapas do processo
Sequências de ações devem ser organizadas em grupos com início, meio e fim. O feedback informativo ao completar um grupo de ações dá ao usuário satisfação de realização, senso de distinção e uma indicação que o caminho é claro para se preparar para o próximo conjunto de ações.

5. Ofereça uma forma simples de correção de erros
Tanto quanto possível, o design do sistema não deve permitir que o usuário cometa erros graves. Se um erro for cometido, o sistema deve ser capaz de detectar e oferecer um mecanismo simples e compreensível para a solução.

6. Permita fácil reversão de ações
Esta funcionalidade diminui a ansiedade, desde o momento que o usuário toma conhecimento que um erro grave pode ser desfeito. Isso potencializa a exploração de funções desconhecidas. As unidades de reversibilidade podem ser de uma única ação, de uma entrada de dados ou uma sequência completa de ações.

7. O controle do sistema é do usuário
Usuários experientes desejam ter a noção de que controlam o sistema e este é que responde aos seus comandos. O sistema deve ser projetado para deixar os usuários como iniciadores das ações ao invés de reagentes.

8. Reduza a carga de memória curta do usuário
Este princípio está relacionado à limitação humana de processamento de informação na memória de curta duração. O sistema deve ser projetado para que haja o menor esforço possível do usuário em memorizar ou relacionar elementos na interface.

Heurísticas de Nielsen

1. Visibilidade do status do sistema
O sistema deve manter o usuário sempre informado sobre o que está acontecendo através de um feedback em tempo real.

2. Correspondência entre o sistema e o mundo real
O sistema deve usar a linguagem e modelo mental do usuário e não ser orientado a estrutura do sistema.

3. Liberdade e controle do usuário
Usuários frequentemente cometem erros e precisarão ser capazes de reconhecerem ‘saídas de emergências’ para se recuperarem de estados indesejáveis.

4. Consistência e padrões
Em ações e contextos iguais use as mesmas palavras, ícones e comportamentos. Facilite o reconhecimento do usuário.

5. Prevenção de erros
Mais importante que uma boa mensagem de erro é um design cuidadoso que evita o problema. Em ações como a de exclusão de um arquivo, por exemplo, forneça uma mensagem de confirmação antes da ação ser executada.

6. Reconhecimento ao invés de memorização
Evite a sobrecarga de memória do usuário. Forneça informações contextuais para que cada ação não precise de informações que estão em outro ponto do sistema.

7. Flexibilidade e eficiência de uso
Forneça atalhos para usuários experientes que agilizem o uso deste perfil, mantendo a facilidade para usuários leigos.

8. Estética e design minimalista
O diálogo do sistema com o usuário não deve conter informações desnecessárias. Mantenha apenas as informações úteis, diretas e claras.

9. Ajude os usuários a reconhecerem, diagnosticarem e recuperarem-se de erros
As mensagens de erro devem ser claras a ponto de indicarem o problema e sugerirem uma solução.

10. Ajuda e documentação
Embora o melhor é o usuário ser capaz de usar o sistema sem necessidade de ler a documentação, é necessário fornecer ajuda documentada em caso de necessidade. As informações devem ser facilmente encontradas, descreverem passos de forma clara e não serem extensas demais

Jason Zimdars - 37Signals

Jason Zimdars ou apenas JZ trabalha como visual designer e front end developer na 37Signals. (uma empresa americana que desenvolve aplicações web para gerenciamento de projetos. Com aproximadamente 3 milhões de clientes, são os criadores de vários produtos de sucesso tais como: Basecamp, Backpack, Highrise e autores do livro: Getting Real) (clique aqui para ver em português)

1)Hey JZ, first of all, I’d like to thank you for taking the time to give us this interview and would like you to tell us about yourself, your life as a professional designer, and the “paths you’ve traveled down” to get where you are. (We also know that you’ve been a designer since your childhood, doing more artistic design earlier and now more… psychological design, since we’re talking about User Experience )

Thanks, it’s good to talk with you. As you mentioned I’ve always been interested in art and design — and technology. I feel like I grew up at a very interesting time. I’m old enough to remember the days before personal computers, but I’m still able to experience the amazing things we can do with technology today and use them in my career. By growing up when I did, I have a very fundamental relationship with technology. I dabbled with art and programming on very basic personal computers. I was able to learn HTML before WYSIWYG editors existed. Having that understanding of how these things work is important to me — I can’t imagine being part of the next generation for whom the computer has always been a part of their lives, but it’s just sort of this magical box. Sure kids in college today have tremendous advantages, but they may never get a chance to look under the hood like I did.

I was an “art kid” growing up and even in college was in a very traditional art program. Drawing, painting, ceramics; even the graphic design classes were largely traditional — we hand-drew letterforms, cut designs from paper and painted swatches. But this was also the time when the internet was blossoming. So, with a self-motivated interest in technology I explored computers and the web. Heck, I even talked a painting professor into letting me paint frames of an animation in class, then sequence them with Flash for a project.

Naturally, when it came to my professional career, I stuck with what I knew and liked best. That has always been human-computer interface. I think you’re going to do the best work when you do what you like and what interests you. I don’t have specific education or training in user experience, but I’m a pretty good user. They say the best training for writing is reading and I believe the best way to learn to make great software is to use it. Not only use software, but pay attention to what works, what doesn’t, what was unexpected, what could be better. Years of experience as a user helps you develop a feel for user experience that I doubt a school or book could teach you anyway.

2)How’s your creative process, from start to finish?

Design always begins on paper for me. My sketchbook is where I work out my ideas. I like that with paper I can quickly try a lot of variations and have a record to return to later. Once I’ve got an idea or two that I think is worth moving forward with, I try to get into some kind of mock-up where I can see it in as real a form as possible. Those mock-ups can be static comps or be right inside the application using mock functionality. But the idea is to go from paper to the browser as soon as you can.

Once in the browser it’s easier to see things you couldn’t work out on paper or in Photoshop. From there it becomes a process of iterating just going over and over it with small improvements until you have something really good.

3)Paper prototypes – do they really work? You recently “fired photoshop” from your life, how does that feel? Don’t you miss it even a little?

Well, I wouldn’t say that I “fired” Photoshop, but I have definitely changed the way I use it. Before joining 37signals, I worked a lot on client-driven websites. In those cases the Photoshop comp was our contract, we never proceeded forward with a website or application until we had approved comps. While this approach certainly ensured that we had a solid direction moving forward, it didn’t allow the design to continue to evolve and grow as we moved into code.

Even before joining 37signals, I had begun exploring the idea of working more directly in code and not in Photoshop. I noticed that whenever I designed for myself, I always started with mark-up and layered CSS and graphics on top of it. Even when you’re working from a comp there are things you can’t see until the design is in the browser. There can be awkward interactions that aren’t visible until you can click them. A static comp is just too illusionary to be the gospel for your design. So working out my ideas in the browser became my preferred way of working.

At 37signals we really believe in the Getting Real methods and part of that is making our work real. Sure, I might jump into Photoshop to quickly try a design idea that might take too much time or require too many code changes to see in code, but for the most part we try to work in the browser, with real code that we can click and resize and truly feel.

Most of the time we communicate ideas with each other with simple sketches and then jump right into the apps to try them out. Photoshop only comes into play when it’s a faster way to see and evaluate an approach.
Do I miss it? Not really. I still use Photoshop plenty, but it’s just another tool. It’s nice to not be making comps just for their own sake. The work that I’m excited about is in the browser so the sooner my process gets me there, the better my work is.

4)What tools do you use to find User Experience issues? Do you do usability testing? When? How often?

There aren’t any specific tools or tests that we use and yet we are constantly evaluating the usability in everything that we do. Its is rare that a day goes by when we aren’t working on something in our apps that could be better, be it copywriting, design, or customer service. Ease of use, clarity, and pure enjoyment are things that we expect of our products and every member of the team is always working to make sure we meet our standards and continue to improve them. This isn’t just the realm of designers, at 37signals everyone is involved in using, supporting, and improving our products. Programing, customer support, designers, right up to the partners that run the company; everyone is always keeping an eye on usability.

5)Working in a company that has customers around the world, do you have UX problems that don’t affect Americans, but affect Brazilians, for example? How do you solve this kind of problem?

Many of the design considerations we make have to do with copywriting and units of measure. There are subtle differences in the way US and other countries expect to see dates and times, in particular. This is an area where we’re still improving. Right now we’re fortunate that our customers are primarily English speaking, but I’m sure that will change as we consider localization and experience growth outside North America and Europe.

6)Where do you find inspiration?

Lots of places, but no place in particular. I don’t really seek inspiration, but I try to pay attention when it finds me. The things that I appreciate in the work of others are sincerity, clarity, beauty — the little things that seem clever, creative and make them enjoyable. You can tell when a product is made by someone who really loves it and truly wants people to love it, too. I look for those little moments in products, movies, music, whatever, where you kind of connect with the object. I try to imagine the thought that went into it and how that touch was created. It is a lifetime of experiencing these little moments that help me make them for others.

7)What are your favorite websites, and why?

I tend to visit sites more for their utility than simply for the sake of their design so I appreciate websites that work well and get me in and out quickly.

I really like CNN.com’s article pages. The tabs for media content are nicely done and the “story highlights” at the top of each article are a tremendous innovation. Many times that’s all I need to get what I need from a story.
I love the design and general spirit of Etsy.com. I have a lot of respect for people who make things with their hands.
I’m not a big fan of design galleries, but siteinspire.net stands out as one that truly has a voice. It is well designed and impeccably curated.
I can’t imagine shopping without Amazon.com. I love some of the stuff the guys are doing at Behance. Very nice, clean design. Threadless is another favorite — great design, amazing community.

Thanks a lot for this interview JZ. The closing comments are up to you…

No, thank you! I enjoyed talking with you and I hope some of this is interesting to people out there. If I had to sum it all up, I’d just encourage everyone to keep learning, keep growing and always try to get better. So many things all around us can be better and design has a huge opportunity for impact in places you might never expect.

Faça o mínimo de coisas surpreendentes, é o que diz essa regra. E o “surpreendente” aqui é no sentido de “coisas não esperadas”, ou seja, que não responde da forma que a pessoa acha que deveria responder. Esta regra está embasada no fato de que seres humanos só conseguem prestar atenção em uma única coisa por vez (por mais que nós queiramos saber/ler/ver tudo ao mesmo tempo agora!!) e comportamentos inesperados em uma interface foca a atenção do usuário em um único ponto, mais que na tarefa completa a qual esse ponto pertence.

Interfaces mais fáceis de usar são aquelas que demandam pouco ou nenhum aprendizado do usuário, ou seja, aquelas que efetivamente se encaixam no que seus usuários já sabem, em modelos mentais pré-existentes (pausa: conhecer a sua audiência é um ponto importante aqui) . O melhor, se possível, é não projetar um modelo de interface totalmente novo, mas sim seguir padrões de design e interação bem conhecidos e testados.

Mas cuidado, isso não significa que o desenho de uma interface deva ser uma tarefa mecânica e conservadora, sem possibilidades de inovação. Inovação tem sim o custo do primeiro contato do usuário com uma nova forma de interação, porém existe formas melhores de fazê-la. Não inove em funcionalidades que o usuário tem pouca disposição para aprender a usá-las, por exemplo.

Recentemente li um post interessante do Jeff Atwood que dá algumas dicas de como ajudar seu usuário a usar sua aplicação de forma correta - ou como treinar seu usuário.
A idéia central do post é:

Torne as coisas corretas simples de fazer e as erradas horríveis de fazer

Segundo Jeff, ao deixar certas funcionalidades fáceis de usar você estará recompensando usuários que têm o comportamento que você deseja. Ao mesmo tempo, escolhendo intencionalmente não deixar algumas funcionalidades simples você estará desencorajando usuários com comportamento não desejado.

Um caso interessante de uso dessas idéias é a edição do registro do Windows. Por se tratar de uma operação de risco para o sistema operacional, geralmente os acessos ao registro são feitos por programas de instalação/remoção de aplicativos que usam wizards para guiar o usuário pelo processo, oferecendo configurações padrão para que o usuário tenha que tomar poucas decisões. Na maioria das vezes, o usuário nem mesmo sabe que o registro foi editado. Porém, se o usuário desejar editar manualmente o registro, a interface oferecida é muito pouco amigável - o que sugere que talvez não seja uma boa idéia realizar essa operação.

A conclusão de Jeff é que utilizando conscientemente essas técnicas - recompensar seu usuário com simplicidade e propositalmente deixar complexidade onde desejado - você estará devidamente treinando seus usuários no uso de sua aplicação.

A Wordpress.org anunciou no blog que em breve convocará designers  para contribuirem com wireframes e especificações de tarefas a serem disponibilizadas na interface administrativa do sistema.

Errata: A WordPress.org  convocará designers para criar elementos gráficos para a interface do sistema e, para isso, dará acesso aos wireframes e especificações criados pelos desenvolvedores da organização.

Inicialmente os designers  poderão contribuir criando elementos de interface mais simples, tais como botões ou menus.  As demandas são geradas a partir do WordPress Trac, um sistema colaborativo de monitoração e discussão sobre bugs e melhorias de interface do gerenciador de conteúdo.

A participação dos designers  no desenvolvimento de fluxos mais complexos, “tais como temas para o admin ou novos processos de upload”, ocorrerá num segundo momento e as soluções serão escolhidas através de concursos.

A idéia das novas formas de contribuição ao sistema veio depois do sucesso do Icon Design Contest. O concurso recebeu a participação de designers de diversos países e o vencedor teve seu conjunto de ícones  aplicado à mais recente versão da interface administrativa.

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:

Veja a comunicação completa no blog deles.

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:

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

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:

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

No post anterior o Marcos falou sobre a importância de disponibilizar as informações corretas e na medida certa para que potenciais usuários de aplicações online se tornem clientes efetivos.

Páginas de cadastro eficientes demandam boas práticas de usabilidade. No entanto, as questões em torno do envolvimento do cliente com a aplicação são mais de aspecto motivacional, visto que, num processo ideal, o formulário é o último passo a ser apresentado nesse fluxo de adoção.

Então como motivar o visitante interessado a assinar o serviço?

A seguir detalharei duas técnicas sugeridas por Joshua Porter, ministrante do seminário Design for Sign-Up. O post original com exemplos mais detalhados pode ser lido em inglês aqui.

1 - Seja simples: a técnica do Jornalismo

Assim como os jornalistas se baseiam num conjunto de perguntas básicas para escrever uma notícia, utilize um conjunto de perguntas-guia cujas respostas montam um esquema informativo completo para que as pessoas adotem a aplicação:

- O que é isso? O que isso faz?
- Como isso funciona? Por onde começar? Como se beneficiar disso?
- Por que isso é importante? Por que isto torna melhor a vida das pessoas?
- Quem usará isso? Para quem é?
- Quando poderá ser usado? Posso acessar a qualquer momento?
- Onde poderá ser usado? Tem uma versão mobile?

Detalhando:

Descreva O QUE é sua aplicação:

Mostre claramente o que a sua aplicação faz e para que ela serve. Seja simples e direto. Quanto mais complicada for a maneira como você apresenta as funcionalidades e vantagens do seu serviço, mais complicado ele será aos olhos do seu público.

Exemplos:

Página de abertura do Firefox 3

Blogger

Mostre COMO funciona:

Mostre, através de gráficos ou vídeos, como o sistema funciona. Seja breve e, no primeiro instante, mostre apenas as informações principais. Mas não deixe de fornecer informações em profundidade para aqueles que desejam saber mais sobre o serviço.

Exemplos:

Programa de Afiliados do Submarino

Google Chrome

Explique o PORQUÊ da aplicação com características e vantagens

Explique a relevância do seu serviço apresentando as vantagens do seu uso. Apresentar as características do sistema descreve o seu produto, porém não deixa claro para os usuários o seu valor e benefícios. Faça conexões entre características e vantagens.

Exemplo:

Skype

Plaxo

Dê exemplos de QUEM está usando

A maioria das pessoas toma decisões sob a influência de outras pessoas. Então mostre de alguma forma as pessoas que já estão usando o seu serviço.

• Forneça formas de encontrar amigos que já estão usando o serviço;
• Publique testemunhais e permita que as pessoas falem do serviço;
• Defina um nicho e comunique-se com ele;
• Mostre cases de sucesso (no uso do serviço);
• Revele números e estatísticas de adoção (se eles forem altos);
• Apelo à autoridade: se alguém influente usa o seu serviço, mostre ao seu público;
• Uso hipotético: se o serviço for novo e não tiver usuários, dê exemplos de como usá-lo.

Exemplo:

Par Perfeito

Amigo Secreto

QUANDO as pessoas podem usar?

Se for gratuito, deixe claro. Se o seu produto for vendido, dê uma chance às pessoas de testá-lo sem custos. Além de deixar as pessoas satisfeitas com seu produto antes mesmo de fazê-las decidir pela compra, as versões trial costumam evocar o sentimento de reciprocidade – que faz com que pessoas lhe retribuam algo que você ofereceu a elas anteriormente.

Exemplo:

Skype

ONDE as pessoas podem usar a sua aplicação

Se a sua aplicação for especialmente interessante ao ser usada em trânsito, com dispositivos móveis, destaque esta característica para demonstrar o valor do seu serviço.

Exemplo:

Oi Paggo

2 - Reduza o atrito do cadastro

Se a técnica do jornalismo foi bem aplicada, os visitantes estão bem informados sobre o valor da aplicação e os benefícios da sua adoção. Agora é necessário reduzir ao mínimo os atritos do cadastro. Para tanto:

Não exija o cadastro até que seja necessário (Envolvimento Progressivo)

Deixe que o visitante explore a sua aplicação e até mesmo comece a usá-lo antes de se cadastrar. Quando o usuário estiver envolvido com o serviço ofereça a opção de fazer o cadastro para salvar os dados ou continuar o processo. Essa técnica também pode ser chamada de “Envolvimento Progressivo” e foi descrita por Luke Wroblewski no livro Web Form Design: Filling in the Blanks.

Joshua traz como exemplo o Netvibes. Essa aplicação permite que você configure a página inicial com os conteúdos desejados, com a organização desejada, porém os dados personalizados apenas serão salvos e acessíveis de qualquer computador se o usuário se cadastrar.

Pergunte apenas o que for necessário

…mesmo que os usuários estejam suficientemente motivados para usar a sua aplicação!

Em tese, há um tempo ilimitado quando imaginamos o processo de alguém que tem o primeiro contato com um software online até que se torne um cliente do serviço. O interessado toma conhecimento da existência da ferramenta, pesquisa mais sobre ela, conhece as vantagens e finalmente torna-se um assinante.

No seminário virtual que participei, Design for Sign-Up: How to How to Motivate People To Sign Up For Your Web App, o especialista em usabilidade Joshua Porter afirmou que temos aproximadamente 8 segundos para convencer uma pessoa sobre valor de uma aplicação online. É nesse período que temos a missão de provar o valor de nossa aplicação aos que se mostraram interessados.

O primeiro desafio, segundo Joshua, é convencer o público que se interessou pela ferramenta a realmente inscrever-se e usar o software pela primeira vez.

Para que esta barreira seja superada, devemos expor claramente os benefícios que o software pode trazer. Para isso, devemos passar pelos seguintes estágios:

• A primeira impressão em relação ao software é a grande chance de transformar um interessado em um cliente fiel ou fazer com que ele não perceba o valor da aplicação e assim não retorne;
• As dúvidas são bem maiores do que as certezas, você deve usar esta oportunidade para falar mais sobre a utilidade do software;
• O público está receptivo a usar sua ferramenta, transforme a receptividade em um efetivo uso;
• Por fim, faça com que as pessoas acreditem que usar sua aplicação é importante, elas tomarão esta decisão e iniciarão um relacionamento com você e isso é que decidirá seu futuro.

Para que a comunicação entre o desenvolvedor e o público seja positiva, tenha abordagens distintas para os variados tipos de público.

Existem pessoas que estão prontas a usar sua aplicação, neste caso facilite ao máximo eliminando problemas de usabilidade ou obstáculos na interface.

Outras estão interessadas, porém ainda não tem certeza sobre a real utilidade da aplicação. Para elas, enfatize que estão tomando a decisão certa e ofereça uma variedade de detalhes que respondam o que seu software pode fazer.

Algumas estão apenas pesquisando, mas ainda não planejam usar realmente o software. Eles querem saber detalhes para transmitir a outras pessoas. Forneça a eles uma abrangente lista de funcionalidades e detalhes de como a aplicação funciona.

Os céticos buscam provas de que a sua aplicação não serve e sim que a escolha deles atual é a melhor opção. Neste caso, o ideal é mostrar testemunhais de como outras pessoas estão satisfeitas por terem optado por seu software.

Após conhecer os possíveis tipos de público, crie uma estrutura de informações que servirá de apoio ao público interessado e que impulsione a conversão deste em usuários reais. Esta estrutura deve conter níveis de detalhamento de acordo com o interesse de quem está visitando, desde uma breve explicação até detalhes do serviço. Exiba gráficos e ilustrações do seu serviço, vídeos ou capturas de telas da ferramenta em ação. Mostre também pessoas que iniciaram o uso da ferramenta e os casos de sucesso.

Com tudo isso, você poderá comunicar claramente as qualidades do software e permitir ao interessado decidir se o software é realmente o que ele quer, responder qualquer questionamento, confirmar ou eliminar qualquer preconceito sobre a aplicação que ele tenha em mente.

No próximo post, a Gabriela explicará em detalhes como fazer a abordagem na prática.