Ontem revi este vídeo do Ryan Singer na FOWA 2010, onde ele explica como é o processo de design dos produtos da 37Signals, desde uma ideia inicial de produto/funcionalidade até o deploy do software em produção.
A palestra tem uma caráter bastante prático, então não valeria a pena eu tentar fazer um resumo dos conceitos aqui. Mesmo para quem não é designer ou desenvolvedor, sem dúvida vale o investimento de meia hora assistindo o vídeo.
Logo na sequência faço alguns comentários sobre os pontos que eu mais gostei do processo e que certamente servirão de input para melhorarmos a maneira como nós desenvolvemos nossos produtos. O interessante é que grande parte das práticas remetem a conselhos que eles já deram há muito tempo no Getting Real. Nos comentários também vou apontar para os links para seções específicas do livro.
Ryan Singer at Future of Web Apps, London 2010 from Ryan Singer on Vimeo.
Minhas observações:
- Tudo começa com o problema, ou como o Ryan colocou, com a definição do “modelo”: parece óbvio, mas muita gente esquece de focar no problema de negócio que o software pretende resolver na hora de projetar uma interface. (referência no Getting Real: “What’s the big idea?”)
- Simplicidade é chave: uma série de decisões e detalhes sempre poderão ser melhor definidos e aprimorados à frente. Deve-se pensar sempre qual é a coisa mínima que resolve de forma elegante o problema explicitado. (ref. “Ignore details early on”)
- Elimine as abstrações: quanto mais próxima a aplicação estiver do seu ambiente final (rodando em produção), melhor. Não gaste um tempo excessivo em especificações, rascunhos, wireframes, arte, mockups, etc. (ref. “Race to running software”)
- Faça o designer e o programador trabalhar simultaneamente: isso também tem a ver com o ponto acima e ficou bastante evidente no processo quando ele sugeriu que o próximo passo depois dos rascunhos seria já fazer código HTML, assim o programador não fica esperando todo o design ficar pronto para começar a codificar o software. Claro que, para isso funcionar bem, um dos pré-requisitos é que se tenha iterações curtas. (ref. “Rinse and repeat”)
- Cresça a aplicação de dentro para fora: A parte mais importante de uma página sempre é a funcionalidade em si, e não os cabeçalhos, barra de navegação, etc. No processo de design de um site, o projeto do núcleo deve vir antes do template, e não o contrário. (ref. “Epicenter Design”)
- Nem todas as informações na página têm a mesma importância: Dê destaque (em tamanho, contraste, etc.) as partes mais importantes da página – o que Ryan chamou de “Halo of attention” – mesmo que isso venha ao custo de uma inconsistência com outras páginas. (ref. “Context over Consistency”)
- A aplicações está sempre viva: mesmo as premissas mais básicas do modelo podem mudar ao longo do tempo. Mantenha o caráter iterativo e a abertura à feedback. (ref. “Go with the flow”)
Via RSS de Manual da Startup
Comente este artigo