[Brazilian Portuguese] Getting Real A maneira mais inteligente, rápida e fácil de construir uma aplicação web de sucesso Jason Fried, David Heinemeier Hansson, Matthew Linderman

Introdução

O que é Cair na Real

Quer construir um aplicativo web de sucesso? Então é hora de Cair na Real (Get Real). Cair na Real é uma maneira menor, mais rápida e melhor de construir software.

Cair na Real é sobre pular toda a coisa que representa o real (gráficos, diagramas, caixas, setas, esquemáticos, wireframes, etc.) e realmente construir a coisa real.
Cair na Real é menos. Menos massa, menos software, menos funcionalidades, menos papelada, menos de tudo que não é essencial (e a maior parte do que você acha que é essencial na verdade não é).
Cair na Real é permanecer pequeno e ser ágil.
Cair na Real começa com a interface, as telas reais que as pessoas vão usar. Começa com o que o cliente realmente experimenta e constrói a partir daí. Isso permite acertar a interface antes de errar o software.
Cair na Real é sobre iterações e reduzir o custo da mudança. Cair na Real é sobre lançar, ajustar e melhorar constantemente, o que o torna uma abordagem perfeita para software baseado na we

O que é Cair na Real 903 words

Sobre o Basecamp

O que nós fazemos

Basecamp é uma equipe pequena que cria softwares simples e focados. Nossos produtos ajudam você a colaborar e se organizar. Milhões de pessoas e pequenos negócios usam nossos aplicativos web para realizar suas tarefas. Jeremy Wagstaff, do Wall Street Journal, escreveu, “Os produtos [Basecamp] são ferramentas belamente simples, elegantes e intuitivas que fazem uma tela do Outlook parecer o equivalente em software de uma câmara de tortura.” Nossos aplicativos nunca te colocam na tortura.

Nosso modus operandi

Acreditamos que o software é complexo demais. Muitas funcionalidades, muitos botões, muito o que aprender. Nossos produtos fazem menos que a concorrência — intencionalmente. Construímos produtos que trabalham de maneira mais inteligente, têm uma sensação melhor, permitem que você faça as coisas do seu jeito e são mais fáceis de usar.

Nossos produtos

Basecamp vira a gestão de projetos de cabeça para baixo. Em vez de gráficos de Gantt,

Sobre o Basecamp 342 words

Advertências, disclaimers e outros avisos prévios

Apenas para esclarecer, aqui estão nossas respostas para algumas reclamações que ouvimos de vez em quando:

"Essas técnicas não funcionarão para mim."

Cair na Real é um sistema que funcionou incrivelmente para nós. Dito isso, as ideias neste livro não se aplicam a todos os projetos sob o sol. Se você está construindo um sistema de armas, uma usina de controle nuclear, um sistema bancário para milhões de clientes ou algum outro sistema crítico para a vida/finanças, você vai se assustar com nossa atitude laissez-faire. Vá em frente e tome precauções adicionais.

E não tem que ser uma proposta de tudo ou nada. Mesmo que você não possa abraçar completamente Caindo na Real, com certeza há pelo menos algumas ideias aqui que você pode introduzir sorrateiramente.

"Vocês não inventaram essa ideia."

Não estamos reivindicando ter inventado essas técnicas. Muitos desses conceitos existem de uma forma ou de outra há muito tempo. Não fique irritad

Advertências, disclaimers e outros avisos prévios 830 words

Ponto de Partida

Vencendo pela simplicidade

A sabedoria convencional diz que para vencer seus concorrentes, você precisa superá-los. Se eles têm quatro recursos, você precisa de cinco (ou 15, ou 25). Se eles estão gastando x, você precisa gastar 2x. Se eles têm 20, você precisa de 30.

Essa mentalidade de Guerra Fria de superação é um beco sem saída. É uma maneira cara, defensiva e paranóica de construir produtos. Empresas defensivas e paranóicas não podem planejar o futuro, só conseguem olhar para trás. Elas não lideram, apenas seguem.

Se você quer construir uma empresa que apenas segue, nem se dê o trabalho de terminar esse texto.

E aí, o que fazer então? A resposta é fazer menos. Faça menos do que seus concorrentes para vencê-los. Resolva os problemas simples e deixe os problemas difíceis, complicados e desafiadores para os outros. Em vez de superar, tente simplificar. Em vez de fazer mais, tente fazer menos.

Vou falar em post futuros sobre esse conceito, mas para começar, fazer menos significa:

Menos

Vencendo pela simplicidade 187 words

Qual é o seu problema?

Construa software para você mesmo

Uma excelente maneira de construir software é começar resolvendo seus próprios problemas. Você será o público-alvo e saberá o que é importante e o que não é. Isso te dá uma grande vantagem para entregar um produto incrível.

A chave aqui é entender que você não está sozinho. Se você está enfrentando esse problema, é provável que centenas de milhares de outras pessoas estejam no mesmo barco. Aí está o seu mercado. Não foi fácil?

O Basecamp originou-se de um problema: Como uma empresa de design, a 37signals precisava de uma forma simples de comunicar sobre projetos com clientes. Começou fazendo isso através de extranets de clientes que eram atualziadas manualmente. Mas, alterar o html à mão toda vez que um projeto precisava ser atualizado simplesmente não estava funcionando. Esses sites de projetos sempre pareciam ficar obsoletos e eventualmente eram abandonados. Era frustrante porque ficava desorganizado e os clientes no escuro.

Entã

Qual é o seu problema? 685 words

Finance a você mesmo

Dinheiro externo é o plano B

A primeira prioridade de muitas startups é adquirir financiamento de investidores. Mas lembre-se, se você recorrer a fontes externas para financiamento, também terá que responder a eles. As expectativas são elevadas. Os investidores querem seu dinheiro de volta — e rapidamente. O triste fato é que capitalizar muitas vezes começa a ser mais importante do que construir um produto de qualidade.

Hoje em dia, não é preciso muito para começar. O hardware é barato e muitos softwares de infraestrutura excelentes são de código aberto e gratuitos. E paixão não tem preço.

Então faça o que puder com o dinheiro que tem em mãos. Pense bem e determine o que é realmente essencial e do que você pode abrir mão. O que você pode fazer com três pessoas em vez de dez? O que você pode fazer com $20 mil em vez de $100 mil? O que você pode fazer em três meses em vez de seis? O que você pode fazer se manter seu emprego e desenvolver seu aplicativo nas horas vagas?

Finance a você mesmo 557 words

Fixe prazo e orçamento, flexibilize o escopo

Lance no prazo e dentro do orçamento

Aqui vai uma maneira fácil de lançar no prazo e dentro do orçamento: mantenha ambos fixos. Nunca jogue mais tempo ou dinheiro num problema, apenas reduza o escopo.

Existe uma lenda mais ou menos assim: podemos lançar no prazo, dentro do orçamento e com o escopo planejado. Isso quase nunca acontece e, quando acontece, a qualidade muitas vezes é prejudicada.

Se você não consegue encaixar tudo dentro do tempo e orçamento previstos, então não expanda o tempo e o orçamento. Em vez disso, diminua o escopo. Você sempre vai poder adicionar coisas depois — o depois é eterno, o agora é passageiro.

Lançar algo incrível que é um pouco menor em escopo do que o planejado é melhor do que lançar algo medíocre e cheio de falhas porque você tinha que atingir uma janela mágica de tempo, orçamento e escopo. Deixe a mágica para o Houdini. Você tem um negócio de verdade para gerir e um produto de verdade para entregar.

Aqui e

Fixe prazo e orçamento, flexibilize o escopo 343 words

Tenha um inimigo

Compre uma briga

Às vezes, a melhor maneira de saber o que seu aplicativo deve ser é saber o que ele não deve ser. Descubra o inimigo do seu aplicativo e você iluminará o caminho a seguir.

Quando decidimos criar um software de gerenciamento de projetos, sabíamos que o Microsoft Project era o gorila na sala. Em vez de temer o gorila, usamos isso como um motivador. Decidimos que o Basecamp seria algo completamente diferente, o anti-Project.

Percebemos que o gerenciamento de projetos não é sobre gráficos, tabelas, relatórios e estatísticas — é sobre comunicação. Também não é sobre um gerente de projetos sentado no alto e transmitindo um plano de projeto. É sobre todos assumirem a responsabilidade juntos para fazer o projeto funcionar.

Nosso inimigo eram os Ditadores de Gerenciamento de Projetos e as ferramentas que eles usavam para dar ordens. Queríamos democratizar o gerenciamento de projetos — torná-lo algo do qual todos participassem (incluindo o cliente). Os projetos tê

Tenha um inimigo 683 words

Não deveria ser uma obrigação

Sua paixão — ou falta dela — transparece

Quanto menos seu aplicativo se sentir como uma obrigação para construir, melhor ele será. Mantenha-o pequeno e gerenciável para que você possa realmente desfrutar do processo.

Se seu aplicativo não te empolga, algo está errado. Se você está trabalhando nele apenas para conseguir um retorno financeiro, isso ficará evidente. Da mesma forma, se você sente paixão pelo seu aplicativo, isso será percebido no produto final. As pessoas conseguem ler nas entrelinhas.

A presença da paixão

No design, onde o significado é muitas vezes controversamente subjetivo ou dolorosamente inescrutável, poucas coisas são mais aparentes e lúcidas do que a presença da paixão. Isso é verdade seja o design de um produto que te encanta ou te deixa indiferente; em ambos os casos, é difícil não detectar o investimento emocional das mãos que o construíram.

O entusiasmo se manifesta prontamente, é claro, mas a indiferença é igualmente indelé

Não deveria ser uma obrigação 265 words

Mantenha-se enxuto

Menos massa

Quanto mais enxuto você for, mais fácil é mudar

Quanto mais massa tem um objeto, mais energia é necessária para mudar sua direção. Isso é tão verdade no mundo dos negócios quanto no mundo da física.

Quando se trata de tecnologia web, a mudança deve ser fácil e barata. Se você não pode mudar rapidamente, perderá espaço para alguém que pode. É por isso que você precisa buscar menos massa.

A massa é aumentada por

Contratos de longo prazo
Excesso de pessoal
Decisões permanentes
Reuniões sobre outras reuniões
Processos complexos
Estoque (físico ou mental)
Dependências de hardware, software, tecnologia
Formatos de dados proprietários
O passado governando o futuro
Roadmaps de longo prazo- Politicagem corporativa

A massa é reduzida por

Pensamento sob demanda
Membros da equipe multitarefas
Abraçar restrições, não tentar levantá-las
Menos software, menos código
Menos funcionalidades
Times pequenos- Simplicidade
Interfaces s

Menos massa 453 words

Diminua seu custo de mudança

Mantenha-se flexível reduzindo obstáculos à mudança

A mudança é sua melhor amiga. Quanto mais caro for fazer uma mudança, menos provável será que você a faça. E se seus concorrentes podem mudar mais rápido do que você, você está em grande desvantagem. Se a mudança se tornar muito cara, você está morto.

Aqui é onde ser enxuto realmente ajuda. A habilidade de mudar rapidamente é algo que pequenas equipes têm por padrão e que grandes equipes nunca podem ter. É aqui que os grandes invejam os pequenos. O que pode levar uma grande equipe em uma enorme organização semanas para mudar, pode levar apenas um dia em uma organização pequena e enxuta. Essa vantagem é inestimável. Mudanças baratas e rápidas são a arma secreta dos pequenos.

