Change neon

Engaged - Designing for Behaviour Change by Amy Bucher - Simples Review com exemplos do que Aprendi

 

Terminei de ler o livro “Engaged – Design for Behavior Change”, que aprofunda vários temas de Behaviour Change e que nos ajudam a entender o comportamento humano. Amy Butcher utiliza de forma plena a Teoria da Autodeterminação (SDT) para nos guiar pelo complexo mundo Behaviour Change, enfatizando particularmente o aspeto crucial de integrar o Behaviour Change no Design de produtos e serviços digitais.

Embora o livro não aborde explicitamente os exemplos que enumerarei a seguir, eles permanecem altamente relevantes no contexto atual em que vivemos, sendo muitas vezes negligenciados por profissionais da área.

  • A E-Privacy e o GDPR – sendo, respetivamente, uma Diretiva Europeia e um Regulamento aplicado em Portugal, giram principal e logicamente em torno do panorama legal. No entanto, os mesmos foram criados porque não houve um respeito pelos utilizadores. Ou seja, a essência destes documentos está na necessidade de respeitar as escolhas das pessoas e estabelecer uma arquitetura de escolhas transparente. Os utilizadores têm o direito fundamental de compreender o propósito das tecnologias com as quais interagem, garantindo clareza e uma tomada de decisão informada.

 

  • Imagens nos maços de cigarros – Outro exemplo é a utilização de imagens gráficas em maços de cigarros como meio de desencorajar o tabagismo. Apesar das boas intenções, o conceito ignora um fator crucial conhecido como “Present Bias“. A suposição de que os indivíduos que compram cigarros têm o objetivo imediato de parar de fumar ignora a realidade de que a sua intenção principal é fumar. Ao não se guiar, primeiramente, as pessoas para a mudança de comportamento, a abordagem/tática pode não alcançar o impacto pretendido.

Estes exemplos ilustram a importância de alinhar estratégias de design com uma compreensão profunda do comportamento humano. E não o contrário. Sendo que o contrário pode ser uma grande black-box.

Ao se considerar as motivações subjacentes e os preconceitos cognitivos, os profissionais da área podem criar intervenções que ressoem nas pessoas a um nível profundo, promovendo mudanças de comportamento significativas e tornando a utilização do produto/serviço claro, transparente, duradouro e não apenas num pico de utilização com objetivo único e exclusivo de crescimento instantâneo.


O-que-são-Produtos-Digitais

Será Diferente Criar um Produto Digital em Ambiente Agile ou Waterfall?

Introdução

Já vimos na PARTE 1 – O que são Produtos Digitais. E na PARTE 2 – O que Envolve Criar Produtos Digitais? E como o Tema está Relacionado com o Scrum.

Vamos agora ver na PARTE 3 – se Será Diferente Criar um Produto Digital em Ambiente Agile ou Waterfall?

Ambiente Waterfall

Em ambiente waterfall significa, de forma não exaustiva, o seguinte:

  1. O tipo de projeto não envolve incertezas. Ou seja já se sabe o que se vai desenvolver/construir. Por exemplo, uma casa ou uma piscina.
  2. As as atividades desse projeto, por estar inserido num ambiente de certeza e não de incerteza, são desenvolvidas sequencialmente. Ou seja, após o términos de uma atividade, começa-se a segunda.
  3. Não existe um envolvimento direto do cliente e, por conseguinte, não é costume haver iterações à medida que as atividades vão sendo desenvolvidas
  4. Havendo possibilidade e vontade em fazer testes, estes são feitos em grande escala no final de todas as atividades estarem concluídas

Ambiente Agile

O ambiente agile significa, o contrário do ambiente waterfall. Ou seja, e de forma não exaustiva:

  1. Os projetos mais adequados para serem desenvolvidos neste tipo de ambiente são projetos complexos e que envolvem algum grau de incerteza. Por exemplo, o desenvolvimento de um produto digital, enquadra-se neste tipo de projetos.
  2. Todas as atividades que se consideram necessárias para produzir um incremento, são realizadas no sprint correspondente. E, portanto, daqui surgem duas grandes diferenças de projetos em ambiente waterfall e ambiente agile:
    1. As equipas devem ser multi-disiplinares e autónomas
    2. Os testes, devem ser considerados uma atividade que produz um incremento e, portanto, são realizados em cada sprint e não no final do projeto. Até porque, e passamos para o ponto 3…
  3. Tem de existir um envolvimento direto do cliente. Isto porque não sabemos a 100% como vai ser o produto final. E o cliente também não sabe. E, portanto o cliente tem de estar envolvido no desenrolar do projeto. Por exemplo, criando atividades de UX Research na fase em que Visão do Produto está a ser desenvolvida. E com isso, valorizamos e muito o início do projeto, porque a Visão do Produto incorpora findings e insights daquilo que são as necessidades, frustrações e motivações dos cliente.
  4. Outra altura onde o cliente pode estar presente será nas cerimónias de review para recolha direta de feedback. e, por conseguinte, não é costume haver iterações à medida que as atividades vão sendo desenvolvidas. Ou seja, e vamos para o ponto 4…
  5. Há iterações entre as equipas, clientes e stakeholders. Iterações essas que nos vão permitindo afinar o produto final. Como? Redefinindo e refinando o backlog prioridades de produto e, posteriormente, o backlog da sprint.

Conclusão

Poder-se-ia dizer que se as metodologias, ou melhor, se os ambientes ou frameworks são diferentes, então, obrigatoriamente, será diferente criar um produto digital em ambiente agile do ambiente waterfall. E dizer isto não está errado. Afinal é uma verdade de La Palice.

O problema é que não basta dizer que estamos ou adotamos uma metodologia agiela e o desenvolvimento do produto digital, per si, será diferente.

Quem faz os ambientes serem waterfall ou agile ou de outro tipo são as pessoas. E, portanto, se não houver vontade, motivação, aprendizagem e um step-up, sem medos e com compreensão 100% da hierarquia de quais são os papéis de cada um e o que isso implica, para mudar a cultura da Empresa e assim efetivamente implementar o ambiente agile, o que vai acontecer é que estaremos a desenvolver um produto digital em ambiente “pseudo-agile”; ou seja na realidade o ambiente é waterfall.

Há várias de formas de perceber isso, elenco apenas quatro:

  • O cliente não é envolvido de início e ao longo do desenvolvimento
  • As equipas não são multi-disciplinares nem autónomas
  • A priorização das atividades ou a re-priorização das mesmas ou de algumas delas, não é feita pelo PO, mas está dependente do cargo da pessoa que faz um pedido.
  • Os testes são feitos “em barda” dias antes do lançamento do produto para o mercado

