[AI] [DesInterac] Re: Elementos da Experiência do Usuário e Desenvolvimento Ágil
Carlos Kramer
kramer.carlos em gmail.com
Domingo Outubro 2 22:15:17 EDT 2011
Bruno,
Concordo em parte. É claro que não imagino um especialista em gente que
saiba tudo de cabeça :) Isso seria impossível. Mas o próprio foco da
pesquisa muda quando você passa a encarar pessoas não apenas como usuários
ou clientes. Com boa parte das técnicas de pesquisa de design hoje, nós nos
tornamos capazes de entender a pessoa enquanto usuária de um produto, mas
acredito que seja necessário entender pessoas de maneira um pouco mais
abrangente.
Sobre todos serem designers em equipes multidisciplinares, concordo, isso de
fato acontece. Justamente por isso é que digo: a nossa formação precisa de
mais base em sociológica, psicológica, ciência cognitiva para que o designer
tenha de onde tirar insumo para indicar a pesquisa correta, ou seja, saiba o
que precisa "perguntar" com a pesquisa e tenha embasamento para extrair
dados dela. Quando falo em "formação", não me refiro exclusivamente à
formação acadêmica, mas aos nossos interesses de um modo geral.
Ou seja, precisamos nos beneficiar mais de conceitos e estudos de outras
áreas humanas e sociais, precisamos desse embasamento. Além do mais, fazer
pesquisa empírica específica para um projeto é importante, pode ser
importante, mas não resolve tudo, muitas vezes engana bastante, e não
substitui sozinha a atividade de conceber o produto. O Don Norman provoca
dizendo que fazer muita pesquisa inibe a criatividade. Mas acho que a gente
já foge muito do tópico com essa conversa :)
Grande abraço,
*Carlos Krämer*
+55 (21) 9803.2408
Site <http://carloskramer.com/> |
Linkedin<http://www.linkedin.com/in/carloskramer>|
Twitter <http://twitter.com/#%21/carloskramer>
Em 2 de outubro de 2011 22:19, Bruno Gabriel
<brunoradiotv em yahoo.com.br>escreveu:
> Carlos,
>
> Fiquei curioso e gostaria de debater esse comentário:
>
> *"Além disso, eu acredito que o designer tem que ser cada vez mais o
> especialista em "gente" dentro do processo. Não apenas o especialista em
> técnicas de pesquisa com usuário, mas o especialista que entende o
> comportamento humano em seus aspectos psicológicos e sociais, e pode agregar
> esse conhecimento ao projeto. Exemplo disso foi o processo de criação dos
> círculos do Google+ (dica do Fred, inclusive)."*
>
> Desculpe, mas acredito que esse profissional não existe. Ser um
> especialista em comportamento humano em seus aspectos priscológicos e
> sociais é algo um pouco utópico. Acredito que nas equipes multidisciplinares
> todos são designers, cada um com sua responsabilidade e opninando ativamente
> no desenvolvimento do projeto. Nesse contexto, a equipe, com consciência que
> o comportamento humano e os desejos do cliente é algo muito completo, apoia
> a aplicação de pesquisas em diversas etapas do projeto, fugindo assim de
> trabalhar baseados apenas em 'achismos' dos membros envolvidos.
>
> O que acha?
>
> Abraço!
>
>
>
> Atenciosamente,
> Bruno Gabriel
> brunoradiotv em yahoo.com.br
> *De:* Carlos Kramer <kramer.carlos em gmail.com>
> *Para:* Arquitetura da Informação (em Português) <
> aifia-pt em lists.ibiblio.org>; DesInterac <desinterac em googlegroups.com>
> *Enviadas:* Domingo, 2 de Outubro de 2011 1:27
> *Assunto:* Re: [AI] [DesInterac] Re: Elementos da Experiência do Usuário e
> Desenvolvimento Ágil
>
> Oi, Érico,
>
> A ideia dos círculos partiu de um entendimento sobre o comportamento social
> humano, de que ninguém interage socialmente da mesma forma em todos os seus
> "círculos sociais". Grosso modo, eu falo de um jeito com minha vó, de outro
> com meu orientador da faculdade, e de outro com a galera do futebol. Ou
> seja, os círculos do Google+ são uma transposição do convívio social humano
> para uma interface. Design para dar suporte à interação social. A meu ver,
> para chegar a isso, o designer precisa ser esse especialista em
> comportamento humano de que falei.
>
> O artigo que o Fred indicou naquela outra conversa que tivemos sobre a
> "batalha dos termos" foi esse aqui:
>
> http://www.businessinsider.com/heres-the-presentation-that-inspired-google-2011-7#-1
>
>
> Grande abraço!
>
> *Carlos Krämer*
>
> +55 (21) 9803.2408
> Site <http://carloskramer.com/> | Linkedin<http://www.linkedin.com/in/carloskramer>|
> Twitter <http://twitter.com/#%21/carloskramer>
>
>
>
>
> Em 2 de outubro de 2011 01:16, Érico Fileno <efileno em gmail.com> escreveu:
>
> Oi Carlos,
>
> Como foi o processo de criação dos círculos do Google+?
> Fiquei curioso...
> Abração
>
> Érico Fernandes Fileno, M.Sc.
> Interaction Designer
> (41) 9102 6776
> http://www.ericofileno.com.br
> @efileno <http://www.twitter.com/efileno>
>
>
>
>
> 2011/10/2 Carlos Kramer <kramer.carlos em gmail.com>
>
> Fred,
>
> Não acho que chegou a discordar de fato :)
>
> O que você fez foi aprofundar o conhecimento sobre as origens do agile,
> ainda que, no que diz respeito à industria de software, a filosofia ágil
> permanece sendo obra de desenvolvedores, não de designers. E mesmo fora da
> indústria de software, como no caso do just-in-time, o foco é estoque,
> produção e entrega, não projeto.
>
> No mais, acho que concordamos. Agile não entrega produtos necessariamente
> melhores. E a minha questão permanece: agile é bom para o Design? Do que
> vimos até agora, parece que não. Os relatos apontam sempre para adaptações
> que tentam "encaixar" o design no processo.
>
> Ma veja, isso não significa que eu esteja sugerindo o retorno de um modelo
> cascata (a cultura agile trouxe coisas positivas, em especial o incentivo a
> equipes multidisciplinares, e tirar o designer da casca e colocá-lo no
> ambiente de produção). Na verdade, não tenho uma alternativa em mente, tenho
> apenas uma inquietação. Um exemplo possível poderia ser (apenas sugestão
> para enriquecer a discussão) o "funil" do Bill Buxton. Para quem não
> conhece, está no slide 6 dessa apresentação:
> http://www.slideshare.net/bunky34/design-studios-idea-creation
>
> Há uma versão também no texto que enviei no meu primeiro comentário.
>
> Sobre o designer criar patterns, guidelines e "bootstraps" e depois focar
> no macro, é curioso que vejo dois movimentos hoje. Um que vai nessa direção,
> outro que vai da direção oposta, do progressive prototyping, no qual, de
> fato, o designer em algum momento se coloca como parte do time de
> desenvolvimento, pois vai do sketch direto para o código. Tem gente boa indo
> nessa segunda direção, como o Ryan Singer e o Todd Zaki Warfel.
>
> O design, enquanto atividade conceptiva, criadora, sempre foi e sempre será
> livre, justamente por ser uma atividade, não uma profissão ou papel. (Esse é
> mais um motivo para eu considerar uma bobagem, além de muito pouco
> produtiva, a regulamentação da profissão). Quanto menos "inocentes" as
> pessoas ficam em relação à concepção de produtos, mais descentralizada fica
> a atividade conceptiva do Design. Eu vivo isso: não tem nenhum "bobo"
> trabalhando comigo. Trabalho com desenvolvedores e engenheiros muito
> competentes e com muita visão de produto, por isso todos fazem parte da
> concepção macro dos produtos, e todos discutem as decisões micro sobre
> funcionalidades e comportamentos. Nesse contexto, o designer pode assumir a
> função de propiciador, de guia do processo de concepção, mas não de "dono".
>
> Além disso, eu acredito que o designer tem que ser cada vez mais o
> especialista em "gente" dentro do processo. Não apenas o especialista em
> técnicas de pesquisa com usuário, mas o especialista que entende o
> comportamento humano em seus aspectos psicológicos e sociais, e pode agregar
> esse conhecimento ao projeto. Exemplo disso foi o processo de criação dos
> círculos do Google+ (dica do Fred, inclusive).
>
> Abraços,
>
> *Carlos Krämer*
>
> +55 (21) 9803.2408
> Site <http://carloskramer.com/> | Linkedin<http://www.linkedin.com/in/carloskramer>|
> Twitter <http://twitter.com/#%21/carloskramer>
>
>
>
>
> Em 30 de setembro de 2011 09:35, Frederick van Amstel <
> usabilidoido em gmail.com> escreveu:
>
> Carlos, permita-me discordar.
>
> Os princípios básicos de agile development, SCRUM, XP, Kanban e outros não
> surgiram no desenvolvimento de software. São conceitos importados,
> principalmente, da indústria automotiva. Essas indústrias desenvolveram
> métodos ágeis para poder entregar o produto o mais rápido possível e
> diminuir o tamanho do estoque. Para quem gazeou as aulas de Geografia do
> Ensino Médio, o nome disso é just-in-time.
>
> O just-in-time se deve à aceleração do capitalismo. Quanto mais rápido
> viera o retorno, melhor. Por isso os produtos de hoje são feitos mais
> rápidos, vendem mais rápido e quebram mais rápido do que os antigos. É claro
> que o único que se beneficia desse ciclo é o próprio capital e não as
> pessoas.
>
> Agile development se deve à maturação das fábricas de software que, frente
> ao (óbvio) fracasso do taylorismo aplicado a software, tiveram que se
> adaptar. O resultado certamente não será software de melhor qualidade, e sim
> mais do mesmo. E isso não é visto como um problema, pois a demanda por
> aplicativos especializados baseados em padrões universais é gigantesca.
>
> Eu acredito que as fábricas de software não vão dar conta da demanda por
> agilidade, que vai crescer ainda mais. Acredito muito mais no
> desenvolvimento localizado baseado em plataformas customizáveis. Esse
> movimento a indústria automobilística já fez há algum tempo, usando a mesma
> base com diferentes carcaças, peças compartilhadas, acessórios.
>
> Uma das coisas que estou pensando em falar na palestra é sobre o papel do
> designer nesse contexto. Se ele tenta projetar todas as telas que saem da
> produção, ele vai estar sempre atrasado, empatando o trabalho de todo mundo.
> É preciso pensar a experiência do usuário num nível mais macro.
>
> Um papel possível para o designer é projetar essas plataformas
> customizáveis. Inicialmente dentro da empresa, como patterns, toolkits,
> guidelines e posteriormente fora da empresa, como produtos modulares, DIY
> kits, treinamentos. O designer delega o design e se responsabiliza pelo
> metadesign.
>
> Nessa perspectiva, o uso desses recursos por desenvolvedores sem formação
> em design pode ser considerado design também, mesmo que não haja uma
> metodologia. A metodologia é praticada por osmose pela interação com a
> plataforma.
>
> Já vi algumas pessoas apontando esse caminho, mas poucos mostraram como
> fazer isso na prática. Por isso decidi fazer um doutorado para pesquisar
> esse fenômeno, que estou chamando de Design Livre.
>
> Soa interessante?
>
>
> Em 29 de setembro de 2011 18:25, Carlos Kramer <kramer.carlos em gmail.com>escreveu:
>
> O assunto é realmente interessante.
>
>
> Duas impressões minhas:
>
> 1 - entre método ágil e o manifesto ágil há uma abismo. Conversei isso com
> alguns amigos desenvolvedores que advogavam o agil, mas se desencantaram com
> os desdobramentos, e eles concordaram com essa visão. O simples fato de ter
> virado um "método" já é a antítese do manifesto.
>
> 2 - o método ágil é obra de desenvolvedores, voltado para desenvolvedores.
> A aplicação dele ao processo de Design é uma espécie de "aberração" (palavra
> um pouco exagerada, eu sei), e vai especialmente na direção oposta do design
> centrado em pessoas.
>
> Se pudéssemos condensar ao máximo numa frase bem simples e curta o que é
> Design, eu talvez optasse pela frase "antever, pensar antes de fazer". Sem
> querer abusar da etimologia, "projetar" é exatamente isso, lançar-se para
> frente, projetar-se para frente, antever problemas e especificar soluções (e
> por especificar me refiro inclusive ao design de uma interface, por
> exemplo). O agile, por sua vez, se simplificado em bom português, é mais ou
> menos isso: "vai pensando e fazendo, no fim a gente vê no que deu".
>
> Ao aceitar a filosofia ágil (que é uma filosofia de desenvolvimento, não de
> design), a gente abre mão de boa parte das premissas do ato de projetar. É
> nesse ponto que ouvimos sempre o mesmo argumento: "software não é carro, não
> é navio, não é prédio, é mais fácil e barato de modificar, etc". Isso é
> verdade, mas acho que pouca gente se questiona se isso é bom. A pergunta
> mais importante nesse caso acho que é: o agile propicia produtos finais
> melhores? Melhores para quem? Se pensamos em softwares como produtos, não
> seria o caso de aprendermos um pouco com os processos de design de produtos,
> e com todo o resto do conhecimento humano sobre "projetar".
>
> Não sei se já conhecem, mas sugiro um texto do Bill Buxton sobre o assunto:
> *Performance by Design: The Role of Design in Software Product Development
> *
> http://www.billbuxton.com/SoftwareDesign.pdf
>
> A crise de identidade do Design atrapalha bastante nisso. O meu mantra
> pessoal é "Design é muito mais do que UX". Mas esse é outro assunto. :)
>
> Abraços,
>
> *Carlos Krämer*
>
> +55 (21) 9803.2408
> Site <http://carloskramer.com/> | Linkedin<http://www.linkedin.com/in/carloskramer>|
> Twitter <http://twitter.com/#%21/carloskramer>
>
>
>
>
> Em 28 de setembro de 2011 18:40, Frederick van Amstel <
> usabilidoido em gmail.com> escreveu:
>
> Caros,
>
> Estou preparando uma palestra para o Intercon sobre desenvolvimento ágil e
> procuro relatos de equipes e profissionais da Experiência do Usuário que
> estejam trabalhando em ambientes de Desenvolvimento Ágil.
>
> Até o presente momento, as equipes com que já tive contato me relataram que
> o modelo do Garrett (Estratégia > Escopo > Estrutura > Esqueleto >
> Superfície) não funciona para esse tipo de ambiente. É preciso fazer
> adaptações nas metodologias tradicionais de UX para encaixar com o
> desenvolvimento ágil.
>
> Alguém gostaria de compartilhar um relato na lista ou em PVT sobre esse
> assunto?
>
> Agradeço de ante-mão.
>
> --
> .
> .{ Frederick van Amstel }.
> http://fredvanamstel.com
>
> Faber-Ludens Interaction Design Institute
> http://www.faberludens.com
>
>
> . . . . . . . . . . . . . . . . . . . . . .
> Ao responder, elimine o texto não essencial
> de mensagens anteriores e evite formatação.
>
> Lista de discussão AIfIA-pt
> AIfIA-pt em lists.ibiblio.org
> Arquitetura de Informação em Português
> http://lists.ibiblio.org/mailman/listinfo/aifia-pt
>
>
> --
> ::: Ao responder, elimine o texto não essencial de mensagens anteriores :::
>
> ***************************************************************************************
> DesInterac - comunidade mantida pelo Instituto Faber-Ludens, uma entidade
> sem fins lucrativos que promove a integração do Design e da Tecnologia no
> Brasil.
>
> Novidades em http://www.faberludens.com.br
> Cursos em http://cursos.faberludens.com.br
> Projetos abertos em http://www.corais.org
> --
> Você recebeu esta mensagem porque se cadastrou no Grupo "DesInterac" do
> Google Groups.
> * novos tópicos pelo email desinterac em googlegroups.com
> * cancelar a inscrição http://bit.ly/a2Tfoo
> * outras opções em http://groups.google.com/group/desinterac
>
>
>
>
> --
> .
> .{ Frederick van Amstel }.
> http://fredvanamstel.com
>
> Faber-Ludens Interaction Design Institute
> http://www.faberludens.com
>
>
> . . . . . . . . . . . . . . . . . . . . . .
> Ao responder, elimine o texto não essencial
> de mensagens anteriores e evite formatação.
>
> Lista de discussão AIfIA-pt
> AIfIA-pt em lists.ibiblio.org
> Arquitetura de Informação em Português
> http://lists.ibiblio.org/mailman/listinfo/aifia-pt
>
>
>
> . . . . . . . . . . . . . . . . . . . . . .
> Ao responder, elimine o texto não essencial
> de mensagens anteriores e evite formatação.
>
> Lista de discussão AIfIA-pt
> AIfIA-pt em lists.ibiblio.org
> Arquitetura de Informação em Português
> http://lists.ibiblio.org/mailman/listinfo/aifia-pt
>
>
>
> . . . . . . . . . . . . . . . . . . . . . .
> Ao responder, elimine o texto não essencial
> de mensagens anteriores e evite formatação.
>
> Lista de discussão AIfIA-pt
> AIfIA-pt em lists.ibiblio.org
> Arquitetura de Informação em Português
> http://lists.ibiblio.org/mailman/listinfo/aifia-pt
>
>
>
> . . . . . . . . . . . . . . . . . . . . . .
> Ao responder, elimine o texto não essencial
> de mensagens anteriores e evite formatação.
>
> Lista de discussão AIfIA-pt
> AIfIA-pt em lists.ibiblio.org
> Arquitetura de Informação em Português
> http://lists.ibiblio.org/mailman/listinfo/aifia-pt
>
>
> . . . . . . . . . . . . . . . . . . . . . .
> Ao responder, elimine o texto não essencial
> de mensagens anteriores e evite formatação.
>
> Lista de discussão AIfIA-pt
> AIfIA-pt em lists.ibiblio.org
> Arquitetura de Informação em Português
> http://lists.ibiblio.org/mailman/listinfo/aifia-pt
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://lists.ibiblio.org/pipermail/aifia-pt/attachments/20111002/ca469b39/attachment-0001.html
Mais detalhes sobre a lista de discussão AIfIA-pt