Anatomia de uma proposta comercial de sucesso

Um estudo feito pela empresa BidSketch analisou 25.000 propostas comerciais de agências e designers freelancers, destacando elementos importantes que fazem a diferença na formulação de uma proposta comercial.

Separei algumas dicas interessantes e recomendo a leitura do PDF com o estudo completo:

1. Suas propostas devem ser pontuais. Quanto mais rápido você enviá-las, maior a chance de serem aceitas (as propostas mais rápidas são enviadas, em média, 2,7 dias após a solicitação).
2. Acima de tudo, nunca tenha medo de recusar um cliente que você sabe que não será um bom negócio.
3. Não formule documentos longos. Propostas com menos de 5 páginas possuem 31% a mais de chance de terem sucesso.
4. Remova as informações sobre sua empresa: eles são fáceis de preencher e parecem informações importantes, mas a verdade é que os clientes simplesmente não a lêem. Eles provavelmente já conhecem sua empresa, caso contrário, não estariam solicitando uma proposta.
5. Use as palavras corretas no título, prefira algo como “Reformulação da presença digital” do que “Criação da nova homepage”;
6. Use templates, mas as melhores propostas possuem de 50 a 80% de conteúdo original, específicos para aquele cliente.
7. Propostas são documentos de persuasão de vendas. Elas precisam mostrar ao cliente que você sabe o que ele precisa e é a pessoa certa para ajudá-lo.
8. No final da proposta, você deve deixar claro quais os passos que o cliente deve tomar em seguida. Você pode escrever a melhor proposta do mundo, mas seria inútil se o cliente não sabe como agir sobre a informação que acabou de ler.

Designers possuem diferentes metodologias. Alguns pulam a fase de rabiscar no papel (sketching) e avançam diretamente para os wireframes. Alguns não fazem wireframes e vão diretamente para o mockup. Quando você pula uma fase (…) a interface sofre porque avança de forma prematura e perde elementos fundamentais ou não fica completamente refinada.

(…)

O que acontece é que você acaba criando o conceito básico da interface durante a fase de wireframe, ou refinando o conceito durante o estágio de mockup. Isso é contra-produtivo porque sketching é onde o conceito básico é feito. Wireframe é onde refinamos o conceito. E mockup é onde os elementos visuais são feitos, não a conceituação da interface. Quando você não rabisca no papel ou não faz wireframes, acaba pensando em coisas demais de uma única fase.

Tradução livre de trecho do artigo de Anthony T. no blog UX Movement

Foi pensando nisso que Andy Clark, designer e autor do livro “Hardboiled Web Design”, escreveu um modelo de contrato de prestação de serviços que se tornou bastante popular entre web designers e desenvolvedores. Sua linguagem chega a ser bem informal, mas não deixa dúvidas sobre quem deve fazer o quê.

Fiz uma tradução para português, usando trechos usando alguns trechos da tradução anterior feita por Henrique Arake.

Acessar o modelo

Basecamp Classic

Lançado em 2004, o Basecamp tornou-se uma unanimidade e hoje é utilizado por 7 milhões de pessoas em 180 países. A 37signals lançou em 2012 uma nova versão do software e passou a chamar a anterior de Classic. Gostei bastante da nova, mas ela não possui uma funcionalidade que ainda considero essencial e que somente existe na versão clássica, o controle de horas.

Preço: A empresa oferecia uma versão gratuita com funcionalidades limitadas, mas atualmente existe somente a versão paga com possibilidade de teste por 60 dias. As contas variam de US$ 20 a US$ 150 por mês. O plano de US$ 50 atende bem uma empresa de até 100 pessoas.

Plataformas: A versão web é totalmente adaptada para mobile e existem alguns apps de terceiros para smartphones.

Quando usar: Para equipes com mais de 10 pessoas que precisam manter um controle de horas trabalhadas. A integração com o email permite que diretores e outros executivos acompanhem o andamento dos projetos sem a necessidade de acessar o aplicativo.

Trello

Desenvolvido por Joel Spolsky em 2011, o Trello é uma ferramenta gratuita que se baseia na metodologia Kanban, popularizada pela Toyota em 1980. Cada projeto é representado por um mural dividido em colunas que contêm cartões. Os cartões podem ser arrastados de uma coluna para outra (drag-and-drop), espelhando o fluxo do conceito à implementação.

Preço: Grátis para sempre. Os desenvolvedores estudam a possibilidade de incluir funcionalidade pagas no futuro.

Plataformas: Versão web e mobile (Android e iPhone).

Quando usar: Projetos individuais ou para empresas que não exigem muita formalidade e documentação no processo de trabalho.

GitHub