Espero que tenham gostado e aprendido alguma coisa neste conjunto de 3 artigos sobre produtos digitais.

Want to read this article in English? Please click here


O-que-são-Produtos-Digitais

O que Envolve Criar Produtos Digitais? E como o Tema está Relacionado com o Scrum

Introdução

Já vimos na PARTE 1 – O que são Produtos Digitais. Vamos agora ver o que envolve, em termos de negócio e de equipas, criar um produto digital.

A PARTE 3 – Será Diferente Criar um Produto Digital em Ambiente Agile ou Waterfall? Será publicada no final do mês de Agosto.

 

O que Envolve Criar um Produto Digital?

Criar um produto digital não é pensar o design e depois bater código. Desenvolver um produto digital envolve muito mais do que design e desenvolvimento. Tal como a construção de uma casa não envolve apenas um desenho do arquiteto. Ainda que a construção de uma casa seja um projeto fechado e um projeto que decorre em ambiente certo.

Existem diferentes temas que são essenciais para descobrir, posicionar, desenvolver, monitorar, comunicar e impulsionar a adoção deste tipo de produtos.

 

Visão do Produto – Envolve identificar os diferenciais do produto, definir a proposta de valor única e criar mensagens de marketing que comuniquem esses aspectos de maneira convincente.

 

User Experience Research – Antes de se criar um produto digital, é crucial realizar perceber quais as necessidades, motivações, frustrações, expectativas e emoções dos clientes ou potenciais clientes.

O trabalho de desenvolvimento de um produto digital deve ser feito com base em Outcomes e não em Outputs.

As atividades de UX Research fornecem uma base sólida para as decisões de design, permitindo que as equipas validem hipóteses, identifiquem problemas de usabilidade e iterem rapidamente com base no feedback dos utilizadores. Além disso, o foco contínuo nas atividades de UX Research possibilita a adaptação às mudanças ao longo do projeto, tornando o Scrum ainda mais eficiente e eficaz na entrega de soluções inovadoras e centradas no usuário.

 

User Interface Design – Aspeto fundamental do processo de desenvolvimento de produtos, dedicado a criar interfaces visualmente atraentes e user friendly que melhoram a experiência geral dos utilizadores. Estas atividades de desenho do user interface concentram-se em temas que permitam desenvolver interações entre os utilizadores e esses produtos digitais, garantindo que cada interação seja fluida e intuitiva

O User Interface Design não é só algo estético; deve haver um esforço para se encontrar o equilíbrio entre forma e função. Um interface bem pensado (UX Research) guiará os utilizadores ao longo do produto de forma suave e sem atritos, ajudando-os a realizar as suas atividades de forma eficiente e com o mínimo de frustração.

Podem saber mais sobre o tema Como Definir os Princípios de Design.

 

UX Writing ou Marketing de Conteúdo – A criação de conteúdo relevante e valioso é fundamental para a atração e retenção de potenciais utilizadores dos nossos produtos. O UX Writing não se restringe só à escrita de textos para blogues. Todo o conteúdo de um website ou loja online ou de outro produto digital deve ter uma estratégia de UX Writing. Além dos de vídeos, animações, white papers ……

E é preciso saber como escrevê-los; onde colocá-los no nosso produto e quando colocá-los.

 

SEO – A otimização para os motores de pesquisa é fundamental para garantir que o produto digital seja encontrado online, quando os utilizadores pesquisarem por keywords relevantes. Isso envolve a criação pensada e estruturada da arquitetura de Informação desse produto digital, a inserção/utilização adequada de keywords de forma a otimizar o conteúdo e a criação de backlinks.

O UX Writing ou Marketing de Conteúdo e o SEO são disciplinas que têm muita interligação entre si.

 

Acessibilidade A acessibilidade no contexto do design, dentro de uma equipa que utiliza o Scrum, refere-se às atividades e práticas implementadas para garantir que o produto desenvolvido seja inclusivo e facilmente utilizado por todas as pessoas, independentemente de suas capacidades e/ou necessidades específicas. Este tema, tal como os anteriores e os a seguir devem ser considerados pelas equipas desde o início das atividades do projeto, incorporando-a em todas as etapas do ciclo Scrum.

Este tema, deverá ser também tido em conta aquando das atividades de UX Research. Podem ler mais sobre Empathy as a Service.

 

Analytics — Desempenha um papel fundamental no desenvolvimento de produtos dentro de um ambiente ágil. Ao aproveitar o poder dos dados e os insights que se obtêm a partir deles, as equipas podem tomar decisões informadas em cada etapa do processo de desenvolvimento.

Análises qualitativas — A incorporação de análises qualitativas capacita as equipas a adaptar estratégias com base no feedback dos clientes e em tempo real, garantindo que as suas necessidades, motivações, frustrações são tidas em conta no desenvolvimento do produto.

Análises quantitativas — Essas análises permitem compreensão profunda dos comportamentos, preferências e pontos problemáticos dos usuários, o que influencia significativamente o aperfeiçoamento e a otimização de produtos digitais. Podemos utilizar ferramentas de web analytics e/ou de user behaviour analytics.

 

Desenvolvimento – As atividades de desenvolvimento é tudo aquilo que engloba colocar em prática todo o trabalho desenvolvido nas atividades anteriormente descritas. O trabalho de desenvolvimento não é só olhar para o “design” e começar a programar. Algumas atividades que devem ser tidas em conta antes do desenvolvimento front-end e back-end apresentam-se abaixo.

    • Arquitetura funcional
    • Arquitetura técnica
    • From-end development
    • Back-end development e Gestão de Base de Dados
    • Integração de sistemas e desenvolvimento de infra-estruturas

 

Testes – Em ambiente agile todas as user stories devem ser testadas pelo membro da squad para o efeito. Desenganem-se aqueles que acreditam que os testes são feitos pelas pessoas das organizações ou que se podem fazer depois testes de usabilidade com os clientes. Deixarmos a realização dos testes, com as funcionalidades já em produção, para outras pessoas e/ou para os clientes fazerem é meio caminho andado para que a dívida técnica/UX aumente. Além de que não cumpre com aquilo que a framework do scrum apregoa.

    • Testes de Carga do Servidor
    • Testes das Funcionalidades
    • Produção de quick reports com as respetivas conclusões/correções a fazer

Depois numa fase já mais estabilizada do produto, podemos desenvolver então os testes com os utilizadores.

 

