Linha Datasul

Árvore de páginas

O que é Experiência do Usuário (UX)?



Experiência do Usuário (UX) é o valor oferecido aos usuários quando eles estão usando o seu produto. É um termo que está bastante associado com a beleza de uma interface de usuário, mas principalmente, desenhar um projeto de experiência do usuário (UXD ou UED) é um processo de melhorar a satisfação do usuário com o produto, melhorando a usabilidade, a acessibilidade e o prazer proporcionados na interação com o produto. Desenvolvedores investem uma considerável quantidade de tempo para garantir  que cada interação, cada elemento da interface seja o mais agradável possível para o usuário.



Produzir o melhor tipo de UX é principalmente criar processos. Processos que as equipes de UX utilizam para garantir que seus resultados sejam de alto valor agregado, desejado e utilizável pela comunidade. Não é somente apresentar beleza de interface. Eles garantem que nestes processos todas as partes interessadas são envolvidas para que não existam supresas  súbitas no final. Eles também fazem pesquisa, teste de usuário e prototipagem suficientes para garantir que todas as ideias ou designs que estão gerando sejam compatíveis com os usuários-alvo.



Design não é só sobre aparência e sentimento. Design é como funciona - Steve Jobs



Porque você deveria se preocupar sobre o Design de uma API?

O interessante sobre uma API seria ter um ciclo de vida, que contenha estágios como:

  • Planejamento;
  • Depuração;
  • Testes automatizados;
  • Documentação;
  • Monitoramento e;
  • Publicação desta API.

Para então os usuários poderem consumi-la.



O planejamento e depuração em uma API são os primeiros e mais importantes passos do ciclo de vida. Qualquer bom engenheiro pode te dizer que se você começar com uma fundação instável ou uma base ruim, logo entrará em colapso. O mesmo é válido para as APIs. Se você não fizer um bom planejamento da API, os efeitos serão em cascata e atingirá as outras etapas do ciclo de vida.



Quando as API´s já estão prontas, mudanças são difíceis, caras e demandam tempo. Pior ainda, realizar correções e mudanças em APIs que já estão no cliente. O planejamento permite programar todos os detalhes, de forma a iterar várias propostas e possibilidades e executar análises hipotéticas. Enfim, mudanças no início do planejamento de uma API são mais baratas ;)


O planejamento das APIs nos ajuda a evitar a construção de APIs erradas ou do jeito Errado!




Mesmo assim, você ainda vai encontrar mais desenvolvedores codificando suas APIs do que planejando elas. As APIs, são sempre consideradas para consumo de maquinas e não para uma interface orientada ao usuário, como resultado disso as organizações não investem muita atenção e recursos para criar um processo de desenvolvimento de APIs.  Contudo, como hoje as arquiteturas de micro-serviços estão conquistando o mundo, as APIs estão começando a parecer mais como um produto do que uma tecnologia. Nesta visão estão proporcionando mais funcionalidades para os usuários finais.



No mundo API, construímos algo em uma máquina para uma máquina usar e isso é errado, pois  existem pessoas no outro lado que são os clientes da API.




Planejando o melhor UX, mas para APIs



Muitas APIs RESTful projetadas hoje não passam de navegadores de objetos que fornecem representações internas dos objetos de domínio/negócios sobre protocolos HTTP/S como uma camada de transporte. Então, como você pode fazer o melhor projeto de APIs, como você pode garantir que todas as APIs que você desenvolver seguem padrões consistentes, como você pode garantir que novos integrantes da equipe não reinventem a roda criando projetos de  APIs que o resto do time já está saturado. Se você ler estas questões de novo, você vai descobrir que está faltando o processo de planejamento de APIs similar ao que os designers de UX empregam e esse é o tipo de problema que eles resolvem diariamente em suas rotinas.



Um bom UX deveria seguir as regras de usabilidades definidas por Peter Morville conhecidas como UX HoneyComb em tradução livre "Favo de mel":


Parar criar um ótimo projeto de API você deve responder as seguintes perguntas ao projetá-la:
Util: A API é útil do ponto de vista do usuário final?
Utilizável: A API pode ser usada de forma rápida por um desenvolvedor e fornecer funcionalidades fáceis de usar?
Desejável: A funcionalidade fornecida pela API é algo que gera vontade de utilizar por parte dos desenvolvedores e usuários finais?
Localizável: A documentação da API pode ser encontrada facilmente e os desenvolvedores podem começar a usá-la imediatamente?
Acessível: A API pode fornecer funcionalidade para usuários finais que possuem restrições/limitações técnicas ao consumi-la?
Credibilidade: Os dados fornecidos pela APIs são confiáveis?
Valor: A API contribui para os resultados da empresa e melhora a satisfação do cliente?


Definindo o Processo de Planejamento para APIs


O poder de um design está tanto nas etapas adotadas para criá-lo quanto no resultado final. Um processo de planejamento te ajuda a manter a transparência e eficiência enquanto projeta a solução. Isso promove uma expectativa clara e diminui os riscos de gerar resultados indesejáveis nas entregas.
O processo de planejamento conhecido como Diamante Duplo (British Design Council) é um desses processos. Ele permite que sejam criados planos intencionais de tomada de decisão explorando várias opções (pensamento divergente) enquanto validam as mais fortes e descartam as mais fracas (pensamento convergente).

Esta abordagem te ajudará a alcançar as duas coisas mais importantes em qualquer processo de planejamento:

1. Planejar a coisa certa

2. Planejar do jeito certo



Planejando a Coisa Certa!

