Design centrado no usuário

Da Wikipédia, a enciclopédia livre
Ir para navegação Pular para pesquisar

O Design Centrado no Usuário ( UCD ) ou Desenvolvimento Orientado ao Usuário ( UDD ) é uma estrutura de processos (não restrita a interfaces ou tecnologias) em que objetivos de usabilidade , características do usuário, ambiente , tarefas e fluxo de trabalho de um produto , serviço ou processo são fornecidos atenção extensiva em cada estágio do processo de design . Esses testes são conduzidos com / sem usuários reais durante cada estágio do processo de requisitos , modelos de pré-produção e pós-produção, completando um círculo de prova de volta e garantindo que "o desenvolvimento prossiga com o usuário como o centro do foco." [1] [2]Esses testes [3] são necessários, pois geralmente é muito difícil para os designers de um produto entender intuitivamente os usuários iniciantes de suas experiências de design e como pode ser a curva de aprendizado de cada usuário . O design centrado no usuário é baseado na compreensão de um usuário, suas demandas, prioridades e experiências e, quando usado, é conhecido por levar a uma maior utilidade e usabilidade do produto, pois entrega satisfação ao usuário. [4]

A principal diferença de outras filosofias de design de produto é que o design centrado no usuário tenta otimizar o produto em torno de como os usuários podem, querem ou precisam usar o produto para que os usuários não sejam forçados a mudar seu comportamento e expectativas para acomodar o produto. Os usuários, portanto, ficam no centro de dois círculos concêntricos. O círculo interno inclui o contexto do produto, os objetivos de desenvolvê-lo e o ambiente no qual ele será executado. O círculo externo envolve detalhes mais granulares de detalhes da tarefa, organização da tarefa e fluxo da tarefa. [2]

História [ editar ]

O termo "Design Centrado no Usuário" foi cunhado por Rob Kling em 1977 [5] e posteriormente adotado no laboratório de pesquisa de Donald A. Norman na Universidade da Califórnia, San Diego . O conceito tornou-se amplamente popular como resultado da publicação do livro User-Centered System Design: New Perspectives on Human-Computer Interaction em 1986. [6] O conceito ganhou mais atenção e aceitação no livro seminal de Norman The Design of Everyday Things ( originalmente chamado de The Psychology of Everyday Things) Neste livro, Norman descreve a psicologia por trás do que ele considera um design "bom" e "ruim" por meio de exemplos. Ele exalta a importância do design em nossa vida cotidiana e as consequências dos erros causados ​​por designs inadequados.

Os dois livros incluem princípios para a construção de produtos bem projetados. Suas recomendações são baseadas nas necessidades do usuário, deixando de lado o que ele considera questões secundárias como a estética. Os principais destaques são:

  1. Simplificar a estrutura das tarefas para que as ações possíveis a qualquer momento sejam intuitivas.
  2. Tornar as coisas visíveis, incluindo o modelo conceitual do sistema, ações, resultados das ações e feedback.
  3. Obter os mapeamentos corretos entre os resultados pretendidos e as ações necessárias.
  4. Adotando e explorando as restrições dos sistemas

Em um livro posterior, Emotional Design , [7] : p.5 em diante, Norman retorna a algumas de suas ideias anteriores para elaborar o que ele considerou excessivamente redutor.

Modelos e abordagens [ editar ]

Por exemplo, o processo de Design Centrado no Usuário pode ajudar os designers de software a cumprir o objetivo de um produto projetado para seus usuários. Os requisitos do usuário são considerados desde o início e incluídos em todo o ciclo do produto. Esses requisitos são observados e refinados por meio de métodos investigativos, incluindo: estudo etnográfico, investigação contextual , teste de protótipo, teste de usabilidade e outros métodos. Métodos generativos também podem ser usados, incluindo: classificação de cartões , diagramação de afinidade e sessões de design participativo. Além disso, os requisitos do usuário podem ser inferidos por uma análise cuidadosa de produtos utilizáveis ​​semelhantes ao produto que está sendo projetado.

