MyDraft

Getting Real

Capítulo 12 – Precificação e Assinatura

Amostra Grátis 

Dê alguma coisa de graça para que as pessoas o notem em meio a multidão. As empresas espertas sabem que dar brindes é uma ótima forma de fisgar clientes. A Apple, por exemplo, fornece gratuitamente o iTunes para gerar demanda para o iPod.

Ofereça algum tipo de versão gratuita do seu aplicativo. Deixe as pessoas experimentarem o seu produto, a interface, a utilidade do que foi construído. Uma vez fisgados eles estarão mais propensos a aderir a um plano pago.

Divida seus aplicativos em pequenos pedaços para que possa fornecer um destes como aperitivo.

Fácil entrar, fácil sair 

Se você está fornecendo um serviço, torne o processo de adesão e cancelamento simples.

Sempre deve existir uma opção grátis para que os clientes possam experimentar o aplicativo sem ter que fornecer dados de cartão de crédito. Deixe qualquer um experimentar o seu serviço ou aplicativo gratuitamente a qualquer hora.

Crie um formulário de cadastro simples e enxuto. Não assuste as pessoas com um imenso questionário.

Os mesmos princípios devem ser seguidos no formulário de cancelamento. Não queira prender as pessoas dentro do seu produto. Também garanta que as pessoas possam levar seus dados caso queiram sair. Para isso, permita a exportação das informações em formato XML. Dar as pessoas o controle de suas próprias informações gera confiança. É melhor que seu cliente volte por confiança do que por obrigação.

Coelhinho Bobinho, Truques são para Crianças 

Evite contratos de longa duração, taxas de assinatura ou cancelamento. Não tente encontrar modos alternativos de ganhar mais dinheiro, faça por merecê-lo. 

Batendo de Leve 

Precisa dar uma má notícia ao usuário? Faça da forma mais indolor possível, usando algum tipo de aviso prévio. Os usuários são o seu ganha pão, faça-os sentirem-se valorizados.

  # Na seqüência o resumo do capítulo 13 (Promoção). 

Getting Real

Capítulo 11 – Palavras

Não Há Nada de Funcional em uma Especificação Funcional 

Não escreva um documento de especificações funcionais. Elas acabam descrevendo algo completamente diferente do produto final. Alguns motivos:

• Especificações funcionais são fantasias, não refletem a realidade. São apenas palavras em papel;
• Especificações funcionais são apenas uma forma de acalmar os ânimos. Elas nunca tocam nos pontos mais críticos do projeto ou mesmo avaliam custos. Servem apenas para que todos se sintam felizes e envolvidos com o projeto;
• Especificações funcionais apenas levam a àilusão de um acordo. O fato de um certo número de pessoas concordarem sobre alguns parágrafos não quer dizer que todos chegaram a um entendimento comum. Todos podem estar lendo o mesmo texto mas chegando a conclusões complemente distintas;
• Especificações funcionais forçam você a tomar decisões importantes com o mínimo de informações sobre o todo, quando na realidade as decisões devem ser tomadas conforme o projeto for avançando, quando você começar a enteder mais sobre o produto em si;
• Especificações funcionais geram excesso de funcionalidades, pois não há nada que o impeça de adicionar mais um tópico na lista de requisitos. No final das contas você terá uma aplicação que atenderá a uma lista de requisitos e não a seres humanos. Portanto, "desagrade a lista", agrade os usuários. Livre-se de toda e qualquer "funcionalidade de estimação";
• Especificações funcionais deixarão você "engessado". Mesmo que você perceba durante o desenvolvimento que uma determinada funcionalidade é uma má idéia, não há mais nada que possa ser feito.

Então que deve ser feito em vez de uma especificação funcional? Comece com uma alternativa mais breve, que possa transformar-se em algo real mais rapidamente. Escreve uma página dizendo o que a aplicação deve fazer. Este processo de "especificação" não deve tomar mais que um dia.

A construção da interface será a substituta da especificação funcional. Desenhe os esboços no papel e parta logo para o código HTML.

Construa uma interface que permita que todos naveguem, usem e sintam a aplicação antes mesmo de se preocupar em desenvolver o código backend. Coloque-se na pele do usuário.

Pulando a etapa da especificação funcional você mantém o custo das mudanças em baixa e a flexibilidade em alta.

Desenvolver com base em especificações funcionais é a pior maneira de se escrever software, pois trata-se de programar para satisfazer uma teoria, não a realidade.

Não Faça "Documentos Mortos"

Evitar especificações funcionais é um bom começo, mas não é tudo. Elimine do projeto toda a papelada desnecessária. Não escreva, construa! Evite a papelada, use protótipos.

Me Conte Uma História Rápida 

Sempre que faltarem palavras para descrever uma nova funcionalidade, escreva histórias, não detalhes! Não entre em detalhes técnicos ou de design.