Pode parecer estranho incluir um serviço de hospedagem de código compartilhado nessa lista, mas o GitHub é uma ótima ferramenta para gerenciar projetos de desenvolvimento de aplicativos ou websites. É possível criar metas, tarefas, atribuições e acompanhar as contribuições de cada membro da equipe. O diferencial do GitHub é que tudo gira em torno do código-fonte de sua aplicação.

Preço: Grátis para uma conta individual com repositórios de código aberto. Para empresas, o ideal é ter uma conta paga (de US$ 20 a US$ 200 por mês) que permite criar times e trabalhar com repositórios privados.

Plataformas: Versão web, desktop (Mac, Windows e Eclipse) e mobile (Android e iPhone).

Quando usar: Projetos de desenvolvimento de aplicativos e websites onde o código-fonte é a principal insumo.

Versão anterior do website GOV.UK

Desde o início do projeto de reformulação do website do governo britânico (GOV.UK), a equipe de desenvolvimento acreditava que a homepage deveria ser semelhante a do Google: uma caixa de pesquisa no centro da tela e nada mais.

Seguindo seus príprios princípios de design, o website é aperfeiçoado constantemente com base no feedback de seus usuários. Nos Últimos testes de usabilidade, os desenvolvedores chegaram a conclusão de que uma página inicial igual ao do Google não era a melhor solução. Eles diminuiram a importância da busca e destacaram os atalhos para os principais serviços.

As pessoas que visitam nossa homepage o fazem porque estão perdidas. Elas não encontraram a página certa e não estão confortáveis usando um mecanismo de busca, então eles vão para a página inicial para tentar encontrar o que estão procurando. Navegando e não usando a busca.

Tradução livre de trecho do artigo Why we’ve changed the homepage

Isso mostra a importância de testar o website com usuário reais e que melhorias constantes são muito mais eficientes do que um redesign completo.

Quando você desenvolve um website utilizando WordPress existe a necessidade de criar diferentes tipos de posts. Pode haver um canal de notícias, um calendário de eventos ou uma lista de receitas. Tudo isso são basicamente posts. Era comum o desenvolvedor web diferenciar os posts utilizando categorias. Uma resenha de livro, por exemplo, era marcada na categoria “Resenha” e isso já associava o post a um template específico.

Na busca em tornar-se um CMS cada vez mais completo, a versão 3.0 do WordPress permitiu a criação de custom post type. Você deve usá-los para tudo aquilo que não é post, como uma lista de produtos, um calendário de eventos e uma relação de funcionários. Isso evita o uso excessivo de categorias para diferenciar os posts.

A versão 3.1 do WordPress incluiu os post formats. Como o nome diz, isso está relacionado com o formato do post e não ao seu conteúdo. A lista de formatos é fixa e limitada para que exista um padrão entre todos os temas. Veja a lista completa:

• standard – Post padrão;
• aside – Uma nota, semelhante a uma publicação no Facebook;
• gallery – Uma galeria de imagens;
• link – Um link para outro site;
• image – Uma imagem simples;
• quote – Uma citação;
• status – Uma nota curta, como um Tweet;
• video – Um vídeo simples;
• audio – Um arquivo de áudio;
• chat – A transcrição de uma conversa;

As duas funcionalidades são similares e isso acaba gerando muita confusão. É importante entender bem esse conceito para saber como e quando utilizar cada uma das funções.

Se você usa o Google Analytics e nunca configurou metas (goals) porque acha que isso serve apenas para e-commerce, saiba que você pode (e deve) definir metas para um blog pessoal ou site institucional.

As metas no Google Analytics são ações realizadas pelos usuários que de alguma forma atendem os objetivos de negócio de um site. O exemplo mais óbvio é a realização da compra de um produto, mas metas vão muito além disso: aumentar número de visitas, geração de leads ou assinaturas de RSS são alguns exemplos.

O Google Analytics não tem como saber quais são os objetivos do site, por isso as metas de conversão não são medidas automaticamente e exigem algumas configurações extras.

Para cadastrar uma meta, acesse a conta do seu site no Google Analytics, clique em Administrador > Metas > Adicionar Meta. Existem 4 tipos de meta para diferentes tipos de conversão:

URL de destino

A conversão ocorre porque uma página específica (ou página virtual) é visualizada pelo visitante. Por exemplo, se você possuir um website de geração de leads que apresenta uma página agradecendo o usuário pelo envio de solicitações de contato, poderá definir o URL como /sales/thankyouforcontactingus.html.

Duração da visita

A conversão ocorre depois de decorrido um período de tempo específico na visita. Por exemplo, você pode usar esse tipo de meta para determinar quantos visitantes ficam mais de dois minutos em sua página de compras recém reformulada.

Páginas/visita

A conversão ocorre depois que um número definido de páginas for visualizado na visita. Você pode usar esse tipo de meta quando estimar que os visitantes visualizam no mínimo um conjunto de 3 páginas, por exemplo.