E lembre-se: Todo o dinheiro, todo o marketing, todas as pessoas do mundo não podem comprar a agilidade que você tem por ser pequeno.

Quando se trata de tecnologia web, a mudança deve ser fácil e barata. Se você não pode mudar rapidamente

Diminua seu custo de mudança 535 words

Os Três Mosqueteiros

Use uma equipe de três para a versão 1.0

Para a primeira versão do seu aplicativo, comece com apenas três pessoas. Esse é o número mágico que lhe dará capacidade o suficiente, mas ainda permitirá que você permaneça ágil e enxuto. Comece com um desenvolvedor, um designer e um faz-tudo (alguém que pode transitar entre os dois mundos).

Claro, é um desafio construir um aplicativo com algumas poucas pessoas. Mas, se você tiver a equipe certa, vale a pena. Pessoas talentosas não precisam de recursos infinitos. Elas prosperam com o desafio de trabalhar dentro de restrições e usar sua criatividade para resolver problemas. Sua falta de mão de obra significa que você será forçado a lidar com tradeoffs mais cedo no processo — e tudo bem. Isso fará com que você descubra suas prioridades mais cedo em vez de mais tarde. E você será capaz de se comunicar sem estar constantemente preocupado em deixar pessoas fora do loop.

Se você não pode construir sua versão inicial com três pessoas,

Os Três Mosqueteiros 415 words

Abrace as limitações

Deixe as limitações te guiarem para soluções criativas

Sempre vai faltar alguma coisa. Falta tempo. Falta dinheiro. Falta gente.

E isso é uma coisa boa.

Em vez de surtar com as limitações, abrace-as. Deixe elas serem o guia. As limitações promovem inovação e forçam o foco. Em vez de lutar contra elas, use-as a seu favor.

Quando o Basecamp foi construído, haviam várias limitações:

Uma empresa de design pra tocar- Projetos para clientes acontecendo- Uma diferença de 7 horas no fuso horário (David estava programando na Dinamarca, e o restante do time nos Estados Unidos)- Uma equipe pequena- Nada de financiamento externo

A amargura do "não é suficiente" pairava no ar. Nesse caso, o segredo era dar garfadas pequenas. Assim, não dava pra abocanhar coisa demais. Tarefas grandes eram divididas em pedaços pequenos e enfrentadas uma de cada vez. Avançando passo a passo e priorizando ao longo do caminho.

Isso forçou a descoberta de soluções criativas. O custo de mu

Abrace as limitações 254 words

Seja você mesmo

Diferencie-se das grandes empresas sendo pessoal e amigável

Muitas empresas pequenas cometem o erro de tentar agir como grandes. É como se elas percebessem seu tamanho como uma fraqueza que precisa ser encoberta. Que pena. Ser pequeno pode na verdade ser uma enorme vantagem, especialmente quando se trata de comunicação.

Empresas pequenas desfrutam de menos formalidades, menos burocracia e mais liberdade. Empresas menores são, por padrão, mais próximas do cliente. Isso significa que elas podem se comunicar de uma maneira mais direta e pessoal com os clientes. Se você é pequeno, pode usar uma linguagem familiar em vez de jargões. Seu site e seu produto podem ter uma voz humana em vez de soar como um drone corporativo. Ser pequeno significa que você pode conversar com seus clientes, não falar de cima para baixo com eles.

Há também vantagens nas comunicações internas em empresas pequenas. Você pode dispensar formalidades. Não há necessidade de processos árduos e múltiplas ap

Seja você mesmo 436 words

Qual é a grande ideia?

Defina explicitamente a visão única para o seu aplicativo

O que seu aplicativo representa? Sobre o que ele é realmente? Antes de começar a projetar ou codificar qualquer coisa, você precisa conhecer o propósito do seu produto — a visão. Pense grande. Por que ele existe? O que o torna diferente de outros produtos similares?

Esta visão guiará suas decisões e manterá você em um caminho consistente. Sempre que houver um ponto de dúvida, pergunte: "Estamos sendo fiéis à visão?"

Sua visão também deve ser breve. Uma frase deve ser suficiente para transmitir a ideia. Aqui está a visão para cada um dos nossos produtos:

Basecamp: Gerenciamento de projetos é comunicação
Backpack: Reúna as pontas soltas da vida
Campfire: Chat em grupo por mensagem instantânea é ruim
Ta-da List: Competindo com um post-it
Writeboard: Word é um exagero

Com o Basecamp, por exemplo, a visão era "Gerenciamento de projetos é comunicação". Sentíamos fortemente que

Qual é a grande ideia? 500 words

Prioridades

Ignore os detalhes no início

Trabalhe do maior para o menor

Somos loucos pelos detalhes:

O espaço entre objetos
O tipo de letra perfeito
A cor perfeita
As palavras perfeitas
Quatro linhas de código em vez de sete
90% vs 89%- 760px vs 750px
$39/mês vs. $49/mês

O sucesso e a satisfação estão nos detalhes.

No entanto, o sucesso não é a única coisa que você encontrará nos detalhes. Você também encontrará estagnação, discordância, reuniões e atrasos. Essas coisas podem matar o moral e diminuir suas chances de sucesso.

Quantas vezes você se viu preso em um único elemento de design ou código por um dia inteiro? Quantas vezes você percebeu que o progresso que fez hoje não foi um progresso real? Isso acontece quando você foca nos detalhes muito cedo no processo. Há muito tempo para ser um perfeccionista. Só faça isso mais tarde.

Não se preocupe com o tamanho da fonte do seu título na primeira semana. Você não precisa acertar aquele tom perfeito de verde na segunda sema

Ignore os detalhes no início 409 words

É um problema quando for um problema

Não perca tempo com problemas que você ainda não tem

Você realmente precisa se preocupar em dimensionar para 100.000 usuários hoje se levará dois anos para chegar lá?

Você realmente precisa contratar oito programadores se só precisa de três hoje?

Você realmente precisa de 12 servidores de ponta agora se pode operar com dois por um ano?

Improvise

As pessoas frequentemente gastam muito tempo no início tentando resolver problemas que nem sequer têm ainda. Não faça isso. Na verdade, o Basecamp foi lançado sem a capacidade de cobrar os clientes! Como o produto era faturado em ciclos mensais, sabíamos que tínhamos um intervalo de 30 dias para resolver isso. Usamos esse tempo para resolver problemas mais urgentes e, depois do lançamento, lidamos com a cobrança. Funcionou bem (e nos obrigou a encontrar uma solução simples sem firulas desnecessárias).

Não se preocupe com coisas até que seja realmente necessário. Não faça um excesso de construção. Aum

É um problema quando for um problema 242 words

Contrate os clientes certos

Encontre o mercado principal da sua aplicação e foque somente nele

O cliente nem sempre tem razão. A verdade é que você precisa filtrar quem está certo e quem está errado para o seu aplicativo. A boa notícia é que a internet facilita mais do que nunca encontrar as pessoas certas. Se tentar agradar a todos, você não agradará ninguém.

Quando construímos o Basecamp, focamos nosso marketing em empresas de design. Ao restringir nosso mercado dessa forma, tornamos mais provável atrair clientes apaixonados que, por sua vez, evangelizariam o produto. Saiba para quem o seu aplicativo é realmente destinado e concentre-se em agradá-los.

A Melhor Decisão que Já Tomamos

A decisão de direcionar o Campaign Monitor estritamente para o mercado de design web foi a melhor escolha que já fizemos. Isso nos permitiu identificar facilmente quais recursos seriam genuinamente úteis e, mais importante, quais recursos deixar de fora. Não só atraímos mais clientes ao visar um grupo

Contrate os clientes certos 248 words

Escale depois

Você ainda não tem um problema de escalabilidade

"Meu aplicativo vai escalar conforme milhões de pessoas comecem a usá-lo?"

Sabe de uma coisa? Espere até que isso realmente aconteça. Se você tem um grande número de pessoas sobrecarregando seu sistema, então parabéns! Esse é um ótimo problema para se ter. A verdade é que a grande maioria dos aplicativos web nunca vai chegar a essa fase. E mesmo que você comece a ficar sobrecarregado, geralmente não é um problema de tudo ou nada. Você terá tempo para ajustar e responder ao problema. Além disso, você terá mais dados do mundo real e benchmarks após o lançamento, que você pode usar para descobrir as áreas que precisam ser abordadas.

Por exemplo, nós rodamos o Basecamp em um único servidor durante o primeiro ano. Porque optamos por uma configuração tão simples, levou apenas uma semana para implementar. Não começamos com um cluster de 15 máquinas ou gastamos meses preocupados com escalabilidade.

Nós enfrentamos alguns problemas?

Escale depois 361 words

Crie software com opinião

Seu app deve tomar partido

Algumas pessoas argumentam que o software deve ser agnóstico. Dizem que é arrogante os desenvolvedores limitarem funcionalidades ou ignorarem pedidos. Dizem que o software deve ser sempre o mais flexível possível.

Nós achamos isso um absurdo. Os melhores softwares tem uma visão. Os melhores softwares tomam partido. Quando alguém usa um software, não está apenas procurando por recursos, está procurando por uma abordagem. Está procurando por uma visão. Decida qual é a sua visão e siga com ela.

E lembre-se, se eles não gostarem da sua visão, há muitas outras visões por aí para as pessoas. Não corra atrás de pessoas que você nunca fará feliz.

Um ótimo exemplo é o design original do wiki. Ward Cunningham e amigos deliberadamente retiraram do wiki muitos recursos que eram considerados integrais para a colaboração em documentos no passado. Em vez de atribuir cada mudança do documento a uma certa pessoa, eles removeram grande parte da represen

Crie software com opinião 255 words

Seleção de Funcionalidades

Meio, não meia-boca

Construa meio produto, não um produto meia-boca

Cuidado com a abordagem de "tudo e mais um pouco" no desenvolvimento de aplicativos web. Se você incluir toda ideia razoável que surgir, acabará com uma versão malfeita do seu produto. O que você realmente quer fazer é construir metade de um produto que seja excepcional.

Foque no que é verdadeiramente essencial. Boas ideias podem ser adiadas. Pegue o que você acha que seu produto deve ser e corte pela metade. Reduza as funcionalidades até restar apenas as mais essenciais. E então faça isso novamente.

O Basecamp começou apenas com a seção de mensagens. Sabíamos que essa era a essência do aplicativo, então ignoramos milestones, listas de tarefas e outros itens por hora. Isso nos permitiu basear decisões futuras em uso real em vez de suposições.

Comece com um aplicativo enxuto e inteligente e deixe que ele ganhe tração. Então você pode começar a adicionar à sólida base que construiu.

Meio, não meia-boca 162 words

Simplesmente não importa

Somente o essencial

Nossa resposta favorita para a pergunta "por que vocês não fizeram isso ou aquilo?" é sempre: "Porque simplesmente não importa." Essa afirmação encapsula o que torna um produto excelente. Descobrir o que importa e deixar o resto de fora.

Quando lançamos o primeiro Campfire, ouvimos algumas dessas perguntas de pessoas que estavam conferindo o produto pela primeira vez:

