.png){kind=small}
.png){kind=small}
Analisar conceitos relativos à usabilidade de uma API é essencial, pois se ela não for relativamente descomplicada, ocorrerão falhas em alguma etapa de sua execução, que impedirão o funcionamento adequado.Portanto, para saber as chances reais de uma API “vingar”, é preciso pensar na usabilidade.Na prática, usabilidade quer dizer quatro coisas:
A importância disso é ter uma API atraente, e não apenas existente. Não é porque você expõe seus dados em forma de API que uma multidão irá usá-la. Mas se a API está à altura das expectativas, já é meio caminho andado.Podemos dizer que este processo de verificação ocorre com base em:
Vamos ver isso com mais detalhes!
Tudo na vida é uma questão de expectativas. "Perfeito" é uma questão de ponto de vista.Portanto, o primeiro passo de qualquer projeto é definir a persona, ou seja, as características pessoais e profissionais do público-alvo.O desenvolvedor precisa sentir a dor do usuário (neste caso, pode ser o próprio consumidor final da app), aplicando questões relativas a seu comportamento em relação à aplicação.Aqui entra o fator compreensibilidade.Quando falamos nisto, nos referimos ao fato de as pessoas que irão utilizar a API devem ser capazes de entendê-la, sem maiores dificuldades. Isto significa que quanto mais intuitiva ela for, maior será a usabilidade, naturalmente. Ou seja, a compreensão de alguém que acabou de chegar nessa API é alta, já que ela é intuitiva.Um exemplo disso é um indicador que gostamos de usar nas APIs, chamado Time to First Hello World (TTFHW). Quanto mais tempo alguém levar para conseguir criar suas primeiras e mais simples apps com uma API, pior. (Se quiser ver outras métricas e indicadores legais para se ter em uma API, clique aqui).Isto permitirá identificar o que é preciso criar na API para satisfazer os padrões de uso do público-alvo e ampliar sua experiência, tornando-a diferenciada e aumentando o engajamento com o público.
Para exemplo, é possível utilizar funcionalidades já conhecidas por devs na API, para que se sintam familiarizados ou mais confiantes em utilizá-la. Ou seja, uma API programada em Java, por exemplo, pode ter mais chances de ser interpretada com facilidade por usuários comuns que já conhecem essa linguagem, ou até mesmo baixar este suporte para rodar outros conteúdos, como gráficos executados por outros programas e games.Inclusive, esse é um bloco de construção muito importante na exposição de APIs. Se você quer que ela tenha um bom nível de usabilidade, favoreça linguagens de programação populares e abrangentes.Porém, o que é popular, no seu meio de atuação?Talvez seja Java, ou .NET, ou Go, ou Javascript, ou Ruby, ou Python... Eu poderia continuar citando linguagens diferentes, sem nunca chegar à correta. É por isso que você deve estudar a persona, o perfil adequado que você espera que usará e aproveitará sua API. Qual linguagem é mais adequada para a sua persona?Fugir disso prejudicará qualquer dev interessado na sua API, mas que nunca teve contato com a linguagem de programação obscura que você escolheu.
Em situações nas quais o usuário da aplicação (seja ele o dev, o usuário final ou os próprios criadores da API) precisa executar determinada função, como o design da API ajuda a tornar esta tarefa mais ágil?Já vimos vários exemplos péssimos de design, com recursos bizarros e versionamento duvidoso. E por mais que certas APIs possam ter particularidades em relação às demais, há certos padrões de design que são praticamente obrigatórios, visto que é o padrão no mercado.E você não quer que um dev acostumado a usar APIs chegue até seu suporte com dúvidas sobre versionamento ou códigos de erro.A documentação também deve ser clara e objetiva, ajudando não só a diminuir o tempo de pesquisa como também organizar as opções dadas a este dev.Organizar o ponto de entrada da API, no momento da estruturação, é essencial para facilitar este processo depois. Por exemplo, usar o código fonte como documentação para orientação inicial de determinada ação, de modo que a partir de um lugar único nas classes, o programa encontre sempre um ponto de início rápido para ajudar as pessoas a realizarem seus objetivos.Nesse ponto, não posso deixar de recomendar nosso Ebook de Blocos de Construção para APIs e nosso Webinar de Design de APIs. Ambos ajudarão você a ter uma estrutura bem completa na sua API.
Uma API é essencialmente uma ferramenta de comunicação entre dois sistemas. Por isso, é preciso rastrear os bugs mais comuns na troca de informações entre API e app.Essa é uma questão básica e central na usabilidade de qualquer tipo de software, e APIs não são exceção.Dificuldades em mover dados ou tratar erros? Problemas ao acessar componentes adicionais que ajudam sua API a rodar ou ao fazer as chamadas? Neste caso, é preciso identificar os erros e trabalhar em melhorias focadas.Há inúmeras razões para um programa ou API apresentar bugs, e esse é um assunto cheio de detalhes, por si só.Coloque no planejamento da sua API uma série de testes e espaço para correção de bugs.
É preciso pensar nos nomes que você dará a cada recurso em sua API. Para isso, é necessário entender o que o usuário precisará saber para utilizá-la com facilidade, dialogando em bom entendimento com as funções disponíveis.Essa é uma preocupação que deve ser levada em conta desde o início do Design da API, considerando que recursos você quer expor, e sob quais categorias eles estão aninhados.Não só isso, mas as mensagens de erro, códigos HTTP e exibição de mensagens para os usuários finais das apps devem ser sempre claros e objetivos. Retomando o primeiro ponto, é preciso levar em conta as necessidades e formas de comunicação da sua persona.É sempre bom ter um linguajar voltado para leigos, mas sem subestimar a inteligência e conhecimento dos devs que usarão sua API.Ter um glossário de termos e um sistema de Suporte ativo e funcional são boas dicas para garantir a comunicação efetiva.
É preciso simular seu uso no dia a dia dos clientes finais, através da abertura interna de auditoria de UX (experiência do usuário) em sua API.Ou seja, pessoas dentro da sua empresa (mas fora da equipe de desenvolvimento da API) conseguem usá-la de forma satisfatória?Um trabalho de auditoria pode estar pautado nos seguintes itens, devendo contar com a contribuição de todos os envolvidos e não só dos programadores em si:
Vários dos problemas acima podem ser resolvidos com uma Documentação de qualidade. Esse é o primeiro passo para um Suporte Self-service, que é bem mais barato que o Suporte tradicional. Simples: tenha material pronto para responder as principais dúvidas e ensinar aqueles que querem usar sua API.Documentar significa criar um guia sobre tudo na API, desde uma listagem completa dos recursos e métodos, com exemplo de código e retornos, até os limites de uso, códigos HTTP, e muito mais.Temos algumas boas referências aqui para ajudá-lo na criação da Documentação de uma API.E é claro, tudo isso depende do nível de conhecimento e particularidades da persona alvo, projetando funcionalidades compatíveis com os interesses desse público, para tornar suas funções e propriedades legíveis para diferentes perfis que tenham sido definidos.É necessário ter também o que chamamos de plano de evolução ou Roadmap: devs precisam documentar desde o início a projeção do que pode acontecer com a API no passar do tempo, sendo que ela pode tanto ser toda reescrita ou simplesmente melhorada, corrigindo falhas e acrescentando recursos.
A API pode, ainda, ser planejada para vir antes ou em conjunto com a solução propriamente dita, em uma estratégia conhecida como API First (clique aqui, caso não saiba do que se trata).Desse modo, ao invés de ela ter de se ajustar inteiramente à app, ocorra o inverso: a aplicação seja concebida para já executar tudo o que a API propuser, considerando também futuras melhorias e novos recursos, descritos no Roadmap (leia o item acima).Nesta parte de experiência, também entra uma questão muito importante: o estímulo à continuidade de uma estratégia iniciada com a API. Por exemplo, como falamos, APIs podem sofrer atualizações constantes e nem sempre ou quase nunca permanecem em suas versões iniciais.É por isso que bibliotecas de diferentes linguagens (populares com o seu público) são tão importantes. Se sua API é lançada pensando em Java e Ruby, e de repente você decide largar o suporte à uma dessas linguagens, tenha em mente que perderá uma base já criada de usuários.O mesmo ocorre com a "aposentadoria" de recursos e métodos. Empresas como Twitter e Facebook são bastante criticadas por mudarem suas políticas de uso, limites e recursos, tornando completamente obsoletas certas aplicações.Se for fazer isso, pelo menos avise os devs com uma boa antecedência, antes de interromper definitivamente aquela característica da API.Porém, sempre que puder, evite fazer isso. É preciso pensar que para criar uma API, são investidos tempo e recursos que, se não forem bem empregados, não justificarão a iniciativa.
O volume de utilização da API na prática será um indicador importante de sua usabilidade.Tenha em mente as APIs mais famosas e populares do mundo e imite suas estruturas para criar a sua. Se essas APIs possuem uma base de usuários grande, a chance de terem um excelente nível de usabilidade com certeza é alto.Concluímos assim que estabelecer prioridades para organizar internamente o time de desenvolvimento em conformidade desde o início com a interação entre usuários e projetos é essencial para atingir os objetivos finais.E é claro, tendo sempre em mente sua persona e definição da sua estratégia para satisfazer as necessidades dela.E então, entendeu melhor o que define a usabilidade de uma API? Para saber mais ainda sobre o assunto, não deixe de conferir também nosso post sobre 5 formas de ganhar dinheiro com APIs!