Tudo que você precisa é de uma história capaz de iniciar uma discussão e colocar o projeto no rumo correto.

Use Palavras de Verdade 

Evite o Lorem ipsum, use texto real!

Se o site requer entrada de dados, entre com dados. Lorem ipsum não é um dado. Se o site requer um nome, forneça um nome real. Lorem ipsum não é um nome.

Não é sábio testar um sistema com lixo ou um monte de caracteres sem sentido. Não é isso que os clientes farão. Teste o sistema agindo como um cliente. Forneça informações reais e entenda os usuários.

Entender o usuário e sentir o que ele sente ao usar o sistema, irá ajudá-lo a construir uma interface melhor.

Leia o post "I hate Lorem Ipsum and Lorem Ipsum Users" no blog do Tom Smith.

Dê Personalidade a Seu Produto 

Produtos devem ser encarados como se fossem pessoas. Que tipo de pessoa o seu produto deve ser? Divertida? Educada? Séria? Relaxada? Ela deve ser lembrada como uma aplicação confiável ou entremamente segura?

Uma vez que você determine as características da aplicação, elas devem ser lembradas durante a construção do produto.

Estas características devem ser usadas para guiar a construção da interface, a escolha das funcionalidades, etc.

Cada produto tem uma "voz".

  # Na seqüência o resumo do capítulo 12 (Precificação e Assinatura).

Getting Real

Capítulo 10 – Código 

Menos Software 

Mantenha o seu código o mais simples possível. 

A melhor forma de se enfrentar a complexidade é com menos código. Em vez de tentar prever problemas futuros, lide apenas com os problemas de hoje. Não perca tempo tentando solucionar "problemas-fantasma". 

Menos código é mais fácil de gerenciar, reduz a carga de trabalho de manutenção (e uma equipe mais feliz), reduz os custos de mudança, reduz o número de bugs e significa menos suporte. Mude de idéia sem ter que mudar milhões de linhas de código. 

A escolha de quais funcionalidades incluir ou omitir também tem muito a ver com a quantidade de software.

Encoraje-se (e a sua equipe de programadores) a pensar em contra-propostas. Escreva apenas o software que precisa e nada mais!

O segredo do bom projeto de software não está em saber o que codificar. Está em saber o que não codificar.

Otimize para Felicidade 

Escolha ferramentas que estimulem e motivem o seu time (ou a si mesmo). Um programador feliz é um programador produtivo. Isto é especialmente importante quando você estiver escolhendo a linguagem de programação. 

Resumindo, sua equipe necessita trabalhar com ferramentas que eles gostem. Usamos o contexto de linguagens de programação, mas o conceito se aplica à aplicações, plataformas e praticamente tudo. Faça a escolha que deixa as pessoas felizes e você alcançará um melhor resultado.

O Código Fala 

Uma nova funcionalidade está requerendo semanas de tempo e milhares de linhas de código? Isso é o seu código lhe dizendo que provavelmente existe uma maneira melhor, mais simples de se fazer as coisas.

Gerencie Débitos 

Normalmente pensamos em débito na forma de dinheiro mas ele vem em outras formas também. Junte alguns códigos ruins que são funcionais e um design "mais ou menos" e você estará construindo débito.

Não tem problema em fazer isto de vez em quando para se chegar mais rápido ao objetivo (Getting Real Fast!), mas ainda assim você estará gerando débito. Em algum momento você precisará limpar o código e/ou redesenhar aquela tela "mais ou menos", ou seja, pagar o débito.

Assim como você separa uma parte de seu salário para pagar impostos, separe uma parte do seu tempo para pagar estes débitos, caso contrário começará a pagar os juros por isto.

Abra as Portas 

Publique dados para o mundo, via RSS, API's, etc.

Não tente prender seus usuários. Deixe que a informação flua. Garanta o acesso à informação via RSS. Ofereça API's que permitam a construção de aplicações integradas à sua.

Os RSS permitem ao usuário manter-se atualizado sobre mudanças internas à aplicação sem a necessidade de logar-se diversas vezes.

Já as API's, permitem que desenvolvedores contruam plugins adicionais à sua aplicação, o que geralmente agrega valor ao seu produto.

  # Na seqüência o resumo do capítulo 11 (Palavras).

Getting Real

Capítulo 9 – Design de Interface 

Primeiro a Interface 

Desenhe a interface antes de começar a programar. Muitos possuem a idéia de começar a programar primeiro. Isto é uma má idéia!

Programar primeiro prende você e gera custos adicionais de mudança. Desenhar antes deixa você flexível.

Outra razão para desenhar primeiro é que a interface é o seu produto. O que as pessoas vêem é o que você está vendendo.

Existem perguntas que você só poderá responder quando lidar com telas reais (Isto faz sentido? É fácil de usar?).

Desenhar antes faz com que você obtenha respostas mais cedo.