"Por que timestamps apenas a cada 5 minutos? Por que não marcar cada linha do chat?" Resposta: Simplesmente não importa. Com que frequência você precisa rastrear uma conversa pelo segundo ou mesmo pelo minuto? Certamente não 95% do tempo. As timestamps de 5 minutos eram suficientes porque algo mais específico simplesmente não importava.

"Por que vocês não permitem formatação em negrito, itálico ou colorida nos chats?" Resposta: Simplesmente não importa. Se você precisa enfatizar algo, use a confiável tecla de caps lock ou coloque alguns *’s ao redor da palavra ou frase. Essas so

Simplesmente não importa 350 words

Parta do "Não"

Faça com que as funcionalidades trabalhem duro para serem implementadas

O segredo para construir meio produto, em vez de um produto meia-boca, está em dizer não.

Cada vez que você diz sim a uma funcionalidade, está adotando um filho. Você precisa passar por uma série de eventos com o seu bebê (por exemplo, design, implementação, teste, etc.). E uma vez que essa funcionalidade estiver lá fora, você está preso a ela. Tente retirar uma funcionalidade já lançada dos clientes e veja o quanto eles ficam irritados.

Não seja submisso

Faça com que cada funcionalidade trabalhe duro para ser implementada. Faça com que cada funcionalidade se prove e mostre que ela é uma sobrevivente. É como no "Clube da Luta". Você só deve considerar funcionalidades se elas estiverem dispostas a esperar na porta por três dias para serem aceitas.

É por isso que você começa com o não. Toda solicitação de nova funcionalidade que chega até nós - ou parte de nós - recebe um não. Nós ouvimos, mas não

Parta do "Não" 378 words

Custos escondidos

Exponha o custo das novas funcionalidades

Mesmo que uma funcionalidade passe pela fase do "não", ainda é preciso expor seus custos ocultos.

Por exemplo, fique de olho em loops de funcionalidades (ou seja, funcionalidades que levam a mais funcionalidades). Recebemos pedidos para adicionar uma aba de reuniões ao Basecamp. Parece simples o suficiente até você examinar de perto. Pense em todos os diferentes itens que uma aba de reuniões pode exigir: local, horário, sala, pessoas, convites por email, integração com calendários, documentação de suporte, etc. Isso sem mencionar que teríamos que alterar capturas de tela promocionais, páginas de tour, páginas de FAQ/ajuda, os termos de serviço e mais. Antes que se perceba, uma ideia simples pode se transformar em uma grande dor de cabeça.

Para cada nova funcionalidade, você precisa:

Dizer não.
Forçar a funcionalidade a provar seu valor.
Se "não" novamente, terminar aqui. Se "sim", continuar...
Esboçar a(s) tela(s)

Custos escondidos 229 words

Você dá conta?

Construa algo que você possa gerenciar

Se você lançar um programa de afiliados, você tem os sistemas necessários para lidar com a contabilidade e os pagamentos? Talvez você devesse apenas permitir que as pessoas ganhassem créditos em sua assinatura em vez de escrever, assinar e enviar um cheque todo mês.

Você pode se dar ao luxo de oferecer 1 GB de espaço de graça só porque o Google oferece? Talvez você devesse começar pequeno, com 100 MB, ou apenas fornecer espaço em contas pagas.

Em resumo: Construa produtos e ofereça serviços que você possa gerenciar. É fácil fazer promessas. É muito mais difícil cumpri-las. Certifique-se de que o que quer que você esteja fazendo seja algo que você possa realmente sustentar — organizacionalmente, estrategicamente e financeiramente.

Você dá conta? 131 words

Soluções Humanas

Construa softwares para conceitos gerais e incentive as pessoas a criarem suas próprias soluções

Não imponha convenções às pessoas. Em vez disso, torne seu software generalista para que todos possam encontrar suas próprias soluções. Dê às pessoas apenas o suficiente para resolverem seus próprios problemas do seu jeito. E depois saia do caminho.

Quando construímos a Ta-da List, omitimos intencionalmente muitas coisas. Não há como atribuir uma tarefa a alguém, não há como marcar uma data de vencimento, não há como categorizar itens, etc.

Mantivemos a ferramenta limpa e descomplicada, permitindo que as pessoas fossem criativas. As pessoas descobriram como resolver problemas por conta própria. Se quisessem adicionar uma data a um item de tarefa, poderiam simplesmente adicionar (vencimento: 7 de abril de 2006) no início do item. Se quisessem adicionar uma categoria, poderiam simplesmente adicionar [Livros] no início do item. Ideal? Não. Infinitamente flexível? Sim.

Se tentá

Soluções Humanas 207 words

Esqueça solicitações de funcionalidades

Deixe seus clientes te lembrarem do que é importante

Os clientes querem tudo o que se possa imaginar. Eles vão te soterrar com solicitações de funcionalidades. É só verificar nossos fóruns de produtos; a categoria de solicitações de funcionalidades sempre supera as outras por uma grande margem.

Nós ouvimos muito "aquele pequena funcionalidade extra" ou "isso não pode ser difícil" ou "não seria fácil adicionar isso" ou "deveria levar apenas alguns segundos para implementar" ou "se você adicionasse isso, eu pagaria o dobro" e assim por diante.

Claro que não culpamos as pessoas por fazerem pedidos. Nós encorajamos isso e queremos ouvir o que eles têm a dizer. Quase tudo que adicionamos aos nossos produtos começa como um pedido de cliente. Mas, como mencionamos antes, sua primeira resposta deve ser um “não”. Então, o que você faz com todos esses pedidos que chegam? Onde você os armazena? Como você os gerencia? **Você não faz. Apenas leia-os e depois j

Esqueça solicitações de funcionalidades 389 words

Feito especialmente para você

Pergunte às pessoas o que elas não querem

A maioria das pesquisas e perguntas de produto se concentra no que as pessoas querem em um software. "Que funcionalidade você acha que está faltando?" "Se pudesse adicionar apenas uma coisa, o que seria?" "O que tornaria este produto mais útil para você?"

E o outro lado da moeda? Por que não perguntar às pessoas o que elas não querem? "Se pudesse remover uma funcionalidade, qual seria?" "O que você não usa?" "O que mais te atrapalha?"

Mais nem sempre é a resposta. Às vezes, o maior favor que você pode fazer aos clientes é deixar algo de fora.

A inovação vem de dizer Não

A inovação vem de dizer não para mil coisas para garantir que não entremos no caminho errado ou tentemos fazer demais. Estamos sempre pensando em novos mercados que poderíamos entrar, mas é só dizendo não que você pode se concentrar nas coisas que são realmente importantes.