O Design Centrado no Usuário se inspira nos seguintes modelos:

  • Design cooperativo : envolvendo designers e usuários em pé de igualdade. Esta é a tradição escandinava de design de artefatos de TI e vem evoluindo desde 1970. [8] Isso também é chamado de co-design .
  • Design participativo (PD), termo norte-americano para o mesmo conceito, inspirado no Cooperative Design, com foco na participação dos usuários. Desde 1990, tem havido uma Conferência de Design Participativo semestral. [9]
  • Design contextual , "design centrado no cliente" no contexto real, incluindo algumas idéias do design participativo [10]

Aqui estão os princípios que ajudam a garantir que um design seja centrado no usuário: [11]

  1. O design é baseado em uma compreensão explícita de usuários, tarefas e ambientes.
  2. Os usuários estão envolvidos em todo o design e desenvolvimento.
  3. O design é conduzido e refinado por avaliação centrada no usuário.
  4. O processo é iterativo.
  5. O design aborda toda a experiência do usuário.
  6. A equipe de design inclui habilidades e perspectivas multidisciplinares.

Processo de Design Centrado no Usuário [ editar ]

O objetivo do design Centrado no Usuário é fazer produtos que tenham uma usabilidade muito alta . Isso inclui a conveniência do produto, em termos de uso, capacidade de gerenciamento, eficácia e quão bem o produto é mapeado para os requisitos do usuário. Abaixo estão as fases gerais do processo de Design Centrado no Usuário: [12] [13]

  1. Especifique o contexto de uso : identifique quem são os principais usuários do produto, por que usarão o produto, quais são seus requisitos e em que ambiente o usarão.
  2. Especificar requisitos : uma vez que o contexto é especificado, é hora de identificar os requisitos granulares do produto. Esta é uma fase importante que pode facilitar ainda mais aos designers a criação de storyboards e definir metas importantes para tornar o produto bem-sucedido.
  3. Criar soluções e desenvolvimento de design : com base nos objetivos e requisitos do produto, inicie um processo iterativo de design e desenvolvimento de produto.
  4. Avalie o produto : os designers de produto fazem testes de usabilidade para obter feedback dos usuários sobre o produto em cada estágio do design centrado no usuário.

Nas próximas etapas, o procedimento acima é repetido para finalizar ainda mais o produto. Essas fases são abordagens gerais e fatores como metas de design, equipe e sua linha do tempo e ambiente no qual o produto é desenvolvido determinam as fases apropriadas para um projeto e seu pedido. Você pode seguir um modelo em cascata , um modelo ágil ou qualquer outra prática de engenharia de software .

Objetivo [ editar ]

UCD faz perguntas sobre os usuários e suas tarefas e objetivos, em seguida, usa as descobertas para tomar decisões sobre desenvolvimento e design. O UCD de um site, por exemplo, busca responder às seguintes questões:

  • Quem são os usuários do site?
  • Quais são as tarefas e objetivos dos usuários?
  • Quais são os níveis de experiência dos usuários com o site e sites semelhantes?
  • Quais funções os usuários precisam do site?
  • De quais informações os usuários podem precisar e de que forma eles precisam?
  • Como os usuários acham que o site deve funcionar?
  • Quais são os ambientes extremos em que o site pode ser acessado?
  • O usuário é multitarefa?
  • A interface utiliza diferentes modos de entrada, como toque, fala, gestos ou orientação?

Elementos [ editar ]

Como um exemplo de pontos de vista UCD, os elementos essenciais do UCD de um site geralmente são as considerações de visibilidade, acessibilidade, legibilidade e linguagem.

Visibilidade [ editar ]

A visibilidade ajuda o usuário a construir um modelo mental do documento. Os modelos ajudam o usuário a prever o (s) efeito (s) de suas ações ao usar o documento. Elementos importantes (como aqueles que auxiliam a navegação ) devem ser enfáticos. Os usuários devem ser capazes de dizer rapidamente o que podem ou não fazer com o documento.

Acessibilidade [ editar ]

Os usuários devem ser capazes de encontrar informações de forma rápida e fácil em todo o documento, independentemente de seu comprimento. Devem ser oferecidos aos usuários várias maneiras de encontrar informações (como elementos de navegação, funções de pesquisa, índice, [14] seções claramente rotuladas, números de página, código de cores , etc.). Os elementos de navegação devem ser consistentes com o gênero do documento. ' Chunking ' é uma estratégia útil que envolve quebrar as informações em pequenos pedaços que podem ser organizados em algum tipo de ordem ou hierarquia significativa . A capacidade de folhear o documento permite que os usuários encontrem suas informações digitalizando em vez de lendo. Ousado epalavras em itálico são freqüentemente usadas para esse fim.