Gestão da Release – A gestão da release no contexto do Scrum refere-se ao processo de planeamento, coordenação e entrega dos outputs, sempre baseados em outcomes (o que defendo) desenvolvidas ao longo das várias sprints pronto para ser disponibilizado aos utilizadores.

Muito importante na gestão da release, nomeadamente se for uma gestão da release já com o produto “fechado” (se bem que o produto nunca estará fechado) é a definição da estratégia de lançamento.

 

Estratégia de Lançamento – A estratégia de lançamento engloba as atividades que têm como objetivo informar os utilizadores sobre as diversas vertentes do produto. A estratégia de lançamento focam-se, na sua maioria, em temas de comunicação como:

  • Campanhas offline (TV, rádio, jornais, revistas, outro tipo de publicações)
  • Organização de Eventos
  • Campanhas online (e-mail, ppc, social media, afiliados, ….)
  • Redes Sociais
  • Influenciadores

 

Conclusão

É fundamental ter em atenção a todos estes temas quando se desenvolve um produto digital, seja em ambiente agile ou ambiente waterfall. Nomeadamente, é imperativo considerar estes temas em cada uma das fases dos ambientes agile:

  • visão do negócio/produto
  • Desenvolvimento do backlog do produto
  • Desenvolvimento do backlog da sprint (Priorização de acordo com aquilo que é a visão do negocio)
  • Cerimónias de Planeamento
  • Cerimónias de Review
  • Cerimónias de Retrospective

Além disso, fica bem patente, tal como o Scrum advoga, que um desenvolvimento de um produto digital não é só desenhar e programar o desenhado.
Sabe mais sobre Scrum neste artigo – Scrum for Dummies”: Papéis e Eventos – Comparação com o Futebol

 

Want to read this article in English? Please click here


O-que-são-Produtos-Digitais

O que são Produtos Digitais?

Introdução

Quando pensei escrever este artigo tinha imaginado um título do género “Como gerir projetos digitais (ou não) que são transversais à Empresa e/a determinado produto digital em ambiente agile”. Mas dediquei algum do meu tempo a pensar no assunto e percebi que o título não faz sentido algum.

E para não tornar o artigo demasiado longo dividi-o em 3 partes:

PARTE 1 – O que são Produtos Digitais

PARTE 2 – O que Envolve Criar um Produto Digital

PARTE 3 – Será Diferente Criar um Produto Digital em Ambiente Agile ou Waterfall?

 

O que são Produtos Digitais?

Um produto digital é todo o produto que pode ser utilizado e/ou comercializado online. Ou seja, podemos ter como produtos digitais aqueles que são passíveis de download e aqueles que não são passíveis de download:

 

Produtos Digitais Passíveis de Download

  • Produtos que os utilizadores podem fazer o seu download e começam a utilizá-lo. Por exemplo uma App para afinar a guitarra como o Guitar Tuner.

 

Produtos Digitais Não Passíveis de Download – SAAS / Cloud Software

  • Produtos em que os utilizadores não necessitam de fazer download dos mesmos e ainda assim utilizá-los na modalidade de free, paga ou freemium. Todos os Softwares As a Service são este tipo de produtos. Por exemplo, a Google Cloud Platform funciona como SAS.

 

Produtos Digitais como Extensão da Experiência de Cliente – Canal Online

Depois ainda existe uma categoria de produtos digitais que são um misto entre as duas categorias acima. E que eu caracterizo não como produtos digitais, mas sim como táticas ou canais de comunicação com os utilizadores. Por exemplo:

ebooks – livros; Webinars – Conferências; PodCasts – Entrevistas; Cursos online – aulas presenciais; Websites/Lojas Online – sede ou loja física

Conclusão

A criação de produtos digitais, não é desenhar e desenvolver o front-end desse desenho. Nem é desenvolver o back-end desse front-end.

Pensar em desenvolvimento de produtos digitais com foco apenas em design, front-end e back-end vai dar origem a:

1 – Potenciais MVPs mal definidos

2- Desenvolvimento de produtos com base em features (outputs) e não outcomes (mudança que queremos ver no mundo ou nas pessoas para que a vida delas se torne melhor)

3 – Dívida Técnica com uma enormidade de bugs e issues para corrigir

4 – Custos escondidos – de desenvolvimento ou de redesenvolvimento; horas-extra da equipa; possíveis custos no suporte ao cliente, entre outros

Será isto fácil de implementar nas empresas? Certamente que não o é! Mas é meio caminho se as pessoas envolvidas tiverem esta visão e a colocar em prática, mesmo que devagar este princípio.

 

O próximo artigo PARTE 2 – O que Envolve Criar um Produto Digital

Want to read this article in English? Please click here


Checklist de Atividades de UX e de UI para (Re)Lançamento de um Website - 12 Atividades a Considerar - PARTE 1

Introdução 

Como todos os lançamentos ou relançamentos de um website é preciso, além de objetivos bem claros e definidos, é preciso ter em atenção as atividades que são necessárias desenvolver e planeá-las. As atividades para o lançamento ou relançamento de um website atravessam várias áreas do digital: desde atividades de UX, passando pelas atividades de UI e de Conteúdos, e atividades de SEO ou de Analytics.

Obviamente que à partida estou a considerar que os Objetivos do Website (lançamento ou relançamento) já foram ou estão definidos com recorrência e suporte das atividades de UX Research, nomeadamente no Estudo de Personas; Estudo da Experiência (pain points e love moments) e no Benchmarking e das Best Practices de UX/UI. 

Neste artigo que será o primeiro de quatro irei elencar que atividades de UX e de UI é preciso ter em consideração no lançamento ou relançamento de um website.

 

Arquitetura de informação - Checklist de Atividades de UX e de UI para (Re)Lançamento de um Website - 12 Atividades a Considerar