Evento

A conversão ocorre porque uma ação foi acionada em um evento. Para definir esse tipo de meta, primeiro você deve configurar o acompanhamento de eventos em seu site com pelo menos uma categoria de evento nomeada. (…)

via Ajuda do Google Analytics

Veja alguns exemplos de metas que você pode cadastrar de acordo com o tipo de site:

Portfólio de um freelancer:

• Enviar uma solicitação de orçamento
• Permanecer mais de 2 minutos em uma página de portfólio
• Acessar mais de 3 páginas do portfólio
• Curtir uma página do portfólio

Blog pessoal sobre um assunto específico:

• Enviar uma mensagem através do formulário de contato
• Fazer um comentário em um post
• Curtir ou Tweetar um post
• Assinar o RSS

Site institucional de um pequena empresa

• Enviar uma mensagem através do formulário de contato
• Enviar uma solicitação de orçamento
• Curtir a página no Facebook

Com as metas configuradas você pode quantificar a eficiência de suas ações. É possível medir o aumento de conversões quando publicamos um post ou até mesmo quando participamos de um evento offline.

Referências:

• Como configuro metas e funis?
• Análise de Conversão – Metas no Google Analytics
• 4 Google Analytics Goal Types That Are Critical To Your Business

Ame o processo. Eu não acho que a vida como designer seja monótona até que você comece a trabalhar para a Coca-Cola ou para a Nike. Isso é besteira. O processo por trás de qualquer novo projeto é valioso e educativo, sinta o momento, explore os detalhes e tente realmente compreender aquilo que você está trabalhando. Quanto mais envolvido estiver, mais vai amar o processo e o resultado – não importa o nome do cliente. Em suma: você tem que gostar do que está fazendo para fazê-lo bem.

Tradução livre de trecho do artigo de Daniel Gjøde na Computer Arts Magazine via @drigoteixeira

http://gov.uk

A equipe de governo digital do Reino Unido publicou a primeira versão das diretrizes de design para site governamentais. O material é tão rico que eu não poderia simplesmente colocar o link no Twitter. Escrevi essa tradução resumida, mas se você sabe ler em inglês, sugiro ir direto para a página original.

Princípios de Design do Governo Digital

1. Comece com as necessidades (do cidadão, não do governo) – O processo de design deve começar com a identificação das necessidades reais do usuário. Devemos criar em torno disso – não da forma como é o atual “processo oficial”. Devemos entender essas necessidades completamente – pesquisa de dados, não apenas suposições – e devemos lembrar que nem sempre o que usuários pedem é o que eles precisam.

2. Faça menos – Governo só deve fazer o que só o governo pode fazer. Se alguém já está fazendo isso – coloque o link. Se podemos fornecer recursos (como APIs) que vão ajudar outras pessoas a construírem coisas – que seja feito. Devemos concentrar-se no núcleo irredutível. (…) O Governo deve oferecer informações sobre impostos e não sobre criação de abelhas.

3. Faça design com dados – Normalmente não estamos começando do zero – usuários já estão usando nossos serviços. Isto significa que podemos aprender com o comportamento do mundo real. Devemos fazer isso, mas devemos ter certeza de que esse seja um processo contínuo de desenvolvimento – protótipos e testes com usuários reais na web. (…) Esta é a grande vantagem de serviços digitais – podemos observar e aprender com o comportamento do usuário, moldando o sistema para atender o que as pessoas fazem ao invés de forçá-las a usar um sistema que inventamos.

4. Faça o trabalho difícil para torná-lo simples – Fazer algo parecer simples é fácil; fazer algo simples de usar é muito mais difícil – especialmente quando os sistemas envolvidos são complexos – mas é o que devemos fazer. Com grande poder vem grande responsabilidade – muitas vezes as pessoas não têm escolha a não ser utilizar nossos serviços. Se não trabalharmos duro para torná-los simples de usar estamos abusando desse poder e desperdiçando o tempo das pessoas. (…) O sistema de licença maternidade é um bom exemplo de como tornar simples algo complicado. O código (…) está disponível no GitHub.

5. Faça iterações. E então faça novamente – A melhor maneira de criar serviços eficazes é começar pequeno e iteragir continuamente. Publique Produtos Mínimos Viáveis, teste com usuários reais, passe do Alpha para o Beta e para o Lançamento, adicionando recursos e aperfeiçoamentos com base no feedback de usuários reais. Iteração reduz o risco. Torna grandes fracassos improváveis e transforma pequenas falhas em lições. Isso evita as 200 páginas de especificações. Isso, novamente, é a principal vantagem do digital: não estamos construindo pontes – as coisas podem ser desfeitas.