–Steve Jobs (em “[A semente da inovação na Apple](https://web.archi

Feito especialmente para você 175 words

Processo

Corra para ter software funcionando

Coloque algo real em funcionamento o mais rápido possível

Software que funciona é a melhor maneira de construir momentum, unir sua equipe e descartar ideias que não funcionam. Isso deve ser sua prioridade número um desde o início.

É ok fazer menos, pular detalhes e tomar atalhos em seu processo se isso levar a um software em funcionamento mais rápido. Uma vez lá, você será recompensado com uma perspectiva significativamente mais precisa sobre como prosseguir. Histórias, wireframes, até mockups em HTML, são apenas aproximações. Software em funcionamento é real.

Com software real e em funcionamento, todos ficam mais próximos do verdadeiro entendimento e acordo. Você evita discussões acaloradas sobre esboços e parágrafos que acabam por não importar de qualquer forma. Você percebe que partes que você pensava serem triviais são na verdade bastante cruciais.

Coisas reais levam a reações reais. E é assim que você chega à verdade.

Coisas Reais Levam ao

Corra para ter software funcionando 413 words

De novo e de novo

Trabalhe em iterações

Não espere acertar de primeira. Deixe o aplicativo crescer e falar com você. Permita que ele se transforme e evolua. Com o software baseado na web, não há necessidade de entregar perfeição. Desenhe telas, use-as, analise-as e então comece de novo.

Em vez de contar com acertar tudo de antemão, o processo iterativo permite que você continue a tomar decisões informadas à medida que avança. Além disso, você terá um aplicativo ativo e funcionando mais rápido, já que não está buscando a perfeição logo de cara. O resultado é um feedback real e orientações reais sobre o que requer sua atenção.

Iteração leva à libertação

Você não precisa mirar na perfeição na primeira tentativa se sabe que vai fazer tudo de novo mais tarde mesmo. Saber que você vai revisitar questões é um ótimo motivador para apenas colocar ideias na rua e ver se elas vão decolar.

Talvez você seja mais inteligente do que eu

Talvez você seja MUITO mais inteligente do que eu.

De novo e de novo 366 words

De ideia a implementação

Do brainstorm aos esboços, ao HTML e à programação

Aqui está o processo que usamos para Cair na Real:

Brainstorm

Pense em ideias. O que esse produto vai fazer? Para o Basecamp, olhamos para nossas próprias necessidades. Queríamos postar atualizações de projetos. Queríamos que os clientes participassem. Sabíamos que os projetos tinham marcos. Queríamos centralizar arquivos para que as pessoas pudessem revisar facilmente coisas antigas. Queríamos ter uma visão geral, de cima, do que está acontecendo com todos os nossos projetos. Juntas, essas suposições, e algumas outras, serviram como nossa base.

Esta etapa não é sobre detalhes minuciosos. É sobre grandes questões. O que o aplicativo precisa fazer? Como saberemos quando for útil? O que exatamente vamos criar? Isso é sobre ideias de alto nível, não discussões ao nível do pixel. Nesta fase, esse tipo de detalhe simplesmente não é significativo.

Esboços no papel

Esboços são rápidos, sujos e baratos e é

De ideia a implementação 339 words

Evite preferências

Decida os pequenos detalhes para que seus clientes não precisem fazer isso

Você está diante de uma decisão difícil: quantas mensagens incluímos em cada página? Sua primeira inclinação pode ser dizer, "Vamos tornar isso uma preferência onde as pessoas podem escolher entre 25, 50 ou 100." Mas essa é a saída fácil. Apenas tome uma decisão.

Preferências são uma maneira de evitar decisões difíceis

Em vez de usar sua expertise para escolher o melhor caminho, você está deixando nas mãos dos clientes. Pode parecer que você está fazendo um favor a eles, mas você só está criando trabalho extra para eles (e é provável que eles já estejam ocupados o suficiente). Para os clientes, telas de preferência com uma quantidade infinita de opções são uma dor de cabeça, não uma bênção. Os clientes não deveriam ter que pensar em cada detalhe minucioso — não coloque esse fardo sobre eles quando deveria ser sua responsabilidade.

Preferências também são ruins porque criam mais software. Mai

Evite preferências 425 words

"Feito!"

Decisões são temporárias, então tome a decisão e siga em frente

Feito. Comece a pensar nisso como uma palavra mágica. Quando você chega a "feito", significa que algo foi realizado. Uma decisão foi tomada e você pode seguir em frente. Feito significa que você está construindo momentum.

Mas e se você errar e tomar a decisão errada? Tudo bem. Isso não é uma cirurgia cerebral, é um aplicativo web. Como estamos sempre dizendo, provavelmente você terá que revisitar recursos e ideias várias vezes durante o processo de qualquer maneira. Não importa o quanto você planeje, é provável que você erre pela metade de qualquer forma. Então, não caia na armadilha da "paralisia pela análise". Isso só atrasa o progresso e enfraquece a moral.

Em vez disso, valorize a importância de seguir em frente e avançar. Entre no ritmo de tomar decisões. Faça uma escolha rápida e simples e depois volte e mude essa decisão se não der certo.

Aceite que as decisões são temporárias. Aceite que os erros acontecerão

"Feito!" 365 words

Teste no mundo real

Teste seu aplicativo através do uso no mundo real

Não há substituto para pessoas reais usando seu aplicativo de maneiras reais. Obtenha dados reais. Receba feedback real. Depois, melhore com base nessas informações.

Testes de usabilidade formais são muito rígidos. Ambientes de laboratório não refletem a realidade. Se você ficar observando por cima do ombro de alguém, você terá alguma ideia do que está funcionando ou não, mas as pessoas geralmente não se saem bem na frente de uma câmera. Quando alguém está assistindo, as pessoas são especialmente cuidadosas para não cometer erros — no entanto, erros são exatamente o que você está procurando.

Em vez disso, lance recursos beta para alguns selecionados dentro do próprio aplicativo real. Faça com que eles usem os recursos beta ao lado dos recursos lançados. Isso exporá esses recursos aos dados reais das pessoas e ao fluxo de trabalho real. E é aí que você obterá resultados reais.

Além disso, não tenha uma versão de lançame

Teste no mundo real 530 words

Diminua seu tempo

Desmembre

Estimativas que se estendem por semanas ou meses são fantasias. A verdade é que você simplesmente não sabe o que vai acontecer tão longe no futuro.

Então, reduza seu tempo. Continue desmembrando prazos em pedaços menores. Em vez de um projeto de 12 semanas, pense nele como 12 projetos de uma semana. Em vez de estimar tarefas que levam mais de 30 horas, divida-as em blocos mais realistas de 6 a 10 horas. Depois, prossiga um passo de cada vez.

A mesma teoria se aplica a outros problemas também. Você está enfrentando um problema que é grande demais para compreender? Desmembre. Continue dividindo os problemas em peças cada vez menores até que você consiga digeri-los.

Tarefas Menores e Prazos Menores

Desenvolvedores de software são um tipo especial de otimista: quando apresentados a uma tarefa de programação, eles pensam, “Isso vai ser fácil! Não vai levar muito tempo.”

Então, dê a um programador três semanas para completar uma grande tarefa, e ele pass

Diminua seu tempo 644 words

A organização

União

Não se divida em silos

Muitas empresas separam design, desenvolvimento, copywriting, suporte e marketing em diferentes silos. Embora a especialização tenha suas vantagens, ela também cria uma situação em que os funcionários veem apenas o seu próprio mundinho em vez do contexto inteiro do aplicativo web.

Sempre que possível, integre sua equipe para que haja um diálogo constante de ida e volta durante o processo. Estabeleça um sistema de checagens e equilíbrios. Não deixe que as coisas se percam no caminho. Faça com que os copywriters trabalhem com os designers. Certifique-se de que as consultas de suporte sejam vistas pelos desenvolvedores.

Melhor ainda, contrate pessoas com múltiplos talentos que possam desempenhar diferentes funções durante o desenvolvimento. O resultado final será um produto mais harmonioso.

União 127 words

Tempo sozinho

As pessoas precisam de tempo ininterrupto para realizar suas tarefas

O Basecamp está espalhado por quatro cidades e oito fusos horários. De Provo, Utah, a Copenhague, Dinamarca, os cinco de nós têm uma diferença de oito horas. Um efeito colateral positivo dessa diferença de oito horas é o tempo sozinho.

Há apenas cerca de 4-5 horas durante o dia em que todos estamos acordados e trabalhando juntos. Em outros momentos, a equipe dos Estados Unidos está dormindo enquanto David, que está na Dinamarca, está trabalhando. O resto do tempo, estamos trabalhando enquanto David está dormindo. Isso nos dá cerca de metade do dia juntos e a outra metade sozinhos.

Adivinhe em qual parte do dia realizamos a maioria do trabalho? Na parte em que estamos sozinhos. Isso não é realmente surpreendente. Muitas pessoas preferem trabalhar de manhã cedo ou tarde da noite - momentos em que não são incomodadas.

Quando você tem um longo período em que não é incomodado, você pode entrar na "zona". A zona

Tempo sozinho 535 words

Reuniões são tóxicas

Não tenha reuniões

Você realmente precisa de uma reunião? Reuniões geralmente surgem quando um conceito não está claro o suficiente. Em vez de recorrer a uma reunião, tente simplificar o conceito para que você possa discutí-lo rapidamente via e-mail ou mensagem instantânea. O objetivo é evitar reuniões. Cada minuto que você evita gastar em uma reunião é um minuto que você pode realmente trabalhar.

Não há nada mais tóxico para a produtividade do que uma reunião. Aqui estão algumas razões:

Elas quebram seu dia de trabalho em pequenos pedaços incoerentes que interrompem seu fluxo de trabalho natural
Geralmente são sobre palavras e conceitos abstratos, não coisas reais (como um pedaço de código ou algum design de interface)
Costumam transmitir uma quantidade abismalmente pequena de informação por minuto
Frequentemente contêm pelo menos um idiota que inevitavelmente tem sua vez de desperdiçar o tempo de todos com bobagens
Desviam do assunto mais facilmente que

Reuniões são tóxicas 455 words

Busque e celebre pequenas vitórias

Lance algo hoje

A coisa mais importante no desenvolvimento de software é a motivação. A motivação é local — se você não está motivado pelo que está trabalhando agora, então provavelmente não será tão bom quanto deveria ser. Na verdade, provavelmente vai ser ruim.

Ciclos de lançamento longos e arrastados são assassinos de motivação. Eles inserem muito tempo entre as celebrações. Por outro lado, vitórias rápidas que você pode celebrar são ótimos motivadores. Se você deixar ciclos de lançamento longos esmagar vitórias rápidas, você mata a motivação. E isso pode matar seu produto.

Então, se você está no meio de um ciclo de lançamento de vários meses, dedique um dia por semana (ou a cada duas semanas) para algumas pequenas vitórias. Pergunte-se "O que podemos fazer e lançar em 4 horas?" E então faça isso. Pode ser…

Uma nova funcionalidade simples
Um pequeno aprimoramento em uma funcionalidade existente
Reescrever algum texto de ajuda para reduzir o ô

Busque e celebre pequenas vitórias 209 words

Equipe

Contrate menos e contrate depois

Adicione devagar para acelerar

Não há necessidade de crescer rapidamente — nem agora, nem depois. Mesmo que você tenha acesso a 100 das melhores pessoas, ainda é uma má ideia tentar contratá-las todas de uma vez. Não há como você assimilar imediatamente tantas pessoas em uma cultura coesa. Você terá dores de cabeça com treinamento, choques de personalidade, lapsos de comunicação, pessoas indo em direções diferentes e mais.

Então, não contrate. Sério. Não contrate pessoas. Procure outra maneira. O trabalho que está te sobrecarregando é realmente necessário? E se você simplesmente não o fizer? Você pode resolver o problema com um pedaço de software ou uma mudança de prática, em vez disso?

Sempre que Jack Welch, ex-CEO da GE, demitia alguém, ele não contratava imediatamente um substituto. Ele queria ver quanto tempo poderia se virar sem aquela pessoa e aquela posição. Certamente não estamos defendendo demitir pessoas para testar essa teoria, mas achamos que Jac

Contrate menos e contrate depois 329 words

Test drive

Trabalhe com potenciais funcionários em um formato de testes primeiro

É uma coisa olhar um portfólio, currículo, exemplo de código ou trabalho anterior. É outra coisa trabalhar realmente com alguém. Sempre que possível, leve os potenciais novos membros da equipe para um "test drive".

Antes de contratarmos alguém, damos a eles um pequeno projeto para experimentar primeiro. Vemos como eles lidam com o projeto, como se comunicam, como trabalham, etc. Trabalhar com alguém enquanto eles projetam ou codificam algumas telas vai te dar uma tonelada de insights. Você aprenderá bem rápido se a vibe certa está lá ou não.

Agendar isso pode ser difícil, mas mesmo que seja por apenas 20 ou 40 horas, é melhor do que nada. Se é um bom ou mau fit, será óbvio. E se não, ambos os lados se poupam de muito problema e risco ao testar a situação primeiro.

Comece pequeno

Tente uma pequena tarefa de teste para começar. Não mergulhe com todo o seu trabalho de uma vez. Dê ao seu novo [assistent

Test drive 223 words

Ações, não palavras

Avalie potenciais contratações técnicas com base em contribuições para o open source

O método típico de contratação para posições técnicas — baseado em diplomas, currículos, etc. — é questionável em muitos aspectos. Realmente importa de onde é o diploma de alguém ou seu CR? Você pode realmente confiar em um currículo ou em uma referência?

Open source é um presente para aqueles que precisam contratar pessoas técnicas. Com open source, você pode rastrear o trabalho e as contribuições de alguém — boas e ruins — por um longo período de tempo.

Isso significa que você pode julgar as pessoas por suas ações em vez de apenas suas palavras. Você pode tomar uma decisão baseada nas coisas que realmente importam:

Qualidade do trabalho

Muitos programadores podem falar bem, mas tropeçam na hora de mostrar serviço. Com open source, você obtém os detalhes específicos das habilidades e práticas de programação de uma pessoa.

Perspectiva cultural

Programar é sobre decisões.

Ações, não palavras 539 words

Busque pessoas equilibradas

Prefira generalistas que aprendizado rápido em vez de especialistas enraizados

Nós nunca contrataremos alguém que seja um arquiteto de informação. É simplesmente muito específico. Com uma equipe pequena como a nossa, não faz sentido contratar pessoas com um conjunto de habilidades tão limitado.

Equipes pequenas precisam de pessoas que possam usar diferentes chapéus. Você precisa de designers que possam escrever. Você precisa de programadores que entendam de design. Todos deveriam ter uma ideia sobre como arquitetar informações (o que quer que isso signifique). Todos precisam ter uma mente organizada. Todos precisam ser capazes de se comunicar com os clientes.

E todos precisam estar dispostos e aptos a mudar de direção no futuro. Lembre-se de que equipes pequenas frequentemente precisam mudar de direção e fazer isso rapidamente. Você quer alguém que possa se ajustar, aprender e fluir ao invés de alguém que só sabe fazer uma coisa e não se adapta.

Busque pessoas equilibradas 155 words

Não se finge empolgação

Prefira feliz e competente do que frustrado e excelente

Entusiasmo. É uma característica que simplesmente não pode ser fingida. Quando chegar a hora de contratar, não pense que você precisa de um guru ou de uma celebridade da tecnologia. Provavelmente eles já foram mimados demais de qualquer forma. Um funcionário feliz, ainda que mediano, é melhor do que um especialista descontente.

Encontre alguém entusiasmado. Alguém em quem você possa confiar para fazer as coisas quando deixado sozinho. Alguém que tenha sofrido em uma empresa maior e mais lenta e anseie por um novo ambiente. Alguém que esteja empolgado para construir o que você está construindo. Alguém que odeie as mesmas coisas que você odeia. Alguém que esteja animado para embarcar no seu projeto.

Pontos extras por fazer perguntas

Observe se um candidato em potencial faz muitas perguntas sobre o seu projeto. Programadores apaixonados desejam entender um problema o melhor possível e rapidamente querem pro

Não se finge empolgação 229 words

Letristas

Contrate bons escritores

Se você está tentando decidir entre algumas pessoas para preencher uma posição, sempre contrate o melhor escritor. Não importa se essa pessoa é um designer, programador, profissional de marketing, vendedor ou qualquer coisa, as habilidades de escrita vão valer a pena. Escrita e edição eficazes e concisas levam a código, design, e-mails, mensagens instantâneas e todo o resto mais eficazes e concisos.

Isso porque ser um bom escritor é mais do que palavras. Bons escritores sabem como se comunicar. Eles tornam as coisas fáceis de entender. Eles conseguem se colocar no lugar de outra pessoa. Eles sabem o que omitir. Eles pensam claramente. E essas são as qualidades que você precisa.

Uma Mente Organizada

Boas habilidades de escrita são indicadoras de uma mente organizada que é capaz de arranjar informações e argumentos de forma sistemática e também ajudar (não fazer) outras pessoas a entenderem as coisas. Isso transborda para o código, comunicações pesso

Letristas 259 words

Design de interface

Interface primeiro

Desenhe a interface antes de começar a programar

Muitos aplicativos começam com uma mentalidade de programar primeiro. Isso é não é uma boa ideia. Programar é o componente mais pesado na construção de um app, o que significa que é o mais caro e o mais difícil de mudar. Em vez disso, comece pelo design.

O design é relativamente leve. Um esboço no papel é barato e fácil de mudar. Os designs em HTML ainda são simples de modificar (ou descartar). Isso não é verdade na programação. Começar pelo design mantém você flexível. Programar primeiro te limita e prepara o terreno para custos adicionais.

Outro motivo para começar pelo design é que a interface é o seu produto. O que as pessoas veem é o que você está vendendo. Se você simplesmente colocar uma interface no final, as lacunas vão aparecer.

Nós começamos com a interface para podermos ver qual é a cara do app e como seria usá-lo desde o início. Ela está constantemente sendo revisada ao longo do processo. Faz sentido? É fáci

Interface primeiro 560 words

Design pelo epicentro

Comece pelo centro da página e construa de dentro para fora

O design pelo epicentro foca na verdadeira essência da página — o epicentro — e depois constrói de dentro para fora. Isso significa que, no início, você ignora as extremidades: a navegação/abas, rodapé, cores, barra lateral, logo, etc. Em vez disso, você começa pelo epicentro e desenha a peça mais importante do conteúdo primeiro.

O que a página absolutamente não pode viver sem é o epicentro. Por exemplo, se você está projetando uma página que exibe uma postagem de blog, a própria postagem do blog é o epicentro. Não as categorias na barra lateral, não o cabeçalho no topo, não o formulário de comentários no fundo, mas a unidade real da postagem do blog. Sem a unidade da postagem do blog, a página não é uma postagem de blog.

Só quando essa unidade estiver completa é que você começaria a pensar no segundo elemento mais crítico na página. Depois do segundo elemento mais crítico, você passaria para o terceiro, e ass

Design pelo epicentro 324 words

Soluções em três estados

Desenhe para estados regulares, em branco e de erro

Para cada tela, você precisa considerar três possíveis estados:

Regular

A tela que as pessoas veem quando tudo está funcionando bem e seu aplicativo está cheio de dados.

Em Branco

A tela que as pessoas veem quando usam o aplicativo pela primeira vez, antes que os dados sejam inseridos.

Erro

A tela que as pessoas veem quando algo dá errado.

O estado regular é óbvio. Esta é a tela onde você passará a maior parte do seu tempo. Mas não se esqueça de investir tempo nos outros estados também.

Soluções em três estados 107 words

A folha em branco

Estabeleça expectativas com uma experiência bem pensada

Ignorar o estágio de tela em branco (blank state) é um dos maiores erros que você pode cometer. A tela em branco é a primeira impressão do seu aplicativo e você nunca tem uma segunda... bem, você sabe.

O problema é que, ao desenhar uma UI, geralmente ela está cheia de dados. Os designers sempre preenchem templates com dados. Cada lista, cada postagem, cada campo, cada cantinho tem algo nele. E isso significa que a tela parece e funciona muito bem.

No entanto, o estado natural do aplicativo é um que está desprovido de dados. Quando alguém se inscreve, começa com uma folha em branco. Muito como um weblog, cabe a eles populá-lo — a aparência geral e a sensação não tomam forma até que as pessoas insiram seus dados: postagens, links, comentários, horas, informações da barra lateral ou o que for.

Infelizmente, o cliente decide se um aplicativo vale a pena nesse estágio de tela em branco — o estágio quando há a menor quan

A folha em branco 520 words

Jogue na defensiva

Desenhe para quando as coisas derem errado

Vamos admitir: Coisas vão dar errado online. Não importa o quanto você desenhe seu aplicativo cuidadosamente, não importa quanto teste você faça, os clientes ainda encontrarão problemas. Então, como você lida com essas quebras inevitáveis? Com design defensivo.

Design defensivo é como dirigir defensivamente. Da mesma forma que os motoristas devem estar sempre atentos a estradas escorregadias, motoristas imprudentes e outros cenários perigosos, os construtores de sites devem constantemente procurar por pontos problemáticos que causam confusão e frustração aos visitantes. Uma boa defesa do site pode fazer ou desfazer a experiência do cliente.

Poderíamos preencher um livro separado com todas as coisas que temos a dizer sobre design defensivo. Na verdade, já fizemos. "Defensive Design for the Web" é o título e é um ótimo recurso para quem quer aprender a melhorar telas de erro e outros pontos de crise.

Lembre-se: Seu aplicativo po

Jogue na defensiva 177 words

Contexto acima de consistência

O que faz sentido aqui pode não fazer sentido lá

As ações devem ser botões ou links? Depende da ação. Uma visualização de calendário deve ser em forma de lista ou grade? Depende de onde está sendo mostrada e quanto tempo dura o período. Todo link de navegação global precisa estar em toda página? Você precisa de uma barra de busca global em todo lugar? Você precisa exatamente do mesmo rodapé em cada página? A resposta: "Depende".

É por isso que o contexto é mais importante do que a consistência. Está tudo bem ser inconsistente se o seu design faz mais sentido dessa maneira. Dê às pessoas apenas o que importa. Dê a elas o que precisam quando precisam e livre-se do que não precisam. É melhor estar certo do que ser consistente.

Inconsistência Inteligente

A consistência não é necessária. Por anos, estudantes de UI e UX foram ensinados que a consistência na interface é uma das regras cardinais do design de interface. Talvez isso se mantenha em software, mas

Contexto acima de consistência 260 words

Copywriting é design de interface

Cada letra importa

Copywriting é design de interface. Grandes interfaces são escritas. Se você acha que cada pixel, ícone e fonte importam, então você também deve acreditar que cada letra importa. Quando estiver escrevendo sua interface, sempre se coloque no lugar da pessoa que está lendo. O que ela precisa saber? Como você pode explicar isso de forma sucinta e clara?

Você rotula um botão como “Enviar”, “Salvar”, “Atualizar”, “Novo” ou “Criar”? Isso é copywriting. Você escreve três frases ou cinco? Explica com exemplos gerais ou com detalhes? Rotula o conteúdo como “Novo”, “Atualizado”, “Recentemente Atualizado” ou “Modificado”? É “Tem mensagens novas: 5” ou “Há 5 mensagens novas” ou é só “5” ou “cinco” ou “mensagens” ou “posts”? Tudo isso importa.

Você também precisa falar a mesma língua do seu público. Só porque você está escrevendo um aplicativo web não significa que você pode usar jargão técnico. Pense nos seus clientes e no que esses botões e palavras

Copywriting é design de interface 251 words

Uma interface

Incorpore funções administrativas na interface pública

Telas administrativas — as telas usadas para gerenciar preferências, pessoas, etc. — tendem a ter uma aparência ruim. Isso acontece porque a maior parte do tempo de desenvolvimento é gasta na interface voltada para o público.

Para evitar a síndrome da tela administrativa ruim, não construa telas separadas para lidar com funções administrativas. Em vez disso, incorpore essas funções (ou seja, editar, adicionar, deletar) na interface regular da aplicação.

Se você tiver que manter duas interfaces separadas (ou seja, uma para o público geral e outra para administradores), ambas sofrerão. Na prática, você acaba pagando o mesmo imposto duas vezes. Você é forçado a se repetir e isso significa que você aumenta as chances de ser descuidado. Quanto menos telas você tiver que se preocupar, melhor elas serão.

Sem Interface Separada

A aplicação é tudo. Tudo o que pode ser alterado, adicionado ou ajustado pode ser feito diret

Uma interface 261 words

Código

Menos software

Mantenha seu código o mais simples possível

Você poderia pensar que o dobro de código tornaria seu software apenas duas vezes mais complexo. Mas, na verdade, cada vez que você aumenta a quantidade de código, seu software se torna exponencialmente mais complicado. Cada pequena adição, cada mudança, cada interdependência e cada preferência tem um efeito cascata. Continue adicionando código sem critério e, antes que perceba, você terá criado a temida Grande Bola de Lama.

A maneira de combater essa complexidade é com menos software. Menos software significa menos funcionalidades, menos código, menos desperdício.

A chave é reformular qualquer problema difícil que exija muito software em um problema simples que exige muito menos. Talvez você não esteja resolvendo exatamente o mesmo problema, mas tudo bem. Resolver 80% do problema original com 20% do esforço é uma grande vitória. O problema original quase nunca é tão grave que valha a pena cinco vezes o esforço para resolvê-lo.

Menos software 712 words

Otimize para Felicidade

Escolha ferramentas que mantenham sua equipe animada e motivada

Um programador feliz é um programador produtivo. É por isso que otimizamos para a felicidade e você também deveria. Não escolha ferramentas e práticas baseando-se apenas em padrões da indústria ou métricas de desempenho. Olhe para os intangíveis: Existe paixão, orgulho e maestria aqui? Você realmente seria feliz trabalhando nesse ambiente oito horas por dia?

Isso é especialmente importante ao escolher uma linguagem de programação. Apesar da percepção pública do contrário, elas não são criadas iguais. Enquanto praticamente qualquer linguagem pode criar praticamente qualquer aplicação, a certa torna o esforço não apenas possível ou suportável, mas agradável e revigorante. É tudo sobre tornar os pequenos detalhes do trabalho diário prazerosos.

A felicidade tem um efeito cascata. Programadores felizes fazem a coisa certa. Eles escrevem código simples, legível. Eles adotam abordagens limpas, expressivas, legí

Otimize para Felicidade 244 words

O código fala

Escute quando seu código reage

Escute o seu código. Ele oferecerá sugestões. Ele reagirá. Ele vai lhe dizer onde residem os perigos. Ele sugerirá novas maneiras de fazer as coisas. Ele vai ajudá-lo a manter um modelo de menos software.

Uma nova funcionalidade está exigindo semanas de tempo e milhares de linhas de código? Isso é o seu código lhe dizendo que provavelmente existe uma maneira melhor. Há uma maneira simples de codar algo em uma hora em vez de uma maneira complicada que levará dez horas? De novo, isso é o seu código guiando você. Escute.

Seu código pode guiá-lo para correções que são baratas e leves. Preste atenção quando um caminho fácil surgir. Claro, a funcionalidade que é fácil de fazer pode não ser exatamente a mesma que você tinha em mente originalmente, mas e daí? Se funciona bem o suficiente e lhe dá mais tempo para trabalhar em outra coisa importante, vale a pena mantê-la.

Fique atento

Não se preocupe com o design, se você escutar o seu código, u

O código fala 259 words

Gerencie dívidas

Pague suas "dívidas" de código e design

Costumamos pensar em dívida em termos de dinheiro, mas ela vem em outras formas também. Você pode facilmente acumular dívidas de código e design.

Junte um código ruim que é funcional, mas ainda um pouco complicado e você está acumulando dívida. Monte um design que é bom o suficiente, mas não realmente bom e você fez isso novamente.

É ok fazer isso de vez em quando. De fato, muitas vezes é uma técnica necessária que ajuda você a fazer a coisa toda de Tornar-Real-ASAP. Mas você ainda precisa reconhecê-la como dívida e pagá-la em algum momento, limpando o código complicado ou redesenhando aquela página mais ou menos.

Da mesma maneira que você deve regularmente reservar uma parte de sua renda para impostos, regularmente reserve um tempo para pagar sua dívida de código e design. Se você não fizer isso, você estará apenas pagando juros (corrigindo gambiarras) em vez de pagar o principal (e avançando).

Gerencie dívidas 165 words

Abra portas

Leve os dados para o mundo via RSS, APIs, etc

Não tente aprisionar seus clientes. Deixe-os obter suas informações quando quiserem e como quiserem. Para fazer isso, você tem que abandonar a ideia de selar os dados. Em vez disso, deixe-os correr soltos. Dê às pessoas acesso às suas informações via feeds RSS. Ofereça APIs que permitam a desenvolvedores terceiros construir em cima da sua ferramenta. Quando você faz isso, torna a vida dos clientes mais conveniente e expande as possibilidades do que seu aplicativo pode fazer.

As pessoas costumavam pensar em feeds RSS apenas como uma boa maneira de acompanhar blogs ou sites de notícias. Os feeds têm mais poder do que isso, no entanto. Eles também oferecem uma ótima maneira para os clientes se manterem atualizados sobre o conteúdo mutável de um aplicativo sem ter que fazer login repetidamente. Com os feeds do Basecamp, os clientes podem colocar a URL em um leitor de notícias e ficar de olho nas mensagens do projeto, listas de tarefas e mar

Abra portas 524 words

Palavras

Não há nada funcional sobre specs funcionais

Não escreva um documento de especificações funcionais

Esses documentos de projeto geralmente acabam tendo quase nada a ver com o produto finalizado. Aqui está o porquê:

Especificações funcionais são fantasias

Elas não refletem a realidade. Um aplicativo não é real até que os construtores estejam construindo, os designers estejam desenhando, e as pessoas estejam usando. Especificações funcionais são apenas palavras no papel.

Especificações funcionais são sobre apaziguamento

Elas são sobre fazer todos se sentirem envolvidos e felizes o que, embora caloroso e fofinho, não é tão útil. Elas nunca são sobre fazer escolhas difíceis e expor custos, coisas que precisam acontecer para construir um ótimo aplicativo.

Especificações funcionais apenas levam a uma ilusão de acordo

Um grupo de pessoas concordando em parágrafos de texto não é um verdadeiro acordo. Todos podem estar lendo a mesma coisa, mas estão pensando algo diferente. Is

Não há nada funcional sobre specs funcionais 720 words

Não crie documentos mortos

Elimine papelada desnecessária

Evitar especificações funcionais é um bom começo, mas não pare por aí; previna excesso de papelada em todos os lugares. A menos que um documento vá realmente se transformar em algo real, não o produza.

Construa, não escreva. Se você precisa explicar algo, tente fazer um mockup e prototipá-lo em vez de escrever um documento longo. Uma interface real ou protótipo está a caminho de se tornar um produto real. Um pedaço de papel, por outro lado, está apenas a caminho da lixeira.

Aqui vai um exemplo: Se um documento de wireframe está destinado a parar e nunca se tornar o design real, não se dê ao trabalho de fazê-lo. Se o wireframe começa como um wireframe e depois se transforma no design real, vá em frente.

Documentos que vivem separadamente da sua aplicação são inúteis. Eles não te levam a lugar nenhum. Tudo o que você faz deve evoluir para a coisa real. Se um documento para antes de se tornar real, ele está morto.

Ninguém Vai

Não crie documentos mortos 349 words

Me conte uma história breve

Escreva histórias, não detalhes

Se você realmente precisar usar palavras para explicar um novo recurso ou conceito, escreva uma breve história sobre isso. Não entre nos detalhes técnicos ou de design, apenas conte uma história rápida. Faça isso de uma maneira humana, como você faria em uma conversa normal.

Não precisa ser um ensaio. Apenas descreva o fluxo do que acontece. E se você puder incluir a breve história em contexto com as telas que está desenvolvendo, melhor ainda.

Concentre-se na experiência ao invés de ficar preso aos detalhes. Pense em estratégia, não em táticas. As táticas se encaixarão assim que você começar a construir essa parte do seu aplicativo. Agora, você só quer criar uma história que iniciará conversas e colocará você no caminho certo.

Me conte uma história breve 133 words

Use palavras reais

Insira texto real em vez de Lorem Ipsum

Lorem ipsum é um amigo confiável dos designers. Textos fictícios ajudam as pessoas a entender como o design ficará uma vez que esteja completo. Mas o texto fictício também pode ser perigoso.

Lorem ipsum muda a maneira como o texto é visto. Ele reduz o conteúdo baseado em texto a um elemento de design visual — uma forma de texto — em vez do que deveria ser: informações valiosas que alguém vai ter que inserir e/ou ler. Texto fictício significa que você não verá as variações inevitáveis que aparecem uma vez que informações reais são inseridas. Significa que você não saberá como é preencher formulários no seu site. Texto fictício é um véu entre você e a realidade.

Você precisa de texto real para saber quão compridos certos campos devem ser. Você precisa de texto real para ver como tabelas vão expandir ou contrair. Você precisa de texto real para saber como seu aplicativo realmente se parece.

Assim que puder, use palavras reais e rele

Use palavras reais 432 words

Personifique seu produto

Qual é a personalidade do seu produto?

Pense no seu produto como se fosse uma pessoa. Que tipo de pessoa você quer que ele seja? Educado? Sério? Perdoador? Estrito? Engraçado? Sério? Sério? Descontraído? Você quer que ele pareça paranóico ou confiável? Como um sabichão? Ou modesto e simpático?

Uma vez que decida, sempre mantenha essas características de personalidade em mente à medida que o produto é construído. Use-as para guiar a redação, a interface e o conjunto de recursos. Sempre que fizer uma mudança, pergunte-se se essa mudança se encaixa na personalidade do seu aplicativo.

Seu produto tem uma voz — e está falando com seus clientes 24 horas por dia.

Personifique seu produto 116 words

Precificação e cadastros

Amostras grátis

Dê algo de graça

É um mundo barulhento lá fora. Para fazer as pessoas te notarem no meio desse ruído, você precisa dar algo de graça.

Empresas inteligentes sabem que dar brindes é uma ótima maneira de atrair clientes. Veja a Apple. Eles oferecem o software iTunes de graça para aumentar a demanda pelo iPod e pela loja de músicas iTunes. No mundo offline, as lojas de varejo fazem o mesmo. A Starbucks diz uma nova compra é estimulada a cada cinco amostras de bebidas que dão aos clientes. Nada mal.

Para nós, Writeboard e Ta-da List são aplicativos completamente gratuitos que usamos para levar as pessoas a usar nossos outros produtos. Além disso, sempre oferecemos alguma versão gratuita de todos os nossos aplicativos.

Queremos que as pessoas experimentem o produto, a interface, a utilidade do que construímos. Uma vez que estão ”fisgadas”, elas têm muito mais chances de fazer upgrade para um dos planos pagos (que permitem mais projetos ou páginas e dão acesso a recursos adicion

Amostras grátis 328 words

Vem fácil, vai fácil

Torne o processo de inscrição e cancelamento tranquilo

Facilite ao máximo a entrada — e saída — do seu app.

Se eu sou um cliente querendo usar seu app, o processo tem que ser tranquilo, sem dor de cabeça. Faça um botão de inscrição grande, chamativo, que se destaque, e coloque-o em cada página do seu site de marketing. Diga para todo mundo como é fácil: "Do cadastro ao login em apenas 1 minuto!"

Deve sempre haver uma opção gratuita, assim os clientes podem testar o app sem precisar informar dados de cartão de crédito. Alguns dos nossos concorrentes exigem uma ligação, um agendamento ou uma senha especial para testar o produto. Qual é a dessa? Nós deixamos qualquer um experimentar nossos apps de graça a qualquer momento.

Mantenha o formulário de inscrição o mais curto possível. Não peça informações que você não precisa e não assuste as pessoas com um formulário longo e intimidador.

Os mesmos princípios valem para o processo de cancelamento. Você nunca quer "prender

Fácil entrar, fácil sair 392 words

Truques são para crianças

Evite contratos de longo prazo, taxas de inscrição, etc

Ninguém gosta de contratos de longo prazo, taxas de rescisão antecipada ou taxas únicas de configuração. Então, evite-os. Nossos produtos são cobrados em uma base mensal. Não há contrato para assinar e você pode cancelar a qualquer momento sem penalidade. E nunca há taxas de configuração.

Não tente encontrar maneiras "espertas" de conseguir mais dinheiro. Faça por onde.

Truques são para crianças 73 words

Uma bala mais suave

Suavize o impacto de más notícias

Precisa entregar más notícias, como um aumento de preço? Torne isso o menos doloroso possível, dando às pessoas bastante antecedência. Além disso, considere um período de carência que isente os clientes existentes por um determinado tempo. Essas pessoas são a sua base e você quer fazê-las se sentir valorizadas, não exploradas.

Uma bala mais suave 63 words

Divulgação

Lançamento de cinema

De teaser a prévia até o lançamento

Se um aplicativo é lançado em uma floresta e não há ninguém lá para usá-lo, ele faz barulho? O ponto aqui é que, se você lançar seu aplicativo sem nenhum pré-hype, as pessoas não vão saber sobre ele.

Para construir expectativa e antecipação, siga um lançamento estilo Hollywood: 1) Teaser, 2) Prévia, e 3) Lançamento.

Teaser

Alguns meses antes, comece a dar pistas. Deixe as pessoas saberem no que você está trabalhando. Poste um logotipo. Poste no seu blog sobre o desenvolvimento. Mantenha-se vago, mas plante a semente. Também, monte um site onde você possa coletar emails de pessoas interessadas.

Nesta fase, você também deve começar a seduzir os entendidos e insiders. Essas são as pessoas na vanguarda. Eles são os formadores de opinião. Apelo à vaidade deles e status como pioneiros. Diga que eles estão recebendo uma prévia exclusiva. Se um site como Boing Boing, Slashdot ou Digg linkar seu aplicativo, você vai receber uma carga

Lançamento de cinema 800 words

Um site promocional poderoso

De teaser a prévia até o lançamento

A melhor ferramenta de promoção é um ótimo produto. A notícia se espalhará se você tem um aplicativo que as pessoas acham realmente útil.

Ainda assim, você também precisa de um site promocional de primeira. O que você deve incluir neste site? Algumas ideias:

Visão Geral: Explique seu aplicativo e seus benefícios.
Tour: Guie as pessoas pelas várias funcionalidades.
Capturas de tela e vídeos: Mostre às pessoas como o aplicativo realmente parece e como usá-lo.
Manifesto: Explique a filosofia e ideias por trás dele.
Estudos de Caso: Forneça exemplos da vida real que mostram o que é possível.
Buzz: Citações de testemunhos de clientes, resenhas, imprensa, etc.
Fórum: Ofereça um lugar para membros da comunidade ajudarem uns aos outros.
Preços & Inscrição: Leve as pessoas para dentro do seu aplicativo o mais rápido possível.
Blog: Blogs mantêm seu site atualizado com notíci

Um site promocional poderoso 166 words

Surfe a onda do conteúdo

Criar conteúdo pode ser mais eficaz que anunciar (e é muito mais barato)

Anunciar é caro. E avaliar a eficácia de vários tipos de publicidade pode acabar sendo ainda mais caro que a própria publicidade. Quando você não tem tempo ou dinheiro para seguir a rota tradicional de publicidade, considere a rota de promoção via blog ou conteúdo.

Comece criando um blog que não apenas promove seu produto, mas também oferece conselhos úteis, dicas, truques, links, etc. Nosso blog Signal vs. Noise recebe milhares de leitores únicos por semana graças às informações úteis, informativas e interessantes que postamos diariamente.

Então, quando chegou a hora de promover nosso primeiro produto, Basecamp, começamos por lá. Divulgamos a palavra no SvN e ela começou a se espalhar. Pessoas como Jason Kottke, os BoingBoingers, Jim Coudal e uma variedade de outras pessoas com blogs populares ajudaram a aumentar a visibilidade e as coisas decolaram.

Ta-da List é outro ótimo exemplo do pode

Surfe a onda do conteúdo 229 words

Peça o quanto antes

Comece a criar expectativa e inscrições o quanto antes

Já tocamos no assunto, mas vale a pena repetir: coloque algum tipo de site no ar e comece a coletar e-mails o quanto antes. Escolha o nome do seu domínio e coloque um logotipo e talvez uma frase ou duas que descrevam, ou pelo menos dêem uma ideia, do que seu aplicativo fará. Depois, deixe as pessoas fornecerem o endereço de e-mail delas. Agora você está no caminho para ter uma base de pessoas prontas e esperando para serem notificadas do seu lançamento.

Peça o quanto antes 98 words

Divulgue Através da Educação

Compartilhe seu conhecimento com o mundo

Quando um professor aparece em algum reality show, frequentemente ouve-se comentários de que essa é uma "profissão nobre". Esses comentários estão certos. Há definitivamente algo maravilhoso e gratificante em compartilhar seu conhecimento com os outros. E quando o assunto que você está ensinando é o seu produto, isso serve a um duplo propósito: Você pode retribuir à comunidade que te apoia e ao mesmo tempo conseguir uma boa exposição.

Como divulgação, a educação é uma forma suave de colocar seu nome — e o nome do seu produto — na frente de mais pessoas. E, em vez de uma abordagem de venda direta 'compre este produto', você ganha atenção fornecendo um serviço valioso. Isso cria um burburinho positivo que as táticas de marketing tradicionais não conseguem igualar. Pessoas que você educa se tornarão seus evangelistas.

A educação pode vir em muitas formas. Poste dicas e truques no seu site que as pessoas vão querer compar

Divulgue Através da Educação 528 words

Sirva funcionalidades

Eles estão famintos por isso, então sirva

Novas ou interessantes funcionalidades são uma ótima maneira de gerar buzz para o seu aplicativo. Grupos de interesse especial adoram se alimentar funcionalidades e cuspi-las de volta para a comunidade. Certo, essa é uma analogia meio desagradável, mas você entendeu o ponto.

Por exemplo, ao usar Ruby on Rails, uma nova plataforma de desenvolvimento, geramos uma tonelada de atenção para o Basecamp dentro da comunidade de desenvolvedores.

Os elementos Ajax que usamos em nossos aplicativos receberam muita atenção e até levaram a revista Business 2.0 a nomear o Basecamp como um "player chave em Ajax" ao lado de grandes nomes como Google, Yahoo, Microsoft e Amazon.

Outro exemplo: Blogueiros notaram o suporte a RSS do Basecamp, já que foi um dos primeiros exemplos de negócios usando RSS.

Integração com iCal, uma funcionalidade aparentemente menor, nos deu imprensa em uma tonelada de sites relacionados a Mac que provavelmente nu

Sirva funcionalidades 256 words

Acompanhe seus rastros

Estude seus registros para acompanhar o buzz

Você precisa saber quem está falando sobre você. Verifique seus registros e descubra de onde vem o buzz. Quem está gerando links para você? Quem está reclamando de você? Quais blogs listados no Technorati, Blogdex, Feedster, Del.icio.us e Daypop estão te acompanhando?

Descubra e então marque sua presença. Deixe comentários nesses blogs. Agradeça às pessoas por postarem links. Pergunte se elas querem ser incluídas na sua lista especial para que sejam algumas das primeiras a saber sobre futuros lançamentos, atualizações, etc. Colete elogios positivos e crie uma página de “buzz” no seu site. Depoimentos são uma ótima maneira de promover seu aplicativo, já que elogios de terceiros são mais confiáveis para a maioria das pessoas.

Se os comentários forem negativos, ainda assim preste atenção. Mostre que você está ouvindo. Responda às críticas de forma pensada. Algo como: “Agradecemos o feedback, mas fizemos dessa maneira porque...

Acompanhe seus rastros 199 words

Upsell em contexto

Promova oportunidades de upgrade dentro do aplicativo

Todo mundo sabe que se deve vender na landing page. Mas a venda não deve parar por aí. Se você tem um plano de preços escalonado (ou uma versão gratuita do seu aplicativo), não esqueça de destacar as oportunidades de upgrade dentro do produto.

Informe às pessoas que você removerá barreiras se elas fizerem um upgrade. Por exemplo, no Basecamp, você não podia fazer upload de arquivos se tivesse uma conta gratuita. Quando alguém tenta fazer upload de um arquivo, nós não apenas os recusamos. Explicamos por que o upload de arquivos não está disponível e incentivamos a fazer o upgrade para a versão paga e explicamos por que isso é uma boa ideia. A mesma abordagem é usada para incentivar clientes existentes a fazerem upgrade para uma conta de nível superior quando eles atingem o limite do seu plano atual.

Clientes existentes são sua melhor aposta para vendas. Não tenha receio de tentar vender repetidas vezes para pessoas que

Upsell em contexto 178 words

Nome que cole

Dê ao seu aplicativo um nome fácil de lembrar

Um grande erro que muitas pessoas cometem é pensar que o nome do seu aplicativo precisa ser ultra descritivo. Não se preocupe em escolher um nome que descreva vividamente o propósito da sua ferramenta; Isso geralmente leva a um nome genérico e esquecível. Basecamp é um nome melhor do que algo como Centro de Gerenciamento de Projetos ou ProjetoExpresso. Writeboard é melhor do que ColaboraEdição.

Além disso, não transforme o processo de nomeação em algo excessivamente burocrático ou decidido por comissões. Escolha um nome que seja curto, cativante e memorável e siga em frente com ele.

E não se preocupe se você não conseguir o nome de domínio exato que quer. Você sempre pode ser criativo e chegar perto com algumas letras extras (por exemplo, backpackit.com ou campfirenow.com).

O fácil resolve

A indústria da tecnologia não percebe que pensar em nomes cativantes e autoexplicativos acabaria beneficiando-a da mesma maneira? Ele

Nome que cole 237 words

Suporte

Sinta a dor

Derrube as paredes entre suporte e desenvolvimento

No ramo de restaurantes, há um mundo de diferença entre aqueles que trabalham na cozinha e aqueles da linha de frente que lidam com os clientes. É importante que ambos os lados se entendam e se coloquem no lugar do outro. É por isso que escolas de culinária e restaurantes frequentemente fazem com que chefs trabalhem como garçons, para que a equipe da cozinha possa interagir com os clientes e ver como é de fato a linha de frente.

Muitos desenvolvedores de software têm uma divisão semelhante. Designers e programadores trabalham na “cozinha” enquanto o suporte lida com os clientes. Infelizmente, isso significa que os chefs do software nunca chegam a ouvir o que os clientes estão de fato dizendo. Isso é problemático porque ouvir os clientes é a melhor maneira de entender os pontos fortes e fracos do seu produto.

A solução? Evite construir paredes entre seus clientes e a equipe de desenvolvimento/design. Não terceirize o suporte ao c

Sinta a dor 529 words

Treinamento zero

Use ajuda integrada e FAQs para que seu produto não exija manual ou treinamento

Você não precisa de um manual para usar o Yahoo, Google ou Amazon. Então, por que não pode construir um produto que não exija um manual? Esforce-se para criar uma ferramenta que não necessite de treinamento algum.

Como fazer isso? Bem, como já mencionamos antes, você começa mantendo tudo simples. Quanto menos complexo for seu aplicativo, menos você precisará ajudar as pessoas a sair da confusão. Depois disso, uma ótima maneira de prevenir o suporte é usando ajuda integrada e FAQs nos pontos potenciais de confusão.

Por exemplo, oferecemos suporte preventivo na tela que permite às pessoas fazerem upload do seu logo no Basecamp. Algumas pessoas enfrentavam um problema onde continuavam vendo um logo antigo devido a um problema de cache do navegador. Então, ao lado da área de “enviar seu logo”, adicionamos um link para um FAQ que instruía os clientes a forçarem o recarregamento de seus navegadores pa

Treinamento zero 188 words

Responda rápido

Tempo rápido de resposta a consultas de suporte deve ser uma prioridade máxima

Os clientes ficam encantados quando você responde às perguntas deles rapidamente. Eles estão tão acostumados a respostas automáticas que aparecem dias depois (se aparecem) que você pode realmente se diferenciar dos concorrentes oferecendo uma resposta ponderada imediatamente. Durante o horário comercial, respondemos 90% de todas as solicitações de suporte por e-mail em 90 minutos — e muitas vezes em meia hora. E as pessoas adoram isso.

Mesmo que você não tenha uma resposta perfeita, diga algo. Você pode comprar boa vontade com uma resposta que é entregue rapidamente de uma maneira aberta e honesta. Se alguém está reclamando sobre um problema que não pode ser corrigido imediatamente, diga algo como, “Ouvimos o que você está dizendo e trabalharemos nisso no futuro.” É uma ótima maneira de desarmar uma situação potencialmente negativa.

Os clientes apreciam a franqueza e muitas vezes mudam de irritado

Responda rápido 462 words

O cliente nem sempre tem razão

Esteja disposto a dizer não aos seus clientes

Quando se trata de pedidos de novas funcionalidades, o cliente nem sempre tem razão. Se adicionássemos tudo o que nossos clientes pedem, ninguém ia querer nossos produtos.

Se obedecêssemos a todos as vontas dos usuários, o Basecamp teria: um sistema abrangente de controle de tempo, faturamento completo, agendamento de reuniões detalhado, calendário completo, sistema complexo de tarefas dependentes, chat de mensagens instantâneas completo, funcionalidade de wiki abrangente e tudo mais que você possa imaginar.

Ainda assim, o pedido nº 1 que recebemos nas pesquisas com clientes é manter o Basecamp simples.

Aqui vai outro exemplo: Apesar de algumas reclamações, decidimos não oferecer suporte ao IE5 em nossos produtos. Isso significava ignorar 7% do mercado. Mas decidimos que era mais importante nos preocuparmos com os outros 93%. Corrigir bugs e testar para o IE5 simplesmente não vale o tempo. Preferimos fazer u

O cliente nem sempre tem razão 258 words

Fóruns de comunidade

Use fóruns ou chat para permitir que os clientes se ajudem mutuamente

Fóruns e chats em grupo baseados na web são uma ótima maneira de permitir que os clientes façam perguntas e se ajudem. Ao eliminar o intermediário — ou seja, você — você fornece um fluxo aberto de comunicação e economiza tempo no processo.

Em nossos fóruns de produtos, clientes postam dicas e truques, solicitações de recursos, histórias e mais. Nós aparecemos de vez em quando para oferecer alguma assistência, mas os fóruns são principalmente um lugar para a comunidade se ajudar e compartilhar suas experiências com o produto.

Você ficará surpreso com o quanto as pessoas querem ajudar umas às outras.

Fóruns de comunidade 118 words

Torne seus erros públicos

Divulgue más notícias rapidamente e resolva o assunto

Se algo der errado, conte às pessoas. Mesmo que elas nunca tenham percebido por conta própria.

Por exemplo, o Basecamp ficou fora do ar uma vez por algumas horas durante a noite. 99% dos nossos clientes nunca souberam, mas ainda assim postamos um aviso de "interrupção inesperada" no nosso blog Everything Basecamp. Achamos que nossos clientes mereciam saber.

Aqui está um exemplo do que postamos quando algo dá errado: “Pedimos desculpas pela interrupção desta manhã — tivemos alguns problemas com o banco de dados que causaram grandes lentidões e interrupções para algumas pessoas. Corrigimos o problema e estamos tomando medidas para garantir que isso não aconteça novamente... Obrigado pela sua paciência e, mais uma vez, pedimos desculpas pela interrupção.”

Seja o mais aberto, honesto e transparente possível. Não guarde segredos ou se esconda atrás de manobras de relações públicas. Um cliente informado é o seu m

Torne seus erros públicos 302 words

Pós-lançamento

Calibre em um mês

Lance uma atualização importante 30 dias após o lançamento

Uma atualização rápida mostra dinamismo. Mostra que você está ouvindo. Mostra que você tem mais truques na manga. Isso dá uma segunda onda de buzz. Reafirma os bons sentimentos iniciais. Dá algo para você falar e outros para escreverem a respeito.

Saber que uma atualização rápida está a caminho também permite que você coloque o foco nos componentes mais cruciais antes do lançamento. Em vez de tentar incluir mais algumas coisas, você pode começar aperfeiçoando apenas o conjunto de recursos essenciais. Então você pode "arejar" o produto no mundo real. Uma vez que está lá fora, você pode começar a receber feedback dos clientes e saberá quais áreas precisam de atenção em seguida.

Esta abordagem de pequenos passos funcionou bem para o Backpack. Lançamos o produto base primeiro e então, algumas semanas depois, adicionamos recursos como o Backpack Mobile para dispositivos móveis e tagging, já que essas são as coisas que n

Calibre em um mês 173 words

Mantenha os posts fluindo

Mostre que seu produto está vivo mantendo um blog de desenvolvimento do produto pós-lançamento

Não pare de escrever uma vez que você lançar. Mostre que seu produto é uma criatura viva mantendo um blog dedicado que você atualiza frequentemente (pelo menos uma vez por semana, mais vezes se puder).

Coisas para incluir:

FAQ- Como fazer
Dicas & truques
Novas funcionalidades, atualizações & correções
Buzz/imprensa

Um blog não apenas mostra que seu aplicativo está vivo, ele faz sua empresa parecer mais humana. Novamente, não tenha medo de manter o tom amigável e pessoal. Equipes pequenas às vezes sentem que precisam soar grandes e ultra-profissionais o tempo todo. É quase como uma versão empresarial do Complexo de Napoleão. Não se preocupe em soar pequeno. Alegre-se no fato de que você pode falar com os clientes como um amigo.

Está Vivo!

Um blog de produto frequentemente atualizado é o melhor indicador de que um webapp está em desenvolvimento ativ

Mantenha os posts fluindo 351 words

Desculpas em Beta

Não use "beta" como desculpa

Nos dias de hoje, parece que tudo está em fase beta para sempre. Isso é uma saída fácil. Uma fase beta interminável diz aos clientes que você não está realmente comprometido em lançar um produto acabado. Isso diz, “Use isto, mas se não estiver perfeito, não é nossa culpa.”

Beta transfere a responsabilidade para seus clientes. Se você não tem confiança suficiente no seu lançamento, então como pode esperar que o público tenha? Betas privados são aceitáveis, betas públicos são bobagem. Se não é bom o suficiente para consumo público, não o entregue ao público para consumir.

Não espere que seu produto atinja a perfeição. Isso não vai acontecer. Assuma a responsabilidade pelo que está lançando. Coloque no mercado e chame de lançamento. Caso contrário, você está apenas dando desculpas.

Beta é Não Faz Sentido

Culpe o Google, etc, por causar problemas como este. Por agora, os usuários foram treinados pelo conjunto de desenvolvedores a pensar

Desculpas em Beta 207 words

Nem todos os bugs são criados iguais

Priorize seus bugs (e até ignore alguns deles)

Só porque você descobriu um bug no seu produto, não significa que é hora de entrar em pânico. Todo software tem bugs — é um fato da vida.

Você não precisa consertar todo e cada bug imediatamente. A maioria dos bugs são no máximo irritantes, não destrutivos. Irritações podem ser deixadas de lado por um tempo. Bugs que resultam em erros do tipo "isso não parece certo" ou outros pequenos deslizes podem ser tranquilamente adiados. Mas se um bug destruir seu banco de dados, obviamente você precisa consertá-lo imediatamente.

Priorize seus bugs. Quantas pessoas são afetadas? Quão grave é o problema? Esse bug merece atenção imediata ou pode esperar? O que você pode fazer agora que terá o maior impacto para o maior número de pessoas? Muitas vezes, adicionar uma nova feature pode ser até mais importante para seu aplicativo do que consertar um bug existente.

Além disso, não crie uma cultura de medo em torno dos bugs

Nem todos os bugs são criados iguais 271 words

Deixe a poeira baixar

Espere até que reações impulsivas às mudanças acalmem antes de tomar uma ação

Quando você balança o barco, haverá ondas. Após introduzir uma nova funcionalidade, mudar uma política ou remover algo, reações impulsivas, muitas vezes negativas, vão surgir.

Resista à vontade de entrar em pânico ou mudar as coisas rapidamente em resposta. As paixões se inflamam no começo. Mas se você aguentar este período inicial de 24-48 horas, as coisas geralmente se acalmam. A maioria das pessoas reage antes de realmente se aprofundar e usar o que você adicionou (ou se acostumar com o que você removeu). Então, recoste-se, absorva tudo e não faça uma jogada até que algum tempo tenha passado. Assim, você poderá oferecer uma resposta mais racional.

Além disso, lembre-se de que reações negativas são quase sempre mais altas e mais apaixonadas do que as positivas. De fato, você pode apenas ouvir vozes negativas mesmo quando a maioria da sua base está feliz com uma mudança. Certifique-se de não

Deixe a poeira baixar 176 words

Acompanhe a competição

Assine feeds de notícias sobre seus concorrentes

Assine feeds de notícias sobre o seu produto e seus concorrentes (é sempre sábio conhecer os caminhos do inimigo). Use serviços como PubSub, Technorati, Feedster e outros para se manter atualizado (para palavras-chave, use nomes de empresas e nomes de produtos). Com o RSS, essas informações constantemente atualizadas serão entregues diretamente a você, assim você estará sempre informado.

Acompanhe a competição 70 words

Cuidado com o monstro do inchaço

Mais maduro não precisa significar mais complicado

À medida que as coisas progridem, não tenha medo de resistir ao inchaço. A tentação será escalar. Mas não precisa ser assim. Só porque algo fica mais velho e mais maduro, não significa que precisa ficar mais complicado.

Você não precisa se tornar uma caneta espacial que escreve de cabeça para baixo. Às vezes está tudo bem em ser apenas um lápis. Você não precisa ser um canivete suíço. Você pode simplesmente ser uma chave de fenda. Você não precisa construir um relógio de mergulho seguro a 5.000 metros se seus clientes são amantes da terra que apenas querem saber que horas são.

Não infle apenas por inflar. É assim que os aplicativos ficam inchados.

Novo nem sempre significa melhorado. Às vezes, há um ponto em que você deve apenas deixar um produto ser.

Este é um dos principais benefícios de construir software baseado na web em vez de software tradicional para desktop. Fabricantes de software para deskto

Cuidado com o monstro do inchaço 246 words

Deixe rolar

Esteja aberto a novos caminhos e mudanças de direção

Parte da beleza de um aplicativo web é sua fluidez. Você não o embala em uma caixa, envia e depois espera anos pela próxima versão. Você pode ajustar e mudar conforme avança. Esteja aberto ao fato de que sua ideia original pode não ser a melhor.

Olhe para o Flickr. Ele começou como um jogo online multijogador chamado The Game Neverending. Seus criadores logo perceberam que o aspecto de compartilhamento de fotos do jogo era um produto mais plausível do que o próprio jogo (que acabou sendo arquivado). Esteja disposto a admitir erros e mudar de curso.

Seja um surfista. Observe o oceano. Descubra onde as grandes ondas estão quebrando e ajuste-se de acordo.

Deixe rolar 127 words

Conclusão

Ligue os motores

Concluído

Tudo certo, você chegou até aqui! Espero que esteja animado para começar a Cair na Real com seu aplicativo. Realmente nunca houve um momento melhor para fazer ótimos softwares com recursos mínimos. Com a ideia certa, paixão, tempo e habilidade, o céu é o limite.

Algumas considerações finais:

Execução

Todo mundo pode ler um livro. Todo mundo pode ter uma ideia. Todo mundo tem um primo que é designer web. Todo mundo pode escrever um blog. Todo mundo pode contratar alguém para juntar alguns códigos.

A diferença entre você e todos os outros será o quão bem você executa. O sucesso é tudo sobre ótima execução.

Para software, isso significa fazer muitas coisas corretamente. Você não pode apenas ter uma boa escrita, mas falhar em cumprir as promessas no seu texto. Design de interface limpo não adianta se seu código está cheio de gambiarras. Um ótimo aplicativo é inútil se uma promoção ruim significa que ninguém nunca sabe sobre ele. Para ter grande sucesso, v

Ligue os motores 660 words