1 – (Re) Definição da Arquitetura de Informação

  • O que é: Se procurarmos o significado etimológico da palavra “Arquitetura” vemos que significa “primeiro construtor”. E em UX/UI também não é diferente o seu significado. A Arquitetura de Informação como atividade de UX/UI para (re)desenho de um website significa criar as bases e os alicerces do sistema de informação do website e a forma como as mesmas são apresentadas e como se interligam e comportam em resposta a ações do utilizador. 
  • Para que serve: A Arquitetura de Informação de um website defini-se como sendo páginas do website A arquitetura da informação é uma atividade que pode e deve ter também o deliverable respetivo. Além disso, é uma atividade que deve ser pensada em conjunto com as área de SEO e de Conteúdos, porque no primeiro caso vai ser preciso criar o sitemap dessa arquitetura para colocar ou a) na raíz do código fonte do website; 2) compará-la com o sitemap criado automaticamente via plugin do CMS do website. No que respeita à área dos Conteúdos, simultaneamente com a área de SEO, terão a responsabilidade de analisar e verificar se as keywords utilizadas no sitemap estão em consonância com aquilo que os utilizadores pesquisam.
  • Quais são os seus componentes: Sendo a Arquitetura de Informação um sistema, é elementar que seja composto por vários processos e são eles: os processos de organização, os processos de rotulagem; os processos de navegação e os processos de pesquisa. Estes 4 processos devem ser trabalhados em simultâneo. 
  • Quem deve estar envolvido: Equipas de UX, de Conteúdos, e de SEO
  • Entregáveis: O principal entregável da Arquitetura de Informação para o (re)desenho de um website é o sitemap que não é nada mais nada menos do que um mapa com a hierarquia das diferentes páginas do website bem como denominação dos tipos de conteúdos das mesmas, nomeadamente ao nível dos títulos.

 

user flows - Checklist de Atividades de UX e de UI para (Re)Lançamento de um Website - 12 Atividades a Considerar2 – Criação dos User Flows

  • O que é: Os user flows são uma forma de representar, graficamente, o caminho ou os caminhos que os diferentes utilizadores (personas) irão “percorrer” ao navegar no novo ou redesenhado website. E existem 3 tipos de user flows, sendo que todos eles representam atividades, mas uns podem ser mais rudimentares do que outros no sentido em que podemos estar apenas a falar de um simples fluxograma (task flow) ou de um fluxograma relacionado com wireframes já feitos (wire flow) ou exatamente a mesma coisa, mas para cada uma das personas (user flow). 
  • Para que serve: Eu, pessoalmente, considero haver 2 motivos para ter que se desenhar user flows: 1 – perceber se a Arquitetura de Informação está bem pensada ou deve ser revista; 2 – Garantir que o novo ou redesenhado website têm endereçadas todas as atividades que nos propusemos e que queremos que o utilizador, porque é uma necessidade dele.
  • Quais são os seus componentes: Se estivermos a falar de task flows os componentes são os de um fluxograma típico e ilustrativo de uma atividade. Se estivermos a falar de wire flows, os componentes são os diferentes ecrans dos wireframes ligados entre si. As componentes dos user flows são idênticas às do wire flows, mas são inerentes a cada uma das personas estudadas previamente, uma vez que podem haver diferentes use cases de navegação. 
  • Quem deve estar envolvido: Equipas de UX e de SEO, se necessário
  • Entregáveis: O principal entregável são os diferentes user flows de todas ou das principais ações que os utilizadores podem fazer no website.

 

wireframes - user flows - Checklist de Atividades de UX e de UI para (Re)Lançamento de um Website - 12 Atividades a Considerar3 – (Re)Desenho dos Wireframes

  • O que é: Os wireframes são os “esqueletos” daquilo que será o novo website, seja novo no sentido estrito da palavra, seja renovado. oOs wireframes dão uma visão geral da estrutura de cada uma das páginas do website – arquitetura de informação – do layout, dos diferentes user flows e funcionalidades que despontarão os comportamentos dos utilizadores.
  • Para que serve: Os wireframes servem para, essencialmente, para dois objetivos:
    • Apresentar a estrutura, conteúdo e layout do website (imagens e copy e alguma interatividade) desenvolvido com base naquilo que são as necessidades dos utilizadores.
    • Reduzirmos os custos de design – UI – e desenvolvimento – DEV – no desenho ou redesenho de um website e, portanto, utiliza-se, na verão mais “pobre” lápis, papel e borracha para se desenhar os tais esqueletos do website – wireframes.
  • Quais são os seus componentes: Não existem componentes dos wireframes de um website. Mas, posso alertar que não é preciso ser um designer para produzir wireframes. É preciso saber desenhar “círculos”, “quadrados”, “triângulos”, “semi-retas”, saber escrever e pouco mais.  
  • Quem deve estar envolvido: Equipas de UX e de SEO e de UI, se necessário.
  • Entregáveis: O próprio wireframe em papel ou em ficheiro de softwares como o Axure, Balsamiq, Figma e similares.

 

protótipos - wireframes - user flows - Checklist de Atividades de UX e de UI para (Re)Lançamento de um Website - 12 Atividades a Considerar4 – (Re)Desenho dos Protótipos

  • O que é:  Os protótipos nada mais são do que “wireframes on steróids”. Ou seja, são wireframes que já foram mais trabalhados no sentido de já ter alguma componente gráfica e de cores, de já ter mais animações e ser muito mais interativo. 
  • Para que serve: AO grande e principal objeto do desenho dos protótipos é o de serem testados com os utilizadores finais, já que os protótipos por regra, e depois de toda a fase de estudo das necessidades dos utilizadores, devem ser muito idênticos em termos de arquitetura de Informação, user flows e interatividade, ao produto final – UI.
  • Quais são os seus componentes: Não existem grandes componentes num protótipo já que é quase o produto final. Podemos é ter protótipos do website, de uma app. 
  • Quem deve estar envolvido: Equipas de UX, e se necessário de UI
  • Entregáveis: O principal entregável é o protótipo em si, feito em Figma ou em Sketch, por exemplo.

 

user interface - ui - protótipos - wireframes - user flows - Checklist de Atividades de UX e de UI para (Re)Lançamento de um Website - 12 Atividades a Considerar5 – Definição do UI – User Interface

  • O que é: O user interface nada mais é que o “desenho” puro e duro daquilo que foram os wireframes e os protótipos. É dar vida, ou melhor dizendo, dar fogo à peça. 
  • Para que serve: Nesta Checklist de 12 atividades de UX/UI que devemos ter em conta ao (re)desenhar um website, o desenho do user interface – UI – é a fase final do processo, antes do mesmo ser passado para os developers. É como se fosse o “pintar” as paredes exteriores da casa.
  • Quais são os seus componentes: Se estivermos a falar de implementação de um Design System, existem muitos componentes associados. Por exemplo, existem os Princípios de Design, os Logos, a iconografia, a tipografia, o layout com grelhas e breakpoints, ilustrações, animações, e os diferentes componentes gráficos  per si – botões, tabelas, gráficos, overlays, listas….mais recursos de e para consulta. Se não for esse o caso, provavelmente os componentes resumem-se a paleta de cores e tipografia e logos e pouco mais.  
  • Quem deve estar envolvido: Equipas de UI e potencialmente, dependendo do trabalho e do entregável, equipas de UX Writing.
  • Entregáveis: Se estivermos a falar de equipas de UX/UI e restantes áreas digitais numa Empresa com maturidade e cultura digital avançada, o entregarem pode e deverá ser um Design System ou um update ao Design System. Se, pelo contrário, a empresa não tem essa maturidade, os entregáveis podem passar por um Guia de Estilos onde podem estar descriminados as cores principais e secundárias a serem utilizadas, família tipográfica, tom de voz, logotipos e suas dimensões e pouco mais.

 

