Faz já mais de quatro anos desde que me envolvi com grupos de desenvolvedores de softwares em Moçambique. Durante esse período aprendi a programar. Comecei com o básico, HTML, linguagem usada para estruturar websites, depois aprendi a “embelezar” as páginas com CSS, linguagem usada para estilizar websites, e de seguida diverti-me a valer com JavaScript, uma linguagem responsável por tornar os websites interativos. Não demorou muito e quiz aprofundar os meus conhecimentos sobre programação.
Por recomendação de um amigo, aprendi como se trabalhava em C, uma linguagem de programação que se usava maioritariamente para fazer softwares para computadores, como o Photoshop.Para mim, aprender C haveria de ajudar a perceber melhor a lógica de programação.
Comecei a fazer as aulas do CC50 – Ciências da Computação 50 da universidade de Harvard online. Consegui perceber a lógica, mas não passei daí. Programação não funcionou para mim, por isso passei a ser activista, ou melhor, evangelista de tecnologias.
Passei a dedicar parte do meu tempo a incentivar as pessoas a abraçarem a área das tecnologias e do desenvolvimento de software, porque já sabia como funcionava.Com um grupo de amigos, em 2013, criamos a MozDevz – Comunidade Moçambicana de Desenvolvedores de Softwares. Um ano depois passei a ser o presidente da mesma. Organizamos muitas maratonas de programação, encontros para troca de conhecimentos e partilha de ideias.
Ajudamos jovens a aprender sobre programação nas suas mais diversas variáveis. Depois de 3 anos, criamos uma comunidade forte. Agora, Moçambique já tem programadores. Já podemos criar aplicativos, muitos aplicativos.
Mas “muitos” não basta, agora queremos bons aplicativos. Por isso, em Dezembro de 2016, saí da MozDevz, e com ajuda de alguns amigos trouxemos a IxDA – Interaction Design Association, para Maputo.A missão é mesma, desenvolver o ecossistema de tecnologias digitais local.Agora só mudamos o foco. Mais do que Design, mais do que programação, focamo-nos no utilizador, na interação homem-máquina.
Queremos promover o espírito de partilha e troca de conhecimentos entre profissionais que trabalham com Design de Interação nos seus mais variados níveis de experiência. Mas, acima disso, queremos inspirar mais jovens e profissionais a singrar para esta área.
O nosso objetivo é melhorar a condição humana, cada vez mais desafiada por experiências pobres, por meio do avanço do Design de Interação.IxDA – Interaction Design Association, foi fundada em 2003 e incorporada como uma instituição sem fins lucrativos no final de 2005. IxDA, é um novo tipo de “anti-organização” em que não há custos para a adesão. Contamos com seus membros voluntários engajados a ajudar a servir as necessidades da comunidade internacional de Design de Interação.
Com mais de 80.000 membros e mais de 176 grupos locais em vários países, a rede IxDA atualmente se concentram em resolver questões de Design de Interação, num formato muito inclusivo – não importa o nível de experiência do membro, todos podem participar.
O Capítulo da IxDA em Maputo foi criado em Maio de 2017, mantendo os mesmos ideias da IxDA Global – melhorar a condição humana, cada vez mais desafiada por experiências pobres, por meio do avanço do Design de Interação. As principais metas do capítulo são promover eventos que estimulem a produção de conhecimento e a divulgação dos benefícios de pertencer à IxDA e dos seus processos de trabalho, além da inserção do Design de Interação no mercado regional.Esperamos fazer magia nos próximos meses. Junta-te a nós.
Hoje vim falar de dois tópicos curiosos, o Progressive Enhancement e Graceful Degradation. Minha abordagem será curta desta vez. Este artigo é inspirado no curso de Dynamic User Experience: Ajax Design and Usability que estou a fazer na Interaction Design Foundation.
Os tópicos abordados chamaram a minha atenção porque aconteciam em muitos websites e serviços que uso no meu dia-adia na internet mas não sabia como chama-los.
O Progressive Enhacement (Melhoria Progressiva) acontece quando desenvolvemos uma página ou serviço garantimos que a mesma tem os seus requisito básicos em pleno funcionamento com mínimo de recursos disponíveis (velocidade de conexão)e para a as versões mais antigas dos navegadores. Isto para garantir que o uma experiência minimamente consistente para todos os utilizadores do serviço.
O Progressive Enhancement tem a sua base o critério fail-safe. Este que em termos simples diz que se um recurso ou função usada num determinado serviço não é suportado por um navegador o sistema não pode responder como um erro. Os desenvolvedores e designers do sistema tem de estar preparados e responder seguindo o contexto de uso.
De certa forma Graceful Degradation (Degradação Harmoniosa em tradução livre) é a outra face da moeda do Progressive Enhancement, isto é, com o Graceful Degradation começamos do topo onde projectamos a melhor experiência que a tecnologia pode oferecer em um serviço e garantimos que a mesma tem um padrão de funcionamento consistente a medida que o serviço passa a ser usado por utilizadores com ou em condições menos favoráveis.Resumindo e concluindo, Progressive Enhancement começa na base das necessidades do serviço.
Melhora a experiência na medida que melhoram os recursos. Enquanto que Graceful Degradation começa dos requisitos mais complexos que requerem tecnologias mais avançadas e garante que a experiência ainda é fluindo mesmo para os dispositivos de baixo desempenho.Bem, por hoje é tudo, até o próximo artigo.
Referência
Dynamic User Experience: Ajax Design and Usability, Interaction Design Foundation
Para fechar o ciclo de artigos sobre Avaliação Heurística vamos hoje falar de um tópico mais prático. Como sugere o tema, vamos falar sobre quando é que usamos este procedimento. Vamos a prática!A avaliação Heurística na maioria dos casos feita com um conjunto de 3 a 5 pessoas desde expert em Design até membros da equipe que não tem muito haver com área.
A esta equipe, é fornecida um conjunto de ferramentas que é amplamente usado no processo. São dadas ferramentas diferentes quando se tenciona alcançar resultados diferentes. Os membros da equipe, durante os testes não se comunicam, sendo que os resultados são usados de forma agregada no final do processo.
A Avaliação Heurística pode ser usada tanto na fase de interfaces do utilizador avançada como na fase de prototipagem de baixa fidelidade (sketches).
Este método pode ser usado em múltiplas fases do projecto. Neste artigo vamos citar apenas 4:
Em todas as avaliações, para sejam bem sucedidas é importante que iniciem com um objectivo claramente definido. Estes podem ser:
A avaliação Heurística é na maioria das vezes mais rápida de se realizar do que os testes com utilizadores, estes levam em média 1 a 2 horas por avaliação. Os Resultados da AH vem já pré-interpretados, poupando trabalho de ter de traduzir a linguagem usada pelo utilizador.
Os testes com utilizadores são mais precisos por definição eles levam em consideração o utilizador e a tarefa a ser executada. Em alguns casos a AH, deixa alguns problemas escaparem de forma despercebida e contra “falsos pontos positivos”É compensador usar diferentes abordagens, desta forma encontramos diferentes problemas e poupamos utilizadores em testes desnecessários.
1. Treinamento de Pré-avaliação – nesta fase é dada/ensinado aos utilizadores os avaliadores necessários e mostrada as informações do cenário a avaliar.
2. Avaliação – nesta fase é feita a avaliação individual com cada um dos utilizadores.
3. Classificação de Prioridade – depois de agregados os feedbacks dos utilizadores, é feita a escolha do problema se deve dar prioridade no momento, baseado no custo-benefício.
4. Debrienfing – Nesta fase feita a avaliação dos resultados da pesquisa com a equipe de design.
5. Usar pelo menos 2 passos para cada fase de avaliação:
i) Ambientar-se com o escopo e com o fluxo do sistema;
ii) Focar-se em elementos específicos.6. Liste os problemas de forma separada, este faz com que sejam evitadas listagens repetidas.
Se o sistema for fácil de usar ou caso os avaliadores tenham domínio das técnicas de avaliação não haverá necessidade de assistência, caso contrario, terão de ser adicionadas avaliadores com cenários pré-elaborados. Cada avaliador produz uma lista específica de problemas.
Explique o porque de cada situação fazendo referência ao ponto de Avaliação Heurística (informação)
7. Classificação de Prioridade é estimada de forma independente depois de cada revisão
Alocação de recursos para a resolução dos problemas identificados. Estimar necessidades de aplicação de melhorias da usabilidade.
Identificação de prioridades combinadas (Frequência, impacto e persistência).
Valores de Classificação
0 – Não problemas na usabilidade
1 – Problema de estético
2 – Problema de usabilidade de menor escala
3 – Problema médio de usabilidade, é importante resolver
4 – Catástrofe na usabilidade, é imperativo resolver9. Debriefing
Termina aqui o guia completo sobre como usar Avaliação Heurística nos nossos projectos. Caso apliques alguns dos procedimentos indicados no artigo, não hesite em entrar em contacto para partilhar a tua experiência.No proximo artigo vamos mudar a temática, vamos falar de Gestalt. Contamos contigo. Até já!
Referências
Heuristic Evaluation: How to Conduct a Heuristic Evaluation, The Interaction Design Foundation
Princípios de Usabilidade para Avaliação de Interfaces.
Na publicação passada prometi que falaria da avaliação heurística e dos princípios de usabilidade com mais profundidade. Vou hoje cumprir minha promessa. Tentei neste artigo ser o mais claro e directo possível. Os princípios da avaliação heurística postulados por Jakob Nielsen, segundo o professor Scott Klemmer estão divididos em três grupos: Compreensão, Acção e Feedback.
Esta categorização nos ajuda a compreender de forma mais natural a origem dos princípios de Nielsen. Indo directo ao assunto, segue abaixo a descrição de cada grupo e seus respectivos princípios.
Este grupo destaca a importância da interpretação do sistema pelo utilizador. Este é o primeiro grupo da avaliação heurística. Neste grupo encontramos os princípios de Consistência, Utilização de Metáforas e Claridade no Design.
Consistência – segundo este princípio, os utilizadores criam mapas mentais baseados em expectativas e na experiência de utilização de softwares anteriores. Por isso, é importante ter em consideração o histórico do utilizador e suas respectivas expectativas concernentes a utilização de um sistema.Utilização de Metáforas – o segundo princípio importante é a utilização de metáforas familiares para os utilizadores.
As interfaces na sua maioria tem as suas características dominantes baseadas em objectos e ambiente do mundo físico. Estas quando interpretadas no mundo digital tem de informar da mesma forma que o fazem no contexto físico. Quando se projecta para um grupo alvo específico é importante falar a linguagem comum para o público alvo.
Claridade no Design – “A forma segue a função”, segundo o princípio da claridade no design o layout deve dizer/fazer o que as pessoas gostariam que ele fizesse. A interface tem de ser clara para que o utilizador saiba exactamente o que deve fazer para alcançar determinados objectivos.
Esta secção está mais focada nas acções dos utilizadores (o que os utilizadores, podem ou devem fazer), estas estão divididas em três princípios: Liberdade, Flexibilidade e Reconhecimento Baseado em Lembranças/Memórias.Liberdade – toca-se no princípio tangente a liberdade de utilização de um site ou software a possibilidade de adicionar o remover itens, desfazer ou retificar processos em casos de erros, possibilidade e apreciar/explorar sem se comprometer com dados de login (sites de compras).
Flexibilidade – bons softwares oferecem a possibilidade de flexibilidade aos utilizadores mais experientes. Um exemplo claro são os shortcuts para para tarefas rotineiras em softwares. Um outro exemplo de flexibilidade é mostrar categorias pré-definidas, isto é, os utilizadores podem num site pesquisar por o que quiserem mais como pré-definidas estão as categorias mais populares.
Reconhecimento Baseado em Lembranças/Memórias – este princípio mostra-nos como não podemos usar elementos que não comuniquem de forma eficiente com o utilizador. Casos em que os utilizadores tem de fazer um esforço para saber o que significa uma cor especifica o ou qual acção remete um determinado botão. Uma das formas de ajudar com reconhecimento é ter bons previews e thumbnails.
Quando usamos uma interface como sabemos o resultado de uma determinada acção? através do feedback/reposta que o sistema fornece. No mundo físico o feedback aparece naturalmente, mas no mundo da computação estas respostas são programadas. Em muitos casos é difícil se não formos atentos fornecer os feedbacks, mas existem várias estratégias que podem ajudar a facilitar o processo: Demonstração do estado, Prevenção de Erros, Suporte na Descoberta de Erros e Ajuda.
Demonstração do Estado do Sistema – quando parte da interação acontece instantaneamente, o feedback basicamente convite em mostrar o novo estado do sistema, mostrando a página que em que carregou. Sobre quanto feedback será necessário, vai muito com o tempo de resposta. Quando o processo leva mais de um segundo, é importante sempre, termos um indicador que mostra o nível de processamento da página. Assim sabemos que há processos a correr no sistema e que o computador não “congelou”. Se o processo levar mais tempo, é importante que tenhamos um indicador de progresso mais específico, este que deve mostrar o tempo restante de carregamento.
Prevenção de Erros – um bom feedback ajuda também a prevenir erros, por exemplo no caso de estamos a salvar um documento com o nome que já existe no banco de dados, o sistema pode enviar um alerta a notificar o facto. Mas mais do que notificar o sistema pode também prover alternativas.Suporte na Descoberta de Erros – uma boa interface pode eliminar até 90% ou mais dos erros que os utilizadores venham a ter na utilização de um sistema. Mas infelizmente é impossível alinhar 90% dos erros que o sistema pode ter. Quando os erros acontecem é importante ajudar o utilizador a manter o mesmo claro, para que seja possível ajudar o utilizador a mover-se partir do ponto em específico.
Ajuda – é certo olharmos para a componente ajuda como um problema de um utilizador e não uma componente do sistema. Um dos métodos mais comuns de oferecer ajuda é mostrar exemplos de situações específicas para que os utilizadores possam identificar os seus problemas. Ainda no processo de ajuda, temos sempre de ver como colocamos a informação. No caso em que mostramos textos longos aos utilizadores pouco ajudamos. A técnica eficaz é sumariarmos partes dos componentes e mostrarmos textos mais curtos e deixarmos como opção de leitura a versão completa do texto.
Resumindo os 10 princípios da Avaliação Heurística são:
A matéria do artigo de hoje foi mas extensa do que os outros, mas tinha de ser. Assim, aprendemos de uma única vez os princípios que guiam uma uma boa interface gráfica. No próximo artigo, irei explicar como implementar a avaliação heurística em um projecto. Por hoje tudo.Até já!Referências
A importância dos testes de softwares.
Todo bom software antes de passar para a fase de lançamento oficial, passa por uma fase de testes. Estes podem ser de vários tipos, neste artigo o maior enfoque estará virado para os testes baseados na critica – Avaliação Heurística. Na maioria dos casos, realizam-se testes para assegurar que todos os requisitos necessários para o pleno funcionamento de um software encontram-se em condições adequadas para que o utilizador final possa desfrutar dos serviços proporcionados pelo mesmo sem complicações.
Fora a Avaliação Heurística, existem outras formas de fazer testes em softwares. Estes podem ser por via de testes empíricos, testes formais ou testes automatizados.Testes Empíricos – estes são feitos com utilizadores reais, que testam o software e dão feedbacks baseados nas suas experiências e observações. Os testes empíricos são na base na tentativa e do erro, cada utilizador compreende o software a sua maneira.
Testes Formais – neste tipo de testes, são construídos modelos e fórmulas para calcular/medir a reposta ou comportamento do utilizador. Dependendo do ambiente em que este é colocado.Testes Automatizados – no modelo de testes automatizados, são construídos ou utilizados outros softwares para testes dos softwares em desenvolvimento. Este modelo é facilmente aplicado em projectos de pequena envergadura e de difícil implantação para projectos de grande envergadura.
Nos testes acima citados, só em 2 ( testes empíricos e formais) é que precisamos de utilizadores reais. Embora o processo de implementação seja diferente. Enquanto que no teste empírico o processo é mais livre e a mais recolha de dados qualitativos nos testes formais acontece o inverso. O ambiente é mais controlado e respostas estão sempre dentro de um parâmetro.
O testes automatizados por sua vez, vem de certa forma complementar a componente humana, dando mais respostas quantitativas, trazendo sempre, respostas relacionadas a performance a outras componentes técnicas do software.
Ainda no mesmo espectro de testes, encontramos outro tipo de testes que de certa forma é apoiado pelos utilizadores, mas mais especializados, são estes chamados testes baseados na crítica ou avaliação heurística, como o título do artigo sugere. Os testes baseados na crítica são normalmente feitos por experts na área. Nestes, pode-se ter/conseguir feedbacks de alto valor. Avaliação Heurística é um método de teste/avaliação de interfaces de softwares baseado em princípios de usabilidade.
Os princípios são chamados de heurísticas pois são desenvolvidos a partir de uma série de experiências prévias, sintetizando pontos recorrentes. Este termo foi cunhado inicialmente por Jakob Nielsen e Rolf Molich em 1990. Por ser o elo entre o homem e o computador, as interfaces dos softwares, pautadas nas heurísticas, é necessário considerar os elementos relacionados à sua adequada estruturação: Arquitetura da Informação, Arquitetura de Design, Navegabilidade, Conteúdo e Interatividade, que relacionados entre si, definem a usabilidade de um de uma interface.
No processo de avaliação a interface é submetida para diferentes avaliadores. Estes darão seu parecer baseando-se em 10 princípios, as chamadas heurísticas (este tópico será tema principal do próximo artigo). Umas das maiores vantagens do feedbacks baseado na crítica é proporcionar a possibilidade deste ser feito em qualquer fase do projecto, sendo que poupa os utilizadores, para testes de outra natureza em fases mais avançadas, onde o feedback baseado no uso do software dentro de um contexto é indispensável.Na avaliação heurística é importante dar destaque ao perfil do avaliador, o expert.
Para que o teste tenha efectivo valor este tem de ser um profissional com experiência. Se este for da área de Engenharia de Software ou Design será melhor. Mas com mais enfoque em análise de interfaces interactivas em aspectos concernentes a usabilidade.
Como já havia prometido acima, no próximo artigo irei abordar a avaliação heurísticas e os princípios de usabilidade com mais profundidade. Bem, por hoje é tudo.
Até a próxima!
Referências
Para além de observar as pessoas de forma participativa como expliquei no artigo anterior, podemos também conseguir feedback valiosodos utilizadores entrevistado-os, isto é, perguntando directamente sobre as suas experiências. Entrevista é a técnica de coleta de dados na qual as perguntas são formuladas e respondidas oralmente.
Trata-se, portanto, de uma conversação metódica, que proporciona ao entrevistador as informações solicitadas. Como técnica de pesquisa, a entrevista é utilizada para obter informações sobre o que as pessoas sabem, crêem, esperam, sentem, desejam, pretendem fazer, fazem ou fizeram e também sobre o que motiva ou motivou tudo o que acabamos de mencionamos.
Neste processo, o passo mais importante é decidir quem serão as pessoas entrevistadas. É importante que as pessoas entrevistadas representem o público alvo do produto que vamos desenvolver. Para encontrar estas pessoas ideais, o método mais comum é definir personas, ou seja, descrever, detalhadamente e com antecedência, o nosso utilizador ideal.
A persona é baseada em dados reais sobre comportamentos e características demográficas dos utilizadores, assim como na definição das suas histórias pessoais, motivações, objetivos, desafios e preocupações. Os entrevistados podem ser utilizadores de sistemas parecidos com o que estamos a desenvolver mas também podem ser não-utilizadores. Desde que eles se encaixem no perfil do utilizador ideal, será suficiente. Depois de defini-los, vamos à busca.
O que é uma boa pergunta numa entrevista?
Uma boa pergunta não é aquela que nos dará necessariamente uma resposta concreta, mas sim aquela que levará o entrevistado a contar-nos uma história a partir da qual perceberemos com mais clareza quais são as suas motivações, aspirações, pressupostos, etc. Como já havíamos dito na semana passada, as pessoas não são muito boas em saber o que querem, logo, perguntando-lhes directamente, poderemos obter respostas ideiais na teoria mas que não expressam os seus reais desejos. Por exemplo, se perguntarmos a alguém: “A atualização diária em softwares é importante pra si?” a maioria dos utilizadores diria “Sim”.
Esta resposta pode parecer ideal mas, se colocarmos a pergunta de outra forma, poderemos ter um resultado mais elucidante. Por exemplo: “Vejo no seu registro que nunca usou a atualização diária. Há algum motivo específico para isso?”.
Aí, o utilizador é capaz de mencionar problemas com a actualização diária dos quais não tinhamos noção, uma resposta mais valiosa que se simplesmente perguntarmos se o utilizador acha as actualizações diárias importantes. Quanto mais abertas forem suas perguntas, mais interessantes serão as respostas.
Da mesma forma que certos tipos de perguntas dão respostas mais interessantes, há também questões que devemos evitar numa entrevista:
Uma boa entrevista é aquela que nos elucida sobre coisas que de outra forma não teríamos como saber e, por isso, é importante tomar sempre atenção em escolher o público alvo que melhor representa o grupo de utilizadores finais e prestar atenção na formulação das perguntas para que, em conjunto com os outros métodos descritos nas publicações anteriores, possamos perceber melhor o utilizador final do nosso produto e, com isto, desenvolver a melhor solução possível para o seu problema.Por hoje é tudo. Daremos seguimento às nossas conversas em breve.
Até já.
Referências
Quando projectamos novas tecnologias, é importante identificar claramente um problema ou necessidade. Mas, depois de encontrá-lo, de nada vale correr para solucionar o problema sem antes perceber como é que a pessoa que vai usar a solução que vamos desenvolver pensa e age. Observar de forma participativa situações correntes, situações do dia-a-dia, ajuda-nos a construir empatia, a pensar no ponto de vista do utilizador e a entender melhor os seus hábitos, metas e valores.
A IDEO, uma das mais conceituadas agências de design do mundo, utiliza a etnografia, ou seja, uma inerção directa e prolongada com o utilizador final dos seus produtos, durante a pesquisa de campo, período inicial no desenvolvimento de produtos e/ou serviços. Isto é a essência da observação participativa: a documentação dos ambientes naturais onde pessoas trabalham e residem e a elaboração de entrevistas um pouco mais detalhadas, com o intuito de desenvolver empatia e identificar padrões de comportamentos e necessidades reais das pessoas para as quais estamos a desenvolver serviços e/ou produtos.
Na observação participativa, há alguns pontos importantes a destacar:
1. Quando vamos desenvolver um produto, é comum que as pessoas já usem uma metodologia especifica para alcançar os objectivos que o nosso produto pretende melhorar. Uma pergunta importante a fazer no início da pesquisa é: Que processos ou procedimentos as pessoas já usam para resolver este problema? Qual é a linha de base que se vai usar para avançar com a pesquisa?
2. Na maioria dos casos, vamos construir tecnologias que se alinhem com o que as pessoas se importam e esperam conseguir. Contudo, isso não significa que temos de construir o que as pessoas pedem, como é o caso da Walmart (que já veremos a seguir), mas sim projectar tecnologias e soluções que se entrelaçam na vida cotidiana das pessoas. Muitas vezes, as pessoas não sabem o que querem, especialmente quando se trata de tecnologias disruptivas então, aqui, o importante é perceber: Quais são os objectivos e valores das pessoas?
3. Para desenvolver soluções efectivas, é importante perceber o contexto maior onde essa solução se encaixa. Como é que as actividades particulares dos utentes estão inseridas numa ecologia maior de comportamentos? Como é que as actividades se integram do dia-a-dia dos utilizadores? Em que momento ou situação é que as pessoas realizam uma determinada tarefa?4. Nem todas as pessoas reagem da mesma forma a diferentes situações, por isso, é importante ter em conta as variáveis comportamentais.
Quais são as semelhanças e diferenças que se podem encontrar nas pessoas?Um dos exemplos usados pelo professor Klemmer foi a Walmart. Em 2009 Walmart fez uma pesquisa com seus clientes, onde perguntou se eles gostariam que os corredores fossem menos confusos e a resposta, sem muita surpresa, foi “Sim!”. Então, muito diligentemente, a Walmart começou a tornar os seus corredores menos confusos. Gastaram centenas de dólares no processo, removendo o stock, limpando as coisas e o que aconteceu? Eles perderam USD1.85 bilhões em vendas.
Parece surpreendente porque eles fizeram exatamente o que as pessoas pediram, certo? Mas a Walmart cometeu dois erros: o primeiro é que eles prestaram atenção ao que as pessoas disseram, em vez do que elas fizeram; o segundo é que a pesquisa deles fez uma pergunta principal: “Vocês gostariam que os corredores fossem menos confusos?”, ou seja, criaram uma solução e depois pediram para que os clientes concordassem com eles.
Juntos, estes dois erros induziram-lhes a tomar uma direção exatamente oposta àquela que deviam ter tomado: fizeram o que os clientes disseram que queriam (tornar os corredores menos confusos) em vez de observá-los e fazer o que eles realmente queriam (uma variedade de produtos a preços baixos).
E daí a importância da verdadeira observação, da prática, como já havíamos falado antes. De nada vale seguirmos cegamente os nossos planos sem realmente conhecer as necessidades de quem vai usar o produto final e sem receber feedback a cada passo. Um pouco mais de observação pode previnir erros monumentais.Vou terminar o artigo de hoje citando Yogi Berra: “We can observe a lot just by watching” que em tradução literal significa: “Nós podemos observar muito, só olhando”.
Até já.
Referências
O ciclo desenhar-testar-feedback é um loop contínuo quando se fala de bom design. Não se para de obter feedback; continua-se a criar versões cada vez mais avançadas do produto para obter um feedback cada vez melhor e mais detalhado. Os protótipos são justamente isso, modelos mais detalhados e interactivos do produto final, que nos permitem obter feedback muito mais rápido e preciso.A prototipagem é uma actividade vital em inovações estruturadas, colaboração e criatividade no Design.
Ela é uma estratégia eficiente para lidar com as coisas e situações que são difíceis de prever. Ao testar as coisas e aprender a partir desta exploração, podemos melhorar o projecto. Passamos a ter ideias, que de outra forma não conseguiríamos ter.
O principal objectivo da prototipagem, não é obter uma forma “final” do objecto ou producto em desenvolvimento, mas sim receber o feedback.Como componente do Design Thinking, uma metodologia de projecto que fornece uma abordagem baseada na solução para resolver problemas, a prototipagem é extremamente útil para lidar com problemas complexos, mal definidos ou desconhecidos, compreendendo as necessidades humanas envolvidas e re-estruturando a abordagem ao problema para que seja centrada no ser humano.
Para que servem os protótipos?Os protótipos respondem às seguintes perguntas:
1. Sentimento: Com o que é que isso se parece?
2. Implementação: Como pode funcionar?
3. Função: Como será a experiência na utilização do produto?
Técnicas de Prototipagem
Nem todos os protótipos são de igual impacto. Existem protótipos de alta e baixa fidelidade e estes se resumem em: sketches, wireframes e protótipos detalhados.Sketches – Os sketckes permitem verificar se o conceito e os requisitos foram percebidos, sem que seja necessário aplicar muito esforço. Esta é a técnica de prototipagem de menor fidelidade.
É ideal para a fase inicial do projecto por ser é fácil de criar e entregar mas, à medida em que se avança no projecto, os sketches tornam-se menos úteis. É difícil testar funcionalidades com sketches quando o produto se torna complexo.Wireframes – Os wireframes tornam fácil testar ideias e saber se elas funcionam na prática.
Estes são mais complexos que os sketches e se forem criados em softwaresespecializados é fácil adicionar o elemento “interação”. O aspecto de “produto finalizado” não é importante nos wireframes mas, é importante que tenha informações detalhadas para se avaliar como o utilizador irá reagir ao produto.
Protótipos – Estes são modelos funcionais do produto acabado. Eles são desenhados para emular as funcionalidades e bem como o aspecto do produto (look and feel). O protótipo é apresentado quando estão acertados e concordados todos os detalhes do produto e se avança para a fase de desenvolvimento.
Os protótipos, por sua natureza, levam mais tempo necessitam de mais custos para produzir.Uma das técnicas de prototipagem mais interessantes, citada pelo professor Klemer, chama-se o Mágico de Oz (nome inspirado pelo personagem de mesmo nome dos contos do escritor americano L. Frank Baum).
Esta era uma técnica usada em testes de produtos para economizar recursos de produção. Em vez de esperar que o protótipo esteja funcional para realizar testes, um operador humano funciona como computador (o Mágico de Oz), processando os resultados e posicionando as telas para o utilizador.
Um exemplo clássico de uso desta técnica é o Mechanical Turk, uma máquina de jogar xadrez do século XVIII que chegou a enganar famosos como Napoleão Bonaparte e outros. Dentro da caixa estava escondido um jogador de xadrez especialista e através de mecanismos especiais ele conseguia ler o jogo e mover as peças no tabuleiro.
Não interessa a forma específica de criar os protótipos, o que importa é o processo, é manter o ciclo desenhar-testar-feedback vivo e em movimento e chegar cada vez mais perto a uma versão ideal, compreensível e simples de usar, do nosso produto. Como já diz o professor Klemmer:
“Os protótipos são como perguntas, faça muitas.”
Até breve.
Referências
Para garantir “bom design”, a avaliação não é opcional mas sim crucial.A história que partilhei convosco na minha primeira publicação voltou a ser relevante quando aprendi que, mesmo mantendo o utilizador final em mente, o mais eficaz é pôr a interface em frente do utilizador e ouvir dele mesmo o relato da experiência de usar o sistema.
Muitos dos comportamentos do utilizador podem ser previstos na teoria, mas só testanto é que se garante que a interface traduz, da forma mais simples e intuitiva possível, tudo aquilo que foi conceituado. Os benefícios que podemos ter com estas avaliações não terminam por aí, mas também incluem desde insights que nos podem ajudar a gerar novas ideias ou alterações que podem melhorar a usabilidade do sistema de formas que não tinham sido pensadas antes e até à correção de bugs.
Como é que os utilizadores vão usar o sistema? Como reagem durante o usam? Riem-se? Reclamam? De que forma é que um design é diferente do outro? E se alterarmos a interface, como é que isso afecta o comportamento dos utilizadores? Que práticas novas podem surgir da avaliação? Como é que a forma de utilização da interface muda ao longo do tempo?
Estas são algumas das perguntas mais frequentes sobre as interfaces do utilizador, e as respostas para cada uma delas vêm de métodos de avaliação diferentes, o que significa que nenhum método é melhor ou pior que o outro e que a escolha de qual método usar depende principalmente do que é que se quer avaliar.
Alguns dos métodos mais usados são:
1. Estudos de Usabilidade: Um das formas de aprender sobre Experiência do Utilizador, é levar os utilizadores para um local de teste (geralmente um laboratório ou escritório) que pode ser equipado com um espelho sem reflexo que divide a sala, e a equipe de observação e os utilizadores ficam de lados opostos. Isto permite que a equipe de observação veja em tempo real como os utilizadores interagem com a interface e as suas reações.
2. Formulários: Uma forma diferente recolher feedback dos utilizadores é usando formulários. Estes ajudam a recolher informação de múltiplos utilizadores em menos tempo e é relativamente fácil comparar múltiplas alternativas. Para este caso não é necessário que a interface esteja completa e já em uso, podemos usar mockups ou screnshots.
3. Grupos Focais: Usar grupos focais significa reunir um pequeno grupo de pessoas para discutir sobre o sistema. Por um lado, conseguimos descobrir informações novas, dificuldades partilhadas, etc.; por outro lado, o cenário de “grupo” às vezes dá lugar para que as pessoas com personalidades mais fortes dominem a conversa e as pessoas com personalidades menos dominantes não se expressem ou não respondam de forma honesta, com o intuíto de agradar o grupo.
4. Feedback de Experts: Um feedback deste nível é chamado de Avaliação Heurística é um método de avaliação de interfaces baseado em princípios de usabilidade. Os princípios são chamados de heurísticas pois são desenvolvidos a partir de uma série de experiências prévias, sintetizando pontos recorrentes. A interface é submetida para diferentes avaliadores que darão seu parecer baseando-se nos mesmos princípios, as chamadas heurísticas.
5. Observação Participativa: Neste modelo de avaliação, o observador acompanha o utilizador no seu dia-a-dia, fazendo notas sobre como ele desempenha determinadas actividades e como estas podem causar alterações ao sistema no seu todo.
6. Modelos Formais – Simulação: Se houver uma teoria matemática formal, podemos fazer previsões e comparar interfaces, sem necessariamente ter de reunir os utilizadores numa sala de pesquisa. A simulação é um técnica de entrada muito usada porque o desempenho motor dos utilizadores é o mais quantificado em IHC.
Existem ainda outros métodos como: generalização, realismo e comparação, nos quais não vamos entrar em detalhe no post de hoje. Não existe um método certo ou errado. Cada tipo de pesquisa ou por outra, cada fase do desenvolvimento da interface requer que avaliemos diferentes factores e é a definição do que se pretende avaliar que vai determinar qual é o método mais apropriado de se usar naquele momento.
Por isso, a questão que se deve manter sempre em mente é: O que é que pretendemos avaliar?Para terminar o resumo de hoje, vou deixar-vos com uma pequena reflexão que de certeza algum grande pensador já alguma vez disse (ou talvez não, mas fica a reflexão na mesma): quem não avalia, mau design cria.
Até breve.
Referências
É importante estudar o passado para entender o presente e projectar o futuro.Muitas vezes, quando uma coisa se torna tão “parte” das nossas vidas, é difícil imaginar que algum dia elas não foram como são hoje. Ficamos com aquela impressão de que ela deve simplesmente ter sido criada tal e qual a conhecemos hoje e, de certa forma, minimizamos o valor de todo o trabalho que foi feito para que tal coisa saísse da imaginação, de uma simples idéia, à realidade da sua forma actual.
Entender que o processo de criação é exactamente isso – um processo – não só nos lembra de dar valor ao esforço e trabalho de todos que contribuíram para que estivéssemos onde estamos hoje, também lembra-nos que o processo criativo, o processo de materializar algo que está nas nossas cabeças, é árduo, trabalhoso e nem sempre acontece de imediato; pode levar dias, semanas, meses ou até mesmo anos.
A história da IHC – Interação Humano Computador iniciou em Julho de 1945, quando Vannevar Bush escreveu um artigo para a edição de Julho de 1945 da revista Atlantic Monthly, um magazine centrado, na altura, em comentário literário e cultural.
O artigo foi mais tarde reimpresso no Life Magazine, na edição de Setembro de 1945, com o título “As We May Think”. O objectivo do artigo, escrito nos últimos meses da Segunda Guerra Mundial, era de perguntar “o que é que os cientistas financiados pelo governo poderiam fazer para criar um mundo melhor em tempos de paz?”.
A visão de Bush era fortemente centrada no ser humano e contemplava a idéia de uma mesa interativa futurista, à qual chamou “MEMEX”.No centro da idéia do MEMEX, estavam interfaces do utilizador efectivas para armazenamento e recuperação de informações. Mais impressionante ainda, é que a visão que Bush tinha para o MEMEX foi responsável pelas idéias que deram origem à invenção do hipertexto.
Grace Hopper, que em 1944 foi uma das primeiras programadoras do Harvard Mark I e inventou o primeiro compilador para uma linguagem de programação, teve a idéia, no início da década de 1950, de trazer um interface amigável para os computadores. Ela pensou em como ferramentas melhoradas poderiam fornecer acesso à computação a uma audiência muito mais ampla.
Nos anos que se seguiram, o surgimento de cada vez melhores ambientes de programação para desktop e web permitiram que legiões de desenvolvedores criassem conteúdo que ajudasse a colocar um PC (Personal Computer) em cada mesa.Isto é o que acontece quando vamos construindo uma idéia por cima de outra, o que faz com que todo o aglomerado de inspiração, idéias criativas, e vontade de servir a humanidade com coisas que tornam o dia-a-dia cada vez mais simples, sirvam de fundação para os maiores avanços tecnológicos dos nossos tempos.
Do desejo de ter um mundo melhor após a guerra, à necessidade de melhor armazenar e recuperar informações, até à vontade de dar acesso à computação a um público mais abrangente, deu-se espaço à criação de interfaces do utilizador cada vez mais sofisticados e, consequentemente, ao desenvolvimento das tecnologias cada vez mais mais intuitivas que temos hoje.Existem três momentos principais que deram espaço à materialização da interface do utilizador tal como a conhecemos hoje:1)
As sementes da manipulação directa, ou seja, da forma intuitiva como movemos objectos num interface (como se fossem objectos físicos) em vez da manipulação usando linhas de comando (linhas de código, como eram usadas nos sistemas operativos antigos), foram plantadas nos MIT Lincoln Labs por Ivan Sutherland.
A principal inovação da interface gráfica do utilizador foi que a entrada (input de comandos) era realizada directamente, ou seja, quase que em simultâneo com a saída (output de resultados) no sistema. Essa operação directa de entrada-saída tornou a interface muito mais fácil de entender e muito mais intuitiva; a entrada (input) era feita com uma caneta leve (em semelhança das canetas Stylus que são usadas nos tablets hoje em dia), e a saída (output) era um gráfico oscilatório (em semelhança a um osciloscópio).2)
O segundo grande marco foi trazido por Doug Engelbart, técnico de radar da marinha americana, estacionado nas Ilhas Filipinas em 1945. Na biblioteca da marinha, ele encontrou uma cópia da revista Life que continha o artigo de Bush. Inspirou-se nele e teve uma visão que deu espaço à criação do mouse e do hipertexto, que foram as bases fundamentais para o desenvolvimento da web.
Levou tempo, mas ele conseguiu financiamento e começou a trabalhar no mouse. Engelbart mostrou ao mundo os resultados da sua pesquisa na sua famosa demo de 1968 (também entitulada “A ‘Mãe’ de Todos os Demos“).3) Após a demo inicial, Engelbart fez uma tournée/digressão apresentando-a a universidades e centros dedicados à pesquisa e desenvolvimento de tecnologias, tendo numa das suas apresentações parado na Universidade de Utah, onde Sutherland acabava de se juntar ao corpo docente.
Na audiência, estava Alan Kay, um aluno de doutoramento de Sutherland, que também sonhava com o computador pessoal. Depois de terminar o doutorado, Kay muda-se para o Stanford AI Lab e, mais tarde, para a Xerox PARC, onde ele expande sua visão: um Dynabook – o computador pessoal para crianças.
Com esta visão na mão, Kay e seus colegas na Xerox PARC começam a construir a fundação da interface do utilizador e anos depois, deram espaço à criação do Star (sistema de computação criado na Xerox), o primeiro sistema comercial a incorporar várias tecnologias que desde então se tornaram padrão em todos os PCs (display com bitmap, interface gráfica à base de janelas, ícones, ficheiros, mouse com dois botões, etc.).
Esta sequência de acontecimentos, embora no momento pudessem aparentar desconectadas, em retrospectiva têm um ar de intencionalidade. Da descoberta “ao acaso” de um artigo num magazine por um técnico da marinha americana nas Filipinas, ao encontro, anos mais tarde, do técnico com o autor do artigo que o inspirou e este último inspirando também a um aluno do técnico de marinha, agora professor universitário, faz-nos pensar nas várias formas em que variações destas coincidências podem estar a acontecer nas nossas próprias vidas, a todo momento.
O Star foi lançado aproximadamente 40 anos após a visão de Vannever Bush, 30 anos depois da invenção do compilador de Grace Hopper, 20 anos depois do primeiro sistema de Doug Engelbart entrar em funcionamento e 10 anos depois de Alan Kay começar a trabalhar no seu Dynabook.Isto é um exemplo daquilo a que Bill Buxton chama “O longo nariz da Invenção”.
Ele afirma que as primeiras idéias por detrás de novos paradigmas de tecnologias são “plantados” décadas antes da sua adopção comercial. E isto acontece não só com as tecnologias mas em todas as áreas, incluindo as nossas vidas: tudo o que cada um de nós é hoje, é resultado dos actos e idéias que plantamos, nutrimos, e ultimamente, colhemos a cada dia que passa.Mas chega de história por hoje. Na próxima publicação, abordararei assuntos mais práticos.Até já.
Referências