Legibilidade [ editar ]

O texto deve ser fácil de ler: por meio da análise da situação retórica, o designer deve ser capaz de determinar uma família de fontes e um estilo de fonte úteis . Fontes ornamentais, texto em letras maiúsculas , corpo de texto grande ou pequeno podem ser difíceis de ler e devem ser evitados. A coloração e o negrito do texto podem ser úteis quando usados ​​em cenários com muito texto. O alto contraste figura-fundo entre o texto e o fundo aumenta a legibilidade. O texto escuro contra um fundo claro é mais legível.

Idioma [ editar ]

Dependendo da situação retórica, certos tipos de linguagens são necessários. Frases curtas são úteis, assim como textos bem escritos usados ​​em explicações e situações semelhantes de texto em massa. A menos que a situação exija, jargões ou termos muito técnicos não devem ser usados. Muitos escritores escolherão usar a voz ativa , verbos (em vez de cadeias de substantivos ou nominais ) e uma estrutura de frase simples.

Ferramentas de análise [ editar ]

Existem várias ferramentas que são utilizadas na análise do Design Centrado no Usuário, principalmente: personas, cenários e casos de uso essenciais.

Persona [ editar ]

Durante o processo de UCD, uma Persona representando o usuário pode ser criada. A persona é um arquétipo de usuário usado para ajudar a orientar decisões sobre os recursos do produto, navegação, interações, e até mesmo design visual. Na maioria dos casos, as personas são sintetizadas a partir de uma série de entrevistas etnográficas com pessoas reais, em seguida, capturadas em descrições de 1-2 páginas que incluem padrões de comportamento, objetivos, habilidades, atitudes e ambiente, com alguns detalhes pessoais fictícios para trazer a persona para vida. [15]

Para cada produto, ou às vezes para cada conjunto de ferramentas dentro de um produto, existe um pequeno conjunto de personas, uma das quais é o foco principal do design. Há também o que se chama de persona secundária , onde o personagem não é o alvo principal do design, mas suas necessidades devem ser atendidas e os problemas resolvidos, se possível. Eles existem para ajudar a explicar outros possíveis problemas e dificuldades que podem ocorrer mesmo que a persona principal esteja satisfeita com sua solução. Há também um anti-persona , que é o personagem para o qual o design não foi feito especificamente.

Personas são úteis no sentido de que criam um entendimento comum e compartilhado do grupo de usuários para o qual o processo de design é construído. Além disso, eles ajudam a priorizar as considerações de design, fornecendo um contexto do que o usuário precisa e quais funções são simplesmente interessantes de adicionar e ter. Eles também podem dar um rosto e uma existência humanos a um grupo de usuários diversificado e disperso, e ajudar a criar alguma empatia e adicionar emoções ao se referir aos usuários. No entanto, como as personas são uma percepção generalizada do grupo de partes interessadas primárias a partir dos dados coletados, as características podem ser muito amplas e típicas ou muito de um "Joe médio". Às vezes, as personas também podem ter propriedades estereotipadas, o que pode prejudicar todo o processo de design. No geral,personas podem ser uma ferramenta útil a ser usada por designers para tomar decisões de design informadas ao redor, em oposição a se referir a um conjunto de dados ou uma ampla gama de indivíduos.

Personas também podem ser modificados por meio do UCD de um produto, com base em testes do usuário e mudança de ambiente. Esta não é uma maneira ideal de usar Personas, mas também não deve ser um tabu, especialmente quando se torna aparente que as variáveis ​​em torno do desenvolvimento de um produto mudaram desde o início do design e as personas atuais podem não atender bem às condições alteradas.

Cenário [ editar ]