design system - user interface - ui - protótipos - wireframes - user flows - Checklist de Atividades de UX e de UI para (Re)Lançamento de um Website - 12 Atividades a Considerar6 – Update e/ou Criação do Design System

  • O que é: Um Design System é um conjunto de regras padronizadas que permitem às empresas escalarem os temas de design, reduzindo o esforço das equipas, os custos e a redundância, uma vez que todos trabalham seguindo uma metodologia que permite ter uma linguagem visual comum e consistência entre ativos digitais e canais. 
  • Para que serve: Como visto acima, o Design System serve para as equipas operem segundo uma linguagem visual comum e construam ativos digitais consistentes para os diferentes canais em que a Empresa tem presença. Obviamente que isto irá permitir às empresas reduzirem o time to market ou o time to launch dos seus produtos digitais.
  • Quais são os seus componentes: Os componentes de um Design System variam de empresa para empresa, mas de uma maneira geral poderemos ter: a secção dos Fundamentos do Design System, onde estarão incluídos, entre outros, os Objetivos e os Princípios de Design; a secção de Componentes, que será o core do Design System, com todos os elementos/componentes gráficos necessários para o desenho e escalamento dos ativos digitais; Fontes de Estudo/Pesquisa.  
  • Quem deve estar envolvido: Equipas de UX, UI e outras se necessárias
  • Entregáveis: Repositório ZeroHeight, por exemplo com todos os elementos que compõem um Design System e Biblioteca Figma, por exemplo com todos os componentes gráficos que servem de base ao Design System.

 

acessibilidade - design system - user interface - ui - protótipos - wireframes - user flows - Checklist de Atividades de UX e de UI para (Re)Lançamento de um Website - 12 Atividades a Considerar7 – Definição das Questões de Acessibilidade

  • O que é: A acessibilidade é desenhar e desenvolver os ativos digitais tendo sempre em mente a inclusão de todo o tipo de utilizadores, nomeadamente utilizadores com problemas de visão, cognitivos, de surdez, físicos, verbais, neuropsicológicos, mas não só. Por exemplo utilizadores sem este tipo de problemas, se tiverem de ver um website no smartphone que não está adaptado para o efeito é também uma questão de usabilidade.
  • Para que serve: O objetivo do design para todo o tipo de utilizadores é o da inclusão. Não será à toa que todos o a grande maioria dos websites públicos portugueses estão desenhados com estas regras. Por exemplo, o website da Presidência da República Portuguesa.
  • Quais são os seus componentes: nd  
  • Quem deve estar envolvido: Equipas de UX, de UI e, se necessário, de Conteúdos e de SEO
  • Entregáveis: O As especificações de acessibilidade podem vir descriminadas no Documento final de especificações para os developers.

 

direcionamentos-de-páginas - acessibilidade - design system - user interface - ui - protótipos - wireframes - user flows - Checklist de Atividades de UX e de UI para (Re)Lançamento de um Website - 12 Atividades a Considerar8 – Especificações dos Direcionamentos das Páginas

  • O que é: Os direcionamentos das páginas significam qual a navegação que o utilizador vai ter ou vai fazer ao visitar o website. 
  • Para que serve: AOs direcionamentos servem para os utilizadores navegarem ao longo do website.
  • Quais são os seus componentes: Os utilizadores podem navegar no website seguindo 3 vias: Navegação Global – feita através do menu principal e até mesmo secundário do website; Navegação Hierárquica – feita através dos menus específicos de cada página; e Navegação Local/Circular – ; e Navegação Circular – Feita via os diferentes botões (CTA – Call-To-Action) ou hiperligações presentes nas diferentes páginas do website.  
  • Quem deve estar envolvido: Equipas de UX e, se necessário de SEO
  • Entregáveis: Os direcionamentos das páginas podem estar especificados no entregável para o efeito com outras especificações, por exemplo de interatividade e de SEO ou pode-se produzir um Excel com o mapeamento dos URLs das diferentes páginas do website e indicação para onde devem encaminhar o utilizador.

 

direcionamentos-de-páginas - acessibilidade - design system - user interface - ui - protótipos - wireframes - user flows - Checklist de Atividades de UX e de UI para (Re)Lançamento de um Website - 12 Atividades a Considerar9 – Especificações de Headings das Páginas para SEO 

  • O que é: São os principais componentes do conteúdo das diferentes páginas do website, no que ao copy diz respeito. Para cada uma dessas páginas do website funcionam como os títulos principais e secundários (headings) de um índice de um documento.
  • Para que serve: À semelhança daquilo que acontece com a Arquitetura de Informação, a definição dos Headings de páginas para SEO serve para os utilizadores e os motores de pesquisa entenderem a arquitetura/hierarquia de informação das diferentes páginas, através deste processo específico de organização e rotularem de elementos – títulos, sub-títulos e parágrafos de texto. Também serve, em termos de acessibilidade, para os utilizadores poderem ler, com os screen readers, e perceber como está construída a página.
  • Quem deve estar envolvido: Equipas de UX e equipas de SEO
  • Quais são os seus componentes: Considero que os componentes dos Headings para SEO podem ir desde o atributo HTML <H1> até ao <H6> e para textos poderemos estar a falar de atributos HTML <p>. Mas por norma, uma página de um website, em princípio, não terá mais do que 2 ou 3 atributos destes, ou seja terá um atributo H1 e depois tudo atributos H2 ou uma mescla entre atributos H2 e atributos H3.
  • Entregáveis: O entregável desta atividade pode ser o protótipo onde em cada titulo de página e/ou subtítulo devem estar especificados que tipo de Headings devem ser considerados no desenvolvimento dessa página pelos front-end developers.

Pode também ser construído de raíz um documento de especificações, em que deverá ter uma secção que contemple as especificações de headings de SEO para os diferentes títulos, sub-títulos e textos das diferentes páginas do novo website Documento composto pelas diferentes páginas do novo website.

 

