Baixar para ler offline
Carregado porNatalia Arsand
Resolvendo Problemas através do Design
O documento resume vários eventos históricos entre 1959 e 1977, incluindo a revolução cubana liderada por Fidel Castro em 1959 e o voo sem motor de Paul MacCready em 1977. O documento também discute a importância de entender o problema, fazer perguntas e encontrar respostas por meio de conversas e discussões.
Resolvendo Problemas através do Design
- 1.
- 2. 1959 HENRY KREMER “ criar um avião que usasse so- mente a energia do piloto para voar um oito em torno de dois marcadores posicionados a ~1.5km um do outro.
- 3. 1977 PAUL MACCREADY “ o problema é que a gente não entende o problema.
- 4.
- 5. USABILIDADE EXPERIÊNCIA DO USUÁRIO HTML ARQUITETURA DA INFO CSS INTERFACE GRÁFICA MODELOS DE NEGÓCIO six years of experience ESTRATÉGIA DE PRODUTO ...
- 6. a arte dePROBLEMAS RESOLVER
- 7. RESOLVER PROBLEMA fazer perguntas encontrar respostas criar significado
- 8. RESOLVER É NATURAL É VARIÁVEL PROBLEMA É HUMANO
- 9. É NATURAL DESIGN É VARIÁVEL É HUMANO
- 10. DESIGN equals to RESOLVER PROBLEMAS
- 11. PAPEL DO DESIGNER mercado concorrentes cultura NEGÓCIO recursos restrições PRODUTO USUÁRIO valor tipos diferencial ambiente sustentabilidade contexto
- 12. SEM O DESIGNER NEGÓCIO PRODUTO USUÁRIO
- 13. O QUE TE SUSTENTA? NEGÓCIO NEGÓCIO PRODUTO PRODUTO USUÁRIO USUÁRIO
- 14. PROBLEM SOLVING IDENTIFICAÇÃO DE PROBLEMA DEFINIÇÃO DE PROBLEMA ORGANIZAÇÃO DA INFO
- 15. IDENTIFICAÇÃO DO PROBLEMA • Entender as origens do problema. • Externalizar as ideias. • Entender as necessidades da pirâmide. BRAINSTORM PESQUISA
- 16. BRAINSTORM Pode ser feito no início de um projeto para con- hecê-lo melhor, ou quando se tem dúvidas em relação a funcionalidades, novas soluções para um mesmo problema, e entender melhor qualquer Atividade em grupo para externalizar e esclarecer tipo de ideia. ideias sobre determinado problema. Peça para as pessoas expressarem todas as suas ideias que lhe vierem à cabeça em relação ao prob- lema. Nenhuma ideia deve ser criticada ou invalidada. Evite o julgamento e a auto-crítica, deixe que as ideias bobas apareçam e as exponha. Todas as ideias faladas devem ser escritas, ou numa folha grande, ou no quadro branco, ou em post-its, e devem ficar expostas para todos. Não existe certo e errado, o obje- tivo principal é que o grupo consiga ex- por suas percepções, ideias, conhecimento
- 17. PESQUISA Monte um questionáriocom base nas informações existentes sobre um determinado problema e saia É HORA DE IR PRA RUA! para validá-las com usuários reais, pessoas que já atuam no mercado, amigos com algum conhecimento no assunto, e qualquer pessoa que possa trazer al- guma informação valiosa para o entendimento do problema. Você precisa implementar uma nova funcionalidade em um software juntamente com o seu time de de- senvolvimento. Essa funcionalidade é crítica e compl- exa, e será mantida por outros desenvolvedores após a entrega. Monte um quesitonário com poucas perguntas para os desenvolvedores (colegas de projeto mesmo) que responda o que esperar dessa funcionalidade. No final você vai ter diferentes opiniões sobre o mesmo problema, conseguirá identificar os padrões de pen- samento e definir melhor a funcionalidade antes de desenvolvê-la.
- 18. DEFINIÇÃO DE PROBLEMA • Entender o que faz parte do problema • Entender o que não faz parte do problema PROJECT STATEMENT ESCOPO
- 19. PROJECT STATEMENT DEFINIR OQUE SE ENTENDE DO O Viajante é um organizador de viagens para pessoas que gostam de viajar por PROBLEMA EM POUCAS LINHAS. conta própria. Diferente do Gogobot, O Viajante permite que usuários contem Template suas viagens em forma de histórias. O produto X faz Y para o público Z. Diferente de seu concorrente M, o produto X faz N.
- 20. ESCOPO Minha equipe precisa desenvolver um botão que vá para a página de produ- tos em promoção. Toda a parte de produtos da empresa é gerenciada por uma outra equipe. DEFINIR O QUE FAZ E O QUE NÃO FAZ PARTE DO PROBLEMA. Faz parte do escopo adicionar o botão, os estilos, adicionar o link específico, criar a ação do clique. O que acontece depois não é parte do nosso problema.
- 21. ORGANIZAÇÃO DA INFORMAÇÃO • Organizar para projetar. SITEMAP PERSONAS FLUXOGRAMA homepage navegue nas inicie uma saiba mais ideias ideia categoria sobre os sobre o regulamento FAQ temas festival
- 22. SITEMAP NÃO É A LISTA DE PÁGINAS DE UM SITE. Relação e hierarquia de conteúdo. CONTEÚDO, não páginas. homepage Agrupamento de conteúdos relaciona- dos. navegue nas inicie uma saiba mais ideias ideia categoria sobre os sobre o regulamento FAQ temas festival ideia contato
- 23. PERSONAS AS PROPRIEDADES DAS PERSONAS DEPENDEM MUITO DO PRODUTO, ELAS DEVEM FAZER SENTIDO PARA O CONTEXTO. Representações dos usuários de um produto. Servem para nos lembrar quem são os usuários e validar as funcionalidades e fluxos que criamos. Um sistema que permite os usuários acessarem um log de modificações de conteúdo em uma determinada página. João é gestor de conteúdo, ele busca os logs no mínimo 4 vezes por dia para saber o que foi modi- ficado, quem modificou, etc. Mariana é do marketing, ela precisa de uma visu- alização geral do que mudou na página nos últi- mos meses para falar aos investidores o que tem acontecido. Necessidades diferentes do mesmo sistema.
- 24. FLUXOGRAMA Fluxo de navegação,ações e interações. Cenários de cada tipo de usuário (admin- istrador, logado, deslogado) Passo a passo do usuário. EU ADORO FLUXOGRAMAS! - Validar o processo com o cliente - Validar o fluxo de nossas personas - Definir melhor as estórias de usuário - Testar a usabilidade
- 25. “CRIAR UM AVIÃOQUE SEJA RÁPIDO E FÁCIL DE SE RECONSTRUIR”. o problema estava no processo .
- 26. O processo importatanto quanto o resultado EXTERNALIZAR É MAIS EFICIENTE DO QUE SOMENTE PENSAR. PERGUNTE, CONVERSE, DISCUTA, PERGUNTE DE NOVO.
- 27.