Design de Epicentro 

Epicentro é a verdadeira essência da página. Isso quer dizer que no começo você deve ignorar a navegação, menus, rodapés, cores, barras laterais, logotipos, etc.

Desenhe o que realmente é essencial.

Tudo que é essencial deve ser construído primeiro, extras em segundo. O resultado disto são telas mais amigáveis, focadas e funcionais para os clientes. Além disto, Design de Epicentro permite que você inicie o díalogo designer-desenvolvedor antes.

Solução de Três Estados 

Faça o design para os estados: Regular, Branco e Erro. 

• Regular - A tela preenchida com dados, que as pessoas vêem quando tudo funciona perfeitamente;
• Branco - A tela que as pessoas vêem quando vão usar a aplicação pela primeira vez (formulários sem dados);
• Erro - As telas que as pessoas vêem quando algo dá errado. 

O estado Regular é aonde você gastará maior parte do tempo, contudo não deixe de investir tempo nos outros estados.

A Tela em Branco 

Supere as expectativas com uma primeira experiência convincente.

Ignorar o estado Branco é um dos maiores erros que você pode cometer. Designers sempre desenham telas considerando que elas estão populadas de dados. Entretanto, o estado original da aplicação é Branco, ou seja, sem dados.

O cliente decide se a aplicação vale a pena pelo estado inicial de sua tela em branco.

A maioria dos designers e desenvolvedores subestimam este estado. Eles geralmente preocupam-se mais em testar a aplicação colocando dados nos formulários (páginas/telas).

Então o que devemos realmente considerar em uma tela em branco?

• Incluir pequenos tutoriais e caixas de ajuda;
• Dar uma foto (screenshot) de como a tela ficará quando estiver populada de dados;
• Explicar como começar, como a tela vai ficar, etc;
• Responder a perguntas-chave de novos usuários: Para que serve esta página? O devo fazer agora? Como esta tela ficará com quando estiver cheia?
• Superar expectativas, reduzir frustrações e confusões.

Primeiras impressões são cruciais. Se você falhar na criação de sua tela em estado Branco, criará impressão negativa de sua aplicação.

Torne-se Defensivo (Estado Erro)

Vamos admitir: As coisas vão dar errado online. Por isto, faça design para quando as coisas derem errado.

Não importa o quão cuidadoso você seja, os clientes sempre irão encontrar problemas.

Então como gerenciar estas quedas inevitáveis? Com design defensivo.

Procure constantemente por pontos (problemas) que causem confusão e/ou frustração aos clientes.

Lembre-se: Sua aplicação pode funcionar muito bem durante 90% do tempo, mas se o cliente se sentir abandonado no momento em que ele mais precisar, é muito pouco provável que ele esqueça disto!

Neste ponto, vale a indicação do livro "Defensive Design for the Web: How to improve error messages, help, forms, and other crisis points".

Contexto sobre Consistência 

O que faz sentido aqui pode não fazer sentido ali.

As ações devem ser botões ou links? Depende da ação. De que forma o calendário deve ser visto? Depende de onde ele será visto e quão longo será o período de tempo exibido. Devo ter links de navegação global em todas as páginas? Preciso de uma caixa de busca em todo lugar? Devo usar o mesmo rodapé em cada página? Depende!

Forneça às pessoas apenas o que importa. Ofereça a elas o que elas precisam e livre-se de tudo o que não for necessário. É melhor ser correto do que ser consistente.

Direitos Autorais é Design de Interface 

Grandes interfaces são escritas, portanto, cada palavra importa. Quando estiver escrevendo sua interface, coloque-se sempre no lugar da pessoa  que está lendo a sua interface.

Submater ou Salvar? Novo ou Criar? Pesquisar ou Consultar? Tudo isso importa!

Fale a mesma língua que sua audiência. Evite jargões técnicos. Não use palavras que a maioria das pessoas não conhecem.

Boa escrita é bom design. Ícones com nomes, campos com exemplos, instruções passo-a-passo em um processo... Tudo isto é design de interface.

Uma Interface 

Evite as telas administrativas (as telas usadas para gerenciar preferências, pessoas, etc). Elas têm a tendência de parecer lixo! Isto porque a maioria do tempo é voltado para o design de interfaces públicas (aquelas que o cliente realmente usará constantemente).

Por isto, evite as telas administrativas. Dê preferência às funções (editar, adicionar, deletar...) na interface pública de sua aplicação.

Manter duas interfaces separadas (clientes e administradores), faz com que você pague a mesma taxa duas vezes. Você é obrigado a se repetir e isso aumenta as suas chances de tornar-se desleixado. Don't repeat yourself!

Quanto menos telas, menos coisas você terá para se preocupar e melhor as coisas saem.

Leia um pouco mais sobre a filosofia DRY (Don't Repeat Yourself).   

# Na seqüência o resumo do capítulo 10 (Código).