responsive design direcionamentos-de-páginas - acessibilidade - design system - user interface - ui - protótipos - wireframes - user flows - Checklist de Atividades de UX e de UI para (Re)Lançamento de um Website - 12 Atividades a Considerar10 – Definição dos break points para outros Dispositivos – Responsive Design

  • O que é: São testes de usabilidade feitos ao protótipo e junto dos utilizadores finais.
  • Para que serve: Os break points servem para o website se poder adaptar em termos de conteúdo aos diferentes ecrans dos diferentes dispositivos, sejam eles computadores, telemóveis, tablets, televisores, smartwatches, quiosques.
  • Quem deve estar envolvido: Equipas de UX, UI e Developers
  • Quais são os seus componentes: N/D.
  • Entregáveis: Documento das especificações com os diferentes breakpoints para cada um dos dispositivos.

 

especificações elementos de pagina para desenvolvimento - responsive design direcionamentos-de-páginas - acessibilidade - design system - user interface - ui - protótipos - wireframes - user flows - Checklist de Atividades de UX e de UI para (Re)Lançamento de um Website - 12 Atividades a Considerar11 – Especificações dos Elementos das Páginas e Outros para Desenvolvimento

  • O que é: Uma vez terminado todo o trabalho de UX/UI em termos daquilo que é a estratégia e o design do mesmo, é preciso especificar uma série de elementos para as equipas que vão desenvolver e implementar o website novo ou redesenhado. 
  • Para que serve: As especificações servem para os developers entenderem aquilo que tem de fazer para dar vida ao website. É como se fosse um briefing das equipas de UX/UI, SEO, Analytics e Conteúdos para as equipas de desenvolvimento.
  • Quais são os seus componentes: Existem diferentes tipos de especificações, por exemplo: Especificações sobre as páginas: dimensões de grelhas, e dos breakpoints; Especificações UI: especificações hexa dos diferentes elementos das páginas como do textos, dos CTA, dos backgrounds, dos foregrounds, dos hiperlinks, entre outros; Especificações de interatividade: movimento e animações dos menus, animações e movimentos dos CTAs, animação das mudanças de páginas, entre outras animações de elementos; Especificações de SEO: headings, nomenclaturas dos URLs, direcionamentos, meta descrições… Especificações de Acessibilidade: contrastes entre cores, os próprios headings, responsável design, nomeação de imagens.… 
  • Quem deve estar envolvido: Equipas de UX, de Conteúdos, e de SEO
  • Entregáveis: O principal entregável pode ser o protótipo HF com as diferentes especificações ou um documento word/powerpoint com as especificações.

 

testes de usabilidade - especificações elementos de pagina para desenvolvimento - responsive design direcionamentos-de-páginas - acessibilidade - design system - user interface - ui - protótipos - wireframes - user flows - Checklist de Atividades de UX e de UI para (Re)Lançamento de um Website - 12 Atividades a Considerar12 – Desenvolvimento dos Testes de Usabilidade

  • O que é: São testes de usabilidade feitos ao protótipo e junto dos utilizadores finais.
  • Para que serve: Simples: Testar se o que foi criado é perceptível pelos utilizadores e vai ao encontro daquilo que são as suas necessidades.
  • Quem deve estar envolvido: Equipas de UX
  • Quais são os seus componentes: N/D.
  • Entregáveis: São essencialmente 3, os entregáveis desta atividade: 1 – Guião com as diferentes questões e atividades que, respetivamente, queremos fazer aos utilizadores e queremos que eles façam no protótipo; 2- o próprio protótipo apresentado presencialmente ou remotamente e 3 – uma apresentação dos principais findings e insights. 

 

Conclusão

Lançar um website ou relançar um website dá muito trabalho. Implica muito tempo e muitas atividades. E temos sempre 2 hipóteses: fazê-lo bem ou fazê-lo mal.

Hipótese 1 – Para fazê-lo bem feito devemos:

a) ouvir os utilizadores e 

b) seguir esta checklist de 12 atividades de ux/ui para (re)lançamento do website. 

Hipótese 2 – Para fazê-lo mal feito, indo pelo caminho mais fácil e pelo caminho do adivinhar, também temos 2 hipóteses: 

a) compramos um template ou 

b) começamos logo com o design e a adivinhar features que ficariam bem no website, sem ouvir ninguém. 

No primeiro caso temos sempre retorno no segundo temos sempre problemas.

E vocês que outras atividades de ux/ui acrescentariam a esta lista?

 

Want to read this article in English? Please click here


artigo-blogue-Regresso-ao-Básico-UX-diferente-de-UI-Marketing-Digital

Regresso ao Básico: User Experience (UX) ≠ User Interface (UI) e um pouco sobre Marketing Digital

Introdução

Este artigo não trás grandes novidades, acredito eu. Ou melhor, para quem domina a área não há novidades, mas para quem não domina a área (ainda que esteja à frente das mesmas), há. Ainda há muita confusão na cabeça de algumas Pessoas que estão em Empresas entre User Experience (UX) e o User Interface (UI). Pelo menos quase todos os dias vejo publicações do tipo “….UX/UI” e nalguns casos até chego a conversar com essas pessoas. O Marketing Digital entra no artigo, porque já vi Pessoas em Direções Marketing/Digital de Empresas a misturarem também responsabilidades que são destes profissionais, com as de UX / UI… 

Ainda assim quero tornar este artigo divertido e simples de ler. E por isso dividi-o em 3 partes: 

  1.  irei propor um exercício de reflexão sobre muitas funções que se exercem no mesmo âmbito profissional, mas que não podem ser executadas nem acumuladas pela mesma pessoa
  2. A complementaridade entre User Experience (UX) e User Interface (UI)
  3. O Marketing Digital no meio disto tudo

. . .

Funções e Responsabilidades Complementares mas não iguais, tal como acontece com o UX e o UI