Um cenário criado no processo UCD é uma história fictícia sobre a "vida diária de" ou uma sequência de eventos com o grupo de partes interessadas primárias como personagem principal. Normalmente, uma persona criada anteriormente é usada como o personagem principal desta história. A história deve ser específica dos eventos acontecendo relacionados aos problemas do grupo de partes interessadas primárias e, normalmente, as principais questões de pesquisa sobre as quais o processo de design é construído. Pode ser uma história simples sobre a vida cotidiana de um indivíduo, mas pequenos detalhes dos acontecimentos devem implicar em detalhes sobre os usuários, podendo incluir características emocionais ou físicas. Pode haver o melhor cenário , onde tudo funciona melhor para o personagem principal, o pior cenário, onde o personagem principal vivencia tudo dando errado ao seu redor, e um cenário de caso médio , que é a vida típica do indivíduo, onde nada de realmente especial ou realmente deprimente ocorre, e o dia segue em frente.

Os cenários criam um contexto social no qual as personas existem, e também criam um mundo físico real, ao invés de imaginar um personagem com características internas a partir de dados coletados e nada mais; há mais ação envolvida na existência da persona. Um cenário também é mais facilmente compreendido pelas pessoas, pois tem a forma de uma história e é mais fácil de acompanhar. Ainda assim, como as personas, esses cenários são suposições feitas pelo pesquisador e designer, e também são criados a partir de um conjunto de dados organizados. É importante garantir que os cenários sejam criados o mais próximo possível dos cenários do mundo real. No entanto, às vezes pode ser difícil explicar e informar como ocorrem as tarefas de baixo nível, por exemplo, o processo de pensamento de uma persona antes de agir.

Use caso [ editar ]

Resumindo, um caso de uso descreve a interação entre um indivíduo e o resto do mundo. Cada caso de uso descreve um evento que pode ocorrer por um curto período de tempo na vida real, mas pode consistir em detalhes intrincados e interações entre o ator e o mundo. É representado como uma série de etapas simples para o personagem atingir seu objetivo, na forma de um esquema de causa e efeito. Os casos de uso são normalmente escritos na forma de um gráfico com duas colunas: a primeira coluna rotulada como ator , a segunda coluna rotulada como mundo e as ações executadas por cada lado escritas em ordem nas respectivas colunas. A seguir está um exemplo de um caso de uso para tocar uma música em uma guitarra na frente de um público.

Ator Mundo
escolha música para tocar
pegar guitarra
exibir partituras
execute cada nota na partitura usando o violão
transmitir nota ao público usando som
o público fornece feedback ao artista
avalie o desempenho e ajuste conforme necessário com base no feedback do público.
música completa com os ajustes necessários
aplausos da audiência

A interação entre o ator e o mundo é um ato que pode ser visto na vida cotidiana, e nós os consideramos garantidos e não pensamos muito sobre os pequenos detalhes que precisam acontecer para um ato como a execução de uma peça musical existir. É semelhante ao fato de que quando falamos nossa língua materna, não pensamos muito sobre a gramática e como formular palavras; eles simplesmente saem porque estamos tão acostumados a dizê-los. As ações entre um ator e o mundo, notadamente, a parte interessada primária (usuário) e o mundo neste caso, devem ser pensadas em detalhes e, portanto, os casos de uso são criados para entender como essas pequenas interações ocorrem.

Um caso de uso essencial é um tipo especial de caso de uso, também chamado de caso de uso abstrato . Os casos de uso essenciais descrevem a essência do problema e lidam com a natureza do problema em si. Ao escrever casos de uso essenciais, nenhuma suposição sobre detalhes não relacionados deve ser feita. Além disso, os objetivos do assunto devem ser separados do processo e da implementação para atingir esse objetivo específico. Abaixo está um exemplo de um caso de uso essencial com o mesmo objetivo do exemplo anterior.

Ator Mundo
escolha partituras para tocar
reúne os recursos necessários
fornece acesso a recursos
executa a peça sequencialmente
transmitir e interpretar desempenho
fornece feedback
completa o desempenho

Os casos de uso são úteis porque ajudam a identificar níveis úteis de trabalho de design. Eles permitem que os designers vejam os processos reais de baixo nível que estão envolvidos em um determinado problema, o que torna o problema mais fácil de lidar, uma vez que certas etapas menores e detalhes feitos pelo usuário são expostos. O trabalho dos projetistas deve ser levar em consideração esses pequenos problemas para chegar a uma solução final que funcione. Outra maneira de dizer isso é que os casos de uso dividem tarefas complicadas em partes menores, onde esses bits são unidades úteis. Cada bit completa uma pequena tarefa, que então se transforma na tarefa final maior. Como escrever código em um computador, é mais fácil escrever as partes menores básicas e fazê-las funcionar primeiro e, em seguida, colocá-las juntas para terminar o código maior e mais complicado, em vez de lidar com o código inteiro desde o início.