Esta etapa é dividida em Descoberta/Pesquisa e Definição/Síntese. Ao projetar algo novo é muito fácil para as pessoas extrapolarem o escopo atual do problema e colocar todo seu esforço projetando algo que provavelmente ninguém quer ou irá usar. Esta fase do planejamento nos mantém com os "pés no chão" e garante que estamos projetando a coisa certa fazendo pesquisas consistentes e definindo corretamente o problema a ser resolvido.





Descoberta/Pesquisa: 

Quando você está construindo um novo Produto, Funcionalidades ou uma API, você está tentando resolver um problema. Para isso você precisa primeiramente entender o problema. Certo?Então, sempre tente ter o domínio de conhecimento sobre esse problema.  Tente entender qual o problema que você está tentando resolver, para quem isso está sendo desenvolvido, etc. Esclareça os casos de uso e requisitos. Pesquise se existem soluções já criadas para entender como resolveram o mesmo problema e como você pode aprender com esta solução observando a arquitetura/decisões técnicas. Repasse o conhecimento para a equipe e todos os interessados. As diferentes perspectivas te dará uma visão mais ampla sobre a sua API e sobre as decisões técnicas que você está planejando fazer a partir deste ponto.

Esta etapa resultará em muita informação desestruturada, redundâncias e conflitos entre casos de  uso e requisitos. Portanto, na próxima etapa é o momento de estruturar essas informações para que você possa tomar as melhores decisões sobre a sua API.


Definição/Síntese: 

A partir dos dados brutos, encontre tendências e insights que apliquem para diferentes usuários e cenários. Este estágio também é o momento certo para sinalizar qualquer dependência que sua API pode ter com outro serviço, o que é bem comum em uma arquitetura de micro-serviços.  Defina seus modelos de recursos e os relacionamentos entre eles. Isso irá te ajudar a identificar todos os recursos que você precisa expor nas APIs. É preciso também, descrever todos os comportamentos e expectativas da API. Assim quem for utilizar a API não precisará fazer nenhuma suposição. Ao fazer isso será possível identificar o conjunto de lógicas de negócio que farão parte do serviço ou da solução para o cliente.


Planejando do Jeito Certo!

Esta etapa é dividida em Desenvolvimento/Ideação e Entrega/Implementação. Nesta fase será garantido que independente do que você decida, o que for planejado será executado da forma correta para não comprometer a qualidade, segurança e as melhores práticas descritas pela organização.





Desenvolvimento/Ideação: 

Uma vez que estiver claro "O que é preciso alcançar" com a utilização das APIs, chega o momento de projetar essa APIs você pretende comunicar e fornecer com as mesmas. Documentar as APIs utilizando ferramentas como OpenAPI/Swagger, RAML, ect, é uma ótima maneira de expressar a importância dos aspectos de uma API. Especialmente as decisões relacionadas ao 'frontend' e de arquitetura, os quais são visíveis para quem consome e podem ser verificadas na documentação. Uma desvantagem desse tipo de documentação é que elas podem ser muito técnicas, demasiadamente detalhadas e de difícil colaboração. Uma alternativa para isso é importar do Swagger, OpenAPI ou RAML a especificação para dentro de uma ferramenta client REST, como o Postman que oferece suporte ao desenvolvedor de API.


Entrega/Implementação: 

Após você obter sucesso no planejando sua API é hora de começar a implementação. Mas antes de iniciar a codificação das APIs é preciso estabelecer alguns testes para as APIs, para assim garantir que qualquer mudança durante o desenvolvimento acordado nas requisições e respostas, estes testes comecem a falhar. Então é possível atualizar o código ou comunicar todos os efeitos para o time. No Postman existe o conceito de colaboração, isso promove constante visualização entre os participantes e muitos feedbacks podem ser aproveitados dessa interação.




Construindo um Guia de Estilo, mas para APIs




Quando se trabalha em uma equipe, a qualquer momento um novo membro pode ser inserido. Depois de um certo tempo fica difícil manter a qualidade, consistência e segurança das APIs. Imagine que se acontece de um novo desenvolvedor começasse a seguir sua própria convenção para criação de endpoints, autenticação, headers, query parameters, respostas de sucesso e erro, enfim.






As equipes de design enfrentam um desafio parecido quando criam uma nova interface. Eles trabalham nisso construindo Guia de Estilos, os quais garante que cada um no time utilize os mesmos componentes, cores, tipografia, etc. Utilizar um Guia de Desenvolvimento torna o processo de construção de APIs mais fácil, com relação a comunicação entre as equipes, mantém a interface consistente a longo prazo e traz agilidade no planejamento e processo de desenvolvimento .




Então, por que não seguir um Guia de Desenvolvimento?






Isso também garantirá que a experiência do desenvolvedor seja a mais suave possível, tanto para quem cria quanto para quem consome a API.





Algumas coisas são importantes ao criar um Guia de Desenvolvimento de APIs:

  • Estrutura da URL;

  • Métodos das Requisições;

  • Request/Response Headers;

  • Response status codes;

  • Erros ;

  • Versionamento;

  • Filtros/Paginação/Ordenação.






Um pensamento final...


Como qualquer processo de desgin, o processo de design de API precisa ser um processo iterativo. Publicar a API para seus usuários não significa que é o fim do ciclo de vida da API. Você precisa manter o canal aberto para feedbacks constantes dos consumidores e garantir que continuará aceitando sugestões e usando o mesmo processo de design.









Fonte: Prashant Agrawal Product Engineer @Postman