Então, vamos ao que interessa e convido-vos a refletir sobre estas 10 questões. Será que:

  1. Na projeção da sua nova casa contrataria um engenheiro civil? Ou essa é a responsabilidade de um arquiteto?
  2. Pediria um diagnóstico complexo de saúde com respetivos exames e/ou tratamento a um enfermeiro? Ou essa é a responsabilidade do médico?
  3. Deixaria um cardiologista fazer uma intervenção cirúrgica no seu coração? Ou essa é a responsabilidade do cirurgião cárdio-toráxico?
  4. Quando a sua filha tiver a sua primeira menstruação levá-la-á a um obstetra? Ou essa é a responsabilidade do ginecologista?
  5. Admitiria que um psicólogo receitasse medicação ao seu pai? Ou essa é a responsabilidade do psiquiatra?
  6. Se precisasse de desenvolver uma aplicação móvel, queriam um front-end devolver? Ou isso é a responsabilidade do back-end developer? (Neste aspeto, também há muita confusão de conceitos e chega-se a anunciar que se quer um Full stack developer)
  7. Acha que umm chefe de renome contrataria um pasteleiro para assumir a chefia da cozinha de quentes e frios do seu restaurante? Ou isso é responsabilidade de um chefe de cozinha de quentes e frios?
  8. Se precisasse de construir um móvel do estilo séc. XV iria ao carpinteiro? Ou essa é uma arte e ofício do marceneiro?
  9. Precisando de pintar todo o interior e exterior da sua casa, contrataria um artista plástico? Ou essa é uma responsabilidade do pintor? 
  10. Será que a equipa da Ferrari iria buscar um piloto de Moto GP para pilotar o seu Fórmula 1? Ou sabe que a Fórmula 1 em nada tem a ver com o Moto GP, ainda que ambos os desportos exigiam pilotos de alta velocidade?

E poderia continuar por ai fora com muitas mais “questões-exemplos”. Mas acho que deixei o meu ponto claro: 

Assim, como há profissões que são exercidas no mesmo local, ou que os seus profissionais possam ter formação em comum, ou que utilizam o mesmo tipo de ferramentas, e possam inclusivamente ter teorias e práticas idênticas, as funções e responsabilidades não são as mesmas, são sim complementares, tal como acontece com o UX e o UI e o Marketing Digital. 

C’est très simples!!!

. . . 

Algumas das Diferenças entre o User Experience (UX) e o User Interface (UI) 

Nesta segunda fase do artigo vamos ver de forma muito rápida, quais as diferenças entre o UX e o UI. 

  • O UX é pensar em outcomes, UI é pensar mais em outputs 
  • O UX trabalha mais o lado emocional, o UI trabalha mais o lado racional
  • O UX faz-nos sentir algo, o UI faz-nos ver esse algo
  • O UX envolve pensar estrategicamente, UI envolve executar essa estratégia
  • O UX é o pensamento para além do UI, o UI é o resultado do UX
  • O UX faz as perguntas, o UI reflete as respostas a essas perguntas 
  • O UX é mais conceptual, o UI é mais tangível

Em cima disto, poderia falar dos entregáveis que um profissional de UX deve trabalhar e aqueles trabalhados pelos UI designers. E só por ai deveria ser perceptível que as 2 funções devem ter 2 responsáveis distintos, mas tornaria o artigo muito mais longo. Por isso e caso queiram, podem consultar, por exemplo este artigo. 

Ainda assim, para quem é da área, julgo que a diferença ficou bem explícita! Para quem não é da área ou é mas continua confuso, mais dois exemplos.

  • O UX é o esqueleto, o UI são os músculos, os órgãos e a pele
  • O UX é o esboço do artista feito a lápis de carvão, o UI é o desenho final pintado com tinta 

. . .

Marketing Digital e a sua relação com o UX e o UI

Bom, sobre o Marketing Digital a conversa vai ser outra. Bem mais curta, até porque dentro do Marketing Digital temos várias funções e responsabilidades: SEO (e dentro desta outras tantas áreas), e-mail marketing, automação, gestão de redes sociais, gestão de conteúdos, gestão de campanhas, monitorização e analytics…entre outras. E aquilo que acontece com a diferenciação entre UX e UI deveria acontecer, também, para as diferentes sub-áreas do marketing digital.

A relação do Marketing Digital com o UX e o UI dito de uma forma simples é: O Marketing Digital encontra-se a jusante do trabalho de UI, no que há estratégia de lançamento diz respeito e a montante do trabalho de UI e muito interligado com as ações de UX no que há estratégia global do produto/serviço”. 

As diferentes disciplinas do Marketing Digital estão relacionadas com o UX, porque afinal estamos a falar, essencialmente de estratégia, o que não significa, mais uma vez, que as mesmas devam ser exercidas pela mesma pessoa, neste caso pessoa de UX pura e dura ou de UI pura e dura no que às atividades abaixo diz respeito: 

  • Definição de métricas – deve ser feito em conjunto com as equipas e com os stakeholders do produto/serviço e não por uma única pessoa
  • Otimização da conversão – A conversão é algo que está relacionado com o negócio, e considerando que o UX, como já deve estar compreendido, diz respeito a perceber quais as necessidades, expectativas, motivações e frustrações dos clientes, este ponto é algo da responsabilidade dos profissionais de Marketing Digital
  • Configuração e gestão de Google Tag Manager e Google Analytics – responsabilidade dos profissionais de marketing digital ou com formação para tal
  • Definição de requisitos de SEO – responsabilidade dos profissionais de marketing digital ou com formação para tal, nomeadamente SEO técnico, SEO conteúdo,…
  • Conhecimento prático das ferramentas de HTML e CSS – maior responsabilidade dos profissionais de front-end
  • E poderia acrescentar outras tantas atividades desde o SQL, passando pelo código puro e duro até a ferramentas e conhecimentos técnicos de Analytics e BI

Disclaimer: E digo isto, com conhecimento de causa, pois trabalhei com vários profissionais de UX e de UI e de marketing digital, e nenhum deles tem ou tinha conhecimentos mínimos para fazer as atividades acima descritas.

. . .

Conclusão

Como devem ter reparado eu sou defensor que para funções diferentes pessoas diferentes. E a razão é simples: mais competitividade entre pessoas e entre nas Empresas. Porém, isso não significa que uma pessoa com formação em Marketing Digital não possa mudar o seu percurso de carreira e candidatar-se a funções de UX ou UI, ou vice-versa, desde que tenha formação para tal. E também não significa que cada uma destas pessoas deva trabalhar sozinha e em silos ou que não deva ou não possa ter conhecimentos nas outras áreas. Até pode tê-los como hobbie.

E eu sou insuspeito por ter esta opinião, porque tenho uma larga formação certificada e experiência profissional nas áreas de Marketing Digital (SEO, Analytics) e UX e UX Research, ou seja sou aquilo a que chamam um colaborador formado e formatado em T-shape, “valioso” para as Empresas com visão estratégica e com foco nas pessoas (colaboradores e clientes), porque tenho largos conhecimentos nestas áreas complementares e gosto tanto de UX como de Marketing Digital.

