Os sistemas de design permitem que designers e desenvolvedores criem rapidamente software de qualidade em grande escala. À medida que as necessidades das empresas orientadas a software aumentam ainda mais, os sistemas de design estão evoluindo – eles começam a parecer e a funcionar como APIs.
No desenvolvimento de software, “API” significa “Interface de programação de aplicativos”. Uma API é uma maneira confiável de dois ou mais programas cooperarem. Ele permite que os programas trabalhem juntos, apesar das diferenças de hardware, idioma, arquitetura ou outras restrições operacionais.
APIs alimentam a Internet. Eles são tão poderosos porque incorporam um contrato: o sistema A promete agir de maneira previsível, desde que o sistema B solicite essa ação de maneira acordada. Digamos que o sistema A é o PayPal e o sistema B é o Etsy: o PayPal promete fazer uma transação entre duas contas bancárias (um comprador e um vendedor), desde que o Etsy solicite que a transação seja formatada de maneira segura e confiável, com a permissão de seus usuários.
Enquanto esses contratos estiverem em vigor, o Etsy e o PayPal poderão escrever e reescrever seus próprios sistemas sem precisar fazer check-in. Eles podem trabalhar de forma independente e eficiente, de acordo com suas próprias necessidades. Uma API confiável cria confiança e impulsiona a cooperação.
O modelo de API é a combinação perfeita para comunicação entre designers e desenvolvedores.
Uma pseudo-API
Se você é um designer ou desenvolvedor, já existe uma camada de API entre você e seus colegas. Essa API pode não estar bem documentada ou consistente, mas forma a base da sua comunicação entre si.
Por exemplo, na Bitly (onde trabalho), os designers fornecem informações sobre decisões de design na forma de arquivos de esboço em uma ferramenta chamada Resumo. Estamos trabalhando com engenheiros para garantir que o formato funcione para todos como uma maneira eficiente e precisa de compartilhar especificações.
Esses padrões e acordos informais de trabalho se parecem muito com o início de uma API. Mas nossa documentação não é como a documentação típica de uma API (para um exemplo de uma API bem documentada, consulte a referência da API do Stripe ). A equipe de design não listou nenhum ponto de extremidade. Não há solicitações de amostra para aprender ou valores de retorno esperados para testar. Nossa pseudo-API não possui garantia de tempo de atividade, contrato de nível de serviço ou limites de taxa. Também não falha muito bem. Quando algo dá errado, nenhum erro é gerado e o pager de ninguém dispara.
Uma equipe pequena pode lidar com essa incerteza sem perder muita produtividade. Mas, à medida que a equipe cresce, ela precisa de um contrato mais claro entre designers e desenvolvedores.
Sistemas de Design
Os sistemas de design tornaram-se uma ferramenta essencial para as equipes de desenvolvimento de aplicativos em ritmo acelerado. Um bom sistema de design fornece algumas das documentações que os desenvolvedores precisam para obter informações sobre o que estão criando. Como uma API, um sistema de design é uma abstração. Uma API abstrai algumas das funcionalidades de um programa; um sistema de design abstrai parte do processo de design.
Empresas como a Salesforce lideraram o caminho na implementação de sistemas de design em larga escala. O Salesforce possui milhares de desenvolvedores e designers trabalhando em recursos em várias plataformas e aplicativos. Para permitir esse tipo de trabalho em escala, a equipe colaborou para produzir um sistema de design chamado Lightning .
Relâmpago é um contrato. Por um lado, descreve maneiras muito específicas para os desenvolvedores marcarem seu código para garantir que a experiência do usuário seja entregue de forma consistente. Por exemplo, um desenvolvedor concorda em usar um estilo específico de marcação:
<button class="slds-button">Button</button>Em troca, o Lightning garante que esse botão tenha a aparência e a funcionalidade adequadas. Ele atenderá aos padrões de usabilidade e acessibilidade do Salesforce.
No outro lado do contrato, o Lightning especifica regras para criar ou modificar especificações de projeto. Por exemplo, um designer concorda em seguir as diretrizes para o uso de opções de alternância nos formulários:
Em troca, o Lightning promete que essas decisões de design serão entregues rapidamente aos usuários finais com fidelidade e integridade. O aplicativo continuará a atender aos padrões de desempenho e confiabilidade do Salesforce.
O problema com sistemas de design como APIs
O Lightning funciona para o Salesforce, mas requer uma equipe dedicada de engenheiros e designers. A equipe do sistema de design é a única responsável pelo desempenho contínuo do Lightning: eles mantêm a documentação, instruem os usuários, evangelizam para adoção em toda a organização e monitoram como o sistema está funcionando.
Uma equipe de sistema de design dedicada é necessária porque um sistema de design é apenas uma abstração de baixo nível do processo de design.
Isso significa que a documentação do sistema de design – o site, o wiki ou o arquivo de design que o descreve – é sua aplicação mais útil. Por exemplo, a maneira mais fácil de usar as cores fornecidas pelo Lightning é visitar a página ‘Cores’ no site do Lightning .
Pense nisso como uma lista telefônica. Uma lista telefônica é uma abstração de baixo nível de um diretório de números de telefone. Para encontrar o número de alguém, você folheia as páginas da lista telefônica até encontrar o nome dele. Uma equipe inteira produz a lista telefônica, imprimindo e distribuindo-a regularmente para garantir que ela esteja atualizada.
Adicionar um nível de abstração a uma lista telefônica significa remover o livro impresso da equação. Em vez de folhear as páginas, um usuário digita um nome em uma caixa de pesquisa e vê instantaneamente o número de telefone dessa pessoa. O número pode ser mantido atualizado sem reimprimir um livro robusto. Outros programas também podem ler essas informações: integrações com aplicativos de mensagens podem significar que o usuário final nunca precisa ver o número de telefone.
Abstraindo um sistema de design em uma API de design
Como é uma API de design? Tomando dicas de outras APIs de software, uma API de design tem quatro ingredientes:
- Regras para fazer solicitações
- Um URL chamado terminal que serve como endereço para solicitações recebidas
- Uma definição clara de como é uma solicitação formatada corretamente
- Uma definição clara de qual será a resposta da API em diferentes circunstâncias
Regras para fazer solicitações
Existem muitos protocolos diferentes para APIs na Web, como SOAP e REST. Cada protocolo define regras de como as solicitações podem ser feitas. O REST, por exemplo, define os “verbos” que uma solicitação pode incluir: “POST” adiciona novos dados, enquanto “GET” lê os dados existentes. Da mesma forma, nossa API de design precisa de regras para garantir que um usuário possa interagir com ela de maneiras previsíveis.
Além disso, algumas APIs exigem que os usuários vinculem suas solicitações a uma conta específica. Existem muitas maneiras diferentes de autenticar solicitações, desde tokens simples como senhas até trocas mais complicadas como o OAuth. A autenticação ajuda uma API a proteger a funcionalidade contra uso indevido, acidental ou não.
Uma API de design precisa de regras sobre quais tipos de solicitações podem ser feitas. É somente leitura ou um usuário pode atualizar as informações de design por meio da API também? Que tipo de autorização é necessária para cada tipo de solicitação? Definir e fornecer essas regras aos usuários mantém a API funcionando sem problemas.
Um ponto final
Um terminal é a URL usada para fazer uma solicitação a uma API. Por exemplo, para reduzir um link com a API Bitly, você envia uma solicitação para https://api-ssl.bitly.com/v4/shorten. Nossa API de design pode ter um terminal para cores do sistema, como https://example.com/api/colors. Ou um ponto de extremidade para um componente suspensa: .../components/dropdown.
Solicitações de exemplo
A solicitação mais básica em uma API é simplesmente solicitar a visualização das informações fornecidas por um nó de extremidade. Por exemplo, uma API de design pode ser tratada GET https://example.com/api/colorscomo uma solicitação completa e responder com uma lista de cores.
Solicitações mais complicadas envolvem informações extras na forma dos chamados parâmetros de consulta. Os parâmetros de consulta são adicionados à URL de um terminal e fornecem dados à API. Um exemplo de parâmetro de consulta está ?v=uwprhJZHd5Yno final de https://www.youtube.com/watch?v=uwprhJZHd5Y: a sequência de letras e números indica ao YouTube qual vídeo você deseja assistir.
Um exemplo de solicitação com parâmetros de consulta resolve um caso de uso comum: um desenvolvedor web precisa de cores em formato hexadecimal #ffffff– enquanto um desenvolvedor iOS precisa que elas sejam formatadas como UIColor – [UIColor colorWithRed:1.00 green:1.00 blue:1.00 alpha:1.0];. Nossa API de design pode responder às solicitações GET https://example.com/api/colors?format=hexe GET https://example.com/api/colors?format=uicolorapenas com as cores formatadas corretamente.
Respostas de exemplo
Solicitações de exemplo fornecem aos usuários diretrizes para interagir com a API. Mas isso é apenas metade da equação: a API precisa responder.
Respostas consistentes e bem estruturadas são vitais para APIs eficazes. Por exemplo, se GET .../colorsresultar em uma lista de valores hexadecimais, você não esperaria GET .../colors/blueresultar em valores RGB.
Um exemplo de resposta para a GET https://example.com/api/colorsação pode ser assim:
[ { "name": "blue", "value": "#0000ff" }, {...}]Fornecer este exemplo informa ao usuário que a cor deve ser fornecida no formato hexadecimal, junto com o nome de cada cor. Um desenvolvedor pode usar esse modelo para escrever seu próprio aplicativo, sabendo que a API sempre fornecerá as informações nesse formato.
Erros
Um recurso importante, mas geralmente esquecido, de uma API é o tratamento de erros. Se uma solicitação para a API não resultar na ação desejada, a API deverá responder com algumas informações sobre o que deu errado. Alguns erros comuns são:
- Não encontrado: enviado quando a solicitação era válida, mas não há nada disponível no terminal especificado.
- Erro no servidor: enviado quando algo está errado com a própria API.
- Erro de autenticação: enviado quando a autenticação é necessária, mas não estava presente na solicitação.
- Solicitação inválida: enviada quando a solicitação do usuário não foi formatada corretamente.
Uma boa manipulação de erros em uma API de design ajudaria o software na outra extremidade a saber como proceder. Por exemplo, o envio da solicitação GET https://example.com/api/colors/fuchsiapode retornar um erro ‘Não encontrado’ se fúcsia não for uma cor no sistema. O programa que fez a solicitação pode tentar algo mais comum, como GET https://example.com/api/colors/purple. Se a solicitação original resultou em um ‘Erro do servidor’, o programa solicitante pode esperar e tentar novamente mais tarde.
Juntando tudo
Combinando esses componentes, obtemos um exemplo de como pode ser uma API de design.
Como usar a API
Nossa API aceita corpos de solicitação codificados por formulário, retorna respostas codificadas em JSON e usa códigos de resposta HTTP padrão, autenticação e verbos.
Ponto final
https://example.com/api/colorsSolicitação de exemplo
GET https://example.com/api/colorsResposta de exemplo
[ { "name": "blue", "value": "#0000ff" }, {...}]Este é um exemplo muito simples de como uma API de design poderia fornecer informações de design para outro programa.
O estado atual das APIs de design
Tokens de design
Alguns sistemas de design, como o Lightning ou o Polaris , do Shopify , foram pioneiros no uso de tokens de design. Os tokens de design são valores estruturados em um arquivo legível por máquina, semelhante à resposta que você esperaria de uma API de design.
Theo da Salesforce e Style Dictionary da Amazon estão liderando o caminho para a criação e distribuição de tokens de design. Ambos desempenham a mesma função básica: dado um único conjunto de decisões de design, eles geram uma ampla variedade de formatos adequados para serem usados diretamente em uma plataforma ou aplicativo.
Recentemente, usei o Style Dictionary para criar um conjunto de tokens de design para o Bitly. Esses tokens são então distribuídos via NPM, permitindo que os desenvolvedores da Bitly obtenham a versão mais recente de nossas decisões de design sem precisar cavar nos arquivos do Sketch ou solicitar o Slack. Os tokens de design são um grande passo em direção a uma API de design totalmente desenvolvida. No entanto, eles são gerados e distribuídos em massa. Se você precisar apenas de um token, precisará importar a biblioteca inteira. Isso significa que eles ainda são um tipo de catálogo telefônico, embora seja formatado de forma que o software possa ler com facilidade.
Além disso, os tokens de design são somente leitura. As atualizações nos valores originais exigem um conjunto de ferramentas completamente diferente do que o download e o uso dos tokens. Essa divisão do trabalho exige mais colaboradores, levando aos tipos de equipes dedicadas que vemos publicando e mantendo sistemas de design hoje.
Formatos padrão
Todo sistema de design tem sua própria maneira de definir cores, tamanhos de fonte, espaçamento e estilos de texto. Por exemplo, o Material Design do Google designa 14 tons de cada cor, usando um sistema numerado para indicar o quão escuro é cada tom. Por outro lado, o Lightning usa aliases como $ brand-text-link ou $ color-background para indicar como cada cor deve ser usada. Em “Interoperabilidade”, Brent Jackson descreve como isso torna o desenvolvimento de software – especificamente, passando do Basscss para o Tachyons, ambos bibliotecas CSS – mais difíceis:
A verdadeira tragédia das convenções de nomenclatura divergentes é que, se você começou a criar um aplicativo com o Basscss, mas deseja atualizar para algo mais completo como o Tachyons, precisará fazer muito trabalho manual para migrar. Essencialmente, os modelos HTML escritos com uma dessas bibliotecas não são tão portáteis como se tivéssemos usado uma sintaxe padrão, por exemplo, estilos embutidos.
Jackson continua sugerindo um formato padrão para cores, fontes e tamanhos.
O surgimento de formatos padrão significa que os aplicativos podem funcionar perfeitamente com vários sistemas de design ou migrar de um para outro com pouco esforço. A padronização também torna mais rápido a construção de novos sistemas. Ter um modelo abrangente para sua linguagem de design praticamente elimina um dos problemas mais difíceis no desenvolvimento de software: a nomeação .
Mas uma API também reduz a importância de um esquema de nomeação consistente. Um formato bem documentado e legível por máquina para dados de projeto pode ser facilmente transformado no formato que seu aplicativo exigir.
O futuro das APIs de design
A crescente popularidade dos tokens de design e a busca por um formato padrão para sistemas de design significam que as APIs de design estão ao virar da esquina. Essas APIs ricas habilitarão o que chamo de sistemas de design em rede .
Os sistemas de design em rede são conjuntos de aplicativos e ferramentas capazes de se comunicar entre si sobre decisões de design. Compare isso com o estado da arte: o mais próximo que chegamos das ferramentas de rede são bibliotecas como o react -sketchapp do AirBnB , capaz de importar componentes da base de código de um aplicativo para o Sketch. Essa conexão permite que os projetistas usem componentes atualizados diretamente dos aplicativos da AirBnB. Mas é uma conexão de mão única; os designers não podem enviar alterações de volta aos componentes.
Novos aplicativos como o Modulz prometem dar um passo adiante, permitindo que os designers trabalhem diretamente com o código do aplicativo em um meio visual. Modulz faz parte da revolução do “sem código”, uma unidade para colocar mais do processo de criação de software diretamente nas mãos de designers, analistas de negócios, gerentes de produto e executivos. As APIs de design serão cruciais para essas ferramentas. Em vez de um desenvolvedor atualizar o CSS, HTML e JavaScript para refletir as decisões de design mais recentes, a API de design serve como a conexão entre um designer (ou, Deus nos ajude, uma parte interessada ou cliente) e o produto final.
Essa conexão direta abre maneiras inteiramente novas de criar software. Hoje, decisões de design, como cores, tamanhos de fonte e espaçamento, são inseridas no código de um aplicativo. Um desenvolvedor grava especificações de design no código-fonte, que é compilado e entregue ao usuário final. Isso causa problemas quando muitos desenvolvedores estão trabalhando em um aplicativo: partes diferentes da base de código são atualizadas em momentos diferentes, enquanto diferentes especificações de design são incorporadas. Quanto mais recursos um aplicativo tiver, mais difícil será manter uma experiência consistente do usuário.
Uma API de design permitiria que o compilador de um aplicativo solicite as especificações mais recentes sempre que for executado, garantindo que o resultado esteja sempre atualizado. Os desenvolvedores não precisam mais tomar decisões de design em seus códigos. Não importa o tamanho da base de código, todas as decisões de design são mantidas em um único local e distribuídas quando necessário.
Manter as decisões de design separadas da base de código do seu aplicativo tem outra vantagem: você pode criar lógica na API sem aumentar a complexidade do próprio aplicativo. Por lógica, quero dizer programas que dizem respeito às próprias decisões de design. Esses programas podem ser executados automaticamente ou a pedido de um usuário por meio de um terminal da API. Os testes de acessibilidade podem ser executados todas as noites, fornecendo diretrizes valiosas de uso para usuários que desejam aderir a padrões da web como o WCAG . Esses testes também podem ser executados quando um usuário adiciona uma nova cor ou atualiza uma existente, e a API pode rejeitar a solicitação se a nova cor não atender aos padrões de acessibilidade.
Conclusão
APIs são um paradigma poderoso. Usando as bases estabelecidas pelos pioneiros dos programas em rede, designers e desenvolvedores podem evoluir sua abordagem e desbloquear novas formas de colaboração. E, no entanto, as APIs de design não parecem um trecho da imaginação. Uma abordagem orientada a API é a extensão natural do trabalho atualmente sendo realizado em sistemas de design, incluindo tokens e projetos de padronização.
É por isso que estou tão empolgado com as ferramentas e estruturas orientadas à API de design: um sistema de design totalmente em rede, alimentado por uma API de design, oferece grande alavancagem até para as equipes menores. Usando uma API de design, designers e desenvolvedores podem manter bases de códigos cada vez maiores, implantadas em vários aplicativos e plataformas, sem sacrificar a qualidade ou a consistência. Preocupações de design como acessibilidade podem ser automatizadas e gerenciadas por sistemas dedicados; as alterações podem ser testadas em tempo real, na produção, por um único designer.
À medida que os sistemas de design evoluem para APIs de design com todos os recursos, o futuro do design é brilhante.