6. Construa para inclusão – Design acessível é um bom design. Devemos construir um produto que é tão abrangente e legível quanto possível. Se tivermos de sacrificar a elegância – que assim seja. Não devemos ter medo do óbvio, não devemos tentar reinventar convenções de web design e devemos definir claramente as expectativas. Estamos projetando para todo país – não apenas para aqueles que estão acostumados a usar a web. Na verdade, as pessoas que mais precisam dos nossos serviços são aquelas que tem mais dificuldade em utilizá-los. Se pensarmos nessas pessoas desde o início, faremos um site melhor para todos.

7. Entenda o contexto – Não estamos projetando para uma tela, estamos projetando para pessoas. Precisamos pensar no contexto que os usuários utilizam nossos serviços. Eles estão em uma biblioteca? Eles estão em um telefone? Eles só sabem utilizar o Facebook? Nunca usaram a web antes? Estamos projetando para um grupo muito diversificado de usuários com diferentes tecnologias e necessidades. Precisamos ter certeza das circunstâncias tecnológicas e práticas em que nossos serviços são utilizados. Caso contrário, corremos o risco de criar serviços bonitos que não são relevantes para a vida das pessoas.

8. Construa serviços digitais e não sites – Nossos serviços não começam e terminam no site. Pode começar em um site de busca e acabar no posto dos correios. Precisamos projetar para isso, mesmo sem ter controle sobre todo processo. (…) Isso não é sobre sites, deve ser sobre serviços digitais. Hoje, a melhor maneira de oferecer serviços digitais é através da web – mas isso pode mudar, mais cedo do que podemos esperar.

9. Seja consistente, não uniforme – Sempre que possível devemos usar a mesma linguagem e padrões de design – isto ajuda as pessoas a se familiarizar com nossos serviços. Mas quando não for possível, devemos nos certificar que nossa abordagem é consistente. (…) Esta não é uma camisa de força ou um livro de regras. (..) Não temos como imaginar todos os cenários e escrever regras para isso. Cada circunstância é diferente e deve ser abordada em seus próprios termos. O que une as coisas, portanto, deve ser uma abordagem consistente – uma que os usuários venham a entender e confiar.

10. Faça coisas open source: isso as torna melhores – Devemos compartilhar o que estamos fazendo sempre que pudermos. Com colegas, usuários e com o mundo. Compartilhe códigos, design, ideias, intenções e falhas. Quanto mais olhos em um serviço melhor ele fica. (…) Em parte, porque muito do que estamos fazendo só é possível por causa do código aberto e da generosidade da comunidade de web design. (…) Mas principalmente porque essa abertura torna os serviços melhores – mais compreendido e mais analisado. Se nós damos o nosso código, vamos ser reembolsado com um código melhor. É por isso que nós estamos dando tudo isso…

Tradução livre de Government Digital Service
Design Principles

Se você chegou até aqui, não deixe de ler o guia de estilo para produção de conteúdo.

Pode parecer estranho comparar um poderoso iPad (U$400) com um simples Kindle (U$79), mas quando o assunto é leitura a briga esquenta.

Há 3 meses comprei um iPad2 com o objetivo principal de ler livros eletrônicos. Adorei o aparelho e uso para receber emails, navegar na web, acessar redes sociais, jogar e assistir filmes. Tudo menos ler. É impressionante, você abre o iPad para iniciar uma leitura e sempre cai na tentação de algum outro aplicativo.

Recentemente comprei um Kindle Touch e em menos de uma semana já estou terminando meu primeiro e-book. Na carta de apresentação, Jeff Bezos explica que o objetivo do Kindle é fazer você esquecer que está lendo um livro através de um dispositivo eletrônico. E é exatamente isso, ele é focado na leitura, sem interrupções, sem funcionalidades extras.

Pode parecer loucura, mas um fator determinante para a minha compra foi descobrir que existe uma capa de couro com uma lâmpada embutida que permite a leitura no escuro e utiliza bateria do próprio aparelho (que dura semanas!). Um outro detalhe importante é que o Kindle pesa apenas 240g, você não precisa das duas mãos para segurá-lo, diferente do iPad que tem 600g.

Para leitura rápida de blogs e notícias, eu continuo ainda com o iPad e o excelente Instapaper. Você instalar uma extensão no browser e ele envia diretamente para o iPad. Além disso, o aplicativo limpa todo layout do site, deixando apenas texto e imagem. Para o Kindle existe um serviço similar chamado Klip.me, mas a interface do aparelho realmente parece não ter sido feita para esse consumo rápido de informação.

Para mim, o Kindle se mostrou o melhor dispositivo para livros eletrônicos e o iPad para leitura rápida de blogs, notícias e todas as outras atividades online.

UPDATE: Se você se interessou pelo assunto, não deixe de ler o artigo do Tiago Dória com uma ótima comparação sobre leitura de livros digitais.