Para mim o que significa é que a UX quem é de UX (ou mudou para esta área); a UI quem é de UI (ou mudou para esta área) e a Marketing Digital quem é desta área (ou mudou para esta área, sendo que todas elas têm o seu grau de complementaridade e, portanto a formação em T-shape de um colaborador, é uma mais valia para as Empresas, mas não significa que tenha ou deva assumir estas 3 áreas ou 2 delas, simultaneamente. Não que não o possa, mas acho que não é produtivo nem competitivo, acima de tudo para as Empresas. Pode sim, ser ouvido, consultado, se tiver esse know how e os temas serem discutidos conjuntamente. Os engenheiros civis e arquitetos estão em constante conversações no que a potencial projeto diz respeito e ajudam-se. E faz sentido! Imaginem a monotonia, e as perdas em vários sentidos, se o engenheiro civil não percebesse algo de arquitetura e vice.versa? 

As funções de UX são diferentes das funções de UI e ambas são completamente distintas de quem exerce funções na área do Marketing Digital. 

Aliás, é de extrema importância, na minha opinião, que as Empresas entendam que existe uma complementaridade entre elas. Não o ver desta forma, não é competitivo para ninguém! Não é competitivo para a Empresa, não o é para o colaborador e não o é para os clientes. Tal como não é competitivo nem para o Hospital, nem para os colaboradores, nem para os doentes, ter um enfermeiro a fazer o trabalho de um médico, ou num atelier ou empresa de consultoria haver um arquiteto a fazer o trabalho de um engenheiro civil.

Want to read this article in English? Please click here


artigo-blogue-como-definir-os-principios-de-design

Como definir os Princípios de Design

O que são os Princípios de Design

Os Princípios de Design são um conjunto de considerações que as diferentes equipas comungam com o objetivo de resolver problemas de design e com isso criar novos e bons produtos/serviços.

 

Quais as bases em que assentam os Princípios de Design

É interessante perceber que os Princípios de Design não têm por base temas de âmbito Digital, ou temas do âmbito do Design ou até mesmo temas do âmbito de programação e desenvolvimento de software. Os Princípios de Design têm por base as Leis da Psicologia que explicam o porquê das pessoa se comportarem de determinada maneira, e esses comportamentos podem ser transpostos para a utilização de websites e aplicativos.

Também por este motivo que os profissionais de UX e profissionais de UI devem pensar e desenhar as experiências digitais centradas nas pessoas – human-centered experiences.

Os Princípios de Design devem assentar nas diferentes Leis e Efeitos que advêm de diversos estudos feitos no campo da psicologia comportamental e cognitiva. Como o objetivo deste artigo não é o de descrever, exaustivamente, as principais Leis de UX, ou se preferirem as Leis e efeitos da psicologia comportamental e cognitiva, preparei um pequeno resumo dos mesmos, baseados no livro do Jon Yablonsky – UX Laws – e que e podem descarregar aqui.

 

Integrando os Princípios de Design no Processo Criativo

Uma das formas mais eficientes e, diria mesmo mais inteligentes, de conseguirmos, enquanto profissionais de UX e UI, tomarmos decisões que justifiquem as nossas escolhas é criando os tais Princípios de Design.

 

Os Princípios de Design permitem-nos justificar as nossas decisões de forma inequívoca. É por isso que o Design é objetivo e não subjetivo, o que não significa nem iliba o facto de podermos tomar decisões erradas.

 

Leis de Psicologia Comportamental

Princípios de Design

Regras

 

 Doherty Thereshold – Objetivo para manter as pessoas completamente “interessadas” ao interagir com um dispositivo eletrónico, como o computador, tablet ou smartphone. Se o sistema destes dispositivos derem uma resposta após o limite de 400 ms, as pessoas, eventualmente ficarão ou já estarão desinteressadas.

 

 

 

Feedback1

O feedback reconhece as ações e mostra os resultados para manter as pessoas informadas.

Os aplicativos iOS integrados fornecem feedback perceptível em resposta a cada ação do usuário. Os elementos interativos são destacados brevemente quando tocados, os indicadores de progresso comunicam o status das operações de longa duração e a animação e o som ajudam a esclarecer os resultados das ações.

 

Lei de Hick – O tempo que as pessoas demoram a tomar uma decisão, é proporcional ao número e à complexidade de opções que lhe estão disponíveis

 

Direction over Choice2 (Simple)

CTA único proeminente por screen.

Uma única mensagem de E-mail

Uma pergunta de cada vez na jornada Join, perguntas binárias em vez de escolha múltipla.

Tom de voz simples, consistente e direto.

1 – Apple – Human Interface Guidelines

2 – Bulb – Solar Design System – Princípios de Design

 

As Heurísticas de Nielsen e Molich e os Princípios de Design

As Heurísticas de Neilsen e Molich nada mais são do que Princípios de Design, mas que são ou se tornaram tão “óbvios” que, aplicando-os, estamos a proporcionar uma experiência efetivamente centrada nas pessoas. Como descrito no website da NNGroup: “São chamados de “heurísticas” porque são regras gerais e não diretrizes de usabilidade específicas”.

 

Leis de Psicologia Comportamental

Heurística de Nilesen e Molich

Regras

 

 

Lei de Jakob – As pessoas passam a maior parte do seu tempo a navegar noutros websites. Ou seja, e em termos de modelos mentais, significa que preferem que o seu website funcione e que possam navegar nele da mesma forma que veem os outros websites funcionarem por já terem um padrão mental estabelecido

 

 

 

2 – Correspondência entre o Sistema e o Mundo Real

Se inovar no design, não desvirtuá-lo “too much” ao ponto de construir os modelos iniciais que já existem

Alavancar os modelos mentais que as pessoas já possuem, em famigerado de obrigá-las a aprender tudo de novo que os utilizadores entendem o significado sem precisar procurar noutros sítios

 

 Efeito Estética e Usabilidade – As pessoas tendem a considerar o design esteticamente mais agradável como sendo também o design com melhor usabilidade.

 

8 – Estética e Design Minimalista

Criar designs simples e coerentes e que criem uma expectativa de que realmente vai funcionar

Priorizar features e conteúdo que se foquem no objetivo principal do website

 

Conclusão

Devemos sempre ao desenhar ou redesenhar um website, uma aplicação, um layout de uma loja, a decoração do interior de uma assoalhada e por ai fora, ter presente que o que estamos a fazer é para as pessoas e, portanto, é nosso dever perceber como é que estas pensam para podermos

1 – criar experiências efetivamente centradas nas pessoas – pessoas sobre objetos

2 – ter uma metodologia para resolução de problemas de design – função sobre a forma

3 – justificar as nossas escolhas enquanto profissionais, a todos os stakeholders – objetividade sobre subjetividade

 

Artigo redigido com base na leitura do Livro Laws of UX de Jon Yablonsky

 

Want to read this article in English? Please click here