A primeira solução é menos arriscada porque se algo der errado com o código, é mais fácil procurar o problema nos bits menores, pois o segmento com o problema será aquele que não funciona, enquanto na última solução, o o programador pode ter que examinar todo o código para procurar um único erro, o que consome muito tempo. O mesmo raciocínio vale para escrever casos de uso em UCD. Por último, os casos de uso transmitem tarefas úteis e importantes nas quais o designer agora pode ver quais são de maior importância do que outras. Algumas desvantagens de escrever casos de uso incluem o fato de que cada ação, do ator ou do mundo, consiste em poucos detalhes e é simplesmente uma pequena ação. Isso pode levar a mais imaginação e diferentes interpretações da ação de diferentes designers.

Além disso, durante o processo, é realmente fácil simplificar demais uma tarefa, uma vez que uma tarefa pequena derivada de uma tarefa maior pode consistir em tarefas ainda menores que foram perdidas. Pegar uma guitarra pode envolver pensar em qual guitarra pegar, qual palheta usar e pensar primeiro onde a guitarra está localizada. Essas tarefas podem então ser divididas em tarefas menores, como primeiro pensar na cor do violão que se encaixa no local para executar a peça e outros detalhes relacionados. As tarefas podem ser divididas em tarefas ainda menores, e cabe ao designer determinar qual é o lugar adequado para parar de dividir as tarefas. As tarefas podem não apenas ser simplificadas demais, mas também omitidas por completo, portanto, o designer deve estar ciente de todos os detalhes e de todas as etapas principais que estão envolvidas em um evento ou ação ao escrever casos de uso.

Veja também [ editar ]

Referências [ editar ]

  1. ^ "Capa - Basta perguntar: integrando acessibilidade em todo o design" . uiaccess.com .
  2. ^ a b "Notas sobre o processo de design centrado no usuário (UCD)" . www.w3.org .
  3. ^ Rubin, Jeffrey; Chisnell, Dana (10 de março de 2011). Manual de teste de usabilidade: como planejar, projetar e conduzir testes eficazes . John Wiley & Sons. ISBN 978-1-118-08040-5.
  4. ^ Vredenburg, Karel; Mao, Ji-Ye; Smith, Paul; Carey, Tom (2002). "Uma Pesquisa da Prática de Design Centrada no Usuário" (PDF) .
  5. ^ Kling, Rob (1977). "O Contexto Organizacional dos Projetos de Software Centrados no Usuário" . MIS Quarterly . 1 (4): 41–52. doi : 10.2307 / 249021 . ISSN 0276-7783 . JSTOR 249021 .  
  6. ^ Norman, DA (1986). Projeto de sistema centrado no usuário: novas perspectivas na interação homem-computador.
  7. ^ "Don Norman (2003) Emotional Design, Prolog-- Three Teapots" (PDF) . jnd.org .
  8. ^ Greenbaum & Kyng (eds): Projeto no trabalho - projeto cooperativo de sistemas de computador, Lawrence Erlbaum 1991
  9. ^ Schuler & Namioka: Projeto participativo, Lawrence Erlbaum 1993 e capítulo 11 no Manual de HCI de Helander, Elsevier 1997
  10. ^ Beyer & Holtzblatt, Contextual Design , Kaufmann 1998
  11. ^ "Fundamentos do projeto centrado no usuário" . www.usability.gov .
  12. ^ "Notas sobre o Processo de Design Centrado no Usuário (UCD)" . www.w3.org . Recuperado em 30 de março de 2017 .
  13. ^ "Fundamentos do projeto centrado no usuário" . www.usability.gov . Recuperado em 30 de março de 2017 .
  14. ^ Aaron., Scharf (1976). Um novo começo: primitivismo e ciência na arte pós-impressionista; [e] Retorno à natureza . Universidade Aberta. ISBN 0-335-05151-0. OCLC  1086245904 .
  15. ^ "Aperfeiçoando seu ourufrankline | Cooper Journal" . www.cooper.com . Recuperado em 6 de janeiro de 2016 .

Outras leituras [ editar ]

Vídeo [ editar ]