5.0 Introdução à Parte 5: Design de UI e UX
Esta parte trata de onde o software encontra as pessoas que o usam. Isso cobre muita coisa: a pesquisa que revela o que os usuários precisam, a interface e o sistema de design que a apresentam, as palavras que guiam a ação, a acessibilidade e o suporte a idiomas que a tornam utilizável por todos e a engenharia de front-end que a entrega à realidade bagunçada de navegadores e dispositivos reais. É tentador tratar tudo isso como decoração que se aplica no fim. Por favor, resistam. É aqui que todo o trabalho a montante ou chega ao usuário ou desmorona, e isso é decidido muito antes de a última tela ser polida.
Para grandes equipes, o design de produto é na verdade um problema de coordenação. Quando dezenas de esquadrões entregam num único produto compartilhado, as decisões independentes se acumulam numa bagunça: fluxos duplicados, terminologia contraditória, componentes inconsistentes e um pipeline de idiomas de que ninguém é dono. A correção em todos os capítulos aqui tem a mesma forma. Transformem decisões pontuais em ativos compartilhados e governados, como personas, um sistema de design, uma estratégia de conteúdo, um framework de internacionalização (i18n), bibliotecas de componentes e orçamentos de desempenho, para que muitas equipes trabalhando separadas ainda somem uma única experiência coerente.
Empresas e governo elevam ainda mais as apostas. O software corporativo muitas vezes tem usuários cativos, e eles pagam pelo mau design em treinamento, erros e carga de suporte e não indo embora. Os serviços governamentais alcançam o público inteiro (inclusive pessoas em crise, em dispositivos antigos, com pouca confiança digital ou sem nenhum provedor alternativo), então a qualidade do design se torna uma questão de equidade e de confiança cívica. Aqui, a acessibilidade não é um extra desejável, mas um mandato legal: os órgãos públicos são obrigados por lei a construir software que as pessoas com deficiência possam usar, e as obrigações de linguagem simples e de acesso linguístico também costumam ter força de lei.
Capítulos desta parte
5.1 Fundamentos de UX: As práticas de pesquisa, modelagem de usuários e design thinking que permitem a uma organização tomar decisões de produto baseadas em evidências em vez de adivinhar e dão a toda equipe o mesmo mapa do usuário.
5.2 Design de UI e sistemas de design: O ofício de dar forma ao que as pessoas veem e tocam e o sistema compartilhado e governado de tokens, componentes e padrões que mantém coerentes milhares de telas de muitas equipes.
5.3 Acessibilidade: Construir software que pessoas com deficiência possam perceber, operar, entender e usar, tratado ao mesmo tempo como dever legal, dever ético e simplesmente bom design.
5.4 Design de conteúdo e comunicação: Dar forma às palavras, mensagens e comunicações que um produto usa para ajudar as pessoas a agir, em linguagem simples e numa voz consistente, porque as palavras são interface.
5.5 Internacionalização e localização: A arquitetura que permite ao software se adaptar a qualquer idioma e região e o fluxo de trabalho que o traduz e o adapta culturalmente para cada localidade.
5.6 Engenharia de front-end: Construir a camada voltada ao cliente para um ambiente que vocês não controlam, com atenção à longevidade dos frameworks, à estratégia de renderização, ao desempenho e à resiliência.
5.7 Desenvolvimento de aplicativos móveis: Construir para dispositivos móveis, cobrindo as abordagens nativa, multiplataforma e de aplicativo web progressivo, as diretrizes de design das plataformas, as restrições de uso offline, de bateria e de fragmentação, a distribuição em lojas de aplicativos e a segurança e a acessibilidade móveis.
5.8 Pesquisa de design e testes de usabilidade: Reduzir o risco de construir a coisa errada por meio de pesquisa generativa e avaliativa, o método certo para cada pergunta, testes de usabilidade bem feitos, recrutamento representativo e uma síntese que de fato muda as decisões.
5.9 Design de serviços: Projetar o serviço inteiro que uma pessoa vivencia entre canais e ao longo do tempo, de palco e de bastidores, usando blueprints de serviço e mapas de jornada e alinhando a organização em torno do serviço e não de uma única tela.
5.10 Design de visualização de dados: Escolher o gráfico certo para a pergunta e codificar os dados com honestidade, aplicando a excelência gráfica, paletas acessíveis e seguras para daltônicos e anotação clara, para que um gráfico informe uma decisão em vez de enganá-la.
Como estes capítulos se relacionam
Estes capítulos formam um fio condutor único do entendimento à entrega. Os fundamentos de UX (5.1) estabelecem quem é o usuário e que trabalho ele tenta fazer. A UI e os sistemas de design (5.2) dão a esse entendimento uma forma visual consistente. O design de conteúdo (5.4) fornece as palavras que o carregam. A engenharia de front-end (5.6) entrega o resultado. A acessibilidade (5.3) e a internacionalização (5.5) não são etapas separadas, mas qualidades tecidas por todas as outras: uma experiência acessível e traduzível é projetada desde o início em componentes compartilhados, padrões de conteúdo e código, nunca parafusada depois. O capítulo 5.3 em particular se apoia no capítulo 5.2 para resolver a acessibilidade uma vez em cada componente e no capítulo 5.6 para preservá-la em marcação semântica e baseada em padrões.
A parte também alcança o resto do guia. O padrão de “ativos em vez de soluções pontuais” aqui espelha o pensamento de plataforma compartilhada do capítulo 8.4 (engenharia de plataforma e experiência do desenvolvedor), e os valores e formas de trabalhar dos capítulos 1.1 e 1.4 definem as condições organizacionais que tornam possível a coerência de design. As verificações de acessibilidade, de regressão visual e de orçamento de desempenho pertencem aos pipelines de entrega do capítulo 8.1 (CI/CD e entrega), para que a qualidade seja imposta a cada mudança e não auditada logo antes do lançamento. E o monitoramento de usuários reais (dados de desempenho coletados dos dispositivos e redes de usuários de verdade) de que o desempenho do front-end depende se liga diretamente às práticas de observabilidade do capítulo 9.2. Bem feito, o trabalho aqui é o que torna os sistemas descritos em outras partes realmente utilizáveis pelas pessoas a quem se destinam.